WPSTR by CACIC2013

IV WORKSHOP PROCESAMIENTO DE SEÑALES Y SISTEMAS DE TIEMPO REAL - WPSTR -

XIX Congreso Argentino de Ciencias de la Computación - CACIC 2013 : Octubre 2013, Mar del Plata, Argentina : organizadores : Red de Universidades con Carreras en Informática RedUNCI, Universidad CAECE / Armando De Giusti ... [et.al.] ; compilado por Jorge Finochietto ; ilustrado por María Florencia Scolari. - 1a ed. - Mar del Plata : Fundación de Altos Estudios en Ciencias Exactas, 2013. E-Book. ISBN 978-987-23963-1-2 1. Ciencias de la Computación. I. De Giusti, Armando II. Finochietto, Jorge, comp. III. Scolari, María Florencia, ilus. CDD 005.3 Fecha de catalogación: 03/10/2013

AUTORIDADES DE LA REDUNCI Coordinador Titular De Giusti Armando (UNLP) 2012-2014 Coordinador Alterno Simari Guillermo (UNS) 2012-2014 Junta Directiva Feierherd Guillermo (UNTF) 2012-2014 Padovani Hugo (UM) 2012-2014 Estayno Marcelo (UNLZ) 2012-2014 Esquivel Susana (UNSL) 2012-2014 Alfonso Hugo (UNLaPampa) 2012-2013 Acosta Nelson (UNCPBA) 2012-2013 Finochietto, Jorge (UCAECE) 2012-2013 Kuna Horacio (UNMisiones) 2012-2013 Secretarias Secretaría Administrativa: Ardenghi Jorge (UNS) Secretaría Académica: Spositto Osvaldo (UNLaMatanza) Secretaría de Congresos, Publicaciones y Difusión: Pesado Patricia (UNLP) Secretaría de Asuntos Reglamentarios: Bursztyn Andrés (UTN)

AUTORIDADES DE LA UNIVERSIDAD CAECE Rector Dr. Edgardo Bosch Vicerrector Académico Dr. Carlos A. Lac Prugent Vicerrector de Gestión y Desarrollo Educativo Dr. Leonardo Gargiulo Vicerrector de Gestión Administrativa Mg. Fernando del Campo Vicerrectora de la Subsede Mar del Plata: Mg. Lic. María Alejandra Cormons Secretaria Académica: Lic. Mariana A. Ortega Secretario Académico de la Subsede Mar del Plata Esp. Lic. Jorge Finochietto Director de Gestión Institucional de la Subsede Mar del Plata Esp. Lic. Gustavo Bacigalupo Coordinador de Carreras de Lic. e Ing. en Sistemas Esp. Lic. Jorge Finochietto

COMITÉ ORGANIZADOR LOCAL Presidente Esp. Lic. Jorge Finochietto Miembros Esp. Lic. Gustavo Bacigalupo Mg. Lic. Lucia Malbernat Lic. Analía Varela Lic. Florencia Scolari C.C. María Isabel Meijome CP Mayra Fullana Lic. Cecilia Pellerini Lic. Juan Pablo Vives Lic. Luciano Wehrli

Escuela Internacional de Informática (EII) Directora Dra. Alicia Mon Coordinación CC. María Isabel Meijome

comité académico Universidad

Representante

Universidad de Buenos Aires

Echeverria, Adriana (Ingeniería) – Fernández

Universidad Nacional de La Plata

Slezak, Diego (Cs. Exactas)

Universidad Nacional del Sur

De Giusti, Armando

Universidad Nacional de San Luis

Simari, Guillermo

Universidad Nacional del Centro de la

Esquivel, Susana

Provincia de Buenos Aires

Acosta, Nelson

Universidad Nacional del Comahue

Vaucheret, Claudio

Universidad Nacional de La Matanza

Spositto, Osvaldo

Universidad Nacional de La Pampa

Alfonso, Hugo

Universidad Nacional Lomas de Zamora

Estayno, Marcelo

Universidad Nacional de Tierra del Fuego

Feierherd, Guillermo

Universidad Nacional de Salta

Gil, Gustavo

Universidad Nacional Patagonia Austral

Márquez, María Eugenia

Universidad Tecnológica Nacional

Leone, Horacio

Universidad Nacional de San Juan

Otazú, Alejandra

Universidad Autónoma de Entre Ríos

Aranguren, Silvia

Universidad Nacional Patagonia San Juan

Buckle, Carlos

Bosco Universidad Nacional de Entre Ríos

Tugnarelli, Mónica

Universidad Nacional del Nordeste

Dapozo, Gladys

Universidad Nacional de Rosario

Kantor, Raúl

Universidad Nacional de Misiones

Kuna, Horacio

Universidad Nacional del Noroeste de la

Russo, Claudia

Provincia de Buenos Aires Universidad Nacional de Chilecito

Carmona, Fernanda

Universidad Nacional de Lanús

García Martínez, Ramón

comité académico Universidad

Representante

Universidad Nacional de Santiago del Estero

Durán, Elena

Escuela Superior del Ejército

Castro Lechstaler Antonio

Universidad Nacional del Litoral

Loyarte, Horacio

Universidad Nacional de Rio Cuarto

Arroyo, Marcelo

Universidad Nacional de Córdoba

Brandán Briones, Laura

Universidad Nacional de Jujuy

Paganini, José

Universidad Nacional de Río Negro

Vivas, Luis

Universidad Nacional de Villa María

Prato, Laura

Universidad Nacional de Luján

Scucimarri, Jorge

Universidad Nacional de Catamarca

Barrera, María Alejandra

Universidad Nacional de La Rioja

Nadal, Claudio

Universidad Nacional de Tres de Febrero

Cataldi, Zulma

Universidad Nacional de Tucumán

Luccioni, Griselda

Universidad Nacional Arturo Jauretche

Morales, Martín

Universidad Nacional del Chaco Austral

Zachman, Patricia

Universidad de Morón

Padovani, Hugo René

Universidad Abierta Interamericana

De Vincenzi, Marcelo

Universidad de Belgrano

Guerci, Alberto

Universidad Kennedy

Foti, Antonio

Universidad Adventista del Plata

Bournissen, Juan

Universidad CAECE

Finochietto, Jorge

Universidad de Palermo

Ditada, Esteban

Universidad Católica Argentina - Rosario

Grieco, Sebastián

Universidad del Salvador

Zanitti, Marcelo

Universidad del Aconcagua

Gimenez, Rosana

Universidad Gastón Dachary

Belloni, Edgardo

Universidad del CEMA

Guglianone, Ariadna

Universidad Austral

Robiolo, Gabriela

comité científico Coordinación Armando De Giusti (UNLP) - Guillermo Simari (UNS) Abásolo, María José (Argentina) Acosta, Nelson (Argentina) Aguirre Jorge Ramió (España) Alfonso, Hugo (Argentina) Ardenghi, Jorge (Argentina) Baldasarri Sandra (España) Balladini, Javier (Argentina) Bertone, Rodolfo (Argentina) Bría, Oscar (Argentina) Brisaboa, Nieves (España) Bursztyn, Andrés (Argentina) Cañas, Alberto (EE.UU) Casali, Ana (Argentina) Castro Lechtaller, Antonio (Argentina) Castro, Silvia (Argentina) Cechich, Alejandra (Argentina) Coello Coello, Carlos (México) Constantini, Roberto (Argentina) Dapozo, Gladys (Argentina) De Vicenzi, Marcelo (Argentina) Deco, Claudia (Argentina) Depetris, Beatriz (Argentina) Diaz, Javier (Argentina) Dix, Juerguen (Alemania) Doallo, Ramón (España) Docampo, Domingo Echaiz, Javier (Argentina) Esquivel, Susana (Argentina) Estayno, Marcelo (Argentina) Estevez, Elsa (Naciones Unidas) Falappa, Marcelo (Argentina) Feierherd, Guillermo (Argentina) Ferreti, Edgardo (Argentina) Fillottrani, Pablo (Argentina) Fleischman, William (EEUU) García Garino, Carlos (Argentina) García Villalba, Javier (España) Género, Marcela (España) Giacomantone, Javier (Argentina) Gómez, Sergio (Argentina) Guerrero, Roberto (Argentina) Henning Gabriela (Argentina)

Janowski, Tomasz (Naciones Unidas) Kantor, Raul (Argentina) Kuna, Horacio (Argentina) Lanzarini, Laura (Argentina) Leguizamón, Guillermo (Argentina) Loui, Ronald Prescott (EEUU) Luque, Emilio (España) Madoz, Cristina (Argentina) Malbran, Maria (Argentina) Malverti, Alejandra (Argentina) Manresa-Yee, Cristina (España) Marín, Mauricio (Chile) Motz, Regina (Uruguay) Naiouf, Marcelo (Argentina) Navarro Martín, Antonio (España) Olivas Varela, José Ángel (España) Orozco Javier (Argentina) Padovani, Hugo (Argentina) Pardo, Álvaro (Uruguay) Pesado, Patricia (Argentina) Piattini, Mario (España) Piccoli, María Fabiana (Argentina) Printista, Marcela (Argentina) Ramón, Hugo (Argentina) Reyes, Nora (Argentina) Riesco, Daniel (Argentina) Rodríguez, Ricardo (Argentina) Roig Vila, Rosabel (España) Rossi, Gustavo (Argentina) Rosso, Paolo (España) Rueda, Sonia (Argentina) Sanz, Cecilia (Argentina) Spositto, Osvaldo (Argentina) Steinmetz, Ralf (Alemania) Suppi, Remo (España) Tarouco, Liane (Brasil) Tirado, Francisco (España) Vendrell, Eduardo (España) Vénere, Marcelo (Argentina) Villagarcia Wanza, Horacio (Arg.) Zamarro, José Miguel (España)

IV Workshop Procesamiento de Señales y Sistemas de Tiempo Real - WPSTR -

Trabajo

Autores

5708

Determinación de modelos para el análisis del control y estabilidad de sistemas dinámicos

Carlos Alvarez Picaza (UNNE), María Ines Pisarello (UNNE), Jorge E. Monzón (UNNE)

5806

Framework para modelado de Transacciones en Sistemas de Bases de Datos de Tiempo Real

Carlos Buckle (UNPSJB), José M. Urriza (UNPSJB), Damián Pablo Barry (UNPSJB), Lucas Schorb (UNPSJB)

5607

Toolchain and workflow for the design of an ISO 11783-compatible ECU based on ISOAgLib

Joaquin Ezpeleta (UNR), Sebastian Rossi (UNR)

5842

Controlador neuronal incremental aplicado a un mezclador de flujos

Sergio L. Martínez (UNJu), Enrique E. Tarifa (UNJu), Samuel Franco Dominguez (UNJu)

5608

A Fault Resilience Tool for Embedded Real-Time Systems

Franklin Lima Santos (UFB), Flavia Maristela Santos Nascimento (IFBa)

5860

Application of Zigbee Technology for Monitoring Environmental Variables in Greenhouses

Juan Carlos Suárez Barón (UNAD)

5675

Inversión de prioridades: prueba de concepto y análisis de soluciones

Raúl Benencia (UNLP), Fernando Romero (UNLP), Fernando Tinetti (UNLP), Luciano Iglesias (UNLP)

5677

Estudio sobre mediciones de Campos Electromagnéticos No Ionizantes

Jorge S. García Guibout (UDA), Miguel Mendez Garabetti (UDA), Antonio Castro Letchtaler (IESE), Alfredo David Priori (UA)

IV Workshop Procesamiento de Señales y Sistemas de Tiempo Real - WPSTR -

Trabajo

Autores

5729

Selección sub-óptima del espectro asociado a la matriz de afinidad

Luciano Lorenti (UNLP), Lucía Violini (UNLP), Javier Giacomantone (UNLP)

5686

Isolated Spanish Digit Recognition based on Audio-Visual Features

Gonzalo Sad (UNR), Lucas Terissi (UNR), Juan Carlos Gómez (UNR)

5820

Desarrollo de una Ficha Anestésica Web en Áreas críticas

Gustavo Bianco (HIBA), Marcelo Sabalza (HIBA),Daniel Luna (HIBA), Gustavo Garcia Fornari (HIBA), Jorge Garbino (HIBA),Martin Waldhorn (HIBA), Estefanía Tarsetti (HIBA)

5856

Detección de signos respiratorios patológicos en poblaciones avícolas productivas mediante procesamiento digital de señales acústicas

César E. Martínez (UNL), Cristian Kühn (UNL)

5649

Sievert-type measurement and acquisition system for the study of hydrogen storage in solids

Jorge Runco (UNLP),Marcos Meyer (UNLP)

Determinación de modelos para el análisis del control y estabilidad de sistemas dinámicos Carlos Álvarez Picaza1, María Inés Pisarello1, Jorge E. Monzón1 1

Dpto de Ingeniería. Fac de Ciencias Exactas. Universidad Nacional del Nordeste Corrientes, Argentina cpicaza@gmail.com

Abstract. Los modelos aquí presentados analizan las condiciones de control y estabilidad de dos sistemas dinámicos de distinta naturaleza, uno eléctrico y otro biomédico. Los modelos son desarrollados en el espacio de estados, lo que aporta nuevas respuestas al análisis de sistemas. Keywords: espacio de estados, controlabilidad, estabilidad.

1 Introducción La Teoría de Control Clásico describe al sistema dinámico a través de la relación matemática entre la entrada y la salida, o sea su función transferencia, considerando en general a este sistema dinámico como una “caja negra”. Esto se muestra en la Fig 1, en la cual se observa que a través de la inyección de diferentes tipos de señales a la entrada de la caja negra se obtiene un conjunto de señales a la salida de la misma, lo que nos permite conocer el comportamiento del sistema dinámico y así definir las propiedades de este sistema [1]. Entonces a partir de estos ensayos es posible establecer una relación matemática de la función de transferencia del sistema en cuestión, dado por:

g(t)=

y(t) u(t)

(1)

Fig. 1. Modelo general de caja negra

1333

Normalmente los análisis de datos se realizan desde el punto de vista gráfico en el espacio de los tiempos y en el espacio de las frecuencias, mediante la utilización de la función transferencia correspondiente. Lo que permite la Teoría de Control Moderno es el análisis en otro contexto gráfico conocido como “espacio de estados”, a partir del cual, se puede inferir nueva información [1,2]. Espacio de Estado: Es el espacio n-dimensional cuyos ejes de coordenadas están formados por el eje x1, eje x2, … , eje xn, donde x1, x2, … ,xn son las variables de estado. Cualquier estado se puede representar como un punto en el espacio de estados. 

x( t )  Ax( t )  Bu( t )

Ec. de Estado

y( t )  Cx( t )  Du( t )

Ec. de Salida

donde A se denomina matriz de estado, B matriz de entrada, C matriz de salida y D matriz de transmisión directa.

Fig. 2. Diagrama en bloque del sistema de control en el espacio de estados. El objetivo de este trabajo es determinar el comportamiento de dos sistemas de distinta naturaleza, uno biomédico (sistema cardiovascular) y otro eléctricoelectrónico (turbina eólica) mediante el análisis de sus funciones de transferencia, es decir sus señales de entrada y salida. Para ello diseñamos un modelo de tipo caja negra en el espacio de estados.

2 Métodos Utilizaremos el modelado en el espacio de estados aplicado a señales de una turbina eólica (energías renovables) y de un electrocardiograma (biomédica).

1334

La señal de entrada para un sistema de control no se conoce con anticipación, pero es de naturaleza aleatoria, y la entrada instantánea no puede expresarse en forma analítica. Solo en algunos casos especiales se conoce con anticipación la señal de entrada y se puede expresar en forma analítica o mediante curvas [3]. En el análisis y diseño de sistemas de control, debemos tener una base de comparación del desempeño de algunos. Esta base se configura especificando las señales de entrada de prueba particulares y comparando las respuestas de varios sistemas a estas señales de entrada. Muchos criterios de diseño se basan en tales señales o en la respuesta del sistema a los cambios en las condiciones iniciales (sin señales de prueba). El uso de señales de prueba se justifica porque existe una correlación entre las características de respuesta de un sistema para una señal de entrada de prueba común y la capacidad del sistema de manejar las señales de entrada reales. Señales de prueba típicas. Las señales de prueba que se usan regularmente son funciones escalón, rampa, parábola, impulso, senoidales, etc. Con estas señales de prueba, es posible realizar con facilidad análisis matemáticos y experimentales de sistemas de control, dado que las señales son funciones del tiempo muy simples [3].

2.1 Aerogenerador: Debido a la complejidad del modelo del generador de inducción, el principio del proceso de auto-excitación se explica con el uso de un circuito RLC debido a que el comportamiento del generador de inducción es similar a un circuito de este tipo [4].

Fig. 3. Modelo para representación en el espacio de estados del generador

Donde R representa la resistencia equivalente rotórica y estatórica, L los devanados de estator y C, un banco de capacitares reemplazando a la tensión de línea. Para el modelo objeto de tratamiento la función transferencia es

1 E (s) LC  0 G ( s)  1 R Ei ( s ) s2  s  L LC

(2)

1335

Para definir las variables de estado 

R  1 1 . eo  .eo  .ei L LC LC x1  eo

eo 

(3) (4)



x2  eo

(5)

y las variables de entrada y salida mediante

u  ei y  eo  x1

(6) (7)

Matricialmente, queda planteada la siguiente ecuación de estado

.   0  x1    1 .    x2   LC

1   0   x1     R  .     1  .u  x2  L   LC  x  y  1 0 .  1   x2  u

1 LC



x2 



(8)

(9)



x1  y

R L 1 LC

Fig. 4. Diagrama en bloques funcional del aerogenerador representado en el espacio de estados

2.2 Pared Cardíaca: En este trabajo modelamos la dinámica cardíaca utilizando un modelo de Windkessel de tres elementos. El modelo fue elaborado en el espacio de estados. Este enfoque nos permite obtener resultados acerca de la estabilidad del sistema [5].

1336

Fig. 6. - Modelo Windkessel de 3 elementos El modelo consiste en una conexión paralela de una resistencia y un capacitor. La resistencia Rp representa la resistencia total periférica y el capacitor C representa la compliancia de los vasos. Otro elemento resistivo entre la bomba y la cámara de aire, Rc, simula la resistencia del flujo sanguíneo debido a la válvula aórtica o pulmonar. L es un elemento inercial en paralelo con la resistencia característica, Rc. Con estos arreglos, el modelo cuenta con la inercia de todo el sistema arterial a bajas frecuencias y a altas y medias frecuencias permiten que intervenga la resistencia característica [6]. Generalizando Rp = R y Rc muy pequeña, para el modelo objeto de tratamiento es

1 E (s) LC G(s)   0 1 1 Ei ( s ) s2  s RC LC

(10)

obteniendo

s 2 .E0 ( s)  s.E0 ( s ).

1 1 1  E0 ( s).  Ei ( s). RC LC LC

(11)

para definir las variables de estado 

eo 

1  1 1 . eo  .eo  .ei RC LC LC

(12)

Quedando planteada la siguiente ecuación de estado

 .   0  x1    1  .    x2   LC

1   0   x1    1  .     1  .u  x2  RC   LC 

x  y  1 0 .  1   x2 

(13)

(14)

1337

Teniendo en cuenta estos conceptos, el objetivo de este trabajo es aplicar las ecuaciones de estado a los distintos sistemas para el modelado correspondiente y posterior análisis de controlabilidad.

Fig. 7. Diagrama en bloques funcional de la pared cardíaca representada en el espacio de estados

3. Resultados y Discusión 31. Aerogenerador De acuerdo a datos de ensayos en cortocircuito realizado a un generador de 5 KVA y considerando el condensador para estabilizar a la salida, se obtiene Tabla 1. Características eléctricas del sistema generador XL (ohm)

R (ohm)

C (uF)

Sigma

1,5

0,55

Donde las curvas corresponden a la variación de x1 y la variación de x2 (variables de estado).

3.2 Pared Cardíaca Tabla 2. Características funcionales del sistema pared cardíaca Señal

PS (mmHg)

PD (mm Hg)

L (PS-PD)

a41770

93,28

57,12

36,16

C (e-4cm/mm HG) 7,09

Las curvas correspondientes a estos resultados están definidas en las Fig 8 a 11.

1338

3.3 Controlabilidad y Estabilidad La controlabilidad es una de las propiedades cualitativas de los sistemas dinámicos. A grandes rasgos, la controlabilidad estudia la posibilidad de guiar o llevar los estados de un sistema hacia una posición deseada mediante la señal de entrada [6]. Dada una matriz de Controlabilidad genérica

C = éêëB AB A 2 B ... A n-1Bùûú (15) Si el rango de C = n  Existe una entrada que hace que el sistema pase de cualquier estado inicial al estado final deseado. Señal Aerogenerador:

é 0 7.4074 ù ú C =ê êë 7.4074 - 2.7163 úû D = - 54.8697 , rango = 2 l m in = - 8.889 l m ax = 6.1728 cond (C ) » - 0.6944 0.6944 G ´(s) = 2 s + 0.3667 s + 0.6944 La Fig. 8 muestra el efecto de la condición de control, aplicada al sistema, indicando una disminución del valor de la frecuencia natural del sistema para nuevos valores de entrada (x1c y x2c). De acuerdo a los polos de la nueva función transferencia, el sistema se hace mas amortiguado, lo que conlleva a una mas rápida estabilidad al nivel 0. Señal Pared Cardíaca:

é 0 0.0039 ù ú C =ê êë 0.0039 -0.0005úû D = -1.5214*105 , rango = 2 lmin = -0.0042 lmax = 0.0036 cond (C ) » -0.8571 0.8571 G´ ( s ) = 2 s + 0.1370s + 0.8571

1339

x1 2 Variables de Estado x1 y x2

Variables de estado x1 y x2

x1c

x1c 0

x2c

-2

-4

-6 x2

x2 -8

15 t mseg

t m seg Fig. 8 –Respuesta natural del sistema generador incluyendo la condición de control

2 1.8 1.6

Transición con control

1.4

Transición con Control 1.2

Transición Normal

1 0.8 0.6 0.4 0.2

Transición normal

0 3 2

1.5 1

1 0

0.5 -1

0 -2

-0.5 -3

-1 x1

Fig. 9. – Espacio de estados - Sistema Aerogenerador. 3D

1340

0.045 x1c

x1c

0.035

0.03

Variables de Estado x1 y x2

0.04

0.025 x1 0.02

x1 0.015

0.01

x2c

0.005

x2 x2c

-0.005

50 T = 1 latido

100

T=1 latido Fig. 10. Respuesta natural del sistema generador incluyendo la condición de control

La incorporación de la condición de control, produce en el sistema de estudio un aumento de la frecuencia natural del mismo, haciendo que el sistema alcance su equilibrio en un tiempo menor (hay que tener en cuenta que la frecuencia natural del sistema se encuentra acotada a 1 latido/seg.).

2 1.8 1.6 1.4

Transición normal

1.2

Transición Normal 1 0.8 0.6 0.4 Transición con Control

Transición con control

0.2 0 1 0.8

0.6

6 0.4

5 4

0.2

3 0

2 1

-0.2

0 -0.4

-1

Fig. 11. Espacio de estados - sistema pared cardíaca 3D

1341

4. Conclusiones El hecho de que al utilizar la condición de control, ambos sistemas acortan notablemente la trayectoria desde un estado genérico

1 x1    hacia el punto estable 1

0  x0    , es decir, al utilizar estas herramientas de control el sistema gana 0  estabilidad haciendo a “cualquier sistema” mas controlable y asegurando su convergencia a su estado de equilibrio.

Referencias 1. Ogata K.: Ingeniería de control Moderna. 4ta Edición Ed Pearson. ISBN: 84-205-3678-4. 2. Kuo B.: Sistemas de Control Automático. 7ma Edición Ed. Prentice Hall Hispanoamericana S.A. ISBN: 968-880-723-0. 3. Rautenberg C., D’Attellis C.: Control lineal Avanzado y Control Óptimo. 1era Edición Ed. Argentina-AADECA. ISBN: 987-20960-5253. 4. Henández Sanchez A.M.: Análisis, Modelado y Simulación de la Operación de Sistemas de Generación Eoleoeléctrica Basados en Generadores de Inducción de Tipo Jaula de Ardilla. Centro Nacional de Investigación y desarrollo Tecnológico. Méjico. 2008. 5. Monzón J.E., Álvarez Picaza C., Pisarello M.I.: A multiple-input multiple-output system for modeling the cardiac dinamycs. In: Proceedings of the 33th Annual International Conference of the IEEE-EMBS. 2011 6. Álvarez Picaza C., Pisarello M.I., Monzón J.E.: Modelado del Sistema Cardíaco en el Espacio de Estados aplicando Criterios de Controlabilidad. In: 1er Congreso de Bioingeniería Costa Rica 2009. San José de Costa Rica. 2009

1342

Framework para modelado de Transacciones en Sistemas de Bases de Datos de Tiempo Real Carlos E. Buckle, José M. Urriza, Damián P. Barry, Lucas Schorb Depto Informática, Facultad Ingeniería, Universidad Nacional de La Patagonia San Juan Bosco Puerto Madryn, Argentina +54 280-4472885 – Int. 117. cbuckle@unpata.edu.ar, josemurriza@unp.edu.ar, damian_barry@unpata.edu.ar .

Resumen. En los Sistemas de Bases de Datos de Tiempo Real, se requiere extender el modelo tradicional de transacciones para incorporar restricciones temporales. En este tipo de sistemas, una transacción se debe ejecutar dentro de un intervalo de tiempo específico, predeterminado con anterioridad. Además, se debe garantizar la validez de ciertos datos, cuyo valor caduca con el paso del tiempo. Los conceptos teóricos para modelado de transacciones de tiempo real, han sido desarrollados en varios trabajos del área. En este trabajo, se reúnen y exponen los conceptos principales en lo referido a consistencia temporal de datos y transacciones. Luego, se los incorpora a un framework orientado a objetos que guía y facilita el modelado de transacciones con restricciones de tiempo. El uso del framework se presenta y se verifica aplicándolo sobre un caso de ejemplo. Palabras Clave: Transacciones de Tiempo Real, Consistencia Temporal, Bases de Datos de Tiempo Real, Ingeniería de Software de Tiempo Real, Datos de Tiempo Real.

Introducción

El procesamiento de transacciones ([1]), es la técnica utilizada para el acceso concurrente, consistente y tolerante a fallas en un Sistema de Bases de Datos (DBS) convencional. Los Sistemas de Tiempo Real (RTS) que manejan datos persistentes sobre un DBS, imponen que el modelo de transacciones sea ampliado para considerar restricciones temporales. Por ejemplo, en sistemas de supervisión y monitoreo de procesos (SCADA), en tableros de comando (Balanced Scorecard), en ambientes de transacciones on-line de compra/venta de acciones bursátiles (Online Stock Trading), etc. Esta aproximación entre las disciplinas de DBS y RTS, ha dado origen a los Sistemas de Bases de Datos de Tiempo Real (RTDBS) ([2, 3]). Los cuales, además de administrar un gran volumen de datos convencionales, deben manejar datos que se encargan de reflejar el estado de elementos variables del ambiente. Estos datos, tienen como característica que su valor envejece, hasta perder vigencia una vez alcanzado su

1343

vencimiento (Datadeadline [4]). Por ese motivo, son identificados en el sistema como datos de tiempo real (RTD Real-Time Data). Mantener correctamente actualizados estos objetos, permite garantizar la consistencia entre el ambiente supervisado y el RTDBS. En este escenario, las transacciones además de garantizar consistencia lógica, deben garantizar consistencia temporal ([2]), dando origen a lo que se denomina transacciones de tiempo real (RTT) (Real-Time Transaction) ([5], [6]). Sobre ellas debe garantizarse: su instante mínimo de inicio (arrival time), su tiempo de respuesta previo al vencimiento (deadline) y la validez de los RTD involucrados. Estas consideraciones, introducen una complejidad adicional al momento de construir aplicaciones. Además de la lógica propia del dominio del problema a resolver, deben atenderse otras cuestiones como: la contabilización de tiempos, la validación de reglas y la planificación de tareas para garantizar la consistencia temporal de datos y transacciones. Surge así la necesidad de contar con herramientas que incorporen estos conceptos, orienten el modelado y aporten la información temporal necesaria para que el planificador del RTS pueda ordenar debidamente la ejecución de las transacciones. En el presente trabajo se presenta un framework orientado a objetos, para el modelado de RTT, como un aporte concreto para los diseñadores de RTDBS. Este documento está organizado de la siguiente manera: en la sección 2 se presentan trabajos anteriores relacionados con el modelado de RTDS. En la sección 3 se presenta un conjunto de definiciones y clasificaciones asociadas con el concepto de RTT. En la sección 4 se presenta el framework desarrollado. En la sección 5 se aplica el framework sobre un caso de estudio. En la sección 6 se elaboran las conclusiones y se plantean los trabajos a futuro.

Trabajos previos

En el pasado, se han desarrollado una serie de trabajos que apuntan a modelar objetos y transacciones dentro de un RTDBS. Uno de los trabajos más importantes en el modelado orientado a objetos es Real Time Semantic Objects Relationships And Constraints (RTSORAC) ([7]), en el cual se definen tres propiedades básicas de los RTDBS: objetos, relaciones y transacciones de tiempo real. El modelo teórico contempla la mayoría de los requerimientos temporales y permite expresar las diferentes entidades que intervienen en un RTDBS. Sin embargo, es demasiado extenso y genérico como para ser aplicado directamente en el diseño de aplicaciones concretas. No obstante, es utilizado en un conjunto de trabajos posteriores que lo utilizan como base para la definición de perfiles de diseño, como los presentados en [8] y [9]. Dichos trabajos, se enfocan preferentemente a la definición de objetos de tiempo real y no al modelado de transacciones. Tampoco se consideran objetos de cambio discreto ([10]), ni datos derivados (datos calculados). El patrón de diseño presentado en [11], incorpora el modelado de transacciones pero solo de aquellas encargadas de actualizar datos desde sensores. El marco de trabajo (framework) presentado en [12], clasifica aquellas transacciones que actualizan los datos desde

1344

sensores y aquellas que propagan derivaciones de los datos calculados, pero no incluye a las transacciones del usuario que resuelven la lógica de la aplicación. En lo que sigue, se presenta un framework orientado a objetos para el modelado de RTT, en el cual se consideran aspectos ampliados respecto de los trabajos antes mencionados. El framework presentado utiliza el Tipo de Dato Abstracto para Bases de Datos de Tiempo Real RTD ([13]), resultante de un trabajo anterior, el cual se toma como base y permite definir cualquier tipo de atributo de tiempo real encapsulando la validación de consistencia temporal.

Gestión de Transacciones con Restricciones Temporales

El modelo de RTT, puede definirse como una extensión del modelo tradicional de transacciones ([14]), el cual se resume brevemente a continuación: Un DBS es un conjunto de entidades de datos, que representan información sobre un contexto determinado. El mapeo entre entidades y sus valores, define el estado de la base de datos en un determinado instante. Sobre ella se definen un conjunto de operaciones que permiten recuperar, crear, modificar y eliminar entidades. Estas operaciones provocan la transición de un estado a otro. Una transacción, es un conjunto de operaciones parcialmente ordenadas sobre la base de datos que debe ser ejecutada atómicamente. El orden parcial de las operaciones está dado por un algoritmo. La atomicidad significa que la transacción debe ser ejecutada satisfactoriamente o sino no debe ser ejecutada. Para esto el DBS ofrece dos operaciones: commit, que confirma la finalización satisfactoria de una transacción y rollback, que deshace la ejecución parcial de operaciones realizadas por una transacción que no puede finalizar satisfactoriamente. La transacción pasa de un estado consistente de la base de datos, a un próximo estado consistente. La ejecución de las operaciones ordenadas de una transacción se asume correcta, si se ejecuta en forma aislada. El aislamiento, oculta los cambios parciales que realiza una transacción hasta su finalización. Si la transacción finaliza con commit se garantiza la durabilidad (persistencia) de los resultados en la base de datos. De esta forma se han definido las características ACID (atomicidad, consistencia, aislamiento y durabilidad). Sobre este modelo tradicional de transacciones, se puede incorporar la noción de tiempo real. Una transacción puede conocer el tiempo actual (now) accediendo a una entidad única del sistema llamada reloj (clock). Esta entidad es solo-lectura y toma valores positivos que se incrementan monotónicamente en concordancia con el paso del tiempo. Esto permite establecer intervalos de vigencia sobre los RTD y establecer restricciones temporales sobre las transacciones. Si una transacción no cumple estas restricciones temporales al momento del commit, se debe deshacer (rollback) y si corresponde, volverse a ejecutar (restart). 3.1

