De Digitale Dage 2013 – Summa sumarum

Efter tre dage med fuld gas på BIM, kommunikation og innovation kunne vi med god samvittighed fredag eftermiddag sætte tænderne i en pølse og skylle efter med en fyraftensøl ved afslutningen af De Digitale Dage 2013.

Min rolle ved dette års DDD var, som skrevet i forrige indlæg, projektleder. Jeg har aldrig deltaget i DDD før, men det kan varmt anbefales til alle, som gerne vil være spydspids for udvikling og afprøvning af de nyeste IT-systemer inden for byggeriet og indenfor BIM.
Jeg vil kort beskrive processen omkring nogle få af de  programmer vi anvendte ved DDD:

  • Vi anvendte ibinder som projektweb kombineret med Bips struktur for dokumenthåndtering nemlig A104.
    • Beskrivelse af ibinder – http://www.ibinder.com
      • Ibinder er en webbaseret mappestruktur som mest anvendes indenfor  Byggeprojekt, Digitalt udbud, Ejendomsdrift og Arkiv. Det byder på en overkommelig brugerflade, hvor man nemt kan få overblikket over, hvilke mapper man har og hvilke der er aktive.

Untitled

Billedet er fra projektwebbet DDD.
Mapperne som er i halftone er tomme og de andre er i brug – nemt og overskueligt

      • Vurdering
        • Der var masser af opstartsproblemer, da mange skulle oprettes som brugere inden vi kunne komme i gang på dag 1. På trods af det var det en stor succes. Ibinder er som sådan en virtuel mappestruktur, som man nemmere kan overskue pga. opsætningen omkring aktive og ikke aktive mapper. I al sin enkelthed minder det meget om en traditionel mappestruktur man f.eks. bruger, hvis man anvender dropbox til projektweb. Ibinder styres vha. en administrator, som disponere over brugerens rettigheder. På den måde styres hvem, der kan hhv. downloade og uploade. Dermed bliver enkelt for brugeren at forholde sig til.
          Jeg mener ibinder er et godt værktøj til projektweb og jeg tror det bliver noget vi kommer til at stifte bekendtskab med fremover både på skoler og i erhvervslivet.
    • Beskrivelse af A104 – http://bips.dk/nyhed/video-l%C3%A6r-om-dokumenth%C3%A5ndteringsmanualen
      • A104 dokumenthåndtering er et styresystem til at håndtere sin projektweb. Det hjælper til at navngive filer og lave en gennemsigtighed i den måde branchen skal håndtere deres projektweb. Ligesom mange andre tiltag fra BIPS lægger A104 også op til at fordelen rigtig kommer ved. BIPS’ værktøj til dokumenthåndtering slår rigtigt igennem når flere parter i et konsortium eller et samarbejde mellem faggrupper anvender A104Således bliver dokumenthåndteringen lettet pga. de samarbejdende parter kan overskue hindandens filnavngivninger og placeringer i mapperne i deres projektweb.
    • Vurdering
      • Jeg har anvendt A104 til 2 projekter. Det er uden tvivl et værktøj, som skaber en retningslinje for, hvordan man håndterer sin dokumenthåndtering. Selve vejledningen er udført således der ikke er meget overladt til fantasien ift. en almen mappestruktur som hverenkelt firma sætter op. For at komme i gang med A104 er det dog essentielt, at man har BIM-koordinatorer der kan hjælpe en i gang. På trods af at A104 virker godt, er det svært at komme i gang med pga. det er et meget omstændigt dokument at sætte sig ind i – det er 86 sider.
        I vores gruppe på UCN har vi udvalgt de ting af A104 vi kunne bruge og derefter rettet META-DATA’en til, så det har passet til vores projekt. Det er en succes. Til DDD har det været et andet opsæt, så det skulle indlæres med en smule opstartsproblemer, men det var også en succes. Til DDD anvendte vi ikke en så stor del af mappestrukturen som vi ellers gør på skolen, derfor kom der situationer, hvor vi måtte tolke på mapperne.
        Helt sikkert også et værktøj, som efterhånden vil blive anvendt mere og mere, men jeg tror der kommer til at gå tid inden det når ud til de mindre tegnestuer pga. kompleksiteten i opstartsfasen. Det vil med sikkerhed skræmme mange.

