respons pÅ hØringskommentarer til … · iec 81346-2: såfremt udvalgte dele af denne overhovedet...

cuneco står for fællesskab. Vi udvikler det fælles grundlag for

digitaliseret samarbejde i byggeri, anlæg og drift. Målet er øget

effektivitet og produktivitet gennem bedre udveksling af

informationer. www.cuneco.dk

cuneco – en del af bips

Dato 22. juni 2012

Projektnr. 11 011

RESPONS PÅ HØRINGSKOMMENTARER TIL CUNECOS KODESTRUKTUR-PROJEKT cuneco har behandlet høringskommentarerne til cunecos oplæg til en CCS-kodestruktur for bygningsdele og rum, der blev fremlagt på en høringsworkshop den 15. marts 2012. Her kan du se alle høringskommentarer og cunecos svar på dem. Læsenøgle for kommentarskabelon

Felt i kommentarskabelon Betydning

Nr. Høringskommentarens nummer, tildelt af cuneco

Udfyldt af Henvisning til kommentarstiller

Evt. henvisning til slide eller dokument Henvisninger til slides, refererer til præsentationer af rapporten ved høring den 15. marts 2012. Henvisninger til dokument refererer til høringsrapport ”CCS kodningsregler” af 5. marts 2012.

Paragraf / figur eller tabel i slide eller dokument

Henvisning i relation til hhv. præsentationen eller høringsrapporten

Kommentar Kommentar fra kommentarstiller

Foreslået ændring Foreslået ændring fra kommentarstiller

Respons og svarkategorier Definition af svarkategorier: Svarene ”Accepteret”, ”Delvist accepteret”, ”Ikke accepteret” og ”Noteret” er anført ud fra anvendelse i tilretning af rapporten ”CCS kodningsregler”. ”Noteret” De i høringssvarene anførte foreslåede ændringer er opgaver eller kommentarer, der ligger uden for kodeprojektet, og hvor kommentaren er noteret til brug i processen eller til brug i øvrige arbejdsgrupper. ”Accepteret” De i høringssvarene anførte foreslåede ændringer indarbejdes direkte i revisionen af rapporten. ”Delvist accepteret” De i høringssvarene anførte foreslåede ændringer har givet anledning til indirekte eller delvise ændringer, der indarbejdes i revisionen af rapporten. ”Ikke accepteret” De i høringssvarene anførte foreslåede ændringer indarbejdes ikke i revisionen af rapporten. Der er anført en begrundelse herfor.

Kommentar fra cuneco cunecos svar på kommentaren

Nr. Udfyldt

af Slide eller

doku-ment

Paragraf / figur eller

tabel i slide eller

doku-ment

Type af kom-

mentar

Kommentar Foreslået ændring Respons Kommentarer fra cuneco

1 Bygge-

skade-

fonden

Generel De systemer, som beskrives i

rapporten, er efter Byggeskadefondens

opfattelse den samme uheldige

sammenblanding af metoder, som var

en væsentlig svaghed ved DBK.

Rapporten vurderes derfor at være

uegnet som grundlag for det videre

arbejde, og det vurderes dermed også,

at der på det foreliggende grundlag ikke

er basis for at gå ind i en detaljeret

vurdering og diskussion af elementer i

rapporten.

Noteret Da kommentaren er identisk med

kommentaren fra Landsbyggefonden

(høringskommentar nr. 8), henvises til

svar til denne.

2 Bygge-

skade-

fonden

Generel Der er i den danske byggesektor efter

Byggeskadefondens opfattelse primært

behov for en egentlig klassifikation af

bygningsobjekter herunder af

hovedklassen bygningsdele.

Det vurderes som positivt, at der tales

om en egentlig klassifikation.




svar til denne.

3 Bygge-

skade-

fonden

Generel Når klassifikationen udvikles /

foreligger, vil der være behov for at

beskrive hvilke egenskabsdata, der er

relevante i de enkelte klasser.




svar til denne.

4 Bygge-

skade-

fonden

Generel De i rapporten beskrevne aspekter er

simpelthen egenskaber knyttet til

objekterne på lige fod med øvrige

egenskaber.

Ikke

accepteret

Da kommentaren er identisk med



svar til denne.

5 Bygge-

skade-

fonden

Generel Byggeskadefonden tager her forbehold

for aspekttanke-gangen, og det må

forudsættes at de beskrevne aspekter

ikke influerer på den senere udredning

af egenskaber.

Accepteret Da kommentaren er identisk med



svar til denne.

6 Bygge-

skade-

fonden

Generel Der må her endvidere tages forbehold

for at den skitserede kodning ikke bliver

bestemmende for udviklingen af en

kommende klassifikation.

Delvist

accepteret

Da kommentaren er identisk med



svar til denne.

7 Bygge-

skade-

fonden

Generel Det anbefales således, at processen

omkring klassifikation starter helt forfra

i et åbent og fordomsfrit

udviklingsmiljø.

I en sådan proces kan de nødvendige

eksperter på området inddrages med

skyldig hensyntagen til brugernes

egentlige behov samt til, at

klassifikationen skal være

værdiskabende for branchen i bred

forstand.




svar til denne.

8 Lands-

bygge-

fonden

Generel De systemer, som beskrives i

rapporten, er efter Byggeskadefondens

opfattelse den samme uheldige

sammenblanding af metoder, som var

en væsentlig svaghed ved DBK.

Rapporten vurderes derfor at være

uegnet som grundlag for det videre

arbejde, og det vurderes dermed også,

at der på det foreliggende grundlag ikke

er basis for at gå ind i en detaljeret

vurdering og diskussion af elementer i

rapporten.

Noteret Da CCS-forslaget netop imødekommer

den tidligere rejste kritik og nu giver

mulighed for både at kunne foretage en

simpel klassifikation og en mere

avanceret identifikation, er det svært at

forstå kommentaren. Der savnes derfor

en mere detaljeret problembeskrivelse

af ”samme uheldige sammenblanding

af metoder..:”

9 Lands-

bygge-

fonden

Generel Der er i den danske byggesektor efter

Byggeskadefondens opfattelse primært

behov for en egentlig klassifikation af

bygningsobjekter herunder af

hovedklassen bygningsdele.

Det vurderes som positivt, at der tales

om en egentlig klassifikation.

Noteret

10 Lands-

bygge-

fonden

Generel Når klassifikationen udvikles /

foreligger, vil der være behov for at

beskrive hvilke egenskabsdata, der er

relevante i de enkelte klasser.

Noteret Kommentaren overføres til

egenskabsgruppen (der arbejder med

disse emner).

11 Lands-

bygge-

fonden

Generel De i rapporten beskrevne aspekter er

simpelthen egenskaber knyttet til

objekterne på lige fod med øvrige

egenskaber.

Ikke

accepteret

Aspekterne er forskellige måder at ”se”

samme objekt på, og herunder de

egenskaber der er knyttet til

objekterne.

12 Lands-

bygge-

fonden

Generel Byggeskadefonden tager her forbehold

for aspekttanke-gangen, og det må

forudsættes at de beskrevne aspekter

ikke influerer på den senere udredning

af egenskaber.

Accepteret Aspekterne har ikke indflydelse på

egenskaberne der knyttes til et objekt.

13 Lands-

bygge-

fonden

Generel Der må her endvidere tages forbehold

for at den skitserede kodning ikke bliver

bestemmende for udviklingen af en

kommende klassifikation.

Delvist

accepteret

Kodningen dikterer ikke direkte

indholdet af klassifikationen, men der

er en del bindinger til kodeprincipperne

som vil have indflydelse på

inddelingskriterierne for klasserne på

de øverste niveauer. Det er nødvendigt

for at koden kan være konsistent og

stabil gennem livscyklus for et objekt.

14 Lands-

bygge-

fonden

Generel Det anbefales således, at processen

omkring klassifikation starter helt forfra

i et åbent og fordomsfrit

udviklingsmiljø.

I en sådan proces kan de nødvendige

eksperter på området inddrages med

skyldig hensyntagen til brugernes

egentlige behov samt til, at

klassifikationen skal være

værdiskabende for branchen i bred

forstand.

Noteret Det foreliggende projekt har haft til

formål at beskrive principperne for

hvordan kodestrukturen skal være

opbygget. Sideløbende har cuneco

gennemført en behovsanalyse, der har

haft til formål at beskrive hvor

anvendelse af klassifikationen vil give

værdi og dermed også, hvad der skal

klassificeres. Da behovsanalysen har

haft en bred deltagelse af

repræsentanter fra branchen ser

cuneco ikke noget behov for at starte

forfra, da vi forudsætter at brugerne

kender deres egne behov.

15 Kåre

Nilsson

Teknisk Er bokstavskodningen i CCS afstemt

med ISO 14617 tabel 7.3.1 der blandt

andet anvendes i pibs C203 del 5 og 7?

Noteret De foreslåede bogstavkoder i CCS og

ditto fra ISO 14617 (og bips C203) er

ikke i konflikt med hinanden.

Bogstavkoderne fra ISO 14617 er

indarbejdet i ISO/IEC 81346-2 tabel 2

som underklasser til hovedklasse B.

16 Kåre

Nilsson

Teknisk I forbindelse med nummerering af IT

netværk med tilhørende udstyr,

anvendes i dag typisk kravene i TIA 606,

se bilag hvor disse krav er anvendt til

nummerering.

Vil der blive taget højde for kravene i

TIA 606 i CCS?

Ikke

accepteret

TIA 606 har ikke været taget i

betragtning, og vil ikke være direkte

foreneligt med den foreslåede CCS

kodning.

I praksis er det dog muligt at dobbelt-

kode et objekt med fx CCS og TIA 606

såfremt det er påkrævet.

Ved hurtig gennemgang af det

fremsendte bilag, ser det ud til at

mange af informationerne fra TIA 606

vil være egenskaber i CCS.

Der savnes en reference på den

fremsendte danske version af TIA 606,

da koder m.v. er justeret i forhold til

den amerikanske udgave af do.

17 Kåre

Nilsson

13 42. krav

Krav 16

Teknisk I bygger CCS på blandt andet ISO/IEC

81346.

Jeg håber I bruger denne standard,

fordi I finder at den er den bedst

egnede og ikke fordi I tror at der et

direktiv eller en bekendtgørelse kræver,

at det skal man.

For modsat det I skriver under Krav 16,

er der ingen direktiver eller

bekendtgørelser der stiller sådanne

krav. Der er en norm(EN60204) der

anbefaler at ISO/IEC 81346 kan

anvendes, hvis man ikke kan finde på

noget andet.

Accepteret Teksten præciseres i rapporten.

18 Kåre

Nilsson

Teknisk Hvordan nummereres en rumføler der

indeholder de 3 målinger: temperatur,

CO2 og fugt.

Noteret Den tilhører klasse BZ i ISO/IEC 81346-2

(kombinerede opgaver).

Eventuelle underklasser til BZ kan

introduceres i CCS såfremt det er

nødvendigt (BZA, BZB, BZC etc.).

Alternativt kan de tre målinger

betragtes som egenskaber for objektet.

19 Kåre

Nilsson

Teknisk I jeres rapport er det ikke helt klart

hvilken begrundelse der for ikke at

vælge at oversætte Uniclass /

OmniClass til dansk, i stedet for at

udvikle et nyt system. Der er muligt at

Uniclass / OmniClass ikke er så

avanceret som CCS, men når det kan

anvendes I UK, USA og Canada så virker

det lidt mærkeligt, at det ikke kan

anvendes I Danmark.

Delvist

accepteret

Begrundelse tydeliggøres i rapporten.

Baggrunden for ikke at basere CCS-

klassifikationen på et af de nævnte

klassifikationssystemer er, at

klassifikationsinddelingen involverer en

uhensigtsmæssig grad af detaljering i

forhold til objekternes egenskaber.

cuneco har fundet det mere relevant, at

lave en mere robust klassifikation og i

større grad basrere sig på specifikation

af egenskabsdata for de enkelte

objekter i forhold til specifikke formål.

20 MBBL

(Karsten

Gullach)

4.2 Generel Det anføres, at kodesyntaksen skal

understøtte mapping mellem den nye

struktur og DBK 2006. I forlængelse

heraf forudsættes det, at

kodesyntaksen ligeledes skal

understøtte mapping mellem den nye

kodestruktur og (No Suggestions), jf.

den forståelse om mapping mellem DBK

2006 og FK, der blev opnået mellem

bips og Landsbyggefonden i regi af den

daværende Erhvervs- og Byggestyrelse i

2009.

Noteret Mapping mellem CCS-klassifikationen

og Forvaltningsklassifikation vil være et

projekt, der helt naturligt vil komme i

forlængelse af udviklingen af CCS-

tabellerne. Hvem der kommer til at

forestå dette arbejde er ikke fastlagt for

indeværende men cuneco vil bidrage i

relevant omfang.

Derudover bevirker den systematik, der

anvendes i disse klassifikationer, at

omfanget af klassifikation bliver meget

stort, da alle mulige kombinationer skal

klassificeres. Dette vurderes ikke at

være brugervenligt, og det ses som

mere hensigtsmæssigt at håndtere

dette via egenskaber/egenskabsdata.

21 Grontmi

j,

Christia

n

Hansen

Teknisk Vedr. IEC 81346-1:

Placeringsaspekt (+), funktionsaspekt

(=) og produktaspekt (-) har været

anvendt i ca. 10 år på mange CTS-

anlæg, og det fungerer fint. Det har

endda kunnet lade sig gøre at overtale

en række bygherrer til at indarbejde

dette i deres eksisterende ældre

referencestruktur, da bygherren kan se

en praktisk fordel.

Noteret

22 Grontmi

j,

Christia

n

Hansen


Denne del 2 er til gengæld håbløs

brugerfjendsk, f.eks. hedder en

frosttermostat, en brandtermostat, en

kanaltemperaturføler, en

rumtemperaturføler, m.v. alle sammen

”BT” efterfulgt af et løbenr.. Det kan

bygherren ikke bruge til noget, når han

f.eks. får en SMS-alarm en nat med ”-

BT03” (er det en frost- eller en

brandalarm ?)

Vedr. IEC 81346-2:

Såfremt udvalgte dele af denne

overhovedet skal bruges, skal

produktbetegnelserne omarbejdes, så

bygherren umiddelbart let og simpelt

kan skelne mellem forskellige produkter

f.eks. kanaltemperaturføler,

indblæsning, kanaltemperaturføler,

udsugning, m.v. (Alternativet er en

massiv boykot fra bygherrerne)


klassifikationsgruppen. Der arbejdes

med en underklassifikation til gruppe

BT (fx BTA, BTB, BTC etc.). Det

bemærkes at enkelte informationer (fx

indsugning / udsugning) måske

overføres som egenskaber til objektet

eller fremgår af den overliggende

systemklassifikation.

23 Grontmi

j,

Christia

n

Hansen

Teknisk Vedr. sammenbyggede komponenter:

En kanalføler der måler både fugt og

temperatur, hvilken

referencebetegnelsen får den? Der er

mange andre eksempler

Der laves oversigter over f.eks.:

1 komponent med flere signaler

Flere komponenter, der deler samme

signal

M.v.

Delvist

accepteret

Den tilhører klasse BZ i ISO/IEC 81346-2

(kombinerede opgaver).

Eventuelle underklasser til BZ kan

introduceres i CCS såfremt det er

nødvendigt (BZA, BZB, BZC etc.).

Udarbejdelse af oversigter håndteres af

klassifikationsgruppen. Kommentaren

overføres til klassifikationsgruppen.

24 Grontmi

j,

Christia

n

Hansen


Er der modstrid med DS/ISO 14617 ?

F.eks.:

DS/ISO 14617: Temperaturmåling =”T”

IEC 81346-2: Temperaturmåling =”BT”

DS/ISO 14617 er allerede indarbejdet i

bips tegningsstandard C203 del 5 og 7 i

2007.

Det er derfor vigtigt, at CCS ikke er

modstrid med DS/ISO 14617

Noteret De foreslåede bogstavkoder i CCS og

ditto fra ISO 14617 (og bips C203) er

ikke i konflikt med hinanden.

Bogstavkoderne fra ISO 14617 er

indarbejdet i ISO/IEC 81346-2 tabel 2

som underklasser til hovedklasse B.

25 Grontmi

j,

Christia

n

Hansen

Teknisk Vedr.anlægstyper:

En bygherre har brug for simpelt at

kunne skelne mellem en lang række

forskellige anlægstyper.

F.eks. varmeanlæg: Her skelnes mellem

varmevekslere, radiatorblandesløjfer,

varmlufttæpper, varmeanlæg

kørerampe, varmeanlæg kalorifere,

m.v.

Jeg er i tvivl om, der er en

standardiseret detaljeret liste over

anlægstyper i CCS’s forslag

Der udføres en standardiseret

detaljeret liste over anlægstyper. (50

eksempler fremsendes gerne)

Accepteret Klassifikationsgruppen arbejder med

emnet, og en evt. oversigt modtages

gerne.

26 Grontmi

j,

Christia

n

Hansen

Teknisk Nummerering af etager er ofte et

problem, da der anvendes mange

forskellige måder f.eks. overkælder,

underkælder, etage -1, etage 0, m.v.

At der udarbejdes et entydigt

standardsystem for nummerering af

samtlige etager

Accepteret Det anføres i rapporten, at CCS følger

ISO 4157 standardserien på dette

område.

27 Grontmi

j,

Christia

n

Hansen

Teknisk Nummerering af rum, kan ofte give

problemer. Hvad sker der, når rum

opdeles, sammenlægges, m.v. ?

At der udarbejdes nogle vejledninger

for god skik for rumnummerering samt,

hvordan ændringer bør udføres

Accepteret Kommentaren overføres til den gruppe

der skal arbejde med vejledninger /

eksempelmateriale.

28 Grontmi

j,

Christia

n

Hansen

Teknisk Vedr.anlægsopdeling:

I DBK er der massive klager over, at et

ventilationsaggregats blandesløjfer ikke

har samme anlægsnr. som selve

ventilationsaggregatet.

Eksempel: Der står 4

ventilationsaggregater på taget og 12

tilhørende varme- og køleblandesløjfer

på etagen nedenunder.

Når brugeren står ved de 12

blandesløjfer, kan han ikke se, hvilke

blandesløjfer, der hører til hvilket

ventilationsaggregat

Via nogle praktiske eksempeltegninger

vises, at blandesløjfer til

ventilationsaggregater har samme

anlægsnr. som selve

ventilationsaggregatet



eksempelmateriale.

29 Grontmi

j,

Christia

n

Hansen

Teknisk Vedr. eltavler:

Det er meget ofte et brugerkrav at et

nr. på en eltavle indeholder oplysninger

om de forsynende tavler og

transformere. Eksempel:

T1

T1-HT2

T1-HT2-ET4

T1-HT2-ET4-GT13

Dette brugerkrav muliggøres og vises

via praktiske eksempler

Delvist

accepteret

El-tavlers indbyrdes sammenhæng er

en del af CCS kodeprincippet, men kan

udtrykkes ved supplerende mærkning.

Det viste eksempel overholder ikke del-

af reglen for inddeling af systemer.

Kommentaren overføres til den gruppe


eksempelmateriale.

30 Grontmi

j,

Christia

n

Hansen

Generel Vedr. kommunikation og forståelse:

Uanset hvilke referencebetegnelser CCS

ender med, er der en meget

omfattende opgave med at forklare

dem.

Der tilføjes rigeligt med praktiske

eksempler og tegninger



eksempelmateriale.

31 Grontmi

j,

Christia

n

Hansen

Generel Der findes mange bygherrer med 100 –

500.000 m2 eksisterende bygninger

med eksisterende

referencebetegnelser. Der mangler

nogle forklaringer på, hvad der skal ske

ved ændringer, udvidelser,

nygbygninger, m.v.

Der tilføjes rigeligt med praktiske

eksempler



eksempelmateriale.

32 Grontmi

j,

Christia

n

Hansen

Generel Der findes en længere række

eksisterende bygherre-/rådgiver-

/entreprenør-lister med anvendte

referencebetegnelser.

Det er oftest lister der er opstået via

praktiske behov. Hvis CCS skal erstatte

disse, skal CCS være temmelig

dækkende

Der indsamles f.eks. 15-20 eksisterende

bygherre-/rådgiver-/entreprenør-lister

med anvendte referencebetegnelser,

og det kontrolleres, at CCS rent faktisk

kan erstatte disse i praksis

Delvist

accepteret

CCS Strukturelt Produktaspekt skal

opbygges og struktureres af personer

med faglig kompetence.

Eksisterende referencebetegnelser

mappes derefter til denne struktur.

33 Ulla

Michael,

DANSKE

ARK

Generel DANSKE ARK ser det som meget positivt

at der lægges op til en adskillelse af

klassifikation og referencestruktur.

Dette vil være en væsentlig forenkling

af rådgivernes arbejde med at håndtere

CCS i den daglige projektering.

Da hele brugbarheden og

funktionaliteten af CCS står og falder

med de grundlag, der indarbejdes i

rådgivernes projektering, er det set fra

DANSKE ARKs side meget væsentligt at

det i den fortsatte udvikling er stort

fokus på at klassifikationen er enkel,

forståeligt og brugbar. Dette mener vi

fortsat skal prioriteres meget højt.

Noteret

34 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Generel Vi kan både i det udsendte skriftlige

materiale og specielt på workshoppen

se at der er lyttet til de kommentarer,

der i tidens løb er givet til DBK og CCS

imødekommer mange af disse.

Noteret

35 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Generel Vi glæder os til at kunne kommentere

på detaljerne i systemet - på de

konkrete tabelværdier. Det er relativt

komplekst for byggefolk at

kommentere alene på strukturen.

Offentliggør tabellerne under vejs og

involver den brede branche i

udarbejdelsen (workshops og lignende).

Noteret cunecos udviklingsmodel består i, at

projekter gennemføres af en række

nøglepersoner, der kan inddrage

eksterne personer til review i relevant

omfang undervejs i

udviklingsprocessen. Udviklingen følges

løbende af cunecos styregruppe, der

repræsenterer de forskellige dele af

branchen og styregruppens

medlemmer har ligeledes mulighed for

at inddrage deres bagland undervejs.

Endelig er alle projekter genstand for

offentlige høringer, når der foreligger et

resultat, der har en kvalitet, som det er

rimeligt at lægge frem.

36 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Generel Processen omkring høring af strukturen

har ikke været optimal - det har ikke

været muligt at gennemføre en grundig

høringsproces med den begrænsede

høringsperiode.

Længere høringsfrister generelt for

fremtidige arbejder.

Noteret Dette er noteret. I forbindelse med

fremtidige projekter, vil vi sikre os, at

høringsperioden er længere.

37 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk Kan "løbenumre" være

informationsbærende - kan en bygherre

definere en bestemt syntaks for

løbenumre, som vil komplicere

anvendelsen unødigt?

Vi ønsker en specifikation af at

løbenumre, underklassifikation etc. ikke

kan være informationsbærende, men

udelukkende er projektspecifikke

løbenumre.

Accepteret Det forstås således, at løbenumre

anvendes som del af identifikation af

objektet.

38 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk Kan "løbenumre" være

informationsbærende - kan en bygherre

definere en bestemt syntaks for

løbenumre, som vil komplicere

anvendelsen unødigt?

Indarbejd forslag til at etablere

mapning mellem projektspecifikke

løbenumre og informationsbærende

systemer hos bygherrer.

Delvist

accepteret

Princippet er accepteret, men det kan

være vanskeligt at dække 100%.



eksempelmateriale.

39 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk Valgfriheden i strukturen omkring

nummerering og lignende stiller store

krav til projektspecifikke aftaler

omkring "understandardiseringer" for

at muliggøre anvendelse af data på

tværs af parter.

Der ønskes vejledninger i hvordan dette

håndteres.

Accepteret Princippet er accepteret, men det kan

være vanskeligt at dække 100%.



eksempelmateriale.

40 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk Der er usikkerhed omkring hvilke dele

af systemet der skal anvendes og hvilke

der kan anvendes. Skal den simple

klassifikation være til stede, eller kan en

part beslutte udelukkende at anvende

et af de andre aspekter?

Det skal klart beskrives hvilke dele af

systemet der er obligatorisk skal være

til stede - vores opfattelse er at den

simple klassifikation skal anvendes i alle

tilfælde.

Delvist

accepteret

Der stilles ikke krav om anvendelse af

den simple klassifikation i alle tilfælde.

Hvad der obligatorisk eller valgfrit

beskrives i rapporten.

41 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk Vi er nervøse omkring grænsen mellem

klassifikation og egenskaber og om den

placeres for højt, så problemer

udskydes til diskussion i forbindelse

med egenskaber.

Grænsen mellem klassifikation og

egenskaber skal overvejes og defineres

nøje og beskrives detaljeret - dette skal

ske snarest muligt og inden arbejdet

med tabeller kommer for langt.

Noteret Kommentaren overføres til grupperne

for klassifikation hhv. egenskabsdata.

Det er et centralt krav, at

klassifikationen er stabil for et objekt

set i den samlede livscyklus.

42 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Generel Der har været arbejdet med it egnethed

i processen, men fokus har i for høj

grad været på professionelle udviklere -

der er i byggebranchen en lang række

af egenudviklede "Excel-systemer" og

lignende som kan have svært ved at

