Volver al blog BIM e IFC
Validación · 2026-10-01 · 12 min
IDS explicado: cómo comprobar un modelo IFC contra una Information Delivery Specification
IDS convierte «el modelo debe contener la resistencia al fuego» de una frase en un PDF en un archivo que una máquina puede comprobar. Qué comprueban de verdad las seis facetas, dónde fallan la mayoría de archivos IDS y cómo ejecutar uno contra tu IFC en el navegador.
IDS explicado: cómo comprobar un modelo IFC contra una Information Delivery Specification — IFC Viewer Online article cover
Todo EIR que se ha escrito contiene una frase como «todas las puertas deberán indicar su resistencia al fuego». Y en todos los proyectos esa frase se comprueba igual: alguien abre el modelo, hace clic en unas cuantas puertas y decide que probablemente está bien. El requisito es preciso. La comprobación es una sensación.
IDS —la Information Delivery Specification— existe para cerrar esa brecha. Es un formato XML pequeño, estandarizado por buildingSMART como IDS 1.0, que expresa los requisitos de información de forma que una máquina pueda comprobarlos. Escribes el requisito una vez, entregas el archivo .ids a cada proveedor y «probablemente está bien» se convierte en «pasan 412 de 418 puertas; estas son las seis que no».
Lo esencial
- IDS comprueba información, no geometría: clases, atributos, propiedades, clasificaciones, materiales y relaciones.
- Cada especificación tiene dos mitades: a qué elementos se aplica y qué deben tener esos elementos. La mayoría de archivos IDS rotos fallan en la primera mitad.
- Un IDS es un documento contractual. Va junto al BEP, versionado, y se envía a los proveedores antes de empezar a modelar, no después del primer rechazo.
Anatomía de una especificación
Una especificación IDS se lee como una frase: para cada elemento que cumpla la aplicabilidad, exige los requisitos.
Un archivo IDS es una lista de especificaciones. Cada una se lee como una frase con sujeto y predicado: «para cada elemento que cumpla esto, exige aquello». El sujeto es la aplicabilidad; el predicado, los requisitos.
<specification name="Doors carry a fire rating" ifcVersion="IFC4">
<applicability minOccurs="1">
<entity><name><simpleValue>IFCDOOR</simpleValue></name></entity>
</applicability>
<requirements>
<property dataType="IFCLABEL">
<propertySet><simpleValue>Pset_DoorCommon</simpleValue></propertySet>
<baseName><simpleValue>FireRating</simpleValue></baseName>
</property>
</requirements>
</specification>
Léelo en voz alta y es exactamente la frase del EIR: todo IfcDoor debe tener un FireRating en Pset_DoorCommon, guardado como label. El minOccurs="1" de la aplicabilidad añade una segunda afirmación que se pasa por alto con facilidad: el modelo debe contener al menos una puerta. Sin él, un modelo sin ninguna puerta pasa, y eso rara vez es lo que alguien quería decir.
Las seis facetas y qué comprueba realmente cada una
| Faceta | Comprueba | Requisito típico | Trampa habitual |
|---|
| Entity | Clase IFC y tipo predefinido | Los muros son IfcWall, no IfcBuildingElementProxy | Olvidar los subtipos: IfcWallStandardCase es un IfcWall en IFC2x3 |
| Attribute | Atributos IFC directos (Name, Description, Tag…) | Todo espacio tiene Name y LongName | Una cadena vacía está presente pero es inválida; no es lo mismo que ausente |
| Property | Una propiedad de un property set, con tipo de dato y valor | Pset_WallCommon.IsExternal es TRUE o FALSE | Valor correcto, tipo de dato incorrecto (un label donde se pedía un booleano) |
| Classification | Una referencia de clasificación y su código | Todo elemento tiene un código Uniclass Ss | Comprobar el código pero no el sistema al que pertenece |
| Material | Un nombre o categoría de material asociado | Los pilares estructurales declaran un material | Materiales en el tipo, no en la ocurrencia |
| PartOf | Una relación con un elemento padre | Todo elemento está contenido en una planta | Confundir agregación con contención espacial |
Cada faceta puede aparecer en la aplicabilidad (para seleccionar elementos) o en los requisitos (para exigirles algo).Dos de esas trampas merecen una mirada más larga, porque explican la mayoría de falsos fallos que se ven al ejecutar un IDS por primera vez.
Tipo frente a ocurrencia
Las propiedades pueden estar en el tipo y no en la ocurrencia. Un comprobador IDS debe seguir el tipo o suspenderá elementos correctos.
Revit, ArchiCAD y Tekla escriben habitualmente propiedades y materiales en el objeto tipo (IfcWallType) en lugar de en cada muro. La semántica de IDS deja claro que la información heredada del tipo cuenta para la ocurrencia. Un comprobador que solo mira la ocurrencia suspenderá todos los muros de un modelo perfectamente correcto. Si un IDS te dice que al 100 % de tus elementos les falta una propiedad que ves en el panel de propiedades, casi siempre es por esto, y el fallo es del comprobador, no tuyo.
Tipos predefinidos USERDEFINED
Cuando un tipo predefinido es USERDEFINED, el tipo real está en ObjectType (en las ocurrencias) o en ElementType (en los tipos). Una faceta entity que pida IFCWALL con tipo predefinido PARAPET debe coincidir con un muro cuyo PredefinedType sea USERDEFINED y cuyo ObjectType sea PARAPET. Los comprobadores que comparan el enum en bruto se los saltan todos.
Cinco errores que inutilizan un IDS
- Aplicabilidad demasiado amplia. «Todos los elementos deben tener código Uniclass» arrastra huecos, anotaciones y elementos espaciales que nadie clasifica. Limita cada especificación a las clases a las que de verdad se refiere el requisito.
- Valores sin tipo de dato. Un requisito FireRating = «EI 60» no dice nada de cómo debe guardarse; el mismo texto guardado como descripción en otro pset seguirá fallando. Di lo que quieres decir, incluido el tipo de dato.
- Valores exactos donde se quería un patrón. Los datos reales traen «EI60», «EI 60» y «EI-60». Usa un xs:pattern o una enumeración, y acuerda la forma canónica en el BEP.
- Una única especificación gigante. Cuarenta requisitos en una especificación dan un solo aprobado o suspenso por elemento y un informe con el que nadie puede actuar. Un requisito por especificación, con un nombre en lenguaje claro, es lo que hace legible el resultado.
- Escribir el IDS después del modelo. Un IDS enviado con el primer rechazo es un requisito nuevo. Un IDS enviado con el encargo es un requisito. Solo el segundo es exigible.
La parte contractual de ese último punto —qué cláusulas hacen vinculante un IDS y qué pasa cuando una entrega no lo cumple— está en cláusulas del BEP que de verdad evitan malas entregas IFC y en criterios de aceptación IFC.
Ejecutar un IDS contra tu modelo, paso a paso
- Abre el IFC Arrastra el modelo al visor. Se procesa en tu navegador; no se sube nada.
- Carga el archivo .ids Abre el panel IDS y elige tu archivo, o parte de una de las especificaciones de ejemplo incluidas si antes quieres ver el formato.
- Ejecuta la comprobación Cada especificación se evalúa con las seis facetas. Los modelos grandes muestran el progreso por fases y se pueden cancelar en cualquier momento.
- Lee el resultado por especificación, elemento o clase Agrupa los fallos como vayas a corregirlos. Cada fallo trae el motivo en palabras claras: falta la propiedad, valor incorrecto, tipo de dato incorrecto, clase incorrecta.
- Míralo en 3D Resaltar colorea en el modelo los elementos que fallan; Aislar oculta todo lo demás. Ambos están a un clic, y así una lista de GlobalIds se convierte en una conversación con quien modela.
IDS entre revisiones
Una ejecución de IDS es una foto fija. Lo que un coordinador necesita de verdad es la tendencia: ¿la revisión 7 corrigió los fallos de la revisión 6? ¿Introdujo otros nuevos? Como el resultado se indexa por GlobalId, la misma especificación se puede comparar entre dos versiones de un modelo, cosa que solo funciona si tus GlobalIds son estables entre exportaciones. Si no lo son, arregla eso primero: por qué los GUID de IFC cambian en cada exportación. La comparación en sí se explica en cómo comparar dos versiones de un modelo IFC.
Dónde se detiene IDS
IDS no comprueba geometría. No te dirá que dos conductos colisionan, que una puerta es demasiado estrecha para una silla de ruedas ni que el modelo está a dos kilómetros de su punto de replanteo. Tampoco comprueba que un IFC sea estructuralmente sano: un archivo con GlobalIds duplicados o emplazamientos rotos puede pasar un IDS a la perfección.
Eso no es una debilidad; es alcance. Usa IDS para los requisitos de información, un model checker para la estructura y la geometría, y entrega los dos informes juntos. El flujo completo está en cómo validar un archivo IFC.
IDS explicado: cómo comprobar un modelo IFC contra una Information Delivery Specification