Sprawdźmy 🙂

Niniejszy artykuł jest zaproszeniem do udziału w pierwszym projekcie społecznościowym dotyczącym ujednolicenia opisu studni betonowych na potrzeby standaryzacji informacji o elementach na forum DCNavigator. Standaryzacja ta może skutkować cyfryzacją i przyspieszeniem wymiany informacji o studniach, co niesie szereg benefitów dla stron zaangażowanych w projekty infrastrukturalne. Struktura artykułu ma za zadanie przybliżenie problemu jaki chcemy rozwiązać i zarysowanie rozwiązania wraz z uzasadnieniem. Jednocześnie, jeśli ktoś ma inny pomysł, jest w stanie go uzasadnić i obronić na forum społeczności to jesteśmy gotowi przyjąć ten pomysł na warsztat. Innymi słowy nie rościmy sobie monopolu na wiedzę i jedynie słuszne rozwiązania. Zatem do rzeczy.

Problem- dlaczego to tak długo trwa?

Proces przygotowania oferty na elementy kanalizacji dla autostrady czy innego przedsięwzięcia liniowego polega na wertowaniu papierowych rysunków i zliczaniu elementów oraz ich głównych parametrów gabarytowych w celu oszacowania materiałochłonności i pracochłonności potencjalnego zlecenia. W przypadku sukcesu oferty konieczne jest ponowne wertowanie tych samych rysunków w poszukiwaniu informacji szczegółowej, koniecznej do produkcji elementów indywidualnych jak na przykład studnie kanalizacyjne. W epoce BIMu, digitalu, przemysłu 4.0 brzmi to jak jakaś prehistoria. Tym bardziej, że projekt jest generowany przy pomocy narzędzi cyfrowych, modeli które zawierają całą informację geometryczną konieczną do wyprodukowania elementu. Dlaczego ta informacja nie może trafić do producenta w formie zestawienia ze zunifikowanymi nagłówkami rozumianymi tak samo przez wszystkich uczestników procesu? Zamiast tego jest spłaszczana do kresek na papierze lub pliku PDF i pozbawiana całej wielowymiarowości informacyjnej. Przygotowanie oferty zamiast kilku godzin trwa kilka dni.

Istniejące rozwiązania

Aby zapewnić swobodną wymianę informacji o elementach prefabrykowanych w dokumentacji konieczne by było ustalenie zestawu pojęć i ich definicji opisujących dany przedmiot. Można to robić indywidualnie lub globalnie.

Przykład 1- norma (ale takiej nie mamy)

Przykładem działalności globalnej i w dodatku normatywnej jest norma BS8666:2020 opisująca kształty gięcia prętów zbrojeniowych, stosowana w UK (2020 to aktualizacja, norma funkcjonuje od lat). Norma specyfikuje kształty prętów i symbolikę stosowaną do ich opisania. Dzięki temu zestawienie zbrojenia może być kompletnie oderwane od informacji graficznej. Wszyscy wiedzą, że kod 51 to strzemię i jednoznacznie opisuje je 5 niezależnych wartości A, B, C, r i d i wynikowa L. Zatem całe zestawienie to tabela bez grafiki, którą można przesłać w dowolnym formacie tekstowym z modelu na maszynę gnącą i tnącą bez konieczności przepisywania i popełniania błędów. Kody prętów przystępnie zostały przedstawione na stronie producenta stali zbrojeniowej.

Przykład 2- Data Templates (DT)

W miarę rozwoju BIM, kilka podmiotów wpadło na pomysł standaryzacji informacji o produktach w formie usługi dla producentów. Oferują tworzenie Data Templates, które by opisywały dany produkt. Najprościej ujmując definiują nagłówki tabeli zawierające zestawienie materiału określonego rodzaju. Jest to robione na zamówienie producenta, który jako płatnik realizuje swoje interesy. Robi to CoBuilder, NBS i parę innych podmiotów. Jest to interesujący kierunek skutkujący szczegółowym opisem danego produktu. Czy pozwala on na porównywanie między podobnymi produktami? Jeśli dostanę dwa DT z dwóch niezależnych źródeł to czy będą one porównywalne dla maszyn? Czy wyspecyfikowanie produktu na bazie jednego DT będzie umożliwiało jego szybką/ automatyczną wycenę u producenta posługującego się innym formatem DT? Nie wiem. Pewnie zależy to od stopnia typowości/skomplikowania produktu.

I tu przechodzimy do sedna.

Z punktu widzenia działalności gospodarczej nie potrzebuję informacji o promieniu uchwytu klamki, czy średnicy trzpienia zawiasu, żeby móc porównać ceny różnych producentów drzwi i okien. Z drugiej strony skali jest element murowy, który ma mieć parametry wytrzymałościowe i izolacyjne zgodne z normą, a poza tym producent jest w zasadzie nieistotny i decyduje cena. Postuluję zatem aby wspólny słownik pojęć opisujących dany produkt podzielić na informacje pozwalające porównać ceny dwóch różnych producentów i informacje dodatkowe, umożliwiające produkcję, specyfikujące dodatkowe właściwości. W przypadku prefabrykatów studni podstawowe informacje to geometria i klasa betonu, rodzaj armatury rzutujący na cenę. Informacje dodatkowe to też geometria związana ze szczegółami wlotów i wylotów. W przypadku innych prefabrykatów zakres będzie inny, ale póki co skupmy się na studniach.

Czy wyważamy otwarte drzwi?

Mam nadzieję, że nie. Zakres pojęć powinien być osadzony w już istniejącym zestawie pojęć. Ponieważ mówimy o elementach, z których budujemy i cyfryzacji, naturalnym kontekstem wydaje się IFC. Ponieważ całe zamieszanie zaczęło się od studni to okazuje się, że studnia jest ujęta w schemacie IFC. Schemat IFC zawiera zestaw właściwości jakimi można opisać studnie, definicję rodzajów danych etc.

Skoro drogi czytelniku dotarłeś tu i przypadkiem zagadnienie digitalizacji lub prefabrykacji (lub digitalizacji i prefabrykacji), jest Ci bliskie, albo zetknąłeś się z opisanymi wyżej nieefektywnościami w procesie realizacji infrastruktury, zapraszam Cię do dyskusji i współpracy. Współpracy, która mam nadzieję, przyczyni się do usprawnienia drobnego wycinka rzeczywistości budowlanej jakim jest projektowanie, zamawianie i produkcja prostych prefabrykatów infrastrukturalnych.

Cel

Celem tego małego projektu jest uzgodnienie w możliwie szerokim gronie przedstawicieli produkcji, realizacji i projektowania zakresu pojęciowego, służącego opisaniu studni betonowej oraz jej wyprodukowaniu. Zakres ten będzie mógł być dowolnie implementowany w dokumentacji projektowej i produkcyjnej w celu usprawnienia wymiany informacji pomiędzy podmiotami.

W idealnej sytuacji informacja powinna być możliwa do wyeksportowania z oprogramowania do projektowania infrastruktury zawierającej elementy studni w postaci jednoznacznego zestawienia. Beneficjentami tej sytuacji byliby wszyscy:

• Projektanci: automatyczne jednoznaczne zestawienie,
• Wykonawcy: przyspieszone ofertowanie, obniżone koszty zakupów, porównywalność ofert,
• Producenci: automatyzacja produkcji i obniżenie kosztów ofertowania i przygotowania produkcji.

Coś na początek

Wstępna propozycja zakresu podstawowego umożliwiającego wycenę zestawienia:

• Identyfikator elementu,
• Średnica zewnętrzna studni lub długość studni prostokątnej,
• Szerokość studni prostokątnej,
• Wysokość studni,
• Grubość ścianki,
• Klasa betonu,
• Rodzaj uszczelki,
• Zwieńczenie,
• Nośność włazu.

Zadanie polega na uzgodnieniu zakresu i nazw atrybutów (właściwości, parametrów) przez zainteresowanych uczestników projektu i dobranie nazw parametrów wg definicji IFC. Np. średnica zewnętrzna to może być „ChamberLengthOrRadius” , a opis tej właściwości w naszym małym systemie wyglądałby następująco:

Name: ChamberLengthOrRadius

Property Type: IfcPropertySingleValue

Data Type: PositiveLengthMeasure / LENGTHUNIT [mm]

Definition: Length or, in the event of the shape being circular in plan, the radius of the chamber.

Ułatwiamy sobie życie korzystając z istniejących definicji. W jaki sposób uczestnikom projektu/rynku korzystanie z powyższego zestawu informacji ułatwi życie?

1. Wiedzę, że w zestawieniu studni nagłówek „ChamberLenghtOrRadius” zawsze będzie opisywał średnicę studni okrągłej, lub długość studni prostokątnej w milimetrach.
2. Zestawienie można wygenerować bezpośrednio z modelu i przesłać w dowolnym formacie.
3. Stosowanie zestawień czytelnych dla wszystkich przyspiesza pozyskiwanie i porównywalność ofert.
4. Standardowy format zestawień umożliwia automatyzację przygotowania oferty relatywnie niskim kosztem (mniej wariantów i odchyleń do przewidzenia w systemie). Prosty algorytm można zbudować w formie makra w Excelu czy kawałka kodu na stronie www producenta.

Jeśli nie przysnąłeś/ przysnęłaś do tego momentu to zapraszam do zaangażowania się w ten mini projekt społecznościowy. Na dzień dzisiejszy jest to wynik dyskusji z jednym producentem, wydaje się natomiast, że wszyscy uczestnicy rynku zmagają się z tym samym problemem i taka standaryzacja jest w interesie wszystkich, dlatego proponujemy otwartą formułę. Na wstępie liczę na odzew ze strony produkcji w celu ustalenia minimum informacji o elemencie, koniecznej do ustalenia jego ceny. Może ktoś już próbował mierzyć się z tym zagadnieniem?

Podejrzewam, że w trakcie mierzenia się z postawionym wyzwaniem, nie unikniemy dyskusji bardziej filozoficznych i przyziemnych jednocześnie. Na przykład: czy oszczędność czasu przy zbieraniu obiektywnych i porównywalnych ofert jest warta ryzyka związanego z dostarczeniem dostawcy zestawienia, zamiast obarczenia go odpowiedzialnością za samodzielne zliczenie elementów z dokumentacji. Sami prowadziliśmy i podobne rozmowy przed opublikowaniem niniejszego artykułu. Chętnie poznamy i zmierzymy się z tego rodzaju dylematami w ramach DCN.

Dyskusję prowadzimy na Discordzie na kanale „use cases”.

Rysunek tytułowy wg EN 1917:2002/AC:2008

Rysunek pomocniczy: www.pixabay.com