Consistencia Temporal de los Datos de Tiempo Real

Los RTD reflejan objetos cambiantes del ambiente. Existen dos tipos ([13]): Los RTDBase, los cuales reflejan el estado de un objeto externo y actualizan su valor desde sensores o publicadores y los RTDDerived que son datos derivados, cuyo valor se determina con cálculos sobre un Conjunto-Lectura (Read Set) con otros RTD.

1345

La consistencia temporal de los RTD garantiza: 

validez temporal: El valor de un RTD se considera válido dentro de un intervalo de validez, VI (validity interval). En el cual el límite inferior (VILB) es el momento en el que se actualiza el valor y el límite superior (VIUB) es el instante en el que el valor pierde vigencia (DataDeadline). Un RTD respeta consistencia temporal absoluta ([10]) en el instante t si VILBdtr (t )  now(t )  VIUBdtr (t ) .



coherencia temporal: Se debe garantizar que los datos calculados se deriven en base a los RTD actualizados en instantes cercanos de tiempo. Por esto, para los RTDDerived se debe garantizar consistencia temporal relativa ([10]) sobre todo su conjunto lectura, es decir, VI x (t ) x  ReadSet dtr    y su VI se calcula como: VILBdtr (t )  MaxVILBx (t ) x  ReadSet dtr  y VIUBdtr (t )  MinVIUBx (t ) x  ReadSet dtr 

Los RTDBase pueden ser continuos (RTDBaseContinuous) ó discretos (RTDBaseDiscrete). Los continuos, son actualizados con muestras periódicas y su VI depende de su edad (tiempo desde su última actualización). El vencimiento del dato se define en base a establecer la edad máxima (maximumAge) ([15]) y es posible garantizar la consistencia temporal absoluta, si se considera un período de actualización P ≤ maximumAge/2 ([4]). Estos conceptos se desarrollaron en la definición del tipo de dato abstracto RTD presentado en [13]. La actualización de los RTDBase puede implementarse utilizando dos políticas: actualización inmediata o a demanda ([16]). La actualización inmediata garantiza que cada cambio en un objeto externo será inmediatamente reflejado en el RTDBase que lo representa. La política de actualización a demanda, significa que el RTDBase será actualizado solo cuando una transacción necesite utilizarlo. La actualización inmediata procura un sistema más predecible, pero genera una carga innecesaria al actualizar valores de RTD que quizás no requiera ninguna transacción. La actualización a demanda soluciona este problema, pero introduce un tiempo de latencia en las transacciones pues deben actualizar los RTDBase antes de utilizarlos. 3.2

Características de las Transacciones de Tiempo Real.

Como fue presentado inicialmente, una RTT tiene las restricciones temporales propias: un tiempo mínimo de inicio (startTime) y un tiempo de respuesta anterior al vencimiento (deadline). Además, las RTT están condicionadas por la validez temporal de los RTD involucrados en ella. En un RTDBS se identifican tres clases de RTT:  RTT de Actualización de RTDBase (RTTUpdate): Son transacciones de soloescritura sobre un conjunto de RTDBase, llamado Write Set. El sistema debe implementarlas para garantizar la consistencia temporal absoluta de los objetos del Write Set.  RTT de Derivación de RTDDerived (RTTDerivation): Son transacciones de lectura sobre un Read Set de RTD y de escritura sobre un Write Set de RTD. El sistema debe implementarlas para garantizar el re-cálculo de datos derivados.

1346

 RTT del Usuario (RTTUsrApp): Implementan la lógica de la aplicación de usuario. Son transacciones de solo-lectura sobre un Read Set de RTD, aunque además, utilizan datos convencionales que no tienen restricciones de tiempo real. Dependiendo de la política de actualización de los RTDBase, las RTTUpdate se pueden implementar como transacciones independientes (en actualización inmediata), o como sub-transacciones de una RTTUsrApp (en actualización a demanda). Las transacciones independientes se deben planificar con un período P igual al menor período de los RTDBase en el Write Set. Su DataDeadline se puede calcular como el menor VIUB de dicho conjunto, generalmente como P*2 ([4]). Las RTTDerived pueden ser transacciones independientes o transacciones disparadas (triggered) por una RTTUpdate [16]. Si son independientes se debe planificar con un período P igual al menor período de los RTD en el Read Set. Su DataDeadline es el menor VIUB de todos los RTD incluidos en el Read Set. Cada RTT, independientemente de su clase, puede tener su propio requerimiento de tiempo de respuesta, por ende, debe poder indicarse un tiempo para el vencimiento (timeToDeadline) propio de la transacción. Si no se explicita un timeToDeadline se puede considerar como máximo un timeToDeadline = P (período de la RTT). Para que sea posible la planificación, también es necesario poder estimar el peor caso de tiempo de ejecución de cada transacción (Worst Case Execution Time – WCET). 3.3

Planificación de Transacciones

Para garantizar las restricciones temporales mencionadas, es necesario que el RTDBS cuente con un planificador de tiempo real (real-time scheduler) que ordene la ejecución concurrente de transacciones. Para que esto sea posible, se debe manejar un conjunto de atributos y medidores de performance de cada RTT. Mínimamente se requiere:          

arrivalTime: Instante en que la RTT se pone lista para ejecutar. startTime: Instante en que la RTT comienza a ejecutar. WCET. Worst case execution time: Tiempo máximo de ejecución estimado. period: Magnitud del período, para aquellas RTT de ejecución periódica. timeToDeadline: lapso de tiempo para el deadline. deadline: vencimiento de la RTT= (arrivalTime + timeToDeadline). dataDeadline(t): Menor DataDeadline de los RTD del Read Set al instante t. estRemaining(t): lapso de ejecución remanente de la RTT al instante t. estCompletionTime(t): Instante estimado de fin en t = (t + estRemaining(t)). estSlack(t): lapso que se puede retrasar = deadline – estCompletionTime(t).

En función de algunos de estos parámetros, el planificador de tiempo real debe determinar en cada instante t de planificación la prioridad de la RTT.  priorityrtt(t): prioridad de la RTT en el instante t.

1347

El algoritmo de planificación, debe garantizar que las RTT del sistema se ejecuten antes de su deadline y que cumplan con las reglas de consistencia temporal. Para esto se debe implementar una política de planificación. Algunas de las posibles son:      

Rate Monotonic (RM) ([17]): Prioridad basada en la magnitud del período. Earliest-Deadline-First (EDF) ([17]): Prioridad basada en el deadline. Earliest-DataDeadline-First (EDDF) ([4]): Prioridad basada en el dataDeadline. Highest-Value-First (HVF) ([18]): Prioridad basada en el la función valor (Fig. 1). Least-Slack-First (LSF)([5]): Prioridad basada en el tiempo disponible (estSlack). Shortest-Job-First (SJF): Prioridad basada en el tiempo que resta (estRemaining).

Estas políticas se pueden mejorar con el agregado de los conceptos de función valor y espera inducida. Estos se describen en los siguientes párrafos. Las RTT pueden tener diferentes niveles de criticidad en su vencimiento. Estos niveles de criticidad, influyen en las decisiones del planificador, el cual puede considerar el concepto de Función Valor introducido por Jensen en [18]. La función valor de una transacción permite medir el valor (ganancia) del sistema si finaliza la transacción en un determinado instante t. Los valores positivos son deseables y los negativos indeseables. Esta función valor presenta una discontinuidad en el vencimiento de la transacción, dependiendo de la cual se identifican vencimientos duros (hard-real-time), blandos (soft-real-time) o firmes (firm-real-time) (Figura 1).

Figura 1. Función Valor.

Una decisión posible para el sistema, es que si al momento de fin de la RTT se obtiene una función valor negativa se debe deshacer la transacción (rollback). Por otro lado, tampoco es posible finalizar satisfactoriamente una transacción cuyo DataDeadline expira antes que sea posible realizar el commit. Si se puede calcular el parámetro estCompletionTime(t) de una RTT, entonces es posible predecir si se podrá alcanzar el commit antes de que expire el intervalo de validez de los RTD. Si esto no es posible, el planificador puede analizar la posibilidad de retardar la transacción hasta que sus RTD se actualicen nuevamente. A este mecanismo se lo conoce como Espera inducida (Forced Wait)([19]). El planificador debe contemplar: IF dataDeadlineRTT(t) < estCompletionTimeRTT(t): WAIT UNTIL dataDeadlineRTT(t)

1348

Framework RTT para Transacciones de Tiempo Real

La construcción de RTDBS requiere considerar los conceptos descriptos en el punto anterior. Resulta útil para los desarrolladores de aplicaciones contar con un marco de trabajo que facilite el diseño de RTT incluyendo atributos, servicios y reglas de validación de consistencia temporal. De esa manera, el desarrollador se puede enfocar más específicamente a la problemática propia del sistema a modelar. En este trabajo se propone el framework RTT. Este es, un modelo orientado a objetos que contempla las características enunciadas para las RTT y que ofrece la información necesaria para que el planificador de tiempo real pueda implementar cualquiera de las políticas de planificación.

Figura 2. Framwork RTT

Para los datos de tiempo real se ha utilizado un paquete con el tipo de dato abstracto RTD ([13]), el cual caracteriza las diferentes clases de los RTD, encapsula la validación de consistencia temporal de los datos y calcula el Datadeadline de cada objeto. En la Figura 2 se describe el framework RTT en lenguaje UML.

1349

El framework presenta cuatro clases abstractas. Una clase principal Rtt que define atributos y métodos comunes a todas las transacciones de tiempo real y tres subclases que implementan las particularidades de RttUpdate, RttDerivation y RttUsrApp como fue descrito en el punto 3.2. La subclase RttUpdate, permite asociar una lista de RttDerivation que serán disparadas (triggered) en el postCommit(). La subclase RttUsrApp, permite asociar una lista de subtransacciones Rtt que serán ejecutadas al invocar executeRttSubTransaction(). Los atributos, métodos y conjuntos (Read Set y Write Set) de cada clase fueron descriptos en 3.3 y se realizan aclaraciones adicionales en notas de la Figura 2. El desarrollador de aplicaciones deberá implementar las RTT del sistema simplemente extendiendo la subclase que corresponda y definiendo la lógica de la transacción dentro del método execute(). Adicionalmente, se puede definir la Función Valor (valueFunction()) de acuerdo a si se desea implementar una RTT de vencimiento duro, firme o blando. Por defecto, Rtt.valueFunction() se define con vencimientos firmes. En la siguiente sección, se muestra el uso del framework RTT aplicándolo sobre un caso de ejemplo.

Aplicación en un caso de ejemplo

Se desea implementar un monitoreo de salud automatizado sobre una máquina SCADA (Supervisory Control And Data Acquisition). Se realizan diversas mediciones, entre ellas: la carga de trabajo (measureVal), la cual se calcula en función de la carga de CPU (cpuWorkLoad), la carga de memoria (memWorkLoad) y la tendencia de carga de los últimos minutos (loadTrend). Las mediciones tomadas se registran en la base de datos cada 20 segundos.

Figura 3. Aplicación del Framwork RTT para implementar sistema de mediciones

La carga de CPU y de memoria, se obtienen con sensados periódicos cada 4 y 6 segundos respectivamente. La tendencia de carga se obtiene desde la base de datos.

1350

Para implementar este RTDBS se aplica el framework RTT y el diseño de transacciones se muestra en la Figura 3. En el diagrama se definen los RTD necesarios y cuatro RTT encargadas de obtener datos desde los sensores, calcular la medición y grabar en la base de datos. La clase WorkLoadMeasure es la encargada de automatizar la medición. En la Figura 4 se muestra la lógica aplicada: init() : /*Define DTR para sensores */ cpuWorkLoad = new RtdBaseContinuous<Float>(4 secs); memWorkLoad = new RtdBaseContinuous<Float>(6 secs); /*Define DTR derivado. Calcula la medición WorkLoad */ measureVal = new RtdDerived<Float>(); measureVal.addRtdReadSet(cpuWorkLoad); measureVal.addRtdReadSet(memWorkLoad); /* Define transacción de Cálculo de derivaciones */ deriveTrans = new DeriveWorkLoad(pWCET0.02 secs, pTDeadline4 secs); deriveTrans.addRtdWriteSet(measureVal); /* Define transacción de Update de sensores */ updsenTrans = new UpdateSensors(pWCET 0.05 secs , pTDeadline4 secs); updsenTrans.addRtdWriteSet(cpuWorkLoad); updsenTrans.addRtdWriteSet(memWorkLoad); updsenTrans.addRttTriggeredDerivation(deriveTrans);

/* Tendencia de carga con dato de sensado discreto */ loadTrend = new RtdBaseDiscrete<Float>(); /* Define transacción de Update de sensado discreto */ updldTrans = new UpdateLoadTrend(pWCET0.1 secs, pTDeadline 4 secs); updldTrans.addRtdWriteSet(loadTrend); /* Define transacción de Grabar Medición */ saveTrans = new SaveMeasure(pWCET 0.1 secs, pTDeadline20 secs); saveTrans.addRtdReadSet(measureVal); saveTrans.addRttSubTransaction(deriveTrans); doMeasure() : /* Planifica Update de Sensores en RTT periódica*/ updsenTrans.setPeriod(updsenTrans.calcPeriod()); RTTScheduler.dispatch(updsenTrans, _PERIODIC); /* Planifica Registro de Medición en RTT periódica*/ saveTrans.setPeriod(20 secs.); RTTScheduler.dispatch(saveTrans, _PERIODIC);

Figura 4. Métodos de la clase WorkLoadMeasure

El planificador de tiempo real RTTScheduler instancia las transacciones en el período indicado por el atributo period de la RTT pasada como parámetro y al llegar el momento de inicio, la ejecuta invocando al método execute().

Conclusiones y Trabajos Futuros

El trabajo presenta en detalle los conceptos de consistencia temporal en transacciones de tiempo real, que han sido presentados en diferentes trabajos del área. El objetivo principal fue elaborar una herramienta que guíe y simplifique el diseño de transacciones en un Sistemas de Bases de Datos de Tiempo Real. Consecuentemente, se desarrolló el framework RTT, que es un modelo orientado a objetos que incorpora clasificaciones, atributos y servicios necesarios, para implementar los tres tipos de RTT identificadas en el trabajo. Con esta herramienta, el desarrollador de aplicaciones se puede enfocar específicamente en el problema a resolver y dejar bajo la responsabilidad del framework y del real-time scheduler, lo referido a gestión de las transacciones de tiempo real. Finalmente y a modo de verificación, se aplica el framework RTT en la resolución de un problema concreto. No obstante, algunas cuestiones como control de concurrencia, tolerancia a fallos, ambientes distribuidos, infraestructuras de desarrollo, etc. no han sido consideradas. Estos temas se desarrollarán en futuros trabajos sobre esta temática.

1351

Referencias [1] R. Elmasri and S. Navathe, Fundamentals of Database Systems 5/E, 5/E ed.: AddisonWesley, 2007. [2] K. Ramamritham, "Real Time Databases," International Journal of Distributed and Parallel Databases, vol. 1, pp. 199-226, 1993. [3] B. Purimetla, et al., "Real-Time Databases: Issues and Applications," in. vol. ch.20, ed: in S.Son (ed.) Advances in Real-Time Systems, Prentice Hall, 1995. [4] M. Xiong, et al., "Maintaining Temporal Consistency: Issues and Algorithms," in Proceedings of International Workshop on Real-Time Database Systems, 1996, pp. 2-7. [5] R. Abbott and H. Garcia-Molina, "Scheduling Real-Time Transactions: A Performance Evaluation," in Proceedings of the 14th VLDB Conference, 1988. [6] J. A. Stankovic, et al., "Misconceptions About Real-Time Databases," IEEE Computer, vol. 32, pp. 29-36, 1998. [7] J. J. Prichard, et al., "RTSORAC: A Real-Time Object-Oriented Database Model," In The 5th International Conference on Database and Expert Systems Applications, pp. 601-610, 1994. [8] L. C. DiPippo and L. Ma, "A UML Package for Specifying Real-Time Objects," Computer Standards & Interfaces vol. 22, pp. 307-321, 2000. [9] N. Idoudi, et al., "Structural Model of Real-Time Databases: An Illustration," in Object Oriented Real-Time Distributed Computing (ISORC), 2008 11th IEEE International Symposium on, 2008, pp. 58-65. [10] K. Ben, et al., "Maintaining temporal consistency of discrete objects in soft real-time database systems," Computers, IEEE Transactions on, vol. 52, pp. 373-389, 2003. [11] S. Rekhis, et al., "Modeling Real-Time applications with Reusable Design Patterns," International Journal of Advanced Science and Technology, vol. 22, pp. 71-86, 2010. [12] A. Hala, et al., "A General Framework for Modeling Replicated Real-Time Database," International Journal of Electrical and Computer Engineering. Word Academy of Science, Engineering and Technology, pp. 4-8, 2009. [13] C. Buckle, et al., "Abstract Data Type for Real-Time Database Systems," in XVII Congreso Argentino de Ciencias de la Computaci贸n, UNLP. La Plata, Argentina, 2011. [14] Soparkar, et al., Time-Constrained Transaction Management: Real-Time Constraints in Database Transaction Systems: Kluwer Academic Publishers, 1996. [15] B. Adelberg, et al., "Applying update streams in a soft real-time database system," Proceedings of the 1995 ACM SIGMOD, vol. 24, pp. 245-256, 1995. [16] Y. Wei, et al., "Maintaining Data Freshness in Distributed Real-Time Databases," presented at the Proceedings of the 16th Euromicro Conference on Real-Time Systems, 2004. [17] C. L. Liu and J. W. Layland, "Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment," Journal of the ACM, vol. 20, pp. 46-61, 1973. [18] E. D. Jensen, et al., "A Time-Driven Scheduling Model for Real-Time Operating Systems," Proceedings of Real-Time Systems Symposium, pp. 112-122, 1985. [19] M. Xiong, et al., "Scheduling access to Temporal Data in Real-Time Databases," in RealTime Database Systems: Issues and Applications, Bestavros, et al., Eds., ed: Kluwer Academic Publishers, 1997, pp. 167-191.

1352

Toolchain and workflow for the design of an ISO 11783-compatible ECU based on ISOAgLib Joaquin Ezpeleta and Sebastián Rossi, Facultad de Ciencias Exactas, Ingeniería y Agrimensura, Universidad Nacional de Rosario, Av. Pellegrini 250, S2000BTP Rosario, Argentina ezpeleta@fceia.unr.edu.ar, srossi@inti.gob.ar

Abstract. This paper describes a basic toolchain for the design of an ISO 11783-compatible electronic control unit (ECU), from its conception to the implementation of a working embedded prototype, along with a suggested workflow for dividing application programming, mask design and hardware-related tasks in a debugging-friendly and time-efficient manner. The toolchain is centered on the open source ISOAgLib programming library distributed and maintained by OSB AG and the paper will refer to other specific tools and devices, but is otherwise intended to provide a general introductory overview of the process rather than focus on specific vendors or platforms. Keywords: toolchain, workflow, ISO 11783, ISOBus, ISOAgLib, controller area network (CAN), embedded system.

1 Introduction ISO 11783 [1 et seq.] –commonly known as ISOBus– defines a serial data network for agricultural or forestry equipment based on the CAN 2.0 B [4] protocol. It is intended to provide an interconnection system for on-board electronics. A typical ISOBus network is shown on Figure 1. A basic element of such network is the electronic control unit (ECU), which is defined in [1] as an ‘electronic item consisting of a combination of basic parts, subassemblies and assemblies packaged together as a physically independent entity’. This paper describes the process for creating one such ECU, from its design to the implementation of an embedded prototype. Specifically, it suggests a toolchain and a workflow for this process. The toolchain is based on the open-source library ISOAgLib and other related tools distributed and maintained by OSB AG [7], but alternatives are given wherever possible to provide maximum flexibility. Similarly, the process described is mostly platform-independent (both in terms of the operating system used for development on a desktop environment and in terms of the embedded hardware platform used for the actual implementation), but examples are given at various points for the purpose of clarity and reproducibility. For an implementation on specific hardware see, for example, [6]. Section 2 presents the suggested toolchain, along with explanations and brief examples; Section 3 describes the physical and virtual elements needed to test and use

1353

software- and firmware-level applications; Section 4 presents the proposed workflow for an efficient and debugging-friendly task division using the tools and resources presented in Sections 2 and 3.

Fig. 1. Example ISO 11783 network on a tractor with two implements.

2 Toolchain A summary of the suggested toolchain is shown graphically in Figure 2. It presents the tasks needed to design an ISOBus system with ISOAgLib, the tools needed for each task and the relationship between these tasks. As will be seen on Section 4, however, many of these tasks can often be undertaken independently, so a roughly left-to-right and top-to-bottom order will be followed. 2.1 Mask design and parsing The first tool to be discussed is VT designer, which is a graphic interface for designing masks which are compatible with [3]. It is currently available from OSB AG in both a trial and a full version. It has a simple and intuitive interface and includes examples which can be modified to gain insight into its use. The purpose of this tool within the suggested toolchain is to take an abstract design concept for the necessary mask(s) and create files which can be further processed for use in the application. Given one or more manually-loaded masks (collectively, an object pool), VT Designer creates a .vtp project file and a number of .xml files which contain the actual objects and attributes. An alternative for the use of VT Designer is PoolEdit, developed by Matti Ă&#x2013;hman and Jouko Kalmari at Aalto University [9] and distributed under GNU General Public License (GPL). The former is discussed here for its greater affinity with the OSB AG toolchain, but the latter produces almost identical results.

1354

Fig. 2. Toolchain for the development of an ISO 11783-compatible application.

The .xml files output by VT Designer cannot typically be included directly into the source code of the application. A second tool is needed to transform the .xml files into source files which can be handled by the C++ compiler. An example of an application which serves this purpose is vt2iso.exe, available free of charge from OSB AG. It is a console application which essentially takes the .vtp and .xml files from the previous step and produces a group of .inc and .h files which can then be included directly by the compiler. Below is a basic use example on the Microsoft Windows command line, where myDisplay.vtp is a VT Designer project file. A number of optional arguments are also available but are not typically necessary. C:\IsoAgLib\tools\vt2iso\bin>vt2iso.exe myDisplay.vtp

1355

2.2 Project Configuration Another step in the design process is defining project settings. These are to be entered manually in a configuration file and include basic parameters, such as the project name, the folder where the user and library files are stored, the number of CAN instances and the target platform (e.g. PC running Microsoft Windows, PC running Linux, embedded system, etc.), among others. It is advisable to adapt the template (conf_template) included with ISOAgLib rather than enter the settings directly on a blank file, as the former approach will be both faster and less error-prone. In either case, the resulting file is to be processed by a shell script (conf2build.sh) to produce a configuration header (isoaglib_project_config.h) which can be included directly into the application. The shell script is included with ISOAgLib and can be run natively in Linux and other UNIX systems. Microsoft Windows users will need to install MSYS/MINGW [11] or other similar software which makes it possible to run UNIX shell scripts under this OS. A typical command for executing the script is shown below, where myconfig is a copy of conf_template adapted to a specific project. $ conf2build.sh myconfig Also note that the resulting isoaglib_project_config.h header is included via the library header isoaglib_config.h and is not to be included directly (the preprocessor will issue an error if it is). 2.3 Hardware Abstraction Layer (HAL) ISOAgLib includes a Hardware Abstraction Layer (HAL) which acts as an intermediary between the rest of ISOAgLib and the actual hardware on which it runs. This includes system startup, time tracking, power management, CAN communication, non-volatile storage and similar hardware-dependent functions, along with definitions for data types, error codes and configuration parameters. The HALs for certain hardware platforms (most notably, PCs running Microsoft Windows or Linux) are already included with the library, but others must be programmed by the user (e.g. ARM-based MCUs). It is advisable to use an existing HAL as model when creating a new one. It should also be borne in mind that, when changing platforms, the project configuration described in 2.2 must be updated accordingly. In embedded systems, it may also be necessary to include additional files outside the HAL, such as a startup file (see Figure 2, bottom left). 2.4 User Code While ISOAgLib provides for most communication and compliance requirements, it is up to the user to design and program the actual application. The typical application includes initialization code which is run once at the start, a main application loop

1356

which performs all communication and normal operation tasks and closing code which shuts down the application and all associated hardware in a controlled manner. In addition, on embedded systems, startup code is typically needed before the rest of the application can be executed. The initialization code should perform the following basic functions: (a) initialize instances of the system, the scheduler, the bus, the monitor and the CAN controller; (b) declare or retrieve parameters needed for subsequent address claim; (c) register the necessary tasks on the scheduler, initialize the system components and register the object pool on the monitor; (d) transfer control to the main loop. In addition, it should perform any application-specific or hardware-dependent initialization functions (such as interrupt vector, watchdog, real-time clock, analog-digital converter or output configuration or pin remapping), although these can usually be called automatically during system initialization by including them in the HAL. The main application loop should run after initialization and until the application needs to terminate for any reason. As far as the ISOAgLib library is concerned, the only requirement for the main application loop is that the time event of the scheduler instance be called within the time constraints defined in [1 et seq.], but other functions will be needed for any specific application. Finally, the closing code unregisters all elements, deallocates memory, calls the close method for each of the active instances and takes all associated hardware to a safe condition (e.g. deenergized actuators). Gaining insight into the use of ISOAgLib can be challenging given the lack of freely available training and tutorials. OSB AG offers customized workshops and training sessions which include examples, but the examples themselves cannot be bought alone. If workshops or training are not an option due to cost, examples are freely available for earlier versions of ISOAgLib (up to 2.2.1) from OSB AGâ&#x20AC;&#x2122;s repository. These can be adapted to more current versions by following the changelog and inferring necessary changes in the user files, but this involves considerable guesswork and can be a time-consuming process. 2.4 Compilation, Linkage and Loading The tools used for compilation, linkage and (in the case of embedded systems) loading are highly platform-dependent and are usually managed by a single IDE. General purpose compilers such as GCC [10] can be used for early stages of development where the application is to run entirely within the desktop environment, while vendor- or platform-specific compilers are generally needed to compile the application for specific hardware (e.g. armcc for ARM-based MCUs). Remark 1. ISOAgLib is written in C++. This must be taken into account when selecting the product and compiler, as some products do not offer C++ compilers or do so at relatively high prices.

1357

3 Hardware framework Figure 3 shows an example interconnection of system elements. It is intended to provide a summary of the connection options available throughout the entire design process. In each stage of the development proces, however, not all of the elements are simultaneously necessary in general. For example, while initially programming and debugging the application, all work is typically done within a desktop environment without resorting to additional external hardware. Similarly, the process for preliminary design and implementation of sensors and actuators will not normally require access to a virtual terminal, whether physical or simulated. The interconnection between system elements is done basically by means of three CAN buses, namely a physical bus, a socket bus and a proprietary virtual bus. The physical bus is an actual wired bus complying with the requirements set forth in [2]. It includes a pair of data wires CAN_H and CAN_L and should be terminated with impedance-matching resistors. Remark 2. While [2] defines a nominal characteristic bus impedance of 75 Ω, existing CAN hardware not developed specifically for ISOBus may use 120 Ω instead, as defined in [5] (the original Bosch document, [4], did not specify this and other electrical aspects of the physical layer). Data transmission from and to the bus is normally done through CAN transceivers. These convert 3.3 V or 5 V logic values from the RX/TX pins on an MCU (or other levels from other hardware) to dominant and recessive bits on the CAN bus and vice versa. Examples of CAN transceivers are SN65HVD230 and MAX3051 for 3.3 V systems and SN65HVD255 and MAX3058 for 5 V systems. The socket bus is an internal socket connection which emulates a CAN bus within a desktop environment. The ISOAgLib toolchain includes several similar tools for this purpose, one which is designed solely for interaction between several ISOAgLib applications within the desktop (can_server_simulating.exe) and others which additionally provide functionality for connection with vendor-specific hardware and software. For example, can_server_vector.exe and can_server_vector_xl.exe are designed for communicating with hardware and software from Vector Informatik GmbH [8], which is achieved by using Vector’s CAN DLL library. The CAN server thereby acts as a bridge between the socket bus and the proprietary virtual bus, discussed below. The proprietary virtual bus is an emulated CAN bus like the socket bus, and can be thought of as an extension of the latter. It is used for communication between proprietary hardware and software from a given vendor and the corresponding CAN server. In addition, by communicating with a CAN card, the proprietary virtual bus in turn enables access to the physical external bus. For example, Vector offers CANcardXL, a two-channel driver card which provides access to up to two external physical buses. Additionally, they offer an application by the name of CANoe which manages the card and also serves as a bus analyzer. When both CANcardXL and can_server_vector_xl.exe are running, the socket bus, the proprietary virtual bus and the physical bus merge, for all practical purposes, into a single CAN bus. This and other similar setups offer great versatility, as they make it possible for a number of

1358

applications running either on the desktop or on an embedded system to communicate seamlessly with each other and with third-party devices, such as a virtual terminal. In addition, software like CANoe can emulate a virtual terminal, which is essential for running preliminary tests entirely within the desktop environment, with further tests on actual virtual terminals being done at a later stage of development.

Fig. 3. Hardware framework.

In addition to the CAN buses, Figure 3 shows a UART connection between the MCU and a terminal emulator within the PC. This provides a simple means of transmitting debugging information between the PC and the MCU without loading the CAN bus, but is entirely optional.

4 Workflow This Section describes a proposed workflow for the design process of an ISO 11783-compatible application. The basic stages in this process are application programming (with and without masks), mask design, hardware-related tasks and prototyping. A way of organizing these stages is shown in Figure 4. The basic concept is to run tasks in parallel in order to make better use of available time, hardware and

1359

human resources. Time is better used as different teams can work on the different task simultaneously. In addition, each task can be assigned to a specialist in the corresponding field, such as a programmer for building the application and an electrical engineer for working wiring, sensors and actuators, making better use of available human resources. Finally, available hardware can be used more efficiently, as each task requires only some of the hardware tools. Some examples of this were discussed in the previous Section, which described a flexible hardware framework.

Fig. 4. Proposed workflow for the design process.

1360

Another advantage of task division is to facilitate the debugging and troubleshooting process. When each task is undertaken individually, the possible error sources are confined to a subdomain of the entire system. For example, if the application is initially debugged using a virtual bus and simulated data (maskless application or application programming stage in Figure 4), no communication- or hardware-related errors arise and the debugging domain is thereby restricted only to the application itself. The maskless application programming stage consists in the design and programming of a virtual application which does not resort to any virtual terminal (physical or otherwise) for display. Additionally, such application would be developed entirely within a desktop environment, without resorting to external data or elements and without being loaded onto an MCU or other embedded system. The application uses the PC HAL at this point. As the application will be isolated from data which it normally needs for its operation (data from sensors, other network devices or user input), simulated data can be used during this stage to examine the behavior of the application in different situations. The mask design stage basically involves the task of designing one or more masks (an object pool) and parsing then into a format which can be handled directly by the compiler used for building the application. This stage can be completed mostly using the tools described in 2.1 above, although some previous design work is necessary to create a visual concept for the masks (colors, layout, shape and position of various elements, expected functionality, etc.). The application programming stage is an extension of the maskless application programming stage with the addition of the masks designed in the mask design stage. The goal of this stage is to ensure that the application can upload the object pool to a simulated virtual terminal and interact with it (i.e. receive user input and make necessary changes on the elements of the object pool). Except for data flowing to and from the virtual terminal, the rest of the data used during this stage is still simulated. Similarly, the application continues to run within the desktop environment using a PC HAL. The hardware-related tasks stage encompasses all hardware or platform-specific tasks. These basically include the design and implementation of actuators, drivers, sensors, data acquisition means, the creation of a HAL for ISOAgLib if one does not exist for the intended platform and the inclusion or programming of other platformdependent elements which cannot be included within the HAL (such as a startup file). The creation of the HAL in turn involves implementing functions for CAN communication, configuration of interrupt vectors, watchdogs, real-time clock, analog-digital converters or outputs and pin remapping. Finally, the application (included the masks) can be loaded onto the embedded hardware and combined with sensors, actuators, CAN peripherals and other hardware elements to produce a working embedded prototype. This prototype can then be tested for minor bugs or problems within a laboratory environment (possibly using a simulated VT) to create a final version of the device, which can be further tested with actual equipment on field prior to its commercial production.

