El cambio del trabajo en la oficina al trabajo híbrido y totalmente remoto está causando presión sobre los ingresos y la valoración de los propietarios de edificios comerciales. Como resultado, los administradores de edificios están explorando formas de optimizar sus gastos al reducir los costos de mantenimiento y al mismo tiempo brindar una experiencia de inquilino, dice Nick White, arquitecto de soluciones de socios senior, Jameson Bass, arquitecto de soluciones de socios, Julie Zhao, gerente de productos senior de AWS y Stephen Plechy, arquitecto jefe de tecnología en Competente.

Los administradores de edificios son responsables del mantenimiento y de proporcionar un espacio cómodo para los inquilinos mientras equilibran el costo de ambos. A menudo mantienen múltiples propiedades. Es posible que el equipo de mantenimiento no esté físicamente presente en todos los edificios o que no esté familiarizado con el edificio que necesita servicio. Por lo tanto, tener las herramientas adecuadas para solucionar problemas y encontrar la causa principal puede mejorar la eficiencia del mantenimiento.

El mantenimiento del edificio suele ser reactivo y está impulsado por problemas o alarmas informados por los inquilinos. los Mantenimiento HVAC y ahorro de energía El informe establece que el mantenimiento no reactivo en los sistemas HVAC puede reducir el costo operativo entre un 10 % y un 20 %. Programar un servicio regular es simple, pero detectar problemas con sensores, economizadores o configuraciones de anulación olvidadas hace mucho tiempo requiere una solución basada en datos. Los administradores de edificios proactivos identificarán los problemas antes de que surjan, lo que implica tener un método efectivo para buscar en los edificios e identificar equipos en condiciones similares o modos de falla.

En este blog, ampliaremos el caso de uso de nuestro publicación anterior on Solución 1Facility de Cognizant y demostrar cómo Gráfico de conocimiento de TwinMaker, una nueva característica en AWS IoT TwinMaker, hace que sea más fácil encontrar y solucionar problemas. En la publicación anterior, Cognizant describe cómo AWS IoT TwinMaker les permite visualizar el edificio para los clientes y agrega valor al fusionar varias fuentes de datos en una ubicación. Asumimos que el administrador del edificio conocía el edificio, las habitaciones y el equipo, así como la ubicación y los sensores disponibles en cada habitación. En este blog, analizaremos el caso de uso de la resolución de problemas de HVAC en un edificio. Describiremos cómo los clientes usan TwinMaker Knowledge Graph para contextualizar las alarmas y demostraremos cómo permite a los administradores de edificios generar información.

Recorrido del caso de uso: solución de problemas de condiciones incómodas del inquilino

En este ejemplo, el administrador del edificio se centrará solo en uno de los edificios que administra. Un inquilino informó sobre un ambiente incómodo en la habitación 1.1E y señaló específicamente que la habitación estaba calurosa y húmeda.

A partir del gemelo digital de este edificio, el administrador del edificio se entera de que es un edificio de varios pisos con 2 zonas HVAC por piso, alineadas al este y al oeste. Luego, el administrador del edificio examina un tablero que muestra todas las temperaturas de las habitaciones del edificio y confirma que la temperatura en la habitación 1.1E es más alta que el punto de ajuste. Al analizar los datos del sensor de humedad de esta habitación, el administrador del edificio corrobora el informe de que la habitación también está húmeda.

El administrador del edificio no está familiarizado con este edificio y no sabe por qué solo una habitación tiene temperatura y humedad altas. Para investigar más a fondo, el administrador del edificio utiliza el tablero de gemelos digitales para ver las habitaciones en la zona HVAC Este, donde se encuentra la habitación 1.1E. Al inspeccionar los datos del sensor en esas habitaciones en la zona HVAC Este, descubren que todas las demás habitaciones en la zona HVAC Este están más frías que el punto de ajuste de temperatura y más secas de lo esperado. Al examinar el modelo 3D del edificio, el administrador del edificio descubre que la habitación 1.1E es diferente de las demás porque no tiene ventana. Visitan las habitaciones cercanas en la zona HVAC Este y validan la hipótesis. También descubren que los ocupantes de otras habitaciones abrieron sus ventanas para que las habitaciones fueran cómodas. El aire exterior redujo el nivel de temperatura y humedad de las habitaciones por debajo del punto establecido, pero no lo suficiente como para activar una alarma en el sistema de monitoreo del edificio.

