Auger Muon and Infill for the Ground Array Observatorio Pierre Auger

Sistema de Adquisición

El primer prototipo que se instaló en Julio del 2008 en tres detectores ubicados a 200m de distancia, el proceso que se ejecuta en la SBC (SUSimulator) del detector de superficie se comunicaba a través de TCP/IP con el sistema de adquisición de datos. Es decir, que el proceso SUSimulator recibía los datos de la electrónica de superficie (de ahora en más, Local Station – LS), procesaba los mensajes (esto es: calcular el CRC de los paquetes), y enviaba los paquetes al sistema de adquisición. Este nuevo sistema tuvo resultados favorables y la tasa de pérdida de paquetes era nula.

El primer diseño utilizando UDP consta de un proceso que se comunica a través de UDP/IP con los detectores de superficie y TCP/IP con el sistema de adquisición de datos. La Figura 1 muestra el primer prototipo de comunicaciones UDP.

Primer prototipo UDP

Como se puede observar, existe un proceso denominado “Concentrador”, éste proceso se encuentra en la estación central del Observatorio Pierre Auger y se encarga de recibir los datos vía UDP de los detectores de superficie, interpretar los paquetes recibidos, y restransmitirlos al sistema de adquisición

Ésta solución funcionaba cuando teníamos pocos detectores de superficie en funcionamiento con el nuevo sistema de comunicaciones y donde el tráfico de información era relativamente poco, pero a medida que fueron aumentando los detectores de superficie, la carga de éste proceso y la cantidad de información que debía procesar iba en aumento y ésto hacía que algunos paquetes provenientes de las estaciones no se enviaran al PostMaster, perdiéndose información. Se instaló este diseño en 7 detectores. Se optó entonces por la opción de utilizar child processes donde cada uno se encarga de atender a un detector en particular, se modificó un poco el diseño (respecto a lo que se había presentado el año pasado), una de las modificaciones que se hizo es la de evitar que el detector envíe un request_connection al server antes de comenzar a transmitir. El proceso trabaja de la siguiente manera:

1- Al iniciar, proceso padre establece una conexión TCP/IP con el PostMaster.

2- El proceso padre, posee la lista de Ips de los detectores de manera tal que comienza a enviar paquetes ICMP para verificar el estado de la red AMIGA.

3- Por cada estación que le responde al paquete ICMP, el proceso crea dos pipes FIFO (uno para cada sentido de los datos).

4- Por cada estación, el proceso también genera un proceso “child” que antenderá a esa conexión, éste proceso “child” escuchará en el puerto 10000 + número_de_host (de ahí el por qué no es necesario que el detector pregunte al server en qué puerto debe escuchar, como se hacía antes, ya que solo debe revisar su IP y escuchar en dicho puerto).

5- Ahora el proceso SUSimulator que está corriendo en la SBC del detector puede establecer la conexión con el proceso “child”

De vez en cuando, el proceso padre revisará la lista de Ips, si aparece un nuevo miembro, hará los pasos 3 y 4, si existe una estación que dejó de responder, el proceso padre matará al child process correspondiente y cerrará los FIFOs.

La siguiente Figura muestra las secuencias:

Secuencia para establecer una conexión con el sistema de adquisición

Una de las ventajas de tener éste diseño es que no se pierden paquetes como sucedía con el diseño anterior (en el diseño anterior, los paquetes se perdían por que al momento en que el servidor estaba procesando la información y llegaba un paquete UDP, éste no estaría disponible en la próxima lectura de socket). Con el nuevo diseño, el child process atiende solo una conexión por lo que la cantidad de datos que cada uno debe procesar es mínima. Una manera de disminuír completamente la carga de procesamiento en los child processes es hacer que éstos no se encarguen de la interpretación de los paquetes, solo se encargan de leer del socket UDP y retransmitir la información como “raw data” al buffer FIFO, el proceso padre se encarga de la interpretación de los paquetes, pero ésta vez si existe algún problema con el procesamiento de los datos en el proceso padre, la información no se pierde dado que se encontrará disponible en el buffer FIFO antes de la siguiente lectura del socket.

Éste prototipo de software estuvo funcionando correctamente con solo unos pocos tanques (para ser más específicos, solo teníamos la posibilidad de trabajar con tres tanques a la vez). Una vez que se instalaron la cantidad de 7 prototipos de AMIGA, pudimos hacer pruebas mas rigurosas y encontrar de éste modo posibles bugs en el sistema de adquisición de datos de AMIGA. Uno de los problemas encontrados para fines de Noviembre fue que al momento en que CDAS enviaba un paquete solicitando un T3 a los tanques (ya con una lista de tanques >5), La LocalStation de los detectores de superficie no interpretaba correctamente el paquete enviado por el software que corriendo en la SBC (léase SUSimulator). Debido a éste problema y dado que los detectores de superficie interrumpían su adquisición todo el tiempo, se decidió apagar la adquisición de los detectores de superficie (no así el sistema Xbee) para poder encontrar el problema.

Uno de los procedimientos que se siguió para resolver éste problema, fue la de analizar concretamente el paquete recibido por la LS (enviado por una radio de leeds) y comparar éste paquete, por el que recibía de SUSimulator, de manera tal de encontrar las diferencias de un paquete T3 en ambos sistemas. Para poder hacer éste análisis, se utilizó el código de Pm, Xb e IkServer; procesos del CDAS que se encargan de comunicarse con las BSUs del sistema diseñado por leeds, generar el central trigger (T3) y generar los logs para monitoreo del sistema de adquisición respectivamente. Se instaló un Debian 5 en una máquina y se compilaron los procesos del CDAS para poder llevar a cabo esta prueba (tengo que aclarar que compilar los procesos del CDAS no es una tarea trivial, dado que CDAS está desarrollado para poder compilar con g++3.3 o g++3.4, paquetes que ya se encuentran obsoletos en Debian 5, por lo que se tuvo que cambiar a g++4.1; esto implicó tener que modificar el código del CDAS para poder adaptarlo). Se desarrolló también un software para simulación de los tanques y se modificó el código de la LS de manera tal que al recibir un paquete T3 copie un hexadecimal del mismo en un archivo para luego poder analizarlo.

Cuando se hizo la prueba, se encontraron las diferencias entre los paquetes enviados por la radio de leeds y los paquetes enviados por el código SUSimulator. Dado que se encontraron diferencias, se decidió aprovechar las pruebas y hacerlo para todos los tipos de paquetes enviados por el CDAS con una lista mayor de 5 tanques:

IkLsReboot: Reboot de LS.

IkLsStart: Inicio de Adquisición en LS remotamente.

IkLsOS9: Paquete utilizado para enviar comando OS9000 a la LS.

T3: Paquete para solicitud de T3.

Éstas pruebas fueron favorables para poder corregir el problema. Una vez solucionado el problema, se decidió probar el código solo en Heissenberg (para evitar problemas que se puedan presentar en el nuevo código) y una vez seguros de que la adquisición funcionaba correctamente en Heissenberg, se decidió a fines de febrero, principios de marzo del corriente año, copiar el nuevo software en las TS de los demás tanques y ponerlos en marcha. Luego de la puesta en marcha, se analizó que no hubieran más interrupciones de la adquisición al momento en que el CDAS enviaba un T3 a los tanques. Al no encontrar problemas, se determinó que ese problema quedó solucionado.