Rail Baltic IFC standard: mida käsiraamat ei ütle
Rail Baltic Estonia projektidel töötades tekkis mul ühel hetkel kahtlus. IFC eksport ArchiCADist oli alati keerulisem, kui peaks — mitte tööriistas endas, vaid selles, et polnud täpselt selge, millised RBR-* atribuudid kuuluvad millisele IFC klassile. Standard ütles „pane kõik RBR-Data-sse" — aga ei öelnud, et IfcWall saab need konkreetsed atribuudid ja IfcDoor need. Kõik ühte potti.
§01 — KAHTLUSKas puudujääk on minus või standardis?
Kaks varianti: kas mul on midagi läbi lugemata jäänud, või on standardis tõesti lünk.
Et vastust saada, lasin AI-l kogu RBE BIM nõuete kausta läbi kammida. Kuus põhidokumenti, 11 203 rida. Paralleelselt Excel maatriksid — mis on defineeritud, mis mitte, kas kusagil viidatakse konkreetsetele IFC klassidele või standardsetele property settidele.
Vastus oli selge: puudujääk on reaalne. Mitte minu teadmistes — standardis endas.
§02 — RAAMISTIKMida raamistik hästi katab
Rail Baltic Estonia raamistik on mastaapne. Arhitektuuri jaoks on seal:
- 120 elemendiprefiksit — igale seinavariatsioonile, ukse- ja aknaliigile, sambale, tarinale oma kood (EWL, IDO, WIN, COL, ...).
- Uniclass 2015 klassifikatsioon — iga prefiks vastendatud Pr- või Ss-koodiga.
- LoG × LoI maatriks — mis geomeetria ja mis andmed peavad olemas olema igal projektietapil (VE 200 → MD 300 → DTD 400 → CO 500).
- RBR-Data atribuudid — kogu projekti kodifikatsioon läheb ühte property setti nimega
RBR-Data. - IFC versioon — eelistus IFC4 Design Transfer View, varunõue IFC4 Reference View, viimase abinõuna IFC2x3 CV2.
Kõik see on olemas. Detailselt, eestikeelselt, viidatult.
§03 — LÜNKÜks lause ja 11 203 rida
Uuringus otsisime kuuest dokumendist konkreetseid IFC klasse ja standardseid property sette — IfcWall, Pset_WallCommon, IfcDoor, PredefinedType. 11 203 rida teksti.
Tulemus: kaks vastet. Mõlemad üldised — üks loetleb IFC serialiseerimisformaadid (.ifc / .ifcxml / .ifczip), teine selgitab Pset_name mõistet abstraktselt.
Ainus konkreetne IFC-sisu juhis on üks lause, mis kordub kaks korda:
„Atribuudid peavad sisalduma IFC failis ning olema rühmitatud vahekaardile
RBR-Data."— BIMManualEt §15.3
See on kõik. Milline IFC klass peaks EWL-i kandma — SOLIDWALL või PARTITIONING? Kas RBR-Object_ID peab olema ka IfcElement.Tag väljas? Standard ei ütle. Kõik see jäetakse iga töövõtja enda BEP-i otsustada.
§04 — AUTOMAATIKAKus automaatika praegu murdub
See ei ole ainult teoreetiline probleem. Rail Baltic projekti QTO ja QEX — mahutabelid ja andmepakid, mida igal milestone'il tuleb esitada — peaksid olema automatiseeritavad. Kui iga IFC klass kannab täpselt oma RBR-* atribuudid, saab andmepakid genereerida otse mudelist. Automaatika on triviaalne.
Praegu see nii ei tööta. ArchiCADis saab RBR-* propertid ilusti teha — tabel on olemas, atribuudid täidetud. Aga kuna juhendis puudub kaardistus formaadis IfcWall → [RBR-Width, RBR-Length, ...], IfcDoor → [RBR-Width, RBR-Height, ...], ei saa IFC Translatorsiga teha per-klass mappingut. Mapping läheb juur-tasandile — sein, uks, post, ruum saavad kõik samad atribuudid. RBR-NetFloorArea ei kuulu sambale. RBR-NumberOfRisers ei kuulu seinale. RBR-Data on täidetud, aga kas õigete väärtustega õigetel elementidel — seda ei tea ilma kontrolltabeliteta. Kontrolltabeleid ei pea tegema iga milestone'i korral, aga miks peaks neid tegema üldse? ÜBN on sellele küsimusele juba vastuse andnud. IFC loogika pole muutunud.
§05 — LAHENDUSMida õige alus võimaldaks
Lahendus on lihtne kontseptuaalselt: kaardistus formaadis IfcWall → [RBR-Width, RBR-Length, RBR-Height, ...], IfcDoor → [RBR-Width, RBR-Height, ...], IfcSpace → [RBR-NetFloorArea, RBR-Room_Name, ...]. Iga IFC klass saab täpselt need RBR-* propertid, mis on selle elemendi jaoks relevantsed — mitte kõike kõigile.
Sellise kaardistuse olemasolul saab teha õiged IFC templid kõigile tarkvaradele korraga — ArchiCAD IFC Translators, Revit export configuration, Allplan. Iga tarkvara seadistab sama loogika oma formaadis, aga tulemus on ühtne. Töövõtja ei pea ise otsustama, mis IfcWall-ile külge läheb. Ja koodiga saab kirjutada tööriista, mis loeb IFC välja ja genereerib QTO/QEX tabelid otse — sest nüüd on teada, kust iga elemendiliigi jaoks millist väärtust otsida.
Võrdluseks: ehitus.ee ÜBN platvorm teeb seda juba. Iga IFC klassi kohta on täpselt kirjas, mida oodatakse — millised property setid, millised atribuudid, milline klassifikaator. Kui mudel ei vasta, saad konkreetse veateate konkreetse elemendi kohta. IFC loogika pole muutunud. Miks polnud see RBE raamistiku aluseks?
Lahendus on buildingSMART IDS — Information Delivery Specification. IDS järgib täpselt sama loogikat, mida IFC kasutab: iga reegel on seotud konkreetse IFC klassiga, konkreetse atribuudiga, konkreetse oodatava väärtusega. ArchiCAD ja Revit ei loe IDS-i automaatselt — tarkvara tuleb ikka käsitsi seadistada. Aga IDS-i saab avada veebivaaturis või XML-vaaturis ja seal on kogu nõutav struktuur inimloetavalt kirjas: mis klass, mis atribuut, mis väärtus. See on täpne alus, millest authoring tarkvara konfiguratsiooni tuletada. Solibri ja BIMcollab loevad IDS-i otse — mudeli valideerimine käib IDS vastu automaatselt. Selle puudumine maksab integratsioonitunde igal koordineerimisringil kogu projekti vältel.
Jah — Rail Baltic Estonia kontekstis on see hiline avastus. Projekt on käimas, töövõtjad töötavad olemasolevate juhenditega. Aga see ei tähenda, et sellest ei peaks rääkima. Parem hilja kui mitte kunagi, ja paremad templid tuleviku etappides on ikka paremad kui mitte midagi.