Control de calidad IFC: encuentra el error antes de la entrega
El IFC abrió a la primera. El visor mostró el hospital completo, las plantas estaban en su sitio y nadie recibió un mensaje rojo. Durante unos minutos, la entrega pareció correcta. Después coordinación intentó filtrar puertas cortafuego, mediciones buscó tipos de muro y el equipo de explotación preguntó por los códigos de los equipos. La geometría seguía allí, impecablemente visible; la información necesaria había tomado otro camino.
El control de calidad IFC empieza cuando dejamos de preguntar si el archivo se abre y preguntamos si sirve para el uso acordado. Un modelo puede ser sintácticamente válido y fallar en propiedades, relaciones, clasificación, coordenadas o selección de objetos. Revisarlo exige conocer el requisito, comprobar el archivo exportado y separar lo que una regla puede validar de lo que necesita criterio profesional.
Tabla de contenidos
La primera pista estaba en el propósito de la entrega
El paquete debía apoyar coordinación, medición de varias partidas y preparación de activos. Cada uso necesitaba información diferente. Para coordinar importaban geometría, posición y disciplinas completas. Para medir, tipos, materiales y clasificación. Para activos, identificadores, sistemas y propiedades mantenibles.
El equipo convirtió esos usos en requisitos verificables. Las puertas resistentes al fuego debían pertenecer al conjunto correcto, declarar la prestación acordada y conservar un identificador. Los muros medibles necesitaban tipo, clasificación y cantidades coherentes. Los equipos incluidos debían relacionarse con un sistema y una ubicación.
Sin esta definición, cualquier revisión habría sido arbitraria. Encontrar diez parámetros vacíos no indica gravedad si ninguno forma parte del intercambio. En cambio, perder un único código que conecta el activo con mantenimiento puede invalidar todo un uso.
Validar el contenedor no validó el proyecto
La primera comprobación revisó que el archivo siguiese el esquema esperado y pudiera interpretarse. Detectó entidades y relaciones mal formadas, referencias rotas y valores incompatibles con la estructura. Era una barrera necesaria: si el contenedor está corrupto, analizar el contenido será una excursión corta.
Sin embargo, un archivo conforme al esquema puede representar información equivocada. Una puerta puede existir como entidad válida y carecer de la propiedad necesaria. Un equipo puede clasificarse como elemento genérico. Las coordenadas pueden ser legales y no coincidir con el resto de modelos.
El informe separó validación sintáctica, semántica y de uso. Así, «IFC válido» dejó de funcionar como certificado universal. Era una conclusión concreta sobre una capa concreta.
La geometría se revisó con preguntas de producción
El visor permitió inspeccionar plantas, volúmenes y elementos. El equipo comparó extensiones, número de pisos y posición con referencias conocidas. Buscó objetos desplazados, geometrías ausentes y elementos convertidos en representaciones que otras herramientas no interpretaban bien.
No se pretendía comprobar cada triángulo. Se seleccionaron muestras y condiciones críticas: huecos, elementos inclinados, familias complejas y objetos necesarios para coordinación. Una exportación visualmente parecida podía cambiar sólidos, perder aperturas o fragmentar elementos de forma que afectase a medición.
Las tolerancias dependían del uso. Una pequeña diferencia geométrica podía ser irrelevante para visualización y crítica para prefabricación. El control indicaba objetivo y severidad; no aplicaba un milímetro sagrado a todo el edificio.
Las propiedades necesitaron algo más que estar presentes
El IFC incluía muchos conjuntos de propiedades, pero varias prestaciones aparecían como texto libre. «EI60», «60 min» y «RF-60» describían intenciones relacionadas sin ser equivalentes para una regla. El equipo acordó nombre, tipo y valores permitidos.
Las comprobaciones revisaron presencia, tipo, formato y coherencia. Un valor no bastaba si pertenecía al objeto equivocado o representaba una unidad distinta. También se evitó exigir información a categorías fuera del alcance.
Los resultados conservaban entidad, identificador, propiedad, valor encontrado y requisito. De este modo, el autor podía corregir la fuente en Revit u otra aplicación, no rellenar una copia del IFC que quedaría desconectada del siguiente ciclo.
Las relaciones explicaron el edificio mejor que una lista plana
Los equipos existían, pero algunos no estaban vinculados a sistemas. Varias puertas no quedaban contenidas en el espacio esperado y ciertos elementos perdían su planta. Para explotación y análisis, estas relaciones eran tan importantes como las propiedades.
El control revisó descomposición, contención espacial, tipificación y conexiones necesarias. No todas las herramientas de autor exportaban igual, por lo que se probaron configuraciones reales y versiones. La expectativa se alineó con el intercambio acordado, no con una idea abstracta del estándar.
Una relación ausente podía deberse al modelo de origen, al mapeo o a la configuración. El informe evitaba declarar culpable al autor sin investigar la cadena. El IFC mostraba el síntoma; la corrección debía encontrar su origen.
La vista de intercambio recortó lo que debía viajar
El equipo no necesitaba todas las posibilidades del esquema. Definió un subconjunto apropiado al uso y documentó las restricciones. Esta visión de intercambio ayudó a acordar entidades, geometrías y relaciones soportadas.
Elegir una MVD o configuración conocida no sustituía los requisitos del proyecto. Dos entregas bajo la misma vista podían diferir en propiedades exigidas. La especificación técnica del intercambio debía combinar alcance estándar y necesidades concretas.
También se comprobó que las aplicaciones receptoras interpretasen el resultado. La conformidad aislada tenía poco valor si el flujo real perdía información al importar. Interoperabilidad significa completar un recorrido, no aprobar una casilla.
IDS convirtió requisitos repetibles en controles
Para propiedades y clasificaciones, el equipo formalizó requisitos mediante reglas legibles por máquina cuando el flujo lo permitía. Se declaraba a qué entidades aplicaban, qué propiedad se esperaba y qué valores eran válidos.
El IDS no decidía si el modelo resolvía bien el hospital. Comprobaba información acordada. Esa frontera evitaba cargar sobre la regla decisiones espaciales o normativas que necesitaban contexto.
Antes de usarlo como bloqueo, se probó con archivos correctos, incorrectos y ambiguos. Los falsos positivos llevaron a ajustar alcance y vocabulario. Un requisito mal escrito puede generar un informe impecable sobre el problema equivocado.
El visor, las reglas y la revisión manual hicieron trabajos distintos
| Necesidad | Herramienta principal | Límite |
|---|---|---|
| Inspeccionar posición y geometría | Visor y comparación visual | No demuestra propiedades completas |
| Comprobar requisitos repetibles | Validador de esquema, IDS o reglas | Solo evalúa lo formalizado |
| Analizar intención y aceptabilidad | Revisión profesional | Necesita evidencia preparada |
| Investigar una pérdida | Modelo origen, mapeo y exportación | El IFC muestra el resultado, no siempre la causa |
La matriz apareció al recorrer el problema. Ninguna herramienta cubría todas las preguntas. El visor encontraba anomalías espaciales; las reglas recorrían miles de objetos; las personas interpretaban consecuencias y excepciones.
Las severidades evitaron que todo pareciese urgente
Un archivo ilegible bloqueaba. También lo hacía perder coordenadas o información crítica para el uso. Una propiedad opcional podía ser advertencia. Los resultados informativos ayudaban a mejorar sin impedir la entrega.
Las severidades se acordaron antes de ejecutar y se vinculaban a una acción. Si todo era rojo, el equipo aprendía a ignorar el rojo. Si nada bloqueaba, el control era un informe ceremonial.
Las excepciones tenían alcance, motivo, responsable y vigencia. Aceptar temporalmente una clasificación no modificaba la regla para todos los proyectos. El historial permitía revisar si una excepción recurrente indicaba un requisito mal definido.
La corrección volvió al modelo de origen
El primer impulso fue editar propiedades en una herramienta IFC. Podía resolver una entrega puntual, pero el siguiente archivo repetiría el fallo. El equipo rastreó cada problema hacia parámetros, mapeo o configuración de exportación.
En Revit, algunas propiedades no estaban informadas; otras utilizaban nombres que el mapeo no reconocía. Varios tipos se exportaban como entidades genéricas. Se corrigieron plantillas y configuración, luego se generó un nuevo archivo.
El control volvió a ejecutarse sobre la exportación. No se asumió que arreglar Revit garantizase el IFC. La verificación final debía observar el artefacto que recibirían los demás.
Comparar versiones redujo revisiones repetidas
En la segunda entrega, el equipo quería saber qué se había corregido y qué había cambiado accidentalmente. Se compararon recuentos, propiedades críticas, relaciones y resultados de reglas. Los identificadores ayudaron cuando permanecían estables.
No toda diferencia era error. El proyecto evolucionaba. El informe separaba cambios esperados, incidencias resueltas, persistentes y nuevas. Una alteración masiva de identificadores activaba una investigación porque podía romper trazabilidad.
La comparación no reemplazaba una revisión completa en hitos importantes, pero dirigía atención. Revisar solo diferencias ahorra tiempo mientras la base y el método sigan siendo fiables.
El control también necesitó mantenimiento
Las reglas tenían versión y propietario. Cambios en requisitos, esquema, exportador o aplicación receptora activaban pruebas. Los archivos de referencia se conservaron para detectar regresiones.
El equipo medía falsos positivos, tiempo de corrección y fallos recurrentes. Si una regla no conducía a decisiones, se ajustaba o retiraba. Añadir controles indefinidamente no aumenta calidad; puede sepultarla.
La documentación explicaba uso, alcance y límites. También registraba configuraciones compatibles. Un control de calidad depende de su contexto técnico, aunque el botón siga llamándose igual tras actualizar el software.
Cuándo IFC no debe cargar con toda la solución
IFC es útil para intercambio abierto, revisión y conservación de información acordada. No siempre mantiene cada comportamiento nativo de la herramienta de autor. Si una tarea depende de editar familias, restricciones paramétricas o funciones específicas, quizá necesite el modelo original.
Tampoco todo control normativo puede reducirse a propiedades. La accesibilidad o seguridad pueden requerir interpretar geometría, uso y condiciones. Las reglas preparan evidencia y detectan candidatos; la responsabilidad permanece en profesionales competentes.
En una colaboración pequeña y directa, un control manual acotado puede ser suficiente. La automatización gana valor con volumen, repetición y necesidad de trazabilidad. Configurar un sistema complejo para una entrega única también puede ser un error de calidad, esta vez presupuestaria.
El IFC correcto fue el que permitió continuar el trabajo
La segunda exportación seguía abriendo sin errores, pero ahora ese hecho era solo el primer resultado. Las puertas cortafuego podían filtrarse, los muros conservaban información de medición y los equipos se relacionaban con sistemas e identificadores. Las excepciones estaban documentadas.
El control de calidad IFC merece ese enfoque: definir uso, validar estructura, revisar geometría, comprobar propiedades y relaciones, y devolver cada fallo con contexto. Después hay que corregir el origen y verificar otra vez el archivo entregado.
Si tu única prueba es girar el modelo en un visor y decir «se ve bien», disfruta del momento. Luego busca una propiedad importante. IFC tiene una habilidad especial para parecer completo justo antes de que intentes utilizarlo.
Respuestas