BIM projekty často selhávají na překvapivě jednoduchém místě: zadavatel sice ví, jaká data chce, ale požadavky předá v PDF, tabulce nebo dlouhém dokumentu. Projektant je interpretuje po svém, BIM koordinátor kontroluje část a při předání se zjistí, že některé hodnoty chybí nebo jsou zapsané jinak.

IDS – Information Delivery Specification – řeší právě tento problém.

Jeho smyslem není nahradit BIM Execution Plan ani lidskou dohodu. Umožňuje ale část informačních požadavků převést do struktury, které rozumí člověk i software.

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

Co je IDS jednou větou

IDS je strojově čitelný způsob, jak říct:

„Pro tyto objekty očekávám tyto informace a tyto hodnoty.“

Například místo věty v PDF:

Všechny dveře musí obsahovat požární odolnost a identifikátor místnosti.

může vzniknout kontrolovatelné pravidlo, které definuje:

  • na jaké IFC entity se požadavek vztahuje,
  • jakou vlastnost hledáme,
  • kde má být umístěna,
  • zda je povinná,
  • jaký formát nebo hodnotu očekáváme.

Proč nestačí Excel

Excel je pro přípravu požadavků pohodlný. Pro automatickou validaci ale vznikají problémy:

  • různé názvy sloupců,
  • lidské zkratky,
  • nejasné významy,
  • textové poznámky místo pravidel,
  • rozdílné chápání „povinné“ a „doporučené“,
  • chybějící vazba na konkrétní IFC entity.

Tabulka může být výborným redakčním prostředím. Neměla by ale být nutně finálním strojovým kontraktem.

IDS vytváří přesnější mezivrstvu.

Jak IDS funguje

Zjednodušeně každá specifikace obsahuje dvě části:

Applicability

Říká, na které objekty pravidlo aplikovat.

Například:

  • IfcDoor,
  • objekty určité klasifikace,
  • entity s konkrétním property setem,
  • objekty určitého typu.

Requirements

Říká, co u těchto objektů musí platit.

Například:

  • vlastnost musí existovat,
  • hodnota musí odpovídat vzoru,
  • materiál musí být uveden,
  • klasifikace musí patřit do povoleného systému.

To umožňuje vytvořit velmi konkrétní test.

Příklad: dveře v projektu

Představme si, že zadavatel požaduje pro každé dveře:

  • ID,
  • požární odolnost,
  • akustický parametr,
  • označení prostoru.

IDS může vyjádřit, že se pravidlo vztahuje na IfcDoor a požadované vlastnosti musí být přítomné.

Výstup validace potom není obecná věta:

„Model nesplňuje BIM požadavky.“

Ale konkrétní seznam:

Door_001 → FireRating missing
Door_014 → AcousticRating missing
Door_087 → RoomCode missing

To je dramaticky použitelnější pro opravu modelu.

Co lze pomocí IDS specifikovat

buildingSMART uvádí možnost pracovat například s:

  • objekty,
  • klasifikacemi,
  • materiály,
  • properties,
  • hodnotami vlastností.

V praxi to pokrývá velkou část požadavků typu:

„Co musí být v modelu?“

IDS naopak není univerzální jazyk pro všechny možné kontroly projektu.

Co IDS neumí dobře

Je důležité nepřetížit standard očekáváním.

IDS není primárně určený například pro:

Geometrické kolize

„Potrubí nesmí procházet nosníkem“ je spíše clash/geometry rule.

Komplexní výpočty

„Součet ploch musí odpovídat ekonomickému modelu“ může vyžadovat vlastní logiku.

Textové rozpory mezi dokumenty

„Technická zpráva tvrdí jinou požární odolnost než výkres“ je vhodnější pro document review.

Odborné rozhodnutí

IDS neumí rozhodnout, jestli je návrh architektonicky nebo staticky správný.

Proto je nejlepší IDS vnímat jako jednu vrstvu QA systému, ne jako kompletní BIM checker.

IDS vs. IFC Validation Service

Tyto dva nástroje se často pletou.

IFC Validation Service

Kontroluje soulad IFC souboru s IFC standardem – syntax, schema, normativní pravidla a další kontroly.