håndtere kodestrukturen (ikke

positionsfast).

Noteret Eksempler på konkrete problemer

savnes.

43 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk It egnetheden er ikke håndteret

konsekvent gennem et teoretisk

fundament, men er håndteret gennem

involvering af udvalgte SW udviklere -

f.eks. ingen it teoretikere og praktikere.

Inddragelse af andre kompetencer. Noteret Sikringen af IT-egnetheden er tilstræbt

sikret ad flere veje. Dels - som det

rigtigt påpeges - gennem involvering af

en repræsentant fra en IT-leverandør i

selve udviklingen og dels igennem en

høring i bips' IT-forum undervejs i

udviklingsforløbet. Derudover er selve

den offentlige høring, som

høringsworkshoppen er en del af, men

som også omfatter en løbende dialog

med de IT-leverandører, der vil deltage

i cunecos afprøvningsprojekter, også et

væsentlig element i sikringen af IT-

egnetheden.

44 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Generel Hvilke tiltag er der gjort for at

gennemføre høringen mod et

internationalt høringspanel?

Høringsdokument oversættes til

engelsk og en international høring

gennemføres.

Noteret Undervejs i udviklingsforløbet har der

været ført en dialog med flere

internationale kompetencer som fx

Håvard Bell (Norge), Eirik Selvik (Norge)

og Anders Ekholm (Sverige).

Derudover holder bips - inkl.

repræsentanter fra CCS

kodestrukturgruppen - løbende møder

med klassifikationsrepræsentanter fra

de øvrige nordiske lande. bips og

cuneco deltager i arbejdet omkring

revision af klassifikationsstandarden

ISO 12006-2 og koordinerer i den

forbindelse løbende udviklingen med

en række internationale aktører.

cuneco har indgået aftale med Anders

Ekholm (Lunds Universitetet) om et

tværgående review af cunecos

projekter, med henblik på at sikre

indbyrdes koordinering og

sammenhæng til international

udvikling.

45 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Generel Vi mangler en konsekvent beskrivelse af

hvordan systemet forholder sig til de

mest udbredte nationale

klassifikationsstandarder - herunder

overvejelser omkring en mere direkte

kobling mellem CCS og disse. Dette er

specielt relevant i forbindelse med det

fremadrettede arbejde med de

konkrete tabeller, hvor kompetencer

med direkte relation til de nationale

standarder bør involveres.

Involver ressourcer fra OmniClass og

Uniclass direkte i arbejdet med

udarbejdelse af tabeller.

Noteret Det væsentligste bidrag til at sikre

koblingen til de øvrige nationale

klassifikationssystemer vil bestå i, at

klassifikationsstandarden ISO 12006-2

opdateres, således at denne vil afspejle

principperne i CCS uden at dette dog vil

påvirke opbygningen og indholdet af de

øvrige nationale systemer.

46 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk Der mangler en gennemgang af

hvordan CCS forholder sig til det hidtil

anvendte klassifikationssystem i

Danmark - SfB systemet.

Praktisk mapning udarbejdes på linje

med mapningen til DBK



eksempelmateriale.

47 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk Et objekt kan have to forskellige numre

i to forskellige aspekter - døren er

nummer 3, men dør nummer 7 i

vægsystem 1. Dette giver forvirring i

praksis og giver risiko for misforståelser

i praksis.

Problemstillingen skal beskrives og

operationaliseres.

Delvist

accepteret

Det er et unødigt stærlt krav at kræve

at nummereringen samordnes på tværs

af aspekterne. Aspekterne mulliggør

håndtering af objekterne fra forskellige

synsvinkler, hvorfor objekterne ikke vil

have de samme kompositoriske

relationer. Dette detaljeres yderligere i

rapporten.

48 Digital

Konverg

ens v/

Jørgen

Storm

Emborg

Teknisk Det er et problem for branchen at der

er to helt separate

klassifikationssystemer til hhv.

byggeperioden og driftperioden

(Forvaltnings Klassifikation)

De to systemer bør behandles til et

samlet system.

Noteret cuneco vil bidrage til, at der udarbejdes

et system til mapning mellem CCS og

FK, således at man vil overgangen til

drift vil have mulighed for at få

genereret FK-koder for objekterne ud

fra den CCS-klassifikation og

egenskabsdata, der er påført

objekterne i projekterings- og

udførelsesperioden.

49 DTU,

Risø,

Allan

Murphy

Generel Dette er en fælles kommentar fra DTU,

Lyngby og DTU Risø (Campus service =

driftsafdelinger):

Det er et for abstrakt grundlag for DTU

til at kunne vurdere konsekvenserne

Fornyet høring med langt mere vægt på

eksempler og praktiske konsekvenser

Noteret Ønsket om at høringsmaterialet i højere

grad skal bestå af praktiske eksempler

er noteret, og vil blive taget i

betragtning i forhold til kommende

projekter. M.h.t. ønsket om en ny

høring vil vi afvise dette med den

begrundelse af høringen har genereret

så mange konstruktive og relevante

kommentarer, at vi vil mene at den har

opfyldt sit formål.

50 Henrik

Schleder

mann

Teknisk Når man laver et så omfattende

klassifikations og identifikationssystem

så synes jeg det er problematisk at man

ikke forholder sig til en ensartet måde

at identificerer komponent placering i

forhold til bygningsgeometrien.

Rumnumre er ikke entydige.

Rum opsplittes, nedlægges og nye rum

etableres.

Rumnumre ændres løbende af brugere.

For de tekniske installationer er der i

relation til drift og

overvågningssystemer et stort behov

for kunne angive entydig placering af

komponenter som ikke ændres i løbet

af bygningens levetid.

Det er også et meget vigtigt aspekt i

hele driftforløbet.

Hvis rumnumre ændres hvad de ofte

gør af brugere eller arkitekter er det

meget kostbart at oprette den bagved

liggende dokumentation.

At der udarbejdes et entydigt system

for hvordan placering af komponent /

anlæg identificeres og som skal

anvendes på alle nye bygninger.

Dette kunne være via:

- GPS koordinater.

- Ved anvendes af et

hensigtsmæssigt og standardiseret

bygningsgrid hvor der er regler for

hvordan dette anvendes og hvordan

akser nummereres.

- Ved at lave en standardiseret

måde at tildele rumnumre afhængigt af

et bygningsgrid.

Delvist

accepteret

De foreslåede CCS aspekter for rum

(funktionsaspektet og strukturelt

produktaspekt) anvendes til

identifikation af rum, og er (samlet set)

stabile set over livscyklus for et rum,

men omfatter ikke fx når to rum

sammenlægges, og det ene dermed

nedlægges/udgår.

De foreslåede ændringer (fx GPS-

koordinater) kan tilføjes som

egenskaber for de pågældende rum.

De ønskede (”historiske”)

informationer, fx om ”tidligere

rumnummer” kan evt. bevares som en

del af egenskabsdata knyttet til et

objekt og ses som en særskilt aktivitet

der omhandler vedligehold af

informationer.

Der indarbejdes en beskrivelse i

rapporten, der viser hvorledes CCS

koderne kan anvendes til dette formål,

fx at et tidligere rum efter en

renovering skal findes som en del af et

nyt rum.

Kommentaren overføres til

egenskabsdatagruppen

51 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Generel Det er en rigtig god ide, at optage hele

præsentationen, og efterfølgende give

muligeh for, at se de fire film.

Rigtig stor ros!

Noteret

52 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Generel Der er tilgengæld ikke ros for

høringsfristen. Det er et svært emne,

som bliver beskrevet meget abstakt og

komplekst. Det kræver tid, at sætte sig

ind i stoffet.

Fremlæggelserne den 15. marts var til

gengæld mere ”spiselige”.

Noteret Vi har noteret os, at høringsfristen har

været for kort, hvilket vi vil tage i

betragtning i forbindelse med

fremtidige projekter. M.h.t. det

tekniske indhold af rapporten mener vi

ikke at det kan undgås, at man kommer

op på et vist teknisk niveau i

beskrivelsen af systemet. Til gengæld

har vi prioriteret at følge dette til dørs

af en præsentation, der er mere

pædagogisk og umiddelbart forståelig.

53 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

1.

Resume

side 3

Generel I princippet giver det ikke mening, at

man kun skal kommentere

kodestruktur, uden at kende omfanget

og indhold af tabeller, klasser,

domæner, fag, ressourcer mv. Det er

nærmest en form for en accept på et

ufuldstændigt grundlag, som senere

kan give bagslag, når man er kommet i

dybden med indholdet af tabellerne.

Fordi man kan frygte, at der på

nuværende tidspunkt er taget

beslutninger, som det ikke er muligt, at

gennemskue.

Desværre har det mest karakter af, at

rapporten skulle ud nu.

Det vil kræve flere høringer, dette kan

ikke være den endelige høring.

Arbejdet bør koordineres med de

øvrige projekter som har indflydelse i

en eller anden udstrækning. Her vises

eksempler fra cunecos egen

projektliste:

· Afklaring af klassifikationsniveau

· Afklaring af struktur og metode

for egenskabsdata

· Klassifikation af bebyggelser,

bygninger og rum

· Begrebsmodel for

ressourcedomæne

· Metode-struktur for

egenskabsdata

· Egenskabsdata for ressourcer,

processer, produktions-planlægning,

driftsregistrering, beregninger,

rumprogrammer, opsamling af

driftsdata,

· Krav til informationer for drift

· Tabeller for bygningsdele, tabeller

for drift

· Sammenhæng mellem

egenskabsdata og IFD

· Sammenhæng mellem

bygningsmodel og bygningsbeskrivelse

Noteret Alle de nævnte projekter koordineres

løbende med hinanden ligesom de hver

især vil være genstand for selvstændige

høringer. Der vil således blive tale om

mange høringer undervejs i cunecos

projektperiode.

54 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Generel Det virker stadig unødigt komplekst. Udover forenkling bør der arbejdes

med formidlingen af stoffet, med mere

sigende og oplysende eksempler.

Delvist

accepteret



eksempelmateriale.

55 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Generel Ved vurderingen af DBK tilbage i

oktober 2010, blev der fra mange sider

efterlyst en værdianalyse.

Den har branchen stadig tilgode.

Dicon-rapporten fra 2008 peger flere

steder på belysning af værdien.

De afholdte behovsanalyser kan ikke

gøre det ud for en gennemarbejdet og

afsluttet værdianalyse – fordi de netop

ikke har beskæftiget sig ed

klassifiaktion, som oplyst af Torben

Klitgaard på høringen om

brugerseminarere.

Noteret Det er cunecos holdning, at man ikke

kan tale om værdien af klassifikation i

sig selv. da klassifikation først giver

værdi, når det bliver anvendt i

forbindelse med konkrete processer.

Fokus for indeværende projekt har

været at definere en kodestruktur, der

gør det muligt at referere til et specifikt

objekt samt at sige noget om, hvilken

klasse objektet tilhører. Når dette

formål er opfyldt mener vi, at det er

muligt at anvende objektet i forhold til

de processer, der skaber værdien.

Analyserne af værdiskabelsen i disse

processer foretages i forbindelse med

afprøvningsprojekterne med opstart i

efteråret 2012.

56 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Indlæg

2, slide 6

Generel Der blev i præsentationen nævnt, at

man skulle have kigget på Holland i

stedet for de andre lande, hvor man

tidligere har kigget i deres systemer.

Der er muligt; men vi mangler

dokumentationen herfor.

Derfor ved vi ikke, om det ville være

bedre at fordanske et af de andre

systemer.

Ikke

accepteret

Kommentaren på fremlæggelsen havde

til formål at tydeliggøre, at der er andre

lande der arbejder efter de samme

principper som CCS nu lægger op til.

Det er ikke en del af

opgavebeskrivelsen, at et dansk

klassifikationssystem skal være en

fordanskning af andre landes systemer.

57 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Generel Inden lancering af den nye CCS. Det skal sikres, at man ikke får de

samme vanskeligheder med CCS, som

man har haft med DBK. Derfor bør test

og afprøvning foregå på et mere

kvalificeret grundlag end det skete med

DBK.

Noteret Dette er helt i overensstemmelse med

cunecos holdninger og arbejdsmetoder.

cuneco har allerede på nuværende

tidspunkt indgået aftaler med en lang

række IT-leverandører, der vil

implementere CCS og der arbejdes i

øjeblikket på at de tabeller, der bliver

udviklet, vil blive stillet til rådighed for

IT-leverandørerne via webservices.

58 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Generel Generelt om syntaksen Det vil være en fordel, at betragte de

forskellige oplysninger som

enkeltstående oplysninger i hvert sit

felt. Det forhindrer ikke en samlet

visning af hele strengen.

Det er ganske almindelig

databaseteknik.

Det vil ydermere give store fordele ved

sortering og anvendelse i andre

programmer f. eks. Excel. Dermed vil

aspekt præfix ikke ødelægge

sorteringen.

Delvist

accepteret

Det præciceres i rapporten, at de

enkelte aspekter er seperate

egenskaber for et objekt, der evt. kan

samles til én kodestreng (adskilt med

”/”) såfremt det er påkrævet. De

enkelte aspekters præfiks muliggør

dette, da koden for hvert aspekt er helt

entydig, og ikke kan forveksles med

andre koder for andre aspekter pga.

deres forskellige præfiks.

Kommentaren overføres til gruppen der

arbejder med egenskabsdata, således

at koden for de enkelte aspekter evt.

kan udveksles som flere enkelte

egenskaber.

59 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Generel Når kompleksiteten og omfanget af

kommentarer tages i betragtning, bør

der i værksættes en ny høring, når alle

problemstillinger er indarbejdet.

Noteret Opfølgeren til kodestrukturprojektet er

et projekt vedr. afklaring af

klassifikationsniveau. Formålet med

dette projekt er at udarbejde

retningslinjer for klassifikation af

bygningsdele samt grænsefladen til

egenskabsdata. Indholdet af dette

projekt vil inddrage de ting, der er

kommet frem i den indeværende

høringsproces og projektet vil være

genstand for en særskilt høring.

60 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

1.

Resume

side 3

Afsnit 4 Generel Der er taget udgangspunkt i ISO 12006-

2 og ISO/IEC 81346 standarderne. Men

hele systematikken der er beskrevet

hælder sig hovedsagligt op af

sidstnævnte, som er en elektrisk og

mekanisk standard, hvilket giver en

uheldig udformning af det vi har brug

for i byggeriet.

Det er helt uforståeligt, at man ikke har

vist den samme interesse for ISO

12006-2 og IFC, som man har for IEC

81346. Disse standarder har dog en

langt større udbredelse bredt blandt

byggefolk end 81346, som kun benyttes

af en mindre del af el- og

mekanikfolket.

Det foreslås, at der udarbejdes

eksempler og scenarier der analyserer

og demonstrerer hvordan de

identificerede brugerbehov kunne løses

gennem anvendelse af elementer fra

12006-2 og IFC – evt. i kombination

med 81346.

Ikke

accepteret

ISO 12006-2 er en rammestandard, der

i sin udformning danner en fælles

platform for definition af byggeriet. ISO

12006-2 er ikke i modstrid med ISO/IEC

81346 (og omvendt). ISO 12006-2 er

derfor helt central for CCS.

IFC er et udvekslingsformat og ikke et

kodesystem. IFC kan indeholde CCS

koderne, hvorved CCS koder kan

overføres mellem forskellige IT

systemer.

Det er valgt at anvende principperne fra

ISO/IEC 81346, da denne standard

stiller nogle værktøjer til rådighed, der

er nyttige i forbindelse med cunecos

ønsker om at kunne identificere

objekter entidgt ud fra forskellige

aspekter.

Der savnes eksempler på, hvad der

menes med ”uheldig udforming af det

vi har brug for i byggeriet”.

61 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

3. intro-

duktion

side 7

Afsnit 2

og 3

Generel Her er beskrevet at det er en revideret

version af DBK.

Skemaet på side 70 med aspektkoder

viser tydeligt, at bygningsdelene er

klassificeret anderledes i det nye CCS.

Visningen af de 4 øvrige aspekter og

forslag til indhold, viser desværre

tydeligt, at tankesættet bagved er det

samme som DBK, og dermed kan man

have en begrundet frygt for den megen

fokus på referencesystemet, som

umiddelbart ser ud til unødigt at

komplicere koderne og vanskeliggøre

anvendelsen for mange af byggeriets

brugere.

Her henvises til ovenstående punkt om

beslægtede projekter i Cuneco.

Ikke

accepteret

Med CCS er det nu muligt kun at

klassificere bygningsdele og rum (med

% hhv. %%)., og derfor er der tale om

en anderledes tilgang end DBK, hvord

dette ikke var muligt.

Referencesystemet fra DBK er

revideret, og indgår fortsat i CCS, da

dette tankesæt er centralt i bestemte

sammenhænge. Der er i CCS ikke krav

om anvendelse af refrencesystemer. Vi

vil undersøge fordele og ulemper ved at

gøre fx den simple klassifikation

obligatorisk for at skabe et fælls

grundlag for den simple anvendelse,

som efterlyses.

Se endvidere svar på

høringskommentar 60.

62 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

3. intro-

duktion

side 7

Afsnit 6 Generel Rapporten præsenterer forslag til

klassifikationstemaer, men indeholder

ikke det specifikke tabelarbejde,

herunder de klassifikationstabeller der

skal udarbejdes, på baggrund af denne

rapport.

Dette er særdeles uhensigtsmæssigt,

når man tænker på, at

opmålingsreglerne fra 2008, stort set

ikke er blevet anvendt, pga. af den

kobling man lavede til DBK, som

begrænsede muligheden for

entydighed, som et af mange

væsetligste ankepunkter.

Her henvises til ovenstående punkt om

beslægtede projekter i Cuneco.

Noteret De uhensigtsmæssigheder, der er

blevet afdækket i forhold til DBK2006,

har cuneco valgt at håndtere gennem

opstilling af succeskriterier for sine

udviklingsprojekter. Den beskrevne

vanskelige kobling til DBK i forhold til

Opmålingsreglerne bundede ifølge

cunecos opfattelse i at man ikke kunne

klassificere uafhængigt af

referencestrukturen eller referere til

projektspecifikke typer. Begge disse

forhold har været med i

kodestrukturprojektets succeskriterier

og cuneco anser at projektet har

opfyldt disse kriterier med den nye

kodestruktur som CCS repræsenterer.

63 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

3. intro-

duktion

side 8

Afsnit 2 Generel I grundlag for rapporten omtales

Ekholm-rapporten

Det er svært at se hvor præcis denne

rapport har inspireret i

revideringsarbejdet.

Lad Anders Ekholm og Lars Häggström

gennemgå rapporten sammen med

resultaterne af denne høring.

Noteret cuneco har bedt Anders Ekholm lave

review på høringsmaterialet, og han vil

således selv kunne give udtryk for om

hans kommentarer til DBK er tilgodeset

i CCS kodestrukturen.

64 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

3. intro-

duktion

side 8

Afsnit 3 Redaktio

nel

I rapporten:

”Behovsanalyse – hvad er

byggebranchens behov for standarder

for udveksling af digital information?

(Foreløbige hovedkonklusioner)”

Kommenteres under 16 Bilag D side 72

Accepteret Der indsættes en reference fra afsnit 3

til bilag D i rapporten.

65 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

3. intro-

duktion

side 8

Afsnit

3.2.2

Redaktio

nel

Rapporten:

Indsamling af basisinput til

projektarbejdet med deltagelse af

udvalgte eksperter med afsæt i de

vedtagne forudsætninger for opgaven.

Det vil klæde rapporten, at oplyse om

disse.

Delvist

accepteret

Der indsættes en reference til

forudsætningen for projektarbejdet

(indsættes som bilag).

66 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Afsnit 4.

– 10.

Side 10 -

62

Generel Det vil ikke give mening, at

kommentere på et detaljeret niveau,

som f.eks.:

· Er 3-400 bygningsdele dækkende?

· Om alle bygningsdele kan

beskrives med 2 eller 3 bogstaver?

· Om der er underklasser mv.?

· Hvordan skal de relevante

egenskaber klassificeres?

· Hvordan behandles øvrige

egenskaber, som er relevante f. eks. for

opmåling og produktion mv., hvilken

form for struktur?

Vi mener grundlæggende, som

beskrevet ovenfor, at der skal tages

hensyn til de øvrige cuneco-projekter,

som har indflydelse struktur,

terminologi, opbygning mv.

Når dette ikke er belyst, er det

foreslåede blevet unødigt komplekst,

fordi alle nuancer ikke er tænkt ind.

Så fremt alt skulle være løst, ville det

det formentlig tage 3 – 5 år, at lave den

samlede klassifiaktion; men det vi har

set i dette oplæg, er til gengæld for lille

del af isbjerget. Der er alt for mange

afhængigheder som vil afstedkomme

revisioner, og på den måde kræve nye

høringer.

Udover denne kommentar, efterlyses

flere gennemarbejde praktiske

eksempler, det vil give en bedre

mulighed for, at gennemskue

kompleksitete, og se konsekvenserne i

sin helhed.

Kompleksiteten er i forvejen unødig

høj.

Noteret Det er cunecos holdning, at man med

det foreliggende resultat har lagt sigt

fast på nogle principper, som der ikke

skal laves om på i forbindelse med de

forhold, der er nævnt i kommentaren.

Det er korrekt, at der er tale om en

række faktorer, der ikke for

indeværende er afdækket, hvilket vil

ske i forbindelse med cunecos

kommende projekter. cuneco mener at

man med det foreliggende resultat fra

kodestruktur projektet, vil kunne

håndtere den relevante datamængde

uden at koderne bliver unødigt lange og

komplicerede.

67 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Afsnit

4.2

Afsnit 1

pkt. 6

Generel ”Kodesyntaksen skal understøtte

mapning mellem den nye struktur og

DBK2006”, blev der nævnt under

debatten på mødet den 15. marts, at

man ville kunne dette ”en til en”.

Det er nok love for meget, det er tale

om en enklere struktur i det nye CCS.

Hvis det endeligt er tilfældet, kan man

konkludere, at adskillelsen og

nytænkningen ikke har været

omfattende nok i revisonen af DBK.

I øvrigt bør man prioritere denne

indsats med mapning, og koncentrere

sig om det fremadrettede, under

respekt af de få som har anvendt

DBK2006 med udbytte.

Herudover er mapning til SfB og

Forvaltningsklassifikationen formentlig

mere påkrævet.

Det er stadig uhensigstmæssigt med

både CCS og

forvaltningsklassifikationen. De burde

smelte sammen.

Noteret Det er korrekt at man ikke vil kunne

lave 100% en-til-en mapning mellem

DBK2006 og CCS. Dette skyldes dels at

CCS ikke klassificerer varianter af typer

og dels at CCS eliminerer muligheden

for at klassificere objekter med

forskellige klasser, som det er tilfældet

med DBK2006.

cuneco er enige i, at det er

uhensigtsmæssigt for branchen med to

klassifikationssystemer, hvilket

adresseres ad 2 veje. Den ene er, at CCS

vil definere de klassifikationskoder og

egenskabsdata, der er nødvendige for

at matche funktionaliteten i FK, og den

anden er at cuneco vil bidrage til at

udvikle en mapning mellem CCS og FK.

68 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Afsnit

12 side

66

1. Afsnit Generel I rapporten står:

CCS er designet til at være et fælles

kodesystem, som er fælles for alle

domæner: Der kan derfor udarbejdes

en fælles formidling og

eksempelsamling. Endvidere er der lagt

vægt på at de forskellige domæner vil

kunne arbejde bedre sammen og

reducere antallet af fejl og

misforståelser mellem parterne, idet

koderne er ensartet og entydigt

opbygget for alle domæner.

Her mangler praktisk eksempler som

belyser dette, da de nævnte domæner

ikke er omtalt i rapporten

Delvist

accepteret

Det præciseres i rapporten hvad der

forstås ved "domæner" (der tænkes på

faglige domæner).

69 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Side 66 Generel På samme side nævnes at

softwareleverandørerne har været

konsulteret og CCS kan understøttes af

IT-værktøjerne.

Det vil klæde rapporten at omtale

hvilke leverndører og værktøjer der er

tale om.

Accepteret Omtale af leverandørene og

værktøjerne vil indgå i rapporten.

70 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Afsnit

15

Side 70-

71

Bilag C Generel Fin visualisering. Noteret

71 Flemmi

ng

Grangaa

rd,

Dansk

Byggeri

Afsnit

16

Side 72

Bilag D Generel Der er flere citater fra behovsanalysen,

som lige så godt kunne have været

valgt som repræsentative om behov for

bruger-venlighed og enkelhed osv.

F. eks.:

· Der er ikke sammenhæng mellem

klassificeringen/bygningsmodellen og

bygningsdelsbeskrivelserne.

· Anvendelsesbehovet for

klassifikation skal afklares gennem

konkrete eksempler for forskellige

fagområder.

· Det svenske klassifikationssystem,

hvor der er kobling til

beskrivelsesværktøjet fungerer godt.

· Hvorfor ikke benytte os af de

navne, som vi giver dem alligevel?

· DBK er ikke velegnet i

udførelsesfasen.

· cuneco skal starte med kernen,

dvs. beskrive et system, som branchen

over tid kan forbedre.

· Klassifikation og niveauer – de

forskellige aktører har forskellige