1361

References 1. ISO 11783-1:2007, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 1: General Standard for mobile data communication, International Organization for Standardization, Geneva (2007) 2. ISO 11783-2:2002, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 2: Physical Layer, International Organization for Standardization, Geneva (2002) 3. ISO 11783-6:2004, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 6: Virtual Terminal, International Organization for Standardization, Geneva (2004) 4. CAN Specification Version 2.0 Part B, Robert Bosch GmbH, Stuttgart (1991) 5. ISO 11898-2:2003, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit, International Organization for Standardization, Geneva (2003) 6. Tumenjargal, E., Badarch, L., Kwon, H., Ham, W.: Embedded software implementation system for a human machine interface based on ISOAgLib. Journal of Zheijang University (2013) 7. OSB AG, http://www.osb-ag.com/osb-ag.html 8. Vector Informatik GmbH, http://vector.com 9. PoolEdit - Open Source XML ISO 11783 User Interface Editor, http://autsys.aalto.fi/en/Farmix/PoolEdit 10.GCC, the GNU Compiler Collection, http://gcc.gnu.org 11.MSYS, http://www.mingw.org/wiki/MSYS

1362

Controlador neuronal incremental aplicado a un mezclador de flujos Sergio L. Martínez1, Enrique E. Tarifa1,2 & Samuel Franco Dominguez1 (1)

Facultad de Ingeniería, Universidad Nacional de Jujuy, Gorriti 237, S. S. de Jujuy, Jujuy, Argentina {smartinez, eetarifa, sfdominguez}@fi.unju.edu.ar (2) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET). eetarifa@arnet.com.ar

Resumen. En este trabajo se diseña e implementa un controlador tipo MIMO basado en redes neuronales artificiales, aplicado a un modelo de mezclador de corrientes líquidas, configurado sobre el entorno de simulación gráfica de Matlab®. Se destaca una particular metodología de entrenamiento del controlador neuronal, basada en un punto de operación genérico asociado a un reducido entorno del espacio de datos definidos en forma incremental, permitiendo una importante reducción de datos de aprendizaje y esfuerzo computacional. El desempeño del controlador es comparado con otro controlador neuronal similar configurado bajo un proceso de entrenamiento estándar. Los resultados obtenidos permiten apreciar las ventajas del método de control incremental. Palabras clave. Redes neuronales. Mezclador de flujos. Control. Simulación.

Introducción

Los dispositivos mezcladores de flujos son sistemas adicionales indispensables en muchos procesos industriales y son objeto de estudio y aplicaciones en diversas investigaciones [1], [2], [3]. Usualmente se complementan con sistemas de control que requieren correcciones permanentes, que según la complejidad de la dinámica del proceso podrían ser realizadas por un operario experto; o por un sistema de control automático. En este trabajo se diseña e implementa un controlador tipo MIMO (Multiple-input Multiple-output) basado en redes neuronales, aplicado al modelo de un mezclador de corrientes líquidas, configurado sobre el entorno Simulink® de Matlab®. Se destaca una particular metodología de entrenamiento del controlador, basada en un punto de operación genérico que incursiona sobre un reducido entorno definido en forma incremental, permitiendo una importante minimización de datos requeridos para el aprendizaje de la red neuronal. El desempeño del controlador es comparado con otro controlador neuronal similar configurado bajo un proceso de entrenamiento estándar. Los resultados obtenidos permiten apreciar las ventajas del método de control incremental.

1363

Proceso a controlar

Los mezcladores de flujos o de caudales (flow mixers), utilizados en muchos procesos industriales, suelen estar sometido a dinámicas exigentes, requiriendo la asistencia de sistemas de control automáticos. Un sistema de este tipo, cuyo esquema y modelo gráfico se muestran en la Fig. 1, es utilizado en este trabajo como sistema a controlar. corriente caliente

corriente fría

Ff Tf

Fc Tc

Vc corriente mezcla

F T

(a)

(b)

Fig. 1. Mezclador de caudales en línea. (a) esquema físico, (b) modelo.

Las entradas reciben las corrientes para la mezcla con caudales y temperaturas preestablecidos, y en la salida se obtiene una nueva corriente con propiedades específicas (caudal, presión, temperatura, composición). 2.1

Modelo del mezclador en línea

El modelo para el mezclador de flujos en línea se puede representar con el siguiente conjunto de ecuaciones: F = xf Ff + xc Fc .

(1)

xf Ff Tf + xc Fc Tc . xf Ff + xc Fc

(2)

0 ≤ xf ≤ 1 y 0 ≤ xc ≤ 1

(3)

donde la corriente de entrada (fría), tiene un caudal máximo Ff y una temperatura Tf. Esta corriente es regulada por la apertura xf de la válvula Vf. La otra corriente de entrada (caliente), tiene un caudal máximo Fc y una temperatura Tc. Esta corriente es regulada por la apertura xc de la válvula Vc. Las aperturas xf y xc incursionan en el intervalo (0, 1), donde 0 corresponde a la válvula completamente cerrada y 1 a la válvula completamente abierta, de modo que permite pasar la totalidad del caudal asignado. La corriente mezcla presenta a la salida un caudal F y una temperatura T.

1364

2.2

Modelo inverso del mezclador en línea

Invirtiendo el modelo planteado, se obtiene un sistema de control ideal MIMO que proporciona las aperturas de las válvulas (xf y xc), para un caudal de referencia (setpoint) Fsp y para una temperatura de referencia Tsp preestablecidos. El modelo matemático asociado a este sistema inverso está formado por las ecuaciones siguientes:

xf =

xc =

Fsp ( Tc − Tsp ) Ff ( Tc − Tf ) Fsp ( Tsp − Tf )

Fc ( Tc − Tf )

(4)

(5)

Tf ≤ Tsp ≤ Tc y 0 ≤ Fsp ≤ Fmax

(6)

donde Fmax es el máximo valor que puede adoptar Fsp para un dado Tsp. El caudal Fmax se obtiene a través de un problema de optimización, cuyo resultado se muestra en (7):

Fmax

3 3.1

 Ff ( Tc − Tf ) F T + Fc Tc . si Tf ≤ Tsp ≤ f f .  Ff + Fc  Tc − Tsp =  Fc ( Tc − Tf ) . en otro caso  Tsp − Tf 

(7)

Sistemas de control RNA como procesadores no lineales

Las redes neuronales artificiales (RNA), son modelos matemáticos que emulan –a nivel básico– la actividad del cerebro humano, dotados de la capacidad de aprender, “memorizar” y generalizar la información aprendida, con elevada tolerancia al ruido. Desde un punto de vista general, las RNA se especializan en descubrir y asociar patrones de entrada–salida con relación lineal o no lineal, según sea su arquitectura, configuración de las neuronas y proceso de aprendizaje [4], [5]. La Fig. 2 presenta una arquitectura típica de red neuronal feedforward de tres capas, con M neuronas de entrada, L neuronas en la capa oculta y N neuronas de salida. La primera capa de la RNA –de entrada– se configura con unidades ficticias que distribuyen las señales hacia la capa oculta. La salida de cada neurona de esta capa responde a la siguiente ecuación: M   yl = g  − w0 l + ∑ wlm xm  con l = 1,..., L . m =1  

(8)

1365

donde xm es la m-ésima componente del patrón de entrada; wlm es el peso de conexión entre la neurona l de la capa oculta y la neurona m de la capa de entrada; w0l es el peso de ajuste (bias) de las neuronas de la capa oculta; g(·) es la función de transferencia de las neuronas ocultas y yl es la salida de la l-esima neurona oculta. La salida de cada neurona de la última capa se modela con la ecuación (9): L   zn = h  − v0 n + ∑ vnl yl  con n = 1,..., N . l =1  

(9)

donde yl es el valor de salida de las neuronas de la capa anterior; vnl es el peso de conexión entre la neurona n de la capa de salida y la neurona l de la capa oculta; v0n es el peso de ajuste (bias) de las neuronas de la capa de salida; h(·) es la función de transferencia de las neuronas de salida y zn es la n-ésima componente del patrón de salida Z. w11

x1 wl1

w01 -1

wlm

v11 z1 v1n

v01 -1

wnl

zn v0n

w0l -1

-1 wlM xM

vnL zN

vNM

wLM

v0N

w0L -1

-1

Fig. 2. Red feedforward tricapa genérica.

3.2

Controlador neuronal incremental

Se pueden adoptar dos enfoques generales para la implementación de controladores neuronales. En un primer enfoque, la RNA tiene como entrada tanto las variables controladas como los correspondientes valores de referencia, mientras que las salidas son las variables manipuladas (F, T, Fsp y Tsp en este caso); mientras que las salidas son las variables de control (xf y xc). Si se tiene algún conocimiento previo del sistema –tal como el modelo del proceso, secuencias históricas o muestras de ejemplo con sus correspondientes valores de salida–, se puede utilizar para el entrenamiento de la red. En este caso, la RNA aprenderá a asociar cada patrón de entrada con la salida correspondiente, sobre la totalidad del espacio de datos del sistema, dentro de un nivel de error predeterminado. Aunque este es un enfoque clásico y ampliamente utilizado, tiene algunos inconvenientes que pueden considerarse críticos. El primer inconveniente surge por la gran cantidad de información que se requiere para cubrir adecuadamente el espacio de datos del sistema, que en muchas ocasiones no están disponibles. Otro inconveniente destacable es la compleja arquitectura que puede alcanzar la RNA, eventualmente con una importante cantidad de unidades neuronales internas, demandando un elevado esfuerzo computacional, que en ciertos casos obliga a aplicar técnicas adicionales para reducir el flujo de información a costa de un incremento en el error de aprendizaje [6].

1366

En un segundo enfoque para implementar una RNA como controlador, se puede considerar la operación de la red bajo un esquema incremental. Para ello, se configura la RNA para que las entradas sean los errores de las variables controladas (eF y eT), y las salidas sean las correcciones que deben realizarse sobre las variables manipuladas (∆xf y ∆xc). Estas nuevas variables se definen como: eF = Fsp0 − F

eT = Tsp0 − T .

(10)

∆xf ( t ) = xf ( t ) − xf ( t − ∆t )

(11)

∆ xc ( t ) = xc ( t ) − xc ( t − ∆ t )

(12)

Var2

donde t es el tiempo de simulación, y ∆t es el paso de simulación. Con este cambio de variables, el punto de operación deseado es aquel que anula los errores. Cualquier desviación de este punto de operación, requiere que el controlador realice correcciones sobre las variables controladas. Es decir, cuando ambas entradas de la RNA sean nulas, sus salidas también lo serán y no es necesaria ninguna acción de control. En cambio cuando una o ambas entradas dejen de ser nulas, las salidas de la RNA deberán proveer las correcciones necesarias sobre las variables de control. La conducta descripta es independiente del punto base que se tome. Más aún, si la superficie de control es lineal, las magnitudes de las correcciones serán independientes de la posición del punto base. En este nuevo esquema de control, no es necesario entrenar a la RNA en toda la región de control. Concretamente, bajo este enfoque se establece un punto de operación genérico que representa la situación de referencia general de las variables de control y se definen las condiciones de operación sobre un entorno, mediante valores incrementales a partir del punto de operación establecido. En la Fig. 3 se muestra un espacio de datos bidimensional genérico con sus límites, un punto de operación base definido y el entorno asociado con los respectivos incrementos de las variables de control. Límites Entorno incremental

Espacio de datos

Incremento Var2

V2SP Punto de operación

Incremento Var1

V1SP

Var1

Fig. 3. Punto de operación y entorno incremental para un proceso genérico.

La adecuada implementación de la estrategia de control propuesta requiere algunas consideraciones adicionales. Por un lado está la selección del punto base, cuya ubicación no debe sobrepasar los límites del espacio de datos, y debería ser el punto

1367

establecido por las condiciones nominales de diseño del sistema. Por otro lado, está la determinación de la extensión del entorno alrededor del punto base, que debe ser suficientemente extensa como para capturar la naturaleza de la superficie de control. Un tercer criterio a considerar es el intervalo de subdivisión del entorno de operación: incrementos muy grandes no permiten capturar las variaciones del entorno de la superficie de control, generando errores considerables en otras ubicaciones del punto base; incrementos muy pequeños producirían gran cantidad de datos innecesarios por estar más allá de la sensibilidad de los componentes del sistema.

Desarrollo experimental

El modelo experimental del mezclador de flujos (Fig. 1) se ha implementado inicialmente para operación manual sobre el entorno Simulink® de Matlab® (Fig. 4) y se ha instanciado con los siguientes parámetros: • Corriente fría: caudal de entrada Ff = 100 l/min, temperatura Tf = 25 ºC. • Corriente caliente: caudal de entrada Fc = 100 l/min, temperatura Tc = 70 ºC.

Fig. 4. Modelo Simulink® del mezclador de flujos en línea.

4.1

Generación de datos

Para determinar el punto base de operación se utilizó el modelo directo del mezclador, definido por las ecuaciones (1) a (3), donde las variables de entrada son las aperturas xf y xc, y las variables de salida son el caudal F y temperatura T de la mezcla. Evaluando este modelo para el caso en que ambas válvulas están abiertas a la mitad (xf = xc = 0.5), se obtiene a la salida un caudal F = 100 l/min y una temperatura T =47.5 ºC. Este punto fue tomado como base para el proceso de entrenamiento de la RNA. A continuación se estableció el entorno de operación en ±10% para ambas variables y la variación incremental ∆F y ∆T en el 1%, considerando que es ésta la mínima resolución del sistema. De esta manera, cada punto del entorno de operación queda definido de la siguiente forma:

1368

Fspi = Fsp0 + ( i − 11) ∆F Fsp0 min sp

max sp

= 90 l/min

Tspj = Tsp0 + ( j − 11) ∆T Tsp0 T min = 42.75 ºC

con i = 1,..., 21

(13)

= 110 l/min

j = 1,..., 21

con

(14)

T max = 52.25 ºC

El entorno de operación queda particionado en 21 intervalos, obteniéndose un total de 441 puntos de operación incrementales alrededor del punto base, como se esquematiza en la Fig. 5. UBICACIÓN PUNTO BASE 200 180

cau d al referen cia FSP [l/m in ]

160

Límite caudal máximo

140 120

Límite caudal máximo

Incremento caudal

100

FSP0 Punto base

80 60

Incremento temperatura

Superficie de control

TSP0 0 25

temperatura referencia TSP [ªC]

Fig. 5. Posición de punto base y entorno incremental del mezclador de flujos.

Definido el entorno de operación a estudiar, se utilizó el modelo inverso, ecs. (4) a (6), para obtener las acciones de control requeridas para cada uno de los puntos incluidos en el entorno del punto base. En este modelo inverso, las variables de entrada son el caudal de referencia (Fsp) y la temperatura de referencia (Tsp); mientras que las variables de salida son las aperturas xf y xc que permitirán alcanzar el estado deseado. Conocidas las acciones de control necesarias para llegar a cada punto del entorno de operación, se las expresa como cambios requeridos en función de los errores medidos:

eFi = Fsp0 − Fspi = − ( i − 11) ∆F Fsp0 eTj = Tsp0 − Tspj = − ( j − 11) ∆T Tsp0 . ∆xfij = xfij − 0.5.

4.2

∆xcij = xcij − 0.5.

(15) (16) (17)

Diseño del controlador neuronal incremental

A partir de una arquitectura neuronal feedforward, los parámetros más significativos a considerar son el número de capas y las cantidades de neuronas por capa. La dimen-

1369

sionalidad de las capas de entrada y salida queda definida por las características del problema, siendo cada una bidimensional, en este caso. De acuerdo con la interpretación del teorema de aproximación de Cybenko [7], una capa oculta con una cantidad finita de unidades con funciones monótonas crecientes, es suficiente para cualquier mapeo no lineal de entrada-salida con un nivel de error suficientemente bajo. Luego, el parámetro de mayor criticidad es la cantidad de neuronas ocultas encargadas del procesamiento interno; una cantidad insuficiente de neuronas ocultas puede impedir alcanzar el nivel de error deseado, mientras que una cantidad excesiva puede disminuir la capacidad de generalización de la red. En muchos casos, la determinación de este parámetro se realiza en forma experimental, aunque existen algunas heurísticas dedicadas a la determinación de la cantidad de neuronas ocultas, que aunque no son matemáticamente rigurosas, pueden producir buenas aproximaciones. Así por ejemplo, se puede citar a la regla de la pirámide geométrica, donde el número de neuronas ocultas (N(o)) se obtiene como una progresión geométrica entre el número de neuronas de entrada (N(e)) y el número de neuronas de salida (N(s)), de la forma N ( o ) = N ( e ) . N ( s ) [8]. La regla de las capas entrada-oculta establece que el número de neuronas ocultas no debe superar dos o tres veces la cantidad de neuronas de entrada [9]. Otra regla práctica, utilizada por Goethals et al. [10], sugiere que el número de neuronas ocultas (N(o)) se relaciona con el número de neuronas de entrada (N(e)) de la forma N(o) = 2×N(e) + 1. Bajo las consideraciones anteriores, se definió una RNA feedforward con arquitectura 2+5+2 para actuar como un controlador neuronal incremental tipo MIMO (2 entradas y 2 salidas), con las siguientes características: • 2 neuronas en la capa de entrada. • 5 neuronas en la capa oculta. Función de transferencia tangente sigmoide. • 2 neuronas en la capa de salida. Función de transferencia lineal. Con los parámetros anteriores definidos, la RNA fue entrenada con el algoritmo backpropagation obteniéndose los siguientes resultados: • Cantidad de iteraciones: 500. • Entrenamiento con algoritmo backpropagation, variante LM. • Error cuadrático medio (ECM) de entrenamiento: 2.11×10-10.

4.3

Configuración y operación del sistema

El modelo experimental del sistema completo (controlador–planta), fue configurado en el entorno de simulación gráfica de Matlab® (Fig. 6). En este modelo, el sistema a controlar se incorpora como un bloque que recibe los parámetros de caudales de entrada (Ff y Fc), de temperatura (Tf y Tc) de tales caudales y las variables de control (xf y xc), produciendo las variables de salida caudal (F) y temperatura (T). El controlador neuronal, recibe a la entrada el error de caudal (errF = Fsp – F) y el error de temperatura (errT = Tsp – T), ambos modulados por limitadores que mantienen a los valores incrementales dentro del entorno definido, mejorando la estabilidad del sistema; y genera las variaciones de apertura de la válvula fría (∆xf) y de la válvula caliente (∆xc). Estas variaciones se componen con las aperturas del estado anterior (xf (k) = xf (k–1) + ∆xf(k) || xc (k) = xc (k–1) + ∆xc(k)) para ser realimentadas al mezclador de flujos, cerrando el lazo de control.

1370

Fig. 6. Modelo experimental del mezclador de flujos con control neuronal.

4.4

Prueba del sistema

Para comprobar la operación del sistema, se aplicaron diferentes condiciones en los parámetros de referencia (setpoints). En el primer caso, los parámetros de referencias requirieron variaciones abruptas para el caudal y la temperatura como muestra la Fig. 7.

Fig. 7. Control de caudal y temperatura de salida para referencia tipo escalón.

Se observa que el sistema ejecutó una muy buena acción de control para responder a las variaciones abruptas de los valores de referencia de caudal y temperatura. En el segundo caso, el parámetro de referencia caudal (Fsp) exigió una variación sinusoidal suave mientras que la temperatura (Tsp) debió mantenerse en un valor constante (Fig. 8). En este caso que la variación exigida por la referencia del caudal (Fsp) es correctamente seguida por la planta, mientras la temperatura se mantiene constante en T = 47.5 ºC como requiere la referencia Tsp.

1371

Fig. 8. Control de caudal y temperatura de salida para referencia tipo sinusoidal.

En el tercer caso, se provocó una perturbación sinusoidal del 2% en el parámetro caudal de corriente caliente (Fc), al mismo tiempo que se aplicó una variación lineal tipo rampa a la temperatura de referencia (Tsp), que se inició en 25 ºC, obteniéndose los resultados mostrados en la Fig. 9.

Fig. 9. Control de caudal y temperatura de salida para perturbación en caudal.

En este caso la perturbación fue adecuadamente absorbida por el controlador, hasta el instante t = 75.02 min, donde el controlador se satura (la válvula de la corriente fría se cierra totalmente, xf = 0) y la temperatura de salida se estabiliza en T = 70 ºC. El desempeño del controlador neuronal incremental (CN incremental) desarrollado se ha comparado con un controlador neuronal equivalente (CN estándar), con entrenamiento clásico, para la misma planta y con idénticos parámetros [6]. La comparación de los parámetros más representativos se observan en la Tabla 1. Los datos de esta tabla, evidencian una indiscutible ventaja del controlador neuronal incremental en varios aspectos, tales como una arquitectura más simple, menor cantidad de variables de entrada, gran reducción en la cantidad de datos –sin necesidad de preprocesamiento previo–, menor tiempo de entrenamiento y mejora en el error general de aprendizaje.

1372

Tabla 1. Parámetros de comparación entre controladores equivalentes. Parámetro Variables de entrada Variables de salida Cantidad de capas Neuronas ocultas Patrones de entrenamiento ECM de entrenamiento Tiempo de entrenamiento

CN incremental 2 2 3 5 2×441 2.11×10-10 36 seg

CN estándar 4 2 3 10 4×5034 4.83×10-9 1 min 47 seg

Conclusiones

Se ha diseñado e implementado en un sistema de simulación gráfica, un controlador neuronal MIMO configurado para trabajar por incrementos a partir de un entorno genérico predefinido, aplicado a un mezclador en línea de corrientes líquidas. La capacidad del conjunto controlador–planta se ha comprobado experimentalmente bajo diversas condiciones, tales como variaciones abruptas y oscilantes de los parámetros de referencia y perturbaciones de los parámetros de la planta, mostrando un muy buen desempeño del sistema de control neuronal propuesto. El controlador neuronal incremental se ha comparado con un controlador neuronal estándar equivalente aplicado a la misma planta, poniéndose en evidencia las ventajas en diseño, entrenamiento y operación del modelo incremental.

Referencias

[1]

Palencia Díaz A. Estudio de Diferentes Estrategias de Control para un Tanque de Mezclado: PID, Control de Matriz Dinámica y Lógica Difusa. Prospect, 8(1), pp. 43-51, (2010) [2] Mohamed Sultan M., Sha A.S., David C.O.: Controllers optimization for a fluid mixing system using metamodeling approach. In: International Journal of Simulation Modelling, 8(1), pp. 48–59, (2009) [3] Yan Deng S.: Nonlinear & Linear MIMO Control of an Industrial Mixing Process. Master Thesis, McGill University, Montreal, Canada, (2002) [4] Galushkin A.I.: Neural Networks Theory. Springer, New York (2007) [5] He X., Xu S.: Process Neural Networks - Theory and Applications. Springer-Verlag, Berlín (2009) [6] Martínez S.L., Tarifa E.E., Sánchez Rivero V.D.: Control neuronal tipo MIMO aplicado a un mezclador de corrientes líquidas. En: Investigaciones en Facultades de Ingeniería del NOA, T2, pp. 865-874. Catamarca, Argentina (2011) [7] Poznyak A.S., Sanchez E.N., Yu W.: Differential Neural Networks for Robust Nonlinear Control. World Scientific Publishing, Singapore (2001) [8] Blum A.: Neural Networks in C++: An Object-Oriented Framework for Building Connectionist Systems. John Wiley & Sons Inc, New York (1992) [9] Berry M. J. A., Linoff G. S.: Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management. John Wiley & Sons, New York (2011) [10] Goethals P.L., Dedecker A.P., Gabriels W., Lek S., De Pauw N.: Applications of artificial neural networks predicting macroinvertebrates in freshwaters. Springer - Aquatic Ecology, V. 41, pp. 491-508 (2007)

1373

A Fault Resilience Tool for Embedded Real-Time Systems Franklin Lima Santos1, FlĂĄvia Maristela Santos Nascimento2 1 Federal University of Bahia Department of Electric Engineering franklin_lima@ieee.org 2 Federal Institute of Bahia Department of Electro-Electronic Technologies flaviamsn@ifba.edu.br

Abstract. Real-time systems have been used in many different areas such as medicine, multimedia and mechatronics. For such systems, it is important to meet both logical and timing requirements, since a malfunction may have undesired consequences. In this paper, we developed a simulation tool in MATLABÂŽ environment to deal with fault-tolerant real-time scheduling under Rate Monotonic scheduling policy, so that errors consequences can be envisioned, before system is put on operation.

Keywords: Real-time systems, fault-tolerance, simulation, MATLABÂŽ.

Introduction

Over the past decades computer designers focused their attention on developing what they considered a perfect computer project: computers had to be small, fast and cheap [12]. Indeed, their effort in reaching more performance at low cost and minimum size contributed remarkably for recent technological advances, especially those related to hardware improvements. The remarkable growth of electronic devices and computing systems in our daily activities has been boosting mechatronics, as a subarea of automation due to its ability of integrating electronic components and systems [4, 7]. The main elements of a mechatronic system can be observed in Figure 1.

Fig. 1. Components of a mechatronic system [10].

1374

The user is the entity responsible for monitoring, super visioning and controlling the controlled object, which may be an airplane board control or an industrial plant, for example. Controlled objects are usually manipulated through human-machine interface (HMI), which is the element responsible for (i) translating control information to the user and (ii) allowing an interface between users and controlled objects. The control system is an interactive computer system that enables monitoring and changing the state of a controlled object, which is done through sensors and actuators [8]. The evolution of computer systems also allowed systems designers to focus on modeling, designing and implementation aspects of such systems aiming at developing applications with differentiated performance skills. At the same time, miniaturization of electronic components allowed computers to evolve from simply terminals to host control systems. For some of these applications correctness were not only associated with logical, but also with timing requirements. Indeed, systems in which correctness is associated not only with producing logically correct results, but also with the time at which such results are produced (timeliness) are known as realtime systems [2,5]. Real-time systems are present in many different areas such as medicine, avionics, multimedia and mechatronics [13]. For some of them, when timing requirements are not accomplished, the system may not achieve the expected level of Quality of Service (QoS). This is what happens, for example, in a video transmission (multimedia application). In worst cases, missing timing requirements may have undesired consequences as for example, if we consider an automobile ABS control, in which human life may be at risk [3]. This evidenced that different applications may have different criticality levels. Indeed, for "soft" real-time systems missing deadlines may not have more serious consequences, while for "hard" real-time systems missing deadlines may cause injuries for human beings and/or environment [2, 9, 11]. Since temporal requirements play an important role for real-time systems, it is crucial to have means of guaranteeing such requirements. In fact, both scheduling policies and schedulability analysis are responsible for ensuring timeliness for such applications. To do so, system tasks are ordered according to a specific scheduling policy and a subsequent schedulability analysis is performed to assess timeliness of each task. We detail such aspects in Section 2. Ensuring reliability is an important goal to be achieved for real-time systems. However, in terms of computational applications, the only certainty we have is that all of them may potentially fail [1]. In fact, system correctness relies on its dependability, a concept which discussed in Section 3. Also, since faults cannot be avoided and are difficult to predict [9, 11], taking such events into consideration is almost an obligation, if someone needs to guarantee QoS for real-time applications or even avoid more serious consequences. In this paper we investigate the impact of errors in real-time applications considering a specific scheduling policy. To do so, we defined a simulation environment, presented in Section 4 and developed a simulation tool, detailed in Section 5, which aims at measuring fault resilience for a particular set of real-time systems. Last, in Section 6, some conclusions and future works are drawn.

1375

Real-Time System Overview

A real-time system is a computer system in which both timing and logical requirements must be respected. Thus, the correct behavior of such a system depends not only on the integrity of produced logical results (also known as "correctness"), but also on the time at which they are produced ("timeliness") [2]. Examples of real-time systems include current control laboratory experiments, vehicle control, nuclear plants and flight control systems [13]. Usually, real-time systems are structured as a set of n periodic tasks Г = {τ1, τ2, … τn}. A given task τi represents a function, routine (or subroutine) or any code snippet. Each task τi has attributes such as an execution cost Ci, a deadline Di, an activation period Ti and a recovery execution cost Ci. Thus, a periodic task can be described as an ordered tuple τi = (Ci, Ti, Di, Ci). Tasks are executed in a specific order called execution scale. Such a scale is defined based on some heuristics, known as scheduling policy. Several scheduling policies have been addressed in literature and most of them are priority oriented [3, 9, 10], which means that tasks are ordered according to its priority. A well-known priority oriented scheduling policy is Rate Monotonic (RM), according to which tasks with shortest periods have higher priority. Clearly, this is a fixed-priority policy, since tasks period are defined offline and do not change during system execution. After a scheduling policy is chosen for a given task set Г is it important to assess if any task τi ϵ Г may miss its deadline. To do so, we perform some tests, also known as schedulability analysis, which aims at determining if a given task set is feasible. In other words, such tests determine if any task τi ϵ Г misses its deadline. Clearly, schedulability analysis is strongly linked with the chosen scheduling policy. In this paper we address the analysis based on Processor Utilization Analysis, which is discussed in Section 2.1. 2.1 Processor Utilization Analysis According to this approach, the schedulability of a given task set is assessed based on processor use. Indeed, processor utilization U, for a given task set Г composed of n a periodic and independent real-time task is given by: (1) Regarding Rate Monotonic, if we assume a periodic task set Г in which tasks period are equal to their deadlines, we state that Г is schedulable if: (2)

1376

For RM, Processor Utilization Analysis is a sufficient schedulability test, which means that it is not able to ensure schedulability for all task sets. In fact, it has been proven that [6] if: (3) The task set is schedulable with RM. Otherwise the analysis does not guarantee schedulability. Also, Rate Monotonic is considered an optimal algorithm for systems in which tasks period are equal to their deadlines (Ti = Di) [6].

Fault-Tolerant Real-Time Systems

Faults are random events that cannot be predicted or avoided. Actually, the only certainty we have is that all computational applications potentially fail [1]. Indeed, a fault may be caused by several different events, as for example cosmic radiation, hardware fatigue or malfunctioning, specification and/or implementation aspects. A system is said to fail when there is a transition from an expected correct behaviour to an incorrect and unexpected behaviour. In other words, a fail represents a deviation from specification. The error is the state that leads the system to fail and faults are the causes of an error, which may be physical or algorithmic [1]. Indeed, applications must provide confidence in the expected operations, a concept usually addressed as dependability, which is related to some attributes such as availability, reliability, safety and maintainability [1, 14]. In terms of real-time system there is a concern about fault tolerance aspects, since a fault may affect the system schedulability, or in other words, may prevent tasks to meet their deadlines. For this reason, faults are considered as a threat to dependability. Thus, techniques must be implemented to deal adequately with faults, so that applications keep their correctness even in the presence of such events [1, 14]. Faults are more commonly classified based on the persistence criterion, according to which they can be transient, intermittent or permanent. Transient faults occur only for a given time and then disappear. An example could be electromagnetic interference. When a transient fault occurs repeatedly it is called intermittent, as for example a loose contact on a connector. Both transient and intermittent faults are difficult to diagnose. Last, permanent fault is one that continues to exist until the faulty component is repaired, as for example a lack of connectivity between two nodes in a network [10, 14]. In this paper we investigate the effects of transient faults focusing on techniques that can be used to deal with such faults, which are based on temporal redundancy. This consists of repeating the computation in time, or in terms of scheduling can be understood as re-executing a task (see Figure 2) or executing an alternative task (see Figure 3) until the system is put on a safe state [9,11].

