Grafika źródłowa do montażu zdjęć: © Who is Danny - stock.adobe.com
Jak radzić sobie z wymaganiami informacyjnymi bezpośrednio w oprogramowaniu autorskim
Zapobieganie błędom zamiast ich korygowania
Każdy, kto pracuje w sektorze budowlanym, zna ten scenariusz aż za dobrze: dane, które są niezbędne do realizacji projektu, są nieaktualne, niespójne, nieprawidłowe lub mogą w ogóle nie zostać przekazane. Wyobraźmy sobie następującą sytuację: Wykonawca prac malarskich maluje cały parter na różowo, a ktoś uświadamia sobie, że tak naprawdę chciał kolor jasnoniebieski. Może się to wydawać absurdalne, ale w chwili, gdy czytasz ten artykuł, taka sytuacja ma miejsce w tysiącach projektów budowlanych na całym świecie na poziomie danych. Zawsze zachowujemy się tak, jakby dane były bezkosztowe i jakby jedyną rzeczą lepszą od ton danych było jeszcze więcej danych. Ale ktoś musi wprowadzać dane i powinien je sprawdzać. Każda dodatkowa iteracja oznacza większe koszty i więcej stresu. Dotyczy to zarówno świata wirtualnego, jak i rzeczywistego: naprawianie błędów jest czasochłonne, a ich unikanie trudne. Ale dlaczego właściwie? Po prostu wszyscy muszą mieć jasność co do tego, co jest wymagane, kiedy, od kogo i w jakiej jakości. Przekazanie tego nie może być aż tak trudne!
Z tego powodu zaleca się precyzyjne określenie wymagań informacyjnych przed rozpoczęciem projektu, najlepiej zaczynając od klienta i kończąc na poziomie atrybutów. Seria DIN EN ISO 19650 pokazuje procesy i role związane z żądaniem i dostarczaniem informacji. Ponadto, metoda definiowania wymaganego zakresu informacji jest określona przy użyciu Poziomu Potrzeby Informacyjnej (patrz np. DIN EN 17412-1). Wynikiem planowania przygotowawczego są dokumenty pomocnicze, takie jak wymagania informacyjne klienta (AIA: Auftraggeber-Informationsanforderungen) i plany wykonania BIM (BAP: BIM-Abwicklungspläne), tradycyjnie w formie dokumentów PDF lub Excel. Niektórzy mogą zauważyć, że jest to przynajmniej rozwiązanie cyfrowe, podczas gdy ci, którzy mają z nim pracować, przewijają tabele w poszukiwaniu odpowiedzi. Zapewnienie jakości jest realizowane poprzez ustanowienie reguł inspekcji, które są tworzone w specjalistycznym oprogramowaniu w oparciu o strukturę wyższego poziomu, umożliwiając automatyczne tworzenie bariery jakości. Jeśli dostarczone dane nie przejdą tej bariery, żądanie rewizji jest wysyłane z powrotem do poziomu modelowania i próbujemy ponownie.
Testowanie oprogramowania umożliwia obecnie osiągnięcie wysokiej jakości wyników. Nie jest to jednak szczególnie łatwe, ponieważ ważne jest, aby zwracać szczególną uwagę na wymagania w środowisku autorskim. Przynajmniej jeśli chcesz uniknąć czasochłonnych i kosztownych iteracji podczas testowania. Spojrzenie na rzeczywistość po raz kolejny prowadzi do pochopnego wniosku: BIM jest skomplikowany i nie jest niczym innym, jak odciąganiem uwagi od pracy!
Brakuje sposobu na naturalne radzenie sobie z tymi wymaganiami. Brakuje nadrzędnej struktury, która rozumie moje oprogramowanie autorskie i może zaoferować mi z niego widok. Brakuje środowiska, w którym nie mogę łamać zasad gry.
Specyfikacja dostarczania informacji
Specyfikacja dostarczania informacji (IDS) to nowe podejście do technicznej specyfikacji takich wymagań informacyjnych. IDS to niezależny od producenta standard stworzony przez buildingSMART w celu cyfrowej interpretacji wymagań dotyczących wymiany informacji. W przeciwieństwie do Model View Definition (MVD), IDS koncentruje się wyłącznie na wymaganiach alfanumerycznych. Określa, które właściwości z jaką zawartością (wartościami i jednostkami) powinny być ostatecznie przypisane do poszczególnych obiektów w projekcie. IDS jest zatem idealny do definiowania alfanumerycznej zawartości informacji (Level of Information - LOI).
Jako alternatywa dla prostych tabel definicji, IDS oferuje obecnie znormalizowany, możliwy do cyfrowej interpretacji sposób integracji tych informacji z zautomatyzowanym procesem BIM (patrz rys. 1). Można to zrobić na dwa sposoby:
- Jako plik konfiguracyjny dla oprogramowania autorskiego do automatycznego tworzenia wymaganej struktury informacji.
- Jako plik konfiguracyjny dla oprogramowania testującego do automatycznego wypełniania reguł testowych.
W ten sposób przepływ informacji między definicją a testowaniem zawartości modelu jest połączony za pomocą znormalizowanego formatu. Ponadto IDS umożliwia bardziej precyzyjną definicję wymagań modelu. Do tej pory informacje alfanumeryczne były przeważnie określane na poziomie klasy (np. właściwości wymagane dla IfcSpaceHeater). Dzięki IDS wymagania mogą być również konfigurowane w zależności od atrybutów, właściwości, klas zewnętrznych, statków relacji i materiałów. Na przykład, sensowne jest dostarczanie ciepłej wody do bidetów, ale nie do pisuarów. Albo klasa odporności ogniowej klapy przeciwpożarowej musi zaczynać się od "K".
P rzegląd strukturalny takich szczegółów umożliwia filtrowanie odpowiednich elementów i pozwala na znacznie dokładniejsze odwzorowanie wymagań.Rozwiązania IDS i LINEAR dla Revit
Tyle jeśli chodzi o teorię. W praktyce istnieją już pierwsze implementacje, które pozwalają na automatyczne przenoszenie specyfikacji IDS do reguł testowych oprogramowania koordynującego. Jest to dobry pierwszy krok, ale w rzeczywistości tylko pół kroku. Wciąż brakuje zautomatyzowanego transferu specyfikacji technicznych do struktury informacyjnej środowiska autorskiego. I nawet jeśli stanowi to ogromny krok naprzód, nie należy na tym poprzestawać, ponieważ dobre przygotowanie po stronie modelowania otwiera drzwi do znacznie więcej. Oferuje również pomoc w trakcie wprowadzania wyników. Jeśli wiem, że zgodnie z moim IDS należy określić klasy odporności ogniowej z listy F 30, F 60, F 90, dlaczego miałbym być w stanie wprowadzić cokolwiek innego? Jeśli moje numery pomieszczeń mają być przypisane zgodnie z formatem "dwucyfrowy numer piętra + myślnik + trzycyfrowy indeks" (np. 01-234), dlaczego moje środowisko programistyczne nie wskazuje mi tego od razu?
Odpowiedź na powyższe pytania jest równie prosta, co upokarzająca. Revit nie zna IDS, a IDS nie zna Revit. Dlatego musimy wypełnić lukę między tymi dwoma światami. I z dynamicznie konfigurowalnym oknem właściwości. Wszystko zaczęło się w wersji 24, z opcją określania klas elementów poza kategoriami Revit i łączenia ich z zestawami właściwości, regułami i modelami dojrzałości. Teraz w wersji 25 przenosimy to na wyższy poziom, włączając możliwość półautomatycznego tworzenia wymaganych struktur danych w oparciu o naszą własną standaryzację opartą na IDS.
Dlaczego tylko półautomatycznie? Odpowiedź pozostaje taka sama. Oba modele nie mogą się ze sobą w pełni komunikować; nie ma jednoznacznego odwzorowania IDS na model danych Revit. Musimy zatem stopniowo wzbogacać informacje w IDS, aby można je było przenieść do modeli Revit przy jak najmniejszej utracie wiedzy strukturalnej (patrz rys. 2).
Oprócz pewnych szczegółowych kwestii technicznych, należy zwrócić szczególną uwagę na następujące kwestie:
Wybór sybór specyfikacji do zaimportowania
IDS może zawierać dużą liczbę specyfikacji, z których nie wszystkie mogą być istotne dla bieżącego zadania planowania lub modelu technicznego. Dlatego pierwszym krokiem jest określenie, które specyfikacje mają zostać przyjęte. W tym miejscu można również przypisać LOI do poszczególnych specyfikacji.
Przypisywanie klas IFC do kategorii
IDS jest zwykle oparty na klasyfikacji IFC, Revit jest zorganizowany we własnych kategoriach. Klasyfikacja IFC w Revit jest zatem definiowana strukturalnie przez typ komponentu w predefiniowanym parametrze, niezależnie od kategorii Revit. Na przykład "komponenty HLS" odnoszą się tematycznie do dziesiątek klas IFC, od kontenerów po urządzenia centralne.
Przypisanie kategorii do typów IFC nie jest zatem jasno zdefiniowane i dlatego musi zostać dodane podczas importu. Aby uprościć to zadanie, LINEAR Solutions oferuje opcję wyprowadzenia ustalonych przypisań z konkretnego modelu, jeśli zostały one już w nim zapisane.
Przypisywanie parametrów do definicji
IDS identyfikuje parametry IFC poprzez nazywanie i przypisywanie ich do zestawów właściwości (Psets). Środowisko Revit nie rozpoznaje takich zestawów, a ponadto musi radzić sobie z zawartością pochodzącą z różnych źródeł. Aby rozwiązać powstałe sprzeczności, w programie Revit przechowywany jest plik tekstowy zawierający definicje tak zwanych "parametrów współdzielonych". Tam zapisywany jest projekt parametru (nazwa, typ danych itp.), który otrzymuje unikalny identyfikator. Proces ten umożliwia standaryzację parametrów w modelach komponentów i opartych na nich etykiet w różnych projektach. Aby zapewnić płynne przejście z IDS za pośrednictwem pliku Revit do IFC, platforma generująca IDS musi zatem zapewnić dodatkowe metadane w postaci plików parametrów dla środowiska tworzenia Revit i konfiguracji Pset dla eksportera IFC. Jeśli dostępny jest odpowiedni plik definicji, środowiska LINEAR automatycznie przejmują przypisanie. Alternatywnie tworzone są odpowiednie definicje do dalszego przetwarzania w programie Revit.
Wnioski
Standard IDS buildingSMART otwiera możliwość prawdziwie spójnego wykorzystania danych, niezależnie od używanej platformy oprogramowania. Definicja standardów projektu do poziomu atrybutów stanowi atrakcyjną alternatywę dla tekstowych lub tabelarycznych opisów wymagań.
Zautomatyzowany import specyfikacji IDS do platformy docelowej, takiej jak Revit, jest logicznym krokiem, dzięki któremu wymagana struktura może zostać uwzględniona bez żmudnego i podatnego na błędy ręcznego wprowadzania danych. Zaprojektowaliśmy kreator importu, który prowadzi użytkownika przez cały proces i pobiera jak najwięcej informacji z istniejącego modelu. Znacznie skraca to konfigurację standardu projektu, a kontrola wejściowa typów danych i zakresów wartości, która jest możliwa w rezultacie, może ostatecznie zapewnić wymaganą jakość danych.
Teraz wszystko zależy od Ciebie:
Czy masz już specyfikacje IDS, które chciałbyś przetestować pod kątem praktycznej przydatności z naszym zespołem programistów? A może masz pomysły, które mogłyby nam pomóc w dalszym ulepszaniu opisanego przepływu pracy? W takim przypadku czekamy na Twoją opinię!
Źródła i zalecana literatura
DIN EN ISO 19650-1 : 2019-08 Organizacja i digitalizacja informacji o robotach budowlanych i usługach inżynieryjnych, w tym modelowanie informacji o budynku (BIM)
DIN EN 17412-1 : 2021-06 Modelowanie informacji o budynku - Głębokość wymagań informacyjnych
Eichler et. al - Podręcznik BIMcert - Podstawowa wiedza openBIM, buildingSMART, 2024
Chcesz przeczytać więcej takich artykułów? Zagłosuj na nie (anonimowo) tutaj.