detaljeringsbehov.

· DBK-kodningen er tung og hænger

ikke sammen med mængdeudbud.

Deltagerne på disse workskops og

bølger har ikke prioriteret DBk højest.

Det skal man ikke lade sig mærke af,

der er ikke tvivl om at

bygningsdelsklassifikationen er vigtig

for flere ting end man umiddelbart er

klar over eksempelvis opmåling og

produktion.

Noteret

72 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Afsnit

17

Side 80

Bilag E Generel I henhold til ovenstående generel

bemærkning om tabeller mv. Er det

vigtigt at understrege, at der skal

arbejdes meget mere med klasser og

underklasser, og hvordan de skal

navngives.

Noteret

73 Flemmin

g

Grangaa

rd,

Dansk

Byggeri

Generel IT- egnethed:

Der var oprindeligt planlagt en seance

om IT-egnethed af DBK2006, den blev

pludselig aflyst i efteråret 2010.

Vi må anbefale at man tager dette op

igen, og får belyst IT-egnetheden i en

bredere sammenhæng med erfarne

brugere i forhold til alle typer relevant

software, som anvendes i

virksomhederne.

Noteret Det er cunecos holdning at den bedste

metode til at verificere IT-egnetheden

er ved at afprøve det i praksis. Dette

har cuneco mulighed for fx i forbindelse

med afprøvningsprojektet DNV-

Gødstrup, hvor der er indgået aftaler

med IT-leverandører og brugere om

implementering og afprøvning af CCS.

74 Bygning

sstyrelse

n

Generel Bygningsstyrelsen er interesseret i en

udrulningsplan og leveringstidspunkter

for:

- bygningsdel- og rumtabeller.

- mappingtabel/vejledning for

konvertering af DBK til CCS.

- mappingtabel/vejledning for

konvertering af SfB til CCS.

Noteret cuneco vil i løbet af juni måned 2012

komme med udmeldinger omkring

konkrete planer for udrulning af

klassifikations- og mapningstabeller.

75 Bygning

sstyrelse

n

Generel Hvordan tænkes CCS at håndtere mere

abstrakte aspekter som fag/rolle og

arbejde (jf. bips 1000)? Dette spørgsmål

af hensyn til fx økonomisk opfølgning

og omkostningsanalyser.

Noteret CCS anvendes til kodning i

resultatdomænet. De nævnte aspekter

vil blive håndteret i form af

egenskabsdata, der jævnfør ISO 12006-

2, vil omfatte både ressourcer,

processer og resultater.

76 Bygning

sstyrelse

n

Generel Rapporten bør give brugerne relevante

kriterier for en beslutning om

anvendelse af CCS kontra anvendelse af

egenskabsdata.

Noteret Kommentaren overføres til de grupper


eksempelmateriale samt

egenskabsdata.

77 Bygning

sstyrelse

n

Generel Bygningsstyrelsen efterlyser, at

fordelene ved anvendelse af CCS

belyses yderligere ift. små

byggeprojekter, inden aflevering til

drift.

Dette tiltag skal være med til at ’sælge’

brugen af systemet yderligere overfor

brugerne.

Noteret Denne opfordring er også modtaget

gennem behovsanalysen og ønsket vil

blive efterkommet gennem de

scenarier cuneco anvender i sit arbejde.

Scenarierne vil delvist udgøre

beskrivelsen af den værdiskabelse, der

skal verificeres i forbindelse med

afprøvningsprojekterne.

78 Kjeld

Svidt og

Maria

Thygese

n,

Bygning

sinform

atik,

Aalborg

Universi

tet

3 Generel Det konstateres, at rapporten

omhandler kodningsprincipper til

anvendes ved klassifikation og

identifikation af bygningsdele og rum.

Det blev ved høringsworkshoppen

pointeret, at det ikke handler om

klassifikation, men om kodestuktur.

Kommer der en tilsvarende rapport og

proces for hhv. klassifikations- og

identifikationsprincipperne?

Umiddelbart skulle man tro, at

kodestrukturen skulle afhænge af et

forventet antal varianter, identificeret i

klassifikations- og referencestrukturen .

Noteret Det er cunecos opfattelse, at den

foreslåede kodestruktur er fleksibel og

uafhængig nok til at man kan håndtere

det antal varianter, der vil blive

afdækket i de kommende

klassifikationsprojekter. Denne

antagelse er gjort med udgangspunkt i

det meget omfattende arbejde med

hensyn til afdækning af antallet af

bygningsdele, der blev gjort i DBK 2006.

79 Kjeld

Svidt og

Maria

Thygese

n,

Bygning

sinform

atik,

Aalborg

Universi

tet

S. 3 i

rapport

+ slide 4

i

tk_intro

Generel CCS skal afløse DBK. Førend CCS udskiftes med DBK i

lovgivningen, skal det sikres, at CCS er

afprøvet og testet på flere scenarier.

Systemet skal kunne skabe

produktivitet, og de

anvendelsesvanskeligheder DBK

medførte, må ikke gentages.

Noteret Dette er en hel central forudsætning i

cunecos arbejde.

80 Kjeld

Svidt og

Maria

Thygese

n,

Bygning

sinform

atik,

Aalborg

Universi

tet

Slide 17

i

tk_intro

Generel Mappingtabeller der migrerer fra SfB til

CCS

Ved migrering af SfB til CCS, hvordan er

dette tiltænkt i forhold til f.eks.

driftsherrens driftssystemer. Det bør

testes, om de anvendte systemer også

kan behandle CCS.

Noteret Det er cunecos opfattelse, at

mappingen fra SfB til CCS er blevet gjort

væsentligt enklere end fra SfB til

DBK2006, da klassifikationen nu er

uafhængig af referencestrukturen.

cuneco planlægger at gøre denne

mapping til genstand for en selvstændig

afprøvning.

81 Kjeld

Svidt og

Maria

Thygese

n,

Bygning

sinform

atik,

Aalborg

Universi

tet

S. 7 +

slide 10 i

tk_intro.

Generel I rapporten på side 7, beskrives CCS

som en revidering af DBK, mens slide 10

indikerer, at tavlen er visket ren.

Gør det klart hvorvidt tavlen er visket

ren eller om det er en mindre revision

af et tidligere system.

Accepteret Teksten præciceres i rapporten.

82 Kjeld

Svidt og

Maria

Thygese

n,

Bygning

sinform

atik,

Aalborg

Universi

tet

s. 12 4.2. Krav Generel ”Som udgangspunkt for projektet er der

jævnfør opgavedefinitionen pkt. 3.3

stillet følgende minimumskrav som

succeskriterie for projektet”

Grundlaget for de 31 krav er uklart.

Der refereres til pkt. 3.3, som ikke

findes i rapporten.

Accepteret Grundlaget beskrives bedre og

referencer opdateres.

83 Kjeld

Svidt og

Maria

Thygese

n,

Bygning

sinform

atik,

Aalborg

Universi

tet

63 Generel IFC beskrives som et udvekslingsformat

mellem forskellige IT systemer.

IFC er en omfattende datamodel, som

har været under udvikling i mere end

15 år, og som også indeholder aspekter

af klassifikationer og

referencesystemer. Hvorvidt forsøger

man med CCS at løse samme

problemer, som IFC skal løse?

Accepteret IFC er et udvekslingsformat og ikke et

kodesystem. IFC kan indeholde CCS

koderne, hvorved CCS koder kan

overføres mellem forskellige IT

systemer.

Emnet præciceres yderligere i

rapporten.

84 Kjeld

Svidt og

Maria

Thygese

n,

Bygning

sinform

atik,

Aalborg

Universi

tet

14 Generel ”Den nye CCS-kode er derfor udformet

således at CCS-koden kan anvendes

analogt uden understøttelse af IT-

systemer. I praksis vil IT understøttelse

dog være en væsentlig effektivisering i

anvendelsen af CCS.”

I hvilke situationer er CCS anvendelig

uden brug af IT? Hvilke processer skal

CCS understøtte – hvem, hvad og

hvornår?

Der bør udarbejdes

anvendelsesscenarier og

brugergrænseflader, som illustrerer

brugeren i den enkelte

anvendelsessituation.



eksempelmateriale.

85 White

arkitekt

er A/S

Høringsr

apport

Side 17

Figur 2

med

tilhøren

de

definitio

n ISO

12006-

2:2001

Teknisk Rapport definition:

”Brugsrum: Et rumligt

sammenhængende og afgrænset

område i en bygning, der har et

primært menneskeligt

anvendelsesformål. ”

Figur er vist med vægge rundt rummet.

ISO 12006-2:2001 Afsnit 2.10 Note 1 ”A

space may be bounded physically or

notionally” se derudover Annex A punkt

A.4 i ISO 12006-2 for 4 deling af Space

begreb.

Der findes ligeledes rum uden for

bygninger gårdrum, torve,

parkeringspladser mv.

Forslag til ny definition:

”Brugsrum: Et rumligt

sammenhængende og afgrænset fysisk

eller teoretisk område i en bygning eller

bebyggelse”

Delvist

accepteret

Definitionen opdateres i samråd med

de øvrige arbejdsgrupper.

86 White

arkitekt

er A/S

Høringsr

apport

side 24,

25 & 26,

samt

Bilag C

Regel 12

Bilag C

Redaktio

nel

Rapport s. 24 ”Strukturelt

produktaspekt: Koder i dette aspekt

identificerer objektforekomster i en

strukturel dekomponering (systemer og

deres bestanddele) af byggeriet. Denne

dekomponering kan enten være

foruddefineret i CCS eller være bestemt

af projektet.”

Tabel 2 – ”Foruddefinerede CCS

aspektkoder inden for hvert aspekt”

Rapport s 25 ”(-) Identifikation af

bygningsdele, baseret på en CCS

defineret dekomponering af bygnings-

struktur i systemer og deres

bestanddele.”

Regel 12: Projektspecifikke aspektkoder

anvender 3 ens præfikstegn (f.eks. ”---

”). Definition af sådanne

projektspecifikke aspekt-koder skal

beskrives i projektets dokumentation

inkl. den anvendte klassifikation.

Spørgsmål:

Hvad eller hvordan adskilles et

projektspecifik Bygningsdels ID fra et

projektspecifik Brugsrum ID hvis begge

har 3 ens præfikstegn.

Forslag til ny regel 12:

Regel 12: Ved projektspecifikke

aspektkoder indsættes 2 ekstra

præfikstegn af samme karakter som

aspekt foran aspektkode. f.eks. "---"

angiver projektspecifik Strukturelt

Bygnings ID, "----" angiver

projektspecifik Strukturelt Brugsrums

ID.

Bilag C. bør udbygges med kodesyntaks

for projektspecifikke systemer og

hierarkier.

Delvist

accepteret

Regel 12 bearbejdes.

Bilag C udvides tilsvarende.

87 White

arkitekt

er A/S

Forudgå

ende

komme

ntar

Regel 12 Teknisk Såfremt et projekt ønsker flere

forskellige projektspecifikke Strukturelt

aspekt for Bygnings ID – f.eks en for

beskrivelser, en for anlægsbudget, en

for finansiering og en for drift &

vedligehold, hvilke muligheder er der

for dette i kodesyntaksen ?

Delvist

accepteret

Formålet med CCS koderne er at

klassificere og identificere bygningsdele

og rum.

Rapporten opdateres, så det præciceres

hvad aspekterne gør, og hvordan man

kan lave projecktspecifikke aspekter, og

hvilke regler disse skal følge.

88 Markus

Lampe,

DTU CAS

Bilag C Begge

sider

Teknisk Hvorfor skal der defineres præcise disse

4 delaspekter og hvordan sikres det, at

det er de aspekter som er de

nødvendige for byggebranchen? Det vil

først vise sig med anvendelsen af CCS.

Bred anvendelse og stor fleksibilitet af

CCS skal sikres, så at systemet kan

bruges også med de ukendte krav, som

kommer i fremtiden.

Derfor burde der være en mulighed for

at sener hende tilføje aspekter eller

slette nogen, når de ikke bliver brugt.

Alternativ: Kun klassifikationsaspekt &

egenskaber (herunder de resterende

aspekter).

Delvist

accepteret

Der er ikke krav om at anvende alle

aspekter. Dette er styret af behov.

De foreslåede aspekter er hentet fra

