Control de calidad IFC: revisa una entrega con criterio

El edificio gira, las fachadas aparecen y alguien concluye que el IFC está bien. Una auditoría extraordinariamente económica: con ese método también podríamos aprobar un presupuesto porque el PDF permite hacer zoom. Abrir el archivo demuestra una parte del recorrido; no confirma que estén los elementos y datos que necesita quien lo recibe. Vamos a separar esas comprobaciones antes de que la siguiente entrega vuelva a pasar el examen de «se ve bastante bonito».

El control de calidad IFC consiste en comprobar que el archivo entregado sirve para el uso acordado. Que pueda leerse es una condición inicial; coordinar, medir o gestionar activos exige además información concreta y relaciones coherentes. Vamos a recorrer un ejemplo hipotético de entrega de un edificio para entender qué revisar, cómo interpretar los resultados y cómo devolver un problema a quien puede resolverlo. Sin convertir cada aviso en una catástrofe ni cada casilla verde en una licencia para dejar de pensar.

Empieza por lo que el receptor necesita hacer

Imagina que la entrega debe permitir localizar los equipos de climatización que pasarán a mantenimiento. El receptor necesita reconocer cada equipo, situarlo en una planta y relacionarlo con un sistema. Puede que también necesite fabricante y modelo, pero solo cuando esos datos deban estar disponibles en ese hito. Pedirlos durante una fase en la que aún no se han seleccionado los productos generaría una colección muy ordenada de incumplimientos previsibles. La informática tiene esa virtud: ejecuta con disciplina incluso las peticiones absurdas.

Antes de abrir una herramienta de revisión conviene escribir una frase comprobable: «Los equipos incluidos en el alcance de esta entrega deben disponer de un código de activo único dentro del edificio y una ubicación identificable». Después hay que concretar dónde se espera encontrar ese código, qué elementos están incluidos y qué significa una ubicación aceptable. Un número de planta escrito en cualquier propiedad no equivale necesariamente a la relación espacial que utilizará el sistema receptor. Si las partes entienden cosas distintas, el validador llegará puntual a una discusión que ya estaba servida.

El alcance necesita ejemplos de inclusión y exclusión. ¿Se entregan los equipos proyectados, los instalados o ambos? ¿Qué ocurre con los elementos de referencia, los objetos de otro edificio y los componentes que forman parte de un conjunto? Esas decisiones determinan el denominador de la revisión. Un informe que dice «el 98 % tiene código» puede ser inútil si ha contado también accesorios que no debían llevarlo o ha dejado fuera los equipos problemáticos. Primero se define la población; después se celebra el porcentaje.

Para organizar el trabajo basta una ficha breve por requisito: propósito, elementos afectados, dato esperado, criterio de aceptación, responsable y momento de entrega. No hace falta redactar una enciclopedia de propiedades para descubrir que el código acordado se ha exportado a otro conjunto de propiedades. El esfuerzo inicial debe concentrarse en los datos que desbloquean un uso real. Esa ficha también permitirá discutir un fallo sin depender de quién recuerde mejor lo que se comentó hace tres reuniones.

Revisa el archivo por capas, sin confundir sus garantías

La primera capa comprueba que el archivo puede interpretarse y respeta las reglas que se hayan incluido en la validación del formato y del esquema. Es una revisión distinta de comprobar si contiene los equipos contratados. El servicio de validación de buildingSMART explica esa separación: sus comprobaciones de conformidad IFC no sustituyen los requisitos específicos de un proyecto. Un archivo puede superar esas comprobaciones y seguir siendo inútil para nuestro mantenimiento. No hay contradicción: ha aprobado un examen diferente.

La siguiente capa revisa el contenido del intercambio. En nuestro ejemplo interesa comprobar la presencia y el formato del código, su unicidad dentro del alcance definido, la identificación del equipo y su relación con la ubicación. Conviene distinguir un dato inexistente de otro presente pero vacío y de otro que tiene un valor no permitido. Los tres impiden usar el dato, pero apuntan a causas distintas: configuración de exportación, información pendiente o un criterio que el equipo no está aplicando igual.

También hay una capa geométrica y espacial. Que un equipo esté relacionado con una planta no demuestra que su geometría esté en el lugar esperado; que aparezca en el lugar esperado tampoco garantiza que esté relacionado correctamente. Para coordinación habrá que comprobar referencias, unidades, posición y completitud con un alcance propio. Una inspección visual ayuda a detectar desplazamientos llamativos, pero no convierte una tolerancia sin definir en un criterio objetivo. «Parece cerca» es una observación. Sigue sin ser una regla de aceptación.

Las herramientas pueden cubrir varias capas, aunque cada función conserva sus límites. La validación de IfcOpenShell, por ejemplo, documenta comprobaciones de instancias y opciones para reglas EXPRESS, además de limitaciones que obligan a atender también a los errores de lectura. Eso no certifica por sí mismo la idoneidad del diseño. Conviene guardar qué versión de la herramienta se utilizó y qué comprobaciones se activaron: «validado» sin ese contexto describe más una sensación que un resultado reproducible.

Convierte los hallazgos en decisiones que alguien pueda tomar

Supongamos que el archivo contiene cuarenta equipos dentro del alcance: treinta y seis tienen código, dos lo tienen vacío y otros dos comparten el mismo. Es un ejemplo inventado para seguir el razonamiento. El informe útil conserva los cuarenta elementos evaluados y permite distinguir los cuatro casos que requieren intervención. Si solo muestra una luz roja junto al nombre del archivo, alguien tendrá que repetir la investigación. Hemos automatizado la alarma y dejado intacto el trabajo pesado, una modalidad bastante popular de progreso.