Ahora, está claro que hay un problema en la zona este de HVAC con las condiciones anormales en la sala 1.1E. Para encontrar la causa raíz del problema, usó el panel gemelo digital para inspeccionar los valores de los sensores de la zona HVAC del este. El administrador del edificio selecciona una vista para mostrar todos los datos del sensor para la zona este de HVAC. Inspecciona las mediciones de los sensores (datos de series temporales), como la temperatura del aire de retorno del piso 1, la temperatura del aire de retorno del piso 2, la temperatura del aire de suministro, la temperatura y la humedad del aire exterior, así como otros valores controlados, como las velocidades deseadas del ventilador, posición del economizador y la posición de la compuerta en cada piso. Con acceso a todos estos puntos de datos, el administrador del edificio puede comparar tendencias e identificar comportamientos anormales. Luego descubre que la temperatura del aire de suministro no cambia cuando se cambia el comando del economizador. Esto indica que el economizador no funciona correctamente y que el aire exterior no se mezcla con el aire de retorno antes de reciclarse en el edificio.

A continuación, el administrador del edificio analiza los datos históricos para identificar cuándo comenzó a funcionar mal el economizador. Ahora el administrador del edificio estará familiarizado con los detalles del problema del economizador antes de enviar una orden de reparación a la empresa de HVAC que mantiene el sistema. Estos conocimientos reducen el tiempo de diagnóstico del problema y aceleran el tiempo de resolución. Como seguimiento, verifica proactivamente el estado del economizador para las otras unidades HVAC en este edificio y otros edificios que administra. Estas acciones no solo mitigan un posible problema de comodidad del inquilino, sino que también ayudan a reducir el costo operativo del sistema HVAC si se identifican y reparan proactivamente otros problemas del economizador. Este es el valor del mantenimiento proactivo.

Implementación técnica usando TwinMaker Knowledge Graph

TwinMaker Knowledge Graph es una característica nueva de AWS IoT TwinMaker. Los clientes existentes de AWS IoT TwinMaker habilitan esta característica seleccionando el plan de precios estándar en la página de configuración de la consola de AWS. Todos los clientes nuevos tendrán un plan de precios estándar de forma predeterminada y tendrán habilitado TwinMaker Knowledge Graph. Con la función, los usuarios ejecutan consultas utilizando el código abierto PartiQL lenguaje de consulta con sintaxis similar a SQL. Los clientes usan la propiedad de relación para describir cómo las entidades se relacionan entre sí física o lógicamente. A continuación, pueden consultar la entidades en su espacio de trabajo y del relación entre estas entidades. Por ejemplo, los clientes pueden consultar todas las entidades con un nombre que contenga "temperatura" o encontrar todas las entidades conectadas a una entidad de interés. Estas capacidades permiten a los clientes crear tableros para ver las tendencias de rendimiento para el mismo tipo de equipo en un sitio, o encontrar la causa raíz de un problema recorriendo todas las entidades relacionadas con el problema.

En esta sección, veremos los pasos de cómo se implementa el caso de uso del análisis de causa raíz mediante TwinMaker Knowledge Graph.

El desarrollador de la aplicación crea entidades para representar cosas físicas, como una habitación o una unidad de tratamiento de aire, y luego agrega un componente que se instancia desde un tipo de componente. Un componente incluye los atributos o propiedades que describen la cosa física. Por ejemplo, una propiedad puede ser un descriptor, como el número de piso, o un flujo de datos de series temporales, como una medición de temperatura almacenada en un almacén de datos externo. Una propiedad de relación captura cómo esta entidad se relaciona con otra entidad en el contexto del componente. Un componente puede contener varias relaciones o ninguna, y cada relación puede conectarse a una o varias entidades. Para definir una propiedad de relación, se debe especificar un tipo de relación junto con los ID de entidad a los que hace referencia esa relación.