defineret anvendelse (=,+.- og #) i

ISO/IEC 81346 og

klassifikationsaspektet (%) er tilføjet så

klassifikationen kan anvendes seperat.

Aspekterne er ikke begrænset til dette,

og kan evt. udvides såfremt der viser sig

et behov for dette senere.

Dette tydeliggøres i rapporten.

89 Markus

Lampe,

DTU CAS

Bilag C Begge

sider

Teknisk Rigtig godt tiltag, at anvende en simplet

stabil klassifikation sammen med et

identificerende aspekt / egenskab.

For sikre en hurtig og bred integrering i

byggebranchen og største fleksibilitet

skulle man forenkle CCS, så at forklaring

ikke behøver at fylde 80 sider, men kan

forklares på få sider.

CCS til ”klassifikationsaspekt” (på

grundlag af en enklere klassifikation

end f.eks. SFB med synonymer) og

egenskaber. De 4 resterende aspekter

kunne fremhæves som ”nøgle

egenskaber”. Klassifikationen og

identifikation kan dermed også ske

igennem egenskaber (aspekt) sammen

med klassifikationsaspektet som stabilt

omdrejningspunkt ”fra vugge til grav".

Fremtidig fleksibilitet er sikret.

Ikke

accepteret

Den foreslåede ændring anses ikke for

tilstrækkelig fleksibel til at tilfredsstille

samtlige behov i livscyklus for et objekt.

90 Markus

Lampe,

DTU CAS

Saml.

Præsent

ation

Slide 27

til 29

Teknisk Softwaren skal automatisk klassificere.

Men sikkerhed af enkelt integration i

software er ikke tilstrækkelig

dokumenteret. Bestræbelser (Letter og

intet, afprøvningsprojekt) grunder ikke

på den til høring fremlagt materiale.

Softwareudbyder har ikke set helheden

af CCS. Dybden af forpligtelse af

integration er ikke defineret (f.eks.

komponentniveau).

Mere inddragelse af en breder vifte af

softwareleverandør. Når CCS er

defineret, bred undersøgelse af

integrationsmuligheder med svar ad

softwareleverandør i ca.

programmeringstid for integrationen af

f.eks. kalssifikationssaspekter og

egenskaber.

Noteret cuneco har en dialog med et bredt

udsnit af de leverandører, der leverer

IT-systemer til den danske

byggebranche, og er for indeværende

ikke blevet gjort opmærksom på, at der

er ting i CCS der ikke vil kunne

implementeres i software. cuneco er

opmærksomme på, at enkel

softwareunderstøttelse samt

tydeliggørelse af værdiskabelse er to

helt centrale forudsætninger, for at

tingene bliver implementeret.

91 Markus

Lampe,

DTU CAS

Side 8 Teknisk ”d. løbende test af IT-egnetheden” Dokumentation offentliggøres

Har man bed Bips / Cunecos IT-

leverandør udvalg at bekræfte dette?

Delvist

accepteret

Procedure og deltagere tilføjes i

rapporeten.

92 Markus

Lampe,

DTU CAS

Side 8 Side 63

Figur 10

- CCS og

relation

til

IFC/IFD

Teknisk ”e. CCS kode og relation/samspil med

IFC og IFD”

Dokumentation, redegørelse

offentliggøres

Har man bed Bips / Cunecos Building

Smart udvalg at bekræfte dette?

Noteret bips buildingSMART udvalg er ikke

blevet bedt om at bekræfte de

udtalelser, som rapporten indeholder

om IFC og IFD. Projektgruppen har haft

møde med Håvard Bell (Norge), der er

en af bagmændende bag IFD for bedst

muligt at beskrive, hvordan der kan

drages fordel af denne teknologi i

forhold til CCS.

93 Markus

Lampe,

DTU CAS

Side 9 Redaktio

nel

”(…) Undervejs i projektet er afholdt

koordinerende workshops og møder

med(…)”.

Blev CCS forlagt IT-leverandørgruppen i

Bips?

Forlægges IT-leverandørgruppen i Bips. Accepteret Er gennemført som en del af

projektarbejdet.

Det præciceres, at gruppen er IT-

leverandørgruppen i bips i stedet for

”interessenter fra IT-

leverandørbranchen”.

94 Markus

Lampe,

DTU CAS

Side 12

Side 59

Teknisk ”(…) Klassifikationsdelen i CCS skal

muliggøre en statisk klassifikation af en

bygningsdel eller et rum, således at

tilskrivningen af egenskabsdata ikke

ændrer klassifikationen af objektet.(…)”

Er man sikkert på, at egenskaber aldrig

må være klassificerende?

”(…) Egenskabsdata såsom materialer

eller form indgår ikke som

klassifikationstema.(…)” Det kan være

meget vigtig, f.eks. for entreprenør.

Alternativ: Kun klassifikationsaspekt &

egenskaber (herunder f.eks. de

resterende aspekter).

Hermed sikres en fremtidig fleksibilitet

og gøre det muligt at anvende

egenskaber til identifikation og

typisering. Det vil kunne dække alle

behov af alle aktør i byggebranchen.

Delvist

accepteret

CCS indeholder en forenklet

klassifikation, der kan indgå i en entydig

identifikation af et objekt. Når objektet

er identificeret, kan man finde de

øvrige egenskaber der er knyttet til

objektet.

Det er muligt projektspecifikt at inddele

objekter i klasser på baggrund af

objekternes egenskaber men hvad CCS-

klassifikationen angår, forudsættes det

at objekterne ikke ændrer klasse, når

egenskaber ændres i projektforløbet.

Egenskaber kan inddeles i klasser hvor

det giver mening/værdi.

95 Markus

Lampe,

DTU CAS

Side 14 Teknisk ”(…) Herved udelukkes bl.a. GUID(…)” –

farlig, da den bruges i dagens dato i

mange sammenhæng som kobling

mellem forskellige programmer. F.eks.

arealstyring i Dalux.

GUID kan anvendes som link. Ikke

accepteret

GUID kan evt. anvendes som link, men

anses som ustabil som identifikation set

over livscyklus.

96 Markus

Lampe,

DTU CAS

Side 18 Teknisk ”(…) De enkelte aspektkoder kan

anvendes individuelt eller i kombination

med hinanden. (…)”.

Det er rigtig vigtigt, at man ikke bliver

påkrævet hvilke aspekter eller

kombinationer man SKAL anvende.

Dette er forskelligt fra fase til fase og

behov til behov og fra bygherre til

bygherre.

Accepteret CCS stiller ikke krav om hvilke aspekter

der anvendes af de forskellige parter,

da dette er afhængigt af deres

individuelle behov.



eksempelmateriale.

97 Markus

Lampe,

DTU CAS

Side 67 Redaktio

nel

Definition af ”aspekt” mangler

Vigtig grundlægende del af CCS

Definition tilføjes Accepteret Definitionen tilføjes.

98 Markus

Lampe,

DTU CAS

Side 73 Redaktio

nel

“Der savnes en enklere klassifikation af

bygningsdelene.”

Man kan ikke sige at CCS er enklere en

DBK med aspekterne

Der anvendes en funktionel enkelt

klassifikation af bygningsdele og rum &

egenskaber

Der bruges filter for egenskaber og eller

bygningsdele/rum klassifikationen for

at finde de ønskede dele.

Ikke

accepteret

Kodeprincipperne i CCS lægger op til at

klassifikationsdelen forenkles i forhold

til DBK2006. Identifikation af objekter i

CCS foretages ved brug af

referencestrukturer eller simpel

fortløbende nummerering. Dette

betyder at objekter idenficeres ved

brug af CCS, og det er derfor ikke

nødvendigt at finde objekter ved brug

af diverse former for filtre.

99 Markus

Lampe,

DTU CAS

Side 74 /

75

Teknisk ”Kommentar: Skillefladen mellem

egenskabsdata og klassifikation af

objekter bør defineres således at

kodningen af byggematerialer og

produkter ikke bliver påvirket af

ændringer i deres egenskabsdata”

”(…) af egenskabsdata ikke ændrer

klassifikationen af objektet.”

Hvorfor skal Skillefladen mellem

egenskabsdata og klassifikation

defineres? Hvis man kun bruger

klassifikationsaspektet & egenskaber er

det også løst.

Hvorfor er det nødvendig? Brug af

klassifikationsaspektet & egenskaber

gør bygningsdel og rum stabil. Man kan

udpege den egenskab, som ikke skal

ændre sig ”fra vugge til grav” og det

kunne også være en brandklasse lige så

meget som f.eks. funktionsaspektet.

Noteret Kommentaren videregives til

projektgruppen der arbejder med

klassifikation.

100 Christia

n

Lundstr

øm

Generel ISO standarden foreskriver anvendelse

af symboler som præfiks for angivelse

af domæne. Dette giver anledning til

misforståelse idet +, -, = har entydig

betydning i samfundet som regnetegn

og vil blive læst som sådan. I forhold til

oplistning af bygningsdele m.v. i

regneark vil anvendelse af de gængse

regnetegn give anledning til problemer

og store fejlmuligheder. Eks. =JB2 vil

returnere indholdet af celle JB2, som

almindeligvis er =0.

==, ++ o.l. har tilsvarende andre

betydninger ved programkodning,

hvorfor de også ved implementering i IT

programmer kan give anledning til

misforståelser hos programmører og

fejl.

At præfiks f.eks. anføres i parentes (=),

(+) etc. Dette giver større

læsevenlighed, færre misforståelser og

kan anvendes i regneark.

Ikke

accepteret

Da cuneco finder at tilføjelse af fx

parenteser i forbindelse med præfiks vil

besværliggøre arbejdet med koderne

vælger vi at fastholde, den foreslåede

notation. Det er i fx Microsoft Excel

muligt at ændre formateringen af celler

for at sikre, at CCS-koder ikke opfattes

som regneudtryk, formler eller

referencer.

101 Kristian

Birch

Pederse

n

3.1

Projekt-

grundlag

Teknisk Det er lidt trist, at cuneco alene

forsøger at løse morgensdagens

udfordringer med gårsdagens metoder.

I andre brancher udvikles ontologier,

der redegør for objekter og

sammenhænge mellem objekterne.

Herved kan man opbygge intelligente

videnhåndteringssystmer, der

automatisk kan analysere viden i

systemer.

I CCS ses kun på objekter, men ikke

deres relationer, dermed er CCS alene

anvendeligt til strukturering og ikke

umiddelbart klart til at blive anvendt

f.eks. i forbindelse med Semantic Web

teknologier o.lign.

Jeg har beskrevet en ontologi-

udviklingsmetode i denne rapport på

side 251, som cuneco med fordel kunne

lade sig inspirere af:

http://vbn.aau.dk/files/55290157/Virtu

al_Models_Linked_with_Physical_Com

ponents_in_Construction.pdf

Noteret I forbindelse med cunecos projekt vedr.

metode og struktur for egenskabsdata

beskrives det, hvordan relationer til

andre objekter er en egenskab for et

objekt. Om dette er fuldt tilstrækkeligt i

forhold til at opfylde de formål, der

efterlyses, kan være genstand for en

nærmere analyse, men i forhold til

nærværende projekt har vi begrænset

os til at identificere det enkelte objekt

med henblik på at kunne referere til

alle egenskaber for objektet.

102 Kristian

Birch

Pederse

n

4.2 Krav Teknisk Det undrer, at kravene er så detaljerede

tekniske, og at der ikke er formuleret

nogle mere overordnede krav om hvad

klassifikationssystemet som minmum

skal kunne bruges til.

Derved er der en betydelig risiko for at

CCS opfylder de formaliserede tekniske

krav uden f.eks. at være egnet til at

strukturere bygningsdele, så de kan

anvendes til entydig og automatisk

prissætning i forbindelse med udbud

baseret på mængder og lignende

prakiske use-cases.

Noteret Den valgte fremgangsmåde er en

konsekvens af, at cunecos

behovsanalyser´(der netop skal belyse

anvendelsen) har pågået samtidig med

gennemførelsen af

kodestrukturprojektet. Samtidig er det

cunecos holdning, at man med den

definerede struktur vil kunne opfylde

de beskrevne behov. cuneco er

indstillet på, at foretage korrektioner,

hvis det fortsatte arbejde indikerer, at

dette er nødvendigt.

103 Kristian

Birch

Pederse

n

4.2 Krav Teknisk Det undrer, at det ikke er noget krav, at

der udvikles en klassifikationsstruktur

som er konsistent, korrekt og uden

redundans.

Noteret

104 Kristian

Birch

Pederse

n

Afsnit 5 Redaktio

nel

Formuleringen ”CCS omhandler klasser

og identifikation af objekter i ”den

rigtige verden”, dvs. uden om (IT)

modelverdenen. Dermed sikres, at CCS

ikke er i konflikt med eventuelle 3D

modeller, IFC m.v., men er et fælles

referencepunkt for disse. ” virker noget

talesprogsaktig og indekreret, at der

formodes at være en konklikt ift. IFC.

Det foreslås at lade afsnittet udgå og i

stedet udføre en saglig vurdering og

eksemplificering af hvorledes CCS og

IFC kan anvendes sammen.

Delvist

accepteret

Afsnittet udgår ikke, men forholdet

mellem IFC og CCS beskrives bedre.

105 Kristian

Birch

Pederse

n

Afsnit 5 Teknisk Beskrivelsen af forskellen på

objekttype, objektforekomst og

objektindivid er ikke helt klar. Er det

nødvendigt at tale om både

objektforekomster og objektindivider?

Er begge ikke blot en instans af en

objekttype med forskelligt

detaljeringsniveua af egenskabsdata?

Det foreslås at lade betegnelsen

objektindivid udgå, ligesom det er valgt

for rum i afsnit 6.

Delvist

accepteret

Definitionerne af de forskellige objekter

er central og bevares, men suppleres

med en figur der tydeliggør forskellen.

106 Kristian

Birch

Pederse

n

Afsnit 5 Teknisk Formuleringen ”Objektindivider kan

udskiftes, mens objektforekomsterne

består.” er ikke korrekt, afhænger det

ikke af størrelsen af renoveringen?

Se ovenfor. (red. Kommentar 105:

"Kristian Birch Pedersen, Exigo-5")

Delvist

accepteret

Formuleringen rettes og skal præcicere,

at objektforekomster også kan udgå,

såfremt objektet helt udgår.

107 Kristian

Birch

Pederse

n

Teknisk Ville det ikke være hensigtsmæssigt, at

sætte referencekoderne til sidst? Med

undtagelse af efter ibrugtagning af el og

mekaniske anlæg underlagt

stærkstrømsbekendtgørelsen og

maskindirektivet er disse af mindre

betydning end klassifikationskoden.

Noteret Det er uklart hvad der menes med

”referencekoderne”.

Rækkefølgen af de forskellige

aspektkoder er uden betydning.

108 Kristian

Birch

Pederse

n

4.2.2

Identifik

ationskr

av

Teknisk Hvorfor bruges ressourcer på at

integrere kodningsprincipperne med

identificationsprincipper? Kan dette

ikke blot gøres med en unik genereret

kode, som det kendes fra f.eks. IFC-

modeller, stregkoder, RFID-tags,

objekter bygningsmodelleringssoftware

m.v.?

Ikke

accepteret

I flere sammenhænge vil de automatisk

genererede koder, der stammer fra fx

bygningsmodelleringssystemer, ikke

være anvendelige. Dette gælder fx hvis

man ønsker at slette et objekt og

genindsætte uden at ændre

identifikationen af objektet. Derudover

vil denne type koder ikke være læselige

for mennesker, og det vil ikke give

mening at sortere efter dem.

109 Kristian

Birch

Pederse

n

Generelt Generel Det er lidt trist, at der bruges så meget

fokus på referencestrukturer

sammenligt med den beskedne fokus

på klassifikation.

Lad teksten om referencestruktur udgå

og tilføj følgende: ”For anvendelse af

referestrukturer i forbindelse med

f.eks. driften af mekaniske og elektriske

anlæg se: ISO/IEC 81346”, og kom nu i

gang med at definere de

klassifikationstabeller. Den danske

byggebranche har behov for et

klassifikationssytem hurtigst muligt.

Ikke

accepteret

Klassifikationen har fået en central rolle

i CCS. Det er vigtigt at få et fælles

kodningsprincip på tværs af fagene /

domæner.

110 Kristian

Birch

Pederse

n

Afsnit

7.1.4

Teknisk Det er uklart hvor dybt cuneco vil

klassificere bygningsdele. Hvis dette

gøres alt for overordnet, vil CCS blive

uanvendeligt til f.eks. brug i forbindelse

med f.eks. automatisering af

tilbudsprocessen.

En stålsøjle bør f.eks. kunne skelnes fra

en betonsøjle via klassifikationskoden,

selvom den eneste forskel på dem er

egenskabsdata for materialer.

Alternativt bør egenskabsdataene

systematiseres så meget, at der

automatisk kan filtreres eller sorteres

efter dem i stedet for

klassifikationskoden.

Præciser den planlagte dybde af

klassifikationstabellerne.

Noteret Kommentaren vidergives til

arbejdsgrupperne for klassifikation og

egenskabsdata.

Kommentaren ” Alternativt bør

egenskabsdataene systematiseres så

meget, at der automatisk kan filtreres

eller sorteres efter dem i stedet for

klassifikationskoden” er den løsning der

er valgt i CCS.

111 Kristian

Birch

Pederse

n

Afsnit

3.1

Teknisk ISO 12006-2 nævnes i projekgrundlaget,

men dens fundamentale pincip med at

klassifikationstabeller skabes ud fra en

overordnet systematik om at en

”construction process” skaber et

”construction result” og bruger

”construction ressource” ser ud til at

være helt negliceret i CCS. På den

baggrund vurderes det meget tvilvsomt

om CCS i praksis vil kunne mappes til

andre klassifikationssystemer baseret

på ISO 12006-2.

Delvist

accepteret

De foreslåede CCS koder anvendes

udelukkende i ”construction result”,

hvilket præciceres i rapporten.

Mapning til andre landes

klassifikationssystemer foregår via IFD,

hvilket præciseres i rapporten.

112 Kristian

Birch

Pederse

n

Afsnit

7.1.4

Teknisk Det er uklart hvad der sker med koden

hvis der viser sig behov for at have

mere end 29 objekttyper på hvert

niveau.

Delvist

accepteret

Der er rettelig plads til 23 objektklasser

pr. niveau, og ikke 29. Klassifikationen i

CCS fastlægges så der ikke er behov for

mere end 23 objektklsser pr. niveau i

klassifikationen.

Det præciceres i rapporten, at der

anvendes underklassifikation såfremt

de 23 typer overskrides.

113 Kristian

Birch

Pederse

n

Afsnit 8 Teknisk Det giver ikke mening at omtale et

klassfikationsaspektet. Klassifikationen

anvendes til at strukture og gruppere

de øvrige aspekter.

Lad klassifikationsaspektet udgå. Delvist

accepteret

Fuktionaliteten af

"klassifikationsaspektet" i CCS

bibeholdes. En endelig afklaring af

anvendelsen af begrebet aspekt pågår i

cuneco i øjeblikket, og denne afklaring

vil afgøre, om begrebet

'klassifikationsaspekt' bibeholdes eller

omdøbes, fx til "typeaspekt".

114 Kristian

Birch

Pederse

n

Afsnit 8 Teknisk Der er ikke taget stilling til hvorledes

hovedparten af tabellerne i ISO 12006-2

skal kodes.

Noteret Nærværende projekt omhandler kun

resultatdomænet i ISO 12006-2.

Ressource- og procesdomænet

håndteres separat hvilket dog ikke

betyder, at man ikke vil kunne komme

til at anvende lignende principper i

disse domæner. Det konkrete antal

tabeller, der skal udvikles er ikke

fastlagt og vil afhænge af de

identificerede behov samt de

igangværende afklaringsprojekter.

115 Kristian

Birch

Pederse

n

Afsnit 8 Teknisk Det er unødvendigt at anvende %-

tegnet foran klassifikationskoden, det

vil sikkert forvirre mere end det vil

gavne.

Ikke

accepteret

Tegnet er medtaget for at kunne skelne

de forskellige aspektkoder entydigt fra

hinanden.

Dette understøtter bl.a. IT

anvendeligheden af CCS.

116 Kristian

Birch

Pederse

n

Afsnit 8 Teknisk Er et rum ikke en slags placeringsaspekt

i sig selv?

De dobbelte koder for rum bør udgå.

Det forvirrer mere end det gavner.

Ikke

accepteret

Det er uklart hvad der menes med

”dobbelte koder”.

117 Kristian

Birch

Pederse

n

Afsnit 8 Teknisk Rum har fået sin egen præfiks med

dobbelt-koder. Det virker lidt underligt.

Hvad sker der med alle de objekter i

byggeriet som endnu ikke er

klassificeret såsom materiel,

arbejdsprocesser, bebyggelser,

personer/roller osv. Er tanken så for

hver klassifikationstabel, at fortsætte

med at sætte tegn efter hinanden? Var

det ikke mere hensigtsmæssigt blot at

bruge et tal eller bogstav til

klassifikationstabellens nummer?

Delvist

accepteret

De fremlagte kodeprincipper anvendes i

resultatdomænet. De nævnte klasser

ligger jævnfør ISO 12006-2 i andre

domæner end resultatdomænet og

tænkes ikke kodet i henhold til en

aspekttankegang. Dette præciseres i

rapporten.

118 Kristian

Birch

Pederse

n

Afsnit

10.

Teknisk De fire foreslåede tabeller for

bygningsdele har ikke nogen

umiddelbart relation til ISO 12006-2.

Der foreslås at lave en 100 % 1-til-1

sammenhæng mellem de 16

overordnede klasser (tabeller) i ISO

12006-2 og de overordnede tabeller i

CCS.

Argumentationen er et citat fra ISO

12006-2, side 9:

“There are other possible ways of

specializing the object classes, but the

recommended tables are considered to

represent the most important ways.

Provided that each country uses this

framework of tables and follows the

definitions given in this part of ISO

12006, it will be possible for

standardization to develop table by

table in a flexible way; e.g. country A

and country B could have a common

classification table of elements, for

example, but different classification

tables for work results without

experiencing difficulties of “fit” at the

joints.”

Ikke

accepteret

De 4 foreslåede tabeller (systemtabel,

bygningsdelstabel 1, bygningsdelstabel

2, ISO/IEC 81346-2 tabel 1) er alle del-

tabeller af ISO 12006-2 tabel A7

(elements).

Det bemærkes, at ISO 12006-2 er under

revision, og at dette bl.a. omfatter nye

tabeller som ikke eksistere I ISO 12006-

2 I dag, herunder del-af tabeller som fx.

CCS strukturelle produktaspekter.

119 Kristian

Birch

Pederse

n

Afsnit

10.1.1

Teknisk Det virker højest besyndeligt at starte

kodningen med K for terræn.

Hvor blev KISS princippet af? Alfabetet

starter med A.

Det virker somom, at CCS forsøges

indpasset i ISO 81346 uden rigtigt at

passe særlig godt ind.

Referencesystematikken bør kun

anvendes der hvor den giver mening og

ikke gennemsyre og komplicere

klassifikationskoderne unødigt. De tre

grundlæggende aspekter produkt,

placering og funktion der anvendes i

ISO 81346 giver god mening, men at

gennemtvinge referencemetodikken i

alle andre klassifikationstabeller virker

ikke gennemtænkt, og vil med stor

sandsynlighed resultere i, at CCS vil lide

samme triste skæbne som DBK 2006.

Ikke

accepteret

Klasserne for hovedsystemer skal følge

reglerne for klassifikation beskrevet i

ISO/IEC 81346-2 tabel 3.

De anførte klasser er kun ment som

eksempler.

Klasserne af hovedsystemer skal kun

anvendes i del-af strukturene, og ikke i

%-klassifikationen, der alene

klassificerer bygningsdele (uden at

være en del af en referencestruktur).

120 Kristian

Birch

Pederse

n

Afsnit

10.1.2

Teknisk Det er højest besyndeligt, at der i

forslaget til klassifikationstabellen er

gjort rigtig meget for at undgå konflikt

med kodning af elektriske og mekaniske

bygningsdele efter ISO/IEC 81346-2,

men det virker ikke som om, at der er

brugt energi på at udvikle et system

baseret på ISO 12006-2.

Noteret ISO/IEC 81346-2 og ISO12006-2 er ikke i

konflikt med hinanden.

121 Kristian

Birch

Pederse

n

Teknisk Definitionerne af Konstruktioner, Del-

konstruktioner og Komponenter virker

ikke særligt teoretisk velfunderet. Er

der ikke blot tale om bygningsdele, som

kan nedbrydes i bygningsdele ind til et

atomart niveua nås?

Der foreslås opbygget én simpel

klassifikationsstruktur med 5-8 niveauer

og 2-5000 bygningsdele. Arbejdet

foreslås grebet successivt an, så

detaljereingsniveauet fastlægges ud fra

behovet svarende til praktisk

anvendelse.

Noteret Kommentaren vidergives til

arbejdsgruppen for klassifikation, hvor

indelingskriteriet for de enkelte klasser

skal defineres.

Teknisk note: Der vil i praksis være få

hundrede objekter der skal klassificeres

jf. det nye princip om stabilitet, og ikke

2-5000 som anført.

Klassifikationsstruktur med 5-8

niveauer vil ikke overholde kravet om

stabilitet i klassifikationen, og der vil i

praksis sandsynligvis blive tale om 2-3

niveauer for at skabe en stabilitet der

er tilstrækkelig.

122 Kristian

Birch

Pederse

n

Afsnit

11.3

Teknisk I teksten står: ”At arbejdet funderes på

ISO12006-2” dette er ikke udmøntet i

den i høringsmaterialet beskrevne

udgave af CCS, der alene er baseret på

ISO 81346-2.

CCS bør grundlæggende baseres på ISO

12006-2 og ISO 81346-2 bør så

indpasses heri, og ikke omvendt.

Alternativt kan ISO 81346-2 anvendes

som supplement i forbindelse elektriske

og mekaniske systemer i drift.

Delvist

accepteret

CCS er baseret på ISO 12006-2, der er

en rammestandard for klassifikation af

byggeriet (dvs. uden at være særlig

specifik).

ISO 12006-2 omhandler ikke

kodningsprincipper for bygningsdele

eller rum.

ISO/IEC 81346 indeholder principper for

kodning og identifikation, som cuneco

har valgt at inddrage i arbejdet i det

omfang det kan supplere ISO 12006-2.


123 Kristian

Birch

Pederse

n

Afsnit

11.3

Teknisk Det er uklart hvorledes cuneco tænker

ISO 12006-2 og ISO 81346-2 anvendt i

sammenhæng. Kan produktaspektet

f.eks. sidestilles med ”work result” i ISO

12006-2?

Delvist

accepteret

Tydeliggøres i rapporten.

124 Kristian

Birch

Pederse

n

Generelt Generel Ideen om at have en stabil kode

gennem hele projektet er fin.

Noteret

125 Kristian

Birch

Pederse

n

Generelt Generel Anvendelsen af bogstaver i koderne i

stedet for tal er fin, det giver kortere

koder end ved anvendelse af tal.

Noteret

126 Jan

Karlshøj

Generel Positivt

· Man arbejder med en mere

stringent syntaks i kodningen.

Arbejde med adskilte variable og kun

bruge sammensatte strenge, hvor det

giver værdi.

Noteret Aspektkoderne kan i det fremsatte

forslag allerede nu anvendes separat og

sammensættes til en samlet kodestreng

efter behov.

127 Jan

Karlshøj

Generel Positivt

· Man fjerner krav om

klassifikationen per undertype skal

danne en kontinuer liste af tal. Dvs. en

ventil har samme ”underkode” uanset

om den tilhører det ene eller andet

system.

Noteret

128 Jan

Karlshøj

Generel Positivt

· Der er en klarere adskillelse af

klassifikation og løbenr.



giver værdi.




efter behov.

129 Jan

Karlshøj

Generel Positivt

· Der forventes en mere overordnet

klassifikation, som ikke overlapper så

meget med objekternes egenskaber.



giver værdi.




efter behov.

130 Jan

Karlshøj

Generel Negative

· Strukturen ser fortsat ud til at

være kompliceret og kræve bruge af

computere, men på den anden side ikke

it-egnet.



giver værdi.




efter behov.

131 Jan

Karlshøj

Generel Negativt

· Ser ikke specielt it-egnet ud – fx

svært at lave en sortering i Excel. Man

blander fire aspekter sammen i en

kode.

Jeg ville foretrække, hvis der skal være

4 koder/variable, at de var adskilte og

kun blev samlet i forbindelse med

udskrifter. Jeg mener ikke at strengen

egner sig til behandling i it-systemer.

Brugen af specielle karakterer gør ikke

implementeringen lettere.

Delvist

accepteret

Aspektkoderne kan anvendes separat

og sammensættes til en samlet

kodestreng efter behov.

Egenskabsprojektet vil varetage dette

således at de enkelte aspektkoder er

separate egenskaber på objekterne

(datamæssigt set).

Brugen af præfiks og skråstreger til

seperering af aspektkoderne muliggør

adskillelse af aspektkoderne.

132 Jan

Karlshøj

Generel Negativt

· Systemet giver anledning til

dobbelt registrering såfremt at fx BIM-

programmer benyttes. CCS kan angive

relationen fra en bygningsdel til et rum,

men denne relation ”kender” softwaren

allerede eller kan beregne den.

Skal kun bruges når det er relevant – fx

i forbindelse med udskrifter.

Delvist

accepteret

CCS er designet til brug i alle

sammenhænge, herunder også BIM

(men ikke begrænset hertil). Det kan

ikke forudsættes, at alle parter har BIM

til rådighed, og derfor skal CCS også

kunne håndteres uden BIM-modeller.

Systemerne vil kunne generere den

strukturelle kode ud fra deres kendskab

til sammenhængen. Det er ikke

nødvendigt at vedligeholde den

strukturelle kode mens man arbejder

internt i systemet.

133 Jan

Karlshøj

Generel Negativt

· Koblingen til IFD er kun mulig for

en del af CCS-koden. Bruges hele koden

kan den ikke kobles til IFD.

Adskil strengen i flere variable. Delvist

accepteret

Se svar til høringskommentar nr. 58

134 Jan

Karlshøj

Generel Negativt

· Det er mere eller mindre basalt

set DBK i en forbedret udgave, men

med mange af de samme svagheder

som DBK havde.

Hold tingene adskilt. Lav et it-egnet

system og fasthold de eksisterende

systemer/lav det er nødvendigt af

hensyn menneskelig tolkning. Det må

forventes at regler og lovgivning i

stigende grad tillader brug af it, og

dermed vil behovet for systemer til

menneskelig tolkning blive mindre.

Ikke

accepteret

Det er uklart hvad der menes med

”mange af de samme svagheder som

DBK havde”, ”Hold tingene adskilt” og

”Lav et IT-egnet system”.

Ifølge cunecos opfattelse beror mange

af de uhensigtsmæssigheder, der er

blevet påpeget i forhold til DBK på, at

man i forbindelse med udviklingen og

impelementering ikke i tilstrækkelig

grad har belyst, hvordan og til hvad

systemet skulle anvendes. cuneco vil

gennem en beskrivelse af hvordan CCS

anvendes i interaktionen mellem

mennesker-mennesker, mennesker-

maskiner og maskiner-maskiner sikre,

at systemet vil kunne anvendes nu

uden at blive konserverende i forhold til

den fremtidige udvikling.

135 Jan

Karlshøj

Side 51 Generel %JB / #JB7 / -MB3.JB2 / =MB1 /

+MB3.DF3 / ++A1.AAA1

Adskil strengen i flere variable. Noteret Aspektkoderne kan i det fremsatte



efter behov.

136 Jan

Karlshøj

Generel Er/bliver materialet kommenteret af

Anders Ekholm og Lars Haggstöm?

Få både Anders Ekholm og Lars

Haggstöm til at kommentere konceptet.

Noteret cuneco har indgået aftale med Anders

Ekholm om at han kommenterer

materialet.

137 Jan

Karlshøj

Generel Er konceptet reelt baseret på input

behovsanalysen? Og er der lavet en

mapping mellem elementerne i

konceptet og behovsanalysen?

Lav en mapning – så er det klart for alle

hvor behovet kommer fra.

Noteret Behovsanalysen siger ikke særlig meget

om klassifikation - men siger rigtig

meget om behov der forudsætter, at

der foreligger en fælles klassifikation.

cuneco arbejder på at beskrive

løsningen af disse behov i form af

scenarier, som anvendes i forbindelse

med udvikling og afprøvning.

138 Michael

Porskær

, Søren

Jensen

A/S

Teknisk Aspektkoder bør komme i bestemt

rækkefølge, der bør som minimum

anbefales en rækkefølge. I forhold til IT

systemer er det naturligvis underordnet

hvilken orden de kommer i, men i

praktisk daglig brug ville det for

genkendelsen, når man arbejder på

forskellige projekter være rart at ikke at

skulle huske på hvad der nu gælder for

det ene og det andet.

Der vedtages en række følge for

aspektkoder

Ikke

accepteret

Aspektets præfiks er entydigt og er

tilstrækkelig til at genkende koden,

både for mennesker og IT-systemer. En

fast rækkefølge er derfor ikke

påkrævet.

Kommentaren overføres envidere til de

grupper der skal arbejde med

vejledninger / eksempelmateriale.

139 Michael

Porskær

, Søren

Jensen

A/S

Side 23 Teknisk Antallet af cifre i løbenummeret bør

være fast ellers skal det aftales fra gang

til gang

Antalet af cifre vedtages at være 3 Ikke

accepteret

Koderne vil blive unødigt lange, og kan

endvidere vedtages separat for de

enkelte projekter.

140 Michael

Porskær

, Søren

Jensen

A/S

Side 38 Teknisk Hvornår er det godt at vide at en

stikkontakt sidder i en bestemt væg?

Referencen til væggen kan naturligvis

undlades, men der savnes konkrete

eksempler på hvornår det giver mening

at have denne reference og hvem der

kan have gælde af den

Specificer med konkrete eksempler Noteret Kommentaren overføres til de grupper


eksempelmateriale.

141 Michael

Porskær

, Søren

Jensen

A/S

Side 55 10.1.1 Teknisk Hvorfor er systemnumre ændret til

bogstaver? Er det fordi 81346-2 angiver

disse, ville det ikke være godt at kunne

skælle systemer fra bygningsdele der

også er 2-cifre bogstaver

Noteret CCS benytter konsekvent bogstaver

som klassifikation.

142 Michael

Porskær

, Søren

Jensen

A/S

Side 55 Teknisk Der savnes en definitation af hvornår

mar eksempelvis et vægsystem. Det kan

være det løser sig når tabellerne bliver

udarbejdet, men system tanke gangen

er ikke så umiddelbar ved arkitekt og

konstruktuion, som den er ved

installation

Det definderes klare hvornår man har

et system.



eksempelmateriale.

143 Claus

Johanne

ssen

Generelt Generelt Generel Kære Cuneco. Jeg deltog i jeres

høringsmøde i går på DTU. Selve

grundlaget for kodningsprincipperne

ser ud til at kunne bære igennem fsa.

”Kodning” Jeg vil dog stille spørgsmål til

anvendeligheden i det daglige arbejde.

Hvorfor kalder man ikke en spade for

en spade og en dør for en dør ? Når vi

skal beskrive en bygningsdel har vi brug

for en klar beskrivelse. Dvs. at vi altid –

og også fremover vil bruge en

betegnelse der angiver dørnummer,

brandklassifikation, materialer, farve,

beslåning mv. – og det er det samme

for alle bygningsdele. Hvad skal så

egentligt bruge koden til hvis ikke den

er i stand til at beskrive dette ? Så er

det jo bare det samme som et ethvert

andet nummer. HVORFOR kan man ikke

bruge betegnelser i klassifikationen

som: DOOR, WALL, CEILING, FLOOR,

ROOF, BUILDING, ROOM, etc. etc. Det

giver umiddelbart mening og vil være

en information vi vil skulle levere under

alle omstændigheder. Det virker som

om kodningsprincipperne er bygget op

omkring en tankegang der fokuserer på

små EL og VVS dimser som nok er

svære at holde styr på men i bund og

grund ikke bør diktere klassifikationen

på det der er det væsentlige: Nemlig

BYGNINGEN !

Nu har en dør heddet en dør i mange

tusinde år. Brug IFC navngivningen !

Ikke

accepteret

Koderne vil blive for lange (Door3,

Wall34) og princippet kan ikke håndtere

underklassificering af objekter i typer.

144 NCC Generel NCC har gennem flere år anvendt dele

af DBK2006 (bygningsdele og

entrepriser). Vi er overbevist om

værdien af et klassifikationssystem. For

os er værdien skabt gennem vores egen

interne anvendelse af DBK, ikke

gennem kommunikation af DBK-koder

med andre virksomheder. Ikke fordi, vi

ikke gerne vil kommunikere DBK-koder

med andre, men fordi der har været få

at kommunikere med.

Værdien af et klassifikationssystem

fremhæves ofte som kommende fra at

virksomhederne kan kommunikere

effektivt med hinanden, at vi taler

samme sprog. Den værdi er der

naturligvis, men den første, og i lang tid

den største værdi er den, virksomheden

skaber internt gennem veldefinerede

begreber, en ensartet terminologi, en

nyttig struktur, et anvendeligt

kodesystem osv.

Der er ikke behov for ændringer til

standarden på dette punkt.

Men fortæl meget gerne om begge

former for værdiskabelse:

· Den værdi, virksomheden kan

skabe internt, også selvom den i lang

tid er ret alene om at bruge

klassifikationssystemet.

· Den værdi, der skabes, når

virksomheden kan kommunikere mere

effektivt med andre virksomheder.



eksempelmateriale.

145 NCC Generel Det er ikke muligt fuldt ud at vurdere

”CCS kodningsregler” på nuværende

tidspunkt.

Af to årsager:

· Standarden er kompleks og svær

at forstå. Der er tale om meget mere

end ”kodningsregler”, nemlig en hel

filosofi for, hvordan klassifikation skal

håndteres i den danske byggebranche.

Man kan ikke afslutte formidling og

høring af noget så komplekst på 18

dage. Det bliver ikke nemmere af, at

rapporten kunne være mere

pædagogisk. Vi er bange for, at mange i

branchen ikke har kunnet sætte sig

fyldestgørende ind i standarden på den

korte tid – selvom de gerne ville. Det

gælder i hvert fald os selv.

· Rapporten beskæftiger sig kun

med en del af CCS’ samlede

klassifikationskoncept. Rapporten

udpeger (gennem eksempler) kun de

objekttyper, der skal klassificeres (de

forskellige bygningsdele, f.eks.

”vægkonstruktion”, ”dør”, ”samling”).

Det har bestemt værdi, men begrænset

i forhold til en mere detaljeret

klassifikation. Der er behov for

underklassifikation af f.eks.

bygningsdele (forskellige

vægkonstruktionstyper, dørtyper, …).

Rapporten mener, at yderligere

klassifikation af objekttyperne skal

håndteres vha. egenskabsdata. Det

betyder, at cunecos samlede

Vi synes, det en fordel med del-

høringer, som den der er i gang for CCS

kodningsregler. Den samlede opgave

både med udvikling og høring af CCS må

nødvendigvis brydes ned.

Af de to årsager, nævnt i

kommentarkolonnen foreslår vi, at

høringen af ”CCS kodningsregler”

afsluttes med status ”Vi er klogere men

ikke færdige med CCS kodningsregler

og klassifikation”.

Cuneco bør støtte yderligere formidling

og debat om ”CCS kodningsregler”.

Det er desuden nødvendigt med en

samlet diskussion og vurdering af hele

cunecos klassifikationskoncept. Det

samlede koncept vil være beskrevet i:

· En ny udgave af ”CCS

kodningsregler”, der tager

høringsresultatet i marts 2012 i

betragtning.

· Resultatet af cuneco-projektet

Afklaring af klassifikationsniveau. Dette

projekts opgave er bl.a. at afklare hvor

grænsen skal gå mellem klassifikation i

CCS og klassifikation vha.

egenskabsdata. Denne afklaringsopgave

ligger ret beset ikke i CCS

kodningsregler.

· De konkrete

klassifikationstabeller, der skal udvikles.

· Resultatet af cuneco-projektet

Afklaring af struktur og metode for

Noteret cuneco anvender helt generelt en

iterativ tilgang til udviklingen. Dette

betyder at der afholdes en lang række

høringer undervejs i

udviklingsprocessen, og at

tilbagemeldingen fra en høring kan

have konsekvenser for andre projekter

end lige præcis det, der var i høring i

den pågældende sammenhæng. cuneco

er derfor enige i den fremgangsmåde,

der foreslås i denne kommentar, og

opfatter det som værende i

overensstemmelse med den anvendte

arbejdsgang i cunecos projekter.

klassifikationskoncept bliver en

blanding af ”CCS-klassifikation” og

”CCS-egenskabshåndtering”.

egenskabsdata.

Den samlede vurdering af CCS skal

naturligvis inddrage resultatet af

yderligere cuneco-projekter, bl.a.

· Klassifikation af bebyggelser,

bygninger og rum.

· Begrebsmodel for

ressourcedomæne, samt heraf følgende

projekt(er).

Vurdering af de enkelte dele af

klassifikationskonceptet, og af det

samlede koncept, bør omfatte

· Formidling

· Høring

· Afprøvning

· Debat i branchen

146 NCC Afsn.

7.1.4

side 22

Generel Vi mener, at grænsen mellem hvilke

klassifikationsbehov, der dækkes vha.

klassifikationskoden, og hvilke

klassifikationsbehov, der dækkes vha.

(yderligere) egenskabsdata er helt

fundamental for alle

klassifikationssystemer, også for CCS.

Alle klassifikationssystemer har denne

grænse. På et eller andet tidspunkt

slipper mulighederne for klassifikation

vha. klassifikationskoden op, og man

må ty til (andre) egenskabsdata.

Forskellige klassifikationssystemer

placerer grænsen forskelligt. DBK2006

har mulighed for en ret detaljeret

klassifikation af bygningsdele, og – hvis

ellers bygningsdelsklasserne er nyttige

– må man relativt sjældent ty til de

øvrige bygningsdelsegenskaber for at

klassificere. OmniClass har en endnu

mere detaljeret klassifikation af

bygningsdele vha. klassifikationskoden.

Vi mener ikke, der er nogen naturlov,

der siger, hvilket klassifikationsniveau

(vha. klassifikationskoden), der er det

rigtige. Der er fordele og ulemper ved

både høje og lave niveauer. Vi har i

næste kolonne søgt at skitsere nogle

fordele og ulemper ved det meget høje

niveau, som CCS kodningsregler

anbefaler.

Vi vil pege på et muligt designproblem i

Lav en god analyse af fordele og

ulemper ved en klassifikationskode på

meget højt niveau og tilsvarende

omfattende brug af egenskabsdata til

klassifikationsformål. Her er, hvad vi

kan komme i tanke om:

Fordele:

· Klassifikationskoden vil med

relativt høj sandsynlighed forblive

konstant. Betyder f.eks., at

objektforekomstens identifikator

sjældent ændres, da

klassifikationskoden indgår i

identifikatoren (hvilket vi ikke er helt

overbeviste om, er en god ide, se andet

punkt).

· Klassifikationskoden kan gøres

relativt enkel indenfor det enkelte

aspekt.

· Koden kan indgå i dækningen af

mange klassifikationsbehov (men

ulempen er, at koden ofte ikke er nok).

· Mange varierede

klassifikationsbehov kan dækkes vha.

egenskabsdata. I princippet kan alle

objektets egenskaber, bortset fra

identifikatorer, bruges i klassifikation.

Man får fleksibilitet og dynamik i

klassifikationen.

· Relativt lille risiko for konflikt

mellem konkrete egenskabsdata og

klassifikationskode for det enkelte

objekt.

Ulemper:

· Det samlede

Delvist

accepteret

CCS kodningsregler og CCS klasser og

CCS egenskaber skal fungere sammen

som beskrevet, og derfor afsluttes

kodningsregler ikke før end

klassifikationen er på plads.

Kommentaren overføres til

klassifikations- og

egenskabsdatagruppen.

CCS kodningsregler. Fordi

klassifikationskoden indgår i

identifikatoren både i det simple

produktaspekt (#) og det strukturelle

produktaspekt (-), er CCS afhængig af,

at klassifikationskoden er stabil. Ellers

ændrer identifikatorerne sig, og det er i

høj grad uønskeligt. HVIS nu det viser

sig i cuneco-projektet ”Afklaring af

klassifikationsniveau”, at der er behov

for en mere detaljeret klassifikation af

bygningsdele, bliver koden (og dermed

identifikatorerne) mere ustabil. Der kan

blive behov for at gentænke dele af

designet.

klassifikationskoncept[1] skal inddrage i

hvert fald de egenskaber, der hyppigst

anvendes til klassifikation. Disse

egenskaber skal standardiseres

(egenskabsnavn, -definition, tilladte

værdier, …). Den samlede klassifikation

bliver mere komplekst at overskue, da

man ofte vil skulle kombinere de to

metoder, klassifikation og egenskaber.

· De IT-systemer, der skal oprette

og vedligeholde de standardiserede

egenskabsdata, skal have disse

egenskaber (”felter”) tilføjet i database

og på brugergrænseflade. Kan være et

stort arbejde og kan kollidere med

egenskaber, der allerede findes for

objektet (fordi der findes egenskaber,

der allerede ”ligner”, men ikke er helt

som defineret i CCS). Kan være meget

mere krævende, end at etablere en

klassifikationskode (der måske allerede

har et felt i systemet). Risiko for, at det

kan afholde mange virksomheder fra at

implementere andet end

klassifikationskoden.

· Brugerne skal indtaste og

opdatere de ekstra egenskabsdata (i

heldigste fald, kan et tilsvarende antal

eksisterende egenskaber fjernes).

· De IT-systemer, der skal anvende

klassifikationskode og tilhørende

klassifikationsegenskaber, skal

tilpasse/udvikles.

· CCS følger en anden

klassifikationsfilosofi end visse andre

klassifikationsstandarder. OmniClass

(og DBK2006) anvender generelt en

mere detaljeret klassifikation. Uanset

om dette klassifikationsniveau er

hensigtsmæssigt eller ej, er det

besværligt at mappe mellem to

klassifikationssystemer med så

forskellige klassifikationsniveauer.

(Retfærdigvis skal det nævnes, at det

også kan være besværligt at mappe

mellem to klassifikationssystemer med

meget detaljeret klassifikation – nemlig

hvis de detaljerede klasser er meget

forskellige mellem de to standarder.)

Det anbefales, at designet af CCS

kodningsregler ikke lukkes, før

klassifikation vha. egenskaber er

designet og opgavens omfang for

cuneco og branchens virksomheder er

vurderet.

147 NCC Generel Vi værdsætter, at der er lyttet til

kritikken af DBK2006 og tidligere

arbejdsversioner af CCS, og at CCS

gennem sin større fleksibilitet

imødekommer en række af de behov,

der har været nævnt.

Bliv ved med at lytte. Noteret

148 NCC Generel De formulerede krav til CCS er

omfattende, og løsningen er ambitiøs –

måske for ambitiøs. Der er reelt tale om

flere delstandarder indenfor samme

standard.

Pas på med ambitiøsiteten. Noteret

149 NCC Generel DBK2006 er også kompleks, når man

tager flere/alle aspekter i anvendelse,

men her har produktaspektet en

dominerende stilling. Alle skal anvende

dette, mens de øvrige aspekter er

frivillige. Sådan er det ikke i CCS, så vidt

vi har forstået: Her er alle aspekter

frivillige, men man skal selvfølgelig

anvende mindst ét aspekt.

Er der en regel, der siger, at alle

aspekter er frivillige, men at mindst ét

aspekt skal anvendes? Hvis ikke (og hvis

dette i øvrigt er korrekt), bør man

tilføje sådan en regel.

Måske er det ikke så simpelt. Kan man

f.eks. anvende placeringsaspektet uden

at anvende det strukturelle

produktaspekt (eller måske det simple

produktaspekt)?

Accepteret Dette præciseres i rapporten.

150 NCC Generel Prisen er en standard, der samlet set er

mere kompleks. Det er rigtigt, at man

gennem anvendelse af et/få aspekter

kan forsimple sin anvendelse af

standarden væsentligt i forhold til

DB2006.

Men virksomheden/byggeprojektet skal

igennem en ikke helt enkel proces for at

forstå standarden og for at udvælge de

dele, der skal tages i anvendelse.

Tilsvarende har den IT-producent, der i

sit standardsystem vil implementere

hele eller store dele af CCS, en stor

opgave.

Der er en reel risiko for, at standardens

udbredelse og IT-implementering

hæmmes pga. kompleksiteten.

Vi peger på nogle få forenklinger i de

følgende kommentarer.

Men grundlæggende følger

kompleksiteten og omfanget af krav,

ambitionsniveau og overordnet filosofi

for CCS.

Hvis man holder fast i dette, er

indsatsen primært af pædagogisk og

hjælpende art:

· Let forståelig dokumentation –

CCS for Dummies – afprøv både

standarden og dokumentationen

· Vejledninger f.eks. i hvordan man

udvælger de dele af CCS, man vil

anvende.

· Kurser, støtte

· Gennemskuelig og pålidelig

understøttelse i standard IT-systemer

Noteret cuneco finder de foreslåede løsninger

til, hvordan forståelsen af systemet kan

understøttes meget konstruktive og

anvendelige, og det er givetvis noget

der vil tages i anvendelse. cuneco finder

det centralt at beskrive koblingen

mellem formålet med at klassificere og

de dele, der anvendes i forhold til det

konkrete formål, da det kan hjælpe

brugeren (og IT-leverandøren) med at

fokusere på den del af systemet, der er

relevant for ham.

151 NCC Generel Med den store fleksibilitet i

anvendelsen af CCS følger, at to parter,

virksomheder, projekter, … der begge

anvender CCS, ikke nødvendigvis kan

kommunikere effektivt med hinanden.

Eks.1: En installationsingeniør, der kun

anvender det strukturelle

produktaspekt, kan f.eks. ikke

kommunikere sine identifikatorer for

bygningsdele til en entreprenør, der

kun anvender det simple

produktaspekt.

Eks. 2: En arkitekt placerer døren

direkte i vægsystemet, men

konstruktionsingeniøren placer den i

vægkonstruktionen, der er placeret i

vægsystemet. En udfordring, hvis de

samarbejder i samme byggeprojekt.

Parterne kommunikerer heller ikke

nødvendigvis deres bygningsdelsklasser

og rumklasser særlig effektivt med

hinanden.

Vi har ikke nogen gode løsningsforslag.

En mulig, men skræmmende, løsning

er, at man for det enkelte byggeprojekt

beslutter, hvordan CCS skal anvendes.

At der indgås en projektspecifik CCS-

aftale (analog med en IKT-aftale). Det

stiller store krav til den enkelte parts

omstillingsevne, og kan føre til at han

stort set skal mestre hele standarden.

Vi hører meget gerne om bedre

løsninger.

Delvist

accepteret

Anvendelsen af CCS koder afhænger til

dels af de projektspecifikke aftaler fx i

en IDM manual (informationsniveauer)

aftales.

Ad eks. 2.)

Ikke accepteret.

En dør kan ikke placeres i (være en del

af) en vægkonstruktion.

152 NCC Afsn. 6

side 17

Redaktio

nel

Der står

”CCS koder to grundlæggende objekter:

bygningsdele og rum.”

Bør der ikke stå:

”CCS koder tre grundlæggende

objekter: systemer, bygningsdele og

rum.”,

og lade afsnittet dække de tre

objekter?

Hvis det er forstået rigtigt, er der vist

mange steder, hvor ”systemer” skulle

være nævnt sammen med bygningsdele

og rum.

Ikke

accepteret

Bygningsdele kan håndteres i

overordnede systemer af bygningsdele.

System(er) er ikke et objekt i sig selv.

153 NCC Afsn.

7.1.4

side 23.

Generel Der står:

”NOTE: Det skal bemærkes at der i

klassifikationsaspektet er mulighed for

at lave en projektspecifik

underklassifikation af CCS-

klassifikationen, og at disse

underklasser fx kan opbygges af tal.”

Skal underklassen ikke opbygges af tal?

Hvis svaret på spørgsmålet er ja, rettes

til ”… og at disse underklasser skal

opbygges af tal.”

Der er et (måske mindre

betydningsfuldt) brud på logikken her. I

de andre aspekter anvendes tal til at

angive løbenumre.

Delvist

accepteret

Anvendelsen af tal præciseres således

at anvendelsen af tal i det nævnte

aspekt fremgår mere tydeligt.

154 NCC Afsn.

8.2.3

side 31-

33

Teknisk Vedr. funktionsaspektet:

Man skal tilsyneladende bruge det

strukturelle produktaspekt både for

den objektforekomst (system eller

bygningsdel), man vil tildele funktionel

klassifikation, og den objektforekomst i

bygningens funktionsstruktur, man vil

tilknytte. Det virker ulogisk og

begrænsende. Hvis det er vigtigt at

kunne angive funktion for

systemer/bygningsdele, er det vel lige

vigtigt, uanset om man anvender

simpel identifikation eller

kompositionel identifikation. Man kan

tilsyneladende ikke skrive:

#JB52 / =JB7 :

Dør nr. 52 har funktionskrav som

specificeret for funktionel dør nr. 7.

Vi er med på, at den foreslåede syntaks

i rapporten ikke kan klare dette, fordi

aspekttegnet = hermed får to

betydninger. Men hvis det er vigtigt, må

man udvikle syntaksregler, der dækker

behovet.

Delvist

accepteret

Anvendelse af funktionsaspektet for

bygningsdele (=) tydeliggøres.

155 NCC Afsn.

8.2.5

side 38

/39

Teknisk Vedr. placeringsaspektet:

Man skal tilsyneladende bruge det

strukturelle produktaspekt både for

den objektforekomst (system eller

bygningsdel), man vil placere, og den

objektforekomst, man vil placere i. Det

virker ulogisk og begrænsende. Hvis det

er vigtigt at kunne angive placering, er

det vel lige vigtigt, uanset om man

anvender simpel identifikation eller

kompositionel identifikation. Man kan

tilsyneladende ikke skrive:

#SFA47 / +LUD65 :

Afbryder nr. 47 placeret i plade nr. 65

Vi er med på, at den foreslåede syntaks

i rapporten ikke kan klare dette, fordi

aspekttegnet + hermed får to

betydninger. Men hvis det er vigtigt, må

man udvikle syntaksregler, der dækker

behovet.

Delvist

accepteret

Anvendelse af placeringsaspektet for

bygningsdele (+) tydeliggøres yderligere

i rapporten.

156 NCC Afsn.

8.3.4

side 45

Generel Her introduceres objekttyperne

Bebyggelse, Bygning og Etage uden

videre. Læseren er ikke velforberedt.

Det virker som nogle ”sidste-øjebliks-

tanker”.

Forbered, beskriv, definer disse

objekttyper på lige fod med de øvrige,

der behandles i rapporten

Accepteret Henvisning til ISO 4157 indsættes.

157 NCC Afsn.

8.3.4

side 45

Redaktio

nel

Skal det angivne aspekttegn efter

sætningen

”Syntaksen for aspektkoden ser derfor

således ud” ikke være ”-” (i stedet for

”=”).

Man bemærker, at identifikation af

bygninger sker uden brug klassekode

sammenstillet med løbenr.

<- Se Accepteret (=) rettes til (--).

158 NCC Teknisk Hvordan bør man vurdere CCS’ IT-

egnethed?

Det er glædeligt, at en række

kompetente IT-leverandører har været

involveret i udviklingen og

kommenteringen af CCS, og at de siger

”CCS kan implementeres i vores IT-

systemer”.

Det er en nødvendig, men langt fra

tilstrækkelig forudsætning, at

kompetente og ressourcestærke IT-

producenter siger god for standarden.

Langt størstedelen af de IT-folk, der

kommer til at arbejde med CCS,

kommer imidlertid fra interne IT-

afdelinger i byggebranchens

virksomheder. IT-afdelingerne kan være

store, men ofte består afdelingen af

nogle få medarbejdere – måske kun en

enkelt – som har få ressourcer til at

lære og til at implementere CCS i

virksomhedens IT-systemer.

Dertil kommer, at størstedelen af IT-

understøttelsen af CCS kommer til at

ske i andre systemtyper end de store

standard-CAD/BIM-systemer med god

udbredelse på det danske marked. Det

drejer sig om: Kalkulationssystemer,

sagsstyringssystemer,

økonomisystemer/kontoplaner, data

warehouse-systemer, rumprogram-

databaser, planlægningssystemer osv.

IT-egnetheden må ikke kun vurderes af

en begrænset skare af ressourcestærke,

kompetente producenter af standard

IT-systemer.

Repræsentanter fra de øvrige grupper

af IT-folk, og fra IT-brugerne, skal også

komme med deres vurdering og denne

skal indgå i den samlede bedømmelse

af CCS’ IT-egnethed.

Noteret De scenarier, der beskriver anvendelsen

af CCS vil beskrive hvilke dele af CCS,

der skal anvendes i konkrete

sammenhænge og dermed hvilken

delmængde af CCS, de enkelte IT-

leverandører skal implementere i deres

systemer. Dette vil gøre opgaven mere

overskuelig.

En stor del af systemerne vil være

standardsystemer med ringe

udbredelse på det danske marked (dvs.

producentens indtægtsgrundlag til at

dække omkostninger til CCS-

understøttelse er meget begrænset).

Endnu en stor del af systemerne vil

være systemer, udviklet af

virksomhedernes interne IT-afdelinger,

med deres ofte begrænsede ressourcer

og typisk store backlog af (ndre)

ændringskrav fra brugerne.

Endelig kommer CCS-koder til at

optræde i office-programmer som Excel

og Word. Brugerne af office-

programmerne er os selv, med den

begrænsede indsigt i teknisk IT, som de

fleste af os har.

159 NCC Teknisk CCS skal være særdeles IT-egnet, hvis

standarden skal udbredes i branchens

IT-systemer, jf. foregående punkt.

Efter vores mening er det ikke let at

bruge CCS i IT-systemerne.

CCS-koden er meget fleksibelt

opbygget. Det fører til en høj grad af

”positionsløshed”. Antallet af bogstaver

på hvert niveau kan variere. Antallet af

cifre i underklasser og løbenumre kan

variere. Foranstillede nuller er ikke et

krav. Antallet af niveauer i

referencestrukturen kan variere (fordi

man ikke behøver at medtage

mellemliggende niveauer).

Det fører til banale, men store praktiske

problemer med at sortere, filtrere, søge

… Desuden bliver fortolkningen af CCS-

koden i applikationssystemerne

vanskeligere.

Dertil kommer, at inddragelse af

egenskaber i det samlede

klassifikationskoncept kan føre til

omfattende systemændringer, jf.

tidligere.

En løsning kan være, at den enkelte

virksomhed definerer sin egen

husstandard for, hvordan CCS-koden

skal bygges op. Men det holder

sandsynligvis kun til det øjeblik, man er

nødt til at kommunikere sine CCS-koder

med andre virksomheder (med andre

husstandarder for CCS).

Her er et eksempel på en mere

håndfast løsning:

• Der skal altid være det samme antal

bogstaver på et givet niveau (inklusiv

typer). Nedenfor forudsættes tre tegn.

• Eksempel: Vægsystem klassificeres

som MB_ – MB for ”vægsystem” og _

(underscore) for ”ingen speciel type

vægsystem”, og MBA – MB for

”vægsystem” og for ”ydervæg” osv.

Dette i stedet for MB for vægsystem

uden nogen speciel type.

• Hvis man har tænkt at opretholde to

niveauer af typer gælder det naturligvis,

at der også skal afsættes fast plads til

dette – og dermed være fire tegn på

hvert niveau

Ikke

accepteret

Kodens opbygning med præfiks,

bogstaver, tal og skilletegn er entydig,

og kan tolkes af IT-systemer efter en

veldefineret regel.

160 NCC Generel CCS skal være særdeles IT-egnet, hvis

standarden skal udbredes i branchens

IT-systemer, jf. foregående punkt.

Man kan forestille sig, at IT-opgaven

forenkles ved at IT-producenter (og

cuneco/bips) udvikler forskellige

tekniske hjælpemidler, som stilles til

rådighed for branchen. F.eks. en

generel fortolker af CCS-kodestrengen.

Denne kunne leveres som plug-in til

forskellige, udbredte programmer,

f.eks. office-programmer. Det kan

hjælpe, men vil ikke fjerne problemet.

Noteret Dette ønske er noteret og cuneco vil

bestræbe sig på, at der bliver etableret

en tjeneste som beskrevet på BDS.

161 NCC Generel Implementering af CCS i et standard IT-

systemer kan ske på mange måder.

Man kan ikke, når man hører, at et

bestemt IT-system understøtter CCS,

vide, hvordan CCS er understøttet.

Der er behov for, at forskellige typer af

IT-systemer implementerer CCS med

fornøden og gennemskuelig kvalitet og

ensartethed. Der er desuden behov for,

at der for et konkret IT-system præcist,

ensartet og enkelt beskrives, hvilke dele

af CSS, der er implementeret i

systemet.

(Dette behov findes også for DBK2006,

men det er større med CCS pga. den

større fleksibilitet i standarden.)

Der bør udvikles et sæt entydige

retningslinjer for, hvordan CCS skal

implementeres i IT-systemer, herunder

hvilke dele, der skal implementeres og

hvilke dele, der er frivillige.

Herudover er der behov for, at en

kompetent og uvildig instans overvåger

og kontrollerer CCS-implementeringen i

branchens standard IT-systemer. Der

skal – efter godkendelse – udstedes et

certifikat for den konkrete version af IT-

systemet, der dokumenterer, at CCS er

implementeret korrekt, samt hvilke

dele af CCS, der er implementeret. Ved

nye versioner af IT-systemet skal

certifikatet fornyes.

Denne instans kan desuden yde bistand

til virksomheder med egenudviklede IT-

systemer.

Noteret Det er cunecos holdning at de enkelte

dele af CCS skal kobles til de praktiske

formål, som klassifikationen skal

anvendes til - og dermed også til

funktionaliteten i IT-systemerne. Dette

vil igen hænge sammen med en

kravstillelse, der er formålsorienteret.

En godkendelsesinstans er en god idé,

men der er ansvarsmæssige

implikationer, der skal overvejs nøje.

162 NCC Teknisk Identifikatorer for objektforekomster

skal ubetinget kunne holdes

uforanderlige.

Identifikatorerne i både det simple (#)

og det strukturelle (-) produktaspekt er

afhængig af objektforekomstens

klassekode. I det strukturelle

produktaspekt er identifikatoren

desuden afhængig af identifikatoren

(klasse + løbenr.) for de overliggende

objektforekomster i

kompositionsstrukturen.

Det fører uvægerligt til at

identifikatoren ikke med sikkerhed kan

holdes konstant.

Det fører også til krav om klassen ikke

må ændres for en objektforekomst, og

det heraf afledte krav, at CCS skal

klassificere på et relativt højt niveau.

Begge dele uheldige, som nævnt ovf.

Udform et identifikatorbegreb, der er

uafhængigt af andre egenskaber for

objektforekomsten eller for andre

objektforekomster.

Man behøver ikke kaste sig ud i GUID-

identifiers for at opnå dette. Det simple

produktaspekt kunne f.eks. blot tildeles

en 6-tegns kode. Det giver et antal

mulige identifikatorværdier på mindst

346. Eller 1 mio, hvis man kun vil

anvende cifre.

Ikke

accepteret

Den foreslåede CCS opfylder de krav

som der er stillet til løsningen for

kodeprincipperne.

Dette er beskrevet i rapporten, og er

måden som CCS koderne virker på.

CCS forholder sig ikke til antallet af cifre

i hver kodedel og vil /bør ikke

standardiseres, da antallet af cifre også

afhænger af størrelsen på den enkelte

projekter (store projekter = større antal

løbenumre, små projekter = lille antal

løbenumre).

163 NCC Teknisk Vi forstår godt baggrunden, men det

virker ikke logisk og hensigtsmæssigt, at

en objektforekomst kan have to

identifikatorer (i det simple og det

strukturelle). Hvorfor er der flere

identifikatorer i standarden?

Kan standarden nøjes identifikation i #-

aspektet?

Vi kan godt se, dette vil føre til et tab,

hvis man vil have CCS-koden til at

angive bygningsdelsforekomstens

(rumforekomstens) kompositionelle

placering indenfor overliggende

forekomst(er).

Delvist

accepteret

De to muligheder for identifikation

dækker forskellige behov, og det er

frivilligt hvilken man benytter (evt.

begge). Man kan derfor nøjes med én

identifikation.

Der udarbejdes et skema i rapporten

der viser de forskellige

kombinationsmuligheder ved

anvendelse af de forskellige aspekter

samt begrænsningerne ved udeladelse

af bestemte aspekter.

164 NCC Afsn. 10,

s. 54 og

frem

Teknisk Vi er meget skeptiske overfor

rapportens input til selve

kodningsarbejdet. Her anbefales, at

man benytter bogstaverne og

klassifikationen fra ISO/IEC 81346, og at

man så lægger de dele som denne

standard ikke dækker (dvs. de

konstruktive bygningsdele) ind på de

ledige bogstaber (vist kun 3 bogstaver).

Dette mener vi er uacceptabelt:

· Vi kan ikke styre hvad der sker

med ISO/IEC standarden. Den kan på et

senere tidspunkt vælge at lave

væsentlige ændringer eller at tage de

ledige bogstaver i brug til noget andet

end det CCS på eget initiativ bruger

dem til.

· Vi mener at det vil give en meget

skæv klassifikation hvor man på det

øverste niveau bruger mange bogstaver

på at dække installationer og kun

ganske få til de øvrige områder. Der er

ikke noget logisk/teknisk i vejen for det,

men det kan være forkert

behovsmæssigt og vil i hvert fald være

uheldigt formidlingsmæssigt.

Ikke dermed sagt at man ikke kan bruge

hele eller dele af ISO/IEC

klassifikationen i CCS, men det skal i

givet fald være i en indkapslet del, hvor

CCS har kontrollen og sætter

rammerne, ikke omvendt. Se

”Foreslåede ændring”.

Der bør udvikles en generel

mekanisme, der tillader andre

standarder at blive adopteret i

værtsstandarden CCS. Den fremmede

standard skal på en eller anden generel

måde indkapsles (måske med et

præfix?), så dens koder ikke clasher

med eller begrænser kodeanvendelse i

værtsstandarden, CCS, eller i andre

standarder, som værtsstandarden har

adopteret. IEC skal have lov til at

anvende sine koder. Men det skal

klassifikationen af konstruktive og

andre ikke-mekaniske/elektriske

systemer/bygningsdele også.

Denne adoptionsmekanisme skal være

generel. Dvs. den skal ikke kun gælde

systemer, bygningsdele og rum, men

alle objekttyper, som CCS i fremtiden

kommer til at dække, f.eks. også

objekttyper indenfor

ressourcedomænet.

Det bliver måske ikke (forhåbentlig

ikke) sidste gang, CCS bliver vært for

andre standarder. Hvad med f.eks.

· Standard(er) for anlæg

· Standard(er) for byggevarer

(ressourcedomænet). Vi har tidligere

anbefalet, at man her kigger på de

etablerede standarder, frem for at

udvikle selv (stort arbejde, stor risiko

for at byggevareproducenterne ikke vil

følge).

Noteret I forbindelse med cunecos projekt vedr.

afklaring af klassifikationsniveau for

bygningsdele pågår der i øjeblikket et

arbejde, hvor inddelingen og kodning af

klasser laves med udgangspunkt i

klassifikationsbehovene for de

relevante områder. I den forbindelse vil

de relevante standarder blive

inddraget.

165 NCC Generel Ovenstående fører til det generelle krav

->

Klassifikationsstandardens grunddesign

skal være af en sådan karakter, at der i

fremtiden ikke lægges væsentlige

begrænsninger på

udvidelsesmuligheder. Standarden skal

være langtidsholdbar, og vi kender ikke

fremtidens behov.

Der skal være mulighed for at udvide

klassifikationen både i bredden (nye

objekttyper, nye klasser indenfor

kendte objekttyper) og i dybden

(underklasser til underklasser til …).

Noteret Kommentaren videregives til

arbejdsgruppen der bearbejder

klassifikationen for bygningsdele og

rum.

166 NCC Teknisk Vi har behov for mapning fra DBK-

bygningsdelskoder (i produktaspektet)

til CCS-koder (i det strukturelle

produktaspekt).

Vi har behov for, at information ikke går

tabt i denne mapning. I det omfang,

CCS-koderne er mere generelle end

DBK-koderne skal

overskudsinformation i DBK-koden

tydeliggøres i et passende sæt

egenskabsdata.

Vi har behov for at mappingtabeller er

klar samtidig med frigivelse af denne

del af CCS.

Noteret

167 NCC Generel Vi er bekymrede for, at al størstedelen

af udviklingskraft endnu en gang går i

klassifikation af bygningsdele. Hvad

med objekter/begreber i

ressourcedomænet – som først lige er

ved at blive analyseret.

Opprioriter det cuneco-projekt, der skal

afdække behov indenfor

ressourcedomænet. Der er en reel

risiko for, at der endnu en gang hverken

bliver tid eller ressourcer nok til at gøre

noget særligt indenfor dette område.

Cunecos deadline ligger kun godt 2 år

ude i fremtiden.

Noteret Ressourcedomænet er genstand for et

selvstændigt projekt, og den

pågældende projektgruppe er p.t. i

færd med at beskrive behovet for en

indsats på dette område. Styregruppen

vil inddrage denne kommentar i

forbindelse med behandlingen af

gruppens oplæg.

168 NCC Generel NCC, og andre virksomheder indenfor

anlæg, har et behov for en veludviklet

klassifikation indenfor anlægsområdet.

Det gælder både

· Objekttyper indenfor

resultatdomænet. DBK2006 har nogle

ganske få anlægstyper indenfor

bygningsdele og rum, men de er langt

fra dækkende.

· Objekttyper indenfor

ressourcedomænet, specielt

entrepriser rettet mod anlæg.

I første omgang skal kodningsreglerne

for systemer, bygningsdele og rum

(egentlig de tilsvarende

hovedobjekttyper indenfor anlæg)

udformes, så de tilgodeser behovene

indenfor anlægsområdet.

Herudover vil vi opfordre til, at der

igangsættes projekter til udvikling af

objekttyper, klassifikationsdybde,

klassetabeller, egenskabsdefinitioner

osv. indenfor anlæg. Som nævnt både i

resultat- og ressourcedomænet.

Noteret cuneco har fået til opdrag at udvikle

standarder, der dækker hele det

byggede miljø i forhold til alle faser.

Gruppen der p.t. kigger på Klassifikation

af bebyggelser, bygninger og rum skal

også inddrage anlæg, veje, parker,

broer etc.

169 NCC Afsn. 9,

side 48

Teknisk I trin 5 står

”Da det er relevant at vide hvilken

vægkonstruktion i vægsystemet døren

skal monteres i, tildeles dørens

objektforekomst en reference for

placeringen i konstruktionsrummet:

-JB2:MB3 / +DF3:MB3

Koden læses: Dør nr. 2 i Vægsystem nr.

3 placeret i Vægkonstruktion nr. 3 i

Vægsystem nr. 3”

Hvorfor er der behov for denne kodning

i placeringsaspektet?

Kan man ikke bare sige, at døren indgår

i vægkonstruktion nr. 3, dvs. nøjes med

-MB3.DF3.JB2 ?

Når den kompositionelle struktur er

den samme som den

placeringsmæssige, er den

placeringsmæssige vel overflødig?

Ikke

accepteret

1.) Reglen er, at produktaspektet (-)

identificere selve objektet (her: dør),

mens placeringsreferencen er en

”kryds-reference” til et andet objekt,

dvs. hvilket andet objekt som selve

objektet er placeret i. Dette muliggør

referencer på tværs af systemer (fx fra

et el-system til et vægsystem).

2.) Eksemplet ”… døre indgår i