Det var de programmer jeg stiftede mest bekendtskab med. Ud over disse programmer blev der anvendt følgende programmer jeg kun har ringe kendskab til.

  • Solibri modelchecker og naviate – NaviateSolibri
    • Beskrivelse
      • Begge programmer er til at lave kollisionskontrol i. På den måde kan vi kontrollerer vores modeller passer sammen og  om der er sammenstødende objekter, for derefter at rette dem
    • Vurdering
      • Programmerne voldte problemer ved DDD. Både pga. det var nyt materiale der skulle læres, men også fordi der var forvirring omkring hvad programmerne formåede. Jeg mener programmerne begge er gode, men vi havde simpelthen ikke tid nok på de 3 dage til at give dem den tid de fortjente.
        I forbindelse med disse programmer og generelt med kollisionskontrollen stiftede vi bredt bekendtskab med IFC filformatet. Det er det format, der kan trækkes ud fra rigtig mange programmer, som deltager i byggeprocessen. De programmer vi kender bedst er Revit, auto-cad, magi-cad mfl. Her bruges IFC formatet til at udveksle informationer med mellem programmerne og dermed kan der udføres kollisionskontrol. Det var en vigtig lektie. Her er et link til en blog, som fortæller mere omkring dette format. IFC

Dette er mit sidste indlæg på bloggen angående DDD 2013. Jeg håber, at det har givet et indblik i, hvad man som studerende kan få af udbytte ved at deltage i DDD. Såfremt du har lyst til at spørge omkring indhold i mine indlæg eller andet er du velkommen til at skrive til mig.

– Peter Haven

peterhaven@gmail.com

Twitter: Klik her
LinkedIn: Klik her
Blog: Klik her

Reklamer

De Digitale Dage – BIM Koordinator dag 1

Som skrevet igår, vil jeg hver dag under DDD skrive om dagens oplevelser.

Da jeg ankom i dag, var jeg meget spændt på hvordan dagen ville forløbe. Jeg havde hørt fra tidligere deltagere at den første dag godt kunne opleves hektisk og en smule kaotisk. Det kan jeg kun give dem ret i.

De IDM-studerende havde givet os alle en dagsorden, hvori jeg som BIM-Koordinator, ansvarlig for projekweb, skulle starte dagen med at checke om alle de deltagene havde modtaget login og oprettet sig på iBinder (DDD’s Projektweb). Allerede her opstod nogle af dagens store problemer. Mange af deltagernes mail var ikke blevet tilføjet til deltagerlisten, og af samme grund var de ikke blevet tilføjet til iBinder. Pludselig gik megen af den tid der skulle bruges på at instruere i filnavngivning, til at få tilføjet de manglende folk. Denne opgave strakte sig stort set over hele dagen, hvor flere kom til for at få invitationen til iBinder.

Resten af vores opgaver var efterfølgende at kontrollere de filer der blev uploaded til projektwebben. Vi havde valgt kun at tildele en enkelt fra hver faggruppe muligheden for at uploade, for at minimere chancen for forkerte navngivninger, og det gav pote. Efter et par svipsere i starten af dagen, lærte de projektweb-ansvarlige i grupperne hurtigt at filnavngive ud fra Bips A104 – Dokumenthåndtering. Inden DDD havde vi udarbejdet en skabelon for dokumenthåndtering. Den skulle foregå på samme måde som en light udgave af en IKT-aftale, der udspecificerede; placering, fil-,tegning- og modelnavngivning. Den skulle være med til at sikre at folk fik en langt hurtigere forståelse, i stedet for at skulle gennemlæse hele BIPS A104.

Som dagen startede hektisk, sluttede dagen fredeligt og roligt. Efter der kom styr på deltagerliste og alle deltagere havde den fornødne adgang til iBinder. Havde vi tid til bedre at kontrollere at strukturen blev overholdt, samt lave konsistenskontrol på filer.

Dagen i dag har helt klart været utrolig lærerig, én ting er at sidde og læse i A104 om dokumenthåndtering, men en anden ting er at sidde med det i hænderne og bruge det som et redskab i et projekt, bestående af over 30 mennesker.