IDS validation

Kontroluje, jestli konkrétní data splňují vaše informační požadavky.

Příklad:

IFC standard neříká, že každé dveře ve vašem projektu musí mít interní kód Asset_ID.

IDS to říct může.

IDS a bSDD

buildingSMART Data Dictionary (bSDD) slouží jako sdílený zdroj termínů a definic.

IDS a bSDD proto mohou dobře spolupracovat:

  • bSDD pomáhá sjednotit význam termínu,
  • IDS říká, kdy je daná informace požadována.

To je důležitý krok k tomu, aby každá organizace nevytvářela vlastní synonymní slovník bez návaznosti.

Doporučený proces tvorby IDS

1. Začněte od use-case, ne od parametrů

Špatně:

Potřebujeme 180 parametrů, protože je máme v tabulce.

Lépe:

Při převzetí budovy potřebujeme identifikovat zařízení, dohledat jeho umístění a plánovat údržbu.

Až potom definujte minimální informační sadu.

2. Očistěte názvosloví

Rozhodněte:

  • co přesně znamená každá vlastnost,
  • jaký má datový typ,
  • zda je povinná,
  • v jaké fázi je požadována.

3. Rozdělte pravidla podle milníků

Nepožadujte provozní data ve fázi, kdy ještě neexistují.

4. Vytvořte IDS

Použijte nástroj podporující aktuální IDS 1.0.

5. Vytvořte testovací IFC

Ideálně dvě varianty:

  • model, který má projít,
  • model se záměrně vloženými chybami.

6. Ověřte report

Výsledek musí být čitelný i pro člověka, který IDS netvořil.

7. Verzujte

Požadavky se mění. Uchovávejte informaci, proti které verzi IDS byl model kontrolován.

Jak má vypadat dobré pravidlo

Dobré pravidlo je:

  • jednoznačné,
  • měřitelné,
  • relevantní pro konkrétní fázi,
  • technicky realizovatelné,
  • srozumitelné dodavateli.

Špatný požadavek:

Model musí obsahovat všechny důležité informace.

Dobrý požadavek:

Každá instance IfcDoor určená k předání pro provoz musí obsahovat neprázdnou hodnotu vlastnosti Asset_ID podle definovaného naming patternu.

Největší organizační chyba

Technický tým vytvoří stovky pravidel, ale nikdo neověří, zda tato data někdo skutečně použije.

Každá požadovaná vlastnost by měla mít odpověď na otázku:

Kdo ji použije a k jakému rozhodnutí?

Pokud odpověď neexistuje, pravděpodobně vytváříte datový odpad.

IDS a český BIM od roku 2027

Zákon č. 330/2025 Sb. pracuje s datovým standardem stavby a otevřeným strojově čitelným formátem. To přirozeně zvyšuje potřebu automatizovatelné kontroly dat.

Nelze ale bez dalšího tvrdit, že každý konkrétní požadavek zákona musí být implementován právě prostřednictvím IDS. IDS je technický standard buildingSMART, nikoliv automaticky jediný zákonný mechanismus.

Prakticky však dává velmi dobrý smysl tam, kde potřebujeme formalizovat a ověřovat informační požadavky nad IFC.

Jak IDS zapadá do QA pipeline

Požadavky organizace
       ↓
Datový standard / informační požadavky
       ↓
IDS
       ↓
IFC export
       ↓
IDS validator
       ↓
Issue list
       ↓
oprava modelu
       ↓
ověření

Vedle toho samostatně běží:

  • IFC standard validation,
  • clash detection,
  • document review,
  • odborná kontrola.

AIprojektant doporučení

Pokud s IDS začínáte, nevytvářejte jako první 500 pravidel.

Vyberte jednu kategorii – například dveře nebo technologická zařízení – a vytvořte 10 až 20 skutečně užitečných kontrol.

Na malém vzorku zjistíte:

  • zda jsou požadavky jednoznačné,
  • jaké názvy používají exportéry,
  • jak čitelný je report,
  • kolik vzniká false positives,
  • co musí změnit modelovací standard.

Teprve potom škálujte.

Zdroje