1 / 66

Objekt-orienterte Produktmodeller i Byggenæringen

Objekt-orienterte Produktmodeller i Byggenæringen. Av Eirik Kalstveit. Oppgaveteksten. Innledning Digital Produktmodellering Utvikling av konseptuell modell. Forstå produktet. Forstå produktutviklings-prosessen. Forstå produksjonsprosessen. Oppgaveteksten. Innledning

Download Presentation

Objekt-orienterte Produktmodeller i Byggenæringen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Objekt-orienterte Produktmodeller i Byggenæringen Av Eirik Kalstveit

  2. Oppgaveteksten • Innledning • Digital Produktmodellering • Utvikling av konseptuell modell Forstå produktet Forstå produktutviklings-prosessen Forstå produksjonsprosessen

  3. Oppgaveteksten • Innledning • Digital Produktmodellering • Implementering i et datamaskinverktøy Velge et høvelig verktøy Omsette konseptuell modell til et ”kjørbart” program i en datamaskin

  4. Oppgaveteksten • Innledning • Internasjonale prosjekter Standard for the Exchange of Product Model Data, ISO 10303 ISO/STEP (International Standardization Organisation) Felles informasjonsmodeller for petroleumsindustrien POSC/CAESAR (Petrotechnical Open Software Corporation)

  5. Oppgavebesvarelsen • Tilgjengelig på internett etter 15. desember • http://www.selvaag.no/diplom97.htm • Inneholder • Presentasjon av litteratur/web-studium • Modell av enebolig • Produkt/prosess-modell (eventuelt)

  6. System A System B Neutral format Circle NURBS Polyline Informasjonsutveksling Overføring av data er en tilnærming System A og B er bygget på forskjellig logikk, noe som gjør at dataoverføringen er lik, men logikken som tolker dataene avviker Ulike konsepter fører til uønskede avvik

  7. Hva er et produkt • Fysisk eller abstrakt objekt, med en kompleksitet som gjør det nødvendig med en eksakt definisjon, planlegging og koordinasjon for å realisere objektet • Typisk produkt: Bygninger, skip, biler, industrianlegg • Kan være enestående (Oljeplattform), eller masseprodusert (PC’er)

  8. Hva er en modell? • Et diagram er ikke en modell, men en representasjon av modellen. • En modell kan brukes av en ”modellmaskin” (F eks en PC) • En modell forenkler virkeligheten for å få frem ”kjernen” i det som skal produseres. ”A model is a structure that a system can use to simulate or anticipate the behavior of something else” -Marvin Minsky

  9. Utstyrs data-ark 3D DAK Eksempel: Ventil PCV0321 Eksempel på gjenbruk (flerbruk) av data. Ventil PCV0321 Hentet fra POSC/CAESAR prosjektet

  10. Hvorfor produktmodell? • Automatisere boligbygging • Fokus flyttes til kunnskapstilegning • Utveksling og deling av informasjon blir en viktig del av prosessen.

  11. Hvorfor produktmodell? • Effektiv bruk av IT forutsetter omorganisering av arbeidsprosesser • Kommunisere på nye måter • Informasjon blir delt mellom aktører • Standardiseringer av konsepter for å unngå feiltolkinger og kommunikasjonssvikt i byggeprosessen.

  12. Hensikt med en produktmodell • Kommunikasjon mellom involverte parter. (Gjensidig forståelse og idéutveksling?) • Informasjon utveksles og deles • Redusere kompleksiteten til et produkt. • ”Everything should be made as simple • as possible, but not simpler” • -Einstein

  13. Midtsirkelen og kanalene i figuren representerer produktmodellen og innfører en ny måte å organisere byggeprosessen på, der det ikke lenger er en bestemt rekkefølge på når ”ting” skjer ”Livshjulet” for et produkt Gjennom konseptuelt design blir hovedtrekk diskutert, og prinsipielle avgjørelser tatt. Detaljert design baseres på produktdefinisjonen, og innebærer spesifiseringer av løsninger. Her betraktes produktet som en enhet, de ulike valgte løsninger gir erfaringer og kunnskap Her blir produktet realisert, fra bunn til topp (bottom-up) fra detaljert til overordnet nivå

  14. Objekt-orientert tilnærming • ”Naturlig” å dele inn ”verden” i objekter • Fokus på dataoppbygging (struktur) for funksjon • Objekter har visse egenskaper og virkemåter • ”Samarbeider” med andre objekter. • Kommuniserer med andre objekter • Stabil base for utviklingsprosessen • Objekter er beskyttet mot uønskede • forandringer • Definerer problemorienterte objekter tidlig • Utvider disse objektene gjennom prosessen • Sømløs siden notasjonen er lik hele tiden • Hver iterasjon klargjør egenskaper i stedet • for å modifisere arbeid som allerede er gjort • ”Sømløs” utviklingsprosess • Utviklingsprosessen er iterativ (prøv og feil)

  15. Nordre Nes Enebolig nr 7 Konseptuell beskrivelse med notasjon etter Rumbaugh’s Object Modeling Technique

  16. Hva er en enebolig? Vegger, vinduer, dører og pipe etc etc En plass å oppholde seg Tegninger Mye arbeid!!!??? Kostnader

  17. KOSTNADSOVERSLAG Hvordan modellere en enebolig

  18. Design er en prosess som tilfører kunnskap fra et overordnet nivå, ned til en spesifikk forekomst En KATEGORI av konstruksjoner, f. eks boliger GENERISK En TYPE av konstruksjoner, f. eks enebolig type Nordre Nes KUNNSKAP SPESIFIKK ERFARING En spesiell FOREKOMST av typen, f. eks Nordre Nes hus nr 7 FOREKOMST Hovedfaser i modellen DESIGN (Beskrivelse) REALISERING (Slik det blir gjort) Realiseringen gir erfaringer tilbake til generisk nivå På generisk nivå finnes ”generell” kunnskap, det kan være prinsipper, metoder og teorier...

  19. Design vs Realisering • Design-nivå beskriver løsninger • Mest arbeid på realiseringsnivå • Komponentbiblioteket • Standard løsninger • Varekataloger (Fra leverandører)

  20. Økende detaljomfang • Objekter må være i stand til å ta vare på økende detaljomfang etter hvert som designfasen skrider frem. Skisse Plan Detalj (Fra A Ekholm: ”A conceptual framework for classification of construction work”)

  21. Klassifisering av objekter Objekter med en bestemt egenskap kan hentes fra en database, etter klassifisering Slik kan tradisjonelle bygningsklasser, men også f eks lyd-isolasjon og brann-motstand, organiseres • Objekter må kunne ha varierende funksjons- og komponent-egenskaper. (Fra A Ekholm: ”A conceptual framework for classification of construction work”)

  22. Forbindelse er et objekt som realiseres ved en standard løsning, men er også en relasjon mellom Vegg1 og Vegg2 ”Ting” kan være både objekt og relasjon

  23. Et rom er en relasjon mellom gulv, vegg og tak samtidig som det er et eget objekt med plassering og betegnelse ”Ting” kan være både objekt og relasjon TV-stue

  24. Kommentar/beskrivelse av objekt • Alle objekter bør referere til (eie) en kommentar som beskriver formål, funksjon og evt andre spesifikke ting. • Kommentar er et eget objekt. • Nyttig for å oppnå forståelse og entydighet • Bør kunne tilordnes flere verdier

  25. En attributt bør kunne ha flere verdier Verdi tilordnes/settes etter hvor man befinner seg i design-/prosjektfasen

  26. Eksempel: Kostnad • Kostnader er usikre i planleggingsfasen, da bruker man planlagt og forventet kostnad som verdi. • Egentlig kostnad får man først når bygget er ferdig bygget og regnskapet er sluttført. • Erfart kostnad gir da erfaringer tilbake til designfasen.

  27. Informasjon på ulike nivåer • 4 ”abstraheringsnivåer” • Informasjon kan realiseres fra ulike nivåer (Hentes i strukturen) • Alle subklasser kan ”arve” fra generisk ”superklasse”

  28. Eksempel: Boareal • Boareal kan hentes fra totalt boareal som kan være f. eks 170 m2. Design-nivå. • Boareal kan også kalkuleres vha alle roms areal. Verdien blir da hentet nedenfra i strukturen og fastsatt etter valgte løsninger. Verdien kan da være f. eks 168 m2.

  29. Relasjoner • Antall relasjoner mellom objekter i et system er stort • Oppstår som følge av: • Fysisk sammenkobling • Geometrisk oppbygging (rom) • Hierarkisk posisjon

  30. Ulike relasjoner • består av • dekomponering • er en slags • beskriver arv/slektskap • forbinder • relasjoner mellom objekter

  31. Ulike relasjoner • realiseres ved • et designobjekt realiseres ved valgt løsning fra komponentbiblioteket • leveres av • relasjon mellom produkt og leverandør

  32. Geometri/utforming • Kan med fordel beskrives ved egen objekt-klasse, kalt f. eks RefGeometri • Unngår problemer med kalkulasjoner fra f. eks transformasjonsmatriser som kan gi store numeriske operasjoner.* • Mindre risiko for feil, mer effektiv konsistenskontroll.* (*Kilde: Dale, S I: Object-oriented Product Modeling for Structural Design)

  33. Referansegeometri • To måter å representere oppbygning på: • Geometrisk • Topologisk • Geometri beskriver form og plassering i rommet til en figur. • Topologi er ”limet” som binder sammen geometrisk informasjon om punkt, linjer, flater og skall.

  34. Geometrisk • Er lagret i modellen som figurer, linjer etc. • En linje beskrives ved hjelp av en funksjon, f. eks: y = 1 + x • Kan ta unødvendig mye plass, da geometriske data er permanent lagret.

  35. Topologisk • Beskriver sammenheng mellom punkt, linjer og flater. • En linje, L1, beskrives som sammenkoblingen mellom 2 punkt p1 og p2 • Fordelen med topologisk representasjon av geometri er at informasjonen kan genereres når man trenger det, og man unngår feiltolking av informasjon om tilstøtende objekter.

  36. Hvordan behandle geometri? • Man bør bestemme seg for en måte å representere ting på. • Man bør bestemme hvilken geometri systemet kan behandle. • Det vil i alle tilfeller ligge mye arbeid i å utarbeide og implementere en fornuftig og brukende geometri-beskrivelse.

  37. Design-nivå Beskrivelse av hvordan ”ting” bør gjøres

  38. Felles attributter og beskrivelser • Attributter for alle objekter: • Symbol (F eks ikon) • Kostnad (På forskjellig nivå) • Byggetid (Erfaringsmessig)

  39. Design-nivå • Setter krav til og beskriver løsninger • Byggeforskrifter oppfylles • Standarder • Andre • ”Top-down”-design • Dekomponering av enebolig, man definerer hva en enebolig består av og grupperer de ulike delene etter ting som er felles

  40. Design-nivå • Objekter på design-nivå har attributter som avhenger av andre attributter: • Et rom er ikke et fysisk objekt, attributter finnes vha relasjonene mellom gulv, vegg og tak • Kostnad på design-nivå består av alle komponenters kostnader.

  41. Enebolig FASADE ETASJE- SKILLER ALTAN BYGNINGS SKJELETT VEGG ETASJE VINDU DØR TAK + MANGE FLERE + MANGE FLERE VEGG PIPE FUNDAMENT

  42. Enebolig • Fasade • Som oftest sammenhengende over flere etasjer. • ”Dekorativ” del av en enebolig • Bygningsskjelett • Beskriver oppbygning og tekniske løsninger ut fra forskrifter og standarder

  43. Enebolig, dekomponering

  44. Fasade • Fasade er et ”dekke” som beskytter bygningsskjelettet mot vær og vind. • Inneholder åpninger til vinduer, dører og ventiler. (Slf også til strøm, tlf o.a.) • Oppbygd av kledning, utlekting og forhudningspapp

  45. Bygningsskjelett • Trapp • Griper inn i 2 eller flere etasjer. • Trappeåpning beskrives spesielt • Etasje • Oversikt over rom og plassering av vegger, vinduer og dører. • Forbindelse • Realiseringen av forbindelsen er et eget objekt, men forbindelsen er også en relasjon.

  46. Bygningsskjelett • Pipe • Går gjennom alle etasjer og tak • Tak • Har en viss skråvinkel og kan være flere typer • Altan • ”Hektet” på en etasje • Fundament • Husets plassering i et boligfelt

  47. Bygningsskjelett

  48. Etasje • Etasje har objekter som hentes fra komponent-biblioteket.

  49. Trapp • Muliggjør adkomst fra en etasje til en annen • Har en relasjon til en etasjeskiller ved en forbindelse. • Relasjonen beskriver bl a plassering i etasje. • Kjøpes som regel fra leverandør som en del, eller i flere små deler som settes sammen på byggeplass

  50. Forbindelse • Beskriver alle forbindelser mellom objekter • Har en standard utførelse og hentes fra komponentbibliotek. • Realiseres som et objekt, men er også en relasjon mellom objekter

More Related