UTILIZACIÓN DE LA API WIN32 PARA EL CONTROL DE LA COMUNICACIÓN SERIE EN UN SISTEMA PARA PRUEBA DE ESFUERZO

Transcripción

1 UTILIZACIÓN DE LA API WIN32 PARA EL CONTROL DE LA COMUNICACIÓN SERIE EN UN SISTEMA PARA PRUEBA DE ESFUERZO N. Gómez, M. Cañizares, O. Mora, M. de la Parte, A. Guía, J. A. Rodríguez Instituto Central de Investigación Digital Calle 202 #1703 e/ 17 y 19, Siboney, La Habana, Cuba; nglopez@icid.edu.cu RESUMEN Este trabajo explica el procedimiento utilizado para el control de la comunicación serie entre un electrocardiógrafo comercial y una microcomputadora tipo PC en el sistema para la automatización y control de la prueba de esfuerzo denominado EXECG-100. El método propuesto emplea las herramientas que brinda la API Win32 de Microsoft para la comunicación por puerto serie y el control de la prioridad de las aplicaciones. Permite la adquisición de los datos y su procesamiento en tiempo real. Se ha utilizado durante más de un año con resultados satisfactorios. Ha sido probado en diferentes arquitecturas compatibles con IBM demostrando su aplicabilidad en motherboards Pentium o superior. Se realizaron pruebas de funcionamiento ejecutando el EXECG- 100 con otras aplicaciones, obteniéndose buenos resultados. Solo se detectaron problemas cuando se emplean programas antivirus residentes. Las soluciones obtenidas son aplicables para el monitoreo de cualquier señal biomédica y válidas para cualquier plataforma Windows. Palabras clave: comunicación por puerto serie, Win32, monitoreo de bioseñales, prueba de esfuerzo de ECG, Windows. 1. INTRODUCCIÓN El auge alcanzado por la computación en los últimos años ha potenciado la utilización de las microcomputadoras tipo PC en la solución de problemas biomédicos de diversa índole. Una gran variedad de sistemas de adquisición de datos médicos se encuentra disponible en el mercado. Básicamente un sistema biomédico basado en PC consta de un módulo encargado de la adquisición de las bioseñales (ECG, EEG, etc.) y una computadora con un software instalado para el procesamiento y análisis de la misma (figura. 1). Los módulos de adquisición pueden ser externos o internos, aunque los más corrientes son los externos por ser más fáciles de instalar por el propio usuario. La conexión entre el dispositivo externo y la PC puede establecerse a través de los puertos que posee la PC: serie, paralelo, infrarrojo, USB, etc. Aunque la tendencia actual es el uso del USB la comunicación serie es indudablemente la más utilizada, ya que todas las computadoras con arquitectura IBM PC tienen al menos un puerto RS232 disponible [5]. A pesar de no ser el mejor sistema operativo, de presentar numerosos bugs y muchas limitaciones para realizar sobre él aplicaciones profesionales, el número de usuarios que emplean a Windows como sistema operativo se incrementa cada día por su interfaz amistosa, su amplio uso, compatibilidad y la gran cantidad de programas desarrollados sobre esta plataforma. Esto ha traído como consecuencia que la mayoría de los fabricantes de sistemas basados en PC lancen al mercado equipos con sus aplicaciones para Windows. La realización de las pruebas de esfuerzo de ECG requieren la recolección, visualización y procesamiento de hasta 12 derivaciones de ECG simultáneas en tiempo real. Por esa razón, nos propusimos desarrollar un procedimiento que permitiera la recepción a través de un puerto serie de las señales de ECG, su procesamiento y análisis en tiempo real en ambiente Windows. 2. METODOLOGÍA 2.1 Requerimientos del SW Fig.1. Partes componentes de un sistema electrocardiográfico basado en PC: Computadora, software analizador y Los requerimientos de la aplicación realizada hicieron necesario realizar la recolección y procesamiento de las señales en tiempo real. Un sistema de tiempo real es aquel cuya respuesta a variaciones en la entrada es suficientemente rápida en comparación con los requerimientos de trabajo del sistema. En el caso de un sistema para realización de pruebas de esfuerzo (o ergométricas), la respuesta del sistema puede demorarse ocasionalmente hasta 8 a 12 ms sin que sea perceptible para el usuario (médico que realiza la prueba), pero es conveniente que sea menor que 4 ms, que es el intervalo de muestreo.

