W poprzednim wpisie o Open BIM pokazałem przykład tabeli wymagań. Sprawdziliśmy, jak poprawne właściwości IFC zamieniają chaotyczną wymianę informacji w coś, co można ogarnąć.
Ale jest haczyk: nawet gdy wiesz, jakich danych potrzebujesz, tradycyjna dokumentacja tworzy inne problemy. Arkusze Excel i PDFy zawodzą w tym, co najważniejsze – w upewnieniu się, że właściwe informacje zostaną faktycznie poprawnie.
Koszmar ręcznej kontroli jakości
Kiedyś ręcznie sprawdzaliśmy każdy eksport IFC względem wymagań. Pamiętam, jak spędzałem całe tygodnie z Solibri, tworząc reguły walidacji danych i klikając przez tysiące uwag. Połowa z nich to duplikaty, których nie mogłem wcześniej odfiltrować.
To było okrutnie nużące i podatne na błędy.
Bez automatycznej walidacji zespoły zmagają się z:
- Ręczną weryfikacją danych modelu względem specyfikacji
- Subiektywną interpretacją “poprawnych” informacji
- Późnym wykryciem brakujących lub niepoprawnych danych
- Oprogramowaniem, które ledwo coś weryfikowało poza kolizjami fizycznymi
Aktualizacje były prawie niemożliwe
Niejednoznaczność komunikacji
Rozwiązanie
Na szczęście około roku temu BuildingSMART przyszedł z rozwiązaniem tych problemów. Rozwiązaniem, które jest otwarte, darmowe i zautomatyzowane.
I łatwe do wdrożenia zarówno w projekcie, jak i przez producentów oprogramowania.
Zainteresowany?
Poznaj Information Delivery Specification.
Czym jest IDS (Information Delivery Specification)
Information Delivery Specification (IDS) to standard buildingSMART, który definiuje wymagania informacyjne. IDS jest format oparty na formacie XML, który ludzie mogą czytać, a komputery mogą interpretować i przetwarzać automatycznie.
W swojej istocie IDS określa dokładnie, jakie informacje muszą być dostarczone w modelach BIM i jak powinny być ustrukturyzowane. Umożliwia precyzyjną definicję wymagań dla obiektów IFC.
Plik IDS może zawierać wiele niezależnych wymagań. Dzięki temu możesz kopiować i wklejać te bloki między różnymi plikami IDS.
Co zmienia IDS
Information Delivery Specification jest czytelny maszynowo. Komputer rozumie, czego potrzebujesz. Koniec z miejscem na interpretację w stylu “prawdopodobnie chodziło im o to”.
Oprogramowanie wie dokładnie, co sprawdzać.
Proces wygląda następująco:
- Tworzysz wymagania w IDS
- Wgrywasz model i plik IDS do oprogramowania walidacyjnego
- Oprogramowanie sprawdza model względem wgranego IDS
- Dostajesz raport z uwag
Bez ręcznego klikania, bez zgadywania.
Plus: to otwarty standard. Darmowy, dostępny dla wszystkich, wspierany przez rosnącą liczbę narzędzi BIM. Każdy może go używać już dziś.
Korzyści dla twojego zespołu:
- Właściciele aktywów precyzyjnie określają, czego chcą
- Zespoły projektowe widzą wyraźnie, co muszą dostarczyć
- Walidacja działa automatycznie
- Walidacja danych stała się dostępna w wielu programach!
Do czego IDS nie służy
IDS jest potężny, ale nie został stworzony do wszystkiego. Zrozumienie jego ograniczeń ma znaczenie.
IDS nie może:
- Tworzyć niejednoznacznych warunków (np. potrzebuję wystarczającej ilości świeżego powietrza w tym pomieszczeniu). Musisz być konkretny z zakresem w metrach sześciennych na godzinę lub krotności wymian powietrza)
- Definiować wymagań projektowych (odległość komponentów, wolna powierzchnia otwarcia, analiza oświetlenia, itp.). IDS może wymagać danych, nie geometrii.
- Tworzyć zagnieżdżonych reguł dla wielu typów obiektów (np. jeśli przestrzeń jest drogą ewakuacyjną, to drzwi muszą mieć odporność ogniową). Musisz stworzyć osobne specyfikacje dla tego.
Struktura pliku IDS
Pliki IDS używają formatu XML, zapewniając dane zarówno dla ludzi, jak i komputerów. Struktura przestrzega standardów XML.
Plik IDS składa się z dwóch głównych elementów:
Sekcja metadanych
Zawiera ogólne informacje:
- Tytuł, wersja, autor, data utworzenia
- Opis i cel wymagań
Sekcja specyfikacji
Applicability (Filtr)
Sekcja applicability definiuje, które elementy z modelu IFC powinny być wybrane do sprawdzenia. Działa jako filtr stosowany do całego modelu IFC.
Możemy filtrować elementy według typu, właściwości, klasyfikacji lub innych kryteriów nazywanych “Facets” (przetłumaczny to na “aspekty”).
Przykłady w języku ludzkim:
- Pokaż mi wszystkie ściany z modelu
- Pokaż mi ściany, drzwi i okna, które mają odporność ogniową
- Pokaż mi ściany, belki i słupy wykonane z betonu
- Pokaż mi wszystkie obiekty nośne
Requirement (Reguły)
Określa, jakie warunki muszą spełniać wybrane (przefiltrowane) elementy z sekcji applicability.
Możemy określić te wymagania dla właściwości, klasyfikacji, materiałów i relacji. Są one również definiowane przez te same “Facets” co w applicability.
Wymagania definiują dokładne informacje, które muszą być obecne i poprawnie sformatowane. Możesz określić, czy chcesz:
- Dowolną wartość
- Dokładną wartość
- Brak wartości
- Listę wartości
- Wartości ograniczone
- Długość
- Wzorzec regex
Sześć aspektów
Termin “facets” pochodzi z terminologii XML. W kontekście IDS facets opisują, jak różne aspekty wymagań informacyjnych są ustrukturyzowane.
Tak jak kamień szlachetny ma wiele faset odbijających światło w różny sposób, wymagania IDS badają różne “oblicza” informacji budowlanych:
- Każdy aspekt reprezentuje inny wymiar walidacji informacji
- Facets mogą być łączone w celu stworzenia kompleksowych wymagań
- Modułowa natura pozwala na elastyczne tworzenie specyfikacji
- Wiele aspektów może stosować się do tych samych obiektów jednocześnie
Istnieje 6 różnych aspektów w IDS, opiszę je poniżej:
Entity
Faset Entity definiuje, które typy obiektów IFC chcesz sprawdzić. To twój punkt startowy identyfikujący konkretne elementy budowlane do sprawdzenia i tworzy fundament dla dalszych wymagań.
Przykład definicji:
- “Chcę sprawdzić wszystkie ściany” więc wybierasz IfcWall
- “Chcę zobaczyć każde drzwi w tym modelu” więc wybierasz IfcDoor
- “Chcę zobaczyć wszystkie elementy konstrukcyjne” – wybierasz IfcSlab, IfcWall, IfcColumn i IfcBeam (i może IfcMember lub więcej, w zależności od budynku)
Property
Obsługuje wszystkie te właściwości, które tworzą dane modelu. Standardowe zestawy właściwości, z którymi będziesz pracować, obejmują właściwości ze schematu IFC Common Property sets, jak również Custom Defined Properties.
Właściwości wbudowane w schemat IFC znajdziesz tutaj.
Przykład definicji:
- Pset_WallCommon ma właściwość FireRating z akceptowalnymi wartościami jako REI30, REI60 lub REI90
- Dla niestandardowego property set Pset_Manage ma właściwość Responsibility, która podąża za wzorcem “litera R i 3 cyfry” (R210). Zapisałbyś to w REGEX: /^R\d{3}$/
Attribute
Atrybuty, krótko mówiąc, to stałe, podstawowe pola metadanych przypisane bezpośrednio do klas IFC. Są spójne i dziedziczone przez hierarchię klas IFC.
To na przykład GlobalId, Name, Description.
Przykład definicji:
- Poziomy budynku powinny mieć nazwę tylko z tego zakresu: Level 01 – Level 09
Classification
Ten aspekt obsługuje standardy branżowe oraz klasyfikacje zdefiniowane w projekcie. Przykłady to Uniclass, Coclass lub inne narodowe standardy klasyfikacji.
Przykład definicji:
- Klasyfikacja Coclass: wszystkie komponenty central wentylacyjnych mają kod KP.CD.AC
Material
Faset Material określa wymagania i właściwości materiałowe, definiując relacje i charakterystyki materiałów. Ten facet zapewnia właściwą specyfikację materiałów.
Przykład definicji:
- Wszystkie słupy konstrukcyjne są wykonane z betonu
PartOf
Budynki mają strukturę i hierarchię. Ten facet waliduje relacje przestrzenne, zapewniając, że elementy są właściwie zawarte w budynkach i zlokalizowane na odpowiednich piętrach. To najbardziej zaawansowany facet (i najmniej używany).
Przykład definicji:
- Czy każda rura ma izolację
- Czy każdy element należy do konkretnego systemu
Kardynalności
Kardynalności w IDS to restrykcje, które definiują, czy wymagania informacyjne są obowiązkowe, opcjonalne czy zabronione. Określają zachowanie walidacji dla każdej specyfikacji:
- Required (Wymagany) – Element, właściwość lub faset musi być obecny. Walidacja pokazuje błąd, jeśli wymaganie nie jest spełnione. Najpopularniejsza kardynalność.
- Optional (Dowolny) – Element, właściwość lub aspekt może być obecny, ale nie jest obowiązkowy. Walidacja przechodzi niezależnie od tego, czy wymaganie jest spełnione, czy nie. Może być przydatna dla rekomendacji.
- Prohibited (Zabroniony) – Element, właściwość lub faset NIE może być obecny. Walidacja zawodzi, jeśli zabroniony element zostanie znaleziony. Przydatne do wykluczania pewnych konfiguracji lub przestarzałych właściwości.
- Przykład: jeśli cały projekt jest w LOD350, zabronione wartości mogą być LOD100 i LOD200
Przykład IDS
Dostępne oprogramowanie do tworzenia IDS
Lista producentów wspierających tworzenie IDS jest już obszerna.
Ja używam Solibri, bo znam ten program, ale edytor IDS jest płatny. Jeśli szukasz darmowych rozwiązań, słyszałem dobre opinie o Acca usBIM i BIM Vision.
Aby sprawdzić, czy twój ulubiony producent oprogramowania wdrożył kreator IDS, odwiedź oficjalną stronę BuildingSMART dla statusu implementacji IDS.
Przyszłość jest zautomatyzowana
Branża budowlana zmierza w kierunku automatycznego zapewniania jakości i specyfikacji czytelnych maszynowo.
IDS reprezentuje tę zmianę: od reaktywnego sprawdzania jakości do proaktywnej walidacji wymagań. Od wymagań opartych na dokumentach do ustrukturyzowanych, wykonalnych specyfikacji.
Jakie jest twoje największe wyzwanie z wymaganiami informacyjnymi BIM? Podziel się swoim doświadczeniem w komentarzach poniżej i przedyskutujmy, jak IDS może rozwiązać twoje konkretne problemy.