Para crear entidades, componentes y propiedades, puede utilizar el Consola de AWS IoT TwinMaker o llama al CrearEntidad API. También puede usar un script de incorporación o una plantilla de formación de nubes que describa el diseño del edificio y las relaciones entre los objetos físicos. La siguiente figura ilustra una entidad que representa una habitación con un componente definido por el usuario asignado a ella; el objeto JSON que describe las relaciones de los atributos se superpone a la figura. En este componente definido por el usuario, tres propiedades definen relaciones, "feed", "isLocationOf" y "isMonitoredBy", y otras dos propiedades, "roomNumber" y "roomFunction", definen los atributos.

Supondremos que el desarrollador de la aplicación ha creado los componentes, las entidades y las relaciones que representan el edificio. La siguiente figura ilustra la representación del edificio del editor de consultas TwinMaker Knowledge Graph y cómo las zonas HVAC sirven al edificio.

La siguiente imagen muestra una vista más detallada del Gráfico de conocimiento de TwinMaker para la zona HVAC Este.

También supondremos que el desarrollador de la aplicación ha cargado y configurado un modelo 3D relevante del edificio a través de compositor de escenay que el tablero está disponible para el usuario final usando Grafana gestionado por Amazon. Para obtener instrucciones paso a paso sobre cómo importar un modelo 3D y visualizarlo en Amazon Managed Grafana, vea este hipervínculo blog.

Con el gemelo digital del edificio creado en AWS IoT TwinMaker, profundicemos en cómo TwinMaker Knowledge Graph ayuda al administrador del edificio a solucionar el problema de las condiciones ambientales. Para la primera parte del caso de uso, el administrador del edificio quiere ver todos los datos de sensores relevantes para las habitaciones en la zona HVAC Este. El usuario llama al ObtenerHistorialDePropiedad API para obtener datos de sensores con ID de entidad y nombre de componente como entradas. El primer paso es identificar todas las entidades relevantes en las que está interesado el administrador del edificio.

Antes de TwinMaker Knowledge Graph, el usuario tenía que aplicar la lógica empresarial a cada entidad desde el Entidades de lista API y determine si la entidad es un sensor en una habitación en la zona HVAC Este. El usuario tenía que procesar varias páginas de resultados, analizar los datos de la relación y atravesar la relación con una serie de llamadas API recursivas. Con TwinMaker Knowledge Graph, el usuario puede construir una consulta como se muestra a continuación. La consulta devuelve los ID de entidad de todos los sensores relacionados con las habitaciones del circuito HVAC Este. La consulta a continuación se puede ejecutar a través de API de ejecución de consultas o de  editor de consultas en la consola de AWS.

SELECT e3.entityId
FROM EntityGraph
MATCH (e1)-[]->{1,5}(e2)-[:isMonitoredBy]->(e3)
WHERE e1.entityName = 'AHU_East' AND e2.entityName LIKE 'Room%'
AND e3.entityName LIKE '%_Sensor'

En la consulta anterior, el lenguaje PartiQL permite al usuario especificar una consulta de salto variable y una consulta de salto múltiple. Específicamente, MATCH (e1)-[]->{1,5}(e2) es una consulta de salto variable que identificará todas las entidades entre 1 y 5 saltos de distancia de la Unidad de Manejo de Aire del Este que comienzan con la cadena "Habitación". La consulta multisalto, (e2)-[:isMonitoredBy]->(e3) nos permite especificar que estamos específicamente interesados ​​en entidades que terminan con el sensor de cuerda y tienen una relación directa (un solo salto) con las habitaciones. Tenga en cuenta que :isMonitoredBy restringe aún más los resultados al permitir que solo se devuelvan entidades con esa relación específica. Este caso de uso está devolviendo todos los sensores conectados a una habitación en el circuito HVAC Este en lugar de todos los sensores en el circuito HVAC Este.