1377

Fig. 2. Recovery based on re-execution of Task 1 under RM}

Figures 2 and 3 presents a periodic task set being scheduled, where Г = {τ1 = (1,2), τ2 = (1,5)}. Observe that in Figure 2 an error occurred at t = 3 (red arrow), which affect Task 1. The faulty task re-executed immediately since there were no other higher priority task to execute. On the other hand, in Figure 3, an error affected Task 2 at t = 6 (red arrow), but it only could recover at time t = 7, since Task 1 was already released for execution and has a higher priority than Task 2.

Fig. 3. Recovery based on the execution of an alternative version of Task 2 under RM.

In the following sections we present the developed tool which focus on measuring the resilience of hard real-time systems scheduled according to RM scheduling policy.

Simulation Environment

4.1 System Model The assumed system model considers a task set Г composed of n independent and periodic real-time tasks Г = {τ1, τ2, … τn}. Each task τi is represented by a tuple τi = (Ci, Ti) where Ci is the constant worst-case execution time (wcet) of each task and Ti

1378

is the activation period. Also, we assume that the deadline for each task is the same as its period (Ti = Di). Tasks are scheduled according to Rate Monotonic, since this algorithm deals with fixed priority tasks and is widely used for embedded critical applications. Also, schedulability analysis is performed with Processor Utilization Analysis. 4.2 Fault Model Assuming a specific fault model is a difficult task since faults are random and cannot be predicted. We consider that the system is subject to multiple transient faults which can occur at any time instant. Also, we represent the fault resilience of a given system through the maximum number of errors the system can handle and keep its correct behavior. To do so, we use a random function in MATLAB速 to generate the number of errors that will affect each system. Also, the time instant in which errors occur is also determined through a random procedure. We discard errors that occur at time instants in which no task is executing, since such errors will not affect system behavior. We assume that fault detection occurs implicitly, at the end of each task execution, since the focus of the work is not the detection procedure, but system behavior after recovery strategies. 4.3 Recovery Model The recovery model describes the strategy used to put the system in a safe state. Indeed, we consider two possible actions: (i) faulty task re-execution or (ii) execution of an alternative task. Both strategies are defined offline, before running the system, and are performed in idle time instants available in execution scale.

Simulation Tool

The general overview of the developed tool can be seen in Figure 4. The tool was developed in MATLAB速, due to its versatility on numerical analysis, encapsulated functions and graphics.

Fig. 4. Framework of Simulation Environment

1379

The first step to use this tool is to input a schedulable task set. In case the user has no previously generated task set, it is possible to generate a random one inside developed environment. To so, the user only has to choose the number of tasks to be generated. In case the tool generates the task set, it also tests if it is schedulable, through processor utilization analysis. After, the user has to generate the number of errors that will affect the task set. As mentioned before, such a number is randomly generated by the tool. The user only defines a lower and upper bound, which will represent the interval in which the number of errors will be in. Based on the number of errors, the tool generates random time instants in which errors will occur. The screen of MATLAB® running the simulator can be seen in Figure 5.

Fig. 5. Screen shot of MATLAB® running simulator. The simulation environment will generate an execution scale, which takes into consideration Rate Monotonic, as scheduling policy, the defined recovery scheme (reexecution or alternative task code) and the time instants in which errors occur. Based on those values, the system resilience is defined and results can be graphically checked. Briefly, the simulator executes the following steps, given the inputs described in Figure 4: • Identify tasks affected by errors; • Identify idle time after each faulty task, which can be used for recovery; • Verify the possibility of re-executing the faulty task or executing an alternative code, respecting tasks priority (including the simultaneous verification of space for recovery and maximum execution time); • Graphically analyze the resilience of the system, through graphically generated execution scale. • Inform the number of errors and time instant which makes the system unschedulable.

1380

To make things clear let us consider the following example: Example 5.1. Assume a task set Đ&#x201C; = {Ď&#x201E;1, Ď&#x201E;2} composed of two independent and periodic tasks where C = (3, 3) and D = T = (8, 12). Tasks are scheduled according to RM and in case of faults, tasks are re-executed. In other words, Ci = Ci.

Fig. 6. Execution Scale for Example 5.1.

The system is simulated during the hyperperiod h = lcm(8, 12) = 241 to ensure that all system execution will be considered.

Fig. 7. Idle processor time for Example 5.1, graphically represented in tool.

The first chart presented in Figure 6 presents the execution scale for the given task set. The random number of faults that this task set is subject to is nf = 2 and the random time instants in which they occur was tf = (3, 18). This is shown by a red mark in the chart. Detected errors are indicated by green circles. Figure 7 evidences the idle processor time, which are represented in blue. Finally, Figure 8 presents the fault-tolerant real-time schedule.

Fig. 8. Fault Tolerant Scheduling for Example 5.1 assuming errors at tf = (3, 18). 1 lcm(x, y) is the function which calculates the least common multiple of input parameters ,in this case, x and y. Usually systems are simulated during the hyperperiod, since it contains all system behavior.

1381

It is important to mention that depending on the time instant that errors occur, the system may not be schedulable, even if it is subject to the same number of errors. Observe Figure 9, which presents the same task set described in Example 5.1 subject to two errors that happens at tf = (2, 3).

Fig. 9. Execution Scale for Example 5.1 assuming errors at tf = (2, 3).

Observe that in this case, recovery of both faulty tasks is not possible, since the available idle time (same as presented in Figure 7) is not enough for recovering tasks Ď&#x201E;1 and Ď&#x201E;2. before their respective deadlines. The graphic presented by simulator is according to Figure 10, confirming that the fault-tolerant scheduling is not feasible.

Fig. 10. Fault Tolerant Scheduling for Example 5.1 assuming errors at tf = (2, 3).

Conclusions and Future Work

Real-time systems have been used in a wide range area, as for example to control industrial processes. For most of these applications, missing timing requirements imply in a loss of Quality of Service or in worst cases may cause social, economic and/or environmental injuries. In this context, it is extremely necessary to deal with unpredictable and random events, such as faults, so that they interfere minimally in systems operation. In this paper we developed a simulation tool in MATLABÂŽ environment to deal with fault-tolerant real-time scheduling, so that errors consequences can be envisioned, before system is put on operation. One of our goals is to have an approximation between theoretical and practical models. This will enable more detailed studies and previous use of simulations before the applications are put into production. As future work we aim at simulating more robust systems, to evaluate better our preliminary results. Also, we focus on extending scheduling policies, so that EDF [6] is also considered.

1382

Thanks

The authors would like to thank the Federal Institute of Bahia (IFBA) for all support and National Council for Scientific and Technological Development (CNPq) for funding this work.

References 1.

4. 5.

6. 7.

8. 9.

10. 11.

12. 13. 14.

Algirdas Avizienis, Jean-Claude Laprie, Carl Landwehr, and Brian Randell. Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1):11–33, 2004. Jean-Marie Farines, Joni da Silva Fraga, and Rômulo Silva de Oliveira. Sistemas de Tempo Real. Departamento de Automa¸c˜ao e Sistemas - Universidade Federal de Santa Catarina, Florianópolis, Santa Catarina, 2000. Sunondo Ghosh, Rami Melhem, and Daniel Moss´e. Fault-Tolerant Scheduling on a Hard Real-Time Multiprocessor System. In Proccedings of Eighth International Symposium on Parallel Processing, pages 775 – 782, April 1994. Rolf Isermann. Modeling and design methodology for mechatronic systems. IEEE/ASME Transactions on Mechatronics, 1(1):16–28, 1996. Li Jie, Guo Ruifeng, and Shao Zhixiang. The Research of Scheduling Algorithms in RealTime System. In International Conference on Computer and Communication Technologies in Agriculture Engineering (CCTAE’10), volume 1, pages 333 – 336, June 2010. C. L. Liu and James W. Layland. Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment. Journal of the ACM, 20(1):46–61, 1973. Ren C. Luo. Sensors and actuators for intelligent mechatronic systems. In 27th Annual Conference of the IEEE on Industrial Electronics Society, 2001. IECON’01, volume 3, pages 2062–2065, 2001. Paulo Eigi Miyagi and Emilia Villani. Mecatrônica como solução de automação. In Revista Ciências Exatas. Universidade de Taubaté, 2004. Flávia Maristela Nascimento, George Lima, and Verônica Cadena Lima. Deriving a fault resilience metric for real-time systems. In Workshop de Testes e Tolerância a Falhas, August 2009. Flávia Maristela Santos Nascimento. A Simulation-Based Fault Resilience Analysis for Real-Time Systems, 2009. George Lima, Flávia Maristela Santos Nascimento, Verônica Lima. Fault resilience analysis for real-time systems. In Proceedings of the 1st International Workshop on Analysis Tools and Methodologies for Embedded and Real-Time Systems, pages 35 – 38, Brussels, Belgium, October 2010. Mircea R. Stan and Kevin Skadron. Power-Aware Computing. Computer, 36:35 – 38, December 2003. John Stankovic. Misconceptions about real-time computing: a serious problem for nextgeneration systems. Computer, 21(10):10–19, 1988. Andrew S. Tanenbaum and Maarten van Steen. Distributed Systems: Principles and Paradigms. Prentice Hall, 2006.

1383

Application of Zigbee Technology for Monitoring Enviromental Variables in Greenhouses Juan Carlos Su谩rez Bar贸n1 1

Assistant Research Faculty of Engineering, Universidad Nacional Abierta y a Distancia, UNAD Duitama, Colombia

jsuarezbaron@gmail.com

Abstract. This paper describes the application of the Zigbee standard for the development of a Wireless Sensor Networks (WSN) based system, which is used for monitoring environmental variables in greenhouses. This development allows to connect multiple wireless devices for the sake of transmitting variables such as temperature and relative humidity. The Zigbee platform was made in three stages: 1) hardware development, which includes the analysis and hardware selection; 2) construction of a network and the integration of sensors; and, 3) evaluation, in order to define the specifications of each node and scope of communication. Keywords: Environment variables, Greenhouses, WSN, Zigbee.

1 Introduction Greenhouses are used to reduce the influence of adverse factors that limit production and quality of crops. They include the control of environmental variables and make an efficient use of water. On the other hand, modern greenhouses covers several hundreds of square meters, where the location to measure temperature, humidity and lighting is carefully chosen in order to improve production efficiency; thus, a Wireless Sensor Network (WSN) is required. A WSN system includes several spatially distributed devices that use sensors to monitor various conditions in several points, including temperature, sound, vibration, pressure, motion and pollutants [1]. WSN systems have been used for various applications, e.g. habitat monitoring, agriculture, industrial monitoring and control, electronics, home automation and medical health care [2]. There are different technologies for WSN; however, the technology known as Zigbee is one of most widespread. Zigbee was developed for applications where energy consumption and complexity are the main concern. Zigbee is suitable for communicating sensors, actuators and other small devices among them. It makes use of a narrow bandwidth, low energy consumption and low latency [3]. Zigbee is based on the IEEE 802.15.4 standard and defines the hardware and software described in terms of network connection, such as physical layer (PHY) layer and medium access control (MAC). Basically, the system developed in present work consists of a sensor node and a coordinator device. The sensor node is basically a data acquisition unit, and it is responsible for collecting climate variables such as temperature, relative humidity,

1384

and light, and transmits the collected data to the coordinator station through Zigbee modules. 2 Background Wireless sensor networks represent a significant advance over traditional invasive methods for the monitoring species, which can achieve lower costs and errors in the measurement process [4]. For instance, WSN are used for monitoring the reproductive behavior of birds in the Great Duck Island (Maine, USA), as described in [5]. This system enables biologists the analyzing of changes in the environmental conditions inside and outside the burrows during the breeding season. On the other hand, environmental conditions are also a concern. It is developed in [6] a monitoring system of the pollution caused by the emission of gases from car exhausts. The data generated by the gas sensors are transmitted to remote stations via Zigbee modules. Similar Zigbee based systems have been used to monitor water quality in rivers and lakes, as explained in [7], [8]. In agriculture, wireless sensor networks are used to increase efficiency in the production and growth of the crop. Usually, sensed data correspond to environmental conditions such as temperature, wind speed, wind direction, soil moisture and physical and chemical properties of soil such as pH [9]. Another way to increase efficiency in crops is by water resource management; and in this respect, several systems based on sensor networks have been implemented. In [10] it is described the development of a crop irrigation control system in Pakistan. This system makes use of wireless sensor-actuator networks (WSAN) to monitor environmental parameters, which are sent through Zigbee modules to a computer. These variables serve as inputs to the control system. Additionally, the authors in [11] propose the design and implementation of an irrigation system based on low-cost Zigbee technology. Monitored variables are temperature and humidity. The other hand, in [12] it is introduced the use of a wireless sensor network based on Zigbee technology (ZWSN). The climatic variables monitored are temperature, speed and direction of air, relative humidity and rainfall. The data and images related to the amount of leaves and fruits are sent to a personal digital assistant (PDA), which processes and displays the information in order to monitor, in a detailed way, the evolution of diseases. In particular, the impact caused by fruit fly is tracked. Finally, the authors in [13] develop a wireless sensor network based on Zigbee technology, which uses MPWiNodeZ devices, intended for precision viticulture applications. A mesh topology network is utilized to monitor the moisture content of soil, air temperature, relative humidity and solar radiation.

3 Materials and Methods 3.1 System description and hardware development The system consists on a sensor node and a coordinator device that are communicated between them. The sensor node is basically a data acquisition unit, and it is responsible for collecting climate variables such as temperature, relative humidity and

1385

light. In addition, the system transmits the collected data to the coordinator station through Zigbee modules. In this work, SHT71 was selected as the integrated temperature and humidity sensor chip. Regarding humidity, the operating range is from 0 to100%, and the operating range of temperature is from -40 to 125 °C. SHT71 sensors have low power consumption and fast response time. Temperature accuracy is ± 0.4°C and the accuracy of the relative humidity is less than ±3.0 %. Therefore, SHT71 is a good solution for monitoring these variables in the agriculture field [14]. The coordinator system, who acts as a central station, is responsible for receiving the data acquired by the sensor nodes forming a star topology network. This system process, stores and provides to the user a convenient and easy way of displaying real time information by means of a GUI (Graphic user interface) on an LCD device. The functional diagram of the system is showed in Fig 1.

Fig. 1. Structure of wireless monitoring system. (System Overview)

3.2 Prototype network node and the integration of sensors. The sensor node is composed by four (4) elements: The module of sensors The processing module The wireless communication module

1386

The power supply module 3.2.1 Sensor Node Design The sensor module is responsible for collecting information about temperature and relative humidity. The processing module stores and processes data collected by the sensors, and controls the operation of the sensors node; which are achieved by using a microcontroller (MCU). An HCS08 based MCU, the MC9S08JM16, was selected as the main control chip of the sensor node. HCS08 MCUs are suitable due to their processing and memory capacities, being sufficient to support Zigbee. The wireless communication module communicates with other nodes, allowing the exchanging (receiving/transmitting) of data. The power supply device provides energy to the sensor, processing and the wireless communication modules. The power supply of the sensor node corresponds to a 9V alkaline (Zn/MnO2) battery. Using a battery is a low cost, portable and low maintenance solution. On the other hand, the Xbee module, SHT71 sensor and MC9S08JM60 microcontroller require 3.3 V, which are provided by an LM1117 regulator. The block diagram of the sensor node or end device shown in Fig 2.

Fig. 2. Block diagram of sensor node.

The final design consists of two PCB layers. The top layer is used to place the XBee module, LEDs (power, Rx and Tx indicators), microcontroller, SHT71 sensor, battery plug, and on/off switch. Bottom layer is used to place3.3V voltage regulator and as a ground plane under XBee module to minimize any interference cause by the RF signals. An important aspect of the design was miniaturization. Therefore most circuitry components used for the sensor station are either surface-mounted (SMD) or are very small in size. The final design of the sensor node is shown on Fig 3.

1387

Fig. 3. Final design of the sensor node.

3.2.2 Coordinator Design The coordinator receives the signals from the sensor node, and then it integrates and stores the data automatically. The coordinator is composed by five parts: processing module, wireless communication module, power module, display module, and USB communication module. The processing module controls the operation of the sensor nodes; and, stores and processes the collected data. The wireless communication module is responsible of receiving/transmitting data from/to the sensor node. The power supply module provides power to the other modules. The data logger is responsible for storing the sensor data, which are displayed on a liquid crystal display LCD. The union of these allows the coordinator to periodically receive data from the sensor node. The block diagram of coordinator system is shown in Fig 4.

Fig. 4. Block diagram of coordinator device.

For the coordinator, as well as in the sensor node, the XBee modules based on the IEEE 802.15.4/Zigbee Wireless Personal Area Network (WPAN) standards to build a

1388

low-power, low-maintenance, and self-organizing WSN [15] was used. Small size, low power, low cost and long battery life are the reasons of using ZigBee. In case of the hub, the power supply is derived from the PC's USB port via a connector type B. The data logger module includes an LCD and five buttons that are utilized select the physical variables to be displayed and stored in an SD memory card. In order communicate the PC to the coordinator, it was used an FT2232D FTDI chip. The final design of the sensor coordinate is shown on Fig 5.

Fig. 5. Final design of the coordinator.

3.3 Sensor Configuration The temperature sensor output was set to 12 bit format, and RH was configured to 8 bit format; thus, it is achieved an accuracy of 0.04 C and 0.5 for temperature and RH variables, respectively. The sensor and the microcontroller interact by using IÂ˛C protocol, hence only two pins on the microcontroller are required. One of the pins will be used for synchronization while the other is utilized for bidirectional data transfer between the two devices. The pin on the microcontroller that is used for Rx/Tx was pulled up in order to prevent signal contention. In order to interact adequately with the sensor, a specific sequence of events must be followed. The flow chart in Figure 8 illustrates the events to be followed in order to request the sensor to take measurements such that the information can be read. 3.4 Communication between devices The communication of the SHT71 sensor with the microcontroller MC9S08JM16 was through IÂ˛C module. This is possible because there is not any device connected to the IÂ˛C output of the microcontroller, thus it does not generate interferences [16]. Communication with this sensor requires the implementation of a protocol, which is very similar but not compatible with the I2C standard. Therefore, the context integration is strictly controlled. The protocol includes a start condition, and data block both reading and writing with ACK bit. The communication is based into two

1389

pins; a clock (SCK), that is used to synchronize the microcontroller and the sensor; and, the bidirectional data pin.

4. Results and Discussion After verifying proper communication between the various elements of the system built, we proceeded to test the proper connectivity to all the prototype and the proper functioning of the tasks. In order to emulate a greenhouse environment, it was set a space containing two ornamental plants. Near each plant, it was located a sensor node that measures relative humidity and temperature around the plants. The sensor node outcomes are visualized on the LCD. Fig 6 shows the plants and the corresponding measures shown on the LCD.

Fig. 6. Plants 1y 2 of the test displayed in the LCD.

The results of test are depicted in Fig 7 and Fig 8. The results obtained from the experiments show small variations between the readings of the SHT71 sensor for the two tests. Future experiments will entail comparing data collected from these sensors with calibrated standard devices for the sake of obtaining more accurate results.

1390

Fig. 7. SHT71 experimental results (Ambient Temperature)

Fig. 8. SHT71 experimental results (Relative Humidity)

Other experiment consisted on verifying the communication between the two Xbee modules. Figure 9 describes the distances that separate the sender (red icon) of the receptor (blue icon). Measures were taken of packet reception and level RSSI (Received Signal Strengh Indicator) of the received packet to 30 m, 60 m and 100 m away. For the test used two Xbee devices, two laptops and two USB boards for development of digi connected. In the X-CTU software was used Range-test option with its default settings. This configuration is sending 32 bytes of data from one device to another, which returns the data frame to the origin. Others experimental results were based on the Lost Packets with values between 0 to 1000 and LQI within typical values between -95dBm to -18dBm according to IEEE 802.15.4 [16]. Below are the results of the experimental measures of three sequences, with 5, 10 and 20 bytes of payload size per packet, and a Zigbee Network implementation with Monitoring Environmental Variables network. In Fig 10, measures of LQI and Lost packages are shown respectively for 5 bytes in payload per packet.

1391

Fig. 9. Diagram for test of outdoor. Data transmissions - 5 bytes in payload per packet -20

Low Power Outdoor Half Power Outdoor High Power Outdoor Low Power Underground Half Power Underground High Power Underground

-30

LQI (dBm)

-40

-50 -60 -70

-80 -90 0

40 50 60 Distance (m)

100

Fig. 10. Graphics of LQI vs. distance between devices

5. Conclusions and Future Work In this work, it is presented a wireless solution for greenhouse monitoring. The system is based on HCS08 Freescale MCUÂ´s, which monitors environmental variables through SHT71 humidity/temperaure sensor and uses and Xbee modules. Also, it is shown the design of the wireless nodes, network establishment and the software system. Monitoring system is based on ZigBee standard and provides nearly unlimited installation of transducers, which increases network robustness and reduces considerably installation costs. The designed wireless monitoring system uses different sensors and has capability to measure different types of environmental parameters. Developed system helps farmers to increase the harvest production with a better quality. Additionally, it has capability to detect changes in the environment. Finally, the system was tested in a greenhouse located in BoyacĂĄ-Colombia. It is concluded that the ZigBee-based monitoring system is a good solution for greenhouse monitoring. As future work, I aim to develop a neural network system in order to

1392

carry out intelligent control; this element will be constructed together with a model for data mining and system decision support.

References 1.

Aakvaag, N., Frey, J.-E.: Redes de sensores inalámbricos. Revista ABB, 39-42 (2006)

KeKeshtgari, M., Deljoo, A.: A Wireless Sensor Network Solution for Precision Agriculture Based on ZigBee Technology. Journal Wireless Sensor Network IV, 25-30 (2012) Zigbee Alliance: Zigbee Specification 053474r17. Available at: http://www.zigbee.org

3. 4. 5. 6. 7. 8.

9. 10.

11.

12.

13. 14.

Cifuentes García, C.: Diseño e implementación de una red inalámbrica de sensores aplicados a la instrumentación biomédica. Tésis de maestría. Universidad Nacional de Entre Ríos, Oro Verde (2010) Mainwaring, A., Polastre, J., Szewczyk, R., Culler, D., Anderson, J.: Wireless Sensor Networks for Habitat Monitoring. In : WSNA’02 (2002) Eren, H., Al-Ghamdi, A., Luo, J.: Application of ZigBee for Pollution Monitoring Caused by Automobile Exhaust Gases. In IEEE, ed. : SAS 2009 IEEE Sensors Applications Symposium, New Orleans, LA (2009) Wang, X., Ma, L., Yang, H.: Online Water Monitoring System Based on ZigBee and GPRS. Science Direct. Procedia Engineering(15), 2680 – 2684 (2011) Azwan Nasirudin, M., Nurulhaiza Za’bah, U., Sidek, O.: Fresh Water Real-Time Monitoring System Based on Wireless Sensor Network and GSM. In IEEE, ed. : 2011 IEEE Conference on Open Systems (ICOS2011), Langkawi, Malasia, pp.354-357 (2011) Kalaivani, T., Allirani, A., Priya, A.: A survey on Zigbee Based Wireless Sensor Networks in agriculture. In IEEE, ed. : 3rd International Conference on Trendz in Information Sciences and Computing (TISC) 2011, pp.85-89 (2011) Aqeel-ur-Rehman, S., Yousuf, H., Nawaz, F., Kirmani, M., Kiran, S.: Crop irrigation control using Wireless Sensor and Actuator Network (WSAN). In IEEE, ed. : International Conference on Information and Emerging Technologies (ICIET) 2010, pp.1-5 (2010) Zhou, Y., Yang, X., Wang, L., Ying, Y.: A wireless design of low-cost irrigation system using ZigBee technology. In Society, I., ed. : 2009 International Conference on Networks Security, Wireless Communications and Trusted Computing , pp.572 - 575 (2009) Jiménez, A., Ravelo, D., Gómez, J.: Sistema de adquisición, almacenamiento y análisis de información fenológica para el manejo de plagas y enfermedades de un duraznero mediante tecnologías de agrícultura de precisión. Tecnura. Redalyc XIV(27), 41-51 (2009) Morais, R., Fernandes, M., Matos, S., Serôdio, C., Ferreira, P., Reis, M.: A ZigBe multi-powered wireless acquisition device for remote sensing applications in precision viticulture. E. B.V II(62), 94-106 (2008) Kovács, Z., Marosy, G., Gyula, H.: Case study of a simple, low power WSN implementation for forest monitoring. In IEEE, ed. : Biennial Baltic Electronics Conference (BEC2010) , Tallinn, Estonia, pp.161-164 (2010)

1393

15.

16.

Digi International Inc: XBee ZNet2.5/XBee-PRO ZNet2.5 OEM RF Modules, Product Manual v1.x.4x - ZigBee Protocol For OEM RF Module Part Numbers: XB24-BxIT00x. In: Digi International Inc 11001 Bren Road East Minnetonka, MN 55343877 9123444 or 952 912-3444. Available at: http://www.digi.com Sensirion AG: Datasheet SHT7x (SHT71, SHT75) Humidity and Temperature Sensor IC. (Accessed 2011) Available at: http://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/Hu midity/Sensirion_Humidity_SHT7x_Datasheet_V5.pdf

1394

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones Ra´ ul Benencia, Luciano Iglesias, Fernando Romero y Fernando G. Tinetti** Instituto de Investigaci´ on en Inform´ atica III-LIDI Facultad de Inform´ atica, UNLP rbenencia@linti.unlp.edu.ar,li@info.unlp.edu.ar, {fromero,fernando}@lidi.info.unlp.edu.ar, http://weblidi.info.unlp.edu.ar

Resumen La planificaci´ on de tareas es el punto crucial de un sistema de tiempo real. Dicha funci´ on es llevada a cabo por el planificador del sistema operativo, dise˜ nado para poder cumplir con las restricciones temporales de dichas tareas, teniendo en cuenta sus valores de prioridad. Al haber recursos compartidos por estas tareas, se produce el efecto llamado inversi´ on de prioridades. En este trabajo se analiza dicho efecto y se eval´ uan las soluciones implementadas para este problema en el Sistema Operativo de Tiempo Real GNU/Linux con parche RT-PREEMPT. Keywords: Planificaci´ on de tareas de tiempo real, inversi´ on de prioridades, GNU/Linux con parche RT-PREEMPT, Sistemas Operativos de Tiempo Real

Introducci´ on

Los sistemas de tiempo real requieren ser correctos lógica y temporalmente. Se deben respetar las restricciones de tiempo en la ejecución de las tareas. De acuerdo a la funci´ on que realizan, las tareas pueden requerir plazos estrictos o plazos m´ as relajados. Esto conlleva a la necesidad de una planificación basada en prioridades fijas, de manera de asegurar los l´ımites estrictos. Este tipo de planificaci´ on es respecto de uno de los recursos compartidos por las diversas tareas, implicadas en la ejecución, la CPU. De tal manera que si un proceso que implementa una tarea de baja prioridad está usando la CPU y otro proceso con una prioridad mayor requiere su uso, está previsto el desalojo del proceso de menor prioridad para asign´ arsela al de mayor prioridad. El resto de los recursos compartidos por las tareas suele planificarse por demanda (FCFS). Al producirse situaciones de bloqueo de estos recursos, que requieren usarse en forma exclusiva (regi´ on cr´ıtica), puede pasar que el proceso de mayor prioridad quede relegado por uno de menor prioridad. Esta situación se denomina inversi´ on de prioridades [2] y se puede agravar si procesos de prioridad intermedia logran hacerse de la CPU antes de que la tarea de prioridad baja libere el recurso que espera la de **

Investigador CICPBA

1395

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones

alta prioridad. Con lo cual la duración de la inversión de prioridades puede ser ilimitada y no permitir a la tarea de mayor prioridad cumplir con sus restricciones temporales. Los Sistemas Operativos de Tiempo Real suelen contar con mecanismos para atenuar este problema. En rigor, estos mecanismos no evitan la inversi´ on de prioridades, solo la inversión de prioridades ilimitada.

Descripci´ on del problema y soluciones existentes

Los Sistemas de Tiempo Real suelen realizar tareas con diferente nivel de urgencia. Si bien todas las tareas pueden tener restricciones temporales para su ejecuci´ on, estas restricciones pueden ser estrictas (hard real-time) o menos estrictas (soft real-time) [3]. Esto es manejado por los Sistemas Operativos de Tiempo Real de diferentes maneras. Esto se conoce como planificación de tareas. Uno de los métodos de planificación de tareas se realiza asignando diferentes niveles de prioridad, de tal manera que si se debe incumplir una restricción temporal sea de las tareas con menor nivel de prioridad. A su vez, estas tareas suelen estar implementadas por threads, que se caracterizan por compartir memoria y otros recursos. Esto genera un problema llamado inversión de prioridades, que se describe a continuaci´ on: considérese un proceso con prioridad alta, el proceso H, y otro con prioridad baja, el proceso L. Ambos procesos interact´ uan con el recurso r y, para evitar inconsistencias, deben proteger sus respectivas secciones cr´ıticas con un mutex, por ejemplo. Si el proceso H intenta utilizar r mientras L mantiene un lock sobre el mismo, entonces H no podrá continuar su tarea hasta que L no libere el recurso. Hasta aqu´ı se plantea una situación normal. El procedimiento correcto a seguir es asignar el procesador a L para que libere a r lo m´ as pronto posible, para que luego H pueda adquirir el lock sobre el recurso y as´ı continuar su tarea. Sin embargo, el problema de la inversión de prioridades se presenta cuando H espera a que L libere el lock, y mientras L intenta liberar el recurso, el mismo es interrumpido por un proceso de prioridad superior a L pero inferior a H. De esta forma, tanto el proceso L como el proceso H se ven rezagados por el proceso de prioridad media M. En algunos sistemas la inversión de prioridades puede pasar desapercibida puesto que, a pesar de las demoras, las restricciones de tiempo se cumplen y por lo tanto el sistema de tiempo real no falla. Sin embargo, existen numerosas situaciones donde la inversión de prioridades puede causar problemas cr´ıticos. Si un proceso de prioridad alta entra en estado de inanici´ on de los recursos que precisa, puede provocar una falla en el sistema que active medidas correctivas, como un watch-dog que reinicie por completo todo el sistema. 2.1.

El problema en un caso real: El Rover enviado a Marte

Tal vez el caso real m´ as conocido de inversi´on de prioridades fue el que ocurri´ o con el rover que se envi´ o al planeta Marte en la misi´on Mars Pathfinder [4] [5]. La misi´ on Mars Pathfinder fue catalogada como perfecta a los pocos d´ıas de su aterrizaje en la superficie marciana, el 4 de julio del a˜ no 1997. Durante

1396

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones

