Gemelos digitales de edificios: del modelo 3D al mantenimiento conectado

Un responsable de mantenimiento recibe una alerta de temperatura. Tiene el nombre de un equipo, una lectura y una hora. Para decidir qué hacer todavía debe localizar la máquina, averiguar a qué espacios da servicio y comprobar si alguien está trabajando en ella.

Ahí aparece una oportunidad interesante para el diseño 3D y el desarrollo de aplicaciones: reunir el dato, su contexto físico y la siguiente acción en el mismo lugar. Esa es una utilidad concreta de un gemelo digital operativo de un edificio.

Qué convierte una maqueta en un gemelo digital

Una maqueta interactiva permite explorar plantas, materiales y recorridos. Puede ser muy detallada y seguir describiendo únicamente el diseño previsto. Añadir marcadores luminosos o una animación de sensores no demuestra que esté conectada al edificio.

Para el caso operativo que planteamos, hace falta un vínculo mantenido con elementos reales: qué equipo representa cada objeto, de dónde procede su estado y cuándo se actualizó. La actualización puede ser periódica; su frecuencia debe responder a la tarea, sin presentar como instantáneo lo que no lo es.

El 3D es una posible interfaz. Debajo hace falta un modelo de información. Azure Digital Twins describe entidades conectadas mediante relaciones: por ejemplo, una planta contiene habitaciones. Esa estructura permite expresar también qué equipo atiende una zona. La geometría ayuda a entender esas relaciones, pero no las sustituye.

Empezar por la identidad de los activos

El primer trabajo consiste en acordar qué significa «el mismo equipo» entre sistemas. Una bomba puede tener un nombre en el modelo, otro en el programa de mantenimiento y un código diferente en la plataforma de sensores.

En IFC, buildingSMART define el atributo GlobalId en IfcRoot para identificar de forma globalmente única las entidades que lo heredan. Ese identificador puede formar parte de la correspondencia, pero no conecta automáticamente el modelo con todos los sistemas externos.

Conviene mantener un registro que relacione el objeto visual, el activo físico y sus fuentes de datos. También hay que decidir qué sucede cuando se sustituye una máquina: el espacio permanece, pero el nuevo equipo necesita su propia identidad e historial. Reutilizar sin cuidado el registro anterior mezclaría averías de dos activos distintos.

Diseñar la frescura del dato como parte de la interfaz

Una temperatura sin contexto temporal puede inducir a error. Proponemos mostrar junto a cada lectura su unidad, origen, momento de medición y estado de conexión. La hora de recepción también resulta útil cuando existen retrasos en la comunicación.

Cada señal necesita una política de caducidad acordada con quienes operan el edificio. Al superarla, la aplicación debería indicar «dato desactualizado» y conservar visible la última lectura con su fecha. La ausencia de datos no equivale a un funcionamiento normal.

Las inspecciones manuales merecen el mismo cuidado. Una observación registrada por un técnico puede aportar información que ningún sensor ofrece, siempre que se distinga de una medición automática. También deben identificarse claramente las estimaciones y las simulaciones.

Un ejemplo hipotético: mantenimiento en un hotel

Imaginemos un hotel donde una unidad de climatización atiende varias habitaciones. Este ejemplo es una propuesta de funcionamiento, no un proyecto ejecutado ni un resultado medido.

La aplicación recibe una señal fuera del rango acordado para ese equipo. Al abrir la incidencia, el técnico ve la planta, la ubicación de la unidad, los espacios relacionados y el acceso a la sala técnica. Puede consultar las últimas lecturas, el manual y las intervenciones pendientes.

Antes de crear otra tarea, comprueba si existe una orden de trabajo abierta. Después contrasta la señal con otras observaciones y decide si procede una inspección. El modelo facilita orientarse; el diagnóstico sigue necesitando criterio profesional y, cuando corresponda, comprobaciones físicas.

Al terminar, el técnico registra lo observado y la actuación realizada. La incidencia pasa a revisión o cierre según el procedimiento del hotel. Que una lectura vuelva al rango esperado no debería borrar por sí sola el trabajo pendiente de verificar.

Alertas que explican qué ha cambiado

Una alerta útil necesita responder qué activo está implicado, qué cambió, cuándo ocurrió y quién debe revisarlo. También debería mostrar si el aviso depende de información antigua o de una relación entre equipos todavía sin verificar.

La documentación de eventos de Azure Digital Twins distingue cambios de propiedades, cambios de relaciones y mensajes de telemetría. Son mecanismos para comunicar sucesos; convertirlos en incidencias comprensibles requiere lógica de aplicación y reglas acordadas con el equipo de operaciones.

Esas reglas deben contemplar repeticiones y ventanas de mantenimiento. Diez mensajes sobre el mismo problema pueden pertenecer a una sola incidencia. Además, visualizar un equipo y ejecutar una orden sobre él requieren permisos distintos: una interacción en la maqueta no debería convertirse accidentalmente en una orden de control.

Un piloto que permita aprender

Un comienzo razonable es una zona limitada, un tipo de equipo y una decisión concreta. Antes de ampliar el alcance, se puede comprobar:

• Si los técnicos encuentran el activo correcto y reconocen su ubicación.
• Si entienden qué datos están vigentes y cuáles necesitan revisión.
• Si las incidencias conservan responsable, historial y estado.
• Si el proceso sigue siendo utilizable cuando falla una fuente de información.

El piloto también permite medir el esfuerzo de mantener correspondencias, actualizar geometría y revisar permisos. Sin ese trabajo continuo, una representación convincente puede perder fiabilidad. Los posibles beneficios deben evaluarse con datos del propio uso, sin asumir ahorros por incorporar 3D.

En Viseni, la visualización interactiva y el desarrollo digital ofrecen un punto de encuentro para explorar estas interfaces. Cuéntanos qué decisión necesita tomar tu equipo y qué información tiene disponible: será una base más útil para plantear un prototipo que intentar representar todo el edificio desde el primer día.