Volver al blog BIM e IFC
Validación · 2026-06-28 · 20 min
Verificador de modelos IFC: la guía completa de validación IFC, calidad del modelo e IDS
Guía del verificador de modelos IFC: el esquema, la calidad del modelo (44 reglas + Health Score) y el IDS son tres capas independientes. Confundirlas provoca entregas rechazadas. Desglose completo para coordinadores BIM.
Verificador de modelos IFC: la guía completa de validación IFC, calidad del modelo e IDS — IFC Viewer Online article cover
- 3 — capas de validación independientes
- 44 — reglas de calidad del modelo
- 6 — facetas IDS (buildingSMART 1.0)
- 0 — bytes subidos — solo en el navegador
Toda conversación sobre una entrega IFC acaba chocando con el mismo muro. El ingeniero de estructuras dice que el archivo pasó el validador. El coordinador BIM ve que falta la mitad de los conjuntos de propiedades y pregunta con qué validador. El EIR del cliente especifica requisitos de IDS que nadie ha comprobado. El CDE rechaza la subida. Tres semanas después, nadie tiene claro qué significa realmente «válido».
La confusión es comprensible: la palabra «validación» engloba tres operaciones completamente distintas que comparten nombre. Distinguirlas con claridad es una de las cosas con más impacto que un coordinador BIM puede hacer por un proyecto.
Tres problemas de validación completamente distintos
Piensa en una solicitud de licencia de obra. El técnico de control edificatorio verifica tres cosas de forma independiente: si los planos son legibles y están completos (integridad del archivo), si el diseño cumple la normativa de edificación (calidad y cumplimiento) y si cumple el encargo específico del cliente (requisitos del proyecto). Un plano legible puede ignorar por completo la normativa contra incendios. Un proyecto que cumple la normativa contra incendios puede pasar por alto totalmente la especificación acústica del cliente. Son preguntas distintas con respuestas distintas.
Nivel 1 — Integridad IFC
¿Es el archivo un IFC válido según la ISO 10303-21 y la ISO 16739-1? ¿Los GlobalId son únicos y cumplen el formato? ¿Es coherente la jerarquía espacial? Comprobación binaria a nivel de esquema.
Nivel 2 — Calidad del modelo
¿Son los datos realmente útiles para la coordinación? ¿Están rellenos los conjuntos de propiedades? ¿Siguen los elementos las convenciones de nomenclatura? ¿Hay clasificaciones presentes? Esto es lo que rige las entregas reales, no el cumplimiento del esquema.
Nivel 3 — Validación IDS
¿Satisface el modelo los requisitos de información contractuales de este proyecto? Los requisitos del EIR y del AIR codificados como especificaciones IDS legibles por máquina, comprobadas faceta a faceta contra cada elemento.
Estas tres capas son completamente independientes. Un archivo puede ser válido según el esquema de Nivel 1 y ser inútil para la coordinación porque no se exportó ningún conjunto de propiedades. Una comprobación IDS puede superar todos los requisitos declarados mientras el modelo tiene 400 GUID duplicados. Un Health Score de 91 no dice nada sobre si los requisitos de resistencia al fuego del cliente están codificados y se cumplen. Cada capa responde una pregunta distinta: las tres son necesarias antes de una entrega formal.
Nivel 1: integridad del archivo IFC — ¿es esto un IFC válido?
El Nivel 1 es la comprobación de esquema. Responde a una pregunta binaria: ¿cumple este archivo el esquema IFC (ISO 16739-1) y el formato de archivo físico (ISO 10303-21 STEP)? La mayoría de los analizadores de IFC aceptan sin avisar archivos que fallan las comprobaciones de Nivel 1: son permisivos por diseño, porque un rechazo estricto rompería demasiados flujos de trabajo. Esa permisividad oculta el daño hasta que aparece más adelante.
Qué cubre la comprobación de integridad de Nivel 1
- Unicidad del GlobalId: toda entidad IfcRoot debe tener un GlobalId único de 22 caracteres con el alfabeto base-64 propio del IFC. Los GlobalId duplicados son una infracción del esquema que los analizadores aceptan, pero que corrompe silenciosamente los flujos de BCF, el versionado en el CDE y los registros de activos de FM.
- Cumplimiento de formato del GlobalId: el primer carácter de un GlobalId IFC válido solo puede codificar los valores 0–3 (los dos bits significativos de un UUID de 128 bits). Los scripts que truncan UUID de forma ingenua producen caracteres iniciales fuera de rango: inválidos según la especificación, tolerados por la mayoría de los analizadores y rechazados por validadores estrictos.
- Integridad de la jerarquía espacial: el esquema IFC exige IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey. Los nodos ausentes (un Building directamente bajo Project, elementos físicos alojados en IfcSite) son infracciones del esquema con consecuencias reales más adelante.
- Integridad de la cadena IfcRelAggregates: las entidades de relación que construyen el árbol espacial deben referenciar entidades existentes. Las referencias colgantes (cuando una relación apunta a una entidad eliminada o inexistente) rompen la navegación del árbol en todas las herramientas posteriores.
- IfcRelContainedInSpatialStructure: los elementos físicos deben estar contenidos en un elemento espacial (normalmente IfcBuildingStorey). Los elementos sin relación de contención son huérfanos, invisibles en la navegación espacial de la mayoría de las herramientas.
- Exactamente un IfcProject: todo archivo IFC válido debe contener exactamente un IfcProject como raíz de la jerarquía. Los submodelos que lo omiten se analizan sin error, pero no tienen ancla espacial.
- Campos de cabecera FILE_NAME y FILE_DESCRIPTION: la cabecera del archivo STEP contiene metadatos de trazabilidad. La ISO 19650-2 exige que estén rellenos; la mayoría de las herramientas los dejan como cadenas vacías.
- Validez de la geometría: mallas no variedad (non-manifold), caras con área cero, sólidos con el sentido de las normales invertido, representaciones de contorno autointersecantes que no llegan a generar sólidos válidos en las herramientas receptoras.
Qué NO comprueba el Nivel 1
- Si los conjuntos de propiedades están rellenos o son correctos: un modelo válido según el esquema con cero Pset supera el Nivel 1.
- Si los nombres de los elementos siguen alguna convención de nomenclatura del proyecto.
- Si los códigos de clasificación están presentes, son correctos o son coherentes.
- Si se cumplen los requisitos de cantidades por LOD (IfcElementQuantity a partir de LOD 300).
- Si el modelo cumple algún requisito de información contractual o específico del proyecto.
El buildingSMART Validation Service para el Nivel 1
El buildingSMART IFC Validation Service (validate.buildingsmart.org) es la referencia autorizada para el cumplimiento de esquema de Nivel 1: usa el mismo motor que se emplea para certificar software IFC. Úsalo cuando necesites certificar la salida IFC de un exportador propio, cuando estés diagnosticando un archivo que los analizadores interpretan de forma inconsistente, o cuando una cláusula contractual exija explícitamente un certificado de esquema de buildingSMART.
Lo que no hace: comprobar la calidad de los datos, validar convenciones de nomenclatura, revisar si los conjuntos de propiedades están completos, comprobar los campos de metadatos ISO 19650 ni evaluar si el modelo cumple ningún requisito del proyecto. Es una herramienta de esquema, no un filtro de entrega de proyecto.
Inspecciona un IFC real y complejo — las tres capas de validación
Un edificio de oficinas de varias plantas exportado desde Revit. Abre la pestaña de Validación para ver el informe de calidad completo de 44 reglas y el Health Score. Después prueba a cargar una especificación IDS para ver la comprobación de Nivel 3 sobre el mismo modelo.
IFC4 · 14 MB
Abrir el visor IFC interactivo
Nivel 2: comprobación de calidad del modelo — la capa que realmente rige las entregas
La comprobación de calidad del modelo es la capa a la que se refiere la mayoría de los coordinadores BIM cuando dicen «validación IFC», aunque rara vez la llamen así. Responde a preguntas prácticas: ¿están aquí los datos? ¿Son correctos? ¿Son coherentes? ¿Puede alguien más adelante usar de verdad este modelo para coordinación, planificación de costes o FM?
A diferencia del Nivel 1, la comprobación de calidad no es binaria. Un modelo no simplemente aprueba o suspende: tiene un perfil de calidad a lo largo de decenas de dimensiones. El Health Score (0–100) agrega esas dimensiones en un único número que se puede fijar en el BEP, seguir a lo largo de las revisiones y adjuntar a los transmittals como evidencia de la calidad de la entrega.
Qué cubre la comprobación de calidad de 44 reglas
Reglas estructurales núcleo (18)
GUID duplicados, elementos huérfanos, contención incorrecta, agregaciones rotas, IfcProject ausente, nombres de elemento vacíos, ubicación de planta inválida. Las reglas que en la práctica provocan más rechazos en el CDE.
Espacial y cabecera de archivo (11)
Campos de metadatos ISO 19650 en IfcProject, autor y organización rellenos en FILE_NAME, ubicación del emplazamiento frente a las coordenadas compartidas, asociación de elemento a planta, integridad de las plantas del edificio.
LOD, clasificación, MEP (9)
Presencia de IfcElementQuantity a partir de LOD 300, IfcRelAssociatesClassification en elementos estructurales y arquitectónicos, conectividad de los sistemas MEP, uso excesivo de proxies (IfcBuildingElementProxy como % del modelo).
Geometría e integridad de plantas (6)
Validez de la caja envolvente de los elementos, orden de las cotas de las plantas, elementos por debajo de la cota de terreno, ausencia de forjado en la planta, desplazamiento del origen de coordenadas respecto al WCS, detección de colisiones (regla opcional, desactivada por defecto).
El Health Score: la calidad del modelo en un solo número
El Health Score usa una ponderación de penalización logarítmica. Los errores de esquema pesan 3 veces más que los avisos; los avisos pesan 3 veces más que las comprobaciones informativas. La instancia número 1000 del mismo problema resta muchos menos puntos que la número 10: esto evita que los modelos grandes y densos parezcan arbitrariamente peores que modelos pequeños y dispersos con la misma densidad de problemas. Un modelo con 800 avisos de nomenclatura puede sacar un 83; un modelo con 12 referencias espaciales rotas saca un 41. Lo que determina la puntuación es la gravedad, no el volumen.
- 31/100 — Crítico — fallos estructurales, no entregar
- 58/100 — Deficiente — requiere corrección importante
- 74/100 — Aceptable — válido solo para revisión interna
- 87/100 — Bueno — listo para entrega al CDE
- 96/100 — Excelente — calidad de hito ISO 19650
Qué NO hace la comprobación de calidad del modelo
- Verificar los requisitos de información específicos del proyecto: eso es el Nivel 3 (IDS). Las reglas de calidad son comprobaciones genéricas de buenas prácticas, no tu EIR.
- Corregir el modelo: la comprobación de calidad genera un informe. La corrección se hace en la herramienta de autoría o, para arreglos de propiedades y GUID, en un editor de propiedades IFC.
- Proporcionar el certificado de cumplimiento de esquema que exigen los programas de certificación de buildingSMART: eso es el Nivel 1, a través del buildingSMART Validation Service.
- Decirte si el modelo es geométricamente correcto: incluye algunas comprobaciones de integridad geométrica, pero un verificador de calidad no es una herramienta de detección de colisiones ni de autoría BIM.
Nivel 3: validación IDS — los requisitos de intercambio como código legible por máquina
El IDS (Information Delivery Specification) es un estándar de buildingSMART para codificar los requisitos de información específicos de un proyecto en un formato XML legible por máquina. Es el eslabón que falta entre un EIR —que es un documento de Word— y un motor de validación capaz de comprobar un modelo contra él de forma sistemática. El IDS 1.0 se convirtió en estándar oficial de buildingSMART en 2023.
Qué es realmente el IDS de buildingSMART
Un archivo IDS es un documento XML que contiene una o varias especificaciones. Cada especificación tiene una sección de aplicabilidad (¿a qué elementos se aplica?) y una sección de requisitos (¿qué deben tener esos elementos?). El motor comprueba todos los elementos del modelo que encajan con la aplicabilidad, verifica que cumplen todos los requisitos y reporta apto o no apto por elemento y por especificación. El resultado es un rastro de auditoría generado por máquina sobre el cumplimiento contractual.
El conjunto de pruebas de referencia de buildingSMART contiene 100 casos de prueba oficiales que definen el comportamiento esperado de cualquier motor de IDS conforme: son la especificación en forma ejecutable. Un motor de IDS que supera los 100 casos ha demostrado que interpreta las especificaciones .ids de forma coherente con el estándar.
Las seis facetas de IDS
- Entity: restringe la aplicabilidad o los requisitos por tipo de entidad IFC (IFCWALL, IFCDOOR, IFCBEAM) y, opcionalmente, por tipo predefinido. Es el filtro con el que empiezan la mayoría de las especificaciones.
- Attribute: comprueba valores de atributos IFC que residen directamente en la entidad — Name, Description, ObjectType, Tag, PredefinedType. Los atributos son distintos de los conjuntos de propiedades y se comprueban de otra manera.
- Property: comprueba una propiedad concreta dentro de un conjunto de propiedades concreto (Pset_WallCommon.FireRating, Pset_DoorCommon.IsExternal). Es la faceta más usada. Admite restricciones de tipo de dato y coincidencia de patrones sobre los valores.
- Classification: comprueba que los elementos llevan una referencia de clasificación mediante IfcRelAssociatesClassification — Uniclass 2015, OmniClass, NBS, o un esquema propio. Puede restringir el nombre del sistema de clasificación y el patrón del código.
- Material: comprueba que los elementos tienen un material asignado mediante IfcMaterial, IfcMaterialLayerSet o IfcMaterialConstituentSet. Opcionalmente restringe el nombre del material — útil para requisitos de resistencia al fuego o de sostenibilidad.
- PartOf: comprueba que los elementos participan en una relación espacial o lógica exigida — contenidos en una planta, agregados a un sistema del edificio, alojados en un edificio concreto. Es la faceta que impone el cumplimiento de la jerarquía espacial para tipos de elemento concretos.
<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
<ids:info>
<ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
<ids:description>Fire safety and classification requirements.</ids:description>
<ids:ifcVersion>IFC4</ids:ifcVersion>
</ids:info>
<ids:specifications>
<!-- All walls must carry a fire rating property -->
<ids:specification name="Wall FireRating required" minOccurs="1">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:property dataType="IFCLABEL">
<ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
<ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
</ids:property>
</ids:requirements>
</ids:specification>
<!-- Structural walls must carry a Uniclass 2015 classification -->
<ids:specification name="Structural wall classification" minOccurs="0">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
<ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:classification>
<ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
</ids:classification>
</ids:requirements>
</ids:specification>
</ids:specifications>
</ids:ids>
De EIR a IDS: el paso de traducción que la mayoría de los equipos se salta
Un EIR especifica qué información necesita el cliente. Un IDS codifica esos requisitos para que una máquina pueda comprobarlos. La traducción entre ambos es el paso que casi nadie da, porque exige a alguien que entienda tanto los requisitos de información como el esquema XML de IDS lo bastante bien como para escribir una especificación que compruebe exactamente lo que pide el EIR, ni más ni menos.
La consecuencia: los equipos o bien se saltan el IDS por completo y confían en una revisión manual informal en la entrega, o bien usan un archivo IDS genérico que no refleja su EIR real. Ambas cosas generan una falsa sensación de seguridad. Una comprobación IDS que supera una especificación genérica no dice nada sobre si se cumplen los requisitos concretos de tu cliente.
IDS por perfiles: un punto de partida práctico
No todos los equipos escriben el IDS desde cero. Un enfoque práctico es mantener una biblioteca de perfiles de IDS reutilizables: uno para arquitectura de fase 3, otro para MEP de fase 4, otro para la entrega de estructuras. Cada perfil cubre los requisitos más habituales de esa fase y disciplina, y se amplía en cada proyecto con las particularidades del cliente. Los perfiles de IDS se pueden cargar directamente en el motor de validación y combinar entre sí: puedes ejecutar varios archivos .ids contra el mismo modelo y agregar los resultados.
Cómo funcionan juntos los tres niveles — el proceso de validación
Las tres capas forman un control de calidad por el que el modelo pasa en secuencia. Cada nivel tiene una cadencia distinta: el Nivel 1 se ejecuta en cada exportación (una comprobación de cordura), el Nivel 2 se ejecuta antes de cualquier subida al CDE (el control de calidad) y el Nivel 3 se ejecuta antes de los hitos de entrega formales (la comprobación contractual). Ejecutarlos en el orden equivocado hace perder el tiempo: no tiene ningún sentido ejecutar el IDS contra un archivo con la jerarquía espacial rota.
┌──────────────────────────────────────────────────────┐
│ EXPORT IFC from authoring tool │
│ (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…) │
└───────────────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 1 — IFC Integrity │
│ • GlobalId uniqueness & format (leading char 0–3) │
│ • Spatial hierarchy: Project→Site→Building→Storey │
│ • IfcRelAggregates chain integrity │
│ • IfcRelContainedInSpatialStructure (no orphans) │
│ • Exactly one IfcProject │
│ • FILE_NAME header traceability fields │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix in authoring tool (or IFC property editor)
│ Pass
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 2 — Model Quality (44 rules) │
│ • Naming conventions / empty element names │
│ • Property set completeness (Pset_WallCommon etc.) │
│ • ISO 19650 metadata (IfcProject.LongName etc.) │
│ • Classification presence and consistency │
│ • LOD quantity sets, proxy audit, MEP connectivity │
│ → Health Score 0–100 │
└─────────┬────────────────────────────────────────────┘
Score<80 ◄┤ Fix properties / names in IFC editor or authoring tool
│ Score ≥ 80
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 3 — IDS Validation │
│ • Project-specific EIR / AIR requirements │
│ • .ids specification(s) for this milestone │
│ • Six facets: entity, attribute, property, │
│ classification, material, partOf │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix per IDS issue report → export BCF → remediate
│ All requirements met
▼
┌──────────────────────────────────────────────────────┐
│ DELIVER TO CDE │
│ Attach: Health Score report + IDS pass certificate │
└──────────────────────────────────────────────────────┘
Tabla comparativa: Nivel 1 frente a Nivel 2 frente a Nivel 3
| Dimensión | N1: integridad IFC | N2: calidad del modelo | N3: validación IDS |
|---|
| Pregunta que responde | ¿Es el archivo un esquema IFC válido? | ¿Son los datos útiles para la coordinación? | ¿Cumple los requisitos de información del proyecto? |
| Estándar | ISO 10303-21 (STEP), ISO 16739-1 (IFC) | Buenas prácticas BIM, normas ISO 19650 | buildingSMART IDS 1.0 (esquema XML) |
| Lo define | buildingSMART (esquema fijo) | Equipo BIM / EIR (reglas acordadas en el proyecto) | Cliente / promotor (por proyecto) |
| Resultado | Apto / no apto + lista de errores de esquema | Health Score 0–100 + lista de incidencias priorizada | Apto / no apto por especificación |
| ¿Puede sustituir a los otros? | No | No | No — hacen falta los tres |
| Cadencia | Cada exportación IFC | Antes de subir al CDE | Antes de cada hito de entrega |
| ¿Aprueba pero falla en otro? | Cero Pset, sin nombres → aprueba N1, falla N2 | Falta la resistencia al fuego (especificación IDS) → falla N3 | GUID duplicados, jerarquía rota |
| Herramientas de ejemplo | bSmart Validator, IFC Viewer Online | IFC Viewer Online, Solibri, IfcOpenShell | IFC Viewer Online (motor IDS), Solibri |
Cuándo usar el buildingSMART Validation Service — una valoración honesta
El buildingSMART IFC Validation Service comprueba los archivos contra el esquema oficial mediante un motor de varias partes: la sintaxis física del archivo STEP, las reglas EXPRESS del esquema IFC, las reglas de proposiciones informales derivadas de la especificación y las reglas normativas de restricción de IFC. Es la herramienta de referencia para el cumplimiento de esquema de Nivel 1.
Úsalo cuando
- Certificar la exportación IFC de un exportador propio: el comprobador de buildingSMART produce el resultado de referencia que se usa para certificar software. Ninguna otra herramienta lo sustituye en contextos de certificación.
- Diagnosticar inconsistencias entre analizadores: cuando un archivo se abre sin problemas en una herramienta y da errores en otra, el comprobador de buildingSMART determina qué comportamiento es correcto según el esquema. Esto tiene valor diagnóstico aunque el archivo sea usable de todos modos.
- Lo exige una cláusula contractual: algunas especificaciones de contratación citan el cumplimiento del esquema de buildingSMART como requisito de entrega. En ese caso, el certificado del servicio oficial es lo que satisface la cláusula.
- Validar el propio archivo IDS: el validador de esquema IDS de buildingSMART comprueba si tu archivo .ids es un documento IDS válido, algo distinto de ejecutarlo contra un modelo.
No lo uses como sustituto de
- La comprobación de calidad del modelo: el servicio no comprueba si los conjuntos de propiedades están completos, las convenciones de nomenclatura, la clasificación ni ninguna regla de calidad de datos.
- La validación específica del proyecto: el cumplimiento del esquema no dice nada sobre si el modelo cumple el EIR del cliente.
- La confirmación de entrega previa al CDE: un modelo válido según el esquema pero con Pset vacíos y nombres en blanco superará el comprobador de buildingSMART y fallará cualquier control de calidad con sentido.
Validador IFC en la nube frente a validador IFC en el navegador
La diferencia entre la validación en la nube (el archivo se sube a un servidor remoto) y la validación en el navegador (el archivo se procesa localmente mediante WebAssembly) importa más de lo que la mayoría de los equipos se imagina, sobre todo en proyectos de administración pública, defensa y proyectos comerciales sensibles.
Validación en el navegador
- El archivo IFC nunca sale del dispositivo
- Cumple el RGPD por diseño — sin transferencia de datos
- Funciona sin conexión: visitas de obra, redes restringidas
- Sin cuota de subida ni límite de tamaño de archivo
- Respuesta instantánea — sin latencia de ida y vuelta por red
- Rendimiento constante, independiente de la carga del servidor
- No requiere cuenta, clave de API ni suscripción
- Funciona en entornos de red restringidos de la administración
Validación en la nube
- El archivo se sube a un servidor remoto para procesarlo
- Requiere un acuerdo de tratamiento de datos (DPA) para el RGPD
- Adecuada para procesos de validación automatizados CI/CD
- Registro de auditoría centralizado entre proyectos y equipos
- Integración por API y webhook para automatizar entregas
- Escala horizontalmente para procesar modelos por lotes
- Puede ejecutarse sin interfaz, sin sesión de navegador
- Resultados consultables entre ejecuciones históricas
Cuándo tiene sentido la validación en la nube
- Procesos CI/CD automatizados: cuando la validación debe dispararse automáticamente cada vez que se sube o confirma un modelo, de forma parecida a como los equipos de software ejecutan pruebas automatizadas en cada push de código. Las API en la nube con webhooks son la arquitectura adecuada aquí.
- Auditoría a nivel de organización: cuando un BIM manager necesita un registro centralizado de las ejecuciones de validación en varios proyectos y equipos. Los servicios en la nube pueden agregar datos y ver tendencias entre ejecuciones de una forma que las herramientas locales no permiten.
- Procesamiento por lotes: auditar una biblioteca de modelos existentes —todos los archivos IFC entregados al CDE en los últimos dos años— resulta práctico en modo de lotes en la nube e impracticable de hacer a mano en el navegador.
- Modelos no sensibles: en proyectos donde los requisitos de tratamiento de datos no prohíben subir a la nube, los validadores en la nube ofrecen una integración con CI/CD que las herramientas de navegador no igualan.
Cuándo la opción en el navegador es la mejor elección
- Proyectos de administración pública y defensa: los modelos de infraestructura pública, instalaciones de defensa y activos sensibles suelen tener restricciones de tratamiento de datos que prohíben subirlos a servicios de terceros. La validación en el navegador es la única opción que cumple la normativa.
- Proyectos residenciales y comerciales sensibles: los modelos BIM suelen contener información de ocupantes, direcciones de propietarios y metadatos de activos que constituyen datos personales según el artículo 4 del RGPD. Procesarlos en un servidor de terceros sin un DPA válido y una base legal incumple la normativa.
- Uso en obra y en campo: un archivo IFC de 200 MB por una conexión 4G se sube lentamente y de forma poco fiable. La validación en el navegador lo procesa localmente en segundos, sin depender del ancho de banda de subida.
- Prevalidación antes de subir a la nube: incluso cuando un equipo usa un validador en la nube como filtro formal, ejecutar antes una comprobación en el navegador detecta los problemas evidentes sin necesidad de subir el archivo, lo que reduce el coste de uso de la nube y la frecuencia de subidas.
Seis errores de validación que cometen los equipos BIM — y qué significan en realidad
Error 1: «El IDS ha pasado — el modelo está bien»
El IDS solo valida lo que declara la especificación .ids. Si tu archivo exige FireRating en los muros, pero tu EIR también exige IsExternal en las puertas, códigos Uniclass en los elementos estructurales y conjuntos de cantidades en los forjados —y eso no se escribió en la especificación—, el motor informará de que se cumplen todos los requisitos mientras la mitad de tu EIR queda sin comprobar. Que el IDS pase es una confirmación contractual contra una especificación concreta, no un certificado de calidad general.
Error 2: «El comprobador de buildingSMART ha dicho que es válido»
La validez de esquema es el suelo, no el techo. Un archivo en el que todos los elementos tienen Name=«» y cero conjuntos de propiedades cumple el esquema perfectamente. Un modelo sin IfcElementQuantity, sin clasificación y con todos los elementos físicos colocados directamente en IfcSite en lugar de en una planta también cumple el esquema perfectamente. Superar el comprobador de buildingSMART significa que el archivo STEP tiene el formato correcto; no dice nada sobre si los datos son útiles.
Error 3: «Puedo abrirlo en un visor, así que está bien»
Los visores IFC son permisivos por diseño: están construidos para mostrar la geometría con independencia de la calidad de los datos. Un visor que se negara a abrir archivos inválidos según el esquema o pobres en datos sería inutilizable. Que la geometría se represente correctamente no dice nada sobre si los conjuntos de propiedades están completos, sobre las convenciones de nomenclatura, la estabilidad de los GUID, la clasificación ni ninguna de las 44 dimensiones de calidad. Visualizar un archivo es categóricamente distinto de validarlo.
Error 4: comprobar solo la geometría e ignorar los datos de propiedades
Un reflejo habitual es abrir el IFC, inspeccionar el modelo 3D y, si el edificio tiene buena pinta, dar el archivo por terminado. La geometría representa aproximadamente el 30 % de lo que hace útil a un archivo IFC. Los conjuntos de propiedades, las clasificaciones, los nombres de elemento, las asignaciones de tipo y los conjuntos de cantidades son lo que realmente consumen los sistemas de FM, los gestores de costes y los registros de activos del CDE. Un archivo geométricamente correcto pero con los conjuntos de propiedades en blanco falla en la entrega.
Error 5: validar una sola vez, justo en el plazo de entrega
Tratar la validación como el último paso antes de subir al CDE significa corregir incidencias bajo presión y sin margen. Un modelo con 800 incidencias de validación descubiertas el día antes del plazo o se entrega con problemas conocidos, o incumple el plazo. La cadencia correcta: Nivel 1 después de cada exportación, Nivel 2 antes de cada revisión interna (semanal como mínimo), Nivel 3 dos semanas antes de cada hito formal.
Error 6: ignorar la estabilidad de los GUID entre reexportaciones
Los GUID duplicados dentro de un mismo archivo son un problema de Nivel 1 y cualquier validador los detecta. Pero la inestabilidad de los GUID entre reexportaciones —cuando el mismo elemento recibe un GlobalId distinto cada vez que se exporta el modelo— es invisible para la validación de un solo archivo. Cuando los GlobalId cambian entre revisiones, todos los comentarios de BCF, las referencias a elementos del CDE y las etiquetas de activos de FM se convierten silenciosamente en referencias colgantes. Esto exige comparar dos revisiones y revisar la configuración de exportación, no basta con validar un solo archivo.
Un flujo de validación práctico para coordinadores BIM
- Después de cada exportación IFC: ejecuta una comprobación de Nivel 1. Tarda menos de 30 segundos en cualquier validador basado en navegador. Corrige los GlobalId duplicados, los elementos huérfanos y las roturas de la jerarquía espacial antes de que se acumulen entre revisiones.
- Antes de cada revisión interna (semanal o por sprint): ejecuta una comprobación completa de calidad de Nivel 2. Revisa la tendencia del Health Score. Una puntuación que baja entre revisiones significa que se están introduciendo incidencias nuevas: encuentra el origen antes de que se convierta en un patrón.
- Al recibir cualquier modelo de disciplina de un tercero: ejecuta el Nivel 1 y el Nivel 2 antes de federar. Un modelo que recibes puede arrastrar incidencias que heredas en el modelo de coordinación: detéctalas de inmediato, no tres semanas después de coordinar sobre una federación rota.
- Dos semanas antes de cualquier entrega de hito formal: ejecuta los tres niveles. Objetivo de Health Score ≥ 80 antes del IDS. Dos semanas dan margen para corregir sin presión. Avisa pronto: no te comas el margen.
- Antes de subir al CDE: ejecuta el Nivel 2 y el Nivel 3. Adjunta el certificado de Health Score y el informe de resultado del IDS al transmittal. Esto crea un rastro de auditoría documentado y le da al information manager todo lo necesario para aceptar la entrega.
- Después de cualquier actualización de la herramienta de autoría o cambio en la configuración de exportación: vuelve a establecer la línea base de estabilidad de los GUID comparando dos exportaciones consecutivas. Una actualización de Revit o un cambio en la configuración de exportación puede alterar silenciosamente cómo se generan los GlobalId.
Consejos de experto
Prioriza por penalización, no por cantidad
No corrijas las incidencias por orden de volumen, corrígelas por orden de impacto en el Health Score. Tres campos de metadatos de IfcProject ausentes pueden costar 15 puntos. Ochocientos avisos de nomenclatura pueden costar 8 puntos en total. Usa el desglose por gravedad para priorizar por impacto.
Fija la configuración de exportación en una plantilla
Cada vez que se reconfigura manualmente la exportación, existe el riesgo de acabar con una configuración distinta. Crea una configuración de exportación IFC con nombre en tu herramienta de autoría, incorpórala a la plantilla del proyecto y documenta la configuración exigida en el BEP. La deriva de configuración es la causa raíz de la mayoría de los problemas de exportación del tipo «la última vez funcionaba».
Traduce el EIR a IDS al inicio del proyecto
Traduce las cláusulas más críticas del EIR a una especificación IDS en las dos primeras semanas del proyecto. Incluso un archivo .ids parcial —cinco o seis especificaciones— es mejor que revisar todo el EIR a mano en el momento de la entrega, y detecta pronto los vacíos de datos sistemáticos, cuando aún son baratos de corregir.
Valida cada modelo de disciplina antes de federar
Las incidencias de un modelo de disciplina pueden ocultar o interactuar con las de otro dentro de una federación. Valida las entradas limpias y federa limpio. Validar únicamente el modelo de coordinación después de federar dificulta asignar cada incidencia al originador correcto.
Preguntas frecuentes
¿Superar el Nivel 1 significa que puedo saltarme el Nivel 2?
No. El Nivel 1 y el Nivel 2 miden propiedades completamente distintas de un archivo. Un archivo válido según el esquema (Nivel 1) puede tener cero conjuntos de propiedades, nombres de elemento vacíos, ninguna clasificación y ningún metadato ISO 19650 — y sacar un 20 en la comprobación de calidad (Nivel 2). Siempre hacen falta los dos. Piensa en el Nivel 1 como «el archivo está correctamente empaquetado» y en el Nivel 2 como «el contenido del paquete es el que se pidió».
¿Sustituye el IDS al buildingSMART Validation Service?
No. El IDS comprueba los requisitos de información específicos del proyecto (Nivel 3). El buildingSMART Validation Service comprueba el cumplimiento del esquema (Nivel 1). Operan en niveles completamente distintos y resuelven preguntas distintas. Un modelo que supera el IDS pero falla la validación de esquema sería una contradicción lógica: la integridad de Nivel 1 es un requisito previo para que la comprobación de Nivel 3 tenga sentido.
¿Qué facetas de IDS debería priorizar en una entrega BIM estándar?
La faceta Property cubre entre el 70 % y el 80 % de los requisitos de EIR reales: la mayoría de los clientes quieren valores concretos rellenos en conjuntos de propiedades de tipos de elemento concretos. Classification cubre la mayor parte del resto en proyectos regidos por Uniclass o por OmniClass. La faceta Entity aparece en casi todas las especificaciones como filtro de aplicabilidad. Material y PartOf resuelven requisitos contractuales concretos. Empieza por Entity + Property, añade Classification si tu EIR lo exige, y amplía a partir de ahí.
¿Puedo validar un IFC sin subirlo a ningún sitio?
Sí. Los validadores basados en el navegador procesan el archivo por completo en tu propio navegador mediante WebAssembly. Los bytes del IFC nunca salen de tu dispositivo: las 44 reglas de calidad, el cálculo del Health Score y el motor de IDS completo se ejecutan en el cliente. Para modelos con restricciones de tratamiento de datos —activos de la administración pública, datos residenciales sensibles, infraestructura de defensa—, esta suele ser la única opción que cumple la normativa.
¿Qué umbral de Health Score debería fijar en el BEP?
≥ 80 es el umbral estándar para la entrega al CDE y la coordinación de diseño. ≥ 90 para entregas de desarrollo de diseño LOD 300+ y para hitos formales ISO 19650. ≥ 70 es aceptable en revisiones internas de fase de concepto. Por debajo de 60, el modelo tiene problemas de calidad estructurales y no debería entregarse a ningún tercero bajo ninguna circunstancia.
¿Puede una sola herramienta cubrir los tres niveles de validación?
Algunas sí. IFC Viewer Online cubre el Nivel 1 (reglas de integridad, incluidas las comprobaciones de GUID, jerarquía y cabecera del archivo), el Nivel 2 (comprobación de calidad de 44 reglas con Health Score) y el Nivel 3 (motor de IDS 1.0 validado contra los 100 casos de prueba oficiales de bSI). Solibri cubre el Nivel 2 y el Nivel 3 con un motor de reglas más sofisticado, pero sin procesamiento en el navegador. El buildingSMART Validation Service cubre únicamente el Nivel 1. IfcOpenShell se puede programar mediante scripts para el Nivel 1 y el Nivel 2.
Resumen
Ser válido según el esquema no es ser válido para el proyecto. Ser válido para el proyecto no es cumplir el EIR. Hacen falta las tres capas de validación, y confundirlas es la causa raíz de la mayoría de las entregas formales rechazadas.
IFC Viewer Blog
Nivel 1: ejecútalo en cada exportación
Integridad de esquema, unicidad y formato del GlobalId, jerarquía espacial. Tarda 30 segundos. Detecta los fallos estructurales que corrompen silenciosamente el BCF, el versionado del CDE y los registros de activos de FM más adelante.
Nivel 2: filtro de cada entrega al CDE
44 reglas de calidad, Health Score, convenciones de nomenclatura, integridad de los conjuntos de propiedades, metadatos ISO 19650. Exige ≥ 80 en tu BEP y en tu EIR. Es la capa que hace que un modelo sea útil, no solo analizable.
Nivel 3: verifícalo antes de cada hito
Especificaciones IDS que codifican tu EIR y tu AIR en forma legible por máquina. Traduce las cláusulas críticas al inicio del proyecto, no la semana antes de la entrega. Que el IDS pase es un rastro de auditoría contractual documentado.
Ejecuta una comprobación de calidad completa sobre tu modelo actual: menos de 30 segundos en cualquier navegador, sin subir nada. Después lee la guía del Health Score de IFC para entender cómo se calcula la puntuación y qué umbral fijar en tu BEP. Si hay que corregir valores de propiedades o GUID en un archivo recibido, la guía del editor de IFC online gratuito cubre la edición no destructiva de propiedades sin pasar de nuevo por la herramienta de autoría. Y para los fallos estructurales más comunes que provocan rechazos de Nivel 1, consulta los 7 errores de validación IFC más comunes.
Verificador de modelos IFC: la guía completa de validación IFC, calidad del modelo e IDS