IDS: requisitos de información comprobables en IFC

«El modelo incluirá la información necesaria para mantenimiento». Todo el mundo asiente porque todavía nadie ha tenido que concretar qué entiende por necesaria. Instalaciones piensa en fabricante; explotación, en código de activo; alguien entrega Observaciones2 y considera el asunto resuelto. Me han encargado traducir ese prodigio de consenso a condiciones comprobables. Con gusto: una máquina necesita algo más que una frase diseñada para que ninguna reunión termine en discusión.

Information Delivery Specification, o IDS, es un estándar de buildingSMART para expresar requisitos de información interpretables por software sobre IFC. Nos obliga a concretar qué objetos deben cumplir qué condiciones. Vamos a seguir un caso hipotético de equipos de climatización para entender cómo se pasa de una petición genérica a una comprobación útil, qué significa el resultado y qué preguntas seguirán necesitando otra herramienta o una decisión profesional.

Antes de redactar el IDS, acuerda qué necesita el receptor

Imagina una entrega final en la que mantenimiento debe identificar determinados equipos instalados. Se acuerda un código de activo, fabricante y modelo comercial. Antes de convertirlo en una especificación hay preguntas bastante terrenales: qué equipos entran, en qué hito se exige cada dato y dónde debe aparecer en el IFC. Exigir un modelo comercial definitivo durante una fase en la que solo existen equipos genéricos no mejora la información; prepara una lista de incumplimientos que el propio encargo hacía inevitables.

El responsable de mantenimiento debe explicar para qué utiliza cada campo. Si el código enlaza con un registro externo, no basta con que sea un texto cualquiera. Si el fabricante solo facilita una consulta humana, quizá sea suficiente un valor informado con una convención acordada. Y si necesitamos comprobar que el producto coincide con una compra aprobada, entrará en juego otra fuente. Es importante separar esas preguntas antes de que todas acaben empaquetadas bajo la palabra «validación».

Prepara ejemplos pequeños: un equipo que debe cumplir, uno genérico que todavía queda fuera y otro instalado al que le falta el código. Añade un caso dudoso, como un elemento cuya clasificación no permite determinar su inclusión. Estos ejemplos fuerzan a resolver lo que la frase original dejaba abierto. La especificación empieza a ser útil cuando dos personas pueden aplicarla al mismo objeto y llegar al mismo resultado, incluso sin abrir un editor.

El estándar IDS de buildingSMART formaliza requisitos de información para IFC. Su utilidad en nuestro caso consiste en hacer explícito el acuerdo y permitir su intercambio entre herramientas compatibles. La decisión sobre qué necesita mantenimiento sigue siendo del proyecto. El XML llegará después; si lo abrimos antes, solo conseguiremos que la ambigüedad tenga sangría.

Entiende la diferencia entre seleccionar y exigir

Una especificación IDS distingue la aplicabilidad de los requisitos. La primera determina qué objetos entran; los segundos establecen qué deben satisfacer. En el ejemplo podríamos seleccionar los equipos mediante una entidad y una clasificación acordadas, y exigir después determinadas propiedades. No es lo mismo pedir fabricante a todo lo que se ha seleccionado que seleccionar únicamente los objetos que ya tienen fabricante. La segunda opción puede dejar fuera precisamente los casos que queríamos encontrar.

Esta separación merece revisarse con los ejemplos sobre la mesa. Si empleamos una propiedad para delimitar los equipos instalados, ¿qué ocurre cuando falta esa propiedad? Quizá el objeto quede fuera de esa selección aunque en realidad deba formar parte de la entrega. Por eso conviene controlar la cobertura y, cuando corresponda, establecer comprobaciones adicionales sobre los datos que permiten seleccionar. Ningún filtro conoce la intención del proyectista por telepatía; tampoco los que aparecen dentro de un estándar.

La presencia de una propiedad y la validez de su valor requieren atención distinta. El campo puede existir y estar vacío, contener un texto provisional o utilizar un tipo de dato inesperado. El requisito debe expresar las condiciones admitidas dentro de lo que soporta IDS y probar cómo las interpreta el validador elegido. Un patrón de código puede comprobar una forma; no demuestra por sí mismo que ese código esté dado de alta en el registro de mantenimiento.

No todos los campos necesitan un catálogo cerrado. Para un estado puede ser útil una lista acordada de valores; para un nombre comercial quizá se requiera texto informado. Convertir todo en una enumeración también tiene un coste: alguien tendrá que mantenerla cuando aparezca otro fabricante o producto. El rigor consiste en escoger restricciones que ayuden al uso del dato, no en introducir el máximo número de condiciones que permita la interfaz.

Prueba la especificación con el IFC que se va a entregar

El editor de IDS puede ayudar a preparar requisitos sin escribir las etiquetas a mano. Aun así, hay que comprobar la versión del estándar soportada, validar el propio archivo y guardar una representación que el equipo pueda revisar. El repositorio oficial de IDS incluye el esquema y documentación. Una herramienta que abre un archivo no garantiza automáticamente que otra lo interprete con las mismas capacidades; conviene probar el recorrido entre emisor y receptor.

