Existe un problema con la tecnología en nuestra industria. Tenemos todos estos sistemas y dispositivos inteligentes que nos rodean todo el tiempo, tecnología que ha transformado nuestras experiencias cotidianas, pero la mayoría de los sistemas en nuestro entorno construido están encadenados, restringidos, diseñados para ser eslabones discretos en una cadena, en lugar de una red de plataformas cooperativas. Esta es una filosofía rota que ha resultado en un mercado estancado, lleno de dispositivos maravillosos que simplemente “no funcionan”. Consideremos los siguientes dos escenarios:

Son las 7 de la mañana de una fría mañana de invierno. Eres el primero en llegar a la oficina. Buscas a tientas tu tarjeta de acceso en la billetera, la pasas para entrar al edificio, muestras tu identificación al personal de seguridad y luego llamas al ascensor, que tarda un minuto o más en llegar. Al llegar a tu piso, tenuemente iluminado por luces de seguridad estándar, caminas a oscuras hasta encontrar el interruptor de la luz. “¡Qué frío hace!”, murmuras para ti mismo, mientras (de fondo) escuchas el ruido del sistema de calefacción encendiéndose para comenzar el día.

Parece bastante sencillo. Bien, ahora considera esto:

Son las 7 de la mañana de una fría mañana de invierno. Eres el primero en llegar a la oficina. Entras por la puerta principal, pasas junto a seguridad —atravesando el sistema de reconocimiento facial automático— y te diriges a la zona de ascensores. El ascensor, que ya te estaba esperando, te lleva rápidamente a tu piso, donde las luces de la oficina ya están encendidas y el sistema de climatización ha ajustado la temperatura a tu preferencia. No hay tropiezos ni complicaciones: el edificio se ha encargado automáticamente de las tareas rutinarias que a veces son necesarias. En su lugar, puedes ir directo al trabajo (o, primero, a la cafetera).

Todas las diferencias clave entre los dos escenarios giran en torno a la interacción del usuario y la necesidad de interactuar con un elemento específico del edificio, como el interruptor de la luz. En el enfoque más automatizado y fluido, varios sistemas de construcción diferentes e interconectados cooperaron para hacer tu vida y tus interacciones más fáciles, rápidas y fiables, llegando incluso a eliminar la necesidad de algunos de esos pasos. Piensa en los diferentes sistemas que intervienen en ese escenario: sistemas de seguridad físicos y digitales, control de ascensores, integración de climatización e iluminación —todos sistemas de construcción estándar— que normalmente operan de forma independiente, pero que, al combinarse, sirven para crear una experiencia de usuario más completa y fluida. ¿Cómo pasamos del presente a un futuro donde el segundo escenario sea algo común, y luego ir aún más lejos? ¿Cómo podría funcionar algo así? ¿Es posible siquiera una “infraestructura inteligente”?

Un ecosistema más inteligente

En TEECOMlabs, intentamos constantemente imaginar el futuro del entorno construido. Vemos un panorama en constante cambio dentro de una industria que permanece pasivamente inamovible, pero que tiene el potencial de impulsar tendencias, mejorar la forma en que utilizamos nuestro entorno, e innovar y provocar avances considerables en la forma en que interactuamos con nuestro entorno cada día. Imaginamos edificios que incorporen integraciones fluidas centradas en el usuario por defecto, no como funciones adicionales o “premium”. En esta visión, los edificios, los campus e incluso las organizaciones a gran escala con múltiples sedes tendrán pleno conocimiento y control de todos sus componentes, capaces de funcionar de forma autónoma mediante comportamientos intuitivos y de autocorrección.

Las plataformas de software integradas en la infraestructura física permitirán que los sitios se gestionen a sí mismos a gran escala, mucho más allá de la capacidad de lo que los humanos podrían hacer manualmente. En otras palabras, un controlador de software inteligente que orqueste la infraestructura física y digital de un edificio será un componente estándar y necesario de esa arquitectura. Este diseño de hardware y software autosostenible depende de si todos los sistemas del edificio están conectados entre sí. Pero, lo que es más importante, requiere el uso de plataformas diseñadas teniendo en cuenta la comunicación abierta y la accesibilidad, por ejemplo, la capacidad de comunicarse libremente con dicho sistema de software inteligente en primer lugar. Hemos etiquetado esta métrica como: “¿Sabe jugar bien en el patio de recreo?”

