1. Klasy w schemacie IFC
W świecie IT każdą rzecz/obiekt można opisać jako tzw. klasę, podając jakie ma atrybuty oraz jaki jest typ danego atrybutu. Pisałem o tym w poprzednim artykule “Sekrety formatu IFC”:
“Istotne z punktu widzenia inżyniera są również przypisane im (obiektom) atrybuty (drzwi mają wymiar, materiał, z którego są zrobione, położenie w przestrzeni). IFC opisuje każdy z elementów jako klasę. Może wydawać się to nieco zagmatwane, ale w uproszczeniu chodzi o to, aby każdy element posiadał listę atrybutów (nazwę, materiał, położenie, wymiary) oraz rodzaj wartości każdego atrybutu (tekst, liczba, współrzędne itp.)“
1.1 Klasy jako szablon atrybutów
Dla obiektu drzwi taki szablon wyglądałby jak na grafice poniżej:
Tego typu opis obiektu daje nam pewność, że niezależnie z jakiego programu zostanie wygenerowany model IFC, atrybuty obiektu będą zawsze w tym samym formacie, a więc “Nazwa” to będzie zawsze tekst, a “Wysokość” to zawsze będzie liczba.
Wypełniony szablon obiektu drzwi bedzie wygladal nastepujaco:
Klasy niekoniecznie muszą być fizycznym obiektem takim jak np drzwi (IfcDoor) czy ściana (IfcWall). Klasie moze byc rowniez przypisane zadanie ( IfcTask), opisane atrybutami jak poniżej:
Ponownie mamy pewność, że opisując klasę poprzez atrybuty oraz typ wartości, atrybut JestKamieniemMilowym będzie zawsze w formacie Tak lub Nie (a nie np. może, prawie, 0/1 etc.)
Schemat IFC posiada także bardziej abstrakcyjne klasy, takie jak “powiązania” (Relationships), które opisują w jaki sposób można powiązać ze sobą obiekty przy pomocy atrybutów.
Więcej informacji na temat “powiazań” w schemacie IFC przedstawia poniższa grafika:
Można w ten sposób powiązać ze sobą zadanie (Task) np. Etap 1 z elementami budynku – Ściany Poziom 1 ( a więc wszystkie ściany z poziomu pierwszego budynku).
Moze wydawac sie to z początku skomplikowane, lecz w gruncie rzeczy jest to bardzo logiczna struktura.
Schemat IFC ma zdefiniowane kilkaset klas, dzięki czemu możliwe jest zdefiniowanie niemal wszystkiego w projekcie ( a ponadto można nadać dodatkowe Property Sety..ale o tym w kolejnych postach).Sama nazwa IFC Industry Foundation Classes odnosi się zatem do obiektów (opisanych jako klasy poprzez atrybuty i typ danego atrybutu) będące podstawowymi (fundamentami) w przemyśle budowlanym i zarządzaniu obiektami budowlanymi.
Kiedy mowa jest o eksporcie modelu z programu natywnego ( Revit, Tekla, Archicad) w rzeczywistości chodzi o “wypełnienie” przez to oprogramowanie szablonów klas poprzez odpowiednie wartości atrybutów. Najistotniejszy jest fakt, iż każdy program wypełnienia taki sam szablon, tymi samymi typami wartości a więc mamy pewność, że wyeksportowany model jest uniwersalny.
2. Dziedziczenie atrybutów (Inheritance)
W poprzednim artykule wspomniałem również, iż schemat IFC ” (…) nie składa się z płaskiej struktury oddzielnych elementów i ich atrybutów, lecz tworzy raczej drzewo wzajemnych powiązań.” Strukturę tę można porównać do drzewa genealogicznego.
W drzewie tym można wskazać “rodzica” oraz “potomka” Od rodziców natomiast możemy odziedziczyć wiele cech np: kolor oczu, włosów, wzrost, charakter…
Oznacza to, że atrybuty szablonów w schemacie IFC mogą być przekazywane od “rodziców” do “dzieci”.
Zanim przejdę do omawiania schematu, posluze sie przykladem z życia codziennego aby przybliżyć Ci na czym polega dziedziczenie atrybutów.
Wyobraź sobie że masz pojazd, który posiada takie cechy (atrybuty) jak:
- Waga (1500 kg)
- Kolor (srebny)
Pojazdem może być samochód posiadający atrybut:
- Marka (Ford)
Samochod moze byc w wersji kombi i posiadać takie atrybuty jak:
- Ladownosc (200 kg)
Co oznacza dziedziczenie atrybutów w tym przypadku ?
Kombi posiada ładowność oraz odziedziczone atrybuty “marka” – Ford oraz “kolor” – czarny i “waga” – 1500 kg.
Samochód posiada atrybut “marka” – Ford oraz “waga” – 1500kg oraz “kolor” – czarny. Natomiast nie posiada “ładowności”. Pojazd z kolei posiada “wagę” i “kolor” lecz nie posiada “ładowności” ani “marki”.
Podobnie wygląda dziedziczenie atrybutów w Schemacie IFC.
Popatrzmy jeszcze raz na szablon drzwi:
I porównajmy ten szablon z podobnym szablonem reprezentującym płytę IfcSlab.
W obu przypadkach atrybuty sie powtarzaja zarówno w szablonie drzwi jak i w szablonie płyty.
Poprzez analogię do przykładu z pojazdem obydwa szablony maja szablon nadrzędny – w schemacie jest to IfcBuildingElement.
Szablon ten będzie zawierał wszystkie atrybuty, które zawierają drzwi i płyta.
IfcBuildingObject
W jaki sposób zatem w schemacie IFC wykorzystywane jest “dziedziczenie”? Otóż w ten sposób, iż atrybuty w szablonie są wpisywane tylko raz. Jeśli dany atrybut powtarza się w szablonie “dziecka” jest on pomijany aby nie dublować tych samych atrybutów.
A więc szablon dla drzwi IfcDoor wygląda w myśl tej zasady mniej więcej tak:
IfcDoor
Szablon dla płyty IfcSlab z kolei:
IfcSlab:
Poniższa grafika w przystępniejszy sposób przedstawia ten proces:
Generalnie wynik końcowy jest taki, jakbyśmy napisali te wszystkie atrybuty ponownie. Wyeliminowanie całej wiązki tekstu sprawia, że gdybyśmy chcieli zmienić jakiś atrybut, musielibyśmy to zrobić tylko w jednym miejscu. Przydatne prawda?
3 Schemat IFC - drzewo genealogiczne
Jeśli odwiedzisz stronę buildingSmart i spojrzysz na specyfikację schematu IFC https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/ , możesz czuć sie nieco zdezorientowany widzac taki zapis klasy IfcDoor:
Lecz jeśli przedstawię go w uproszczeniu jako drzewo genealogiczne, schemat wydaje się bardziej zrozumiały i przejrzysty a linia wzajemnych powiązań jest dużo czytelniejsza.
Podsumowanie
Widzisz teraz, że z pozoru różne rzeczy w schemacie są do siebie jednak podobne.
Dwie tak odmienne klasy jak obiekt (IfcObject) oraz proces (IfcProcess) maja w rzeczywistości sporo wspólnych odziedziczonych atrybutów. Każda klasa w schemacie posiada Globalny Identyfikator GUID, Historię właściciela, Nazwę i opis odziedziczony po nadrzędnym dla wszystkich klas szablonie IFCROOT.
Użycie standardowych, uniwersalnych szablonów, sprawia, że informacje, które są przekazywane i wykorzystywane w procesie budowy, są prostsze do kontrolowania i bardziej przewidywalne ( w końcu w BIM najważniejsze jest I – informacja). Zwłaszcza, jeśli chcemy zautomatyzować, usprawniać i przyspieszać procesy używając programów komputerowych.
Fakt, że atrybuty w całym schemacie (drzewie genealogicznym) są dziedziczone, sprawia, że mamy absolutna pewnosc, ze format atrybutu dla różnych klas będzie zawsze ten sam. NIe zdarzy się sytuacja, że wysokość drzwi będzie wyrażona w formacie : 120 cm a wysokość okna : metr dwadzieścia.
Inny przykład? Wyobraź sobie, że używasz programu do tworzenia zestawień drzwi. Grupuje je używając atrybutu Typ (IfcObjectType) – np. Drzwi Typ1, Drzwi Typ2 itd. Program odczytuje zatem ten atrybut. Latwo zauwazyc teraz, że ten sam program, bez problemu stworzy zestawienie Okien( IfcWindow), czy ścian (IfcWall) gdyż ich struktura jak pisalem wyzej jest w gruncie rzeczy bardzo podobna dzięki uniwersalnym szablonom i dziedziczeniu atrybutów.
Mam nadzieję, że ten artykuł przybliżył Ci trochę logikę schematu Ifc oraz jego uniwersalność i szerokie spektrum zastosowania. A w jaki sposób Ty używasz modeli Ifc? Podziel się swoimi doświadczeniami i spostrzeżeniami.
Artykuł jest OK, ale mam nieco uwag. Ja rozumiem, że to jest o IFC, ale nie można tego traktować wybiórczo, bo to nie wytłumaczy całego środowiska:
1. Abstrakcyjna (komputerowa) struktura IFC nie jest oderwana od rzeczywistości, jest ona powiązana ze strukturami codziennego świata budowlanego. Kod maszynowy (IFC i inne formaty) posługuje się tzw. GUIDs, a rzeczywistość używa IDs (np. GTIN w systemie identyfikacji GS1). Chodzi o to, żeby powstał spójny ciąg informacji (puryści powiedzieliby o flow) od elementu na komputerze projektanta do elementu w aplikacji do Facility Management, czyli fazie operacyjnej biznesu, a eksploatacyjnej tzw. zasobu (według nomenklatury serii ISO 19650).
Otóż w Polsce tego “flow” nie ma. Brakuje środkowego ogniwa, czyli klasyfikacji budowlanej. Klasyfikacje w krajach, gdzie ona już jest, posługują się tym samym drzewem hierarchicznym, co IFC, a dodatkowo dla poszczególnych jego poziomów istnieją stopnie nasycenia informacją LOD (Level of Development). I tak LOD 100 jest tylko dla brył formy architektonicznej (IfcBuilding), LOD 200 ewentualnie dla kubatur zgrupowanych funkcji (IfcSpace). Nikt nie modeluje np. krzeseł w fazie koncepcyjnej (~ LOD 100).
Normy ISO dla klasyfikacji (12006-3 oraz 81346-2 czy 81346-12) naśladują w tabelach strukturę IFC. Celem ma być mapowanie wszystkiego ze wszystkim, żeby w dużych projektach, zwłaszcza światowych, z wieloma klasyfikacjami równocześnie, zamówienie materiało czy produktu mogło być niezależnie z jakiej klasyfikacji na bazie projektowego IFC było zamawiane.
Odpowiedzialna jest za to matryca bSDD (implementacja IFD), żeby przy pomocy sekwencji IfcGuid <> IfdGuid <> GTIN (sGTIN) była stworzona komunikacja.
Samo IFC jest abstrakcyjne, nie-projektantom ciężko to jest zrozumieć, więc dobrze jest podeprzeć to praktycznym zastosowaniem.
2. IFC przenosi co prawda dane geometryczno-topologiczne (LOG – Level of Geometry) i alfanumeryczne (LOI dla informacji), ale obecnie w buildingSMART International trwają prace nad kompletnym rozdzieleniem tych dwóch typów informacji (nazwa robocza ‘decoupling’).
Będzie to korzystne pod względem zarówno wielkości plików (choć IFC są i tak mikre), ale przede wszystkim projektanci będą się mogli zająć czystą geometrią (nawet ponownie zastosowywaną w innych projektach), a nad informacją tekstową będą pracować inni specjaliści, od projektowania zachowania energetycznego, od ochrony ppoż. itp. W ten sposób także specyfikacja kolejnych wersji IFC będzie prostsza.
Generalną uwagą jest to, że IFC nie nadaje się za bardzo do zadań supply chain (łańcucha dostaw) bez powiązania z produktami poprzez bSDD, a nawet dla produktów no-name (dolny poziom klasyfikacji budowlanej), bo sugerowane w nowoczesnych klasyfikacjach tabele atrybutów zamiast nowych poziomów kodów klasyfikacyjnych także w różnych krajach mają różne nazwy, typy i wartości parametrów, choćby amerykański system imperial vs. metric.
O tym wszystkim należy wiedzieć, zajmując się IFC, które jest tylko dla modelu na komputerze…
Ale i tak dobra robota, dzięki 🙂
-rob-