vægkonstruktion nr. 3 dvs. nøjes med -

MB3.DF3.JB2” er forkert, da en dør ikke

er en del af en vægkonstruktion, men

en del af et vægsystem, på lige fod med

en vægkonstruktion.

170 NCC 13 Bilag

A side

67

Teknisk Citat:

”Objekt (byggeobjekt)

En fysisk bestanddel – eller tænkt fysisk

bestanddel - af en bygning med alle

dens iboende egenskaber, relationer til

omkringliggende byggeobjekter samt

øvrig relateret information.”

Det er forhåbentlig ikke korrekt.

CCS skal også beskæftige sig med ikke

fysiske objekter. Eksempler:

· Faser/processer/aktiviteter

· Roller

· Entrepriser (der nok rummer

fysiske objekter, men ikke selv kan

karakteriseres som et sådant)

Ikke

accepteret

Kodningsprojektet omhandler objekter i

ISO 12006-2’s resultatdomæne, hvor

objekterne bygningsdele og rum

henføres til, og som den anførte

definition omhandler.

De nævnte begreber ”faser, roller,

entrepriser” m.v. er ikke objekter i

resultatdomænet.

171 NCC Generel Afprøvning er vigtig. I Gødstrup bør man sikre sig, at alle

aspekter bliver afprøvet, både indenfor

