Máte IFC soubor. Otevře se v prohlížeči, geometrie vypadá na první pohled správně a software nehlásí chybu.

Je model v pořádku?

Nevíme.

Tohle je jedna z nejčastějších chyb při BIM kontrole: různé typy validace se směšují do jedné otázky „je IFC správně?“. Ve skutečnosti může být model:

  • technicky validní, ale geometricky chybný,
  • geometricky správný, ale bez požadovaných dat,
  • datově bohatý, ale v rozporu s informačními požadavky,
  • perfektně exportovaný, ale nekoordinovaný s ostatními profesemi.

Proto doporučujeme kontrolovat IFC minimálně v sedmi oddělených vrstvách.

Rychlý přehled

1. Soubor a syntaxe
        ↓
2. IFC schema a normativní pravidla
        ↓
3. Geometrie a prostorová struktura
        ↓
4. Data a vlastnosti
        ↓
5. Informační požadavky / IDS
        ↓
6. Koordinace mezi modely
        ↓
7. Projektová a firemní pravidla

Každá vrstva odpovídá na jinou otázku a často vyžaduje jiný nástroj.

1. Soubor a syntaxe: je IFC vůbec technicky čitelné?

Nejnižší vrstva kontroly řeší, zda je soubor syntakticky korektní.

U běžného .ifc jde zpravidla o serializaci ve STEP Physical File Format. Kontroluje se například, zda má soubor správnou strukturu a zda jeho záznamy odpovídají očekávané syntaxi.

buildingSMART provozuje oficiální bezplatnou IFC Validation Service, která mimo jiné kontroluje STEP syntax.

Co tato kontrola zachytí

Typicky technické problémy souboru, kvůli nimž nemusí být data spolehlivě čitelná.

Co nezachytí

Neřekne vám například:

  • že dveře chybí,
  • že místnost má špatnou plochu,
  • že okno koliduje s nosníkem,
  • že požární parametr není vyplněný.

To už jsou jiné vrstvy kontroly.

2. IFC schema a normativní pravidla

Druhá vrstva řeší, zda data odpovídají použité verzi IFC a jejím pravidlům.

Oficiální buildingSMART Validation Service kontroluje například:

  • IFC schema,
  • formální pravidla zakódovaná v EXPRESS,
  • normativní IFC pravidla,
  • některé další industry-practice kontroly.

To je zásadní pro interoperability.

Příklad

Pokud exportér vytvoří vztah nebo entitu v rozporu se specifikací IFC, jiný software může soubor interpretovat chybně nebo ho vůbec nenačíst.

Validace standardu tedy odpovídá na otázku:

„Je tento soubor korektním nositelem IFC dat?“

Nikoli:

„Je tento projekt správně navržen?“

3. Geometrie a prostorová struktura

Teprve tady začínáme kontrolovat, zda digitální reprezentace odpovídá očekávanému modelu.

Kontrolujte například:

  • jestli jsou objekty na správném místě,
  • extrémně vzdálené prvky,
  • chybné transformace,
  • jednotky a měřítko,
  • podlaží,
  • prostorovou hierarchii,
  • duplicity,
  • nekorektní objemy,
  • zjevně rozpadlou geometrii.

Typický problém

IFC je technicky validní, ale část modelu je posunutá o desítky metrů kvůli špatné práci se souřadnicemi.

Standard validator může takový soubor považovat za validní, protože problém není v syntaxi IFC.

Pro projekt je ale model nepoužitelný.

4. Data a vlastnosti

Další vrstva odpovídá na otázku:

„Nesou prvky správná data?“

To zahrnuje například:

  • požadované property sets,
  • hodnoty parametrů,
  • datové typy,
  • klasifikace,
  • názvy typů,
  • identifikátory,
  • materiály,
  • vlastnosti důležité pro FM,
  • disciplínové atributy.

Příklad

Máme 850 dveří.

Požadavek říká, že každé dveře musí obsahovat:

  • identifikátor,
  • požární odolnost,
  • akustický požadavek,
  • odpovědnost za dodávku.

IFC může být zcela validní podle standardu, i když jsou všechny čtyři hodnoty prázdné.

Proto je technická validace jen začátek.

5. Informační požadavky a IDS

Tady se dostáváme od obecné validity k otázce:

„Obsahuje model přesně to, co jsme požadovali?“

buildingSMART Information Delivery Specification (IDS) umožňuje informační požadavky popsat strojově čitelným způsobem.

Můžete například definovat, že:

  • všechny objekty IfcDoor,
  • ve specifickém kontextu,
  • musí mít určitou klasifikaci,
  • konkrétní vlastnost,
  • hodnotu odpovídající pravidlu.

IDS 1.0 je od června 2024 oficiálním standardem buildingSMART.

Proč je to zásadní

Excel nebo PDF s informačními požadavky je čitelné pro člověka, ale ne přímo pro software.

IDS vytváří most:

Požadavek zadavatele
       ↓