La comprobación debe ejecutarse sobre el IFC exportado que se va a intercambiar. Un parámetro correcto en el archivo de autoría puede perderse o cambiar de ubicación durante la exportación. Si solo revisamos la aplicación de origen, estaremos examinando algo distinto de lo que recibe mantenimiento. Conserva la configuración de exportación cuando sea relevante y utiliza los mismos ejemplos para detectar si el mapeo conserva los datos acordados.

Un validador compatible, como IfcTester dentro de IfcOpenShell, puede aplicar una especificación IDS y producir informes. El proceso necesita algo más que pulsar ejecutar: comprobar los objetos seleccionados, revisar resultados conocidos y distinguir un fallo del dato de un problema de ejecución. Empezar con tres o cuatro equipos entendidos manualmente es más revelador que lanzar una primera revisión masiva y confiar en que el resumen verde lo explique todo.

Revisa siempre cuántos candidatos ha encontrado la comprobación. Si esperabas veinte equipos y no se selecciona ninguno, el informe necesita explicar esa ausencia. La cardinalidad de la especificación y el control de cobertura ayudan a distinguir un requisito satisfecho de una consulta que no ha mirado donde debía. «Cero errores» puede significar veinte equipos correctos o cero equipos examinados. Dar por buena la segunda salida porque sale en verde es delegar la revisión en la paleta de colores.

Interpreta el resultado sin convertirlo en un certificado universal

Un informe útil permite localizar el objeto, identificar la condición y entender qué dato se encontró. Para un equipo sin fabricante necesitamos saber cuál es, qué propiedad se esperaba y qué versión del archivo se revisó. Un porcentaje global orienta, pero no explica la corrección. Si el emisor tiene que buscar a mano qué objeto provocó el fallo, hemos trasladado parte del trabajo que pretendíamos ahorrar.

IDS se centra en requisitos de información que pueden expresarse mediante sus facetas y restricciones. No sustituye una revisión completa de interferencias, distancias o recorridos, ni decide por sí solo la conformidad normativa del edificio. Exigir un dato sobre una prestación y demostrar que esa prestación es adecuada para una situación son preguntas distintas. Para la segunda pueden hacer falta geometría, contexto y una interpretación técnica que exceda esa comprobación.

También conviene distinguir formato de veracidad. Un código con la estructura correcta puede no existir en el registro; un fabricante informado puede no corresponder al equipo instalado. El IDS puede ayudar a comprobar condiciones expresadas sobre la información del IFC, pero las comparaciones con sistemas externos o la inspección de la realidad necesitan su propio procedimiento. Una casilla verde tiene valor cuando sabemos qué afirma. Cuando afirma todo, suele estar explicando poco.

En ese conjunto, IFC transporta información del modelo, IDS declara requisitos y otros recursos, como bSDD cuando el flujo lo utilice, pueden aportar referencias semánticas compartidas. BCF puede servir para comunicar incidencias. No son sustitutos entre sí y no hace falta desplegarlos todos para empezar. Primero necesitamos una condición comprensible y una ruta para corregirla; después elegiremos los formatos que faciliten intercambiarla sin perder significado.

Mantén las reglas con el mismo cuidado que la entrega

El IDS debe tener versión, responsable y un momento claro de aplicación. Si cambia un nombre de propiedad o un valor permitido, pueden variar muchos resultados aunque el IFC sea exactamente el mismo. Conserva especificación e informe junto a la revisión del modelo, y explica los cambios a los equipos antes del hito. Estrenar una regla bloqueante el día de entregar es una forma especialmente creativa de confundir control de calidad con sorpresa.

Las excepciones necesitan alcance y aprobación. Si un equipo aún no dispone de modelo comercial por una razón aceptada, no conviene debilitar la regla general para que deje de señalarlo. Registra el caso y su tratamiento en el procedimiento correspondiente. Así puede seguir viéndose qué se ha comprobado, qué está pendiente y qué se ha aceptado temporalmente. Un cien por cien obtenido quitando las condiciones incómodas solo demuestra habilidad con el editor.

Al corregir, vuelve a exportar y revisar. Conserva casos pequeños que detecten cambios en el propio IDS o en las herramientas, y comprueba que los fallos desaparecen por la razón esperada. Puede que un requisito seleccione demasiado y necesite ajustarse; puede que revele un mapeo incorrecto. Esa revisión forma parte del aprendizaje. Lo importante es que el resultado mejore el acuerdo y la información, en lugar de convertirse en una discusión entre porcentajes.

Si quieres empezar, elige una familia de objetos y un requisito que el receptor necesite de verdad. Documenta incluidos, excluidos y valores esperados; prueba el IFC con esos casos y revisa el informe con quien debe corregirlo. Si aún no podéis explicar el requisito con ejemplos, la siguiente herramienta útil es una conversación. Por una vez, no requiere licencia.

Escoge un requisito que se preste a dos interpretaciones y escribe su alcance, dato y condición de aceptación. Ponlo delante de quien prepara y de quien recibe el IFC. Si esperabais cosas distintas, habéis descubierto el problema a tiempo; un informe automático al final de la entrega solo habría añadido solemnidad al desacuerdo. ¿Qué requisito os está dando esa falsa sensación de consenso?