¿Tiene la plataforma de hardware la funcionalidad para enviar y recibir datos sobre sí misma? ¿Puede ser controlada y gestionada de forma remota? En esencia, ¿es capaz de funcionar como parte de un todo conectado más amplio? O bien, ¿el producto, plataforma o sistema se cierra en sí mismo, convirtiéndose en una especie de «caja negra» que carece de la capacidad de comunicarse de manera efectiva y abierta con otros sistemas? Lamentablemente, muchas de las plataformas y productos que se venden actualmente caen en esta última categoría de «caja negra». Esto se debe al enfoque de «jardín vallado» que adoptan muchos fabricantes y proveedores con sus líneas y familias de productos: funcionan bien con otros equipos de la misma marca, pero están diseñados específicamente para no funcionar bien con otros. Ya sea que esta elección de diseño sea intencionada para mantener a los usuarios dentro del jardín vallado, o que el efecto ocurra indirectamente por la decisión de simplemente no invertir recursos en crear las herramientas adecuadas, el resultado es el mismo: nada funciona con nada. Vemos el dilema: ¿por qué permitir deliberadamente que sus clientes utilicen productos de la competencia?

A veces es difícil imaginar un futuro interconectado porque, como demuestra el estado actual de los sistemas empresariales, la intercompatibilidad no siempre es rentable. Entonces, ¿por qué molestarse? Aquí está la razón: porque en el escenario del jardín vallado, nadie gana. Los usuarios obtienen una experiencia más pobre, los fabricantes no se ven obligados a actualizar o modernizar sus productos (por lo que no lo hacen, salvo para seguir siendo competitivos) y las empresas se ven obligadas a comprar estos ecosistemas cerrados sin considerar necesariamente todas las opciones posibles y, probablemente, mejores que tienen a su disposición. Los fabricantes no deberían sacrificar lo que debería ser una funcionalidad imperativa a costa de la experiencia del usuario. Para hacerlo aún más frustrante, en los últimos años hemos visto una renovación en la comunicación electrónica: una gran cantidad de nuevos estándares (REST, AMQP, SOAP, etc.) han hecho que sea muy fácil para múltiples dispositivos comunicarse entre sí. Y, sin embargo, a pesar de todos los protocolos y API*entre los que elegir, los fabricantes, en general, han optado por creer que la solución de software que ellos mismos crearon es claramente el mejor (y obviamente el único correcto) protocolo, o bien han optado simplemente por ignorar los conceptos tecnológicos por completo.

La cooperación es clave

Esta es la parte en la que hago un llamamiento a la acción: depende de nosotros en la industria AEC presionar a todos nuestros fabricantes y proveedores hacia plataformas más abiertas.Algunos de estos sistemas ya se están volviendo más escalables, integrando paquetes de tecnología inteligente y mecanismos de control más avanzados, y ciertos fabricantes ya han comenzado a utilizar software de código abierto e integrar API con especificaciones públicas; sería una lástima ver productos con tanto potencial olvidados en las estanterías, sin vender, simplemente porque están construidos sobre plataformas restringidas y propietarias o no funcionan bien con otros sistemas. También vale la pena señalar explícitamente que un fabricante que decide crear su propia API con sus propios protocolos y especificaciones e integrarla en sus plataformas NO es lo mismo que integrar API con especificaciones públicas. Este cambio de paradigma no ocurrirá de la noche a la mañana, pero por ahora, deberíamos empezar por hacer a los fabricantes las preguntas correctas: «¿Su plataforma está conectada y es segura? ¿Tiene su plataforma una API abierta? ¿"Juega bien en el patio de recreo"? (¿Funciona bien con los dispositivos de otros fabricantes?)». Si la respuesta no es sistemáticamente «Sí», tal vez debería buscar mejores opciones.

La evolución del «centro de control»

En I+D no esperamos a que el futuro se invente solo. Queríamos una experiencia de usuario fluida y sin fricciones, la automatización, el ecosistema de construcción autosostenible. Y lo queríamos hoy, no dentro de un año o cinco. Así que comenzamos con un experimento que nos permitió ver de primera mano los beneficios de un futuro conectado: una plataforma para conectar TODOS nuestros equipos, plataformas y sistemas, y hacer que funcionen e interactúen de forma cooperativa; un puente para conectar todo tipo de hardware en una red única, inteligente y capaz.

«Alexa, ¿serías tan amable de...?»

Todo empezó con un interruptor de luz. En las oficinas de TEECOM en Oakland, utilizamos la serie Legrand Wattstopper DLM (gestión de iluminación digital) de interruptores de luz, luminarias, reguladores, mandos y cables interconectados, todo unido a través de una red propietaria, cerrada y de bajo voltaje. Aunque el sistema funciona normalmente como cabría esperar (pulsas el interruptor, la luz se enciende), nuestro objetivo era ver si podíamos controlar el sistema de iluminación de forma conversacional desde Amazon Alexa. Es decir, «Alexa, enciende las luces porque son las 7 de la mañana, tengo frío y no veo nada».Tuvimos dificultades con la falta de una interfaz adecuada con nuestro sistema de iluminación Wattstopper. El módulo de control serie nunca fue diseñado para ser una API; no es más que una simple interfaz de comunicación. Así que instalamos luces Philips Hue, lo que nos otorgó funcionalidad adicional, una interfaz más centrada en la aplicación y capacidades que incluyen color dinámico y temperatura de color de luz variable. La API de Philips Hue y el módulo de control serie de Legrand Wattstopper (la interfaz) nunca fueron diseñados para trabajar juntos de forma cooperativa, así que creamos una aplicación de software para combinar los sistemas y conectarlos a una skill personalizada de Alexa. Llamamos al softwareLabLight.