varios d´ıas el rover envi´ o cantidades voluminosas de datos, tales como imágenes panor´ amicas. Sin embargo, luego de pocos d´ıas de cumplir con las solicitudes requeridas desde el planeta Tierra, y no mucho después de que el rover comenzara a recolectar datos meteorológicos, el sistema operativo del robot comenzó a reiniciarse continuamente ocasionando severas pérdidas de datos. El problema se encontraba en la administración de las prioridades de VxWorks, el kernel de tiempo real embebido que usaba el Pathfinder. El planificador de VxWorks utilizaba apropiaci´ on por prioridades entre los threads. Las tareas en el rover eran ejecutadas como threads. La asignación de prioridades a los mismos se calculaba reflejando la urgencia relativa de dichas tareas. Además, el Pathfinder conten´ıa un bus de informaci´ on, similar a un área de memoria compartida, utilizado para comunicar informaci´ on entre los distintos componentes de la nave. El kernel VxWorks prove´ıa una tarea de alta prioridad dedicada a la administración de este bus, cuya funci´ on era mover ciertos tipos de datos desde y hacia el mencionado canal. La recolecci´ on de datos meteorológicos se realizaba con poca frecuencia en un thread de baja prioridad, y los datos adquiridos se distribu´ıan utilizando el bus de informaci´ on. Cuando los datos se distribu´ıan por el bus, se adquir´ıa el lock sobre un mutex, se escrib´ıa sobre el bus, y se liberaba el lock. Si una interrupci´ on causaba la apropiación de la CPU mientras el thread de baja prioridad manten´ıa el bloqueo sobre el bus, y el thread de alta prioridad que administraba dicho bus intentaba adquirir el mismo mutex con el objetivo de recibir estos datos, entonces dicho thread se bloqueaba hasta que el thread de baja prioridad liberase el mencionado mutex. Finalmente, el rover también conten´ıa una tarea dedicada a la comunicaci´ on que corr´ıa sobre un thread con prioridad media. La mayor parte del tiempo esta combinación de threads funcionaba correctamente. Sin embargo, con muy poca frecuencia ocurr´ıa que el thread de comunicaciones, de prioridad media, era interrumpido durante un corto intervalo de tiempo cuando el thread dedicado a la administración del bus, de prioridad alta, era bloqueado para esperar por los datos meteorológicos provistos por el thread de prioridad baja. Cuando se daba esta situación, el thread dedicado a las comunicaciones imped´ıa que el thread de baja prioridad pueda ejecutarse para liberar el mutex. Consecuentemente, el thread de administración del bus era efectivamente bloqueado por una tarea de menor prioridad, provocando de esta forma la inversi´ on de prioridades. Luego de un tiempo prudencial, un watch-dog timer del rover notaba el desperfecto y conclu´ıa que algo hab´ıa dejado de funcionar correctamente, provocando un reinicio total del sistema operativo [6]. 2.2.

Soluciones existentes

Se han propuesto diversas soluciones (protocolos) para el problema de la inversi´ on de prioridades, ac´ a se mencionan las principales [7]: 1. 2. 3. 4.

Herencia de prioridad (Priority inheritance) Techo de prioridad (Priority ceiling) Techo de prioridad inmediato (Inmediate priority ceiling) Enmascaramiento de interrupciones

1397

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones

5. Incremento aleatorio 6. Basado en la restauraci´ on del recurso (Shadowing) Herencia de prioridad La solución denominada herencia de prioridad propone eliminar la inversi´ on de prioridades elevando la prioridad de un proceso con un lock en un recurso compartido al máximo de las prioridades de los procesos que estén esperando dicho recurso. La idea de este protocolo consiste en que cuando un proceso bloquea indirectamente a procesos de más alta prioridad, la prioridad original es ignorada y ejecuta la sección cr´ıtica correspondiente con la prioridad m´ as alta de los procesos que está bloqueando. Por ejemplo, vuélvanse a considerar los procesos L, M y H de prioridad baja, media y alta respectivamente. Suponer que H est´ a bloqueado esperando a que L libere un lock sobre un recurso compartido. El protocolo de herencia de prioridad, entonces, requiere que L ejecute su secci´ on cr´ıtica con la prioridad de H. De esta forma, M no podr´ a apropiarse del procesador cuando L lo tenga en uso. Por lo tanto M, que es un proceso con m´ as prioridad que L, deberá esperar a que L ejecute su secci´ on cr´ıtica, ya que L hereda su prioridad de H. Luego, cuando L termina de ejecutar su secci´ on cr´ıtica, su prioridad vuelve a la normalidad y el proceso H es despertado. H, que tiene mayor prioridad que M, se apropia del procesador y se ejecuta hasta terminar. Finalmente, cuando H termina su ejecución prosigue el proceso M, y por u ´ltimo L termina su ejecución. El kernel Linux implementa la herencia de prioridades mediante un sencillo mecanismo que se basa en prohibir la apropiaci´ on del procesador mientras se esté ejecutando código del kernel protegido por un spinlock. Las desventajas que presenta este método son [8]: 1. Este método puede causar más cambios de contexto que el de techo de prioridad 2. El anidamiento de secciones cr´ıticas protegidas por herencia de prioridad puede producir grandes demoras debido a que cada vez que se cambia una prioridad de una tarea debe ejecutarse el planificador 3. El método falla si se mezclan tareas con y sin herencia de prioridad 4. El peor caso de herencia es peor que otras soluciones al problema 5. Seg´ un algunos autores, la mayor´ıa de las implementaciones de herencia de prioridad tienden a complicar el código de las secciones cr´ıticas, reduciendo finalmente el desempe˜ no del sistema [9] Techo de prioridad La solución denominada techo de prioridad es un protocolo que elimina la inversi´ on de prioridades mediante la asignación predefinida de un techo de prioridad a cada recurso. Cuando un proceso adquiere un recurso compartido, la prioridad de dicho proceso se eleva temporalmente al techo de prioridad del mencionado recurso. El techo de prioridad debe ser más alto que la prioridad de todos los procesos que puedan acceder al recurso compartido. De esta forma, cuando un proceso se esté ejecutando con el techo de prioridad de un recurso, el procesador no podrá ser apropiado por otro proceso que quiera acceder al mismo recurso, puesto que todos tendrán menor prioridad [10]. Las desventajas que tiene este método son:

1398

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones

1. Se debe realizar un an´ alisis estático de la aplicación para determinar cuáles ser´ an los techos de prioridad de cada recurso compartido. Para realizar este an´ alisis, todas las tareas que accedan a recursos compartidos deben conocerse de antemano. Esto puede ser dif´ıcil, o incluso imposible de determinar en una aplicaci´ on compleja [10] 2. La prioridad de los procesos aumenta y disminuye cada vez que se accede a un recurso compartido, a´ un cuando no haya procesos compitiendo por el mismo 3. Puede dar un bloqueo falso de threads [11] Esta soluci´ on fue propuesta por primera vez en 1980, en uno de los primeros papers que describi´ o el problema de la inversión de prioridades [12]. Techo de prioridad inmediato Es un derivado del Protocolo de Techo de Prioridad. En este protocolo, la tarea que accede a un recurso hereda inmediatamente el techo de prioridad del recurso. Este protocolo es mas fácil de implementar y es m´ as eficiente (hay menos cambios de contexto) [13]. Enmascaramiento de interrupciones El enmascaramiento de interrupciones también se puede utilizar para evitar la inversión de prioridades. En este caso, las interrupciones se enmascaran cuando un proceso entra en una sección cr´ıtica, y se vuelven a habilitar cuando sale de la misma. De esta forma, la inversión de prioridades no puede ocurrir puesto que todas las secciones cr´ıticas se ejecutan sin ser interrumpidas por procesos de mayor prioridad. Para que este mecanismo funcione correctamente, todas las interrupciones deben estar deshabilitadas. Si s´ olo algunas se enmascaran, entonces la inversión de prioridades podrá ser re-introducida por el mecanismo de gestión de interrupciones del hardware subyacente. Esta soluci´ on al problema de inversión de prioridad suele ser encontrada en sistemas embebidos, debido a su confiabilidad, bajo consumo de recursos y sencillez en su implementación. Las desventajas de este método son: 1. Requiere que las secciones cr´ıticas sean escasas y cortas, puesto que todo el sistema se ve bloqueado mientras un proceso se encuentra en una de ellas. 2. Mientras las interrupciones estén completamente enmascaradas los fallos de p´ agina no podr´ an ser atendidos [12]. Por este motivo, se desaconseja la implementaci´ on de esta solución en sistemas de propósito general. Incremento aleatorio La solución denominada incremento aleatorio propone eliminar la inversi´ on de prioridades mediante el incremento de la prioridad de los procesos de baja prioridad que contengan locks sobre recursos compartidos. La elecci´ on del proceso cuya prioridad será incrementada se realiza de forma aleatoria, de ah´ı el nombre de la técnica. El incremento de la prioridad se mantiene hasta que el lock sea liberado. Esta técnica es utilizada en sistemas operativos Microsoft Windows [14]

1399

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones

Basado en la restauraci´ on del recurso Se basa en la técnica de desalojo de la tarea de menor prioridad que toma el recurso al arribar una tarea de mayor prioridad. Hay dos variantes: mantener un log de lo actuado por el de menor prioridad en el recurso y deshacer los cambios de manera inversa o que la tarea de menor prioridad act´ ue sobre una copia del recurso, que reemplaza al recurso si la tarea de baja prioridad finaliza antes del arribo de la tarea de mayor prioridad. En caso contrario, la tarea de menor prioridad es desalojada, y el recurso aparece inalterado, como si no se hubiera ejecutado la tarea de menor prioridad. Las demoras las sufre la tarea de menor prioridad en este método. Cabe aclarar que los sistemas operativos de tiempo real, implementan solo algunos de estos métodos: FreeRTOS : es un mini kernel de tiempo real dise˜ nado para sistemas embebidos, preparado para funcionar en diferentes plataformas de microcontroladores. Implementa el protocolo de herencia de prioridad [15]. MarteOS : es un sistema m´ınimo de tiempo real, basado en ADA, desarrollado por el Grupo de Computadoras y Tiempo Real de la Universidad de Cantabria. Implementa herencia de prioridad y techo de prioridad [16]. QNX : es un micro-kernel de tiempo real de alto desempe˜ no [17]. Implementa la herencia de prioridad. RTAI : Es un sistema basado en Linux que le agrega funcionalidad de tiempo Real. Este sistema es desarrollado por el Politecnico di Milano - Dipartimento di Ingeneria Aerospaziale (DIAPM). Implementa Herencia de Prioridad [18]. RTLinux : las prioridades de las tareas son estáticas manejadas con dos variantes de algoritmo: FIFO o Round Robin [19]. Si bien su creador, Victor Yodaiken dice que RTLinux no soporta la herencia de prioridad por la simple raz´ on de que es incompatible con cualquier sistema de tiempo real confiable [20] existe una extension que da la posibilidad de usar el mecanismo de herencia de prioridad y el techo de prioridad. VxWorks: de la empresa WindRiverSystem, implementa la herencia de prioridad [21]. Linux con parche RT-preempt: implementa herencia de prioridad y techo de prioridad.

GNU/Linux con parche RT-PREEMPT

GNU/Linux con parche RT-PREEMPT [1] es una modificación realizada al kernel Linux que lo convierte prácticamente en apropiativo, con la excepción de algunas pocas regiones de código peque˜ nas. Esta modificación permite la ejecuci´ on de aplicaciones consideradas hard real-time. 3.1.

Caso de prueba

Como parte del presente trabajo se desarroll´o una aplicaci´on para recrear el fen´ omeno de la inversi´ on de prioridad en GNU/Linux con parche RT-PREEMPT.

1400

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones

Tiene como objetivo evaluar las soluciones de herencia de prioridad y de techo de prioridad implementadas en el kernel. El desarrollo fue realizado en el lenguaje de programaci´ on C utilizando semáforos. La aplicación ejecuta tres tareas (threads) de las cuales dos precisan hacer uso de una región cr´ıtica en com´ un. Dentro de la regi´ on cr´ıtica los distintos threads hacen simplemente unas instrucciones que consumen CPU. Cada thread tiene asignada una prioridad, baja (L), media (M) y alta (H). H y L, son los threads que requieren acceder a la región cr´ıtica compartida. La aplicación se puede ejecutar de tres maneras diferentes seg´ un el algoritmo que utiliza para evitar la inversión de prioridades: inversion: en este modo el programa se ejecuta sin prevenir la inversión de prioridades. inheritance: en este modo el programa evita la inversión de prioridades utilizando el protocolo de herencia de prioridad. ceiling: en este modo el programa evita la inversión de prioridades utilizando el protocolo de techo de prioridad. Sincronizaci´ on La inversión de prioridades se manifiesta cuando los threads del programa se ejecutan sobre un sistema con un u ńico n´ ucleo. Debido a que este caso de prueba es una simulación, los threads se deben sincronizar para que deliberadamente suceda la inversión de prioridades. Dicha sincronización se lleva a cabo usando tres sem´ aforos a modo de barrera, con el fin de ordenar ejecución y la solicitud de acceso al recurso compartido de los mismos. La sincronización sucede de la siguiente forma, una vez que todos los threads fueron lanzados:

Figura 1. Se encuentran los tres threads representados por cada uno de los elipses y las flechas indican el orden y direcci´ on de los avisos para reproducir el fen´ omeno de la inversi´ on de prioridad.

1. El thread L espera la se˜ nal de que H para comenzar sus acciones. Luego de enviar la se˜ nal, H se bloquea esperando a que L bloquee el recurso compartido.

1401

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones

2. Luego de recibir la se˜ nal, L procede a bloquear el recurso compartido. Luego de bloquear el recurso compartido, L env´ıa una se˜ nal a H informando este u ´ltimo evento. 3. Cuando H recibe la se˜ nal de que el recurso ya est´a bloqueado, procede a enviar una se˜ nal a M. Luego de enviar la correspondiente se˜ nal, H procede a intentar adquirir el recurso compartido.

Resultados

4.1.

Tiempo de ejecuci´ on de los threads

La aplicaci´ on realizada para observar el fenómeno de la inversión de prioridad se ejecut´ o sobre un kernel Linux 3.2 con el parche PREEMPT RT [1] con un u ńico procesador. La ejecución de inversion provocó la ejecución de los threads en el siguiente orden: H, hasta la solicitud del recurso compartido. M, hasta su finalizaci´ on. L, hasta que liber´ o el recurso compartido. H, desde que se hizo del recurso compartido hasta el final. L, hasta su finalizaci´ on. Efectivamente se produjo la inversión de prioridades. La ejecuci´ on de inheritance y de ceiling provocó la ejecución de los threads en el siguiente orden: H, hasta la solicitud del recurso compartido. L, hasta que liber´ o el recurso compartido. H, desde que se hizo del recurso compartido hasta el final. M, hasta su finalizaci´ on. L, hasta su finalizaci´ on. En la tabla 1 pueden apreciarse los tiempos de ejecución de cada uno de los threads. Las entradas indicadas en la tabla no consideran el tiempo transcurrido entre que el thread L libera el recurso y termina su ejecución ya que no es de interés para observar el desempe˜ no general del sistema. Como ya se mencion´ o estos dos mecanismos (herencia y techo de prioridades) no permiten garantizar las restricciones temporales que eventualmente podr´ıa tener la tarea de alta prioridad (H), ya que queda atada a la liberación del recurso compartido por parte de la tarea de baja prioridad (L), pero si evitan que tareas de una prioridad intermedia como M, se ejecuten antes que H. 4.2.

Sobrecarga del Sistema Operativo

La implementaci´ on de cada una de la soluciones sobrecarga al sistema operativo con tareas que debe realizar al momento de adquirir o liberar un recurso.

1402

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones Inversion Inheritance L 6368 3164 M 3199 9594 H 9559 6400 Cuadro 1. Tiempos de ejecuci´ on de cada uno de gundos.

Ceiling 3121 9550 6340 los threads, expresados en milise-

Por este motivo, no utilizar ninguno de los protocolos que resuelve el problema ser´ıa como un caso base sin sobrecarga. La solución de herencia de prioridad en cada solicitud de bloqueo de un recurso compartido, debe analizar si el recurso est´ a o no bloqueado por otro proceso de menor prioridad y de ser as´ı pasarle la prioridad a este para que pueda finalizar lo antes posible. De la misma forma cuando libera el recurso debe analizar si tiene una prioridad heredada para restablecer su prioridad original. Por otro lado, la solución de techo de prioridades debe en cada solicitud de bloqueo determinar la prioridad techo entre todos los procesos que est´ an a la espera del recurso y asignárselo al proceso que tiene el recurso para que este se ejecute inmediatamente. En el momento de la liberaci´ on del recurso debe asignar la prioridad techo al proceso de mayor prioridad de entre los que esperan por dicho recurso. Se realiz´ o en GNU/Linux con parche RT-PREEMPT un bloqueo de un sem´ aforo1 . Dicho bloqueo se realizó con la seguridad de que el semáforo no estaba bloqueado previamente, con la intención de hacer un primer análisis de la sobrecarga que cada algoritmo que soluciona la inversión de prioridad conlleva. Con respecto a la opci´ on no impedir la inversión de prioridad, el bloqueo del sem´ aforo con herencia de prioridad llevó un 47 % más de tiempo, mientras que usando el techo de prioridad llevó un 1555 % más de tiempo.

Conclusiones y l´ıneas futuras

Con respecto a la ejecución de la prueba de concepto, mencionada en 4.1, y como ya se mencion´ o all´ı ni la solución por herencia de prioridades ni la solución de techo de prioridades garantizan el determinismo necesario en un sistema hard real-time ya que est´ an ligados a la liberación del recurso compartido por parte de la tarea de baja prioridad. La solución de restauración del recurso si puede garantizar el determinismo necesario, penalizando a las tareas de menor prioridad a que tengan que desechar todo su trabajo con el recurso compartido. Respecto de la sobrecarga del Sistema Operativo (4.2), sólo se analizó la situaci´ on con la garant´ıa de que el recurso compartido estaba libre para poder ser bloqueado. El tiempo para el caso de techo de prioridades es mucho más alto que los dem´ as, tal vez debido a la b´ usqueda inicial de la prioridad techo. Como lineas futuras de investigación queda la opción de ver cuál es la sobrecarga cuando hay otras tareas en ejecución bloqueando el uso del recurso 1

pthread mutex lock

1403

Inversi´ on de prioridades: prueba de concepto y an´ alisis de soluciones

compartido. También ser´ıa de interés analizar la sobrecarga que podr´ıa producir una implementaci´ on de restauración del recurso.

Referencias 1. RTwiki. http://rt.wiki.kernel.org/index.php/Main Page. 2. L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority inheritance protocols: An approach to real-time synchronization. IEEE Trans. Comput., 39(9):1175–1185, September 1990. 3. Alan Burns and Andy Wellings. Sistemas de tiempo real y lenguajes de programaci´ on. Addison Wesley, Madrid [etc.], 2003. 4. Mars pathfinder. http://mars.jpl.nasa.gov/MPF/. 5. The risks digest volume 19: Issue 54. http://catless.ncl.ac.uk/Risks/19.54.html#subj6. 6. What really happened on mars? – authoritative account. http://research.microsoft.com/enus/um/people/mbj/Mars Pathfinder/Authoritative Account.html. 7. Tarek Helmy and Syed S. Jafri. Avoidance of priority inversion in real time systems based on resource restoration. IJCSA, 3(1):40–50, 2006. 8. Victor Yodaiken. Against priority inheritance, 2002. 9. Priority inheritance in the kernel [LWN.net]. http://lwn.net/Articles/178253/. 10. How to use priority inheritance | embedded. http://embedded.com/design/configurable-systems/4024970/How-to-use-priorityinheritance. 11. J. Huang, J.A. Stankovic, K. Ramamritham, and D. Towsley. On using priority inheritance in real-time databases. In Real-Time Systems Symposium, 1991. Proceedings., Twelfth, pages 210–221, 1991. 12. Butler W. Lampson and David D. Redell. Experience with processes and monitors in mesa. Commun. ACM, 23(2):105–117, February 1980. 13. Andreu Carminati, Rˆ omulo Silva de Oliveira, and Lu´ıs Fernando Friedrich. Implementation and evaluation of the synchronization protocol immediate priority ceiling in PREEMPT-RT linux. Journal of Software, 7(3), March 2012. 14. Priority inversion (windows). http://msdn.microsoft.com/enus/library/windows/desktop/ms684831(v=vs.85).aspx. 15. FreeRTOS - market leading RTOS (real time operating system) for embedded systems supporting 34 microcontroller architectures. http://www.freertos.org/. 16. MaRTE OS home page. http://marte.unican.es/. 17. QNX operating systems, development tools, and professional services for connected embedded systems. http://www.qnx.com/. 18. RTAI - official website. https://www.rtai.org/. 19. RTLinux. http://es.wikipedia.org/w/index.php?title=RTLinux&oldid=64581733, March 2013. Page Version ID: 64581733. 20. Rtlinuxpro Victor Yodaiken and Victor Yodaiken. Temporal inventory and realtime synchronization in. 21. Wind river. http://www.windriver.com/.

1404

Estudio sobre mediciones de Campos Electromagnéticos No Ionizantes Jorge S. García Guibout1/2. Miguel Méndez Garabetti1, Antonio Castro Lechtaler3, Alfredo David Priori (estudiante becado)1 1 Universidad del Aconcagua, 2 Instituto Tecnológico Universitario, 3 Universidad Tecnológica Nacional (jgarcia@itu.uncu.edu.ar, miguelmendezgarabetti@gmail.com, antonio.castrolechtaler@gmail.com, dalf_p@hotmail.com)

Abstract. En la actualidad muchas tecnologías de comunicaciones, medicina y del hogar se basan en la emisión de ondas electromagnéticas (TV, WiFi, telefonía celular, hornos a microondas, etc.). Éstas interactúan con nuestro cuerpo y no se tiene, aun, un acabado conocimiento de esa interacción. Esta situación ha provocado que la sociedad comience a preocuparse por las posibles consecuencias de estas emisiones, pidiendo mayores controles y reglamentaciones. Este trabajo busca conocer, en base al estado actual del conocimiento, la forma correcta de medir estos campos para que se puedan acompañar y justificar las decisiones sobre este tema que pueden llegar a ser necesario tomar en las zonas de influencia del Gran Mendoza y del país todo. Keywords: radiación ionizante, radiación no ionizante, campo eléctrico, campo magnético, ondas electromagnéticas, mediciones.

1 Introducción Los avances tecnológicos han producido cambios trascendentales y muchos de estos cambios son debidos a servicios que emplean ondas electromagnéticas, en especial los servicios inalámbricos. Esta situación lleva a que los seres vivos se vean expuestos constantemente e involuntariamente a los efectos de dichas radiaciones. Éstas pueden resultar perjudiciales para la salud (efectos negativos que pueden provocar riesgos en la salud). Si bien se han realizado numerosas investigaciones para conocer los posibles efectos negativos que este tipo de radiaciones pueden causar en la salud en función a la intensidad con las que las mismas inciden en ellos, algunos de estos son conocidos1, otros son aun controvertidos2 por lo que estas investigaciones aún son insuficientes. La Contaminación Electromagnética reconocida por la organización Mundial de la Salud, en primera instancia se enfocó en las antenas de televisión, antenas de radiodifusión, tanto AM y FM, líneas de alta tensión y otras fuentes de RNI [7]. El desplie1 2

Como ser: calentamiento térmico, inducción de corriente eléctrica, etc. Como pueden ser: ciertos tipos de cáncer, alteraciones al sistema nervioso central, leucemia infantil, etc.

1405

gue creciente de la telefonía móvil, según estimó la Unión Internacional de Telecomunicaciones - ITU [9] habría llegado en 2011 a 5.800 millones de suscriptores. Esta situación generó preocupación e incertidumbre, máxime teniendo en cuenta que este número tan importante de usuarios del servicio impacta directamente en la cantidad de antenas instaladas en ciudades y pueblos.

2 Radiación La radiación podemos definirla como la propagación de energía, sea esta en forma de ondas electromagnéticas o partículas a través del espacio. Toda radiación electromagnética está asociada con la emisión de fotones que son los responsables de la interacción electromagnética. Las características del fotón hacen que claramente podamos observar en la vida diaria fenómenos que son explicados tanto por su naturaleza corpuscular como ondulatoria. El fotón es una partícula sin masa y sin carga eléctrica, lo que hace que viaje en el vacío a la velocidad de la luz. La ausencia de carga eléctrica hace que sea noionizante, es decir que por sí misma no puede alterar el equilibro de carga eléctrica por donde pase. Cada fotón se caracteriza por su energía que es directa y biunívocamente proporcional a su frecuencia, calculando la energía del fotón por la ecuación siguiente: E= h f [Julios]

(1)

Donde: f es la frecuencia y h es la constante de Planck que es igual a 6,626 x 10-34 [Js ]. -1

La energía se suele medir en Julios, pero como la energía asociada a cada tipo de radiación electromagnética es débil, se emplea otra unidad de energía llamada eV (electronvoltio). 1eV = 1,602176462 × 10-19 J

(2)

La constante de Planck en dichas unidades será igual a 4,135567 x 10-15 [eV]. En la naturaleza todas las partículas tienen un comportamiento dual: como partículas y como ondas. Así, algunos fenómenos de la radiación pueden ser entendidos como si fueran ondulaciones, y para otros fenómenos tendremos que concebirlos como si fueran partículas. La realidad es que son ambas cosas, de allí el concepto de dualidad. El comportamiento ondulatorio se manifiesta por medio de campos eléctricos y magnéticos perpendiculares entre sí que oscilan perpendicularmente a la dirección de propagación de la onda. Estas ondas electromagnéticas pueden ser descritas mediante sus parámetros característicos como lo son su frecuencia o longitud de onda y contenido de energía.

1406

En función de la energía que tenga la onda electromagnética la radiación puede ser ionizante (RI) o no ionizante (RNI). Una onda de radio, menor a 30 KHz hasta 1 GHz, poseen una energía desde 1,24x10-10 eV hasta 4,14x10-6 eV, la Luz Ultravioleta, 790 THz, con un energía de 3,3 eV y la Radiación Ionizante, 952 THz en adelante, tienen una energía mayor a 4 MeV.

3 Radiación Ionizante (RI) y NO Ionizante (RNI) La radiación ionizante podemos definirla cómo: las radiaciones que por su frecuencia son capaces de entregar energía a los átomos de las sustancias como para romper los enlaces químicos, desprender un electrón y de esta manera crear un ion, e incluso interactuar con el núcleo del átomo [4]. Cuando un átomo pierde uno de sus electrones se dice que se ioniza, convirtiéndose en un ión o un catión y aún modificar la estructura del núcleo desprendiendo neutrones o protones. Este es el caso de la radiación ultravioleta, los rayos x y los rayos gamma, siendo estos últimos los que pueden interactuar a nivel del núcleo. La radiación ionizante es producida por diversas fuentes como fuentes cósmicas externas (radiación cósmica), materiales radiactivos naturales contenidos en la corteza terrestre, en los ecosistemas y en el interior de los organismos vivos, los que pueden emitir, según sea el elemento, partículas Alfa y Beta, rayos Gamma y “radiación exótica” debida a materiales radioactivos producidos por el ser humano a partir de 1945 (fuentes bélicas y experimentales, fuentes civiles), aparatos que producen rayos X como energía residual, radiación solar cuya porción ultravioleta C no haya sido detenida por la alta capa de ozono (1016 a 1017 Hz). Este tipo de radiación en su interacción con la materia puede causar daños en tejidos biológicos incluyendo efectos sobre el ADN (ácido desoxirribonucleico: material genético de los seres vivos), por tales motivos las aplicaciones que utilizan este tipo de radiación se utilizan en recintos aislados con importantes cuidados al medioambiente y del personal que opera la tecnología. Por el contrario de la Radiación Ionizante, la Radiación No-Ionizante (RNI) podemos definirla como: las radiaciones que no poseen la suficiente energía, para desprender electrones de los átomos [4]. Este tipo de radiación se extiende desde las frecuencias muy bajas de la luz ultravioleta hasta las frecuencias extremadamente bajas como las del tendido eléctrico (ELF) y los campos magnéticos y eléctricos de naturaleza estática. Su efecto principal es el incremento de la temperatura del material con el que interacciona. Esto es debido a que el fotón al interaccionar con la materia es como si chocara con ella, es decir, su energía pasa a la materia en forma de incremento de Energía Cinética.

1407

La ionización se produce en forma abrupta a partir de un umbral de frecuencia y este umbral es una barrera de energía perfectamente definida, que es diferente en cada material. Si bien este tipo de ondas electromagnéticas no pueden ionizar la materia incidida, si pueden causar otro tipo de efectos sobre la materia. De aquí es que podemos clasificar a los efectos de las RIN en: Efectos térmicos, Efectos no térmicos o biológicos. El cuerpo humano posee mecanismos para regular de forma eficiente su temperatura, pero si la exposición a campos electromagnéticos es demasiado alta, el cuerpo podría no ser capaz de regular tal incremento, por este motivo es que los límites de exposición previenen un incremento de temperatura en el cuerpo humano de 1º C.

4 Tasa de Absorción Específica Ya que los límites de exposición pueden ser establecidos en distintas unidades, para las frecuencias más bajas y hasta varios cientos de MHz, se suele utilizar la intensidad del campo eléctrico expresada en V/m, la intensidad de campo magnético en A/m o la densidad de potencia expresada mW/cm2 o W/m2. Pero existe un parámetro dosimétrico ampliamente utilizado el cual se denomina "tasa de absorción específica" o SAR Specific Absorption Rate, el cual se define como: La derivada del aumento de la energía, ∂W, absorbida o disipada en un elemento de masa ∂m, contenida en un elemento de volumen ∂V, cuya densidad es ρ. Puede ser expresado analíticamente como [1]:

(3) En la ecuación siguiente se puede observar que el SAR es directamente proporcional al aumento local de la temperatura: (4)

donde T es la temperatura en grados Celsius, y Cp es el calor específico del tejido (J/kg °C). O sea, que la tasa de absorción específica es la medida de la cantidad de energía de radiofrecuencia que es absorbida por los tejidos en el cuerpo humano y se expresa en W/kg.

5 Efectos en la Salud de las Radiaciones No Ionizantes La preocupación por este nuevo tipo de contaminación se ha acentuado con la aparición de la telefonía móvil, la instalación y permanente funcionamiento de una gran cantidad antenas fijas que operan en el rango de las microondas, y la multiplicación de miles de pequeñas antenas móviles que emiten y reciben estas señales (teléfonos celulares, terminales del sistema, o teléfonos móviles, etc.) [4]. Es por ello que en

1408

diversos ámbitos han continuado las investigaciones respecto a los efectos de ellas tanto en el ambiente como en el cuerpo humano. De acuerdo a estudios realizados, la energía radiante puede ser absorbida por el cuerpo humano mediante tres procesos diferentes: efecto antena, absorción de señal (proceso de absorción relacionado con la constante dieléctrica y el tipo de conductividad del tejido, los cuales son diferentes a distintos valores de frecuencia), absorción biofísica (involucra la absorción resonante por sistemas biológicos como el cerebro o las células). Algunos de los bioefectos y sus mecanismos dependen del rango del espectro de frecuencias de las ondas. Ésta se puede dividir en frecuencia extremadamente baja, que es toda frecuencia menor a 30 KHz, y radiofrecuencia y microondas, que incluye frecuencias hasta 300 GHz, que actúan a nivel de las estructuras de las células que están conformadas por moléculas y átomos cargados que pueden cambiar su orientación y movimiento cuando se encuentran expuestos a una fuerza electromagnética Se ha visto que la radiación de los campos eléctrico y magnético de las frecuencias extremadamente bajas pueden existir separadamente el uno del otro. Normalmente, la discusión sobre los efectos se restringe normalmente al campo magnético que es producido por corrientes alternas o campos variantes en el tiempo, cuya intensidad y dirección cambien de forma regular, ya que los campos eléctricos son fácilmente apantallados [13]. Por otra parte, la exposición a radiaciones de frecuencias extremadamente bajas ocurre a distancias mucho menores que la longitud de onda. Esto tiene importantes implicancias porque bajo tales condiciones se tratan como componentes independientes. La situación es sustancialmente diferente de la que ocurre en la radiación de campos de alta frecuencias, en donde los campos eléctrico y magnético están indisolublemente unidos. Esta es la razón por la que las investigaciones se han centrado en los efectos de un campo o el otro, en frecuencias extremadamente bajas. La interacción del campo electromagnético con sistemas vivos que se ha propuesto teóricamente es la habilidad del campo magnético para estimular corrientes en las membranas de las células y en los fluidos de los tejidos, que circulan en un lazo cerrado que descansa en un plano perpendicular a la dirección del campo magnético. Por tanto, en el interior de un medio biológico se inducen corrientes y campos eléctricos debido al campo magnético. Una posible interacción bajo investigación es que la exposición a campos de frecuencias extremadamente bajas suprime la producción de melatonina, que es una hormona producida por la glándula pineal localizada en una zona profunda del cerebro. La melatonina se produce principalmente por la noche y se libera al cuerpo a través del flujo sanguíneo. Ella llega a casi todas las células del cuerpo humano, estimulando