2 Las posibles soluciones de software deben asegurar el procesamiento de un volumen considerable de información que implica la realización de las siguientes tareas: Recogida de información: por puerto serie a una velocidad de baud para recibir 8 canales de ECG muestreados a 250 Hz, con 12 bits de resolución, en forma de paquetes con chequeo de suma. De esta forma se cumple con las recomendaciones de la American Heart Association para prueba de esfuerzo[1]. Mostrar por pantalla informaciones de la prueba: incluye la forma de onda de un grupo de canales y otros parámetros numéricos y gráficos. Identificación de ondas del ECG: complejos QRS, complejos atípicos, etc. Medición de ondas y parámetros: amplitudes e intervalos dentro de los complejos QRS, frecuencia cardiaca (FC), etc. Clasificación de complejos, comparación por correlación y promediación. Control general de la prueba: tiempo por etapa y total según el protocolo. Control de periféricos: manejo del equipo para la realización del ejercicio físico. Chequeo de condiciones peligrosas y emisión de alarmas: arritmias, EV, variaciones de la FC, etc. El sistema realiza otras tareas que no requieren de respuesta en tiempo real, como son las tareas antes de la recogida de información, la elaboración y emisión de reportes y las tareas asociadas al manejo de la información resultante de las pruebas. 2.2 Alternativas de diseño Para la implementación del sistema se evaluaron dos soluciones posibles para realizar la recogida de información: Desarrollo y uso de un Virtual Device Driver: Un Virtual Device Driver (o VxD) es una rutina o un conjunto de rutinas que implementan operaciones de entrada/salida de forma específica para un dispositivo. Cuando se tiene un dispositivo para el cual Windows no posee un VxD se hace necesario buscar o escribir uno, pero este no es el caso de los puertos de comunicación. La atención a los mismos se realiza por la API Win32, en modo Kernel lo que provee el acceso más privilegiado a los recursos del sistema [6]. Por esto desechamos esta alternativa, ya que las funciones que brinda el sistema le son necesarias para garantizar la seguridad y la estabilidad de su funcionamiento. Uso de la API Win32: Las Application Programming Interface (API) Win32 define un conjunto de funciones que intercambian información con el sistema operativo que los programas de aplicación pueden usar para llevar a cabo su trabajo. La información vinculada con sus características y formas de utilización aparecen en la documentación que brinda Microsoft para programadores especializados en Windows, llamada Microsoft Software Development Network (o MSDN). Microsoft ha implementado la API Win32 para cada uno de sus variantes de Windows. De esta forma cada sistema operativo es optimizado para cada situación en específico[2]. Por tanto una de las ventajas de desarrollar una aplicación bajo los requisitos de la API Win32 es que esta aplicación podrá ser ejecutada sobre cualquier sistema operativo que se adhiera a esta normativa (Windows NT/2000, Windows 95/98/Me). La Win32 consta de alrededor de 300 funciones que proveen todos los servicios que el usuario espera en un sistema operativo multitarea. Entre ellos: asignación de memoria, acceso a ficheros y dispositivos de entrada/salida, control, sincronización y comunicación entre hilos de una aplicación, etc. [4]. Es por eso que se ha incrementado el uso de Win32 para el desarrollo de aplicaciones en tiempo real [3]. 2.3 Uso de la API Win32 Existen dos formas de realizar la lectura de los datos del puerto serie: encuestar el puerto continuamente chequeando que haya llegado la cantidad de bytes que forman el paquete, o mandar a leer todos los bytes del paquete y esperar hasta que se reciba el paquete totalmente o salga por timeout. Luego de varias pruebas nos decidimos por la segunda variante, ya que la primera ocupa mucho tiempo del procesador en vano, necesario para acometer todas las tareas descritas en 2.1. Para implementar la solución de lectura por paquetes se emplearon varias funciones de la API Win32 para lograr dos objetivos: Utilizar el Timer Multimedia para darle el control a una rutina cada un cierto tiempo. El Timer Multimedia permite interrumpir cualquier otra tarea que se esté ejecutando. Realizar la lectura del bloque de información en el puerto serie y colocar la información recibida en una cola para su posterior procesamiento en el procedimiento principal de la aplicación. Teniendo en cuenta que la señal es digitalizada empleando una determinada frecuencia de muestreo, se tomó el intervalo de muestreo como intervalo para que sea invocada la rutina Timer donde ser realiza la lectura del puerto serie. Un diagrama de flujo del método utilizado se muestra en la figura 2 y es descrito a continuación Abrir y configurar el puerto serie El puerto serie seleccionado para la comunicación entre el electrocardiógrafo y la PC se abre y se configura definiendo velocidad de transmisión, bits de inicio, bits de parada, paridad, etc. Para ello se usaron las siguientes funciones: CreateFile: Crea o abre el dispositivo de comunicación. SetupComm: Fija tamaño de los buffers de entrada y salida. El tamaño del buffer de entrada utilizado fue de 1024 bytes. Ello se debe a que cuando se programa el Timer, llegan un número elevado de bytes que no se emplean, pero que si se pierden dificultan la sincronización inicial con el Getcommstate: Llena una estructura (DCB) con las especificaciones del puerto seleccionado. SetCommstate: Configura el puerto seleccionado en cuanto a velocidad de transmisión, bits de inicio, bits de parada y paridad.