Det har allerede nu givet mig en langt bedre forståelse for filhåndteringen. Men også nogle problemstillinger jeg kan trække over i mit 4. semesters speciale. Gennem dagen, henvendte flere sig omkring placeringen af filer. Det skyldtes at i vores navngivning af filer bruger Vidensområde (K) og Indholdstype (C). Disse to metadata definerer placering og arbejdsområde. Det i sig selv gør, at man meget præcis kan definere fagområde og hvor filen præcis skal ligge. Problemet opstår dog, når filen i sin helhed kunne ligge flere steder, eller/også tilhører forskellige fagområder. Et eksempel vi stødte på tidligt, var bygherrens kravspecifikationer. Placering blev C08 (Specifikationer), men da den omhandler flere videnområder, var det pludselig svært at navngive og bygherrerådgiveren besluttede at give den, K01 (Arkitektur)

Jeg håber at dagens hektiske start og forvirringer har gjort, at vi i morgen er klar til at tage fat i nye områder, og ikke er nødsaget at bruge størstedelen på fejl invitationer. Men samtidig også byder på nye udfordringer, der skal løses i gruppen.

Mvh. Anders Norup

4. sem.
Mail: 1010937@ucn.dk
LinkedIn: Klik her

Video interview omkring brug af CAD manualer

Hej alle.

Først og fremmest håber jeg i alle har en god sommerferie, på trods af alt den regn 🙂
Den regn har dog også sine fordele! Og det er at man få tid til at surfe lidt rundt på nettet efter spændende ting indenfor den digitale verden.

Jeg faldt over dette interview, hvor bips er ude at snakke meget kort med et medlem omkring deres brug af CAD manualer i den daglige projektering. Det er ikke just fordi videoen er dybdegående eller giver et godt indblik i hvordan tegnestuen bruger CAD manualen, men jeg vælger at dele den med jer, så i ved at bips er ved at lave videoer omkring deres produkter (forhåbentligt flere end de få på deres youtube kanal – Se link herunder)
http://www.youtube.com/channel/UCbXlWm1jebLhWmIKTLtm7Iw

Go film! 🙂

/Kenneth Højbjerg
Mail: kenneth.hoejbjerg@gmail.com
LinkedIn: Klik her

Ny udgave af bipsnyt på gaden

Så er der en ny udgave af bipsnyt på gaden.
Der er en del guf til folk som gerne vil tilegne sig lidt ny viden om hvad der sker for tiden.
Samtidig er en spændende artikel om De Digitale Dage 2012.
Derudover:

  • Bygningsmodeller på tablet-computeren
  • DBK’s arvtager: cuneco classification system
  • bips’ nye fora for bygningsmodeller
  • Københavns Ejendommes ambitiøse strategi
  • Nyt fra beskrivelsesområdet
  • bips’ generalforsamling

Online version kan findes via www.bips.dk

Eller via dette Link: http://bips.dk/files/bips.dk/bipsnyt1-2012.pdf

/Kenneth Højbjerg, 7.sem
Mail: kh61324@ucn.dk
LinkedIn: KLIK HER

Fællesbibliotek og DBK kodning

Vi går alle og drømmer om det.
Et kæmpe stort fælles bibliotek bestående af nok objekter, tegningsstandarder, templates osv. til at vi bare kan køre derud af med alt vores BIM og DDB.
Men der er bare ikke nogle som har lavet sådan et endnu.

Hos aarhus arkitekterne er jeg lige pt. så heldig at være med til at udarbejde dele af sådan et fællesbibliotek og jeg vil rigtig gerne fortælle jer lidt omkring hvad det indebærer.

Hvad indeholder et fællesbibliotek?

Der er nogle helt grundlæggende emner, jeg ser som de bærende kræfter i et fællesbibliotek:

  • Families – Løst inventar
  • Families – Kompletterende bygningsdele
  • Sheet standarder
  • Tegningshoveder standarder
  • Projekt browser templates standarder
  • View templates standarder
  • Fælles navngivnings system af overnævnte emners filer

Det er disse emner der til sammen kan udgøre BIM kogebogen. Disse er samtidig min personlige definition af hvordan et fællesbibliotek bør se ud.
Her i vil man i bedste “madlavning for begyndere” have de ingredienser som skal bruges til et projekt. Og det gode ved dette fællesbibliotek er at ingredienserne altid kan genbruges, hvis sat rigtigt op.