bygningsdele og rum. Man bør ligeledes

afprøve et stort udvalg af klasser både i

bredden og dybden.


afprøvningsprojektet.

172 NCC Generel De dele af CCS, der kommer fra IEC/ISO

81346 (mekaniske og elektriske

systemer/bygningsdele) skal være af

nogenlunde samme natur som de dele

der er udviklet for konstruktive

bygningsdele, f.eks. mht. aspekter,

klassifikationsniveau, detaljeringsgrad i

bygningsdele, …

Vi kender ikke IEC-standarden.

Er det tilfældet?

Noteret Svar: ja, de er af samme ”natur”.

173 NCC Teknisk Bilag B: Vi værdsætter beskrivelsen af

CCS i metasprog. Vi har ikke forstand på

EBNF, men det ser ud som om

beskrivelsen ikke er færdigudviklet.

Beskrivelsen af kodesyntaksen (ikke kun

for bygningsdels- og rumkoder) skal

være en fuldgyldig del af standarden.

Få en metasprog-ekspert til at

udarbejde specifikationen, hvis cuneco

ikke råder over en sådan. Lyt til

eksperten, hvis han påpeger manglende

logik, tvetydigheder osv. så er det

formentlig fordi der er problemer, med

strukturen, som bør løses.

Noteret cuneco har noteret, at relevante

eksterne kompetencer skal inddrages i

denne sammenhæng.

174 NCC Generel Hvad er strategien med

forvaltningsklassifikation. Skal der

udvikles mapping mellem CCS og den

udviklede

Forvaltningsklassifikationsstandard?

Skal den udviklede

Forvaltningsklassifikationsstandard

adopteres i CCS (analogt med IEC/ISO

81 346-2, hvis det kan lade sig gøre)?

Eller skal der udvikles ny

forvaltningsklassifikation i CCS?

Noteret Strategien mht. til FK er beskrevet

ovenfor i svaret på kommentar nr. 67.

175 NCC Teknisk Lokale udvidelsesmuligheder Man bør kunne tilføje

virksomhedsspecifikke eller

projektspecifikke klasser for

bygningsdele (og måske også rum), ikke

kun underklasser til eksisterende CCS-

klasser.

Der bør udvikles en generel mekanisme

for tilpasning af CCS til virksomheden

eller projektet?

Noteret Dette er en del af rapporten, se afs. 8.4.

Se også NCC-10.

176 NCC Teknisk Vi har problemer med at forstå

begrebet ”klassifikationstema”.

Kunne man definere begrebet, og

eksplicit angive de

klassifikationstemaer, der konkret

anvendes rundt omkring? I det omfang,

det ikke allerede er sådan.

Accepteret ”Klassifikationstema” defineres i

rapporten.

177 NCC Teknisk Vi forstår ikke begrebet

”funktionsstruktur” og dermed heller

ikke funktionsaspektet.

Kunne man definere

”funktionsstruktur” og gerne uddybe

med forklaring og eksempel på en

sådan struktur.

Accepteret Begrebet og dets anvendelse

præciseres og eksemplificeres.

178 NCC Teknisk De IT-producenter, der har deltaget i

vurdering af IT-egnetheden, er primært

producenter, der ETABLERER

klassifikationskoder. Der er

tilsyneladende ikke nogen, der læser og

fortolker CCS-koder, som er etableret af

fremmede systemer

Inddrag også IT-producenter, der kan

vurdere om CSS koden kan fortolkes.

Fortolkning kan være en mere

kompleks opgave end etablering af

koden. Særlig i et system, der er så

fleksibelt i sin kodeopbygning som CCS.

Ved kode generering (afsender), kan

man lave sin egen standard inden for

standarden. Det kan man ikke, når man

fortolker (modtager). Her skal man

kunne håndtere alle de mulige

kombinationer, som standarden

tillader.

Noteret

179 NCC Redaktio

nel

Vi synes generelt, at terminologien

omkring klassifikationsaspektet og det

simple produktaspekt antyder, at de to

aspekter er lidt inferiøre.

(Tilsvarende de to punkter ovf. Der

omhandler, at det simple

produktaspekt vist ikke kan anvende i

placeringsaspektet og

funktionsaspektet.)

Brug en ligeværdig terminologi. Delvist

accepteret

En alternativ terminologi overvejes ved

revision af rapporten.

Se også svar til høringskommentar 166.

180 Simon

Friberg

Jeg vil

på

forhånd

beklage

at jeg

ikke kan

være

mere

præcis,

da det

ville

tage for

meget

tid og

ekstra

research

for mig

da jeg

ikke

forsker i

Videnso

rganisat

oriske

brudflad

er til

daglig.

Generel Det er meget vel og godt at tænke i

stabilitet og globalisering men hvis det

er et klassifikationssystem der skal have

en kvalitet med verdensklasse er der,

udfra min synsvinkel, nødt til at være

nogle biblioteks/vidensorganisatorisk

faglighed ind over kodereglerne i

særdeleshed og systemet i

almindelighed.

Ved gennemgang af høringsrapporten

for CCS kodningsregler, forekommer

det mig tydeligt at CCS vil kunne blive

mere smidigt og stabilt uden at gøre

køb på kravet om internationalisering.

To krav der lader til at begrænse målet

når de begge burde/kunne være

innovationsmotorer i udformningen af

koderegler/principper til CCS.

Jeg anbefaler en gennemgang af

systemets dele/mål/opbygning/regler

foretaget af en

informationsvidenskabelig forsker der

arbejder med klassifikationsteoretiske

analyser. Dem findes der et mere end

par stykker af på Informations

Videnskabeligt Akademi, Birger

Hjørland eller Pia Borlund ville være et

fint sted at starte.

Jeg er da også villig til at lede videre for

jer efter eksperter der kan gennemse

og kommentere mere præcist og fagligt

end jeg måske ville kunne.

Det er jo ikke utænkeligt at andre

fagligheder, forskere i

Informationsarkitektur eller

videnorganisation i bredere forstand fx,

kunne sættes ind på opgaven for at

stille de gode og for dem indlysende

spørgsmål, der i sidste ende skaber

skaber det holdbare og prøvede

regelsæt til systemet.

Noteret cunecos styregrupe vil medtage

forslaget i det videre arbejde.

181 Henrik

Bang,

Bygherr

eforenin

gen

Generel Overordnede kommentarer

Overordnet finder Bygherreforeningen

det kursskifte, der er sket fra DBK,

meget positivt – herunder det fokus på

tre mekanismer klassifikation,

specifikation og ID-systematik som

præger CCS. Det virker rigtigt at starte

med håndtering og klassifikation af rum

og bygningsdele – for herefter at

overveje andre objekter (såsom

mandskab, materialer, materiel,

metoder, processer og organisation).

Endvidere finder vi det meget positivt

med udmeldingen om mapping mellem

CCS og Forvaltningsklassifikation.

Vi finder at der med det foreliggende

høringsforslag er åbnet for en frugtbar

diskussion om formålet med at

klassificere rum og bygningsdele, men

også at der stadig savnes en bredere

anlagt beskrivelse af formålet med og

værdiskabelsen i klassifikation set i lyset

af det paradigmeskift som byggeriets

samarbejdsformer, metoder og

værktøjer undergår i disse år.

Udover håndtering og klassifikation af

rum og bygningsdele – overveje andre

objekter (såsom mandskab, materialer,

materiel, metoder, processer og

organisation).

Behov for en bredere anlagt beskrivelse

af formålet med og værdiskabelsen i

klassifikation set i lyset af det

paradigmeskift som byggeriets

samarbejdsformer, metoder og

værktøjer undergår i disse år.

Noteret Formålet med den fremlagte

kodestruktur er at kunne klassificere og

identificere bygningsdele og rum, som

findes i ISO 12006-2 resultatdomæne.

De øvrige objekter der nævnes

(mandskab, materialer, metoder etc.)

ligger i ressourcedomænet og

procesdomænet i ISO 12006-2, og er

ikke en del af kodeprojektet for

bygningsdele og rum.

182 Henrik

Bang,

Bygherr

eforenin

gen

Generel International standardisering

Hvad angår international

standardisering kan vi konstatere, at

man vælger et spor (EN 81346) ud af tre

mulige – og skal pege på den mulige

fare for isolation i den danske

byggesektor, hvis man i udlandet går

andre veje. Det bør undersøges nøje,

om det foreliggende forslag er

kompatibelt med ISO 12006-2 hhv. IFC,

IFD og IDM (de to andre spor).

Undersøgelse af, om det foreliggende

forslag er kompatibelt med ISO 12006-2

hhv. IFC, IFD og IDM (de to andre spor).

Delvist

accepteret

Det fremlagte forslag er ikke i konflikt

med de nævnte standarder, og

understøtter disse. Dette tydeliggøres i

rapporten.

183 Henrik

Bang,

Bygherr

eforenin

gen

Generel Princip og metode for klassifikation

Til at belyse klassifikation kan det være

en god ide at benytte views som

princip, som forslaget bygger på. Men

som generelt princip har den valgte

løsning en række uheldige

konsekvenser, idet kun et stærkt

begrænset antal views tillægges en

særlig betydning (uden at det er

dokumenteret, at der er særligt brug

for dem), mens det ikke nævnes,

hvordan andre lige så relevante views

kan indarbejdes (fx ”fag” og ”arbejder”

views for byg- og driftsherrer). Som

alternativ til at pege på tre views bør

det overvejes at udvikle en metode til

håndtering af anvendelsen af views –

ikke kun i forbindelse med

klassifikation, men mere generelt til

støtte for informationshåndteringen.

Det bør overvejes at udvikle en metode

til håndtering af anvendelsen af views –

ikke kun i forbindelse med

klassifikation, men mere generelt til

støtte for informationshåndteringen.

Det bør overvejes at opgive

referencesystematikken som et fælles

grundlag for bygningsklassifikationen –

og i stedet satse på at udarbejde en

vejledning i konkret anvendelse af EN

81346.

Noteret cunecos strategi om at anvende en

overordnet klassifikation og supplere

dette med en struktureret anvendelse

af egenskabsdata er bl.a. lavet ud fra et

ønske om kunne håndtere objekter i

forhold til en lang række forskellige

formål, der ikke alle kan dækkes af den

samme klassifikation. Dette mener

cuneco er helt konsistent med det

beskrevne ønske og en del af formålet

med egenskabsdataarbejdet vil være at

beskrive, hvordan sæt af egenskaber

defineres i forhold til specifikke formål.

De øvrige objekter der nævnes inden

for fag, arbejder m.v ligger i

ressourcedomænet og procesdomænet

i ISO 12006-2, og er ikke en del af

kodeprojektet for bygningsdele og rum.

Referencesystematikken (del-af) er ikke

grundlag for klassifikation af

bygningsdele i CCS, hvorfor

bemærkningen om at "opgive

referencesystematikken som fælles

grundal for bygningsklassifikation" i

princippet er imødekommet. Det

fremlagte forslag for kodestruktur

tillader en fleksibel anvendelse,

herunder "ren" klassifikation uden

nogen form for referencestruktur.

Dette beskrives mere klart i revisionen

af rapporten.

184 Henrik

Bang,

Bygherr

eforenin

gen


Desuden savner vi en beskrivelse af,

hvordan arbejdet med modelbaserede

værktøjer og IKT-baseret

informationshåndtering skal

understøttes af enten

klassifikationstabeller eller af

specifikation med udfoldede

egenskabsdatasæt – eller begge dele.

Med rigdommen af egenskaber for selv

de enkleste byggeobjekter, er det

vanskeligt at forestille sig en

klassifikationssystematik med lige så

mange klassifikationstabeller eller

facetter, som der kan etableres

relevante views.

Behov for en beskrivelse af, hvordan

arbejdet med modelbaserede værktøjer

og IKT-baseret informationshåndtering

skal understøttes af enten



egenskabsdatasæt – eller begge dele.

Noteret Beskrivelsen vil løbende blive udviklet i

forbindelse med cunecos arbejde med

egenskabsdata og informationsniveuaer

samt afdækningen af behov og

værdiskabelse i branchen.

185 Henrik

Bang,

Bygherr

eforenin

gen


Det bør overvejes at opgive reference-

systematikken som et fælles grundlag

for bygningsklassifikationen – man

kunne i stedet satse på at udarbejde en

vejledning i konkret anvendelse af EN

81346 som alternativ.

Delvist

accepteret

Kravet om at kodestrukturen skal

indeholde en referencedel er en del af

forudsætningerne for løsningen af

opgaven. Dette er begrundet med, at

man ønsker at have en entydig

reference til objekterne gennem hele

projektets livscyklus.

Referencesystematikken er ikke et

grundlag for bygningsklassifikationen.

Med det fremlagte forslag kan

klassifikationen anvendes uafhængigt af

referencesystematikken.


186 Henrik

Bang,

Bygherr

eforenin

gen

Generel Fokusområder for

klassifikationsarbejdet

Bygherreforeningen ser tre oplagte

fokusområder i det fremtidige arbejde

for at kunne skabe værdi:

Grænsefladen mellem drift og

programmering samt konceptuelt

design – grænsefladen mellem

udførelse /drift med fokus på

dokumentation og driftsdata – samt

grænsefladen projektering/udførelse

med fokus på tilbudsberegning og

produktions-forberedelse.

Lad det fremtidige arbejde være rettet

mod de mest oplagte fokusområder

mht. værdiskabelse

Noteret Det er disse tre områder, der explicit er

beskrevet i cunecos behovsanalyse og

alle tre områder vil være centrale i den

fremtidige udvikling.

187 Henrik

Bang,

Bygherr

eforenin

gen

Generel Rum og Bygningsdele - og meget andet

Bygherreforeningen tilslutter sig

forslaget om til en start at fokusere på

håndtering og klassifikation af Rum og

Bygningsdele. Vi er af den klare

opfattelse at det netop er på disse

områder (overgangen mellem projekt

og produktion, hvor

bygningningsdelene jo spiller en central

rolle, samt håndteringen af

bygniningerne hos byg- og driftsherren,

hvor rum, funktion og organisering

spiller en helt central rolle) at gode,

sunde løsninger på datahåndtering kan

skabe størst værdi.

Vi vil foreslå, at der samtidig med at der

arbejdes videre med disse

objektkategorier - og før der træffes

endelige beslutninger om

klassifikationskonceptet og om syntax

mv. - fokuseres på at beskrive, hvordan

man påtænker at håndtere de mange

andre objektkategorier, der er

beskrevet i grundlaget for DBK, og som

jo også nødvendigvis må inddrages i et

samlet klassifikationskoncept.

Der tænkes her især på: De fire M’er -

mandskab, materialer, materiel og

metoder; Byggeriets processer;

Byggeriets organisation - herunder

agenter og roller.

Af disse tre områder finder vi, at det

især er påkrævet med udviklingen af et

klart billede af den fremtidige

sammenhæng mellem det nu

foreliggende og ”de fire M’er” samt

”agenter og roller”. Vi kan f.eks. ikke

forestille os produktionsplanlægnings-

og produktionsløsninger (f.eks. tilbuds-

beregninger) eller programmerings- og

driftsløsninger eller rumklassifikation,

som ikke inddrager disse elementer.