1409

el sistema inmune, preserva el ADN, las proteínas y los lípidos de daños oxidativos al neutralizar los radicales libre que pueden causar daños estructurales [10]. Además regulan otras actividades como los ciclos menstruales femeninos, el ritmo cardíaco, el sueño, el estado de ánimo y la genética y es esencial para el sistema inmunológico, protegiendo al cuerpo de infecciones y de las células cancerosas. Diversos estudios han encontrado reducción de melatonina en células animales y personas expuestos a campos de frecuencias extremadamente bajas siendo un efecto que depende fuertemente del período de exposición y de la intensidad del campo En cuanto a los efectos biológicos de la RF y microondas se han desarrollado un número significativo de estudios. Estos exploran la posible relación entre la exposición a la radiación de campos RF y microondas y las enfermedades, incluyendo el cáncer; pero todavía deberá pasar un tiempo hasta que se tengan los resultados finales de la mayoría de los estudios. Básicamente, existen dos tipos de efectos biológicos a estas frecuencias Efectos térmicos: ocurren cuando la radiación en cuestión posee suficiente energía como para ocasionar un incremento de temperatura medible. Efectos no térmicos: es una línea de investigación en pleno desarrollo. Podemos decir que se registran efectos biológicos a niveles SAR muy por debajo de los 0,08 W/kg y a densidades de potencia minúsculas de 0,0004µW/cm2. Es muy importante remarcar que los estándares tanto del ICNIR - International Commission on Non-Ionizing Radiation Protection, la Organización Mundial de la Salud y la Unión Europea se basan, en su mayoría, en efectos térmicos de naturaleza irreversible para exposiciones a corto plazo.

6 Mediciones de las ondas Electromagnéticas La investigación en el área de los bioefectos de la radiación electromagnética ionizante3 fue anterior a su utilización, lo que permitió reducir los riesgos y por lo tanto aumentar la utilización de dispositivos nucleares generadores de energía, así como también de aquellos derivados de la tecnología de radiación X (medicina, etc.) Los efectos de las radiaciones electromagnéticas no ionizantes de radiofrecuencias son motivo de preocupación, por lo tanto el problema de la dosimetría es muchísimo más complicado en este otro caso4, que en el de la radiación electromagnética ionizante. Es obvio que los estándares de protección contra la radiación de radiofrecuencias deben expresarse en términos de la intensidad del campo Eléctrico (E), campo Magnético (H) y Densidad de Potencia en el espacio libre (S, como se lo llama en la resolución 3690 de la CNC [16]).

3 4

Rayos X y gamma. Radiofrecuencias.

1410

El propósito de la medición o prospección de radiación es medir los campos E, H, y S en el ambiente donde el hombre puede estar eventualmente expuesto y comparar esas mediciones con los estándares de niveles permisibles de exposición establecidos Con el fin de poder determinar las condiciones de exposición mínima a las que son expuestas la población y aquellos agentes que trabajan directamente sobre equipamiento emisor de señales electromagnéticas, el Ministerio de Salud y Acción Social de la Nación estableció por medio de la resolución 202/95 [17] los niveles mínimos a los que pueden ser expuestos la población en general y a personas expuestas por su ocupación. En base a esta resolución del Ministerio de Salud y Acción Social de la Nación la Comisión Nacional de Comunicaciones (CNC) emite la Resolución 3690/2004 [16], que abarca a las 269/2002 y la 217 CNC/2003 de la misma repartición, donde se establecen las formas en que deben medirse los niveles de campos eléctricos, magnéticos y/o densidades de potencia en el áreas bajo interés para corroborar lo dictaminado por el Ministerio de Salud y Acción Social de la Nación.. Se presentan en la tabla 1 los valores propuestos por la Resolución 202/95 [17]. Tabla 1: Niveles propuestos por la Resolución 202/95 de MSAS Rango de frecuencia f (MHz)

Densidad de Potencia equivalente de onda plana S (mW/cm2)

Campo Eléctrico

Campo Magnético

(V/m)

(A/m)

0,3 - 1

275

0,73

1 - 10

20/f2

275/f

0,73/f

0,2

27,5

0,073

f/2000

1,375 f/2

61,4

10 - 400 400 - 2000 2000 - 100.000

Para la toma de las mediciones, la resolución de la CNC define un campo cercano y un campo lejano, existentes en las proximidades de una antena. En la región del campo lejano, a una distancia mayor que 3λ de la antena, el campo predominante es del tipo onda plana, es decir una distribución localmente uniforme de la intensidad de campo eléctrico y de la intensidad de campo magnético en planos transversales a la dirección de propagación. La región de campo cercano se subdivide a su vez en la región de campo cercano reactivo, que es más próxima al elemento radiante y la región de campo cercano ra-

1411

diante, en la que el campo de radiación predomina sobre el campo reactivo, pero que no es sustancialmente del tipo onda plana y tiene una estructura compleja. El campo Eléctrico se expresará en V/m y el campo Magnético en A/m, la Densidad de Potencia (S) se expresa en mW/cm2. En una onda plana estos parámetros están relacionados por medio de la impedancia del espacio libre (Z0 = 377 Ω), por lo tanto con la medición de algunos de los campos será suficiente para obtener el resto por medio de la ecuación:

E2 S= = H 2Z0 Z0

(5)

En el caso de mediciones en el campos cercanos, las componentes de los campos eléctricos (E) y magnéticos (H) son generalmente desconocidas. Por ello, se deberá, en todos los casos, realizar la medición de dichos campos en forma separada. Es necesario introducir las definiciones, que forman parte de de la resolución de la CNC, de Emisión que es la radiación producida por una única fuente de radiofrecuencia, y la de Inmisión que es la radiación resultante del aporte de todas las fuentes de radiofrecuencias cuyos campos están presentes en el lugar. También definimos Potencia Radiada Aparente - PRA como el producto de la potencia suministrada a la antena por la ganancia de antena, en una dada dirección, relativa a un dipolo de media onda y Potencia Isotrópica Radiada Equivalente-PIRE como el producto de la potencia suministrada a una antena por la ganancia de antena, en una dada dirección, relativa a una antena isotrópica. El procedimiento de evaluación para aquellas estaciones cuyas características de radiación impliquen la consideración del campo lejano, la evaluación de los valores de radiaciones no ionizantes (RNI) para el caso de una antena única, las predicciones de densidad de potencia se pueden realizar a partir de las siguientes ecuaciones, que si bien son solamente válidas para los cálculos en el campo lejano de una antena, pueden utilizarse para predecir el peor de los casos,

PRA *1,64 * 2,56 * F 2 4 *π * r 2

(6)

Donde: PRA se considera en W F es la atenuación en veces de la radiación para un cierto ángulo de incidencia en el plano vertical, que si es desconocido toma un valor igual a 1 2.56 es un factor de reflexión empírico, que tiene en cuenta que se puedan adicionar campos reflejados en fase. r es la distancia desde la antena

1412

O por medio de

PIRE * 2,56 * F 2 S= 4 *π * r 2

(7)

Donde: PIRE se considera en W

De estas ecuaciones se puede despejar la distancia mínima a la antena, r, con los valores de densidad de potencia establecidos en la tabla 1 sobre límite de exposición poblacional. En el caso que se determine que se superan los valores límites establecidos en la tabla 1, se deberán llevar acabo mediciones según el protocolo que se detalla a continuación. En base a las características del sistema irradiante y la de los emisores se determinaran los puntos de mayor riesgo tanto externos al predio de la antena como internos al mismo. Se deberá tener en cuenta la topología, edificaciones y superficies reflectoras del lugar. La medición se efectuará en los puntos de mayor acceso por parte del público. En sistemas omnidireccionales se deberán seleccionar 16 puntos como mínimo y para sistemas direccionales se deberán adoptar un mínimo de 4 puntos sobre la dirección de máxima propagación, los 12 puntos restantes deberán ubicarse en función de las características del lóbulo de radiación de dicha fuente. Todos estos puntos serán función de la longitud de onda del sistema emisor. El tipo de instrumento establecido en la resolución son equipos de banda ancha que responden uniforme e instantáneamente a un amplio rango de frecuencias y no son sintonizables. Éstos se emplean con sondas de medición de E y H del tipo isotrópico, para una respuesta independiente de la orientación de la sonda. Los mismos son utilizados para la medición de inmisión. También se menciona instrumentos de banda angosta que operan sobre un amplio rango de frecuencias, pero su ancho de banda instantáneo de medición se reduce a anchos de banda estrechos. Este tipo de dispositivos debe sintonizarse a la frecuencia de interés y utilizarse con antenas aptas para los distintos rangos de frecuencia de medición. Son utilizados para la medición de emisión y proporcionan información de la frecuencia bajo análisis. La secuencia de medición establecida indica que en primer término se medirá inmisión. Si los valores obtenidos superaren los máximos permisibles más estrictos dados en la tabla 1, se continuará midiendo la emisión de cada estación. La medición de inmisión tiene por objeto obtener el nivel pico máximo de los campos eléctrico, magnético o de la densidad de potencia, a lo largo de una línea vertical que represente la altura del cuerpo humano en el punto de medición.

1413

Estas mediciones comienzan a 20 cm por encima del suelo hasta una altura de 2 m a una velocidad constante. Si el valor pico máximo de dichas mediciones resulta inferior al 50% de la Máxima Exposición Permitida -MEP más estricta, se registrará como valor de ese punto. Si dicho valor supera el citado 50% de la MEP más estricta, se deberá realizar una medición con promediado temporal de 6 minutos. En caso que los resultados obtenidos en las mediciones de inmisión superen los límites de la tabla 1, se deberá proceder a la medición de emisión a fin de evaluar los aportes individuales de cada una de las fuentes emisoras de radiaciones no ionizantes. Se medirá la intensidad de campo producida por la estación a verificar sobre cada uno de los puntos de medición seleccionados, por medio de instrumentos de banda angosta asociados con antenas de polarización lineal. A tal efecto podrán utilizarse dos métodos alternativos: a) Orientar la antena en tres direcciones ortogonales entre sí (x, y, z) obteniéndose las componentes de campo respectivas. Los valores cuadráticos de intensidad de campo eléctrico y/o magnético se obtendrán de la suma de los cuadrados de las correspondientes componentes de campo ortogonales, como se observa en las siguientes ecuaciones:

E 2 = E X2 + EY2 + EZ2

(8)

H 2 = H X2 + H Y2 + H Z2 b) Orientar la antena en la dirección de máxima señal. Este método es también aplicable a una antena de apertura

7 Conclusiones La permanente y rápida evolución de nuevas tecnologías que utilizan campos electromagnéticos para brindar servicios cada vez más útiles y novedosos, no ha permitido que en forma simultánea se hayan realizado acabadamente las investigaciones de los posibles efectos negativos sobre personas y ecosistemas antes de su masificación. De acuerdo con la bibliografía analizada, se está trabajando fuertemente en la investigación en torno a este fenómeno, tanto en nuestro país como así también en el resto del mundo. Es importante poder medir las magnitudes de los campos magnéticos y eléctricos a los que nos vemos expuestos, de manera que la sociedad esté segura que se cumplen las normativas de seguridad de exposición y tener las herramientas para solicitar las correcciones que sean necesarias. Para ello es necesario conocer las especificaciones nacionales y compararlas con regulaciones internacionales para mejorar en la toma de estas mediciones, tratando de replicarlas en el laboratorio, para después poder adaptarlas a nuestras topología, dis-

1414

tribución poblacional, particularidad de nuestra estructura edilicia, entre otras características propias de nuestra región. En este sentido es importante destacar el aporte del Laboratorio de Investigación Aplicada y Desarrollo (LIADE) de la Universidad Nacional de Córdoba en el estadio y difusión de este tema [11,12].

8 Bibliografía 1 . International Commission on Non-Ionizing Radiation Protection: Recomendaciones para limitar la exposición a campos eléctricos, magnéticos y electromagnéticos (hasta 300 GHz): http://www.icnirp.de/documents/emfgdlesp.pdf. 2 . Organización Mundial de la Salud: Campos electromagnéticos y salud pública: radares y salud humana:http://www.who.int/pehemf/publications/facts/fs226/es/ 3 . Mobile Phone Simulations with Human Head and Hand Models; Computer Simulation Technology; 2011 CST AG, http://www.cst.com/Content/Applications/ Article/Mobile+Phone+Simulations+with+Human+Head+and+Hand+Models, 4 . Capparelli M., Mata N., Montenegro R., Aliciardi M.(2008). El ambientalismo II, la Electropolución, Contaminación por antenas de telefonía celular., editorial Ediciones del País. 5 . Agencia Internacional sobre Investigación del Cáncer: http://www.iarc.fr/ index.php 6 . Organización Mundial de la Salud; http://www.who.int/about/es/ 7 . IARC classifies radiofrequency electromagnetic fields as possibly carcinogenic to humans, Press Release N° 208 , 31 de mayo 2011. http://www.iarc.fr/en/mediacentre/pr/2011/pdfs/pr208_E.pdf 8 . IEEE Std C95.3-2002 (Revision of IEEE Std C95.3-1991). IEEE Recommended Practice for Measurements and Computations of Radio Frequency Electromagnetic Fields With Respect to Human Exposure to Such Fields, 100 kHz–300 GHz. http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=8351 9 . ITU: http://www.itu.int/es/about/Pages/default.aspx 1 0 . Instituto Latinoamericano de la Comunicación Educativa: http://bibliotecadigital.ilce.edu.mx/sites/ciencia/volumen2/ciencia3/107/htm/paraat ra.htm 1 1 . Bruni R., Vanilla O., Taborda R., Evaluación de radiación electromagnética de antenas, L.IADE (Laboatorio de Investigación Aplicada y Desarrollo) – Universidad Nacional de Córdoba, www.liade.efn.uncor.edu/ 1 2 . Bruni R., Vanilla O., Taborda R, Evaluación de radiación electromagnética de fuentes no naturales, L.IADE (Laboatorio de Investigación Aplicada y Desarrollo) – Universidad Nacional de Córdoba, www.liade.efn.uncor.edu/ 1 3 . Cátedra Radiaciones, Universidad Nacional de Entre Ríos. http://www.bioingenieria.edu.ar/academica/catedras/radiaciones/Descargas/Unidad 1.pdf 1 4 . Portela A., Skvarca J., Matute Bravo E., Loureiro A., Prospección de la radiación electromagnética no Ionizante, Vol.I: Manual de estándares de seguridad para la exposición a radiofrecuencias comprendidas entre 100 KHz y 300 GHz, Dirección

1415

Nacional de Calidad Ambiental Secretaria de Salud Ministerio de Salud y Acción Social. 1 5 . Portela A., Skvarca J., Matute Bravo E., Loureiro A.,Prospección de la radiación electromagnética no Ionizante, Vol.II: Radiación de radiofrecuencias: Consideraciones biofísicas, biomédicas y criterios para el establecimiento de estándares de exposición. 1 6 . Comisión Nacional de Comunicaciones (CNC) (2004). Resolución 3690/2004 (Boletín oficial Nº 30.524, 10/11/04). 1 7 . Ministerio de Salud y acción Social de la Nación (1995). Resolución 202/95 (EXP Nº2002-17655- 94-04).

1416

Selecci´ on sub-´ optima del espectro asociado a la matriz de afinidad Luciano Lorenti, Luc´ıa Violini, Javier Giacomantone Instituto de Investigaci´ on en Inform´ atica (III-LIDI), Facultad de Inform´ atica - Universidad Nacional de La Plata - Argentina. La Plata, Buenos Aires, Argentina. {llorenti,lviolini,jog}@lidi.info.unlp.edu.ar

Resumen. En este art´ıculo se presenta un método de agrupamiento espectral que incorpora un etapa de selecci´ on sub-´ optima de caracter´ısticas. Los métodos de agrupamiento espectral tienden a determinar la estructura subyacente en un conjunto de patrones, donde otros métodos convencionales por la disposici´ on y caracter´ısticas particulares de los agrupamiento, no obtienen los resultados esperados. En este trabajo se propone utilizar un método particular de selecci´ on de caracter´ısticas que tiene como objetivo determinar el mejor conjunto de autovectores de la matriz de afinidad normalizada. La determinaci´ on correcta del subconjunto de autovectores m´ as relevantes, puede ser utilizada para mejorar las caracter´ısticas de las particiones generadas. El método es evaluado con datos sintéticos simulando estructuras de datos espec´ıficas, y en datos reales obtenidos con una c´ amara de tiempo de vuelo. Palabras clave: Clustering espectral, Selecci´ on de caracter´ısticas, Visi´ on por Computadora, Rob´ otica.

Introducci´ on

Una etapa general de un sistema de reconocimiento automático de patrones es la de reducci´ on de dimensi´ on [1][2]. La reducción del n´ umero de caracter´ısticas puede realizarse en modo supervisado o no supervisado y las técnicas empleadas pueden ser clasificadas como de selección o de extracción de caracter´ısticas [3]. En selecci´ on de caracter´ısticas se definen criterios para elegir el mejor subconjunto de caracter´ısticas de un conjunto original [4][5], y en extracción de caracter´ısticas se generan nuevas caracter´ısticas mediante transformaciones lineales o no lineales del mismo. El problema particular para el cual el sistema es dise˜ nado y el tipo de datos que define los objetos o fenómenos tratados, determinará si se incluir´ an las dos etapas, una de extracción y una de selección, o solamente una etapa. El dise˜ no de un m´ odulo de selección de caracter´ısticas involucra m´ ultiples consideraciones sobre el conjunto de patrones disponibles, como valores at´ıpicos, imputaci´ on de valores, tipo de normalización y compromisos en el n´ umero óptimo de caracter´ısticas, dadas por el fenómeno de pico [6]. Sistemas con restricciones

1417

temporales o donde el n´ umero de caracter´ısticas es mucho mayor que el n´ umero de muestras son alguno de los casos en que se plantea utilizar sistemas de reducci´ on de dimensi´ on. En este trabajo se propone un método en el cual se seleccionan autovectores en el contexto de un método de agrupamiento (clustering) y no como una etapa cl´ asica en el dise˜ no de un sistema de clasificación. Cuando la estructura de los datos no corresponde a regiones convexas, no es lineal o cuando los métodos cl´ asicos de agrupamiento, jerárquicos o particionales, no obtienen resultados satisfactorios, una alternativa son los métodos de agrupamiento espectral (spectral clustering) [7][8][9]. Las técnicas de agrupamiento espectral utilizan los autovectores de la matriz de afinidad, o de matrices derivadas, para generar una partici´ on del conjunto de muestras en agrupamientos disjuntos, que presenten valores altos de la medida de semejanza adoptada para patrones en un mismo conjunto, y bajos para patrones de conjuntos diferentes. En general el valor de los correspondientes autovalores determina un criterio que permite establecer la prioridad de los autovectores, esta no necesariamente genera la mejor partici´ on del espacio muestral. Es posible entonces aplicar técnicas de selección de caracter´ısticas para determinar qué combinación de autovectores genera la mejor partici´ on [10][11][12]. En este art´ıculo se propone un método que combina el potencial de los métodos de agrupamiento espectral con un método espec´ıfico de selecci´ on sub-´ optima de caracter´ısticas [13]. Se presentan resultados experimentales utilizando datos artificiales e imágenes de rango reales. En particular se utiliza una c´ amara de tiempo de vuelo [14], utilizada en aplicaciones generales de visi´ on por computadora [15] y robótica [16][17]. En la secci´ on 2 se describe el método de selección sub-óptima de b´ usqueda secuencial flotante hacia adelante adoptado. En la sección 3 se describe método de cortes normalizados y en la sección 4 se presenta el método propuesto. En la secci´ on 5 se muestran resultados experimentales. Finalmente, en la sección 6 se presentan las conclusiones.

2 2.1

Selecci´ on Sub-´ optima de caracter´ısticas Selecci´ on de Caracter´ısticas

El problema de selecci´ on de caracter´ısticas consiste en, dado un conjunto Y de D caracter´ısticas determinar cuál es el subconjunto X de tama˜ no d < D que genera la mayor contribuci´ on a la discriminación entre clases. Se puede plantear el problema en términos de la optimización de una función criterio J para un subconjunto de tama˜ no d. J(X) =

max

J(Z)

Z⊂Y,|Z|=d

El método de selecci´ on determinará una función criterio y el algoritmo de b´ usqueda adecuado para el problema analizado. Una vez determinada la función criterio es necesario definir un algoritmo de b´ usqueda que tenga como objetivo un compromiso entre optimizaci´ on y complejidad que resulte viable. El método sub-óptimo

1418

adoptado en este art´ıculo es el método de b´ usqueda secuencial flotante hacia adelante (SFFS - Sequential Forward Floating Selection) [13][18] y la función criterio adoptada basada en matrices dispersas. El método SFFS fue propuesto para evitar el problema de anidamiento que genera el método de b´ usqueda secuencial hacia adelante (SFS - Sequential Forward Selection) [19]. 2.2

B´ usqueda Secuencial Flotante hacia Adelante

Dado el conjunto completo de D mediciones Y = {yj | j = 1, . . . , D}, seleccionar k caracter´ısticas, para formar el conjunto Xk = {xj | j = 1, . . . , k, xj ∈ Y }, que optimice la funci´ on criterio J(Xk ) correspondiente. Inicializaci´ on: X0 := Ø; k := 0 en la pr´ actica se puede comenzar con k = 2 por aplicar SFS dos veces. Paso 1 (Inclusi´ on): x+ := arg max J(Xk + x) x∈Y −Xk

x+ es la caracter´ıstica m´as significativa con respecto a Xk . Xk+1 := Xk + x+ ; k := k + 1 Paso 2 (Exclusi´ on Condicional): x− := arg max J(Xk − x) x∈Xk

x− es la caracter´ıstica menos significativa en Xk . if J(Xk − {x− }) > J(Xk−1 ) then Xk−1 := Xk − x− ; k := k − 1 ir a Paso 2 else ir a Paso 1 Terminaci´ on: Parar cuando k es igual al n´ umero de caracter´ısticas requerido

2.3

Medida de Semejanza entre clases

Debido al uso recursivo de la funci´on criterio, se propone utilizar la siguiente medida de separaci´ on entre clases basada en matrices dispersas. −1 J = tr{Sw Sm }

donde

Sw =

M P

Pi Σi

Sm = E[(x − µ0 )(x − µ0 )T ]

i=1

siendo M el n´ umero de clases y Pi la probabilidad a priori de cada clase.

1419

Agrupamiento Espectral

El algoritmo de cortes normalizados propuesto por Shi y Malik [20] modela la segmentaci´ on de im´ agenes como un problema de partición de un grafo. Un grafo G=(V,E) est´ a formado por un conjunto de vértices V y un conjunto de aristas E que relacionan elementos de V. Con el objetivo de construir grafos a partir de im´ agenes, los vértices son generados a partir de los pixeles que la constituyen. El conjunto de las aristas E está formado por elementos que denotan la semejanza entre los pixeles. Dado un grafo pesado no dirigido G = (V, E), donde V son los nodos y E son las aristas. Sea A,B una partición de un grafo: A∪B = V, A∩B = ∅. La semejanza entre dos grupos es llamada cut P cut(A, B) = w(i, j) i∈A,j∈B

donde w(i, j) es el peso de la arista que conecta el v´ertice i con el v´ertice j. El criterio propuesto por Shi y Malik utiliza un criterio de semejanza normalizado para evaluar la partici´ on: N cut(A, B) =

cut(A,B) assoc(A,V )

cut(A,B) assoc(B,V )

Una de las ventajas m´ as importantes para usar el criterio de cortes normalizados es que se puede obtener una buena aproximación de la partición óptima de forma muy eficiente. Sea Wij = w(vi , vj ) la matrizPde pesos del grafo y sea D la matriz diagonal de forma que Dii = grado(vi ) = w(vi , vj ) vj ∈V

Shi y Malik demostraron que una partici´on ´optima se puede obtener calculando:

y = arg min N cut = arg min y

y T (D − W )y y T Dy

donde y es un vector indicador binario que especifica a qué grupo pertenece cada pixel. Relajando el carácter discreto de y, la ecuación anterior puede ser aproximada resolviendo el sistema de autovalores generalizado: (D − W )y = λDy El segundo autovector de este sistema es la solución real del problema discreto de cortes normalizados. 3.1

Ncut simult´ aneo de k-v´ıas

Se define el corte normalizado simult´aneo de k-v´ıas que da como resultado k segmentos en una sola iteraci´on de la siguiente forma: N cut(A1 , A2 , . . . , Ak ) =

cut(A1 ,A1 ) assoc(A1 ,V )

cut(A2 ,A2 ) assoc(A2 ,V )

+ ... +

cut(An ,An ) assoc(An ,V )

1420