3 Abrir y configurar puerto serie Elevar prioridad aplicación Establecer protocolo inicial con electrocardiógrafo La combinación de las prioridades de la aplicación y del hilo determina la prioridad base del hilo en ejecución. Para elevar la prioridad de la aplicación se utilizó la combinación de HIGH como prioridad de la aplicación y TIME_CRITICAL como prioridad del hilo principal de la aplicación. Aunque a primera vista parece obvio el uso de la prioridad REALTIME, esta no se puede usar en este caso pues con ella la aplicación no puede recibir los eventos del teclado y del mouse. 1 er paquete recibido SI Activar Multimedia Timer Procesar y analizar señal Fin de la prueba SI Desactivar Multimedia Timer Terminar intercambio de información Restaurar prioridad aplicación NO NO Establecer protocolo inicial con el Realiza el intercambio de comandos inicial entre el electrocardiógrafo y la PC. Para el envío y recepción de comandos/datos por el puerto serie deben utilizarse las funciones: Readfile: Lee n datos del puerto seleccionado. Writefile: Escibe datos en el puerto seleccionado Verificar recepción del primer paquete de datos La recepción del primer paquete de datos permite la sincronización entre el electrocardiógrafo y la función que realiza la lectura de los datos del puerto Activar el Timer Multimedia Una vez que llega el primer paquete de datos se activa el Timer Multimedia utilizando la función TimeSetEvent que hace que se ejecute una función callback que es la rutina que realiza la lectura del paquete de datos del puerto serie. El intervalo fijado fue de 4 ms, el cual coincide con el intervalo de muestreo de las señales analógicas del ECG. Para que la interrupción se realice con la mayor precisión posible, se utilizó la resolución de 0 para el Timer Multimedia. Si los datos llegaron correctamente (cantidad de bytes y checksum), se ponen en una cola para su procesamiento por parte del hilo principal de la aplicación. Si hubo algún error en la transmisión, se pone en la cola la última muestra correcta, minimizando los efectos negativos de la pérdida de información Procesar y analizar la señal recibida Cerrar puerto serie Fig.2. Diagrama de flujo del método propuesto Elevar la prioridad de la aplicación La API Win32 ofrece funciones que permiten variar la prioridad de una aplicación y de un hilo de ejecución dentro de ella. Utilizando la función SetPriorityClass se puede definir la prioridad de una aplicación como: HIGH, IDLE, NORMAL y REALTIME. Con la función SetPriorityThread se puede definir la prioridad de un hilo como: ABOVE_NORMAL, BELOW_NORMAL, HIGHEST, IDLE, LOWEST, NORMAL y TIME_CRITICAL. El procesamiento y análisis de la señal se organizó de forma tal que el sistema responda en tiempo real. Las tareas del sistema se ordenaron por prioridades y se dividieron en pequeñas sub-tareas para lograr que su ejecución no demorase la atención de tareas más prioritarias. El empleo de una cola para almacenar los datos de entrada permite que ocasionalmente el procesamiento de las muestras pueda demorar más tiempo que el previsto sin pérdida de información, e independiza la recepción de los datos del algoritmo de análisis. El tamaño de esta cola se fijó de acuerdo con las características de la aplicación y su procedimiento de análisis Desactivar el Timer Una vez que finaliza la prueba, se desactiva el Timer Multimedia. Para ello se utiliza la función TimeKillEvent.

