Revista
Boliviana de Ingeniería
Volumen
3 | No. 1 | Enero – junio 2021
Página
75 – 90
https://doi.org/10.33996/rebi.v3i1.6
ISSN:
2710 - 0901 | ISSN-L: 2710 - 0901
Consideraciones para el dimensionamiento de
soluciones de sistemas de gestión de edificios
Considerations for sizing of the solutions
for the building management system
Sergio
Andrés Rossells Lovera
sergiorossells@gmail.com
Código
ORCID: 0000-0003-1665-4183
Universidad
Católica Boliviana
La
Paz - Bolivia
Articulo
aceptado en septiembre 2020
Arbitrado
en octubre 2020
Publicado en enero 2021
Resumen
Si
bien los Sistemas de Gestión de Edificios (BMS) generan ventajas competitivas,
su diseño e implementación son complejos. Esta investigación provee las
consideraciones mínimas necesarias para dimensionar una solución BMS. El
desarrollo del proceso tiene un alcance descriptivo. La investigación fue
validada mediante consulta a expertos e involucra la utilización de
herramientas oficiales de Lenovo, Johnson Controls y propias. Como resultado de
la investigación se propone un proceso para el dimensionamiento de soluciones
que contempla los componentes de hardware, software y servicios mínimos para
generar una propuesta de diseño. Se concluye que el proceso propuesto puede
asistir y reducir tiempos en las tareas de diseño de soluciones integrales para
BMS.
Palabras
clave: Edificio
inteligente; Sistema de administración de edificios; Solución BMS; soluciones
para edificios inteligentes; arquitectura BMS
Abstract
Although Building Management
Systems (BMS) generate competitive advantages, their design and implementation
are complex. This research provides the minimum considerations necessary to
size a BMS solution. The development of the process has a descriptive scope.
The research was validated by consulting experts and involves the use of official
tools from Lenovo, Johnson Controls and their own. As a result of the research,
a process for the dimensioning of solutions is proposed that considers the
hardware components, software and minimum services to generate a design
proposal. It is concluded that the proposed process can assist and reduce time
in the design tasks of integral solutions for BMS..
Palabras
clave: Smart
building; building management system; BMS solution; Smart building solutions;
BMS architecture
INTRODUCCIÓN
Tal como expone Gökçe (2012), los Sistemas de
Gestión de Edificios (Building
Management System, a partir de ahora “BMS” por sus siglas en inglés) son sistemas informáticos
que monitorean y controlan los subsistemas técnicos y de servicios de uno o más
edificios. Individualmente proveen información en línea, histórica y tendencias
sobre los subsistemas. Según Van Hoof (2018), los principales motivos para la
inversión en BMS son la reducción de costos en la operación de instalaciones.
El consumo de energía de un edificio puede ser reducido
con un BMS como explica Nguyen (2012), la correlación de información de consumo
energético en edificios públicos o comerciales puede tener un gran ahorro.
Según Gökçe (2012), el 40% del consumo de energía a nivel mundial corresponde
al uso en edificios, tras la investigación de Osama (2018) se reconoce que en
los Estados Unidos los edificios consumen 41% de energía del país. De manera
similar en 2014, en la Unión Europea se reconoció que el consumo de edificios
fue el 37% de la energía total, Osama (2018). En la Unión Europea según la
Fundación Giner de los Ríos (2016) ya se consideran a los sistemas BMS como una
herramienta para optimizar los recursos energéticos de los edificios.
Esta investigación tiene por objetivo proponer un proceso
que incluya las consideraciones mínimas necesarias para dimensionar
adecuadamente una solución BMS, contempla el dimensionamiento de componentes de hardware, software, servicios e
interacción de subsistemas.
La implementación de soluciones integrales de BMS requiere un equipo
multidisciplinario capacitado en infraestructura de tecnología, manejo de
datos, ciberseguridad, BMS y dispositivos de control (Vasques, 2011; Microsoff,
2019).
En la bibliografía revisada se encuentran documentos
aislados o de propósito específico. Sin embargo, se ha detectado la necesidad
de documentar sobre como dimensionar los componentes que comprenden una
solución de BMS y las consideraciones específicas para el dimensionamiento del
sistema integral. Este estudio es de gran utilidad para los profesionales que
tienen la responsabilidad de dimensionar las soluciones de esta naturaleza. El
proceso de dimensionamiento correcto evitará costos adicionales en la
implementación, aporta una base de información para la ejecución del proyecto y
explica los alcances del sistema.
El documento también se justifica por el aporte práctico
y por los beneficios económicos que puede representar para empresas e
industrias a nivel internacional, es una oportunidad de ahorro en los costos
operativos de un edificio o complejo de edificios. Asimismo, debe considerarse
la posibilidad de la extracción de la información del BMS hacia un sistema de
inteligencia de negocios. Esto agregará más puntos de vista al sistema de
inteligencia incrementando así el valor de la información del sistema de apoyo
para la toma de decisiones.
Con estos antecedentes, la investigación se constituye en
una contribución teórica y práctica para todo profesional que requiera
implementar soluciones BMS, el desafío es la recopilación, sistematización y
adecuación de la teoría vigente sobre el objeto de estudio. El rigor científico
con que se investigó y redactó los hallazgos dan valor teórico a estas páginas.
A continuación, se presenta el marco de referencia del estudio. Como explica
Astesana y Medina (2016), las soluciones BMS requieren hacer una introducción
de los sistemas involucrados, para luego concentrar todos en uno principal que
realiza el monitoreo y gestión de todos los sistemas técnicos del edificio.
Así, se optimiza la funcionalidad de cada sector del predio o edificio y se
logra mayor aprovechamiento de los recursos y servicios. Perry (2017), propone
determinar el uso y utilidad que los subsectores empresariales dan y reciben al
adoptar tecnologías inteligentes. Asimismo, plantea establecer si esta utilidad
es relevante como para influir verdaderamente en el sector de la construcción
comercial.
Por su parte, Osama (2018), contribuye definiendo todos
los factores que intervienen en el proceso de diseño de un edificio inteligente
y modelo conceptual que ayuda a reducir el dióxido de carbono emisiones. Otro
aporte importante en este ámbito es el que presenta Van Hoof (2018), cuando
examina el estado del contexto de los espacios inteligentes y analizar lo que
piensan los tomadores de decisiones al considerar y adoptar la tecnología de
espacios inteligentes.
Applied Risk (2019), aporta con un enfoque crítico,
cuestiona la utilidad y plantea la necesidad de determinar el nivel de
vulnerables de los BMS. Asimismo, establece el papel
de los proveedores de BMS en relación con los principios de seguridad por
diseño. El estudio de Applied Risk finaliza resaltando la importancia de
definir las responsabilidades de los usuarios finales de las soluciones BMS.
METODOLOGÍA
Se trata de un estudio de alcance descriptivo
y corte transversal, que presenta un proceso para el dimensionamiento de
soluciones BMS. El proceso se desarrolla en cuatro etapas: 1) consideraciones
generales, 2) relevamiento de variables, 3) diseño de arquitectura y 4)
consenso.
La etapa 1 demandó
tratamiento cualitativo de las variables monitoreo y control, programación de
equipos, registro histórico, análisis de datos e infraestructura tecnológica.
Por otra parte, se trabajó desde una perspectiva cuantitativa a lo largo del
desarrollo de las etapas 2, 3 y 4, las herramientas empleados son provistas por
los fabricantes de hardware y software (Lenovo Data Center Solution
Configurator, Johnson Controls), herramientas independientes (Iris), tablas de
cálculo (Excel), herramientas de dibujo asistido (AutoCAD®, Visio®) y
herramientas propias para este propósito.
Para comprobar la pertinencia del proceso
propuesto se aplicó la técnica de validación por juicio de expertos, el
procedimiento consistió en consultar el dictamen de especialistas de marcas de
cada componente del sistema y de empresas fabricantes de los componentes.
Gracias a la orientación brindada por DATEC, empresa líder en el rubro de
soluciones tecnológicas de Bolivia, se seleccionaron cuatro profesionales con
especialidades en servidores y almacenamiento, redes de datos, BMS y arquitectura
de soluciones de tecnología. El relevamiento de variables y diseño de
arquitecturas consideró como referencia las recomendaciones de los fabricantes
para el uso adecuado del hardware y software. Los especialistas a su vez
acceden a las herramientas de los fabricantes y cuentan con el apoyo directo
del fabricante para la elaboración del diseño de cada componente.
RESULTADOS
En este apartado se presenta el proceso
propuesto para el correcto dimensionamiento de soluciones BMS y se ejemplifica
la aplicación de estos preceptos en un BMS para un hospital. La Figura 1
muestra en resumen las cuatro etapas y la información relevante que se procura
en cada etapa. Este proceso puede iterar para realizar ajustes de presupuesto y
cambios en el requerimiento original.
Figura 1. Etapas del proceso
de dimensionamiento.
Etapa 1. Consideraciones
generales
Dado que la implementación de una solución integral de
BMS requiere habilidades multidisciplinarias en infraestructura de servidores,
infraestructura de redes, bases de datos, virtualización, ciberseguridad, el
propio BMS y los dispositivos de control que este vaya a gestionar. Se debe
contar con los recursos capacitados en cada área para asesorar el
dimensionamiento de cada componente que interactúe con la solución. Antes de
empezar el proceso de dimensionamiento, el equipo a cargo deberá tomar en
cuenta consideraciones generales relacionadas con los roles de control y
monitoreo, programación de equipos de control, registro histórico, análisis de
datos e infraestructura tecnológica. Entender a cabalidad los requerimientos
ahorrará tiempo y esfuerzo más adelante, ya que se evitará readecuaciones
innecesarias durante la fase de implementación. Se describen a detalle las
consideraciones que deberán ser analizadas.
Monitoreo y control
Se deben considerar los roles una o más
estaciones de monitoreo y control que permitan la administración de alarmas y
eventos del edificio en tiempo real. El tamaño, complejidad y operativa del
edificio, podrán demandar
diversos roles de operadores y administradores para la gestión del edificio.
También, se debe considerar la posibilidad de que la operativa requiere el
enmascaramiento automático o manual de información sensible en el desarrollo de
las vistas para mantener la confidencialidad de la información. La segmentación
de permisos y vistas de estos roles pueden impactar en la cantidad de
estaciones de monitoreo, creación de vistas de los sistemas y el licenciamiento
de estos dependiendo del tipo de acceso que se requiera (cliente pesado,
cliente web, cliente móvil).
El monitoreo de subsistemas no solamente comprende la
lectura y almacén de datos si no también proporciona información para la
ejecución y programación de tareas de mantenimiento preventivo a los sistemas.
La entrada de datos de subsistemas solamente monitoreados también puede aportar
a la programación de comportamientos de sistemas controlados del edificio. Por
ejemplo, tomando variables de entrada de CCTV para accionar dispositivos de iluminación.
Programación de equipos.
La información obtenida de los sistemas del edificio
proporcionará la entrada para la configuración del BMS. De acuerdo con el
tamaño, tipo y propósito del edificio, se deben definir comportamientos en
función a las tareas operativas del edificio, ejecutar acciones sobre
equipamiento, automatizar tareas en base a reglas o comportamientos, preparar
flujos ante eventos imprevistos o periódicos. Asimismo, el diseño de estas
tareas demandará horas de capacitación en el sistema para los operadores del
sistema de acuerdo con los privilegios de cada rol que se defina (ej.:
operador, supervisor, administrador).
Registro histórico
La información histórica del BMS debe ser almacenada y
retenida. La información histórica del estado de variables brindará una base
para posterior análisis de datos. El almacenamiento de acciones de operadores,
alarmas y eventos brindarán evidencias para fines de auditoría y control. El
almacenamiento de la información operativa brinda la base para el diagnóstico
de fallas, análisis de tendencias, aseguramiento de calidad, cumplimiento
regulatorio y contabilidad. La capacidad de almacenamiento se verá afectada
directamente por el volumen de información (transacciones) administrada por el
BMS y el tiempo de retención (años) requerido de esta información. El tiempo de
retención de datos puede estar sujeto a regulaciones del sector.
Análisis de datos
Las herramientas de análisis de datos son esenciales para
la toma de decisiones de los operadores y administradores. Las capacidades más
allá de filtros, búsquedas y clasificaciones de alarmas y otros atributos
pueden requerir el desarrollo de reportes avanzados. El desarrollo de reportes
avanzados puede impactar en más horas de servicio e incluso en licenciamiento
adicional. Es recomendable considerar capacidades para la extracción de datos,
análisis estadísticos y generación de informes en esta etapa o para futuro.
Esto puede comprender la integración a otros sistemas para mejor
aprovechamiento de la información. Por ejemplo, integración de datos hacia el
sistema contable para la imputación de gastos de energía por área. Parte de
estas herramientas de reportería avanzada y análisis pueden ser provistas por
el mismo fabricante de BMS.
Infraestructura tecnológica
El dimensionamiento de los componentes de hardware viene
ligado directamente al volumen de información estos van a procesar
y al nivel de disponibilidad requerido. El BMS es un sistema crítico del
edificio. La falta de disponibilidad puede interrumpir la operación normal de
los sistemas controlados. La cantidad de núcleos, memoria, redes y
almacenamiento se pueden estimar de acuerdo con métricas del proveedor de
software para BMS. La inclusión de una plataforma de virtualización brindará
alta disponibilidad al sistema. La capa de virtualización incrementará la
cantidad de núcleos, memoria y almacenamiento. La capacidad requerida para
virtualización dependerá de las recomendaciones del proveedor del hipervisor.
La solución de BMS deberá estar homologada por el fabricante para la
virtualización. El almacenamiento también debe contemplar componentes
redundantes para garantizar la alta disponibilidad a través de arquitecturas
tradicionales (DAS, SAN o Convergente) o a través de nodos Hiperconvergentes en
el que cada nodo aporta capacidades de procesamiento y almacenamiento. Si se
requiere infraestructura nueva (proyecto greenfield) para alojar al BMS, se
debe tomar en cuenta la experiencia disponible de los administradores de
sistemas para la gestión de la plataforma. En caso de falta de experiencia, las
capacitaciones requeridas para aminorar la brecha. Durante el dimensionamiento
de la infraestructura tecnológica también deben considerarse las licencias de
software necesarias para habilitar la infraestructura. Asimismo, los contratos de soporte/suscripción de los fabricantes de software,
hardware, hipervisores, sistemas operativos, bases de datos y conexiones de
clientes/dispositivos.
También debe definirse el acuerdo
de nivel de servicio que se requiere para la atención de incidentes del
sistema, mantenimiento preventivo y horas de soporte.
Etapa 2. Relevamiento de variables
El BMS puede integrarse con diversos
subsistemas del edificio como: almacenamiento de combustible, sistema de agua
caliente, CCTV, climatización, control de acceso, sistemas de evacuación,
distribución eléctrica, distribución de gases, hidrosanitario, transporte
vertical, iluminación, etc. La cantidad y tipo de variables dependerán de los
subsistemas que se decidan integrar al BMS. Cada subsistema puede tener
variables digitales y analógicas de entrada y de salida.
Es necesario contar con la participación de
los instaladores de estos sistemas para la correcta consideración de variables
y validación de protocolos de comunicación.
Los subsistemas que tengan variables de
entrada permitirán conocer y medir estados (variables de monitoreo), en caso de
existir variables de salida será posible definir escalas y estados (variables
de control).
El correcto relevamiento de las variables es
determinante para lograr un adecuado dimensionamiento de la solución BMS. El
procedimiento implica conocer las características de los subsistemas y la
configuración de sus variables, para posteriormente realizar la abstracción de
sus componentes en el sistema. Es recomendable considerar la participación del
ingeniero de cada subsistema para la obtención de los datos consolidados y
validados. Se debe obtener la cantidad de variables digitales y analógicas y
cuales de ellas son de monitoreo y control. Asimismo, los protocolos utilizados
por los dispositivos de control. En esta etapa, también debe participar el
equipo de redes de datos para validar la cantidad de puertos libres en switches
de acceso para los dispositivos de control. Al mismo tiempo, se debe definir un
esquema de ciber seguridad para proteger de la mejor manera la transmisión de
información entre dispositivos a través de la red de datos como el manejo de
contraseñas seguras, mantenimientos programados para actualización de
dispositivos, reglas de firewall, segmentación de redes por propósito, etc.
Las horas de servicio requeridas para la
configuración de subsistemas en el BMS será impactada por el tipo y cantidad de
variables, conexión a dispositivos de control, abstracción de dispositivos de
campo, configuración de los sistemas, configuración de reglas y
comportamientos.
En esta etapa, también se debe obtener planos
para conocer la disposición de los ambientes del edificio. La abstracción
física de las áreas de edificio o complejo también impactarán en las horas de
servicio.
Etapa 3. Diseño de arquitectura
Según se presenta en la Figura 2, toda arquitectura del BMS considera tres (3) capas.
Figura
2. Arquitectura general de un Sistema BMS
El gráfico 2 muestra la arquitectura general del
funcionamiento de un sistema BMS, que consiste en la interrelación entre: capa de
gestión, capa de dispositivos de control y capa de dispositivos de campo. A
continuación, se explica a detalle el objetivo de cada capa.
Capa 1, plataforma de gestión. Comprende los servidores o clúster que alojan a los
servicios del BMS. Se encuentran las estaciones de monitoreo y control para la
gestión del edificio. A este nivel, también se realiza la integración a otros
sistemas (Video Management System, Control de Acceso, Directorio Activo, Bases
de Datos, Herramientas de análisis, etc.). Las comunicaciones en esta capa se
realizan a través de TCP/IP. En este nivel se abstraen los subsistemas del
edificio para su gestión, monitoreo y control. Se realizan las programaciones
de horarios, comportamientos del edificio, reglas y condiciones. Asimismo, la
generación de vistas para monitoreo en línea y reportes históricos de
tendencias, eventos y alarmas.
Capa 2, control de procesos. Esta capa comprende los dispositivos de control y
monitoreo específicos a los subsistemas del edificio. Estos pueden comprender
detección y supresión de incendios, transporte vertical, distribución y
generación eléctrica, sistemas de confort, iluminación, persianas, calidad del
aire, control de acceso, CCTV, intrusión, etc.
Los dispositivos de control son propios de cada
subsistema (eléctrico, confort, transporte, etc.). El dimensionamiento,
distribución e instalación de ellos está sujeto al diseño cada sistema al que
pertenecen. Es decir, son provistos y mantenidos por los
instaladores/mantenedores del sistema. Estos dispositivos deben contar con un
puerto en la red de datos (TCP/IP) para comunicación con el BMS y con
conexiones hacia los dispositivos de campo formando la red de instrumentación.
La red de instrumentación puede utilizar protocolos de comunicación
industriales con los dispositivos de campo (Ej.: Modbus, BACnet, KNX, DALI,
OPC, SNMP, etc.). Los dispositivos de control son la pasarela de interconexión
entre la red de datos y la red de instrumentación.
Capa 3, dispositivos de campo. Controlados directamente desde la capa de control, los
dispositivos de campo obtienen información (sensores de: estado, temperatura,
luz, movimiento, etc.) y controlan mecanismos de los subsistemas (válvulas,
interruptores, actuadores, motores, etc.). En esta capa se debe se realiza la
conexión con los componentes propios de los subsistemas técnicos del edificio.
La provisión, instalación y configuración de ellos están sujetos al diseño cada
subsistema. Cada uno de estos de elementos será abstraído en el BMS.
Dimensionamiento
de hardware y software
Para que el correcto dimensionamiento de la solución, se
debe considerar los componentes de conexión de redes y servidores, según se
muestra en la Figura 3 como referencia.
En la Figura 3 se presenta el diagrama de conexión a
nivel de red de datos. Es importante considerar redundancia de conexiones de
red en los servidores y equipos de red para incrementar la disponibilidad ante
fallas o mantenimientos. Las controladoras de campo, una vez conectadas al
servidor, envían lecturas (monitoreo) hacia el BMS y reciben instrucciones
(control) desde el BMS. Dependiendo el proveedor del sistema, las controladoras
también pueden disponer puertos para conexión redundante. También se debe
considerar que la alimentación eléctrica de las controladoras pueda ser a
través de PoE (Power over Ethernet). La cantidad de dispositivos conectados y
alimentados a la red de acceso impactará en el dimensionamiento de switches de
acceso. Este proceso no contempla el dimensionamiento de switches de acceso.
Sin embargo, esta información relevada en esta etapa puede disparar
adecuaciones previas al sistema de red de datos.
Figura 3.
Conexiones de red de datos.
El dimensionamiento del equipamiento de servidores deberá
realizarse de acuerdo con la cantidad de variables consideradas, según las
recomendaciones de los fabricantes y las tablas de dimensionamiento de
hardware. Con estas métricas es posible dimensionar las especificaciones
requeridas para el sistema. La provisión de infraestructura puede requerir un
clúster nuevo o habilitación de recursos sobre infraestructura existente.
En el caso de que el proyecto demande infraestructura
nueva, se recomienda un clúster de servidores con propósito específico. El
clúster habilita capacidades para alta disponibilidad de los servidores del
sistema BMS, bases de datos y otros servicios de integración (control de
acceso, directorio, etc.). Es necesario dimensionar las especificaciones de los
servidores físicos considerando un porcentaje de crecimiento.
Adelante se presenta un diagrama de alto nivel de un
clúster de servidores contemplando conexiones redundantes en la red de datos
(LAN) y la red de almacenamiento (SAN) (ver Figura 4).
Figura
4. Clúster de servidores con storage SAN
compartido.
Como se observa en el gráfico 4, la infraestructura de
hardware deberá considerar redundancia en las conexiones entre los nodos de
procesamiento, el almacenamiento y la red. Asimismo, la conexión hacia la red
del edificio debe contemplar switches redundantes. Los switches de red pueden
ser desestimados en caso de tener puertos disponibles en la infraestructura
existente.
En cada servidor se deberá montar un hipervisor para
virtualizar los recursos CPU, RAM, Almacenamiento y Redes. Así las cargas que
se ejecutan en el clúster podrán migrar de manera inmediata ante eventualidades
sin afectar la disponibilidad. Los componentes redundantes y la virtualización
de hardware permiten al sistema seguir operando en caso de que un componente
falle. La redundancia en el dimensionamiento de los servidores (de acuerdo con
recomendaciones del fabricante) deberá contemplar proyecciones de crecimiento,
de tal modo que en ningún momento se requiera usar el 100% de capacidad de los
servidores. El clúster debe tener recursos disponibles para garantizar la
disponibilidad en ante la falla de al menos 1 nodo.
De acuerdo con la plataforma de virtualización, se debe
tener en cuenta las licencias requeridas por el fabricante para el
funcionamiento de clúster. Asimismo, las licencias requeridas para los sistemas
operativos de las máquinas virtuales que se ejecuten sobre la plataforma. El
software también debe contemplar el licenciamiento de las bases de datos
requeridas más adelante. De
igual forma, el dimensionamiento de éstas últimas dependerá de las
recomendaciones del fabricante de BMS.
Es necesario tomar en cuenta las configuraciones
necesarias para integrar el clúster a la infraestructura existente. Esta
operación demandará horas de servicios para integración a dominios de seguridad,
cumplimiento de normas de ciberseguridad y
documentación. Asimismo, puede demandar la coordinación para configuraciones de
dispositivos de red, reglas de firewall y herramientas de respaldo de
información.
Etapa 4. Consenso
Con la información de cantidad y tipo
variables por subsistema, dispositivos de control y sus protocolos, información
del edificio y operativa del mismo, arquitectura de hardware definida e
integraciones requeridas a otros sistemas se puede realizar el dimensionamiento
de los componentes de hardware y software para la solución de BMS tomando en
cuenta las consideraciones generales. Esta etapa puede iterar nuevamente el
proceso de dimensionamiento de acuerdo con restricciones presupuestarias,
brechas de experiencia encontradas o cambios de requerimientos en el sistema.
En esta etapa se concertará el alcance de la
solución y los servicios que este conlleve. Se debe tener claro el alcance del sistema y las expectativas de este. Es recomendable
poder segmentar el proyecto en fases para poder sobrellevar restricciones
presupuestarias.
Ejemplo: Arquitectura de solución BMS para un hospital
El objeto de estudio como ejemplo contempla
el dimensionamiento del BMS para un hospital. El hospital comprende 2 edificios
contiguos, Torre A con 8 niveles en una superficie de aproximadamente 1400m2
y Torre B con 5 niveles en
una superficie de aproximadamente de 2500m2. Distribuidos se
encuentran áreas para atención de emergencias, quirófanos, equipamiento de
diagnóstico avanzado, consultorios de diversas especialidades, maternidad,
neonatología, áreas de internación, terapia intensiva, laboratorios, bodegas
climatizadas, servicios de lavandería, comedores de personal y de visitantes.
Como transporte vertical, ascensores de personal en cada torre y ascensor de
servicios en la torre B. Las azoteas de ambas torres se disponen para
equipamiento de climatización. Los predios cercanos para el equipamiento
eléctrico de generación y transformación eléctrica. Asimismo, almacenamiento de
combustible y gases clínicos. Los sistemas de CCTV y Acceso están contemplados
de acuerdo con las áreas comunes, equipamiento monitoreado y otras áreas de
interés.
Con el objetivo de hacer más explícita la dinámica del
dimensionamiento, se presenta brevemente su aplicación en el dimensionamiento
de una solución BMS para un hospital. A continuación, se detalla la solución
propuesta para un hospital, sus componentes de software, hardware e interacción
con los subsistemas del edificio. Los siguientes datos muestran los resultados
de la cuarta iteración del proceso.
Etapa
1. Consideraciones generales
El
desarrollo de la arquitectura del BMS tomó cuatro meses, se contó con un
equipo multidisciplinario compuesto por un arquitecto de soluciones,
especialistas de BMS, servidores, virtualización y telecomunicaciones. Se desarrolló una serie de reuniones en las que
se releva información a detalle de las consideraciones del proyecto en cada
iteración. Las consideraciones de la primera etapa marcarán el lineamiento de
la operativa esperada del edificio, infraestructura de hardware, esquemas de
licenciamiento, alcances y expectativas de la solución.
El objetivo inicial del hospital es generar ahorros con
la solución BMS a través del control y automatización de comportamientos de los
subsistemas de caldera, climatización e iluminación solamente en primera
instancia. Se requiere el monitoreo del resto de los subsistemas comprendidos
en el edificio.
Los sistemas monitoreados y controlados son: Caldera,
Climatización, Iluminación.
Los sistemas monitoreados son: Almacenamiento de
combustible, Almacenamiento de gases clínicos, Ascensores, CCTV, Control de
acceso, Distribución eléctrica e Hidrosanitario.
Se requiere almacenar los datos por 3 años en línea para
el posterior análisis de información y encontrar tendencias en los consumos de
energía de los subsistemas y áreas del hospital. El almacenamiento para 3
años debe ser considerado en la infraestructura. También se consideran las
licencias necesarias para la producción de reportes y análisis de datos.
Como lineamiento de hardware, el hospital no tiene una
arquitectura de hardware ni marca predefinida. Este escenario (greenfield) es
ventajoso ya que permite tener un diseño a medida para la solución.
Esta primera etapa nos brinda el lineamiento básico para
la definición de componentes y la operación entre ellos.
Etapa
2. Relevamiento de variables
Se contempla la integración de monitoreo y control de los
subsistemas y variables descritos en la tabla 1.
Tabla 1.
Listado de subsistemas y variables
|
Subsistemas
|
Variables de
entrada
|
Variables de
salida
|
|
Digital
|
Analógica
|
Digital
|
Analógica
|
|
Almacenamiento de
combustible
|
4
|
2
|
|
|
|
Almacenamiento de gases
clínicos
|
7
|
|
|
|
|
Ascensores
|
48
|
24
|
|
|
|
Caldera
|
|
16
|
4
|
|
|
CCTV
|
350
|
|
|
|
|
Climatización
|
721
|
273
|
429
|
180
|
|
Control de acceso
|
140
|
|
|
|
|
Distribución eléctrica
|
248
|
885
|
|
|
|
Hidrosanitario
|
56
|
1
|
|
|
|
Iluminación
|
317
|
|
317
|
|
|
Total subsistemas
|
1891
|
1201
|
750
|
180
|
|
Reserva 20%
|
378
|
240
|
150
|
36
|
|
Total variables
|
2269
|
1441
|
900
|
216
|
|
Gran total
|
4826
|
La tabla 1 presenta el resumen del relevamiento de los
once subsistemas estima 4826 variables, considerando una proyección de
crecimiento al 20%. El 77% de las variables son de monitoreo o entrada y sólo
23% corresponde a variables de control o salida (caldera, climatización e
iluminación). Los subsistemas que contemplan más variables son distribución
eléctrica, climatización e iluminación.
El tipo y cantidad de las variables son provistas por
cada especialista en el subsistema del edificio. Además de las cantidades,
proporcionan información de los protocolos utilizados en la red de
instrumentación hacia los dispositivos de campo. La cantidad de variables y
protocolos utilizados determinan la cantidad de licencias de software,
protocolos habilitados y horas de servicios requeridos para el dimensionamiento
del sistema. Asimismo, proveen información para dimensionar el tamaño de
servidores y almacenamiento para el procesamiento de la información del BMS.
Finalmente, la cantidad de dispositivos de control afecta la cantidad de
puertos de red requeridos en los switches de acceso. Esta última es información
es útil para el dimensionamiento de la red de datos del edificio (fuera del
alcance del proyecto).
En esta misma etapa se obtienen planos actualizados de
los ambientes para la estimación de horas de servicios requeridas para la
abstracción los ambientes en el sistema BMS.
Etapa
3. Diseño de arquitectura
El diseño requerido por el hospital demanda que la
solución BMS incluya un clúster dedicado para garantizar la alta disponibilidad
bajo la plataforma VMware.
Se considera el clúster para las cargas de servidores de
BMS, base de datos e integración. El clúster albergará 3 máquinas virtuales,
cada una de ellas con 8 cores y 16 GB de RAM de acuerdo con el dimensionamiento
del fabricante de BMS. Los roles de BMS, base de datos e integración deben ser
instalados en servidores independientes. Si bien la separación de roles
incrementa los requerimientos de infraestructura, también brinda facilidades en
las tareas operativas de mantenimiento y respaldo más adelante. Se considera un
clúster pequeño de 3 nodos físicos con un almacenamiento compartido.
La infraestructura de hardware, de acuerdo con el
relevamiento, contempla: 1) Almacenamiento SAN con conexión directa al storage
a través de Fiber Channel a 16 Gbps. 2) Servidores con procesadores Intel Xeon
de 20 cores y 96 GB de RAM. Cada uno con conexiones redundantes a switches Top
of the Rack (ToR) a 10 Gbps. 3) Switches ToR con puertos 10Gbps para la
conexión de servidores y puertos para up-link de hasta 40Gbps para up-link
hacia el core de red.
Figura
5. Diagrama de clúster de servidores con
storage SAN compartido.
La
Figura 5 presenta los componentes de hardware, virtualización, sistemas
operativos y aplicaciones.
Sobre
la infraestructura de hardware, se contempla la siguiente solución de software
1) VMware como hipervisor habilitando el clúster con 3 nodos, 2) licencias de
Windows Server como sistema operativo de las máquinas virtuales para los
servidores de BMS, base de datos e integración, 3) licencia de SQL Server
Standard para la base de datos de ambos sistemas.
Considerando
que el BMS es un sistema crítico, se incluyen contratos de servicio de atención
24/7 para la atención de incidentes
Etapa 4. Consenso
En esta etapa se validaron todos los componentes de la
solución: hardware, software, servicios y soporte, se definieron los montos
estimados de implementación del proyecto. En consenso con los interesados el
proyecto, se ajustaron los alcances de la solución para viabilizar la
adquisición de acuerdo restricciones presupuestarias. Cada iteración produce
cambios en la solución que afectan los costos y
plazos requeridos para su implementación.
CONCLUSIONES
Este proceso plantea las consideraciones
mínimas requeridas para el generar el dimensionamiento ordenado de cada uno de
los componentes para una solución de BMS. Procura simplificar las tareas y
ordenar la información
para generar un diseño de propuesta claro. Gracias a la aplicación práctica en un hospital se evidenció que,
al seguir el proceso, los componentes requeridos para el BMS son supervisados e
integrados para garantizar la funcionalidad del sistema en cumplimiento de los
requerimientos del hospital.
Este proceso puede asistir en el dimensionamiento para
proyectos que requieran una solución completa de
hardware, software, servicios y soporte para BMS.
En el contexto actual, muchas empresas
pequeñas, medianas y grandes, deben elevar la eficiencia, reducir costos e
incrementar la productividad para sobrevivir, el principal aporte tiene foco en
la economía nacional e internacional y en la salud de sus empresas.
En condiciones normales, los aportes
anteriormente descritos generan valor para la comunidad investigativa y
empresarial. En condiciones excepcionales, como la crisis actual generada por
el COVID-19, se valora mucho más todo aporte al sector empresarial.
REFERENCIAS
Applied Risk BV. (2019). I Own Your Building (Management System). Amsterdam.
Antesana,
Iván Robinson y Medina, Anibal (2016) Sistema de control centralizado de
edificios B.M.S. Universidad Católica de Córdoba [Tesis de Grado]
Fundación
Giner de los Ríos (2016). Libro Verde. Hacia un sector eficiente. Chile
Gökçe,
H; Gökçe, K. (2012) Holistic system architecture for energy efficient building
operation
Microsoft
(2019) CREATING INTELLIGENT SPACES Five strategies to accelerate smart building
transformation. Microsoft Azure - White papers
Osama
Omar (2018) Intelligent building, definitions, factors and evaluation criteria
of selection. Alexandria Engineering Journal, Volume 57, Issue 4, December
2018, Pages 2903-2910
Perry,
C. (2017). Smart Buildings: A Deeper Dive into Market Segments. Report A1703. ©
American Council for an Energy-Efficient Economy. EEUU
Nguyen,
T. (2012). Energy and BuildingsEnergy intelligent buildings based on user
activity: A survey. Revista Energy and Buildings. Nijenborgh 9, 9747 AG
Groningen, The Netherlands
Van
Hoof, B. (2018). DATA-DRIVEN WORK SPACES IoT and AI Expand the Promise of Smart
Buildings. Harvard Business School Publishing. MC210190918. EEUU
Vasques,
X. (2011). Analysis and knowledge discovery from sensors data to improve energy
efficiency Conference Paper · DOI: 10.13140/2.1.2843.4240