Luego, la lógica de la aplicación itera a través de los ID de la lista de entidades (es decir, sensores de habitación) y llama a la API GetPropertyValue para recuperar el último valor del sensor. Estos resultados se presentan de vuelta al usuario como datos de un punto único en el tiempo en el tablero, como se muestra en la imagen de arriba. Ahora, el administrador del edificio se da cuenta de que la humedad y la temperatura en todas las habitaciones se desvían ligeramente del punto de referencia.

Este trabajo pesado no diferenciado de identificación de sensores de habitación de la zona HVAC este es manejado por TwinMaker Knowledge Graph en lugar de una lógica comercial compleja. Reduce la complejidad del desarrollo de aplicaciones y permite que el desarrollador de aplicaciones se concentre en mejorar las características. Por ejemplo, al comparar los datos de series de tiempo para la temperatura del aire de suministro y la posición del economizador, el administrador del edificio pudo identificar el economizador averiado como la causa raíz.

En este caso de uso, el administrador del edificio decide explorar de forma proactiva otros edificios que administra para determinar si más unidades de tratamiento de aire HVAC tienen un economizador defectuoso. Seguirá los mismos pasos utilizando el gemelo digital para otros edificios. Se utiliza una consulta similar para recuperar los ID de entidad y, a continuación, el ObtenerHistorialValorPropiedad La API se utiliza para recuperar un rango de datos. Luego, crea y revisa los gráficos del aire de suministro y la posición del economizador.

Conclusión

En este blog, describimos un caso de uso de TwinMaker Knowledge Graph para ayudar a un administrador de edificios a solucionar un problema de comodidad de los inquilinos. El administrador del edificio pudo ver las fuentes de datos dispares presentes en el edificio y profundizar en las habitaciones y sensores relevantes en función de las relaciones físicas capturadas en TwinMaker Knowledge Graph. Esto permite al administrador del edificio identificar un problema dentro de una zona del sistema HVAC. Luego, utilizan la escena 3D del tablero del gemelo digital del edificio para formular una hipótesis sobre la causa raíz. Al profundizar en las relaciones físicas modeladas en AWS IoT TwinMaker, el administrador del edificio identifica todos los sensores en la zona HVAC específica. Al comparar los datos de la serie temporal de estos sensores, pueden reconocer que el economizador de la unidad de tratamiento de aire del techo no funciona correctamente. Como resultado, esto le ahorra tiempo al administrador del edificio y le permite brindar una mejor experiencia al cliente en la resolución de problemas. Con TwinMaker Knowledge Graph, el administrador del edificio puede encontrar la raíz del problema rápidamente y también buscar proactivamente problemas similares en otros edificios. Esta experiencia de solución de problemas para el administrador del edificio se habilitó a través de las diversas características de AWS IoT TwinMaker, incluido TwinMaker Knowledge Graph, la consulta de datos unificada y la visualización en 3D.

Para obtener más información sobre la solución Cognizant 1Facility y cómo TwinMaker Knowledge Graph ayuda a resolver los problemas de los clientes, visite su a medida en el portal de soluciones de AWS. Para obtener más información sobre TwinMaker Knowledge Graph, consulte este documentación sobre el uso de PartiQL en AWS IoT TwinMaker y comienza a construir tu propio espacio de trabajo usando el Consola de AWS IoT TwinMaker.

Los autores son Nick White, arquitecto de soluciones de socios sénior, Jameson Bass, arquitecto de soluciones de socios, Julie Zhao, gerente de productos sénior de AWS y Stephen Plechy, arquitecto jefe de tecnología de Cognizant.

Comenta este artículo a continuación oa través de Gorjeo: @IoTNow_OR @jcIoTnow

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.Haga clic aquí
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://www.iot-now.com/2022/11/22/125602-reduce-building-maintenance-costs-with-aws-iot-twinmaker-knowledge-graph/