Cada hallazgo debería identificar el elemento y la revisión del archivo, explicar la regla, mostrar el valor observado y describir el valor o la condición esperados. Añadir planta, tipo o una vista ayuda a encontrarlo; no sustituye al identificador. El receptor debe poder responder «este equipo no entra en el alcance» o «el dato está en otra propiedad» con evidencias. Esa conversación mejora tanto el modelo como la regla. Un control de calidad que solo admite obediencia acabará acumulando excepciones fuera del sistema.

La gravedad depende del uso bloqueado. Un código duplicado puede impedir enlazar un activo de forma inequívoca con mantenimiento y ser un fallo que detenga esa entrega. Una descripción opcional abreviada puede merecer una advertencia. Y si no se puede determinar si un objeto entra en el alcance, conviene marcarlo como no evaluable o pendiente de aclaración, según el procedimiento acordado. Presentarlo como correcto porque no se ha podido comprobar es una forma muy eficiente de fabricar tranquilidad artificial.

Una excepción aceptada también necesita contexto: quién la aprueba, por qué, para qué revisión y durante cuánto tiempo. Puede ser razonable admitir temporalmente un equipo sin fabricante si la selección está pendiente y el hito lo permite. Esa aceptación no debería borrar el hallazgo ni reaparecer como aprobación automática en todas las entregas futuras. Las excepciones tienen tendencia a convertirse en patrimonio del proyecto cuando nadie les pone fecha ni propietario.

Corrige la causa y vuelve a comprobar la entrega exportada

Cuando falta un código, el problema puede estar en el modelo de origen, en una asignación de propiedades de la exportación o en la propia regla de revisión. Corregir directamente el IFC recibido puede servir en determinados procesos, pero cambia cuál es la fuente que conserva la solución. Si la siguiente exportación vuelve a producir el mismo fallo, no hemos arreglado el intercambio: le hemos aplicado maquillaje entre entregas. Para un flujo repetible conviene resolver la causa donde corresponde y documentar cualquier transformación posterior.

En el ejemplo, los dos códigos vacíos podrían completarse en el modelo de autoría y el duplicado podría exigir acordar qué equipo conserva el identificador. Después se exportaría de nuevo y se revisaría ese nuevo archivo. Comprobar solo que el parámetro se ve bien en Revit u otra aplicación no demuestra que llegue bien al IFC. La exportación es una operación con configuración, selección y posibles pérdidas. El destinatario trabaja con su resultado, no con las buenas intenciones del modelo original.

La comparación entre revisiones debe conservar tanto los fallos resueltos como los nuevos y los que siguen presentes. Si desaparece un equipo del archivo, su incidencia no puede cerrarse alegremente como si ahora tuviera código: tal vez se ha eliminado del alcance o quizá se ha omitido por error. También conviene detectar cambios de identificador que dificulten seguir un elemento. No todos serán incorrectos, pero necesitan una explicación para que el seguimiento no dependa únicamente de contar filas.

Guarda juntos el archivo revisado, la versión de las reglas y el informe. Si el modelo es confidencial, distribuye los resultados solo a quienes los necesitan y comprueba las condiciones del proyecto antes de subirlo a un servicio externo. Al principio basta una carpeta de entrega identificada y un registro legible. Un PDF llamado «revisión definitiva buena ahora sí» no identifica qué se comprobó; documenta, con bastante sinceridad, que el sistema de versiones se ha rendido.

Empieza con pocas reglas y comprueba que detectan el problema

Un primer control útil puede centrarse en los equipos del ejemplo, su código y su ubicación. Antes de aplicarlo a una entrega completa, prepara casos pequeños conocidos: un equipo correcto, otro sin código, dos con el mismo código y un elemento que deba quedar fuera. Añade un caso ambiguo para comprobar cómo se comunica la imposibilidad de evaluarlo. Así se descubre si la herramienta está revisando lo que creemos o si está aprobando todo porque no encuentra ningún elemento. Un cero fallos puede esconder un cero comprobaciones.

Cuando el control sea estable, incorpora requisitos nuevos según el valor que aporten. Los requisitos de información que encajen en su alcance pueden expresarse con IDS; la geometría, las relaciones más complejas y las condiciones específicas pueden necesitar otras herramientas o código. Lo sensato es combinar comprobaciones que se complementen y explicar qué cubre cada una. No hace falta que una sola aplicación reúna todo el conocimiento del proyecto para que el proceso sea fiable.

El resultado que buscamos es que el receptor pueda utilizar el modelo y que el emisor entienda cómo resolver lo que lo impide. Una captura del edificio seguirá siendo útil para orientarse, pero ya no cargará con la responsabilidad de certificar toda la información. La próxima vez que alguien diga «el IFC abre, así que está bien», podrás preguntar para qué uso se ha revisado. Con amabilidad, si es posible. Con una regla y un informe, en cualquier caso.

Acordar el uso del IFC permite decidir qué comprobar y qué error bloquea la entrega. Conserva archivo, reglas e informe de la misma revisión, y evita aprobar lo que no has podido evaluar. Cuando el siguiente control termine con «se abre», pregunta qué más necesitaba demostrar. La capacidad de orbitar merece reconocimiento; la calidad del intercambio exige un examen distinto.