strojově čitelná specifikace
       ↓
automatická kontrola modelu
       ↓
seznam splněno / nesplněno

To významně snižuje prostor pro subjektivní interpretaci.

6. Koordinace

Datově správné IFC modely mohou být stále vzájemně nekoordinované.

Koordinace řeší například:

  • fyzické kolize,
  • prostorové rezervy,
  • přístupnost údržby,
  • návaznosti profesí,
  • trasy instalací,
  • konstrukční prostupy,
  • časové nebo montážní konflikty.

Clash detection není totéž jako IFC validation

Tohle je důležité rozlišení.

IFC validation kontroluje datový soubor proti standardu nebo požadavkům.

Clash detection porovnává geometrii a prostorové vztahy.

Oba procesy jsou potřeba, ale jeden nenahrazuje druhý.

7. Projektová a firemní pravidla

Nejvyšší vrstva je často ta nejcennější a současně nejhůře automatizovatelná.

Každá firma a projekt mají pravidla, která nejsou součástí samotného IFC standardu.

Například:

  • každý stroj musí mít interní asset ID,
  • určité místnosti musí mít konkrétní naming,
  • dveře mezi dvěma typy prostor musí splňovat interní standard,
  • vybrané parametry musí být shodné napříč dokumentací,
  • prvky určitého typu se mají vyskytovat pouze v konkrétní zóně.

Tady vzniká prostor pro kombinaci:

  • deterministic rules,
  • IDS,
  • vlastní model checker,
  • databázové kontroly,
  • AI-assisted review.

Co může dělat AI a co by dělat neměla

AI je silná tam, kde je třeba:

  • interpretovat textové požadavky,
  • porovnat více dokumentů,
  • seskupit nálezy,
  • navrhnout priority,
  • vysvětlit problém člověku.

Deterministická validace je lepší tam, kde pravidlo zní například:

FireRating nesmí být prázdné pro žádnou instanci třídy IfcDoor v zadané sadě.

Takové pravidlo není důvod „hádat“ pomocí LLM. Software ho může vyhodnotit přesně.

Nejlepší kombinace

IDS / deterministic checks
        +
IFC standard validation
        +
geometrická kontrola
        +
AI pro textové a mezi-dokumentové rozpory
        +
lidské odborné rozhodnutí

Praktický checklist před předáním IFC

Technická vrstva

  • [ ] Soubor se validuje proti použitému IFC schema.
  • [ ] Neobsahuje zásadní STEP chyby.
  • [ ] Použitá verze IFC odpovídá zadání.

Geometrie

  • [ ] Model je ve správných souřadnicích.
  • [ ] Neexistují vzdálené nebo zjevně chybné objekty.
  • [ ] Podlaží a prostorová hierarchie dávají smysl.

Data

  • [ ] Povinné vlastnosti existují.
  • [ ] Hodnoty mají správné datové typy.
  • [ ] Klasifikace odpovídají požadavku.
  • [ ] Identifikátory jsou konzistentní.

Požadavky

  • [ ] Existuje formální checklist nebo IDS.
  • [ ] Nálezy jsou uzavřené nebo řádně zdůvodněné.

Koordinace

  • [ ] Model byl porovnán s relevantními profesemi.
  • [ ] Kritické kolize jsou uzavřeny.

QA

  • [ ] Je dohledatelné, kdo model kontroloval.
  • [ ] Je jasné, kterou revizi jsme validovali.
  • [ ] Výstup kontroly je archivovaný.

Nejčastější chyba: „Software mi napsal 0 errors“

Výsledek bez kontextu nic neznamená.

Nástroj může mít 0 chyb, protože kontroloval pouze jednu vrstvu.

Proto by každý validační report měl uvádět:

  • co bylo kontrolováno,
  • proti čemu,
  • jakou verzí pravidel,
  • který soubor/revize,
  • co naopak kontrolováno nebylo.

To je důležitý princip i pro Validorix nebo jakýkoliv jiný checker.

Doporučený workflow

IFC export
  ↓
1. buildingSMART standard validation
  ↓
2. základní geometrický QA
  ↓
3. kontrola informačních požadavků / IDS
  ↓
4. koordinační kontrola
  ↓
5. projektová pravidla
  ↓
6. review nálezů člověkem
  ↓
7. issue register / CDE

U větších projektů bych jednotlivé výsledky ukládal do společného issue managementu, aby kontrola nekončila jednorázovým PDF reportem.

AIprojektant verdikt

„Validní IFC“ je technický pojem, nikoliv známka kvality projektu.

Když budete při každé kontrole explicitně říkat, kterou ze sedmi vrstev právě ověřujete, výrazně se sníží nedorozumění mezi projektantem, BIM koordinátorem a zadavatelem.

A pokud zadavatel požaduje konkrétní data, snažte se je převést z textového seznamu do strojově kontrolovatelné podoby. Právě tam dává IDS a automatická validace největší smysl.

Zdroje