Standarder er en mangelvare rent BIM mæssigt i den danske byggebranche, så jo før man får øjnene op for emner som disse og fokusere på at få dem lavet, jo før får man en bedre struktur på sine projekter.
Et firma vil jo heller ikke have at deres ansatte bruger hver sit brevhoved eller email signatur. Ensartet materiale er vejen frem og vil altid være det.

Klik for større billede

1 projekt af gangen.
Det er den fremgangsmåde jeg ser til hverdag og den virker rigtig godt. Hvorfor?
Jo, jo før man erkender at man ikke kan lave et fællesbibliotek rigtigt i første hug, jo nemmere gør man det for sig selv.

Illustrationen til højre viser en måde at sikre sig fremgang på en sikker måde.
Hvert projekt gennemarbejder en del af fællesbiblioteket og får lavet en masse tilføjelser, samt KS.

Når man når et bestemt punkt i projektet så hives hele fællesbiblioteket ud til revision og rettes op, så når næste projekt går igang, så står de med et frisk fællesbibliotek, hvor man ikke støder på de samme fejl som det første projekt havde.

Nogle vil kalde det for en langsomligt måde og at det ville være nemmere at lave fællesbibliotekets objekter langt mere detaljeret fra start af.
Det ville være en fejl at gøre sådan, da man med 100% sikkerhed vil finde fejl og mangler, og det vil være langt svære at rette til hvis det var alt for detaljeret.

Jeg vil ikke komme nærmere ind på selve objekt opbygning, eller hvilke former for data vi smider på dem. (Det kræver en meget lang forklaring, som vi helt sikkert kommer ind på senere).
I stedet for vil jeg gerne lige fortælle kort om det sidste punkt på listen.

Fælles navngivningssystem
Man kan sagtens kalde en spade for en spade, men det er bare ikke alle der definere en spade på samme måde. Derfor skal der et system til at holde styr på alle objektfilerne, eller bare filerne generelt.
Til dette bruger vi et smart system som Rambøll har lagt ud på nettet http://dbk.ramboll.dk/
Dette system er en simpel måde at lære DBK kodning på. Det er så simpelt at jeg efter et par uger on/off med det allerede kan tolke generelle dele af et filnavn bare ud fra DBK koden.

Rambølls DBK system er fra 2007 og som flere garanteret ved så er selve DBK systemet ved at blive revideret.
Dette skulle gerne være klar om et par år, men selv nu er det et godt system der har mange gode aspekter i sig. Specielt når Rambøll stiller det op på denne måde.

Jeg håber det gav en smule indsigt i hvordan et firma arbejder med fællesbibliotek og hvordan man bærer sig ad med at få det op at køre.
Det er en lang og sej kamp, men man kan kun blive imponeret over det gå på mod som rigtig mange firmaer har når det kommer til DDB og BIM.

Til sidst vil jeg gerne sige at man skal betragte BIM og DDB lidt som et palmeblad. Der er rigtig mange blindgyder og virkelig mange stop på vejen. Men før eller siden når man til tops.

/Kenneth Højbjerg, 6.sem

This slideshow requires JavaScript.

 Eksempler på fællesbibliotek opbygning der er under udvikling med DBK kodning

Digital fremlæggelse er en sjov størrelse. Part 1

Hej alle nysgerrige læsere.

Jeg har fået den store ære at få lov til at blogge lidt på IT-cafeen’s blog. “Hvorfor gør jeg nu det, når jeg ikke sidder dernede og hjælper folk?” Jo nu skal i høre! Jeg sad for nyligt i bil sammen med 3 personer der gør utroligt meget for konstruktør linjen i Aalborg. Under turen får jeg fortalt om dette projekt de har sat igang. En blog hvor elever og erhvervslivet skulle mødes og løfte problematikker sammen.

Da jeg blogger rundt omkring på nettet til hverdag, så fangede dette min interesse ret så hurtigt. Samtidig har jeg altid følt at jeg har noget at byde ind med på netop sådan en blog som denne her.

Dette indlæg her skal handle om mine personlige THE DO og THE DONT DO emner indenfor hele digital fremlæggelses processen, samt nogle af de ting jeg går og fifler med af nye ideer.

THE DONT DO liste:

