¿IDS sustituye al BEP (el plan de ejecución BIM)?

No: los complementa. El BEP describe cómo se trabajará; el IDS convierte la parte de requisitos de información en un archivo machine-readable que un validador puede comprobar contra el IFC, sin interpretación humana.

¿Quién escribe el IDS: el fabricante o el proyecto?

El proyecto (propiedad, consultora BIM). El fabricante lo sufre o lo aprovecha: si tu objeto lleva las propiedades bien definidas, pasa los checks de cualquier IDS razonable; si no, queda fuera sin que nadie te llame para avisarte.

¿Con qué se valida un IFC contra un IDS?

Hay herramientas comerciales y abiertas, incluido el servicio de validación oficial de buildingSMART (gratuito con límites de tamaño). La validación es determinista: pasa o no pasa.

¿En qué unidades lee un IDS la transmitancia?

En las unidades por defecto que fija la documentación de IDS: para IFCTHERMALTRANSMITTANCEMEASURE, W/(m²·K). Si tu IFC declara otra unidad, el validador tiene que convertir; lo prudente es exportar en SI y no depender de esa conversión.

IDS explicado: requisitos BIM que las máquinas verifican

IDS (Information Delivery Specification) es el estándar de buildingSMART que convierte los requisitos de información de un proyecto BIM en un archivo XML que una máquina comprueba contra el modelo IFC. Un ejemplo: “toda IfcWindow declara ThermalTransmittance en Pset_WindowCommon, como número, y no supera 1,4 W/m²K”. Pasa o no pasa, sin opinión.

El problema que resuelve IDS

Durante años, los requisitos de información de un proyecto BIM vivieron en PDFs: “los muros llevarán resistencia al fuego”, “todo elemento tendrá código de clasificación”. Cada uno los interpretaba a su manera y la verificación era manual, muestral y discutible.

IDS cambia eso. La versión 1.0 fue aprobada como estándar final de buildingSMART en junio de 2024; las anteriores (0.9.x y previas) eran betas. Un IDS dice qué entidades deben existir en el modelo IFC y qué información deben llevar. Un validador lo comprueba entero, en segundos.

¿Cómo funciona un IDS?

Un IDS es una lista de especificaciones. Cada una tiene dos mitades:

Mitad	Pregunta	Ejemplo
Applicability	¿A qué elementos aplica?	”Todas las ventanas (IfcWindow)“
Requirements	¿Qué deben cumplir?	”Con propiedad de transmitancia térmica, numérica, en W/m²K”

Las dos mitades se escriben con las mismas seis facetas: entidad, parte de (partOf), clasificación, atributo, propiedad y material. La faceta de propiedad es donde vive tu dato de producto, y la que se conecta con bSDD para que los nombres signifiquen lo mismo para todos.

Cada especificación declara además para qué versiones de IFC vale. El esquema oficial de IDS 1.0 admite tres valores: IFC2X3, IFC4 e IFC4X3_ADD2. Qué cambia entre ellas para una ventana lo contamos en qué cambia en IFC 4.3 frente a IFC4 y 2x3.

Un IDS real: exigir la Uw de cada ventana

Este es el requisito más típico que verá un fabricante de ventanas. Está escrito contra el esquema oficial de IDS 1.0 (el ids.xsd del repositorio de buildingSMART) y valida sin errores:

<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://standards.buildingsmart.org/IDS http://standards.buildingsmart.org/IDS/1.0/ids.xsd">
  <ids:info>
    <ids:title>Ventanas: transmitancia declarada</ids:title>
    <ids:version>1.0</ids:version>
  </ids:info>
  <ids:specifications>
    <ids:specification name="Uw de cada ventana" ifcVersion="IFC4 IFC4X3_ADD2">
      <ids:applicability minOccurs="1" maxOccurs="unbounded">
        <ids:entity>
          <ids:name>
            <ids:simpleValue>IFCWINDOW</ids:simpleValue>
          </ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:property dataType="IFCTHERMALTRANSMITTANCEMEASURE"
                      uri="https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/ThermalTransmittance"
                      cardinality="required">
          <ids:propertySet>
            <ids:simpleValue>Pset_WindowCommon</ids:simpleValue>
          </ids:propertySet>
          <ids:baseName>
            <ids:simpleValue>ThermalTransmittance</ids:simpleValue>
          </ids:baseName>
          <ids:value>
            <xs:restriction base="xs:double">
              <xs:maxInclusive value="1.4"/>
            </xs:restriction>
          </ids:value>
        </ids:property>
      </ids:requirements>
    </ids:specification>
  </ids:specifications>