Noteret cuneco har noteret sig opfordringen til

at lave en samlet oversigt over

sammenhængen mellem de fire

domæner i ISO 12006-2. P.t. foretages

dette i separate projekter, men det

overvejes at lave en samlet redegørelse

for disse domæner, som supplement til

begrebsmodellen fra ISO 12006-2.

188 Henrik

Bang,

Bygherr

eforenin

gen

Generel CCS og Forvaltningsklassifikation (FK)

Bygherreforeningen finder det meget

positivt, at det på høringsmødet blev

bekendtgjort, at der bliver gennemført

en mapping mellem CCS og

Forvaltnings-klassifikation.

Vi vil foreslå, at det i den forbindelse

overvejes, hvordan det kan sikres, at FK

bliver et ægte subsæt af CCS - eller

omvendt, at CCS bliver et supersæt for

FK.

Noteret M.h.t. mapningen til FK henvises til

svaret på kommentar nummer 67. Hvad

angår muligheden for at lade FK være

et subset til CCS vil muligheden for

dette bero på en nærmere analyse af

systemernes kompatibilitet som vil

kunne gennemføres når cunecos

arbejde med klassifikationstabellerne er

mere fremskredet.

189 Henrik

Bang,

Bygherr

eforenin

gen

Generel CCS i forhold til ekspertvurderingens

anbefalinger

Bygherreforeningen savner en

nærmere redegørelse for det

foreliggende forslags forhold til Anders

Ekholms og Lars Häggströms

ekspertvurderinger (den oprindelige

udtalelse og sammenfatningen af

januar 2011) og de mange høringssvar,

som fremkom i forbindelse med

”Symposiet” i oktober 2010.

Vi vil foreslå, at der udarbejdes et kort

notat herom til støtte for prioriteringen

af indsatsen af det videre arbejde.

Noteret M.h.t. relationen til Anders Ekholms

vurdering af DBK henvises til svaret på

høringskommentar nr. 44.

Derudover opfatter cuneco

nærværende høring inkl.

høringskommentarer som et validt

grundlag for det videre arbejde.

190 Henrik

Bang,

Bygherr

eforenin

gen

Generel Hvor skaber klassifikationstabeller

værdi?

Vi finder at med det foreliggende

høringsforslag, er der åbnet for en

frugtbar diskussion om formålet med at

klassificere rum og bygningsdele, men

at der stadig savnes en bredere anlagt

beskrivelse af formålet med

klassifikation set i lyset af det

paradigmeskift som byggeriets

samarbejde, metoder og værktøjer

undergår i disse år. Dette især på IKT-

området, hvor ”den successive

konkretisering” under projekteringen

og udførelsen i stigende grad bliver

understøttet af værktøjer, som

håndterer stadig rigere

egenskabsdatasæt gennem processen.

Klassifikationstabeller må jo

nødvendigvis udvikles inden for

Der bør tages stilling til, hvordan

klassifikation og modellering samvirker i

vore dages projektering og med vore

dages avancerede, objektorienterede

applikationer og

modelleringsværktøjer, samt hvor (i

hvilke domæner og funktioner) der kan

skabes værdi ved at støtte funktioner

og arbejdsprocesser med

klassifikationstabeller.

Noteret Område har været fokus for cunecos

behovsanalyse, hvor der er beskrevet

en række scenarier, hvor klassifikation i

samspil med egenskabsdata og

informationsniveauer skaber værdi i

forbindelse med konkrete projekter.

cuneco finder det ikke formålstjenstligt,

at forsøge at beskrive værdiskabelsen

af klassifikation isoleret set, da

værdiskabelsen er knyttet til en proces,

der indehoder mange elementer.

rammerne af et specificeret domæne

og mhp. at understøtte bestemte

formål og/eller funktioner. Vi savner

følgelig en nærmere beskrivelse af:

Hvor kan der skabes værdi (mest værdi)

ved at udvikle klassifikationstabeller -

inden for hvilke domæner, funktioner

og delfunktioner?; Hvem skal bruge

tabellerne - og til hvad?; Hvordan kan

tabellerne konkret støtte

arbejdsprocesser og modellering?;

Hvordan kan tabellerne skabe værdi

(direkte, indirekte og afledt) i mange

forskellige domæner og funktioner?

Den foreliggende behovsanalyse har

angiveligt ikke behandlet alle disse

spørgsmål, hvis svar er helt centrale for

en overordnet prioritering og endelig

stillingtagen til det foreliggende forslag.

191 Henrik

Bang,

Bygherr

eforenin

gen

Generel Bredde og involvering i arbejdet

Bygherreforeningen er enig i, at det er

vigtigt at arbejdet gennemføres med

tilstrækkelig ekspertise inden for

områderne klassifikation, udvikling af

ID-systemer, informationshåndtering

samt anvendelse af egenskabsdata i

modellering. For at opnå det bedst

mulige resultat er det nødvendigt, at

projektet-gruppen i tilstrækkelig grad er

bemandet med klassifikationsekspertise

og involverer personer med praktisk

erfaring og viden om modellering og

om praktisk anvendelse af

egenskabsdata i forskellige design-,

produktions- og driftsprocesser. Man

kunne med fordel have involveret den

kreds af kritikere, som deltog aktivt og

konstruktivt i symposiet i 2010.

Vi vil foreslå, at man i det videre

arbejde involverer folk i projektarbejdet

med ovennævnte kvalifikationer, og at

man finder en arbejdsform, som

involverer folk med praktisk erfaring

med modellering mv. - herunder fra

BVU-Net og fra kredsen af kritikere af

DBK.

Noteret Sammensætningen af cunecos

projektgrupper foretages af cunecos

styregruppe, der omfatter

repræsentanter fra en række af de

forskellige parter i branchen - og også

repræsentanter for de organisationer,

som de personer med de nævnte

kvalifikationer, er tilknyttet.

Styregruppen bestræber sig på at alle

synspunkter bliver inddraget i arbejdet.

192 Henrik

Bang,

Bygherr

eforenin

gen

Generel Internationalisering og standarder

Bygherreforeningen finder det

overordentlig vigtigt, at den indsats

som vi i Danmark gør på

klassifikationsområdet forholder sig

bevidst til, og lægger sig så tæt op ad

internationale standarder vedr.

klassifikation, ID-systemer, egenskabs-

datastrategier og

informationshåndtering som muligt, og

at vi gør det i overens-stemmelse med

den internationale udvikling på

modelleringsområdet og i Buil-

dingSmart miljøet.

Vi er derfor bekymrede over, at det

foreliggende forslag alene forholder sig

til - og er baseret på - en standard, hvis

primære emne er

informationshåndtering gennem

anvendelse af en referencesystematik

på det elektriske og mekaniske område,

og kun i ringe grad omhandler

klassifikation i byggeriet generelt, og

som ikke forholder sig til emner som

modelleringspraksis i byggebranchen og

håndtering af byggeriets successive

konkretisering i modelbaserede

værktøjer via egenskabsdata. Vi ser det

sådan, at kun en ud af tre forskellige

muligheder – dvs. kun et enkelt bud ud

af tre mulige – på udfordringen er

blevet undersøgt.

Vi vil følgelig foreslå, at man - inden

man går videre i arbejdet -

gennemfører grundige vurderinger af

IFC-konceptet/IFC-standarden og af ISO

12006-2, og undersøger disse

standarders muligheder for at

understøtte byggeriets informations- og

datahåndtering inden for forskellige

domæner og funktioner.

Vi savner en mere udfoldet

dokumentation af inden for hvilke

andre områder denne mekanik kan

være relevant at benytte. Umiddelbart

vil vi pege på to områder, hvor

metodikken ville kunne finde

anvendelse, men der kan ved en

nærmere undersøgelse sikkert

identificeres flere, bl.a. på FM-området.

Vi peger på tilbudsgivnings-processen

hos entreprenører, hvor der allerede er

foretaget eksperimenter, som det

kunne være gavnligt for resten af

branchen at høre nærmere om samt

udviklingen af metoder til at

sammenknytte bips’ beskrivelser til

bygnings- og procesobjekter under

modelleringsprocesser - netop den type

af behov, som EN 81346 er udviklet til

at dække.

Vi er således ikke bekendt med, at

andre fremherskende, internationale

klassifikationssystemer i byggeriet

benytter den foreslåede metodik og

syntax. Vi føler os ikke overbevist om,

Noteret I den palette af internationale

standarder, som cuneco baserer sit

arbejde på, har de buildingSMART-

relaterede standarder en meget central

rolle. Derudover har buildingSMART-

relaterede projekter været nævnt som

grundlag for samtlige de cuneco-

projekter, der indtil nu er startet op.

Endelig har cuneco indgået aftale om,

at projektchefen for cuneco indtræder i

bips buildingSMART-udvalg samt den

nordiske bestyrelse for buildingSMART

for yderligere at sikre denne

koordinering.

at det foreliggende forslag er

kompatibelt med ISO 12006-2 og IFC,

IFD og IDM. Vi frygter at Danmark bliver

isoleret i forhold til andre,

internationalt anerkendte

klassifikationssystemer for

bygningsdele og rum og vil foreslå, at

der snarest muligt gennemføres en

undersøgelse vedr. mulighederne for

mapping mellem CCS (alle 5 facetter for

bygningsdele og rum) og tilsvarende

tabeller for IFC og ISO 12006 samt f.eks.

SfB, BSAB, Omniclass og Uniclass, IFD

og IDM, samt for rum mapping mod

den norske standard for

rumklassifikation.

193 Henrik

Bang,

Bygherr

eforenin

gen

Generel Aspekt, View og Egenskaber

Overalt hvor der arbejdes med

objektorienterede og strukturerede

data i databasebaserede værktøjer

benyttes views som en udbredt metode

til at filtrere og analysere data mhp. at

understøtte en eller flere specifikke

funktioner. Denne ”filtrering” af data

benyttes i det foreliggende forslag.

Mekanismen foreslås anvendt som en

generel metodik, der skal benyttes som

styrende for klassifikation af

bygningsdele og rum, og den vil danne

grundlag for fastholdelse af

aspekttankegangen og

referencesystematikken fra DBK, som et

generelt klassificerende element for

hele CCS.

Vi finder det ikke overbevisende påvist,

at det er hensigtsmæssigt generelt at

indføre dette princip. På denne måde

udpeges på forhånd - og helt generelt -

simple ID’er, funktion, struktur og

placering som særligt vigtige views, hvis

aftryk på klassifikations-tabellerne skal

benyttes, hvis man ønsker en

underopdeling af de foreslåede, grund-

læggende hovedklasser.

Dette synes umiddelbart at have

følgende konsekvenser:

- Klassifikation efter funktion indgår på

to niveauer - dels som ”ren”

klassifikation (hvad det så end måtte

Delvist

accepteret

Kodestrukturen har to primære formål:

1) At identificere objektforekomster

både individuelt og ud fra den

sammenhæng som de indgår i forhold

til systemer og funktioner.

2) At tilknytte objektforekomsten til en

objektklasse..

Det præciceres i rapporten, at

kodestruktuern (views) ikke er styrende

for klassifikationen, men at

klassifikationen skal følge anvisningerne

i ISO 12006-2, hvilket der i øvrigt også

er lagt op i det videre arbejde.

Forslaget er derfor, at lave én simpel

klassifikation (fx af bygningsdele), der

kan anvendes uafhængigt, og på tværs i

de forskellige aspekter.

Anvendelsen af aspekter (views)

præciceres yderligere.

Anvendelse af objektetforekomsten i

konkrete sammenhænge i forbindelse

med byggeriets processer vil blive

foretaget med udgangspunkt i disse to

formål kombineret med en struktureret

anvendelse af egenskabsdata for

objektforekomsten. Det er cunecos

opfattelse at de fremlagte

kodeprincipper opfylder de to nævnte

formål.

være) med præfixet (%) dels i en mere

udfoldet version (=). Man benytter altså

grundlæggende den samme

egenskabsdatatype til klassifikation af

bygningsdele efter funktion, som man

benytter til at klassificere mere

detaljeret efter funktion. Det er jo bare

en detalje-ring/underinddeling, som det

ikke giver mening at forsyne med

særlige skilletegn i syntaxen. Der er jo

netop tale om en underopdeling og ikke

en klassifikation efter andre

grundlæggende kriterier eller views.

- Det tilføjer en unødig kompleksitet og

forvirring til klassifikationskonceptet.

- Det sammenblander tildeling af simple

ID’er med klassifikation. Uanset hvor,

hvorfor, hvordan og i hvilket omfang

der er behov for at arbejde med simple

ID-systemer, vil ID-erne altid være et

resultat af et funktionelt defineret view

på objekterne etableret gennem deres

egenskabsda-ta (eks. historien om

dørnummerering). Det er endvidere

ikke undersøgt hvordan man forestiller

sig at informationshåndteringen kan

understøttes af den maskingenerede

kode, der altid vil oprettes i et IKT-

system, når objektet oprettes. Dette

bør vises en særlig interesse.

- Det tvinger helt generelt alle, som

ønsker at arbejde med specifikation af

objekter, og som finder, at de har

behov for helt eller delvis at

understøtte arbejdet med

klassifikationstabeller, til anvendelse af

en referencemekanisme, selv om de

måske bare har behov for en simpel

me-kanisme til detaljering.

- Det er fortsat ikke klart beskrevet,

hvor (i hvilke domæner og for hvilke

funktioner) der findes behov for et

”placeringsaspekt”. De fleste

modelleringsværktøjer - af hvilken art

de end måtte være - indeholder rige

referencer mellem alle omfattede

objekter, hvorfor det synes overflødigt

til håndtering af bygningsdele og rum -

men det kan fortsat være relevant på

informationshåndteringens område (EN

81346’s oprindelige funktions-område).

Det er endvidere uklart, hvordan man

forestiller sig, at arbejdet med

modelbaserede værktøjer og IKT-

baseret informationshåndtering skal

understøttes af enten



egenskabs-datasæt - eller begge dele.

Ser vi på rigdommen af egenskaber for

selv de enkleste byggeobjekter, er det

vanskeligt at forestille sig en

klassifikations systematik med lige så

mange klassifikationstabeller eller

facetter, som der kan etableres

relevante views. Forestiller man sig, at

Cuneco skal påtage sig at udvikle

tabeller og syntax for alle mulige mere

eller mindre relevante views, eller vil

man helt overlade det til deltagerne i

de enkelte projekter?

Mange byg- og driftsherrer anlægger

f.eks. et ”fag”view og et ”arbejder”view

på bygningsdelene. Disse almindeligt

forekommende views findes ikke

repræsenteret i den foreliggende

model som ”aspekter”, og der er

følgelig ikke defineret en facet i

syntaxen til identifikation af indgange til

sådanne tabeller. Hvordan skal det

håndteres? Har vi nok præfixer til at

kunne repræsentere disse views - og til

at håndtere en hel masse andre

relevante views - og hvor er det evt.

nødvendigt at kunne det? Arbejder man

med model-baserede værktøjer ville

man jo kunne håndtere disse og mange

andre behov netop ved at etablere

views i modellen. Der savnes en

belysning af, hvor man har behovene,

og hvor man konkret løser dem i det

fremlagte forslag.

Vi er bekymrede over, om en

fortsættelse ud af det lagte spor vil

fjerne os yderligere fra de

internationale strategier og standarder

på området, vil virke fordyrende og ikke

generelt vil kunne skabe værdi, der

berettiger omkostningerne for

bygherrer og driftsherrer.

Bygherreforeningen vil foreslå, at man

helt opgiver referencesystematikken

som et fælles grundlag for

bygningsklassifikationen, og i stedet

udarbejder en let forståelig vejledning

med eksempler på konkret anvendelse

af EN 81346 for folk som har åbenlyse

behov for sammenknytte

bygningsobjekter og

informationsobjekter om samme. El- og

mekanik-området er godt dækket af

standarden selv, men der synes at være

et oplagt behov for at udfolde

mulighederne til støtte for f.eks.

tilbuds-kalkulation (relationer mellem

projektets bygningsobjekter og

entreprenørens recepter) og for en

understøtning af anvendelsen af bips’

beskrivelser.

Klassifikationstabellerne for

bygningsdele og rum bør herefter

udformes som ”traditionelle”

klassifikationstabeller i henhold til

reglerne i ISO 12006-2. De specifikke

behov inden for forskellige domæner vil

pege på, hvilke reelle behov der er for

at niveaudele og opdele i hoved- og

underklasser på forskellige områder, og

hvilke views der er behov for at

understøtte.

På området klassifikation af rum ved vi

allerede, at der er behov for at udfolde

en række views, som klassificerer rum

efter f.eks. ydeevne, ejerskab,

institutionstype, anvendelse,

beliggenhed, omkostninger etc.

194 Henrik

Bang,

Bygherr

eforenin

gen

Generel Praktisk udvikling og afprøvning af

klassifikation og ID-systemer for RUM

I Bygherreforeningens medlemskreds er

der gennem længere tid arbejdet på at

identificere behovene for klassifikation

af rum. Arbejdet er ikke afsluttet, men

der foreligger på en række områder

bud på behovene for klassifikation af

rum, lige som en gruppe bestående af

erfarne virksomheder for tiden arbejder

på at finde en praktisk løsning på dette

område. Samtidig ser vi en række

udfordringer i den foreslåede skitse til

klassifikation af rum.

Vi vil foreslå, at der som første fase i en

kombineret udvikling og afprøvning af

behov og udformning af

klassifikationstabeller på området

rumklassifikation gennemføres et

hurtigt workshopforløb med delta-gelse

af fagfolk, som har praktiske erfaringer

inden for området suppleret med folk

med viden om klassifikation.

Workshopforløbet skal fokusere på

”brugsrummet” og kunne i grove træk

struktureres på følgende måde:

- Præsentation for hinanden af

eksisterende behovsformuleringer og

tabelværker - herunder præsenteres

rumklassifikationssystemer og tabeller

fra kendte nordiske forslag samt Om-

niclass mfl.

- Oplistning af basale

klassifikationsparametre/kriterier

baseret på erfaringer og på egenskabs-

datasystematikker kendt fra f.eks.

Drufus og NS og FM-systemer.

- Identifikation af brugerbehov i forhold

til områderne ydeevne, ejerskab,

institutionstype, anvendelse,

beliggenhed, omkostninger etc. og

eksempler på ID- og

rumnummereringssystemer set i hele

rummets levetid (i alle domæner).

- Fastlæggelse af klassifikationstabeller

og klassifikationsparametre for hver

tabeltype.

- Beskrivelse af evt. sammenhænge og

principper for syntaks, herunder

Noteret cuneco har noteret forslaget. I

forbindelse med cunecos igangværende

projekt vedr. klassifikation af

bebyggelser, bygninger og rum, er der

allerede gennemført en workshop efter

disse retningslinjer, men cuneco er

indstillede på at kigge denne proces

efter i sømmene en ekstra gang for at

sikre, at alle perspektiver er dækket af.

sammenstilling med CCS.

Et sådant bredt funderet arbejde ville

efter vores mening skabe det bredest

mulige grundlag for udvikling af en

levedygtig klassifikation af rum, som

kan dække behovene helt fra de store

hospitalsprojek-ter, over andet statsligt

og kommunalt byggeri, og til alment og

privat boligbyggeri. Om industriens

bygninger også skal inddrages må

diskuteres yderligere.

195 Henrik

Bang,

Bygherr

eforenin

gen

Generel Praktisk udvikling og afprøvning af

klassifikation, ID-systemer og

egenskabsdata- og

informationshåndtering for andre,

udvalgte domæner og funktioner

På samme måde som ovenfor beskrevet

vedr. rum, vil vi foreslå at der

tilsvarende gennemføres

afprøvning/alternativ udvikling på en

række andre områder, hvor man vedr.

bygningsdele har en begrundet

formodning om, at der ville kunne

skabes værdi ved implementering af en

simplere model end den foreslåede, og

hvor man samtidig kan afprøve, hvilke

udfordringer det vil give at gennemføre

en fuld udskillelse af

referencesystematikken fra

klassifikationen.

Man kunne her fokusere på overgangen

mellem projekt og

produktionsplanlægning (incl

tilbudsprocessen) samt belyse

mulighederne for at støtte

modellerings-processen med

anvendelse af bips’ beskrivelser.

Noteret De nævnte elementer er taget med i

cunecos beskrivelse af strategien for

afprøvningsområdet, som netop har til

formål at beskrive alle de perspektiver,

der skal afdækkes i forbindelse med

afprøvningen.

196 Henrik

Bang,

Bygherr

eforenin

gen

Generel Trykprøvning af CCS ved udenlandske

eksperter

Bygherreforeningen vil foreslå, at der -

når de foreslåede aktiviteter er færdige,

og der foreligger en revideret version -

gennemføres en yderligere

trykprøvning af CCS i form af et review

af forslaget gennemført af kompetente

eksperter fra udlandet, som har viden

og erfaringer inden for alle tre

hovedemner samt repræsentanter fra

BuildingSmart med kendskab til IFC, IFD

og IDM. Ekspertgruppen bør endvidere

omfatte personer med et særligt

kendskab til klassifikation af

egenskabsdatatyper, som kan medvirke

til at vurdere den foreslåede løsnings

evne til at understøtte

specifikationsfunktioner for

objektegenskaber i tidssvarende

modelleringsværktøjer. BVU-net kan

evt. bidrage med at identificere

sådanne personer.

Noteret

197 Henrik

Bang,

Bygherr

eforenin

gen

Generel Fra tal til bogstaver

Bygherreforeningen finder det positivt

at inddrage bogstaver i kodningen af

objekt-typerne.

Noteret

198 Henrik

Bang,

Bygherr

eforenin

gen

Generel Den stabile kode

Bygherreforeningen kan tilslutte sig

tanken om "den stabile kode" som går

gennem alle snitflader og

transformationer ”fra vugge til grav” og

som kan ses som bærer af et minimums

egenskabsdatasæt.

Men det er efter vores mening

nødvendigt at gå dybere i

undersøgelsen af, om det er muligt i

praksis at realisere - og i givet fald hvor

og hvordan.

Der er to grunde til det:

- Byggeriets virkelighed. Den samlede

proces er karrakteriseret ved successiv

konkreti-sering og den medfører netop

et behov for at man kan ændre i

objekterne og dermed i

klassifikationskoden undervejs i

processen efterhånden som objekterne

samles, opdeles eller beriges med

yderligere egenskaber. Det er et

generelt vilkår i byggeriet, som man må

respektere, og som

klassifikationskonceptet skal kunne

håndtere.

- Værktøjernes forskellighed. Om - og

især hvordan - man i praksis kan ”holde

styr” på sine objekter på deres vej i

byggeriets samlede flow - og ind og ud

af manuelle og automatiserede

processer og objekt-orienterede

værktøjer - er i høj grad et

dataudvekslings- og et formatproblem.

En nærmere belysning af vilkårene for

dette flow må gennemføres før man

kan se, om der er én mulig løsning, der

kan holde ”fra vugge til grav”, om der

evt. er flere fælles for eet eller flere

domæner, og om man evt. kan definere

en standardbeskrivelse af

”minimumsobjektet”, som holder hele

Noteret cuneco er enige i, at princippet om 'den

stabile kode' ikke er noget man kan

vedtage uden at sikre sig, at det kan

implementeres i den virkelige verden.

På den baggrund vil dette princip have

meget stor fokus i forbindelse med

udarbejdelsen af scenarier og

gennemførelsen af

afprøvningsprojekterne.

vejen igennem. Findes der entydige

svar på disse spørgsmål, giver det et

vigtigt bidrag til grundstrukturen i

klassifikationssystemet samt nogle

signaler om syntaxen.

199 Henrik

Bang,

Bygherr

eforenin

gen

Generel Fag og Arbejder

Der efterlyses konkret forslag til to

ekstra facetter for håndtering af hhv.

”fag” og ”arbejder” til støtte for byg- og

driftsherrens håndtering af

bygningsdele i forbindelse med

beskrivelser og gennemførelse af udbud

samt tilbudsvurdering.

Noteret Fag og arbejde er ikke en del af

resultatdomænet i ISO 12006-2, som

kodeprojektet omfatter.

200 Henrik

Bang,

Bygherr

eforenin

gen

Teknisk Simple ID’er, GUID og ID-

Nummererings-systemer

Der findes to typer af ID’er:

- Simple maskingenererede ID’er

etableret i/af IKT-værktøjerne i

forbindelse med oprettelsen af objekter

i systemer - GUID.

- ID’er der repræsenterer et funktionelt

defineret view på objekterne etableret

gennem deres egenskabsdata (eks.

historien om dørnummerering) og som

skal bruges til et bestemt formål.

Vi foreslår, at det beskrives, hvordan

informationshåndteringen kan

understøttes af IKT-værktøjernes

maskingenerede kode.

Vi foreslår endvidere, at der

igangsættes et arbejde med at

identificere og beskrive forskellige ID-

systemer ud fra deres domænetilhør og

specifikke formål, samt udarbejde

forslag til fælles principper for

udarbejdelse/implementering af

sådanne systemer - med eksempler,

guidelines for implementering mv.

Noteret Der er ingen kobling mellem CCS og de

maskingenerede koder. De

maskingenerede koder anses for

ustabile (da de er afhængige af den IT

platform de er udarbejdet på, og

endvidere kan ændre sig for samme

objekt, fx ved at en "væg" slettes i en

model, og genindsættes på ny).