LabLight: el primer gran unificador

LabLight se comunicaba con cada uno de los sistemas de iluminación, solicitaba una actualización de estado y mantenía activamente una base de datos actualizada sobre el estado de cada sistema. Con la introducción de nuestro "procesador de contexto", cualquier persona podía usar el laboratorio y utilizar simultáneamente los dos sistemas de iluminación diferentes sin tener que gestionar solapamientos ni conflictos (como quedarse a oscuras o sufrir un deslumbramiento porque todos los sistemas de iluminación se encendieron al máximo a la vez). El software LabLight se volvió cada vez más complejo de mantener a medida que añadíamos funciones e integrábamos más sensores, dispositivos y equipos en nuestro laboratorio. Pronto quedó claro que necesitábamos algo más adaptable y escalable para las aplicaciones de mayor alcance que teníamos en mente. Necesitábamos una actualización. Presentamos: The Hub plataforma.

The Hub: un sucesor lógico

The Hub consta de una plataforma de software de tres niveles.

1. El nivel más bajo (primero), los controladores, está especializado para cada API con la que interactuamos (Philips Hue, Brivo ACS, Wattstopper, Liftmaster, etc.).

2. El segundo nivel, los controladores de dominio, vincula todos los controladores dentro de un ámbito específico (AV, iluminación, seguridad, redes, etc.). El objetivo de este segundo nivel es simplificar el código necesario para todas las aplicaciones superiores, garantizando al mismo tiempo que todos los controladores sigan funcionando correctamente en la base.

Por ejemplo, tenemos un controlador AV que integra nuestro DSP de audio y los distintos televisores/pantallas del laboratorio, y también un controlador de seguridad independiente que gestiona el Brivo ACS, la puerta del garaje y nuestro sistema de seguridad. "LabLight" fue adaptado como controlador de iluminación y también se sitúa en este nivel.

3. El nivel superior (tercero) consiste en aplicaciones que, actualmente, incluyen nuestra interfaz web, un controlador de sala (monitoreo y gestión de nuestro espacio de laboratorio), pantallas gráficas, herramientas de automatización e informes, entre otras. Aplicaciones como estas incorporan funciones que pueden requerir la interacción con diversas plataformas en múltiples dominios. Desde la perspectiva de la programación, esta jerarquía en forma de árbol es mucho más limpia que construir una arquitectura de software "plana".

Una nueva dimensión, una nueva interfaz

La arquitectura por capas de The Hub añadió una nueva dimensión de capacidades al hardware de nuestro laboratorio. Mediante la creación y el uso de aplicaciones de alto nivel —aplicaciones capaces de utilizar la información de un sistema para controlar inteligentemente otro—, todas nuestras plataformas integradas y sistemas de construcción se convirtieron en componentes modulares de una máquina funcional completa, en lugar de ser piezas y engranajes independientes sin una organización central. En lugar de un caos de infraestructura apenas conectada, The Hub unió todo. Pudimos compartir datos y gestionar de forma inteligente múltiples plataformas entre dominios y fabricantes. Pudimos controlar todos estos sistemas, adquirir sus datos y métricas, y aprovechar las capacidades de cada uno para crear nuevos usos eficaces.

Un ejemplo temprano que utilizó este estilo de "integración cooperativa" fue una aplicación que creamos utilizando tanto las cerraduras Brivo ACS (seguridad) como el abridor de puertas de garaje Liftmaster: para entrar al laboratorio, uno tenía que pasar su tarjeta por la cerradura y la puerta se desbloqueaba sola. Ahora, si pasabas la tarjeta dos veces, la puerta eléctrica del garaje también se abría (Brivo → The Hub → Liftmaster). Otro ejemplo utiliza el software de iluminación automatizada de The Hub.

Como tenemos varios sistemas de iluminación superpuestos (por ejemplo, Wattstopper y Hue), existen un sinfín de combinaciones de escenas, ambientes, efectos o configuraciones que podemos implementar en el laboratorio. El Hub gestiona toda la complejidad operativa, facilitando el cambio entre diversos efectos. Además, ahora el Hub sabe ajustar automáticamente la temperatura de color de la luz durante las primeras horas de la mañana y las últimas de la tarde en función del amanecer y el atardecer, lo cual es mejor para nuestra salud.