4 2.3.8 Terminar intercambio de información con el Se intercambian comandos para finalizar la transmisión de datos Restaurar la prioridad de la aplicación Una vez finalizada la transmisión no es necesario que la aplicación monopolice el control del procesador, por lo que se restaura la prioridad de la aplicación y de su hilo principal a NORMAL Cerrar el puerto serie El puerto serie debe ser liberado mediante la función Closehandle. 3. RESULTADOS Y DISCUSIÓN El software descrito en el trabajo fue programado en Borland Delphi 5.0. El mismo ha sido probado rigurosamente durante un año en el ICID y está en proceso de evaluación por la firma productora del electrocardiógrafo ECG-310B, Dr. Lee Co. Ltd. de Corea del Sur. Este trabajo es el resultado del esfuerzo conjunto para desarrollar un sistema electrocardiográfico basado en PC para prueba de esfuerzo. Las condiciones de prueba fueron las siguientes: Ejecutándose como única aplicación abierta, con diferentes arquitecturas compatibles con IBM, apreciándose un buen desempeño en computadoras con microprocesadores Pentium. Sin embargo, en las pruebas realizadas en PCs con microprocesadores 486, se produjeron pérdidas visibles en la adquisición de los datos por la limitada capacidad de procesamiento. Ejecutándose sobre PC con microprocesadores Pentium mientras con varias aplicaciones en ejecución, obteniéndose buenos resultados. En estas condiciones solo se observaron algunos problemas cuando se ejecutó el software con antivirus residentes, detectándose la pérdida de algunos paquetes de información, aunque el efecto visual no es perceptible. El criterio asumido para evaluar los resultados fue calificarlo de buenos resultados en las pruebas donde el programa no pierde el control, no hay perdida aparente de datos para el usuario y la pérdida si la hay no compromete el funcionamiento del sistema desde el punto de vista médico. En conveniente destacar las imprecisiones potenciales de la evaluación ya que aun en condiciones controladas no se puede garantizar el conocimiento de todas las tareas que Windows está ejecutando simultáneamente con el programa sometido a prueba. que forma parte de un sistema para la automatización y control de la prueba de esfuerzo denominado EXECG-100. El método empleado proporciona una total independencia entre la adquisición de los datos y su procesamiento simultáneos, dándole además al algoritmo de análisis la posibilidad de demorarse en su ejecución ocasionalmente un tiempo mayor que el tiempo entre la toma de muestras, haciendo uso de las funciones que ofrece la API Win32 para la comunicación serie y la prioridad de la aplicación. El uso de la API Win32 también asegura la compatibilidad de la aplicación con Windows NT/2000, Windows 95/98/Me. No obstante haberlo desarrollado para una aplicación específica, se considera que el algoritmo puede ser usado en otras aplicaciones para la recolección de señales biomédicas. REFERENCIAS [1] J. J. Bailey et al, Recommendations for Standardization and Specifications in Automated Electrocardiography: Bandwidth and Digital Signal Processing. A report for Health Professionals by an Ad Hoc Writing Group of the Committe on Electrocardiography and Cardiac Electrophysiology of the Council on Clinical Cardiology, American Heart Association, Circulation, vol 81, p , [2] M. Pietrek, Which Win32 is for you?, PC Magazine Vol 13, n16, p [3] R. M. Smith, Win32 driving real-time applications, Electronics engineering times, n895, p62, [4] X. Teixeira, J. Pacheco, Delphi 5 Developer s Guide, Sams Publishing, [5] W. Tompkins, Biomedical Digital Signal Processing: C-language examples and laboratory experiments for the IBM PC, Prentice Hall, [6] NT drivers FAQ- Basics: Kernel Mode Systems, 4. CONCLUSIONES Como resultado de este trabajo se obtuvo una solución robusta y segura para la comunicación serie entre un electrocardiógrafo comercial y una microcomputadora tipo PC

5 USE OF WIN32 API FOR THE CONTROL OF SERIAL COMMUNICATION IN A STRESS TEST SYSTEM ABSTRACT In this work the authors explain a procedure to control the serial communication between a commercial electrocardiograph and a personal computer in a system for automated and control of stress test named EXECG The proposed method employs the tools contained in Microsoft s Win32 API for serial communication and control of the application s priorities. It allows the acquisition of data and its real-time processing. It has been used for more than a year with satisfactory results. It has been tested on different IBM-compatibles architectures showing its applicability on Pentium-powered same or superior motherboards. Working test were realized executing EXECG-100 with other applications, obtaining good results. Some problems were detected only when use resident antivirus software. The solutions obtained can be applied to monitor any biomedical signal and are valid for any Windows platform. Keywords: serial port communication, Win32, biosignal monitoring, ECG stress test, Windows.