Integración de un centro de control y un programa de gestión del mantenimiento en el ámbito sanitario
RESUMEN
La implantación de un centro de control y de un sistema de gestión de mantenimiento es una actividad bastante laboriosa en edificios de nueva construcción, pero lo es aún más en construcciones existentes y que cuentan con instalaciones de diferentes periodos tecnológicos. Éste es el caso del Hospital Universitario Virgen de las Nieves de Granada, un conjunto de edificios complejos en que los sistemas y equipos que requieren de vigilancia, control y análisis de datos son múltiples y complejos, con equipamientos de diferentes épocas, en algunos casos con más de 30 años de antigüedad y en los que los sistemas de información del mantenimiento eran de poca utilidad. La instalación de estos sistemas es algo muy normal en la industria, por la estandarización en sistemas y equipos, pero muy poco visto en el mundo sanitario, por la miscelánea de productos y el sobrecoste muy pocas veces asumido. El objetivo principal de la implantación de estos sistemas es que la información procedente de equipos, instalaciones y mantenimiento puede confluir en un solo punto. La información dispersa para su análisis requiere de un gran esfuerzo. Sin embargo, si fusionamos las distintas fuentes en un solo elemento obtendremos el máximo rendimiento del uso de las tecnologías.
Palabras clave
Mantenimiento, hospitales, instalaciones, centro de control, gestión del mantenimiento.
ABSTRACT
The implementation of a control centre and a maintenance management system is a complex undertaking in new buildings, but it is much more so in existing buildings which contain installations of different technological eras. This is the case of the Virgen de las Nieves University Hospital in Granada, a collection of complex buildings in which the systems and equipment which require monitoring, control, and data analysis are many in number and complicated, with installations of varying age, in certain cases as much as 30 years old, and where the maintenance information systems were of very limited use. The installation of these systems is common practice in industry, with standardisation of systems and installations, but it is very seldom seen in a healthcare setting, due to the diversity of services and the elevated costs involved. The principal objective of implementing these systems is to enable the data originating from different equipment, installations and maintenance to be collected in one single location. Analysis of dispersed data sources requires considerable effort; however, if we join these sources into one single data output we achieve the maximum efficiency from the use of the technology employed.
Keywords
Maintenance, hospitals, installations, control centre, maintenance management.
Introducción
El Hospital Universitario Virgen de las Nieves (HUVN) pertenece al Servicio Andaluz de Salud. El centro tiene 1.072 camas y su cartera de servicios hace de éste un centro de referencia regional y nacional. Está situado en Granada, cuenta con 11 edificios, entre hospitales, centros administrativos y de servicios, alguno de ellos con más de 50 años de antigüedad. El personal propio del servicio de mantenimiento cuenta con más de 120 operarios.
Las actuaciones que en este artículo se presentan han ido encaminadas a integrar un sistema centralizado de alarmas técnicas (CECO) y un programa de Gestión del Mantenimiento Asistido por Ordenador (GMAO), que, en principio, puede parecer sencillo, pero que lleva consigo un importante trabajo, teniendo en cuenta que contamos con múltiples edificios, separados algunos de ellos por cientos de metros, que éstos son bastante antiguos, que las instalaciones, en muchos casos, son obsoletas y que la mayoría del personal de mantenimiento no poseía conocimientos sobre nuevas tecnologías. Por tanto, y antes de empezar a unir dos aplicaciones informáticas que nos facilitarán el trabajo, había que comenzar realizando un proyecto que definiera las líneas estratégicas de actuación en relación con los aspectos tecnológicos de la ingeniería y el mantenimiento del HUVN. Y esto sí que es un trabajo realmente complejo. Cuanto más, si no reflexionamos sobre lo que tenemos y hacia dónde queremos ir. Este pensamiento nos llevó a la conclusión de que sin un plan estratégico1 que estableciera las pautas que seguir y dibujara la forma cómo hacerlo, no obtendríamos el éxito en aquello que nos proponíamos. Los campos de trabajo a los que este plan se refiere son tres: telecomunicaciones, sistemas de control e información y seguridad de personas y bienes.
Sin lugar a dudas, y por la complejidad del mismo, este proyecto tiene un carácter ineludiblemente multidisciplinar, ya que sin la participación activa de todas las unidades dependientes de los Servicios Generales de un hospital, esta idea no saldría adelante. Además, debe existir sobre todo un apoyo decidido de la dirección, y es la Dirección de Servicios Generales la que debe liderar todo el proceso, consiguiendo, de este modo, que no se produzcan divisiones, falta de interpretación o de cohesión ni responsabilidades difusas o compartidas que llevarían al caos en la ejecución de las distintas acciones.
Motivación
Resulta clave cómo afrontar un proyecto de modernización de los sistemas e instalaciones de edificios de más de 30 años, sin parar la actividad asistencial, y de manera que social y económicamente sea sostenible. Y, en este caso, es muy sencillo: haciéndolo por partes. Esta afirmación puede parecer, en principio, obvia, pero en nuestro caso no lo es tanto si nos referimos a la implantación de las nuevas tecnologías. No es lo mismo tener que afrontar la automatización de una línea de producción de una fábrica que carece de ella, que pretender controlar toda la planta en un solo acto. Esta segunda opción supondrá un ímprobo esfuerzo tanto técnico como económico, y de estas dos voluntades no siempre existen excedentes en la Administración Pública.
Por ello, dibujamos un escenario al cual queremos llegar, y sentamos las bases para conseguirlo sin tener que realizar el esfuerzo de una sola vez. Es como si tuviéramos un puzle en el que hay una imagen compleja y única que está formada por cientos o miles de pequeñas figuras sin sentido por separado pero que, en conjunto, presenta algo sorprendente. Esto es lo que nosotros hemos hecho, integrar poco a poco los sistemas que se han ido ejecutando en las distintas reformas, dedicando en todas ellas un apartado de telecomunicaciones, sistemas de control e información y seguridad de personas y bienes, que al final nos per-mitiera unirlo todo y obtener un único CECO y un único GMAO.
La integración de estas aplicaciones facilita la anticipación de los problemas, por ejemplo, que un usuario pueda mostrar quejas hacia el personal sanitario porque en su habitación hace demasiado calor o frío. Con este sistema nos podemos anticipar al problema. Además, no requerimos que la supervisión del centro de control deba realizarse con la presencia constante de una persona, sino que sabemos que las desviaciones de variables o alarmas serán comunicadas, bien vía SMS si son críticas, o por medio de una hoja de trabajo, si no lo son. Y como es evidente, este uso nos permite obtener una trazabilidad de lo que ocurre en nuestras instalaciones sabiendo dónde y con qué frecuencia se producen los problemas de forma repetitiva. Esto nos ayuda a gestionar el mantenimiento.
El objetivo de obtener la información anteriormente mencionada del CECO y gestionarla en el GMAO es conseguir, en primer lugar, ordenar la información técnica y tenerla en un único sitio, y, en segundo es que el hecho de contar sólo con una fuente de información permite ordenar el trabajo desde dicha referencia. Esto facilita que no existan errores en las prioridades, y en el caso de instalaciones o equipos críticos, el GMAO también envía SMS automáticos a los operarios implicados por el sistema en cuestión, o bien al servicio de atención técnica (SAT) asociado a un determinado equipo.
Líneas de acción
Sistemas Scada
La puesta en marcha de este tipo de sistemas es, tal vez, la actuación que inicia el plan estratégico tecnológico, porque fue el que nos permitió crear una matriz en la que se alojarán todas las acciones que en el futuro pudieran acometerse en este sentido y, a su vez, el embrión del que posteriormente nacería el centro de control.
Con este planteamiento se desarrolló el proyecto de instalación de los subsistemas de seguridad y de gestión de señales técnicas, que comenzó en el año 2005 y finalizó exitosamente en diciembre de 2007. En el proyecto de seguridad se introdujeron cientos de controles de accesos (430), decenas de cámaras (hasta 194 entre digitales, convencionales e IP), sistemas de detección volumétricos (40) y enclavamiento de puertas de acceso y salida al recinto (hasta 80). En las reformas se instalaron autómatas en zonas técnicas, plantas de hospitalización y zonas comunes hasta cubrir una superficie de 58.547 m2 útiles, lo que supone el 45% de la superficie total en grado de control y automatización.
Los sistemas de seguridad se integraron en un centro de control con una única base de datos (Winpack2), enlazado con un software de tratamiento de imágenes (Fusion) y las señales técnicas, el control de las mismas y el análisis de datos se recogieron en un único Supervisory Control And Data Acquisition (SCADA Vijeo Citec). La conjunción de estos sistemas nos permite gestionar la imagen y el seguimiento de personas en función de los eventos que se vayan produciendo. A su vez, facilita la regulación del flujo de profesionales y usuarios dentro del hospital, tanto en circuitos horizontales como verticales -ascensores-, ya que el total de los 4.500 trabajadores del HUVN, así como los cientos de eventuales, todo el personal de servicio, cuidadoras de enfermos de larga estancia y personal de empresas externas cuentan con una tarjeta identificativa de proximidad bajo tecnología de identificación por radiofrecuencia (Rfid).
Éste fue el primer paso en el que sistemas centralizados se refiere, y el segundo trata de integrar todos los sistemas en isla que contaban con un autómata receptor de señales diversas, y que presentaban la información en una interfaz web.
Por otro lado, el sistema de recepción de señales técnicas y alarmas, que hemos denominado centro de control (CECO), integra los diferentes sistemas por medio de las redes LonWorks utilizando dispositivos TAC de Schneider, redes Modbus con dispositivos Telemecanique o redes Profibus con dispositivos Siemens, y todo intercomunicado por medio de la red Ethernet del hospital. Desde este CECO, que se encuentra permanentemente bajo la supervisión, control y análisis de datos de los distintos ámbitos de mantenimiento del HUVN, podemos recoger las señales de los autómatas que se encuentran tanto en zonas de hospitalización y comunes, donde controlan climatización e iluminación, como en zonas técnicas, donde controlan desde ascensores, montacargas, bombas de circulación de agua potable o climatización, funcionamiento de climatizadores, alarmas técnicas de gases medicinales, grupos electrógenos, enfriadoras de agua, calderas, depuradoras de agua para diálisis, sistemas auxiliares críticos (refrigeración RM, PET-TC), etcétera. Además, las alarmas que están clasificadas como críticas pueden ser enviadas a móviles del personal encargado de dicha instalación o equipo mediante una pasarela SMS existente en el hospital (Nagios).
El CECO está basado en una aplicación informática tipo SCADA, de la marca Schneider Electric, modelo Vijeo Citet 6.1, desarrollado por un integrador de sistemas ingeniería y control remoto (ICR), de gama industrial y muy potente debido a la capacidad que posee para la recepción ilimitada de variables (dependiendo de la licencia contratada). Además, la base de datos de registros se puede tratar de forma transparente. Incluso hemos desarrollado un módulo para integrar cualquier tipo de sistema de ventilación (ventiloconvectores, UTA, climatizadores), seleccionando sólo los elementos instalados (sondas, variadores de frecuencia, compuertas…), conectando todo y quedando listo para funcionar.
Sistema GMAO
La puesta en marcha de voluminosos contratos de mantenimiento electromédicos en equipamiento de alta tecnología, radiología convencional y digital, ultrasonidos, equipamiento crítico, como respiradores, electrocardiógrafos, mesas de anestesia, etcétera, permitía en algunos casos, introducir la aplicación de mantenimiento electromédico que poseen las empresas mantenedoras en un hospital3, y se aprovechaba éste para el resto de servicios, debido al esfuerzo que suponía la actualización de bases de datos de equipos y la disciplina que éstas deben de aplicar a sus contratos. También puede darse el caso de que se adquiera un sistema comercial estándar4 por parte del hospital. Pero si bien es cierto que cualquiera de estas soluciones supone adaptarse a algo ya desarrollado, para ser utilizado por un determinado usuario que no ha elegido qué información desea ver o cómo se ha de presentar. Este razonamiento y el hecho de que el resto de sistemas HIS del HUVN se encontraban altamente implantados y requería de complejas integraciones con el nuevo GMAO, nos llevó a la conclusión de que el desarrollo del mismo debía partir desde cero y sobre las premisas que los departamentos de ingeniería, electromedicina o mantenimiento marcarán.
El inconveniente principal de esta solución es que se carece de la experiencia de una empresa especializada en el mercado sobre aplicaciones informáticas de gestión de activos y mantenimiento. Pero, a cambio, la adaptabilidad del programa a la morfología del centro es perfecta y, sobre todo, cuenta con tres pilares fundamentales que son los que han conformado el know-how de este proyecto, y son: la flexibilidad, que la aplicación crezca en función de las necesidades sociales, técnicas y tecnológicas del centro; la integración, que la aplicación se entienda con el máximo de sistemas; de información del hospital, y la libertad, que el lenguaje de programación no sea propietario de una única empresa.
El programa de Gestión del Mantenimiento Asistido por Ordenador (GMAO) cuenta con las principales novedades que pueda poseer una aplicación de este tipo. Entre ellas podemos destacar: su base de tecnología apoyada siempre en estándares de mercado, como SQL Server 2005 SP2, que nos permite trabajar con volúmenes de datos importantes y, a la vez, conseguir velocidades de búsquedas por debajo del segundo para miles de datos; utilizar y mostrar esa información en formato de estadísticas o listados a través de herramientas de creación de informes de la herramienta Crystal Reports, que nos per-mite manejar los datos de la aplicación con gran facilidad, y generar tablas y gráficos adaptados a nuestros cuadros de mando. También se ha utilizado la última tecnología disponible en lenguaje de programación por medio de C#, dentro del entorno Visual Studio .NET 2008, y basado en el la versión 2.00 del .NET FrameWork, que permite una gran escalabilidad, así como la integración con sistemas existentes a través de diversas tecnologías como los servicios web (web servicies). El resultado es una herramienta muy escalable, integrable, robusta y con un entorno actual y muy amigable para el usuario. Con esta aplicación, desarrollada por Iconos Software, podemos gestionar un gran volumen de datos, relativos a las notificaciones de averías así como el tratamiento de hojas de trabajo relacionadas con los mantenimientos correctivos. También podemos generar fichas y programas preventivos y predictivos, organizar el mantenimiento técnico-legal, los recursos humanos, materiales, generar informes, etcétera.
Sistemas de Telecomunicaciones
Si nos quedáramos sólo con el planteamiento del software de gestión, control y vigilancia, y electrónica para el tratamiento de señales, obtendríamos un resultado claramente deficiente, ya que ¿cómo funcionaría todo si no existe un sistema de comunicación entre los dispositivos que garantice la continuidad de la información?
Por ello, y aprovechando las necesidades de otros servicios, como la imagen radiológica digital y la historia clínica del paciente, se diseñó una red de comunicaciones compuesta por fibra óptica en anillo, uniendo los armarios de red más críticos, y en estrella para conectar a los armarios de tercer nivel. A partir de la electrónica de red, conseguimos llegar hasta los autómatas, cámaras o sistemas de seguridad por medio de cableado estructurado, y para garantizar que el flujo de información alcanza el Centro de Proceso de Datos (donde se alojan todos las aplicaciones que aquí se mencionan), conformamos una red con seguridad lógica mediante VLAN5 y, para ello, tendimos una línea de fibra con garantía de tráfico hasta 10 Gb.
A su vez, debíamos conectar las áreas hospitalarias por las que están compuestos el HUVN, Caleta y Cartuja (y separadas entre sí por 800 m). Tuvimos que instalar dos redes bien diferenciadas de fibra óptica, una principal y otra de respaldo, aunque originalmente la de respaldo se suplía por una conexión LMDS6 por medio de Wimax7. Al resto de centros periféricos, que no pertenecen a ninguna de las dos grandes áreas, al transmitir bastante menos información, se les dotó con conexiones ADSL con ancho de banda hasta de 20 Mb/s de transferencia.
Sistemas de información
El principal escollo que se nos ha presentado es la falta de predisposición inicial del principal agente implicado tanto en el centro de control como en la aplicación GMAO: el personal de mantenimiento, que poseía importantes reticencias a ambos proyectos y que intentamos resolver mediante dos fórmulas:
– Con cursos de formación sobre mantenimiento de sistemas autómatas aplicados a edificios.
– Con la participación constante en la mejora de cada una de las aplicaciones, bien con colaboración directa, o bien por medio de foros de comunicación en páginas web o con reuniones periódicas bajo el formato de sesiones técnicas.
El sistema de gestión de información CECO frente a GMAO
En el momento de plantear una integración entre sistemas informáticos, lo primero que debemos hacer es preguntarnos qué información se transmitiría de un lugar a otro, para qué y cómo se hace. Este análisis previo es absolutamente necesario para realizar cualquier maniobra, ya que para fusionar parte de la información de las aplicaciones tendremos que programar pequeños scripts autoejecutables que, dependiendo de su adecuado diseño y concepción, darán un resultado u otro.
Descripción de la integración
Una vez descritos los sistemas destinados a entenderse tenemos que reflexionar sobre cómo se han de hablar. Principal escollo, ya que manejan lenguajes de programación claramente diferenciados. Por tanto, la forma más sencilla de comunicar ambas aplicaciones es compartiendo una base de datos o tabla de intercambio, en la cual alojamos determinada información del CECO. Esta información es verificada de forma continua por el GMAO y, a través de una serie de códigos, se comprueba si los avisos dejados por el CECO en dicha tabla son realmente alarmas, si están reconocidas o si la alarma es persistente y, por tanto, ya ha sido comunicada.
La identificación en el GMAO de los equipos industriales y electromédicos se realiza de manera unívoca por medio del código interno del HUVN más el número de serie, pero para el caso de locales o zonas que no alojan un equipo concreto, sino parte o conjunto de ellos, y donde sólo controlamos ciertos parámetros como iluminación y climatización, la identificación se hace algo más compleja. Estas zonas están comandadas por medio de dispositivos que cuelgan de una red principalmente LonWorks. Por ello, a la hora de integrar ambos sistemas nos surgía la duda de si íbamos a generar una notificación en GMAO contra una alarma de CECO, utilizando el texto que tuviera la misma o, por el contrario, asociábamos a cada alarma un equipo, y de este modo utilizábamos la estructura funcional del GMAO, que se hace más eficaz si hacemos una gestión por equipos, y no sobre textos sin más. Para conseguir este objetivo consignamos en el CECO cada uno de los autómatas a través del código único conocido como el neuronID8 (nID). Por tanto, no existe riesgo de que dos equipos se confundan por tener el mismo número.
Base de datos de intercambio de información GMAO-CECO
Para que la tabla de intercambio alojada en el servidor donde discurre el GMAO pueda funcionar debe poseer una dirección ODBC. Esto es: una dirección de la base de datos para poder establecer el enlace ODBC (nId-IP de la máquina o nombre con la instancia de la base de datos), un nombre de usuario que permite iniciar la sesión y autentificar al mismo para tener acceso a la base de datos, una contraseña, y dos tablas -equipos y alarmas- en las que se escriben los campos de intercambio, perfectamente definidos e inteligibles por ambas aplicaciones. A esta dirección tendrán acceso tanto el CECO como el GMAO para actualizar los registros.
Los equipos en el CECO serán identificados según hemos indicado en el apartado anterior y por medio de una tarea programada serán importados todos los días a la base de datos de equipos de GMAO para actualizar la misma.
Los datos de cada equipo y que son insertados en la tabla de intercambio son:
1. neuronID para fabricados pro Echelon, y n.º de serie para el resto; 2. Descripción del dispositivo; 3. Marca9; 4. Modelo; 5. Ubicación; 6. TAG; 7. IP; 8. Distribuidor; y 9. Servicio técnico.
El GMAO insertará esta información en la ficha de equipo con las siguientes correspondencias y automatizando determinados campos, según muestra en la tabla 1.
A continuación, describimos cómo se produce una alarma en el CECO y cómo se transmite al GMAO:
En primer lugar, se definen los rangos de alarmas. Esto se realiza por el personal de mantenimiento autorizado, de forma que desde la pantalla en la que se ubica un equipo con alarma predefinida, este operador puede configurar los distintos niveles posibles de alarma: muy alto, alto, bajo y muy bajo. Por ejemplo, para una magnitud variable con alarma predefinida como puede ser la pérdida de carga en un filtro de aire de ventilación, tendremos la opción de que el operador defina las siguientes alarmas, según se indican en la tabla 2.
Para esta configuración, tenemos un primer disparo de alarma que indica que se ha superado una pérdida de carga de 200 Pa. Esto significa que debemos cambiar pronto el filtro de ventilación. Con el segundo disparo, se confirmaría que no habremos realizado el cambio de filtro con éxito durante el tiempo disponible, por lo que se ha llegado al nivel de alarma muy alto, haciendo irremediable la sustitución del filtro con carácter inmediato para el correcto funcionamiento de la instalación.
El CECO, que toma continuamente lecturas de variables (TAG11) a las que podemos definirles niveles de alarma, como hemos podido ver en el ejemplo anterior, tiene definidas estas TAG como discretas, enteras o reales, de forma que sus niveles de alarma cambiarán según sean de un tipo u otro. Para un TAG discreto, el nivel de alarma sólo podrá ser uno, cuando el valor de la señal sea 1. Para un TAG entero, tendremos los cuatro niveles (muy alto, alto, bajo y muy bajo), con cambio de signo, pero sin parte decimal. Para las reales, será igual que para las enteras y, además, dispondremos de dos decimales para acotar aún más los rangos de alarmas.
Para acceder a la lectura/escritura de estas TAG, el CECO se apoya en drivers de comunicación que habitualmente vienen integrados con cualquier SCADA. Existen drivers específicos para multitud de protocolos y fabricantes de autómatas (Profibus-Siemens, Modbus-Schneider y DeviceNet-Omron, entre otros).
Para el proyecto de automatización en fase de crecimiento que encontramos en el hospital elegimos protocolos estándar (ModBus, Modicon-Bus original de Modicon12) y el LonWorks, que es el segundo protocolo estándar y que se usa para equipos inmóticos de climatización e iluminación. Este último también llega a ser encapsulado mediante pasarelas LONIP13 de forma que aprovechamos al máximo las ventajas y prestaciones de la infraestructura de telecomunicaciones de Ethernet existente en el hospital.
Al no disponer en el SCADA del protocolo LonWorks integrado, tuvimos que basarnos en un servidor OPC (OLE Process Control) multiproyecto, de la marca Neuron System, para intercomunicar nuestra aplicación existente en el CECO con las numerosas redes LON-IP repartidas por distintas zonas y edificios.
Para intercomunicación de los equipos LonWorks, se utilizan herramientas de software como el LonMaker, de Echelon, que los comisiona, dándoles una dirección única a la que le corresponde implícitamente un gestor (handler), que el servidor OPC utiliza para direccionarse hacia cada equipo y las TAG de cada uno de ellos. De esta forma, el CECO podrá supervisar los muchísimos valores (actualmente, tenemos 12.000 TAG), declarando los ítems14 de las variables IO con un handler por equipo, de forma que para dos variables, como por ejemplo temperatura interior de habitaciones distintas, el ítem de cada TAG cambiará únicamente en el sufijo handler, tal como se indica en la tabla 3.
Podríamos concluir que para cada equipo tenemos declaradas en nuestro CECO varias TAG que comunican a través del servidor OPC mediante la entrada en el ítem de su correspondiente IP:handler:variable. Cada una de estas nomenclaturas se corresponde con el neuronID:variable.
Por consiguiente, explicado el método de comunicación entre CECO y equipos, podemos indicar que para cada variable (TAG) existe una alarma o distintos niveles de alarmas.
Y una vez que hemos conseguido definir cómo se notificarán y producirán las alarmas, por medio de un formulario, podemos seleccionar o deseleccionar un grupo de alarmas o zonas, para los casos de necesidad como avería del autómata, caída de red de telecomunicaciones, falta de suministro eléctrico o por decisión de mantenimiento. De este modo, se evitarán avalanchas de alarmas que, a su vez, desbordarán al GMAO con cientos de notificaciones. Este formulario permitiría activar o desactivar la comunicación CECO-GMAO para cada una de las variables que se asocia a una alarma posible y cada una de éstas aparece en un listado, siendo al interfaz de uso una aplicación web de acceso restringido para administrador del sistema y personal autorizado, o cliente si posee privilegios de administrador.
Así, se puede deshabilitar por equipo o habitación, planta, centro o todas, individualmente, ya que cada equipo suele tener varias alarmas asociadas. Esta configuración se encuentra en la base de datos para el CECO y se actúa sobre la misma por medio de ventanas de configuración y manipulación para el administrador (u operarios con permisos específicos).
También es importante tener en cuenta las situaciones particulares para tratarlas en el momento de la integración. Una de ellas se produce en el CECO, cuando éste está marcando una alarma por exceso o defecto de temperatura en una determinada habitación y resulta que cuando estudiamos el sinóptico de dicha estancia nos percatamos de que el ventilador de la misma se encuentra apagado de forma manual. En este caso, aunque hayamos marcado una temperatura de consigna, ésta no se alcanzará. Por tanto, el CECO solo alojará en la tabla de intercambio aquellas alarmas que se producen cuando una variable (TAG) supera el límite que tiene establecido, si y sólo si no ha existido una intervención manual que ha llevado a que se produzca esta alarma. Esta condición es muy compleja de llevar a cabo de forma automática, pero en nuestro caso, y de momento sólo con ventiloconvectores, se programa el TAG de tal forma que éste no estará en alarma cuando el ventilador se encuentra parado de forma manual. Por tanto, una alarma en el CECO no implica necesariamente que en el GMAO se genere una notificación.
Sintaxis de la alarma
Para el adecuado entendimiento entre el CECO y GMAO hemos tenido que crear una tabla a modo de diccionario electrónico de términos que tras la automatización generada por los scripts hace que la información fluya de un lado a otro.
Estructura
XXX_ PYY_HZZZ_WW
XXX Centro objeto
PYY Planta objeto
HZZZ Habitáculo objeto
WW Tipo de alarma
Los distintos tipos de alarma se indican en la tabla 4. Ejemplo: HRT_P7_H737_AT. Esta alarma indica: «En el hospital de rehabilitación y traumatología, en la habitación 737 se ha producido una alarma por alta temperatura».
Condiciones
1. Siempre asociado a cada nombre de variable (TAG) se ha de acompañar el valor que ha generado la alarma, así como los rangos de la variable.
2. Siempre se ha de generar la entrada de fecha y hora de la última actuación sobre la entrada.
3. Siempre se debe asociar un texto identificativo.
4. Siempre debe tener asociado un campo identificativo para el equipo (nID).
Observaciones
1. Los campos necesarios que requieren una notificación como el GFH, centro, área, etcétera, los toma del equipo.
2. En el caso de que se produzca una alarma de un equipo no existente en la tabla de equipos se generará una línea en el log que llegará por e-mail al administrador de forma diaria.
Uno de los campos de intercambio de la tabla es el del estado de la alarma (EEAA), que puede tomar los siguientes valores:
0: alarma insertada en tabla de intercambio pero no reconocida por el GMAO.
1: alarma reconocida por GMAO y generada la notificación.
2: cierre técnico de la notificación en GMAO.
3: alarma desactivada, o ha desaparecido, que elimina notificaciones generadas y no genera nuevas.
Y la forma como actúa este campo dentro de la tabla de intercambio es la siguiente:
1. En caso de generarse una alarma, el CECO comprueba en su tabla si ésta está habilitada (servidor 1). A continuación, comprueba en la tabla de intercambio si hay registro para esa alarma (servidor 2). Si no existe, la escribe con el valor 0, si ya existe y posee el valor:
a. 0 o 1, no la sobrescribe.
b. 2 o 3, la vuelve a escribir en una nueva línea con el valor 0.
2. En el caso del GMAO, son las siguientes acciones las que realizará en función del valor del campo EEAA:
a. 0, se genera una nueva notificación y cambia el valor a 1.
b. 1, no hace nada.
c. Una vez que la notificación pasa al estado de cierre técnico o definitivo, el valor de EEAA pasa a 2.
d. 3, elimina las notificaciones que todavía no hayan pasado a HT y no genera nuevas.
Si el operador deshabilita una alarma, inmediatamente, CECO escribirá el valor 3 en el campo EEAA de todas alarmas deshabilitadas.
En el caso de que el operador vuelva a habilitar una alarma, o conjunto de ellas, el CECO registrará en la tabla de intercambio las alarmas que en ese momento estén activas y con el criterio del punto 2 de este apartado.
Sin una explicación previa, parece extraño que en lugar de utilizar la fecha y la hora para describir una alarma, tengamos que crear un campo para cada una, con un juego de códigos a su vez. El razonamiento de esta solución viene dado por el hecho de que ambos programas son diferentes y están concebidos, en principio, para usos diferentes. Por tanto, si no introducimos un simple nivel de entendimiento, por medio de claves, podemos encontrarnos situaciones difíciles de resolver, como que exista una avalancha de alarmas por cortes de corriente, que se produzcan dos alarmas de forma simultánea, o que, tal vez, cuando el operario llegue al lugar donde se ha producido la alarma ésta ya ha desaparecido.
Además, para garantizar que el script del GMAO y el CECO esté consultando constantemente todos los registros acumulados, que pueden llegar a ser miles, aquellos que poseen en el campo EEAA el código 2 o 3 son sobrescritos por el CECO cuando haya coincidencia en el nID o número de serie.
Conclusiones
Las ventajas que podemos obtener con la culminación de este desarrollo son múltiples y muy jugosas desde el punto de vista económico, a medio plazo, y de imagen, a corto plazo. Entre ellas, cabe destacar:
1. La automatización e integración de todos los sistemas hace que la información facilitada pueda ser compartida por todos los interesados de forma sencilla.
2. La implementación de un SCADA y un GMAO comunes nos ayudará a no tener que depender de empresas que trabajan en el hospital y que, sin la información que éstas nos facilitan no sabemos dónde nos encontramos.
3. Que la puesta en marcha de un adecuado sistema GMAO nos lleva a un control exhaustivo de las instalaciones y equipos, como conocer el tiempo de disponibilidad (uptime de equipos), tan importante hoy día debido a la presión que existe sobre las listas de espera. Bajando a un plano más operativo, podríamos saber si los recursos que poseemos están bien aprovechados o no, con el resumen de horas y actividades por operario. Esto, a su vez nos llevaría a una respuesta ordenada y ágil de las distintas peticiones del centro, lo que desembocaría en un incremento de la autoestima de los operarios y de la credibilidad de los miembros de mantenimiento ante la institución.
4. Y, finalmente, la existencia de un CECO nos ofrece información de las instalaciones. Esto se traduce en tranquilidad del personal técnico porque permite actuar rápida y eficazmente. También nos ayuda a detectar problemas de índole técnica, sin el cual nos costaría una gran cantidad de tiempo averiguar. Y, evidentemente, se nos ofrece la posibilidad del control remoto de las instalaciones que trae consigo la rapidez de respuesta, la disminución de costes y la modernización del servicio de mantenimiento del Hospital Universitario Virgen de las Nieves.
En un futuro a medio plazo, la información del CECO que pretendemos registrar en el GMAO es la siguiente:
– Número de horas de funcionamiento de bombas y equipos de producción de frío.
– Número y lugar de caídas de interruptores de protección.
– Temperatura de climatización de ciertas zonas que aún no se ha cubierto.
– Alarmas por fallo en maquinaria.
– Información de históricos de consumos energéticos y primarios.
– Estado de depósitos de residuos líquidos.
– Alarmas en sistemas de control de accesos (CCAA) y circuito cerrado de televisión (CCTV).
Esta información nos ayudará a elaborar un plan de mantenimiento basado en la diagnosis de fallos y predicción de los mismos. Además, nos permitirá ganar ingentes cantidades de tiempo tanto en la respuesta de las averías como en la parada de equipos e instalaciones, así como en la toma de decisiones para la adquisición de nuevo equipamiento, porque si sabemos cuánto nos cuesta un mantenimiento sabremos si es rentable cambiarlo .
También se abre una línea de trabajo sobre el uso de dispositivos portátiles para personal de mantenimiento y, sobre todo, para la realización de preventivos y predictivos. Por otro lado, permite reducir tiempos en la gestión administrativa de la información y en el tratamiento de averías y fallos, además de la ventaja de dejar de usar gran cantidad de papel, tener constancia de quién realiza los trabajos por medio de controles biométricos y llegar más lejos en menos tiempo y con menos recursos.
En resumen, poseemos un sistema global de información que nos coloca en la vanguardia de la tecnología hospitalaria y nos permite controlar nuestras instalaciones y el trabajo de nuestro mantenimiento desde una perspectiva ordenada y única. También abre el camino para utilizar la información e interpretarla intentando, de este modo, reducir las averías o paradas de equipamiento crítico, aumentar la eficiencia de las instalaciones para obtener un mayor aprovechamiento energético y obtener una mayor profesionalización del personal que trabaja en las mismas.
Notas
1 En nuestro caso, el I Plan Estratégico Tecnológico en Ingeniería y Mantenimiento (2005-2008).
2 Tanto Fusion como WinPack son de la marca Honey-Well.
3 De aplicaciones de este tipo existen algunos ejemplos como: Asset Plus de General Electric, el MantHosp de Ibermansa o el propio de Dräger.
4 Como pueden ser los desarrollados por empresas como Sisteplant, con Prisma, Allegro Systems, con Maximo, o el propio de Idasa Sistemas.
5 VLAN: (Virtual Local Area Network) Las LAN virtuales son agrupaciones, definidas por software, de estaciones LAN que se comunican entre sí como si estuvieran conectadas al mismo cable, incluso estando situadas en segmentos diferentes de una red de edificio aunque compartan la misma electrónica de red.
6 LMDS: Local Multipoint Distribution Service (Sistema de Distribución Local Multipunto) es una tecnología de conexión vía radio inalámbrica.
7 Comunicación WiFi de alta velocidad hasta 100 Mb/s de tranferencia.
8 Identificador unívoco de un equipo electrónico de Echelon, fabricante de chips comunicantes para redes LonWorks. Todos los equipos instalados en el hospital poseen un identificador de referencia para cada controlador individual (nID, o MAC/IP/dirección Modbus si se trata de autómatas no Lon-Works). En el caso de PLC de mercado o E/S distribuidas esto no es posible. Para este caso utilizamos los números de serie.
9 Tanto este campo como el de modelo serán tomados de una listado actualizado que ofrecerá el GMAO al CECO.
10 Grupo Funcional Hospitalario; representa los centros de coste del hospital y es la agrupación que nos per-mite identificar usuarios con lugares de trabajo, a su vez con edificios y, finalmente, con áreas de actuación.
11 TAG: variable.
12 Posteriormente liberado el código para su estandarización por Schneider Electric. ModbusTCP: Mod-bus encapsulado en tramas de comunicación Ethernet TCP-IP.
13 Comunicaciones industriales de señales técnicas sobre cableado y electrónica de redes locales de comunicación.
14 Item: valor alfanumérico.
15 SNVT: conjunto de tipos predefinidos de variables de red asociadas a unidades, tales como grados centígrados, voltios, etcétera.