Automatización: construyendo capas de intuición

Con el creciente número de sistemas electrónicos instalados en la infraestructura de un edificio, las tareas de gestión, el mantenimiento periódico y la supervisión de los sistemas se delegan cada vez más en sistemas informáticos automatizados, que requieren una fracción del tiempo y pueden manejar órdenes de magnitud más datos que las personas. Sin embargo, hacer que un sistema informático realice una tarea tediosa es solo un tipo de automatización.

Por ejemplo, cuando intentamos enseñar a un sistema a automatizar acciones que de por sí no están bien definidas, es cuando entra en juego la inteligencia. La intuición y, a veces, las conjeturas son partes integrales de la construcción de una plataforma más autosuficiente. Una cosa es que las luces se enciendan al entrar en una habitación y se apaguen poco después de salir, pero otra muy distinta es que se enciendan automáticamente antes incluso de que entres. En otras palabras, se podría pensar en el encendido de las luces en respuesta a tu movimiento como una especie de reflejo. Un comportamiento intuitivo sería que la habitación anticipara tu entrada y encendiera las luces antes de que llegues.

Interactividad inteligente

Uno de los beneficios más directos que observamos inicialmente con el Hub fue la capacidad de satisfacer nuestras intenciones. Esto quedó ilustrado por un cambio fundamental en la forma en que interactuamos con nuestro espacio: empezamos a alejarnos del uso de acciones explícitas (o interfaces específicas de acción-reacción, como un interruptor de luz) para pasar a solicitar simplemente nuestra intención subyacente.

Por ejemplo, mientras que antes, para preparar una sala para una presentación, habríamos realizado una serie de tareas operativas tediosas y secuenciales, ahora podemos simplemente decir "quiero empezar mi presentación" y hacer que todas esas acciones intermedias se realicen por nosotros. Este cambio, que permite abstraer toda la dificultad intrincada de interactuar con un espacio, supuso una mejora importante respecto al funcionamiento manual y al uso de controles explícitos. Aunque el Hub no sustituye intrínsecamente esos controles, aumenta las capacidades de nuestros sistemas mediante la automatización y la programación inteligente.

El futuro inteligente

El atractivo de los sistemas interconectados y cooperativos es muy amplio. Ya sea para la recopilación de datos, interfaces inteligentes más capaces o la gestión automatizada, existen innumerables casos de uso potenciales que pueden construirse sobre sistemas interconectados.

Sin embargo, como dije antes, la necesidad subyacente es la capacidad de estos sistemas para trabajar juntos. En nuestro caso con el Hub, tuvimos que reconstruir gran parte del software y los mecanismos de bajo nivel que, en nuestra opinión, deberían haber venido integrados en estos dispositivos por defecto. Eso está bien para I+D, pero difícilmente es escalable. La plataforma Hub que construimos puede servir como puente provisional, pero no es una solución a largo plazo para toda la industria. Demuestra que incluso ciertos dispositivos cerrados pueden operar de forma cooperativa a través de un intermediario —aunque con algo de trabajo adicional y un "middleware" que sirva de puente—, pero confiar en esta arquitectura de software de "middleware" (que es más bien un paso intermedio) no es una buena estrategia para un despliegue a largo plazo.

Creando conexiones significativas

Aunque "dispositivos más inteligentes" es un término amplio, generalmente implica una mayor conectividad, una mayor captura/conocimiento de datos, o ambas cosas. Deberíamos estar viendo muchísimos más hardware y plataformas que integren estas tecnologías "inteligentes" en el mercado, pero no es así. La tendencia de servicios y plataformas interconectados que ha impregnado otros mercados tecnológicos aún no ha penetrado en el sector AEC de forma significativa. En un sector donde predomina la estrategia de mercado de "jardín vallado", frases como "conectividad abierta" y "arquitectura cooperativa" rara vez están garantizadas.

Por lo tanto, a medida que gravitamos hacia sistemas más entrelazados, los dispositivos que sean más abiertos y conectados se situarán en lo más alto de la jerarquía, dejando de lado otras consideraciones funcionales. ¿Por qué optar por vincularse a un fabricante específico si existe una clase equivalente de dispositivos que funcionan con el resto de tu infraestructura? Las empresas que no den prioridad a las plataformas abiertas y conectadas pronto se verán obsoletas, anticuadas y, poco después, rezagadas. Para estar preparados para un futuro más conectado, tenemos que empezar con un entorno de trabajo más cooperativo.

*API: Interfaz de Programación de Aplicaciones: un conjunto de especificaciones utilizadas dentro de los programas de software para comunicarse con otros componentes de software o hardware.