Tro at digital fremlæggelse først begynder når man skal sætte power-point showet op 3-4 dage inden fremlæggelsen. Dette er en helt forkert holdning da der skal en overordnet struktur på ens mængde af filer. Da min gruppe og jeg sidste semester valgte at fremlægge digitalt, havde vi ikke tænkt over hvor meget unødvendigt arbejde der kunne opstå ved ikke arkivere alt ens materiale løbende og navngive det rigtigt med det samme. Heldigvis var det et andet fokusområde som vi ville give os i kast med, men det var slet ikke tænkt sammen fra starten af semestret.

Tro kvalitetssikring kun hører til tegninger og revit modeller. Ved alt den arkivering af filer, så V-I-L der opstå fejl i navngivning og placering af filerne. Dette er helt klart noget som der skal være fokus på undervejs i ens semester.

Først tage back-up’s af ens digitale arkiv langt henne på semestret. Jo større ens digitale arkiv bliver, jo farligere er det ikke at have en back-up, hvis tingene nu går galt.

Alle “diverse” eller “rodekasse” mapper til fil arkivering skaber oftest flere problemer end hvad der er godt.

Listen kunne nemt blive meget længere. Men det er disse hovedpunkter der efter min mening er vigtigst at have med sig hele vejen.

THE DO liste:

I et projekts opstart skal der findes et arkiverings system. Dette gælder primært en mappestruktur som gør det let og overskueligt at finde sine filer under hele projektet. Et godt råd ville være at fase inddele sine mapper.

Min gruppe valgte at bruge Projektweb som vores arkiveringssystem. Primært grundet back-up funktioner, søgefunktioner og metadata valgene. Samtidigt brugte vi Bips C204 og C212 navngivningssystemer til alle vores filer.

Ugentlige gruppemøder er på mange måder et must. Min gruppe har altid holdt et 1-2 timers møde hver tirsdag hvor vi gennemgik vores tidsplan, timer diverse problemer. MEN! vigtigst af alt, sørgede for at uploade alle dokumenter til vores arkiv (projektweb). Det var meget nemmere at smide de dokumenter op når vi lukkede dem, end at vente til sidst med at uploade alt på en gang.

Kvalitetssikring får større betydning. Fejl på tegninger ses ikke så nemt på en skærm, da man ikke kan se helheden på en gang. Vi 0plevede i gruppen flere gange hvor at fejl ikke blev opdaget, når vi ikke printede tegningerne ud og tjekkede dem igennem. Andre grupper nikker også genkendende til dette problem og de er også enige om en større fokus på kvalitetssikring.

Pdf format er vejen frem til en god præsentation! Når de dage kommer hvor søvn er en mangelvare og alt skal smækkes ind i nogle slide show’s, så er pdf formatet vejen frem. Når i selv vælger at sige “Nu laver vi ikke mere på projektet og gør klar til ophængning”, så gør jer selv den tjeneste at konvertere ALLE dokumenter til pdf. formatet. Det stiller mindre krav til lærerne og jer når i skal fremvise jeres projekter, da det så kun kræver 1 program i stedet for 5-6 forskellige.

Hyperlink til power-point bliver jeres ven. Hvis i vælger at bruge power-point til præsentations værktøjet, så står i over for et valg. 1. loade alle dokumenter ind i jeres power-point fil eller 2. lave en projekt mappe og hyperlinke alle dokumenter derind i power-point showet. Jeg har gennemført nogle tests af min gruppes power-point show hvor at det var hyperlinket og loadet ind.

Den hvor jeg loadede det hele ind, begyndte meget hurtigt at trække CPU og RAM, som et power-point show normaltvis ikke skal gøre. Dette skyldes først og fremmest en loadet power-point kommer op og fylde over 100mb (meget nemt.) Mens at en hyperlinket power-point fyldte 2,4 mb og ikke trak på CPU og RAM udover når PDF vieweren skulle åbnes.

Der findes rigtig mange råd og fif som også kunne bruges. Men i stedet for at skrive dem alle, vil jeg hellere fortælle nogle hovedpunkter jeg ser som vigtige og helt grundlæggende regler man bør tage til sig.

Denne tråd skulle helst bringe en masse gode debatter i fremtiden, da det er stadig er noget helt nyt for rigtig mange elever og lærere.

Jeg ser frem til debatten 🙂

/Kenneth Højbjerg, bk5b F2011

%d bloggers like this: