Przewodnik COBie

[1]

Publiczny przewodnik po COBie wersja 05 [2] wydany przez Nantional Institute of BUILDING SCIENCES zawiera (podano w formie cytatów): 

Ten dokument nie jest instrukcją obsługi oprogramowania. Dokument składa się z dwóch części. Najpierw są wspólne wymagania, które należy spełnić niezależnie od klient. Druga część to zestaw wymagań specyficznych dla klienta, które należy dodatkowo spełnić ogólne wymagania; Informacje COBie to służy do sprawdzenia, czy projektowany obiekt spełnia wytyczne programu właściciela. Ponieważ COBie jest wyciąg z elementów dostarczanych w ramach schematu, informacje w plikach danych COBie muszą być zgodne informacje o przestrzeniach i produktach architektonicznych oraz harmonogramach znalezionych na schemacie; 

Tłumaczenie Dokumentu

W trakcie projektu różni członkowie zespołu mają za zadanie przede wszystkim tworzyć Produkty COBie. Ponieważ wiele zespołów będzie korzystać z narzędzi do modelowania informacji o budynku, szczególnie na etapie projektowania, aby stworzyć wymagane rysunki kontraktowe, identyfikację Obowiązki COBie powinny być wyraźnie uwzględnione w planie wykonania BIM zespołu . Jedno narzędzie, które może pomóc zespołom w określeniu obowiązków związanych z produkcją Elementy dostarczane przez COBie to macierz odpowiedzialności COBie (Matryca odpowiedzialności COBie ) . Ta matryca pozwala zespołowi pokolorować kod różne części dostawy COBie w celu zdefiniowania precyzyjnych wymagań co do tego, z jakiej osoby która odpowiednia firma będzie odpowiedzialna za tworzenie określonych danych w COBie. Podczas gdy zespoły projektowe określą konkretne osoby odpowiedzialne w swoich firmach, następujące kwestie należy przestrzegać ogólnej odpowiedzialności za tworzenie danych COBie.

Wymienione arkusze robocze COBie (lub równoważne dane pliku IFC) na poniższym rysunku należy podać, jak wskazano w „Wymaganiach dotyczących aktywów” i „Dostarczeniu Sekcje „Kryteria oceny”. Celem tych wymagań jest standaryzacja produktu i harmonogramy sprzętu na rysunkach projektowych i odzwierciedlenie tych informacji w tych harmonogramach powiązana dostawa COBie. Treść dostarczanego projektu rozwoju powinna odzwierciedlać przestrzeń i zaplanowane produkty oraz aktywa wyposażenia przedstawione na odpowiednich rysunkach dostarczalnych. Architekt jest odpowiedzialny za skorygowanie wszelkich odchyleń w treści między powiązanym opracowaniem projektu rysunki i informacje dostarczane w tej sekcji.

Unikalne nazewnictwo zasobów: Bez unikalnych nazw nie można skutecznie utrzymać określonych zasobów. Wszystkie zarządzane przestrzenie, produkty i urządzenia znajdujące się w harmonogramach i rysunkach projektowych powinny mieć niepowtarzalną nazwę. Te nazwy muszą zawierać informacje o zasobach poza kontekstem harmonogramu projektowania. Nazwy na rysunkach projektowych muszą odpowiadać nazwom znajdującym się w dostawie COBie.Podczas projektowania Architekt będzie odpowiedzialny za ozwiązywanie wszystkich konfliktów związanych z powielaniem nazw przez własny personel i wszyscy inżynierowie konsultanci. 

Komponentowe rozmieszczenie przestrzenne: Dla każdego składnika COBie.Component należy dostarczyć atrybut COBie.Attribute o nazwie „SpatialPlacement”. To Atrybut identyfikuje informacje potrzebne zarządcy obiektu, operatorowi lub opiekunowi do uzyskania dostępu ten składnik. Typowe wartości atrybutu SpatialPlacement obejmują „UnderFloor”, „AboveCeiling”, „InWall”, „InSpace”, „OnRoof”, „OnSite”

Kategorie: Duzi klienci publiczni zarządzają różnego rodzaju obiektami na wielu kampusach. Aby skutecznie zarządzać tymi portfelami, elementy dostawy COBie są wymagane do otrzymywania informacji o budynku w spójny sposób. W COBie osiąga się to poprzez zastosowanie kilku różnych rodzajów Klasyfikacje. Klasyfikacje to „kody kategorii” różnych typów stosowane w COBie. NBIMS- Stany Zjednoczone wymagają klasyfikacji następujących arkuszy COBie. • Kontakt • Obiekt • Przestrzeń • Rodzaj • System. NBIMS-US wyznacza OmniClass (OMNIClass System klasyfikacji konstrukcji) jako domyślną metodę klasyfikacji stosowaną, jeżeli żadna inna metoda nie jest określone w umowie. Domyślna lista obowiązkowych klasyfikacji COBie, które należy uwzględnić danego klienta wymieniono w załączniku A. Należy pamiętać, że poleganie przez klienta tylko na OmniClass może nie zapewnić zgodności między projektami czas. Tabele klasyfikacji OmniClass, podobnie jak wszystkie systemy klasyfikacji, zmieniają się z czasem jak aktualizacje są włączone. Określenie i opublikowanie precyzji leży w gestii klientów schemat klasyfikacji wymagany we wszystkich projektach.

trefy: Budynki zawierają grupy przestrzeni, które po połączeniu zapewniają określone możliwości właściciel. Arkusz COBie.Zone ma na celu identyfikację przestrzeni tworzących daną strefę. Zasadniczo strefy należy identyfikować według rodzaju i cech strefy. Duże nazwy stref obiekty powinny być również oznaczone jako dołączone do podłogi i skrzydła. Nazwy stref i podstref powinny: być zatwierdzonym przez właściciela. Domyślna lista stref, które będą używane dla danego klienta.

W przyszłości oczekuje się, że klienci określą użycie przygotowanych obiektów szablonów obowiązkowe właściwości, które odzwierciedlają ich unikalne wymagania. W przypadku braku określonych przez klienta regionalnych, krajowych lub specyficznych dla klienta zestawów nieruchomości zespół projektowy może opracowywać harmonogramy sprzętu i produktów zgodnie z aktualnymi praktykami biznesowymi i przesyłać do zatwierdzenia przez klienta te harmonogramy, które zostaną sprawdzone pod kątem standardów jakości określonych w ten przewodnik.

Unikalna nazwa komponentu i nazwa typu: Wszystkie harmonogramy urządzeń, które identyfikują poszczególne elementy, zaczynają się od wymienionych atrybutów poniżej. Podano nazwę zasobu „Component.name” i nazwę typu zasobu „Component.Type” we wszystkich harmonogramach projektowych powinny być unikalne dla wszystkich klas aktywów.

Atrybuty nieistotne: Atrybuty podane w elementach dostarczanych COBie są ograniczone do tych, które dostarczają informacji na temat specyfikacji lub działania zarządzanego składnika aktywów, a nie informacji dotyczących wewnętrzna konfiguracja systemu oprogramowania lub formaty wyjściowe dostarczone przez implementację systemy oprogramowania.

Żródła:

[1] pixabay.com

[2] Przewodnik COBie: komentarz do standardu NBIMS-US COBie [draft]: dr Bill East, PhD, PE, F.ASCE 1 , Mariangelica Carrasquillo-Mangual 2; Nantional Institute of BUILDING SCIENCES; 2013-03-12-COBieGuide-Public-v05    https://www.nibs.org/