Sea L = (D − V ), dado un vector indicador v de un sub-grafo Aj tal que (

1 assoc(An ,V )

√

vi =

si i ∈ Aj si i ∈ / Aj

resulta que viT Lvi =

cut(Aj ,Aj ) assoc(Aj ,V )

Sea H la matriz formada por k vectores indicadores puestos en columnas, minimizar N cut(A1 , A2 , . . . , Ak ) es equivalente a minimizar: min

A1 ,A2 ,...Ak

Tr(H T LH) sujeto a H T DH = I

Se puede hallar eficientemente una aproximaci´on continua de los autovectores discretos que minimizan la traza. Estos son los autovectores correspondientes a los k autovalores m´ as peque˜ nos del sistema de autovalores (D − W )u = λDu.

M´ etodo Propuesto

Sea M ∈ Rn×m una matriz que contiene n patrones de m caracter´ısticas. 1. Se construye la matriz de afinidad W de forma que W (i, j) = w(vi , vj ) Para im´ agenes se utiliza: w(vi , vj ) = e

−kF (i)−F (j)k2 αI

( ∗

−kX(i)−X(j)k2 αX

si kX(i) − X(j)k2 < r c. c.

donde X(i) es la locaci´on espacial (x, y) del pixel i y F (i) es el nivel de intensidad del pixel i. 2. Se calcula la matriz diagonal D tal que D(i, i) = grado(vi ) =

w(vi , vj )

vj ∈V

3. Sea H la matriz formada por los k autovectores correspondientes a los autovalores m´ as peque˜ nos del sistema de autovalores (D − W )u = λDu. 4. Considerando las columnas de H como caracter´ısticas y las filas como patrones se aplica el método de selección sub-óptima descripto en la sección 2. 5. Se aplica el algoritmo k-medias sobre el conjunto de patrones utilizando las mejores caracter´ısticas.

1421

Resultados Experimentales

En esta secci´ on se presentan resultados experimentales preliminares del método propuesto aplicado a im´ agenes simuladas y a imágenes reales. Las evaluaciones comparativas del método han sido realizadas con distintos conjuntos de imágenes de rango, y con diferentes parámetros en la adquisición de las mismas. Las capturas reales fueron obtenidas utilizando la cámara de tiempo de vuelo MESA SwissRanger SR4000 [14] y las imágenes simuladas utilizando el software Blensor [21].

(a) Imagen de rango

(b) Clustering espectral

Fig. 1. Resultados sobre imagen de rango simulada

En la figura 1(a) se muestra una imagen de rango simulada compuesta por cuatro objetos equidistantes del plano focal. La figura 1(b) presenta la segmentaci´on obtenida utilizando las tres primeras columnas de H. En la figura 1(c) se muestra la segmentaci´ on obtenida utilizando las columnas de H especificadas en la tabla 1 seleccionadas por el m´etodo propuesto.

(a) Imagen de rango

(b) Clustering espectral

Fig. 2. Resultados sobre imagen de rango real

La figura 2 muestra im´ agenes del experimento realizado sobre una imagen real obtenida utilizando la c´ amara de tiempo de vuelo MESA SR4000. En la figura

1422

2(a) se muestra una imagen de rango correspondiente a dos objetos. La figura 2(b) presenta la segmentación obtenida utilizando clustering espectral. En la figura 2(c) se muestra la segmentación obtenida utilizando el método propuesto. En la tabla 1 se presentan los parámetros utilizados y las columnas de H seleccionadas.

(a) Imagen de rango

(b) Clustering espectral

Fig. 3. Resultados sobre imagen de rango real

La figura 3 muestra im´ agenes del experimento realizado sobre otra imagen real. En la figura 3(a) se muestra una imagen de rango correspondiente a dos objetos con niveles de profundidad similares. La figura 3(b) presenta la segmentaci´on obtenida utilizando clustering espectral. En la figura 3(c) se muestra la segmentaci´ on obtenida utilizando el m´etodo propuesto. En la tabla 1 se presentan los par´ ametros utilizados y las columnas de H seleccionadas.

M´etodo Columnas de H r αI

αX

Espectral

1,2,3

Propuesto

1,2,7

Espectral

1,2,3

4 0.02

Propuesto

5,7,10

4 0.02

Espectral

1,2

4 0.045 4

Propuesto

4,5

4 0.045 4

Prueba 1

Prueba 2

Prueba 3

Tabla 1.

1423

Conclusiones

En este art´ıculo se propone utilizar un método de selección de caracter´ısticas sub-´ optimo embebido en un método de clustering espectral. Los resultados experimentales preliminares sobre datos simulados y reales permiten concluir que la selecci´ on adecuada del conjunto de autovectores de la matriz de afinidad mejora la determinaci´ on de la estructura subyacente en los patrones de entrada ya sea en datos simulados como reales. El método propuesto muestra potencial para su aplicaci´ on en im´ agenes de rango y de intensidad para problemas que presenten restricciones temporales, si se utilizan cámaras con caracter´ısticas similares a la SR4000 de bajo tiempo de adquisición. El método es sensible al ajuste de los principales par´ ametros del mismo, por lo tanto como parte del trabajo futuro es necesario analizar el comportamiento de los mismos con respecto a los agrupamientos generados. Un segundo aspecto involucra evaluar el mecanismo de selecci´ on en otros métodos espectrales y realizar una evaluación comparativa de los resultados para estructuras de agrupamientos complejas.

Referencias 1. M .A. Carreira-Perpinan. A review of dimension reduction techniques. Technical report CS-96-09, Department of Computer Science, University of Sheffield, 1997. 2. I. K. Fodor. A survey of dimension reduction techniques. Technical report URL-ID148494, Center for Applied Scientific Computing, Lowrence Livemore Laboratory, 2002. 3. P. Narendra, K. Fukunaga. A branch and bound algorithm for feature subset selection. IEEE Transactions on Computers, vol. C-26, no. 9, pp.917.922, 1977. 4. A. Blum, P. Langley. Selection of relevant features and examples in machine learning. Artificial Intelligence, vol. 97(1-2), pp. 245-271, 1997. 5. M. Kudo, J. Sklansky. Comparison of algorithms that select features for pattern classifiers. Pattern Recognition, vol. 33, pp. 25-41, 2000. 6. R. E. Bellman. Adaptive Control Processes: A Guided Tour. Princeton University Press, 1961. 7. J. Shi, J. Malik, Normalized cuts and image segmentation. Proceedings of IEEE Computer Society Conference on Computer Vision and Pattern Recognition, pp. 731-737. 1997 8. P. Perona, W. T. Freeman. A factorization approach to grouping. ECCV, pp. 655670. 1999. 9. A. Y. Ng, M. I. Jordan, Y. Weiss. On Spectral Clustering: Analysis and an algorithm. Advances in Neural Information Processing Systems, vol. 14, 2002. 10. T. Xiang, S. Gong. Spectral clustering with eigenvector selection. Pattern Recognition Vol. 41, 1012-1029, 2008. 11. F. Zhao, L. Jiao, H. Liu, X. Gao, M. Gong. Spectral clustering with eigenvector selection based on entropy ranking. Neurocomputing Vol. 73, pp. 1704-1717, 2010. 12. S. A. Toussi, H. S. Yazdi. Feature Selection in Spectral Clustering. International Journal of Signal Processing, Image Processing and Pattern Recognition vol. 4, No. 3, pp. 179-194, 2011. 13. P. Pudil, J. Novovicova, J. Kittler. Floating search methods in feature selection. Pattern Recognition Letters vol. 15, pp. 1119-1125, 1994.

1424

14. M. Cazorla, D. Viejo, C.Pomares. Study of the SR 4000 camera. XI Workshop de Agentes F織覺sicos, Valencia, 2010. 15. A. A. Dorrington, C. D. Kelly, S. H. McClure, A. D. Payne, M. J. Cree. Advantages of 3D Time of Flight Range Imaging Cameras in Machine Vision Applications. 16th Electronics New Zealand. Dunedin, New Zealand, 95-99, 2009. 16. S. May, B. Werner, H. Surmann, K. Pervolz. 3D time-of-flight cameras for mobile robotics. IEEE International Conference on Intelligent Robots and Systems, pp.790-795, 2006. 17. A. Prusak, O. Melnychuk, H. Roth, I. Schiller, R. Koch. Pose estimation and map building with a Time of Flight camera for robot navigation. International Journal of Intelligence Systems Applications, vol. 5, pp. 355-364, 2008. 18. P. Pudil, F.J. Ferri, J. Novovicova, J. Kittler. Floating Search Methods for Feature Selection with Nonmonotonic Criterion Functions. Proceedings of 12th IAPR Iternational Conference vol. 2, pp. 278-283, 1994. 19. A. W. Whitney. A direct method of nonparametric measurement selection. IEEE Transactions on Computers, vol.20, pp. 1100-1103, 1971. 20. J. Shi, J. Malik, Normalized Cuts and Image Segmentation. IEEE Transactions on Pattern Analysis and Machine Inteligence, Vol. 22, No. 8, pp. 888-905, 2000. 21. M. Gschwandtner; R. Kwitt; A. Uhl, BlenSor: Blender Sensor Simulation Toolbox. Proceedings of 7th International Symposium In Advances in Visual Computing. ISVC 2011, 2011.

1425

Isolated Spanish Digit Recognition based on Audio-Visual Features Gonzalo D. Sad, Lucas D. Terissi and Juan C. GÂ´omez Lab. for System Dynamics and Signal Processing, Universidad Nacional de Rosario, Argentina CIFASIS-CONICET, Rosario, Argentina {sad, terissi, gomez}@cifasis-conicet.gov.ar

Abstract. The performance of classical speech recognition techniques based on audio features is degraded in noisy environments. The inclusion of visual features related to mouth movements into the recognition process improves the performance of the system. This paper proposes an isolated word speech recognition system based on audio-visual features. The proposed system combines three classifiers based on audio, visual and audio-visual information, respectively. An audio-visual database composed by the utterances of the digits (in Spanish language) is employed to test the proposed system. The experimental results show a significant improvement on the recognition rates through a wide range of signal-to-noise ratios. Keywords: Speech recognition, audio-visual speech features, Hidden Markov Models

Introduction

In recent years, significant research efforts have been devoted to the development of Multimodal Human Computer Interfaces (HCIs) that try to imitate the way humans communicate with each other, which is inherently a multimodal process, in the sense that, for the transmission of an idea, not only is important the acoustic signal but also the facial expressions and body gestures [4]. For instance, a significant role in spoken language communication is played by lip reading. This is essential for the hearing-impaired people, and is also important for normal listeners in noisy environments to improve the intelligibility of the speech signal. Audio Visual Speech Recognition (AVSR) is a fundamental task in HCIs, where the acoustic and visual information (mouth movements, facial gestures, etc.) during speech are taken into account. Several strategies have been proposed in the literature for AVSR [7][6], where improvements of the recognition rates are achieved by fusing audio and visual features related to speech. As it is expected, these improvements are more notorious when the audio channel is corrupted by noise, which is a usual situation in speech recognition applications. These strategies usually differ in the way the audio and visual information is extracted and

1426

combined, and the AV-Model employed to represent the audio-visual information. These approaches are usually classified according to the method employed to combine (or fuse) the audio and visual information, viz., feature level fusion, classifier level fusion and decision level fusion [2]. In feature level fusion (early integration), audio and visual features are combined to form a unique audio-visual feature vector, which is then employed for the classification task. This strategy is effective when the combined modalities are correlated, since it can exploit the covariance between the audio and video features. This method requires the audio and visual features to be exactly at the same rate and in synchrony, and usually performs a dimensionality reduction stage, in order to avoid large dimensionality of the resulting feature vectors. In the case of classifier level fusion (intermediate integration), the information is combined within the classifier using separated audio and visual streams, in order to generate a composite classifier to process the individual data streams [5]. This strategy has the advantage of being able to handle possible asynchrony between audio and visual features. In decision level fusion (late integration), independent classifiers are used for each modality and the final decision is computed by the combination of the likelihood scores associated to each classifier [3]. Typically, these scores are fused using a weighting scheme defined based on the reliability of each unimodal stream. This strategy does not require strictly synchronized streams. In this paper an isolated digit recognition system based on audio-visual features is proposed. This system is based on the combination of early and late fusion schemes. In particular, acoustic information is represented by mel-frequency cepstral coefficients, and visual information is represented by coefficients related to mouth shape. The efficiency of the system is evaluated considering noisy conditions in the acoustic channel. The proposed system combines three classifiers based on audio, visual and audio-visual information, respectively, in order to improve the recognition rates through a wide range of signal-to-noise ratios (SNRs). A Spanish audio-visual database is employed to test the proposed system. The experimental results show that a significant improvement is achieved when the visual information is considered. The rest of this paper is organized as follows, the audio, visual and audiovisual features used for each classifier are described in section 2 together with the database used for the experiments. The proposed classifiers and the early integration strategy are analyzed in section 3. A general description of the proposed system using the late fusion scheme is given in section 4. In section 5 experimental results are presented, where the performance of the proposed strategy is analyzed. Finally, some concluding remarks and perspectives for future work are included in section 6.

Audiovisual Database and Features

In order to evaluate the proposed speech recognition system an audio-visual database was compiled. This database consists of videos of 16 speakers facing

1427

the camera, pronouncing a set of ten words 20 times, in random order. These words correspond to the Spanish utterances of the digits from zero to nine. The videos were recorded at a rate of 60 frames per second with a resolution of 640Ă&#x2014;480 pixels, and the audio was recorded at 8 kHz synchronized with the video. All the recorded words in the videos were automatically segmented based on the audio signal, by detecting zero-crossings and energy level in a frame wise basis. The audio signal is partitioned in frames with the same rate as the video frame rate (60 frames per seconds). For a given frame t, the first eleven non-DC Mel-Cepstral coefficients are computed and used to compose a vector denoted as at . In order to take into account the audio-visual co-articulation, the information of tca preceding and tca subsequent frames is used to form the audio feature vector at frame t, oat = atâ&#x2C6;&#x2019;tca , . . . , at , . . . , at+tca . Visual features are represented in terms of a simple 3D face model, namely Candide-3 [1]. This 3D face model, depicted in Fig. 1(a), has been widely used in computer graphics, computer vision and model-based image-coding applications. The advantage of using the Candide-3 model is that it is a simple generic 3D face model, adaptable to different real faces, that allows to represent facial movements with a small number of parameters. The method proposed by the present authors in [8] is used to extract visual features related to mouth movements during speech. As it is described in [8], this visual information is related to the generic 3D model and it does not depend on the particular face being tracked, i.e, this method retrieves normalized mouth movements. The mouth shape at each frame t is then used to compute three visual parameters, viz., mouth height (vH ), mouth width (vW ) and area between lips (vA ), as depicted in Fig. 1(b). These three parameters are used to represent the visual information at frame t, denoted as vt . Similarly to the case of acoustic information, tcv preceding and tcv subsequent frames are used to form the visual feature vector at frame t, ovt = vtâ&#x2C6;&#x2019;tcv , . . . , vt , . . . , vt+tcv . For a particular frame t, the audio-visual feature vector is composed by the concatenation of the associated acoustic and visual feature vectors, that is oavt = [oat , ovt ] .

(1)

Early Integration

In most applications the acoustic channel is corrupted by noise, degrading the recognition rates of audio-only speech recognition systems. The proposed system aims to improve the recognition rates in these situations, by fusing audio and visual features. In the presence of noise in the acoustic channel, the efficiency of a classifier based on audio-only information decreases as the SNR decreases. On the other hand, the efficiency of a visual information classifier remains constant, since it does not depends on SNR. However, the use of only visual information is usually not enough to obtain relatively good recognition rates. It has been shown in several works in the literature [4][7][6], that the use of audio-visual

1428

vW vA vH

(a)

(b)

Fig. 1. (a) Candide-3 face model. (b) Visual parameters.

feature vectors (early integration) improves the recognition rate in the presence of noise in comparison to the audio-only case. In this section, the performances of audio, visual, and audio-visual classifiers are evaluated using audio-visual features extracted from the compiled database, described in section 2. Then, these results are used to derive the proposed late integration strategy described in section 4. Visual classifier. The visual feature vector ovt at frame t is composed by the concatenation of the visual information contained in tcv preceding and tcv subsequent frames (see section 2). Experiments with 0 to 7 frames of coarticulation (tcv ) were carried out. It must be noted that there is no need to carry out these tests considering different SNRs, since the visual features are not affected by the acoustic noise. The results of these experiments are depicted in Fig. 2, using boxplot representation. As it is customary, the top and bottom of each box are the 75th and 25th percentiles of the samples, respectively, the line inside each box is the sample median, and the notches display the variability of the median between samples. These results were computed across all the words in the vocabulary. Audio classifier. Similarly to the case of visual feature vectors, the audio feature vector oat at frame t is composed by the concatenation of the acoustic information contained in tca preceding and tca subsequent frames. To select the optimum value of tca , experiments with 0 to 6 frames of coarticulation were performed. Since the efficiency of the audio classifier depends on the SNR, these experiments were carried out using several SNR levels for two types of noise: additive Gaussian noise and Babble noise. In Fig. 3, the results derived from these experiments are shown, where only the medians for each noise level and coarticulation parameter, are depicted for visual clarity reasons. Audio-Visual classifier. The audio-visual fusion (early integration) proposed in this paper is based on the concatenation of the audio and visual feature vectors associated to each frame t, as stated in (1). Thus, there are two parameters that define the audio-visual vector: tca and tcv . Modifying these values

1429

Recognition rate [%]

tcv

Fig. 2. Recognition rate of the visual classifier using different values of tcv .

different structures can be obtained. In a similar fashion than for the audio classifier and video classifier, experiments were performed for tca and tcv ranging from 0 to 5. These tests were carried out considering different SNRs for the cases of Gaussian and Babble noises. Figure 4 shows the recognition rates obtained for the different SNRs and the two considered noises, for three particular audio-visual fusion configurations, namely – tca = 1 and tcv = 5, denoted as A1 V5 , – tca = 5 and tcv = 5, denoted as A5 V5 , – tca = 5 and tcv = 1, denoted as A5 V1 . It can be noted from Fig. 4 that the better performance at low SNRs is obtained for the case of configuration A1 V5 , while configurations A5 V5 and A5 V1 present the better performances at high SNRs. The performance of the remaining configurations lies between these curves following the same properties. Considering the results associated to each classifier, depicted in Figures 2, 3 and 4, it can be clearly noted that the audio classifier performs better than the visual one for high SNRs and viceversa. The combination of audio-visual features leads to an improvement of the recognition rates in comparison to the audio-only case. However, for the case of low SNRs, the audio-visual classifier performs worse than the visual one since fused audio-visual features are degraded by the highly corrupted acoustic data. Using different combination of acoustic and visual features, different performances can be obtained. For instance, if the audio-visual features contains more visual than acoustic information, the performance at low SNRs is improved since visual information is more reliable in this case. However, the efficiency at high SNRs is deteriorated, where the acoustic information is more important. Even for cases where a small portion of

1430

CLEAN

40 db 35 db

Recognition rate [%]

100

80 30 db 70 25 db 60 50

20 db

40 15 db

100

CLEAN 40 db

35 db

25 db

20 db

50 15 db 40 30

10 db

5 db 0 db −5 db −10 db

30 20 10

30 db

tca

(a) Babble Noise

tca

(b) Gaussian noise

Fig. 3. Efficiency of the acoustic classifier using different values of tca and different SNRs, for the cases of considering (a) Babble noise, and (b) Gaussian noise.

audio information is considered, a notorious improvement could be obtained for low SNRs, but the efficiency at high SNRs could be worse than for the audio-only case. Thus, there exists a trade-off between performance at low and high SNRs.

Late Integration

Taking into account the analysis presented in the previous section, the recognition system proposed in this paper combines three different classifiers based on audio, visual and audio-visual information, respectively, aiming at recognizing the input word and maximizing the efficiency over the different SNRs. In the training stage, a combined classifier is trained for each particular word in the vocabulary. Then, given an audio-visual observation sequence associated to the input word to be recognized, denoted as Oav , which can be partitioned into acoustic and visual parts, denoted as Oa and Ov , respectively, the probability (Pi ) of the proposed combined classifier corresponding to the i-class is given by α

Pi = P (Oa |λai ) P (Ov |λvi ) P (Oav |λav i ) ,

(2)

where P (Oa |λai ), P (Ov |λvi ) and P (Oav |λav i ) are the probabilities corresponding to the audio (λai ), visual (λvi ) and audio-visual (λav i ) classifiers, respectively, and α, β and γ are real coefficients that satisfy the following condition α + β + γ = 1.

(3)

The visual (λv ) classifier is more useful at low SNRs (β is predominant), where the acoustic data is highly corrupted by noise, while at medium levels of SNRs, the audio-visual classifier (λav ) retrieves the better decisions (γ is predominant). For high SNR conditions, an audio classifier (λa ) is employed (α is predominant). A block diagram representing this computation is depicted in Fig. 5.

1431

100

Recognition rate [%]

100

60 50

A1 V5 A5 V5 A5 V1

60 50

A1 V5 A5 V5 A5 V1

10 −10

−5

40 CLEAN

−10

−5

SN R [db]

40 CLEAN

SN R [db]

(a) Babble Noise

(b) Gaussian noise

Fig. 4. Performance of the audio-visual classifier over the SNRs for three different fusion configurations. (a) Babble noise. (b) Gaussian noise.

λai Feature Extraction Audio-visual data

Audio Features

λav i

Visual Features

λvi

P (Oa |λa i) Pav X

P (Ov |λv i)

Fig. 5. Schematic representation of the computation of the probability associated to a particular class i for the proposed combined classifier. Pav refers to P (Oav |λav i ).

Experimental Results

In this section, the proposed audio-visual speech recognition system is evaluated using the audio-visual database described in section 2. For each experiment reported in this section, 50 round cross-validation was performed, randomly selecting 70% of the database for training and using the remaining 30% for testing. In these experiments the coefficients of the feature vectors were normalized by subtracting the corresponding sample mean and dividing by the corresponding sample variance, computed over the corresponding training set. To evaluate the recognition rates under noisy acoustic conditions, experiments with additive Gaussian noise and Babble noise, with SNRs ranging from -10 dB to 40 dB, were performed. As it was previously described, the proposed audio-visual speech recognition system combines three classifiers based on audio, visual and audio-visual information, respectively, in order to improve the recognition rates for different SNRs.

1432

These individual classifiers are implemented using left-to-right Hidden Markov Models (HMM) with continuous observations. In order to select the optimum HMM structure, several experiments were performed considering numbers of states in the range from 3 to 7, numbers of Gaussian mixtures from 4 to 11, and full and diagonal covariances matrices. These tests were carried out for the three cases, namely audio, visual and audio-visual features. Based on these experiments, an optimum HMM structure with 4 states, 6 Gaussian mixtures and full covariance matrices was selected for the three different classifiers. 5.1

Classifier selection

For the visual classifier, the results depicted in Fig. 2 shown that the higher accuracy was obtained for 5 frames of coarticulation, which corresponds to a visual feature vector ovt composed by 33 parameters. In the time domain, this corresponds to a sliding window of 183 msec approximately. Thus, tcv = 5 was adopted for this classifier. For the audio classifier, it must be noted that the selection of tca should be done taking into account that the contribution of this classifier to the final decision stage is important at high SNR conditions. For that reason and looking at Fig. 3, tca = 4 or tca = 5 or tca = 6 could be selected. In order to reduce the dimensionality of the resulting audio feature vectors, without significatively affecting the efficiency of the classifier, tca = 4 was adopted, which corresponds to audio feature vectors composed by 99 parameters. In the time domain, this corresponds to a sliding window of 150 msec. Regarding the selection of the optimal audio-visual classifier configuration to be used at the final decision stage, it must be taken into account that the contribution of this classifier is important at low and middle range SNR conditions, since at high SNR the audio classifier provides more accurate decisions. Thus, from Fig. 4 an adequate configuration for this purpose is the one using tca = 1 and tcv = 5, i.e., configuration A1 V5 . 5.2

Decision level integration

As mentioned in section 4, the combination of the probabilities computed from the independent classifiers, is carried out by the weighted multiplication of the individual probabilities, see Eq. (2), where coefficients α, β and γ modify the contribution to the final decision of the audio, visual and audio-visual classifiers, respectively. The values of these coefficients should be modified for the different SNRs, so that the higher contribution at low SNR comes from the visual classifier, at medium SNRs from the audio-visual classifier, and at high SNRs from the audio classifier. Several experiments were performed using different possible combinations of them to achieve the optimum values. The results of these test are depicted in Fig. 6. For both cases of considering Gaussian and Babble noises, it can be seen that the optimum value of α is the lower one at low SNRs, and it increases as the SNR increases, becoming the higher one at clean audio. On

1433

the other hand, the optimum values of coefficient β present an inverse evolution. While for the case of coefficient γ the higher values are at medium SNRs. 1

α β γ

0.9 0.8

0.8

0.7

0.6

Value

α β γ

0.9

0.5

0.4

0.3

0.2

0.1

0 −10

−5

SN R [db]

(a) Babble Noise

40 CLEAN

−10

−5

40 CLEAN

SN R [db]

(b) Gaussian noise

Fig. 6. Optimum values for coefficients α, β and γ over the SNRs. (a) Babble noise. (b) Gaussian noise.

In Fig. 7 the obtained recognition rates of the proposed fusing strategy over the SNRs, using the optimum values for the weighting coefficients α, β and γ, are presented. In this figure, the recognition rates corresponding to the audio, visual and audio-visual classifiers are also depicted. It is clear that the proposed objective of improving the recognition rates through the different SNRs has been accomplished.

Conclusions

Improvements of speech recognition rates by the incorporation of visual data related to the mouth movements and the late integration of different classifiers are presented in this paper. An isolated Spanish digit recognition system based on audio-visual information was developed to test the proposed system. The acoustic information is represented by mel-frequency cepstral coefficients, while the visual information is represented by coefficients related to mouth shape. Three classifiers based on audio, visual and audio-visual information, respectively, are combined in the proposed system in order to improve the recognition rates through a wide range of signal-to-noise ratios. A Spanish audio-visual database was compiled in order to evaluate the efficiency of the system, considering noisy conditions in the acoustic channel. The experimental results show that a significant improvement is achieved when the visual information is considered. It is important to note that, the absolute recognition rates could be further improved by considering well-known strategies usually employed in speech recognition, for instance, using delta mel-cepstral coefficients in the audio features,

1434

100

80 70 60 50 40

λa λvav λ Fusion

30 20 10

Recognition rate [%]

100

80 70 60 50 40

λa λvav λ Fusion

30 20 10

−10

−5

SN R [db]

(a) Babble Noise

40 CLEAN

−10

−5

40 CLEAN

SN R [db]

(b) Gaussian noise

Fig. 7. Recognition rates of the proposed fusing strategy, audio, visual and audio-visual classifiers.

including noisy features in the training stage, etc. Work is in progress, where the extension of the proposed system to the case of continuous speech recognition is considered.

References 1. Ahlberg, J.: Candide-3 - an updated parameterised face. Tech. rep., Department of Electrical Engineering, Linkping University, Sweden (2001) 2. Dupont, S., Luettin, J.: Audio-visual speech modeling for continuous speech recognition. IEEE Trans. Multimedia 2(3), 141–151 (Sep 2000) 3. Estellers, V., Gurban, M., Thiran, J.: On dynamic stream weighting for audio-visual speech recognition. IEEE Transactions on Audio, Speech, and Language Processing 20(4), 1145–1157 (2012) 4. Jaimes, A., Sebe, N.: Multimodal human-computer interaction: A survey. Comput. Vis. Image Understand 108(1-2), 116–134 (2007) 5. Nefian, A.V., Liang, L., Pi, X., Xiaoxiang, L., Mao, C., Murphy, K.: A coupled hmm for audio-visual speech recognition. In: International Conference on Acoustics, Speech and Signal Processing (CASSP02). pp. 2013–2016 (2002) 6. Potamianos, G., Neti, C., Gravier, G., Garg, A., Senior, A.W.: Recent advances in the automatic recognition of audio-visual speech. In: PROC. IEEE. vol. 91, pp. 1306–1326 (2003) 7. Shivappa, S., Trivedi, M., Rao, B.: Audiovisual information fusion in human computer interfaces and intelligent environments: A survey. Proceedings of the IEEE 98(10), 1692–1715 (2010) 8. Terissi, L., G´ omez, J.: 3D head pose and facial expression tracking using a single camera. Journal of Universal Computer Science 16(6), 903–920 (2010)

1435

Desarrollo de una Ficha Anestésica Web en Áreas criticas Gustavo Bianco 21, Marcelo Sabalza1, Daniel Luna1,Gustavo García Fornari2, Jorge Garbino1, Martín Waldhorn2, Estefania Tarsetti1 1

Departamento de Informatica en Salud, Hospital Italiano de Buenos Aires, Juan D. Peron 4190, Capital Federal, Argentina 2 Servicio de Anestesia, Hospital Italiano de Buenos Aires, Juan D. Peron 4190, Capital Federal, Argentina E-mail: gustavo.bianco@hospitalitaliano.com.ar;

Abstract. Este trabajo se centra en el diseño e implementación de un sistema de registro anestésico web en tiempo real del cual se genera un documento de relevancia asistencial y legal. La solución abarca un híbrido de una aplicación web integrada en la historia clínica electrónica y una aplicación local que maneja la comunicación con el monitor de signos vitales. Debido a la criticidad del ámbito de trabajo se buscó que pueda funcionar en contingencia, logrando una aplicación robusta y confiable.. Palabras clave: Signos Vitales. Anestesiología. Ficha anestésica. Historia clínica. Informática. Tiempo real.

1 Introducción La ficha o registro anestésico es la documentación escrita y gráfica de lo que sucede durante un procedimiento anestésico. Es un documento que cumple fines médicos, legales, de investigación, docentes, estadísticos/epidemiológicos y de referencia para la facturación. A pesar de la importancia del registro anestésico, este tiene un rol secundario dentro del quirófano, ya que la prioridad del anestesiólogo es atender al paciente [1]. El llenado de este registro en papel es manual en la mayoría de las instituciones y los signos vitales como la frecuencia cardíaca, saturación de oxígeno, concentración de dióxido de carbono en la vía aérea, temperatura y tantos otros tienen que registrarse con una frecuencia mínima de 5 minutos [2]. Se ha demostrado que sin entrenamiento previo y con una inversión de bajo costo, se puede implementar en las salas de operaciones el manejo automático de la información anestésica, teniendo siempre presente que para la justicia, una buena ficha anestésica presupone siempre una buena praxis [2].

1436

La bibliografía reporta que en Estados Unidos en 1998 apenas el 1% de los departamentos de anestesia utilizaban sistemas de documentación informáticos en la sala de cirugía, y se estima que actualmente menos del 10 % de todos los hospitales cuentan con este tipo de sistemas [3]. Un estudio demostró que el 70% de los incidentes que ocurren durante el proceso de anestesia están relacionados a errores humanos, y algunos de estos incidentes muestran una falla de la comunicación funcional entre el personal médico.[4] La exactitud de la gráfica anestésica tradicional parece reducirse además significativamente en caso de incidentes críticos. Por ejemplo se observó que más del 22% de los valores registrados por 10 anestesiólogos sometidos a un incidente crítico complejo simulado, anotaron valores que discrepaban en más de un 25% de la realidad, e incluso se registraron errores superiores al 100% de la realidad. Otro aspecto importante es la posibilidad de realizar análisis posteriores por ejemplo; Benson y Col. revisaron 16.019 anestesias para localizar la existencia de episodios de hiper o hipotensión arterial, bradicardia, taquicardia e hipovolemia. Estos fueron recogidos en 911 pacientes (5,7%) de forma manual y en 2.996 pacientes (18,7%) de modo automatizado [5]. Se investigó desarrollos de software que asisten en la tarea de completar el registro electrónico con captura automática de signos vitales en tiempo real, por ejemplo MVOR de iMDsoft[6], SAFERsleep de la empresa del mismo nombre[7] y CompuRecord de Philips [8]. Se vieron varias alternativas de arquitecturas y diseños de interfaces prestando especial atención a este último punto y a la usabilidad. La mayoría del software comercial que realiza registro anestésico son aplicaciones de escritorio, las que no coinciden con el lenguaje de programación y los criterios de ubicuidad, accesibilidad y alta disponibilidad de las tecnologías de desarrollo del Departamento de Informática en salud del Hospital Italiano de Buenos Aires (HIBA). Esta institución cuenta con un sistema de salud informatizado donde la Historia Clínica Electrónica (HCE) de desarrollo propio es su aplicación central y es el repositorio de la documentación de todo acto médico [9]. La HCE es una aplicación web y se busca que la mayoría de las aplicaciones desarrolladas para interoperar con la misma también lo sean. Siendo el registro anestésico una actividad que se desarrolla en muchos casos dentro de los quirófanos, las aplicaciones web ubicadas en servidores centralizados y dependientes de redes de comunicación fisicamente distribuídas (intranets) entran en conflicto con la normativa para sistemas médicos en áreas críticas (IEC60601), las cuales exigen que los sistemas que allí se utilicen se encuentren aislados de las redes eléctricas y de las redes de datos externas. El desarrollo de la Ficha Anestésica Electrónica (FAE) surge como respuesta a múltiples problemáticas, algunas generales y otras particulares de esta Institución. Entre las generales se puede nombrar: • Problemas derivados de registros en papel, se pierden en el traslado, se traspapelan o son ilegibles, esto genera problemas médicos, legales y de facturación. • La forma de digitalizarlos es realizando un escaneo (siendo muy complicado y costoso de utilizar lo registrado para estadísticas). • Los registros se deben almacenar por ley un mínimo 10 años (SALUD PÚBLICA - Ley 26.529).

1437

•

Se estima que entre el 10 y 15 % del tiempo del anestesiólogo se utiliza para completar la ficha anestésica convencional, esta distracción implica un alto riesgo para el paciente [3]. Particularmente del HIBA: • El creciente número de quirófanos como así también de las cirugías que allí se realizan genera una cantidad creciente de información a almacenar. • Dado que el HIBA posee un sistema de Historia Clínica Electrónica, la ficha convencional queda fuera del sistema informático. • Se dificulta cualquier tipo de análisis estadístico o de investigación. • El HIBA tiene la Iniciativa papel cero. El desarrollo de la FAE busca resolver a largo plazo los problemas anteriormente enunciados como así también incluir toda la información que se registra actualmente en la ficha convencional, automatizando la mayor cantidad de tareas posibles. En este trabajo se describe el desarrollo de una solución de software y hardware para el registro en línea de una ficha anestésica electrónica web con captura automática en tiempo real de signos vitales en áreas críticas, respetando las normativas vigentes y los criterios propios de la institución.

2 Materiales y Métodos El Hospital Italiano es un Hospital Universitario de alta complejidad fundado en 1853, pertenece a una red sanitaria sin fines de lucro que incluye 2 hospitales, 23 centros periféricos ambulatorios y 150 consultorios particulares. En la red trabajan 2500 médicos, 1000 enfermeros y 2500 profesionales del equipo de salud provenientes de otras disciplinas. Con el apoyo de 1500 administrativos, los profesionales atienden 2.800.000 consultas ambulatorias y 50.000 internaciones anuales que se distribuyen en sus 750 camas (200 de cuidado críticos). Desde 1998 el HIBA cuenta con un sistema de información en salud integrado. Su historia clínica electrónica (HCE) es web, desarrollada en Java y es el repositorio de la documentación de todo acto médico. Desde el 2013 el HIBA cuenta con 30 quirófanos donde se desempeñan los anestesiólogos, de los cuales 15 pertenecen al Quirófano Central (QC). Existen normas como la IEC60601 que exigen para la atención segura del paciente que las redes de datos y eléctricas deben permanecer aisladas del entorno externo al quirófano durante la cirugía. En la etapa inicial se aprovechó que los nuevos quirófanos centrales estaban en construcción para poder preparar una infraestructura acorde a las necesidades de la FAE. Se diseñó de tal forma que cada quirófano cuenta con un rack informático propio. Además se planteó que cada quirófano sea una unidad funcional independiente y que la FAE cumpla con los siguientes requerimientos: • Tiene que poder seguir funcionando ante la eventual falla de los servidores y/o conexiones externas.

1438

•

• • •

En el caso de perder la conexión con los servidores externos, al restablecerse esta conexión debe sincronizar todo los datos que hayan quedado pendientes de actualizar. Debe considerar un funcionamiento en contingencia. Debe ser ejecutada desde dentro de la historia clínica del paciente. Debe ser Web y en el mismo lenguaje que la HCE (JAVA).

2.1 Hardware Para la primera etapa, en el QC, se diseñó una solución dividida en 2 partes: • Dentro del quirófano se ubicó un Monitor Touch de grado médico fijado mediante un brazo metálico articulado a la mesa de anestesia y un soporte porta teclado y mouse. • En el rack contiguo se alojó un CPU y la comunicación entre ambos se realiza mediante un bloque modulador/demodulador. Este diseño se justifica en que el CPU no es un equipo de grado médico y por lo cual no puede estar alojado dentro del quirófano. Como la distancia entre el CPU y los dispositivos de interfaz humana es de más de 20 metros fue necesario un bloque que module las señales para transmitirlas entre los dispositivos. Los datos son obtenidos de monitores multiparamétricos Philips modelos MP y MX ubicados en las mesas de anestesia.

2.2 Software Se optó por una arquitectura dividida en tres partes: la interfaz de usuario, la interfaz con la HCE y la interfaz con el monitor de signos vitales. A continuación se pude ver un esquema arquitectura propuesta y de sus interrelaciones (Figura 1).

1439

Figura 1: Diagrama de Arquitectura. La interfaz con el monitor multiparamétrico es un servicio web (webservice) instalado en el IIS del CPU en el rack del quirófano que está físicamente conectado al monitor de Signos Vitales. El webservice fue programado en .net como evolución de una aplicación pre-existente (SVCaptor) de desarrollo propio y utilizada desde hace 3 años de forma rutinaria en las terapias y servicios de emergencia del hospital para el registro automático de signos vitales en la HCE desde los monitores paciente Philips [10] . El protocolo de comunicación subyacente fue implementado sobre la capa de transporte física Ethernet y de comunicación lógica del protocolo UDP/IP en base a la interfaz de exportación de datos que tienen los monitores Philips, serie MP y MX y que se ajusta con bastante fidelidad al protocolo estándar de comunicación en tiempo real ISO/IEEE 11073, En este contexto, el CPU de quirófano será el cliente y el monitor el servidor (Figura 2).

1440

Figura 2: Diagrama del protocolo de comunicación. El monitor se configura para que entregue en tiempo real (una muestra por segundo) los signos vitales que le está ingresando a través de sus sensores. Una vez establecida la conexión con el monitor lo siguiente es recibir y filtrar las tramas Ethernet con los paquetes UDP portadores de los mensajes con la información de los signos vitales, parsear estos mensajes, identificar los signos vitales recibidos y tomar correctamente los valores de cada uno. Como el volumen de información es considerable se tomó la decisión de tomar una muestra por minuto de cada signo vital y almacenarla a disco localmente, dejando la potencialidad de configurar este parámetro a futuro. El web service realiza la interfaz entre la aplicación web y el monitor exponiendo métodos o funciones que le permiten iniciar la conexión, informar signos vitales disponibles, configurar cuales se desean capturar, comenzar la captura e informarlos. La interfaz con la HCE recoge de las bases de datos las cirugías programadas con los datos de los pacientes, de los médicos y ofrece una serie de servicios web llamados desde la interfaz del usuario. También al momento de tener que sincronizar la ficha anestésica electrónica se comunica con estos servicios. Una vez que se firma digitalmente la ficha se ejecutan tareas para integrar la información médica (evoluciones, problemas, prácticas, medicamentos, etc) con la HCE. La interfaz de usuario se basa en una aplicación web HTML utilizando las ventajas de los estándares de HTML5 de caché de aplicaciones HTML y de Filesystem, pudiendo con estos APIs cachear la aplicación y los datos (tantos los de la base de datos como los generados desde la aplicación). Con esta arquitectura logramos que al ejecutarse la aplicación se bajen a cache persistivo del browser los datos necesarios para completar la ficha anestésica electrónica durante el procedimiento anestésico y pudiendo grabar localmente en este cache los datos registrados durante la anestesia, corriendo como una aplicación offline con posibilidades de sincronizar con el server los datos recaudados. Esta arquitectura es especialmente robusta ante la pérdida de conexión o caída de los servicios en los servidores de la institución y toleraría un downtime de 48 horas, ya que este es el tiempo de programación de quirófanos en la institución. En el caso

1441

del que downtime sea mayor o sea un paciente de urgencia la aplicación puede funcionar sin los datos del paciente programado, cargando manualmente los datos relevantes del paciente y el episodio, para que una vez en funcionamiento la conexión con los servidores adjuntar la ficha anestésica electrónica a la historia clínica del paciente.

2.3 Registro convencional vs Electrónico Se revisaron registros anestésicos convencionales en papel, detectando fácilmente sus puntos débiles; son de difícil lectura, dependen de la claridad del anestesiólogo y están acotadas en espacio. Algo que surge a posteriori es el desaprovechamiento de la información, ya que por su poca exactitud y confiabilidad no se utilizan para trabajos de investigación ni de análisis. Finalmente se realizó una observación en quirófano, identificando en qué momentos el anestesiólogo realiza el registro anestésico en papel y el tiempo que este conlleva. A partir de todo esto, los integrantes del equipo trabajaron sobre conceptos de usabilidad, diseñaron prototipos y maquetados de la interfaz táctil para testear casos de uso con los anestesiólogos. Esta instancia permitió incluir en la etapa de diseño y desarrollo a los usuario finales, los anestesiólogos, lo que se esperaba brinde un producto con mayor satisfacción y aceptación. Finalmente se elaboró una maqueta del documento que se genera al terminar la ficha anestésica electrónica y queda adosado a la historia clínica del paciente. De comparar el registro anestésico en papel escaneado y el nuevo documento que se genera la FAE se ve una gran diferencia en lo sencillo y legible que resulta entender lo registrado.

1442

Figura 3: Ficha anestĂŠsica convencional.

1443

Figura 4: Captura de la Aplicación ejecutándose. Fi gura 5: Maq ueta del CD A que va a la HCE . A su vez se dise ñaro

1444

n interfaces para interactuar con el sistema de facturación del servicio de anestesia donde la información llega directamente, sin riesgos de traspapelarse o perderse, siendo clara y ayudando al facturista a cargar correctamente las prácticas realizadas.

3 Resultados En principio se logró cachear la información para que la aplicación pueda ejecutarse en el browser y no se vea afectada por la caída de los servidores de aplicaciones, bases de datos y/o fallas en la infraestructura física de la intranet. Luego se logró que la aplicación permita ejecutarse directamente en contingencia, sin haber logrado cachear los datos pertinentes antes de su ejecución y una vez restablecida la comunicación con el resto de los sistemas se sincronice con la base de datos central. El webservice que se comunica con el monitor se puede configurar para que en lugar de almacenar 1 muestra por minuto pueda almacenar hasta 60 muestras por minuto. Esto está pensado para que en un futuro se pueda analizar que sucede con los signos vitales pocos segundos después de que se realiza una práctica o se administra una droga. Hay que tener en cuenta que la frecuencia de registro no se puede aumentar al máximo durante un periodo muy prolongado ya que los tamaños de los archivos crecen rápidamente. En esta primera etapa la aplicación solo maneja Signos vitales, si bien esto es suficiente para la ficha anestésica se busca también que a futuro se puedan almacenar tramos de señales como la de ECG, Presiones invasivas y/o concentración de gases. Se realizaron 2 pruebas piloto en un quirófano del QC, primero se armó la parte de soporte que va unida a la mesa de anestesia, luego se realizó el montaje del CPU en rack contiguo y finalmente se colocó el monitor, mouse y teclado. Vale la pena resaltar que el brazo sobre el que va montado el monitor táctil permite regular su altura y posición para ajustarlo al usuario. Por otro lado el soporte donde van el teclado y mouse es rebatible ya que solo sería para situaciones excepcionales, pues normalmente todo se realizará desde la interfaz táctil.

1445

Figura Y: Sistema de prueba ensamblado en quirófano. Una vez montado el hardware se probó la aplicación con datos de un pacientes de prueba pero capturando y registrando los signos vitales de un paciente real. La idea de estas primeras pruebas era presentar la aplicación, probar como se navega desde la HCE hasta el acceso a la FAE y finalmente ver el desempeño de la interfaz gráfica y graficación de los signos vitales. Las pruebas dieron buenos resultados, los anestesiólogos pudieron interactuar fácilmente y de manera intuitiva, y la aceptación

1446

de la aplicación fue alta. Si bien todos los anestesiólogos que probaron la aplicación tenían sugerencia para mejoras futuras, el 100% estaba conforme tanto con el Hardware como con el software. Una vez finalizada la carga de la ficha anestésica electrónica, observamos que la información cargada representaba fielmente lo observado y capturado por el monitor, y se encontraba accesible para el resto de los sistemas (HCE, sistema de facturación, etc.).

4 Discusión Si bien el desarrollo se encuentra en su primera etapa los resultados obtenidos son coherentes con la mayoría de la bibliografía al respecto. Desde el punto de vista de la integración con otros sistemas informáticos como ser los de Historia Clínica, Contables, etc. permite una comunicación instantánea, permitiendo reducir considerablemente los tiempos de espera y procesamiento que se tienen hoy en día con la ficha convencional. Otro aspecto que cambia de manera considerable es la confiabilidad y exactitud de la información que se genera por cirugía, permitiendo que en un futuro se puedan realizar trabajos de investigación con ella. A futuro no solo se planea implementar esta ficha en todos los quirófanos sino también en todos los sectores que se realicen procedimientos de anestesia, esto requerirá entre otras cosas, migrar la aplicación para que funcione en dispositivos móviles tipo tablet. Una vez completado el desarrollo se espera que la ficha no solo reemplace al papel, sino que agregue nuevas funcionalidades, como por ejemplo la posibilidad de que mediante inteligencia artificial se disparen alertas que asistan al anestesiólogo. Hay que tener en cuenta también que al digitalizarse la ficha anestésica esta contiene información sensible del paciente, por lo que se debe asegurar la seguridad y confidencialidad de la misma.

5 Conclusión Esta primera etapa del desarrollo presenta mucho más que un saldo positivo, se logró establecer una conexión estable con el monitor Philips y realizar la captura de los signos vitales en tiempo real. Cabe destacar que el registro electrónico generado aumenta la frecuencia de muestreo 5 veces y asegura una confiabilidad del dato que la ficha convencional no posee. Se comprobó que la sincronización de datos previa y posteriormente al procedimiento anestésico permite un correcto funcionamiento en contingencia, lo cual le da una robustez y seguridad requerida para este tipo de aplicaciones. El grado de aceptación logrado fue muy satisfactorio teniendo en cuenta que se está introduciendo no sólo una aplicación, sino una nueva forma de hacer las cosas. En resumen, se logró desarrollar una solución informática a medida, partiendo de cero y con recursos propios que no solo cumple los requerimientos internos y normativa al respecto de la seguridad del paciente, sino que también contempla modernos conceptos de usabilidad y diseño, permitiendo una gran escabilidad y la posibilidad a futuro de uso en dispositivos móviles.

1447

Bibliografía 1. Pini M., Lossetti O. and Trezza F., 2002 Suplemento del Diario del Mundo Hospitalario: Importancia Medico-Legal de la Ficha Anestesica, Año 6, Nº 26. 2. Capria J, Gómez Roca M., Tibaldi F., Wikinski J., 1997 Articulo de Investigación Clínica: Comparación De La Información Obtenida Mediante Una Ficha Anestésica Manual Vs. Una Automática Computarizada. 55: 03: 143-152. 3. Trivelato L., Pereira F., Smidarle D., Smidarle R. 2011, Revista Médica de Minas Gerais: La Anestesiologia en la Era Digital. ; Vol. 21(2 Supl 3): S28-S33. 4. Alapetite A., Gauthereau V. 2005 Annual Conference of the European Association of Cognitive Ergonomics: Introducing vocal modality into electronic anaesthesia record systems: possible effects on work practices in the operating room. Section 2 pp. 189-196. 5. Ortiz-Gómez J. R., Monedero-Rodríguez P., Pérez-Cajaraville J. J. 2002 Aplicaciones de la informática en Anestesiología: gráfica anestésica. 2002 49: 141-149 6. Página Web de iMDsoft URL: http://www.imd-soft.com/mv-pacu 7. Página Web de SAFERsleep URL: http://www.safersleep.com 8. Página Web de Philips URL: http://www.healthcare.philips.com/main/products/patient_monitoring/products/intellispace_ cca/compurecord/ 9. Gonzalez Bernaldo de Quiros F, Soriano E, Luna D, Gomez A, Martinez M, Schpilberg M, Lopez Osornio, A. Desarrollo e implementación de una Historia Clínica Electrónica de Internación en un Hospital de alta complejidad. 6to Simposio de Informática en Salud - 32 JAIIO. Buenos Aires - Argentina – 2003 10. Bibiana Schachner, Antonio E. Arias, Jorge Garbino, Guillermo Vignau, Cintia Budalich, Daniel R. Luna, Fernán González B. de Quirós. Implementación de un Registro electrónico para Enfermería en una Unidad de Cuidados Intensivos del Adulto. Congreso Infolac Guadalajara, Mexico. - 2011

1448

Detección de signos respiratorios patológicos en poblaciones avícolas productivas mediante procesamiento digital de señales acústicas Cristian Kühn and César Martínez1,2 1

Laboratorio de Cibernética, Facultad de Ingeniería, Universidad Nacional de Entre Ríos, Ruta 11, Km. 10, Oro Verde, Entre Ríos 2 Centro de Investigación en Señales, Sistemas e Inteligencia Computacional (SINC(i)), Dpto. Informática, Facultad de Ingeniería, Universidad Nacional del Litoral, Santa Fe, Argentina cristian.kuhn20@gmail.com,cmartinez@bioingenieria.edu.ar

Resumen La necesidad en detectar tempranamente la presencia de un problema sanitario en la producción avícola mejora sensiblemente las posibilidades para el control del mismo. Por ello, en éste trabajo se presenta el diseño y desarrollo de un método automático para la tarea de reconocimiento de signos patológicos respiratorios en forma temprana, orientado a la producción avícola. El sistema parte del registro de señales de pollos en galpones productivos, preprocesamiento para acondicionamiento de las señales, medición de parámetros de interés (energía, pseudoespectro) y generación de una señal de detección que indica la presencia de signos patológicos en la población estudiada. Los resultados obtenidos fueron satisfactorios, habiendo sido el sistema capaz de detectar los signos en diferentes condiciones de experimentación, desde el estudio de un solo individuo enfermo hasta la mezcla de individuos sanos y enfermos. Keywords: análisis acústico, signos respiratorios patológicos, pseudoespectro, población avícola.

Introducción

La Industria Avícola es una de las cadenas productivas más importantes del país, habiéndose consolidado como una de las más dinámicas que tiene la producción agropecuaria. En esta industria, las enfermedades respiratorias de pollos son un tema de importancia sanitaria en un establecimiento productivo, dado que presentan una morbilidad alta (80-100 %) y la mortalidad oscila entre el 5 y el 20 %, según sea el tipo y severidad del brote [1]. Conocer la presencia de signos respiratorios en la población avícola es de gran importancia para tomar una acción temprana sobre el devenir en una enfermedad crónica. En la actualidad, y hasta el conocimiento de los autores, no se cuenta con un sistema confiable y de fácil aplicación que brinde este tipo de información. Uno de los principales problemas es la adquisición y clasificación automáticas,

1449

ya que el registro audiovisual continuo es subjetivo, complicado y susceptible de errores. El procesamiento digital de señales brinda herramientas que han sido aplicadas satisfactoriamente a diversas tareas, dando la posibilidad de contar con sistemas de implementación factible en el ambiente productivo animal. En este contexto, se han reportado diversas aplicaciones del análisis acústico estrechamente relacionadas con la aquí presentada, como ser el análisis de vocalizaciones de mamíferos [2], la comunicación de murciélagos [3], o el repertorio de sonidos de ballenas [4]. Una línea de trabajo previamente explorada por los autores consiste en el análisis acústico de sonidos masticatorios de rumiantes, a fin de automatizar el comportamiento ingestivo [5,6]. El estado del arte demuestra que el análisis acústico espectral resulta atractivo por su sencillez, rapidez y relativa robustez al ruido. Es por ello que en este trabajo se plantea el diseño y desarrollo de un método para la detección de patrones de signos respiratorios patológicos en sonido. Se trata de mantener una complejidad computacional relativamente baja, lo que brinda un sistema que ser utilizado para detectar en tiempo real la presencia de los signos anómalos en la producción avícola. El resto del trabajo se organiza como se detalla a continuación. En la Sección 2 se expone detalladamente el diseño de la solución propuesta. En la Sección 3 se muestran los resultados obtenidos en diferentes condiciones experimentales. Finalmente, en la Sección 4 se resumen las conclusiones derivadas de este trabajo y se delinean trabajos futuros.

Método propuesto y materiales empleados

El problema de clasificación de signos respiratorios es similar a muchos problemas existentes en detección y clasificación de patrones. El proceso completo consta de las siguientes etapas, implementadas en el software matemático Matlab: El proceso de recolección de datos incluye la adquisición de audio usando dispositivos de grabación. Los registros son obtenidos en entornos controlados en cuanto al ruido de fondo. La extracción de características se basó en el examen espectro-temporal de los registros sonoros. Básicamente, consiste en el uso de mediciones de los picos principales en el pseudoespectro de segmentos de la señal. De la observación de los patrones se obtienen un grupo de parámetros que permitirán luego su discriminación. El reconocimiento consiste en la medición de los parámetros mencionados sobre intervalos de audio pseudo-estacionarios. El método considera una variabilidad permitida entre patrones, a fin de agregar robustez al sistema y ajustarse mejor a la realidad del problema. La Figura 1 muestra un diagrama en bloques detallado de todo el proceso. A continuación se desarrolla cada uno de ellos, ejemplificando con las señales resultantes de cada proceso dada la novedad de la solución en la tarea abordada.

1450

Figura 1. Diagrama completo del método propuesto para detección de signos respiratorios.

2.1.

Adquisición y acondicionamiento

Adquisición. Se realizaron grabaciones digitales de 60 segundos de longitud conteniendo signos respiratorios patológicos de un grupo de aves afectadas. Las mismas fueron inicialmente apartadas de su entorno para minimizar los efectos del ruido de fondo. A priori se desconocían las características espectrales de los signos patológicos, por lo que se utilizó la resolución máxima disponible: 16 bits por muestra y una frecuencia de muestreo de 44100 Hz. Para las grabaciones se empleó el micrófono on-board de una Netbook Asus I-EEE. La Figura 2 muestra un ejemplo de sonograma obtenido, de la cual se extrae el intervalo de tiempo entre los 20 y 30 s. a fin de evitar diversos ruidos: entre 10–30 s. se identifica el sonido de alboroto del pollo en tanto se estabilizaba frente al setup de adquisición, y entre 30–50 s. se registra la interferencia de un autómovil. Pre–énfasis. La señal digitalizada x(n) es sometida a un filtrado digital de bajo orden (típicamente, un filtro FIR de primer orden), para aplanar el espectro de la señal, según: x e(n) = x(n) − ax(n − 1); con a ∈ R. Filtrado y diezmado. La implementación de esta etapa está dada por la necesidad de acotar la señal x e(n) en banda, dejando pasar solamente aquéllas

1451

Figura 2. Sonograma de la pista de audio adquirida de 1 pollo con síntomas respiratorios.

frecuencias que contengan signos respiratorios. Para tal tarea se implementaron dos filtros Butterworth, un pasa altos y un pasa bajos, aplicados en ese orden respectivamente. La determinación de los parámetros de los filtros fue realizada experimentalmente por inspección del espectrograma de la señal, resultando así las frecuencias de cortes y paso necesarias. El diezmado es aplicado para submuestreo la señal por un factor entero en la forma s(n) = x e(nK), preservando de la señal original una muestra de cada instante nK. La Figura 2.1 muestra el sonograma filtrado y diezmado junto al espectrograma recortado en frecuencia a la banda de interés (0-2500 Hz). En ambos estudios se evidencian los patrones respiratorios patológicos periódicos (22 s., 24 s., etc.), inmersos en un ruido blanco de fondo. 2.2.

Procesamiento de la señal

En este bloque se busca aislar los patrones de interés evidenciados en la señal. Para ello, se calculará el pseudoespectro de la señal y se determinará un patrón característico del signo respiratorio en la señal. Para los procesos siguientes, la señal preprocesada s(n) es ventaneada en bloques de N muestras con solapamiento del 50 %, con ventaneo de Hamming. Energía. Una medida que ayuda a discernir los bloques con signos respiratorios es la energía de la señal, calculada como E = ||s(n)||22 . La Figura 4 muestra un ejemplo de análisis, donde pueden observarse los picos en la localización de los eventos de interés. Pseudoespectro. La estimación de las componentes frecuenciales de los signos respiratorios inmersos en la señal con ruido constituye la base para la clasificación. Así, se aplica en esta etapa el algoritmo MUSIC (Multiple Signal Classification) para la estimación del pseudoespectro de la señal acondicionada [7].

1452

Figura 3. Sonograma y espectrograma de la seĂąal x e(n) luego de aplicarse los filtros pasa-altos y pasa-bajos, con posterior diezmado.

Figura 4. EnergĂa contenida por cada bloque de la seĂąal s(n).

1453

Figura 5. Pseudoespectro de la señal, con sus tres componentes de interés indicadas.

El algorithmo MUSIC logra estimar el contenido frecuencial de una señal pura contaminada con ruido blanco gaussiano, mediante una descomposición en valores y vectores propios, a lo que se denomina pseudoespectro [8]. La localización de los picos de la función estimada constituye la base de la detección de signos respiratorios en la señal. La Figura 5 muestra un ejemplo de pseudoespectro calculado sobre la señal de prueba utilizada.

2.3.

Reconocimiento de signos respiratorios

Una vez determinado el patrón característico del signo respiratorio se procede a buscar su presencia dentro del sonido de audio de la realización completa. Para ello es necesario hacer el acondicionamiento previo a la señal anteriormente descripto. Luego se segmenta en bloques y sobre cada uno se aplica el algoritmo MUSIC para determinar el pseudoespectro correspondiente a cada uno. Finalmente, se genera una señal de detección D consistente en la comparación en cada segmento del pseudoespectro obtenido respecto al pseudoespectro patrón del signo patológico. La señal generada es binaria, indicando la presencia (1’s) o ausencia de signo detectado (0’s) según si la distancia euclídea dj para el jésimo segmento es menor o mayor que un umbral de referencia, respectivamente, según: v uN uX d = t (p − q )2 , (1) j

i=1

donde N es el número de muestras del segmento, p el pseudoespectro patrón del signo respiratorio y q el pseudoespectro calculado sobre el segmento. En la tarea de reconocimiento del signo respiratorio se permitieron diferencias menores a un umbral de máxima diferencia admisible, de modo de discernir entre artefactos en la señal (ruido de autos, etc.). Este umbral se ajusta experimentalmente.

1454

Figura 6. Análisis de distancia entre pseudoespectros. Sonograma de la señal analizada (arriba); distancias calculadas indicadas en el centro de cada frame considerado, sin umbral de selección (abajo).

Experimentos y resultados

A efectos de poder evaluar el desempeño del sistema de reconocimiento propuesto, se lo sometió a diferentes situaciones, de modo de poder observar y comparar aspectos en su funcionamiento. Se observará la respuesta frente a la variación en el número de pollos analizados, provenientes de un lote productivo de 15.000 pollos de 25 días de edad que evidenciaba casos de individuos con signos tempranos de afección respiratoria3 . 3

Granja avícola localizada en la provincia de Entre Ríos.

1455

Figura 7. Sonograma de la señal sin procesar de 1 pollo enfermo (arriba) y señal de detección de signos respiratorios (abajo).

3.1.

Pruebas con un solo pollo enfermo

En esta instancia se aisló a un pollo con signos respiratorios patológicos, en un recinto alejado del galpón donde se aloja el lote productivo. La distancia del micrófono al pollo fue de alrededor de 10 cm. La Figura 7 muestra un ejemplo de los resultados obtenidos. Se puede observar cómo el sistema reconoce la presencia del signo respiratorio solamente en aquellos intervalos donde no se presenta ruido, ignorando en este caso la presencia de ruidos al inicio (aproximadamente los primeros 5 s.) y al final la perturbación por un ruido de automóvil (aproximadamente a los 40 s.). 3.2.

Pruebas con varios pollos enfermos

En la Figura 8 se puede observar la señal adquirida de un grupo de 4 pollos enfermos y cómo el sistema reconoce el signo respiratorio en aquellos intervalos sin presencia de ruidos anormales. A diferencia del caso testigo anterior, se observa aquí una mayor periodicidad en los eventos respiratorios de la señal, así como también un incremento en su amplitud. Esto se debe a una respiración parcialmente sincronizada por pequeños subgrupos de pollos, una característica particular de la enfermedad. 3.3.

Prueba con mezclas de pollos enfermos y sanos

En la Figura 9 se puede observar el caso de una señal perteneciente a una multitud de 7 pollos enfermos, mezclados con individuos sanos (aproximadamente 10 aves/m2 ), registrada con un micrófono colgando 10 cm. sobre los pollos.

1456

Figura 8. Sonograma de la señal sin procesar de 4 pollos enfermos (arriba) y señal de detección de signos respiratorios (abajo).

En este caso, las condiciones desfavorables de ruido en el entorno dificultan la tarea de detección y fue necesaria una modificación en el umbral empleado anteriormente, reduciéndose el intervalo en el cual el sistema detecta la presencia de signos respiratorios.

Conclusiones

En este trabajo se ha presentado el diseño y desarrollo de una técnica computacional de procesamiento de señales de audio que demostró ser de utilidad para la producción avícola, brindando una herramienta automática para la detección temprana de signos respiratorios patológicos. A partir del registro acústico de los pollos en galpón, empleando técnicas de filtrado y estimación frecuencial, se logró identificar la morfología de signos respiratorios patológicos e identificar la presencia de los mismos en individuos del ambiente productivo. Una línea de continuación de este trabajo, posterior a la detección del signo patológico, lo constituye la cuantificación estadística de la incidencia de la patología en la población. Este análisis serviría para determinar, mediante un muestreo de la población de un galpón, si la misma presenta o no signos y establecer diferentes niveles de afectación. Por otro lado, en este trabajo se presenta la técnica y experimentación preliminar para demostrar su fiabilidad. Es necesario, por lo tanto, ampliar la experimentación a poblaciones mayores dentro de los galpones, realizando los ajustes necesarios en el sistema para aumentar la robustez en el ambiente natural de producción.

1457

Figura 9. Sonograma de la señal sin procesar de mezcla de pollos enfermos y sanos (arriba) y señal de detección de signos respiratorios (abajo).

Agradecimientos Los autores desean agradecer a la Agencia Nacional de Promoción Científica y Tecnológica (bajo proyecto PAE 37122), la Universidad Nacional de Litoral (PACT #58, CAI+D 2011 #58-511, #58-525).

Referencias 1. SENASA. Plan nacional de sanidad avícola, 2003. 2. L. Schrader and K. Hammerschmidt. Computer-aided analysis of acoustic parameters in animal vocalisations: a multi-parametric approach. Bioacoustics, 7(4):247– 265, 1997. 3. Jagmeet S Kanwal, Sumiko Matsumura, Kevin Ohlemiller, and Nobuo Suga. Analysis of acoustic elements and syntax in communication sounds emitted by mustached bats. The Journal of the Acoustical Society of America, 96:1229, 1994. 4. Christopher W Clark. The acoustic repertoire of the southern right whale, a quantitative analysis. Animal Behaviour, 30(4):1060–1071, 1982. 5. D. H. Milone, J. Galli, C. E. Martínez, H. L. Rufiner, E. Laca, and C. Cangiano. Reconocimiento automático de sonidos masticatorios en rumiantes. In Anales de las 37 Jornadas Argentinas de Informática, JII-Agroinformática, pages 372–384, Santa Fe, Argentina, september 8-12 2008. 6. D. H. Milone, J. Galli, C. Cangiano, H. L. Rufiner, and E. Laca. Automatic recognition of ingestive sounds of cattle based on hidden markov models. Computers and Electronics in Agriculture, 87:51–55, sep 2012. 7. Ralph Schmidt. Multiple emitter location and signal parameter estimation. Antennas and Propagation, IEEE Transactions on, 34(3):276–280, 1986. 8. L. Marple. Digital Spectral Analysis With Applications. Prentice-Hall, 1987.

1458

Sievert-type measurement and acquisition system for the study of hydrogen storage in solids Jorge Runco, Marcos Meyer IFLP – Departamento de Física – Facultad de Ciencias Exactas – UNLP CONICET { runco, meyer }@fisica .unlp.edu.ar Abstract This paper shows the development and implementation of a system to determine and analyze parameters of interest in the study of hydrogen absorption and desorption mechanisms in solids using the Sievert volumetric method. The experiment is controlled through a PC-type computing system by automatically measuring, controlling, recording and graphing the evolution of variables (pressures and temperatures) according to a set of previously programmed parameters. The manual monitoring, adjustment and operation option is also available to tune the experiment. The software was developed in a high-level programming language (Delphi) which offers the user a graphical interface typical of visual languages. In addition, results for applying the present system to typical ternary hydrides are presented. Key words: hydrogen storage, processes, absorption and desorption, data acquisition.

1. Introduction One of the most important challenges for the development of hydrogen utilization as an energy vector is the possibility of storing it in a safe and effective way [1]. Hydrogen in a gaseous state occupies a very large volume and requires very high pressures in storage reservoirs whereas, in a liquid state, it needs reservoirs at very low temperatures. Since hydrogen is highly reactive, there is a significant number of elements capable of reacting with it to form hydrides under appropriate pressure and temperature conditions. Hence, hydrogen storage in a solid state appears as a more effective alternative in terms of volume with respect to the other methods mentioned above. Absorption in metals, which forms a hydride phase, has many advantages over current systems (compression and liquefaction), since it does not require compressing and liquefying tasks or cryogenic temperatures. An important aspect in experimental research is the analysis of hydrogen absorption-desorption properties of new materials, as well as the study of absorption and desorption kinetics. As considerable pressure changes involve relatively small mass quantities, using volumetric techniques is especially suitable for this kind of research (mainly considering that hydrogen is the lightest element of all).

2. Measurement system description The equipment is based on a Sievert-type system [2], which allows studying hydrogen absorption-desorption kinetics at different temperatures, keeping pressure level constant in the reaction chamber, in a wide range of temperatures (from 300 K to 1000 K) and pressures (from 1 mbar to 50 bar).

1459

Figure 1. Schematic diagram of the Sievert apparatus.

The measuring instrument was developed based on a PC-type computing system which incorporates a 12-bit general purpose A/D interface [3], 5 inputs of which are used to measure analog magnitudes â&#x20AC;&#x201C;4 for pressures and 1 for temperature. It also has digital outputs for the automatic opening and closing of the 7 solenoid valves (V1, V2, V3, V4, V5, PV1 and PV2) of the measurement system. The schematic diagram above illustrates the location of pressure sensors [4] in the experiment as well as valves automatically actuated by the control system. The measurement system has a furnace and a temperature controller to conduct the experiment at different sample temperatures. This controller communicates with the computer by means of an RS-232 interface and MODBUS protocol [5]. A flowmeter was added to the system to control and measure gas flow during the experiment. This device communicates with the computer also through an RS-232 interface and the MODBUS protocol. The software developed makes it possible to open and close solenoid valves at any desired time, to acquire and store parameters of interest â&#x20AC;&#x201C;pressures, temperature and flowâ&#x20AC;&#x201C; and to preset temperature and flow values (setpoints) before starting the experiment. In addition, routines necessary to communicate with furnace and gas flow controllers through the MODBUS protocol were implemented. During the course of the experiment, the abovementioned parameters are acquired and stored, valves open and close when pressure conditions set before starting the measurement are met or for controlling gas flow with the flowmeter, and the system is capable of performing the experiment at a constant temperature, with linearly increasing temperature (temperature ramp), when cooling, or with a combination of these stages. Figure 2 shows the interconnection between the different modules and components. The Signal Adaptation Electronics module is in charge of conditioning (instrumentation amplifiers) signals coming from sensors at the input of the A/D converter. Moreover, this module is equipped with the circuits needed to actuate the valves with digital signals since they operate with 220 V. Isolation between this voltage and the computing system is required; this is accomplished with optically-coupled circuits.

1460

Figure 2. Acquisition and control diagram.

3. Results The equipment described above was used in several experiments for studying the kinetics of absorption and desorption to form typical ternary hydrides. Figure 3 displays temperature and evolution of the materialâ&#x20AC;&#x2122;s pressure when releasing hydrogen according to time. When preset pressure conditions are met, valves automatically open and close between these two values. When hydrogen is released, pressure increases up to a certain value, hydrogen is discharged, pressure decreases, and the cycle is repeated until the sample releases all the hydrogen. Figure 4 illustrates the analytical treatment of measured data.

Figure 3. Temperature according to time. Sample desorption. Pressure variation according to time.

1461

Figure 4. Desorption data treatment.

4. Conclusions This paper describes the development and implementation of a piece of equipment for studying hydrogen absorption and desorption in metals. Having used commercially available components, the importance of this proposal lies in its low cost. The design complies with the requirements specified by a research group from the IFLP (Instituto de Física de La Plata [La Plata Physics Institute] - CONICET [for its Spanish acronym, National Council of Scientific and Tehnical Research]), Departamento de Física, Facultad de Ciencias Exactas, UNLP [Physics Department, Faculty of Exact Sciences, National University of La Plata]) that is part of the project “Materiales nanoestructurados de aplicación en energías alternativas: síntesis, caracterización y modelado” [“Nanostructured materials applicable to alternative energies: synthesis, characterization and modeling”]. The design currently in operation went through several stages: from the development and implementation of the signal adaptation module, to the software that controls and automates the experiment, up to the present situation with variations from the original experiments: constant temperature test, with (linear) increase, acquisition during cooling and gas flow measurement and control.

5. References [1] Optimización de un hidruro complejo para almacenamiento de hidrógeno. Ph.D. thesis. June, 2009 – Cardozo, César Luis - Centro Atómico Bariloche [Bariloche Atomic Center]. [2] R. Checchetto, G. Trettel and A. Miotello. 2003 – Sievert-type apparatus for the study of hydrogen storage in solids. Measurement Science and Technology. [3] Conversor A/D- ADQ-12 – Microaxial [4] Druck-PDCR 4000 Series – High Performance Millivolt Output Pressure Transducers. Motorola MPX2200 Series – On-Chip Temperature Compensated & Calibrated Pressure Sensors. [5] MODBUS Protocol Specification - http://www.modbus.org.

1462

Declarado de InterĂŠs Municipal por el Honorable Concejo Deliberante del Partido de General Pueyrredon