Maskingenerede koder er endvidere

uegnet til menneskelig genkendelse.

De foreslåede nye projekter medtages i

puljen af mulige opgaver.

201 Henrik

Bang,

Bygherr

eforenin

gen

Teknisk Den foreslåede syntax og samspil med

andre værktøjer som fx Excel

Det nævnes flere steder i forslaget, at

koder skal kunne håndteres manuelt,

og let skal kunne indlæses i enkle

værktøjer – som fx Excel - for

gennemførelse af sortering, optælling

og analyser mv. Den foreslåede syntax

udviser udfordringer på to områder i

denne forbindelse:

- Programmer som Excel (som er det

eneste vi har forsøgt os i) opfatter

umiddelbart en CCS-streng som en

blanding af celle-referencer og

funktioner/operatorer, og vil ikke uden

en for- eller efterbehandling af

strengen kunne bruge den

meningsfyldt.

- Dette kræver udvikling af

specialiserede udlæsnings- og

indlæsningsværktøjer evt. baseret på

”xml” (xml-convertere), som dels kan

generere en generelt forståelig eller

specifik maskinlæsbar kode, som kan

indlæses automatisk i relevante

systemer, og som - hvor det måtte være

relevant - samtidig fra det modtagende

system kan tilbagelevere en CCS-streng

med de nød-vendige koder i den

nødvendige syntax. Dette er ikke noget

den gennemsnitlige Excel bruger kan

lave efter behov.

Hvordan problemet skal løses ligger

ikke lige for, men for at lette en manuel

eller halv-automatisk overførsel kunne

man overveje at indføre en fast

rækkefølge af facetter og faste

opdelinger af den enkelte facet – evt.

suppleret med ”tab” eller ”mellemrum”

som skilletegn. Dette vil så til gengæld

formentlig gå ud over

brugervenligheden og ønsket om en

kort kodestreng.

Delvist

accepteret

Kodestrengen kan dekodes i den form

den er nu, og skal ikke være i et fast

format. Kodestrengen kan deles op i de

forskellige aspektkoder. Se svar til

kommentar 131.

Teknisk note: Når fx Excel ”regner” på

kodestrengen, er det fordi cellen i

regnearket skal formateres anderledes.

Kodestrengen kan desuden håndteres

med standard funktionaliteten i Excel.

Håndteringen af kodeprincipper i Excel

belyses nærmere.

202 Henrik

Bang,

Bygherr

eforenin

gen

Generel Fokus i det videre arbejde

Bygherreforeningen er helt enig i, at

det er nødvendigt at gennemføre en

hård prioritering i det videre arbejde for

at sikre, at man kommer til vejs ende

med en klassifikation der skaber værdi

på udvalgte områder.

Vi vil derfor foreslå, at arbejdet

fremover fokuseres på at opnå nyttige

og værdi-skabende resultater på de

områder, hvor COWI-rapporten (og

mange andre udsagn) har peget på, at

værdiskabelsen ved udviklingen af

støtteværktøjer til den videre udvikling

på IKT-området skønnes at ville have

størst effekt i branchen.

Vi vil i den forbindelse pege på især tre

områder, hvor indsatsen skønnes at

ville skabe mest værdi.

Det drejer især sig om følgende tre

områder:

- Grænsefladen mellem projekterings-

domænet og produktionsdomænet

med et særligt fokus på grænsefladen

mellem projekt og udførelse - inkl.

tilbudsberegning og

produktionsplanlægning.

- Grænsefladen mellem driftsdomænet

og de tidlige funktioner i

projekteringsdomænet med et særligt

fokus på grænsefladen mellem

driftserfaringer, programmering og

konceptuelt design.

- Grænsefladerne mellem produktionen

og driftsdomænet med et særligt fokus

på den løbende overdragelse af data

mhp. dokumentation af produkt og

proces samt overdragelse af data til

drift.

Noteret Disse tre områder er alle blevet

fremhævet i cunecos behosvanalyse og

cuneco har enten oprettet eller er i

færd med at definere projekter, der har

fokus på disse områder.

203 Kaj A.

Jørgense

n

Generel En af Cunecos projektgrupper

vedrørende klassifikation har nu

udsendt et første rapport-udkast og

indbudt til høring. Der vil

tilsyneladende ske to væsentlige

ændringer som hilses velkommen: 1)

Efter vi er nogle, der nu i flere år har

påpeget, at DBK på

bygningsdelsområdet ikke er et

klassifikationssystem i egentlig

forstand, ser det ud til at der nu skal

udvikles klassifikationstabeller for

bygningsdelstyper og rumtyper. 2) Der

vil ligeledes blive udviklet

klassifikationstabeller for

rumfunktioner og

bygningsdelsfunktioner. Disse

nyskabelser bliver imidlertid ikke

fremlagt i denne omgang, selv om det

absolut er påkrævet at få skabt

sikkerhed for, at denne udvikling vil

være grundlagt på et sundt fundament.

Der er således endnu ikke opsat en klar

påpegning af formålet med udvikling af

klassifikationssystemer i et

tidssvarende perspektiv. Så efter flere

måneders arbejde, er det relativt

skuffende, at det udelukkende er

såkaldt kodningsregler, der er fremlagt.

Emner, der i denne sammenhæng er

helt sekundære. Det er endvidere

særdeles skuffende, at der

tilsyneladende lades hånt om de mange

høringssvar, der tidligere er udarbejdet

til det danske "klassifikationsarbejde".

I det fremsatte forslag er der stadig en

Fremgår indirekte af kommentaren. Noteret Det pointeres at et af formålene med

CCS bl.a. er entydig identifikation af

objekter uafhængigt af IT-platforme.

CCS skal desuden kunne anvendes både

digitalt og analogt (dvs. egnet til

menneskelig genkendelse), hvilket har

været en forudsætning for

projektgruppens arbejde.

Generel kommentar til ”Fremgår

indirekte af kommentaren”. Det er

teknisk svært at udlede en konstruktiv

kommentar af de betragtninger der

fremføres, da det rummer risiko for

misfortolkning.

stærk fokus på det emne, der vel mest

betegnende kan kaldes opmærkning af

bygningsdele via en sammensætning af

koder. En sådan form for opmærkning

og fokus på koder er uvæsentlig ved IT-

baserede systemer eller

bygningsmodeller, hvor koderne under

alle omstændigheder vil være til internt

brug og ikke noget brugere skal

håndtere.

204 Kaj A.

Jørgense

n

Teknisk Omtalen af nogle helt grundlæggende

begreber bliver forplumret, når

begrebet 'forekomst', som ganske vist

hidtil (i DBK) har været uklart defineret,

nu skal udtrykkes som

'objektforekomst' og i øvrigt iklædes en

ny betydning. I daglig tale er begrebet

jo synonym med 'eksemplar af et eller

andet' og dermed også synonym med

'individ'. I rapporten udtrykkes det som

type af objekt, hvilket er det stik

modsatte og dermed klart forvirrende.

Det er svært at se begrundelsen for i

den grad at skabe forvirring. Det

medvirker yderligere til forvirringen, at

begrebet 'objekt' også skal forstås i en

fremmed betydning (i teksten benyttes

flere betydninger). Nogle steder bliver

det udtrykt som 'objektindivid', hvilket

er dobbeltkonfekt. Andre steder

forklares 'Objektindivid' som et

'specifikt produkt, der indkøbes',

hvorved der sker en uholdbar

indsnævring af betydningen. Det tyder

mest på, at man med vold og magt

ønsker at hænge sig fast i noget, som

allerede er dømt ude, hvilket er i

modstrid med erklæringen om at

"tavlen er vasket ren".

Helt galt bliver det, når der i en note

præciseres, at definitionerne gælder

(cit.) 'objekter betragtet i ”den virkelige

verden”, og omfatter derfor ikke en

model repræsentation af samme

objekt'. Hermed er forvirringen total,

idet hele den fundamentale opfattelse

Fremgår indirekte af kommentaren.

Desuden: Et objekts

attributter/egenskaber kan være af

forskellig art, herunder de almindelige:

numerisk, tekst, osv. (inkl. koder) og

kan desuden referere til andre objekter

(illustreret med pile i figur 1). Visse

attributter kan eksempelvis beskrive

eller referere til byggeprodukter (hvis

man ikke i stedet indsætter en

produktmodel). Begrebet 'objekttype'

er en "skabelon" for objekter i

overensstemmelse med almindelig

opfattelse inden for

informationsmodellering.

Forudsætningen for ethvert objekt er

altså, at der er defineret en objekttype.

Objekter skabes altså som eksemplarer

(forekomster) af en given type. Mere

kompliceret behøver det ikke at være.

Delvist

accepteret

CCS er ikke kun begrænset til

dataobjekter.

Tekst vedrørende modeller "i den

virkelige verden" præciseres i

rapporten.






misfortolkning.

af rapportindholdet smuldrer. Det er

helt afgørende, at der skelnes skarpt

mellem 'den virkelige eller fysiske

verden' og forskellige former for

beskrivelse af denne, altså modeller

heraf. Med en beskrivelse er der jo altid

tale om en mere eller mindre bevidst

forenkling (model) af virkeligheden.

(Med modeller menes her ikke

nødvendigvis den gængse opfattelse af

bygningsmodeller eller BIM modeller

men mere generelt.

Dokumentbaserede beskrivelser eller

objekter i specialsoftware kan også

betragtes som modeller.) Det

forbistrede er ganske vist, at begrebet

'objekt' i bred forstand både kan

benyttes om noget fysisk og om en

'data container', også præciseret som

'dataobjekt' (se figur 1). Hvis ikke

rapportindholdet (om kodning mv.)

primært handler om håndtering af data

om rum og bygningsdele (i 'den

virkelige verden'), altså beskrivelse

heraf (eller mere stringent

'repræsentation heraf'), så er sigtet

med rapporten fuldstændig forfejlet.

I det følgende vil begrebet 'objekt' blive

opfattet som 'dataobjekt'/'data

container', herunder som 'modelobjekt'

som illustreret i figur 1.

205 Kaj A.

Jørgense

n

Teknisk I rapporten forekommer emnet

identifikation som en del af kodningen

og det er en absolut uheldig

sammenblanding, idet påsætning af

koder ikke har noget med identifikation

at gøre. Koder indsættes i objekter som

led i beskrivelse af bygningsdele, altså

specifikation og de er blot at betragte

som helt almindelige

egenskabs¬værdier, der kun er særlige

værdier, fordi de refererer til positioner

i f.eks. eksisterende tabeller (se

eksempelvis attributten 'Classification' i

figur 1). En sådan kode er ganske vist en

identificering af en tabelindgang men

det er jo en helt anden sag og må ikke

forveksles med identifikation af et

objekt. Noget sekundært er, at man

derved tilfører objektet identitet (altså

noget andet end identifikation).

Misforståelsen kan muligvis også

hidrøre fra den sprogbrug, der

anvendes i forbindelse med at søge

efter et informationsobjekt ved at

benytte en eller flere søgenøgler og

dermed indsnævre søgningen indtil

man har fundet eller ”identificeret” det

søgte.

Éntydig identifikation af et objekt fødes

altid med objektet og er derfor i

software applika-tioner som regel

systemgenereret (se ID attributten i

figur 1). Men mere bruger-venlige ID’er

eller navne kan sagtens tilføjes, hvis det

er hensigtsmæssigt (se ’Name’

attributten i figur 1). En navngivning

Fremgår indirekte af kommentaren.

Konklusionen må være, at emnet

identifikation bør adskilles fra de øvrige

emner og behandles helt separat –

mest fordelagtigt efter at de relevante

klassifikationstabeller er udviklet.

Ikke

accepteret

Det pointeres at et af formålene med

CCS bl.a. er entydig identifikation af

objekter uafhængigt af IT-platforme. I

henhold til gældende internationale

standarder, er de CCS kodeprincipper

der er foreslået defineret som entydig

identifikation af et objekt.

CCS er designet til at kunne fungere

uden datamodeller til rådighed, men i

samspil med disse.






misfortolkning.

skal i sagens natur være brugerrettet og

bør derfor ikke gøres unødig besværlig

ved at anvende koder men i stedet

mere klar tekst eller entydige

forkortelser. Identifikation har derfor

ikke nødvendigvis noget med

klassifikation at gøre (selv om en

typebetegnelse eventuelt kan indgå

som i det viste eksempel 'Wall 738').

Desuden: identifikation er ikke et

aspekt i den almindeligt definerede

betydning, da identifikatorer ikke bør

indeholde en betydning.

206 Kaj A.

Jørgense

n

Generel Omkring identifikation bliver det

hævdet, at der er behov for, at hver

identifikator/navn er uændret hen

igennem projektet men i praksis er der

mange eksempler på, at det kun kan

være tilfældet, når objektet ikke

ændres strukturelt. En væsentlig del af

detaljeringsarbejdet handler jo netop

om, at objekter opdeles i flere objekter,

hvorved der er behov for ændring af

ID'er/navne. Tænk f.eks. på en

facadevæg, der opdeles i sektioner

enten fordi de tilgrænsende rum stiller

forskellige krav eller fordi den skal

indkøbes som præfabrikerede

elementer. I dette tilfælde sker

opdelingen måske endog først af

leverandøren, altså relativt sent i

processen. Noget tilsvarende vil kunne

ske med forskellige installationsdele.

Der er naturligvis behov for éntydig

brugerdefineret identifikation af visse

fysiske bygningsdele og indsætte

værdier herfor i dataobjekter. At

oprette sådanne identifikatorer/navne

manuelt før det er nødvendigt og

dermed være tvunget til at

vedligeholde værdierne unødigt er

imidlertid spild af ressourcer. Den til

grund liggende påstand om stabil

identifikation er dermed ikke påvist.

Behovet kan løses meget enklere.

Fysisk identifikation af en (fysisk)

bygningsdel vil i fremtiden meget

hensigtsmæssigt blive foretaget med

RFID eller en tilsvarende teknisk

Fremgår indirekte af kommentaren. Noteret Generel kommentar til ”Fremgår





misfortolkning.

løsning. En sådan ID vil da naturligt

indgå som egenskabsværdi i det objekt,

der repræsenterer bygningsdelen.

207 Kaj A.

Jørgense

n

Teknisk Aspekt-begrebet bliver i rapporten

stadig fremhævet som et hovedemne

men det bliver desværre ikke behandlet

på udtømmende måde. Emnet er ikke

nyt, for der drejer sig ganske enkelt blot

om en måde at kategorisere

egenskaber på og teorien herom

strækker sig helt tilbage til Aristoteles.

Det er bemærkelsesværdigt, at der ikke

fremføres en argumentation for,

hvorfor netop de valgte egenskaber

fremhæves og udråbes som aspekter,

når der findes stribevis af andre

kategorier af egenskaber, der også kan

betragtes ud fra aspekttankegangen.

Eksempelvis kan nævnes valg af

brandklasse, energiklasse eller

sikkerhedsklasse. Aspekt-begrebet har

mest karakter af at være en akademisk

foreteelse, som ikke har nogen særlig

praktisk betydning. Almindelig praksis

er jo, at man bare påsætter

egenskabsdata efter behov.

Komposition og placering er også listet

som aspekter og kan naturligvis

foretages men kodning heraf er helt

overflødig, hvis man tager

udgangspunkt i bygningsmodeller, hvor

det er muligt at trække data ud og

strukturere på flere måder efter behov.

Når bygningsdele vælges og bliver

indsat i en konkrete model, oprettes

der nemlig automatisk relationer dels

mellem bygningsdelene indbyrdes og

dels mellem rum og bygningsdele. Disse

relationer er defineret i IFC og






misfortolkning.

Teknisk kommentar til ”Aspekt-

begrebet har mest karakter af at være

en akademisk foreteelse, som ikke har

nogen særlig praktisk betydning.”

cuneco mener, at der her er tale om en

misforståelse af konceptet, og er ikke

enige i, at det er en akademisk

forteelse, men at den tværtimod har en

særdeles praktisk betydning.

Teknisk kommentar til ”Når

bygningsdele vælges og bliver indsat i

en konkrete model, oprettes der nemlig

automatisk relationer dels mellem

bygningsdelene indbyrdes og dels

mellem rum og bygningsdele”. cuneco

er ikke enige i, at dette er tilfældet i

praksis.

Teknisk kommentar til ”Forslaget

rummer tilsyneladende kun én

kompositorisk struktur (jf. også

referencesystemet i DBK) men det er

vigtigt at understrege, at der

sædvanligvis vil være behov for flere

forskellige formålsbestemte

kompositionsstrukturer, f.eks. også

efter etager og rum.”. Det fremlagte

forslag til kodeprincipper i CCS giver

forventes brugt i modelleringssoftware.

(Se figur 2 som forenklet illustration af

nogle af de relationer, der automatisk

opbygges i bygningsmodeller og som

kan anvendes til sådanne dataudtræk.)

Ønsker man koder lagt ind i modeller,

kunne det gøres ved f.eks. at definere

nogle PropertySets i IFC. Komposition

kan i øvrigt meget enkelt etableres på

anden måde.

Forslaget rummer tilsyneladende kun

én kompositorisk struktur (jf. også

referencesystemet i DBK) men det er

vigtigt at understrege, at der

sædvanligvis vil være behov for flere

forskellige formålsbestemte

kompositionsstrukturer, f.eks. også

efter etager og rum.

mulighed for dette.

208 Kaj A.

Jørgense

n

Generel Ovenstående betragtninger er i høj grad

også en kritik af de standarder, der

refereres til. Disse standarder bliver

altså tillagt uholdbar meget betydning.

Standarder er ikke nødvendigvis

opbygget på et korrekt videnskabeligt

grundlag og skal under alle

omstændigheder vurderes nøje i

forhold til anvendelsesområdet.

Fremgår indirekte af kommentaren. Noteret Der er ikke krav om, at standarder skal

opbygges på et videnskabeligt grundlag.

Til gengæld er der andre mekanismer

der bevirker, at standarder anvendes,

hvilket bl.a. er valgt i CCS.

cuneco er enige i, at anvendelsen af

enhver standard skal ses i

sammenhæng med en vurdering af

kvaliteten af den pågældende standard

i sammenhæng med egnetheden i

forhold til den opgave, der skal løses.

209 Kaj A.

Jørgense

n

Teknisk Under gennemgangen af aspekt-

begrebet figurerer også klassifikation

og dette må siges at være meget

problematisk, idet der teoretisk set er

tale om et brud med traditioner. Helt

principielt må der foretages et valg

mellem to principper for

informationsmodellering og det er der

ikke redegjort klart for.

Den ene mulighed er, at det

traditionelle princip for

modelleringssoftware anvendes

(gælder også for IFC), hvor objekter

skabes ud fra valg af objekttype, hvor

alle mulige typer er defineret i et

klassifikationssystem i form af

biblioteker med objekttyper (taksonomi

i flere niveauer). På denne måde fødes

objekter med et varieret antal

attributter afhængigt af typen og i

tillæg vil der være en række metoder til

rådighed, knyttet til attributterne.

Dette princip indebærer, at

klassifikation ikke kan karakteriseres

som et aspekt på linje med de andre. En

afgørende mulighed ved denne

fremgangsmåde er, at henvisninger til

nationale eller internationale

klassifikationssystemer kan indbygges i

objekttyperne på forhånd og dermed

eliminere eller væsentligt reducere

behovet for manuelt arbejde. Som led i

detaljeringen kan der så ske en

successiv specialisering, dvs. at

eksisterende objekter udskiftes med

mere specielle objekter, altså valg af

Fremgår indirekte af kommentaren. Delvist

accepteret






misfortolkning.

Det tydeliggøres i rapporten hvordan

klassifikationen virker i de aspekter

hvor den anvendes, og hvordan den

kan anvendes separat. Det overvejes

evt. at ændre betegnelsen

”klassifikationsaspekt”.

undertyper. Vinduer og døre kan

eksempelvis i første omgang vælges

som generiske objekttyper uden

nærmere specifikation og senere kan

der foretages valg af en mere speciel

type og det generiske objekt udskiftes

da med et nyt objekt, eventuelt en

model af et byggeprodukt.

Ved den anden mulighed, som der

tilsyneladende lægges op til her, skabes

objekter ud fra ultimativt én objekttype

eller ud fra meget få og meget

generiske objekttyper med meget få

attributter og metoder. Specialisering af

undertyper håndteres derfor

efterfølgende ved specifikation med

successiv påsætning/opdatering af

egenskaber. Som nævnt strider denne

fremgangsmåde mod sædvanlig praksis,

herunder IFC. Det vil således være en

væsentlig mere primitiv tilgang, hvor

struktur og semantik ved allerede

udviklede informationsmodeller med

klassifikation som IFC ikke kan bruges i

forbindelse med softwareudvikling. En

afgørende ulempe er også, at

klassifikation dermed bliver en ren

manuel opgave.

Rapporten tyder desuden meget på, at

der ikke skelnes skarpt mellem a) 'det

at klassificere', altså 'at vælge en klasse'

og b) 'det at opbygge et

klassifikationssystem'. Det første

forudsætter det andet. Så der er kun

tale om 'at klassificere', hvis der vælges

klasser fra et klassifikationssystem.

Påsætning af andre koder er derfor ikke

'at klassificere'.

210 Kaj A.

Jørgense

n

Generel Som anført i indledningen er der i det

foreliggende rapportudkast ikke taget

stilling til formål med

klassifikationssystemer og hvilke

principper, der skal ligge til grund for

udvikling af tidssvarende

klassifikationstabeller. Der er nemlig

behov for at kikke på klassifikation på

en helt anden måde set i relation til

bygningsmodellering. En helt afgørende

begrundelse er som nævnt, at et

modelobjekt altid oprettes fra en

defineret type/klasse

(klassifikationssystem) tidligt i forløbet

og fra det tidspunkt vil arbejdet med

objektet være specificering dels i form

af påsætning af flere

attributter/egenskaber og dels ved

underopdeling i delobjekter. Det er

derfor meget afgørende, at dette kan

ske så

automatisk/softwareunderstøttet som

muligt.

Når et modelobjekt er oprettet, bør

dets derved fastlagte type anvendes til

selektering af data i interne/eksterne

databaser for nærmere specifikation af

modelobjektet, f.eks. med

omkostningsdata, tekniske løsninger,

udførelsesanvisninger/aktiviteter,

monteringsinstrukser og

vedligeholdelsesanvisninger. En

klassifikationstabel over

bygningsdelstyper giver altså grundlag

for inddragelse af data udefra

(branchedata) til projekterne. Dette






misfortolkning.

betyder omvendt, at dette behov giver

grundlag for videninstitutioner kan

organisere (klassificere) og

offentliggøre forskellige former for

byggedata.

Det er derfor også væsentligt at

påpege, at der er brug for mange

forskellige klassifikationstabeller til

støtte for de forskellige trin i den

samlede proces. I figur 3 er der vist en

række eksempler på projektuafhængige

data, der kan være nyttige til brug ved

projekters specifikationsarbejde. Alle

disse datamængder kan med fordel

organiseres i klassifikationstabeller.

Som det kan ses af diagrammet skelnes

der vedrørende rum mellem aktiviteter

og funktioner. Dette forhold er det

vigtigt at få behandlet inden

klassifikationstabeller kan udvikles.

Vedrørende bygningsdele er der vist en

adskillelse mellem funktioner, former,

strukturer, tekniske kompositioner,

produktmodeller og

aktiviteter/recepter. Det er ligeledes

vigtigt at få disse sondringer analyseret

forud for udvikling af

klassifikationstabeller.

211 Kaj A.

Jørgense

n

Generel Dataobjekter til repræsentation af

bygningsdele vil som oftest blive født

ud fra deres former, hvilket netop er

dækket af IFC og modelleringssoftware.

Dermed er klassifikation på dette

område i nogen grad overflødiggjort.

Skulle man alligevel finde det

hensigtsmæssigt at opbygge en national

eller international klassifikationstabel

over formtyper er det meget vigtig, at

der kan ske en jævnførelse med

objekttyperne i IFC. I modsat fald vil

den ovenfor nævnte inddragelse af data

ikke kunne ske effektivt og

softwareunderstøttet.

Generelt er det afgørende, at der er

sammenhæng mellem

klassifikationstabellerne indbyrdes.

Eksempelvis vil det øge produktiviteten

væsentligt, hvis man ud fra valgte

former let kan blive vejledt til valg af

strukturer (f.eks. vedrørende bærende

dele) eller videre kan blive støttet til

valg af tekniske kompositioner (f.eks.

vinduer, trapper eller lagdele af vægge).

Ligeledes vil det være

ressourcebesparende, hvis man ud fra

valgte tekniske kompositioner kan blive

hjulpet til valg af produktmodeller eller

aktiviteter og recepter som grundlag for

estimering og udførelse.

Noteret Teknisk kommentar til ”Dataobjekter til

repræsentation af bygningsdele vil som

oftest blive født ud fra deres former”.

cuneco er ikke enige i betragtningen, da

det kun omfatter enkelte bygningsdele

og ikke kan anvendes som en generel

metodik (gælder fx ikke ventiler, rør,

kabler, sikringer mv.

respons pÅ hØringskommentarer til … · iec 81346-2: såfremt udvalgte dele af denne overhovedet...

Documents