IFC praxe V. - BIM Bridge
BIM Bridge
BIM Bridge je sada utilit, které umožňují převod negrafických informací IFC modelu do formátu COBie.
Proč COBie
Formát COBie představuje dosud nejspolehlivější a nejpřehlednější pohled na strukturu a obsah informací o budově.
IFC model je doposud výhradně vytvářen pro účely koordinace výstavby. Tomu je podřízeno hledisko na maximální podrobnost detailu konstrukcí bez ohledu na výslednou velikost modelu.
Fráze o využitelnosti takovéhoto modelu pro účely provozu a správy budovy jsou falešnými lákadly, které mají zdůvodnit zvýšené náklady na jeho tvorbu. Bohatou argumentaci na toto téma lze najít např na webu Orthograph https://www.orthograph.com/
Proč tedy převodní můstek
Schopnost načíst a analyzovat IFC model z hlediska FM (t.j. provozu a správy) je důležitá proto, že:
- Koordinační model obsahuje sice spoustu nepotřebných (z hlediska FM) informací, ale často to bude jediný zdroj dat.
- Bude důležité vyseparovat alespoň tu část, která může být užitečná
- Bude důležité důrazně upozorňovat na nedostatky, které model obsahuje. Velmi často jsou to především tato pochybení:
- model neobsahuje vůbec definice místností (jde přitom o klíčovou informaci pro provoz)
- model neobsahuje entity k popisu prvků technického a technologického vybavení nebo je obsahuje s chybějícím, nedostatečným či duplicitním označením (takže je nelze efektivně identifikovat, párovat s provozní či technickou dokumentací ani ověřovat jejich úplnost, správnost či ´´účetní a finanční výkaznictví)
Následující text a zobrazení jsou příkladem řešení konverze z IFC do COBie s použitím nástrojů a knihoven popsaných v předchozích příspěvcích.
Přehled souborů v cloudu
Aplikace Bridge komunikuje s IFC serverem prostřednictvím API aniž by vyžadovala vlastní úložiště na pracovní kopii modelu.
To je důležitá vlastnost, neboť více než 90% dat v IFC souboru je pro FM aplikaci nepotřebná
Dostupné JSON konverze
IFC server (BIM App) připraví po importu během několika minut až hodin (podle velikosti souboru) sadu konverzí, jejichž obsah umožní další efektivní práci.
Nejdůležitější je spatial_structure, která obsahuje kompletní strom modelované budovy: podlaží, prostory (místnosti) a prvky vybavení, zatím bez uživatelských identifikací.
Následuje import konverze elements, která obsahuje uživatelské identifikace, popisy a další parametry (kromě vlastností)
Soubory vlastností, množství a materiálů jsou importovány do samostatné SQL tabulky, protože se často opakují u mnoha elementů
Kompletace SQL struktury
A.by bylo možno s SQL tabulkou modelu budovy efektivně manipulovat prostřednictvím SQL nástrojů, je třeba provést některé další konverze a indexace, například proto, aby se jednoznačně odlišily sady prostorových, strukturálních (stavebně konstrukčních) a zařizovacích (TZB) elementů.
Práce s typy
COBie metodika pracuje důsledně s typováním prvků tak, aby všechny společné vlastnosti byly uvedeny jako součást popisu typu.
Samotné elementy (instance typů) pak obsahují pouze unikátní identifikace, jako je výrobní číslo, čárový evidenčné kód a datum instalace.
Tento princip je v IFC sice možný, ale není zpravidla nijak kontrolován ani vyžadován, takže je nutno skupiny elementů se stejnými funkčními, tvarovými, provozními a výkonovými vlastnostmi ručně seskupovat
Můstek pro převod podlaží
Z hlediska provozu je podlaží zcela jednoznačně vymezeno, např. počtem a označením tlačítek ve výtahu. To, že různé části budovy mohou mít úroveň podlahy v různých výškách, není rozhodující.
V IFC modelu není tento princip zpravidla aplikován, takže je zde definováno i několik úrovní pro jednotlivá podlaží a ani jejich označení nemusí být konzistentní.
Je proto nutno sestavit převodní můstek mezi konstrukčními rovinami modelu a provozními úrovněmi podlaží.
Elementy v místnostech a mimo
COBie pohled předpokládá, že všechny elementy (prvky vybavení) jsou součástí nějakého prostoru (třeba i virtuálního), který je nějak vymezen a pojmenován.
To v IFC modelu často neplatí - prvky uvnitř zdí neobsahují přiřazení k žádnému prostoru (i když je to metodicky přípustné).
Proto je mezi množinu prostorů v každém podlaží vložen i virtuální prostor OutOfSpace.
Závěrečné ověření
Formát IFC striktně vyžaduje, aby každý element byl (mimo jiné) identifikován svou třídou (zde označena jako Entity)
Třída (IFC Entity) je často nejvěrohodnějším identifikátorem toho, co daný element představuje. Je proto účelné ověřit alespoň vizuálně, zda pojmenování a popis elementu je v souladu s jeho deklarovanou třídou.
Pozn.: poslední tři obrázky již jsou náhledem na data prostřednictvím COBie metodiky.