</ids:ids>

Cómo se lee, pieza a pieza:

applicability con minOccurs="1": el modelo debe tener al menos una ventana, y la regla se aplica a todas.
dataType: el valor tiene que ser una medida de transmitancia, no un texto. Un “1,1 W/m2K” escrito como etiqueta falla.
baseName: el nombre exacto de la propiedad tal y como va en el IFC. No vale “Transmitancia”, ni “Uw”, ni “U-value”.
uri: apunta a la definición de esa propiedad en bSDD. La URI de ThermalTransmittance consta como viva en nuestra verificación contra la API de buildingSMART del 9 de septiembre de 2026.
xs:restriction: el límite. IDS lee el valor en unidades SI por defecto —W/(m²·K) para esta medida—, según su documentación de unidades.

Lo probamos contra un IFC de ventana con su Pset_WindowCommon bien relleno: pasa. Le quitamos el Pset: falla. Ponemos 1,6: falla. Escribimos el valor como texto: falla.

¿Por qué le importa a un fabricante si nunca escribe un IDS?

Cuando un proyecto con IDS valida sus modelos, tus objetos se examinan con todo lo demás. Las consecuencias son binarias:

Objeto con propiedades correctas y mapeables → pasa, y tu producto sigue especificado.
Objeto sin dato o con property sets inventados → falla el check, y el proyectista lo sustituye por el de un competidor que sí pasa. Sin negociación, sin aviso.

Es la prescripción digital llevada a su conclusión lógica: el filtro ya no es comercial, es computacional.

Los tres fallos que más vemos en ventanas

Pset casero. La Uw va en Pset_MiEmpresa con el nombre U_ventana. El dato existe, pero el IDS lo busca en Pset_WindowCommon y no lo encuentra.
Clase en vez de magnitud. La permeabilidad al aire de la EN 12207 es una clase (1 a 4). Meterla en Infiltration, que en IFC es un caudal de aire a 50 Pa, produce un número que pasa el tipo de dato y miente.
Uf y Uw mezcladas. Pset_WindowCommon no tiene una propiedad propia para la transmitancia del marco. Si publicas la Uf en ThermalTransmittance, el proyecto lee una Uw que no es.

Ninguno lo detecta un humano hojeando el modelo. Todos los detecta un IDS.

¿Qué hacer con esto?

Asegura que tu dato técnico existe como propiedades estructuradas, no como PDF adjunto.
Usa definiciones estándar (bSDD, plantillas ISO 23387) en vez de nombres caseros. El traductor de propiedades a bSDD/IFC te dice, columna a columna de tu Excel, qué propiedad IFC le corresponde y en qué Pset va.
Publica en IFC abierto, no solo en nativo: un IDS se valida contra IFC. Si aún dudas entre los dos, lee openBIM o formato nativo: qué publicar.
Genera los objetos desde el dato maestro —lo que hace Channels— para que pasar un IDS hoy no signifique fallar el del mes que viene.

Es el mismo dato que exige la DoPC digital: un esfuerzo, dos filtros superados.

Fuentes

buildingSMART International, Information Delivery Specification (IDS) v1.0 is approved as a final standard (junio de 2024) — buildingsmart.org
IDS 1.0: esquema XSD, manual y ejemplos oficiales — github.com/buildingSMART/IDS
IDS, unidades por defecto de cada tipo de dato — units.md
bSDD, propiedad ThermalTransmittance del diccionario IFC 4.3 — identifier.buildingsmart.org (verificada el 9-sep-2026)
Servicio de validación oficial de buildingSMART — validate.buildingsmart.org