Workflow – (hodogram – grč. hodós: put + -gram – razrađeni plan, slijed radnji nekog organiziranog procesa) poveznica
Ovo su ključni koraci hodograma:
- Prvi korak je definiranje zahtjeva, što moramo imati prilikom isporuke BIM sadržaja, na koji se način očekuje doći do tih informacija. To se zove IDS – Information Delivery Specification – Specifikacija Informacija koje trebamo isporučiti , format je XML, čitljiv za ljude ali prvenstveno prilagođen računalu, gdje Naručitelj definira LOIN (Level of Informations Need), a ako to Naručitelj ne napravi Projektni ured koristi svoj IDS koji se bazira na uobičajenoj praksi i standardu kao što je ISO 19650.
- Drugi korak je kreiranje samih BIM, odnosno IFC podataka, netko ih treba modelirati u nekom od alata i konvertirati u IFC ili izraditi u native IFC alatu,
- Treći korak je provjera da li imamo IFC podatke u skladu sa zahtjevima iz IDS-a, što se može provjeravati ručno, ali se češće koristi uz pomoć alata kojima je namjena IDS Check, npr. BIM.works, putem online CDE (Common Data Environment)
- Četvrti korak je prijenos i razmjena informacija koje se prvenstveno odnose na odstupanja modela od zahtjeva, postoji BIM format za koordinaciju BCF – BIM Coordination Format čija je funkcija poboljšati komunikaciju sustavnim pristupom
- Opcija: Paralelno provjeri Zahtjeva (IDS check) postoji usluga Validation (koju razvija buildingSmart) kojom se nastoji provjeriti stvari koje nisu opisane u IDS-u, a važne su za cijeli tok posla. Dobar primjer je provjera sintakse, a pored toga Validation je nepristrana ocjena da li je neki IFC model dobar, kao sudac između raznih aplikacija koje se mogu koristiti za kreiranje IFC-a.
Detaljnije o IDS-u - Specifikaciji Informacija koje trebamo isporučiti
IDS (information delivery specification) se koristi za opisivanje zahtjeva koji se upotrebljavaju prilikom izrade BIM modela, a zapis je XML formatu, kako bi bio čitljiv računalu. Ima specifičnu strukturu. Primjer jedne stavke iz IDS-a je „svi prostori moraju imati podatak bruto površine“, a ovo je primjer kako XML dokument izgleda, njegov početak.
<ids:ids xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://standards.buildingsmart.org/IDS http://standards.buildingsmart.org/IDS/1.0/ids.xsd" xmlns:ids="http://standards.buildingsmart.org/IDS"> <ids:info> <ids:title>Example IDS</ids:title>
Sam tok aktivnosti započinje sa izradom IDS specifikacije na bazi predloška, što bi zapravo trebao biti zadatak naručitelja posla (A1), ti se podaci u nekoj prihvatljivoj formi dostavljaju osobi koja kreira model (A2), koja provjerava da li je softversko rješenje s kojim radi ima mogućnost pokriti zahtjeve (A3), slijedi modeliranje, odnosno, kreiranje podataka (A4). Nakon što su podaci kreirani provjerava se njihova usklađenost sa IDS-om (A6), ali se istovremeno nastoji podatke podići na višu razinu povezivanjem sa bSDD-jem (A5), nakon toga slijede dvije aktivnosti koje ovise o tome da li imamo grešaka (A7) kada je potrebno kreirati BCF u kojem će se specificirati što je sporno (i ispraviti greške), a ako takvih grešaka nema možemo pripremiti IFC sa IDS postavkama (A8) za potrebe slanja naručitelju. IFC se šalje naručitelju (A9), naručitelj provjerava usklađenosti sa IDS-om (A10), kada se krug zatvara i vraćamo se u (A1).
Postoji puno IDS editora na raspolaganju, jednako kao i softvera za provjeru IDS-a. Jedan primjer je BIM.works, to je potpuno otvoreni BIM CDE Common Data Environment. IDS je u XML formatu. Količina informacija koja se zapisuje je opsežna i uredno strukturirana. Zapis je čitljiv ljudima, ali je ipak fokus na zapisivanju informacija koje će računalo čitati.
Svaka pojedinačna stavka IDS specifikacije ima tri dijela, pojašnjenju je pridodan primjer „Svi zidovi moraju imati definiranu značajku otpornosti na požar “:
- Opis: namijenjen ljudima gdje je navedeno što je tema specifikacije i kako se to postiže. Tu se također obrazlaže kako različiti primjeri primjene utječu na samu specifikaciju. „Oznaka otpornosti na požar su važna značajka svakog zida“
- Primjenljivost: gdje je važno navesti elemente modela na koje se to odnosi, treba biti jasno na koje se elemente odnosi. Postoji uobičajena praksa kako se ti elementi definiraju, aspekti. „Ova se stavka odnosi na sve zidove“
- Zahtjevi: gdje se navodi koje to informacije taj element mora imati. „Svi zidovi moraju imati definiranu oznaka otpornosti na požar“
Da bi je jednom specifikacijom moglo kvalitetno prenijeti informaciju upotrebljavaju se Aspekti (Facet) koji imaju točno definirane parametre. Koriste se kod definiranja primjenljivosti (kada moramo odabrati dio modela na koji se odnosi) i kod definiranja zahtjeva (kada moramo odrediti ograničenja).
Postoji šest tipova aspekata: objekt, atribut, klasifikacija, značajka, materijal i dijelovi.
- Objekt (Entity), njegovi parametri su IFC klasa i predefinirani tip, a kao primjer se može navesti ‘IfcWall kao klasa i SHEAR kao predefinirani tip’. Iz toga se onda može prikazati zahtjev kao, mora biti IfcWall s predefiniranim tipom SHEAR
- Atribut (Attribute), čiji su parametri Ime i vrijednost, a kao primjer može se navesti ‘primjenjuje se na sve elemente čiji atribut Name ima vrijednost W01’, pa se tako kao zahtjev može pisati ‘Mora imati atribut Name čija je vrijednost W01’
- Klasifikacija (Classification), čiji su parametri sistem i vrijednost, a kao primjer može se navesti ‘odnosi se na elemente klasificirane pod Uniclass kao EF_25_10_25’, što se opet može zapisati kao zahtjev ‘mora imati referencu na Uniclass 2015 klasifikaciju EF_25_10_25’
- Značajaka (Property), čiji su parametri PropertySet, ime i vrijednost, a primjer može biti ‘primjenjuje se na elemente sa Property Setom Pset_WallCommon gdje je LoadBearing vrijednost TRUE ‘, što opet daje zahtjev kao ‘Mora imati Pset_WallCommon property set čija je značajka LoadBearing postavljena na TRUE’
- Materijal, čiji je parametar vrijednost, a kao primjer se može navesti ‘primjenjuje se na elemente čiji je materijal beton’, što daje zahtjev kao ‘mora imati materijal beton’
- Dijelovi (Parts), čiji su parametri objekt i odnos, a kao primjer možemo navesti ‘odnosi se na elemente koji se nalaze unutar IfcSpace’, a zahtjev bi bio ‘mora biti unutar IfcSpase’.
Slika: poveznica
Važno je napomenuti da se aspekti mogu i kombinirati. Svaka specifikacija mora definirati važnost, obvezan (required), opcija (optional) ili zabranjen (prohibited), što se može koristiti i kod aspekata.
Svaka specifikacija mora jasno naznačiti koja se IFC shema koristi … IFC4X3_ADD2 … IFC4 … ili … IFC2X3
bSDD - buildingSMART Data Dictionary
- to je online DataBase (in cloud), kao usluga
- tamo se može objaviti svoje standarde, bilo kao firma, organizacija, država, besplatno na upotrebu svima,
- nema veze sa standardima nego je to izvor podataka, sve se povezuje, sami definiramo uvjete korištenja,
- to nije CDE, Common Data Environment i ne koristi se za potrebe održavanje svojih standarda,
- stavka se može opisati sa puno parametara, po slobodnom izboru,
Ideja je povezati se na bSDD, na neki od standarda, učitati ga u svoje okruženje za rad s BIM podacima, odabrati nešto iz standarda i to povezati sa nekim elementom koji ste modelirali, popuniti obvezne podatke, pa se time dobije kvalitetan opis elementa.
IDS i bSDD predstavljaju zapise dogovor oko sadržaja podataka. Ali IDS je standard koji je oblikovan kako bi pokupili podatke, a bSDD je usluga koja sadrži puno pojmova i definicija koje možemo koristit za te potrebe (u tom kontekstu). Zato bSDD treba gledati kao dijeljenu biblioteku značajki koje se mogu koristiti prilikom izrade IDS-a.
IDS - u praksi
Moramo govoriti o informacijama, podacima koji su semantički korektni, bogati. To je osnova. Moramo znati što nam treba, nije dovoljno reći treba mi IFC ili treba mi LOD350, ili trebaju mi stube, to nije dovoljno jasno.
Dobar je primjer je “Treba mi set informacija u kojima su barem jedne stube, a stube trebaju imati broj i dimenziju visine i širine gazišta, te berem jednu stubu“. Ove se informacije mogu koristiti uz pomoć tablica, ali je IDS sa svojom XML strukturom upravo rješenje za to.
IDS nije namjenjen za definiranje pravila projektiranja, nego pravila o sadržaju informacija, ono što moramo imati. U IDS-u nema If Then Else. Lokalni prijevodi se rješavaju bSDD-jem i ne koriste se u IDS-u. Također nema OR.
