Actas-JCCBD-2018

Vista previa del material en texto

Libro de Actas
JCC&BD 2018
VI Jornadas de Cloud Computing & Big Data
 
 
 
 
 
 
VI Jornadas de 
Cloud Computing & Big Data 
 
La Plata (Buenos Aires), 25 al 29 de junio de 2018 
 
 
Organizador 
Facultad de Informática - Universidad Nacional de La Plata 
 
 
 
 
 
 
 
 
 
Libro de Actas: JCC&BD 2018 - VI Jornadas de Cloud Computing & Big Data; coordinación general de 
De Giusti Armando. - 1a ed. - La Plata: Universidad Nacional de La Plata. Facultad de Informática, 2018. 
 
Libro digital, PDF 
 
Archivo Digital: descarga y online 
ISBN 978-950-34-1659-4 
 
1. Actas de Congresos. 2. Computación. 3. Minería de Datos. I. Armando, De Giusti, coord. CDD 006.312 
 
 
 
 
 
 
Comité Científico 
Coordinador: Armando De Giusti (UNLP) 
Aguilar, José (Universidad de Los Andes, Venezuela) 
Abásolo, María José (UNLP) 
Ardenghi, Jorge (UNS) 
Balladini, Javier (UNCOMA) 
Bria, Oscar (UNLP) 
Castro, Silvia (UNS) 
De Giusti, Laura (UNLP) 
Denham, Mónica (UNRN) 
Diaz, Javier (UNLP) 
Doallo, Ramón (Universidad da Coruña, España) 
Errecalde, Marcelo (UNSL) 
Frati, Fernando Emmanuel (UNdeC) 
Garcia Garino, Carlos (UNCuyo) 
Gaudiani, Adriana Angélica (UNGS) 
Gil, Costa (UNSL) 
Guerrero, Roberto (UNLS) 
Hasperué, Waldo (UNLP) 
Igual Peña, Francisco Daniel (Universidad Complutense de Madrid, España) 
Lanzarini, Laura (UNLP) 
Leguizamón, Guillermo (UNSL) 
Luque, Emilio (Universidad Autónoma de Barcelona, España) 
Marín, Mauricio (Yahoo, Chile) 
Marrone, Luis (UNLP) 
Naiouf, Marcelo (UNLP) 
Olcoz Herrero, Katzalin (Universidad Complutense de Madrid, España) 
Olivas Varela, José Angel (Universidad de Castilla La Mancha, España) 
Pardo, Xoan (Universidad da Coruña, España) 
Piccoli, María Fabiana (UNSL) 
Piñuel, Luis (Universidad Complutense de Madrid, España) 
Pousa, Adrian (UNLP) 
Printista, Marcela (UNSL) 
Rexachs, Dolores (Universidad Autónoma de Barcelona, España) 
Rodríguez, Nelson (UNSJ) 
Saez, Juan Carlos (Universidad Complutense de Madrid, España) 
Sanz, Victoria (UNLP) 
Suppi, Remo (Universidad Autónoma de Barcelona, España) 
Tirado, Francisco (Universidad Complutense de Madrid, España) 
Touriño, Juan (Universidad da Coruña, España) 
Zarza, Gonzalo (Globant) 
 
 
 
 
 
 
 
Índice 
Análisis funcional de la pila de software de E/S paralela utilizando IaaS. Diego Encinas (UNLP), 
Sandra Mendez (LRZ – Alemania), Dolores Rexachs (UAB – España), Emilio Luque (UAB – 
España), Marcelo Naiouf (UNLP), Armando De Giusti (UNLP)……………………………………... 
 
 
 
1 
H-RADIC: The Fault Tolerance Framework for Virtual Clusters on Multi-Cloud 
Environments. Ambrosio Royo (UAB – España), Jorge Villamayor (UAB – España), Marcela 
Castro-León (UAB – España), Dolores Rexachs (UAB – España), Emilio Luque (UAB – España)…... 
 
 
 
7 
Cloud Robotics: Vehículo autónomo conectado a AWS. Manuel Costanzo (UNLP), Marcos 
Boggia (UNLP), Ismael Rodríguez (UNLP), Armando De Giusti (UNLP-CONICET)……………….. 
 
 
14 
SMOTE-BD: An Exact and Scalable Oversampling Method for Imbalanced Classification in 
Big Data. María José Basgall (UNLP-CONICET), Waldo Hasperué (UNLP-CIC), Marcelo Naiouf 
(UNLP), Alberto Fernández (UGR - España), Francisco Herrera (UGR – España)…………………. 
 
 
 
23 
Cloud Médicos – Privacidad, integridad y estandarización – Estado actual. Ezequiel Velurtas 
(UNLP), Patricia Bazán (UNLP)……………………………………………………………………... 
 
 
29 
Automatic and early detection of the deterioration of patients in Intensive and Intermediate 
Care Unit: technological challenges and solutions. Javier Balladini (UNCOMA), Pablo Bruno 
(UNCOMA), Rafael Zurita (UNCOMA), Cristina Orlandi (Hospital Francisco Lopez Lima)………... 
 
 
 
36 
Cloud Computing application model for online recommendation through fuzzy logic system. 
Elham Shojaei (UAB – España), Emilio Luque (UAB – España), Dolores Rexachs (UAB – España), 
Francisco Epelde (Hospital Universitari Parc Tauli – España)………………………………………. 
 
 
 
46 
Fire propagation visualization in real time. Sigfrido Waidelich (UNRN), Karina Laneri (Centro 
Atómico Bariloche-CONICET), Mónica Denham (UNRN-CONICET)………………………………. 
 
 
53 
Job Schedulers for Machine Learning and Data Mining algorithms distributed in Hadoop. 
Félix Martin Cornejo (UNSJ), Alejandro Zunino (UNICEN), María Murazzo (UNSJ)………………. 
 
 
62 
Predicción de nubes a corto plazo en una planta solar a partir de datos históricos. Rafael 
Caballero (UCM – España), Luis F. Zarzaleja (CIEMAT – España), Álvaro Otero (UCM – España), 
Luis Piñuel (UCM – España), Stefan Wilbert (DLR – Alemania)……………………………………... 
 
 
 
69 
Treatment of Massive Metagenomic Data with Graphs. Cristobal R. Santa María (UNLAM), 
Romina A. Rebrij (UBA), Victoria Santa María (UBA), Marcelo A. Soria (UBA)…………………….. 
 
 
77 
Análisis Simbólico de Datos: una potente herramienta para Big Data. Adriana Mallea (UNSJ), 
Myriam Herrera (UNSJ), María Inés Lund (UNSJ)………………………………………………….. 
 
 
81 
Análisis de las topologías IoT en Entornos Fog Computing mediante simulación. 
Javier Sillero Ros (UNSJ), Nelson Rodríguez (UNSJ), Matías Montiveros (UNSJ), María Murazzo 
(UNSJ), Fabiana Piccoli (UNSL), Miguel Méndez Garabetti (UCH)………………………………… 
 
 
 
90 
Implementing cloud-based parallel metaheuristics: an overview. Patricia González (UDC – 
España), Xoan C. Pardo (UDC – España), Ramón Doallo (UDC – España), Julio R. Banga 
(IIM_CSIC – España)………………………………………………………………………………… 
 
 
 
101 
Cloud Computing, Big Data y las Arquitecturas de Referencia para la Industria 4.0. Nancy 
Velásquez (UNLP), Elsa Estévez (UNS), Patricia Pesado (UNLP)…………………………………… 
 
 
111 
 
 
 
 
 
 
 
 
Orquestación de servicios para el desarrollo de aplicaciones para big data. María Murazzo 
(UNSJ), Miguel Guevara (UNSJ), Martín Tello (UNSJ), Nelson Rodríguez (UNSJ), Fabiana Piccoli 
(UNSL), Mónica Giménez (UNLAR)………………………………………………………………….. 
 
 
 
 
 
118 
Processing Collections of Geo-Referenced Images for Natural Disasters. Fernando Loor (UNSL-
CONICET), Verónica Gil-Costa (UNSL-CONICET), Mauricio Marín (USACH – Chile)……………. 
 
 
125 
Secure Computer Network: Strategies and Challengers in Big Data Era. Mercedes Barrionuevo 
(UNSL), Mariela Lopresti (UNSL), Natalia Miranda (UNSL), Fabiana Piccoli (UNSL)……………. 
 
 
133 
 
Adjustement of a simulator of a complex dynamic system with emphasis on the reduction of 
computational resources. Mariano Trigila (UCA), Adriana Gaudiani (UNGS), Emilio Luque (UAB 
– España)……………………………………………………………………………………………... 
 
 
 
142 
Towards Elastic Virtual Machine Placement in Overbooked OpenStack Clouds under 
Uncertainty. Fabio López-Pires (PTI – Paraguay), Benjamín Barán (UNE – Paraguay), Carolina 
Pereira (UNE – Paraguay), Marcelo Velázquez (UNE – Paraguay), Osvaldo González (UNE – 
Paraguay)……………………………………………………………………………………………... 
 
 
 
 
148 
 
 
 
Análisis funcional de la pila de software de E/S paralela
utilizando IaaS
Diego Encinas1, Sandra Mendez2, Dolores Rexachs3, Emilio Luque3, Marcelo Naiouf1, and
Armando De Giusti1
1Informatics Research Institute LIDI, CIC’s Associated Research Center. National University of La Plata, 50 y 120, La Plata,
1900, Argentina.
{dencinas, mnaiouf, degiusti}@lidi.info.unlp.edu.ar
2High Performance Systems Division, Leibniz Supercomputing Centre (LRZ), Boltzmannstr. 1, Garching near Munich, 85748,
Germany
sandra.mendez@lrz.de
3Computer Architecture and Operating Systems Department. Universitat Autònoma de Barcelona. Edifici Q Campus UAB.
Bellaterra, 08193, Spain
{dolores.rexachs, emilio.luque}@uab.es
Abstract
Las operaciones de Entrada/Salida en los centros de
supercomputación siguen siendo un cuello de botella
para el procesamiento en paralelo. Esto provoca que
la capacidad de procesamiento de los distintos nodos
que componen estos centros se vea limitada. Por este
motivo, en el presente trabajo se propone estudiar y
evaluar el rendimiento de las principales operaciones
paralelas de E/S. Las ejecuciones se realizan utilizando
dos tipos de clústeres(fı́sico y virtual), empleando
benchmarks especı́ficos de E/S y sistemas de archivos.
Además, se propone diseñar, desarrollar e incorporar
pequeñas secciones de código a algunas de las fun-
ciones más importantes invocadas durante la ejecución
de los benchmarks, de manera de obtener medidas de
tiempo para cuantificar la ejecución en los distintos
puntos del sistema de software de E/S.
Keywords: Cloud Computing, Pila de Software de
E/S, PVFS2, Instrumentación de Código
1 Introducción
Los actuales sistemas de HPC proporcionan cada vez
mayor capacidad de cómputo debido al rápido avance
de las tecnologı́as de procesadores. Ese avance no es
proporcional en el área de almacenamiento. Para re-
ducir la diferencia entre el rendimiento computacional
y el de almacenamiento, los actuales sistemas de E/S
utilizan hardware de alto rendimiento por medio de
redes de almacenamiento de alta velocidad y sistemas
de discos en RAID para proporcionar E/S paralela.
Para gestionar el hardware de E/S se usa la pila de
software que está compuesta por capas que gestionan
los diferentes módulos de la arquitectura.
La Figura 1 muestra dos visiones del sistema de E/S,
la infraestructura hardware y de la pila de software,
el rendimiento del sistema depende de la carga de
trabajo (patrones de E/S de las aplicaciones) y de la
configuración del sistema. Existe una gran variabilidad
en el comportamiento global del sistema dependiendo
de la configuración y de los patrones de acceso a la E/S
generados por las aplicaciones, observar el impacto de
la configuración del sistema requiere el uso de sistemas
rápidamente reconfigurables [1].
Una operación de E/S debe atravesar la estructura
de la pila de software para escribir/leer a/desde los
dispositivos. El encargado de gestionar el acceso a
los datos es el sistema de ficheros, en HPC para con-
seguir el paralelismo a nivel de E/S, se usan sistemas
de ficheros paralelos. Cuando una aplicación se está
ejecutando y realiza una operación de E/S, las librerı́as
de E/S reciben la operación e interaccionan con el sis-
tema de ficheros. Este tipo de sistemas multicapas trae
una complejidad adicional que está relacionado con el
análisis de rendimiento y de funcionalidad de toda la
pila de software.
Una de las técnicas para evaluar el rendimiento
del Sistema de E/S a nivel de libreria es el uso
de benchmarks especı́ficos como IOR, BT-IO, Mad-
bench2, entre otros que generan diferentes patrones
de acceso[2]. Para poder explicar el rendimiento ob-
servado se pueden utilizar herramientas de análisis
de rendimiento para HPC, pero la mayoria de las her-
ramientas que permiten analizar el rendimiento de la
E/S lo hacen a nivel MPI-IO y de POSIX-IO. Por lo
cual no es posible obtener información sobre cómo
interactúan todas las capas de la pila de SW de E/S.
Entender la interaccion entre las capas de la pila de
software es importante no solo para explicar el compor-
tamiento observado, sino tambien para detectar cuellos
de botellas y proponer tecnicas de optimizacion. Ade-
mas, este tipo de informacion es fundamental para
modelar y simular configuraciones del sistema de E/S
para poder evaluar el impacto de las diferentes capas
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
1
Figure 1: Sistema de HPC: infraestructura y pila de software de E/S
sin alterar sistemas en produccion.
En este artı́culo se presenta un análisis funcional
de pila de software de E/S, por medio de la instru-
mentación de código en las capas de MPI-IO y del
sistema de ficheros paralelo utilizando el servicio IaaS
de Amazon. Para identificar las diferentes funciones
que interactúan se ha optado por una técnica de instru-
mentación de código fuente en la capa MPI-IO y del
sistema de fichero paralelo. Se ha seleccionado una
plataforma Cloud, para desplegar un clúster de HPC
y configurar la pila de software con todas las modifi-
caciones necesarias. Se ha optado por una plataforma
IaaS debido a que los sistemas de I/O en clusters fisicos
requieren permisos de administrador y cualquier cam-
bio afecta a todos los usuarios del cluster. Además,
se pueden evaluar varias configuraciones de E/S de
manera más rápida y practica sin afectar el normal
funcionamiento de un sistema de HPC en producción.
El trabajo está organizado de la siguiente manera, en
la Sección 2 se presentan los conceptos relacionados
al software utilizado. En la Sección 3 se describen las
capas de la pila de software elegidas para explicar el
trabajo. La Sección 4 muestra los experimentos real-
izados y los resultados encontrados. Finalmente, en
la Sección 5 se presentan las conclusiones y trabajos
futuros.
2 Conceptos relacionados
En esta sección se introducen algunos conceptos
básicos relacionados a la pila de software de E/S.
2.1 Middleware
La Interfaz de Pasaje de Mensajes (MPI) es un sistema
estandarizado y portable diseñado por un grupo de
investigadores tanto del sector académico como del
industrial para ser utilizado en una amplia variedad
de arquitecturas de cómputo paralelo. Mientras que
MPI-IO fue desarrollado en el Laboratorio Watson de
IBM para proveer soporte de E/S paralela para MPI.
Los llamados de funciones de MPI-IO son muy sim-
ilares a los de MPI, escribir archivos MPI es seme-
jante a enviar mensajes MPI y leer archivos MPI es
parecido a recibir mensajes MPI. En este trabajo se
utilizó MPICH que es una implementación de alto
rendimiento y ampliamente portátil del estándar MPI.
MPICH [3] está siendo actualmente distribuido como
software abierto, con una licencia libre y gratuita. Ha
sido probado en múltiples plataformas, incluyendo
Linux (en IA32 y x86-64), Mac OS/X (PowerPC e
Intel), Solaris (32 y 64 bits) y Windows.
2.2 Benchmarks
Los benchmarks están diseñados para imitar un tipo
particular de carga de trabajo en un componente o sis-
tema. Los benchmarks sintéticos lo hacen creando
programas especiales para imponer la carga de trabajo
en el componente, mientras que los benchmarks de
aplicación ejecutan programas del mundo real sobre el
sistema. Los benchmarks de aplicación suelen ofrecer
una mejor medición del rendimiento real de un sis-
tema determinado, pero los sintéticos son útiles para
probar componentes individuales, como un disco duro
o un dispositivo de red. Idealmente, los benchmarks
sólo deberı́an sustituir a las aplicaciones reales si la
aplicación no está disponible o es demasiado difı́cil o
costosa de ejecutar en un procesador o sistema deter-
minado.
Se ha optado por dos de los benchmarks de E/S
más populares para evaluar los rendimientos de las
operaciones paralelas de E/S en las que se centrará
este trabajo: uno sintético, conocido como IOR, y otro
de aplicación, llamado BTIO.
2.3 Sistemas de Archivos Paralelos
Al constituir un clúster de cómputo de alto
rendimiento, se tienen tres categorı́as principales de
sistemas de archivos: NFS, los sistemas de red de área
de almacenamiento (SAN) y los sistemas de archivos
paralelos. El primero suele ser considerado fácil de
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
2
utilizar, pero el servidor NFS puede ser un lugar de
fallo crı́tico y NFS no es correctamente escalable a
través de grandes clústeres.
En cambio, entre las principales ventajas que puede
proveer un sistema de archivos paralelo se puede men-
cionar un espacio de nombre global, escalabilidad y
la capacidad de distribuir grandes archivos a través de
múltiples nodos en un entorno de clúster, haciendo que
un sistema de archivos de esta clase sea muy apropiado
para subsistemas de E/S en HPC. Generalmente, un
sistema de archivos paralelo implica un servidor de
metadatos que contiene información sobre los datos
en los nodos de E/S. Algunos sistemas utilizan un
servidor particular para los metadatos, mientras otros
distribuyen la funcionalidad del servidor de metadatos
a través de los nodos de E/S. Algunos ejemplos de sis-
temas de archivos paralelos para clústeres de cómputo
de alto rendimiento sonPVFS y Lustre.
En este trabajo se ha optado por PVFS2 que es so-
portada por la Universidad Clemson y el Laboratorio
Argonne. Aunque, puede mencionarse que Clemson
desarrolló en 2008 una nueva rama llamada OrangeFS
que incluye extensiones para soportar grandes direc-
torios de pequeños archivos, mejoras de seguridad y
capacidades de redundancia. Hacia el año 2011 Or-
angeFS se convirtió en la lı́nea de desarrollo principal,
aunque la mayorı́a de las actualizaciones son aplica-
bles a ambas ramas [4].
3 Análisis funcional de la pila de soft-
ware
Desde la petición por parte de la aplicación de usuario
hasta que la misma llega a realizarse fı́sicamente so-
bre el disco, es importante determinar los programas
y módulos que utilizan cada una de las operaciones,
esto permitirá decidir dónde incluir código adicional
para determinar el tiempo de ejecución de las distintas
funciones ante las diferentes operaciones de E/S. En
la Figura 2 se muestra un esquema de la estructura
analizada para realizar lo antes dicho.
En la Figura 2 se puede ver la estructura interna de
MPICH con respecto a su implementación de MPI-
IO y su vı́nculo con el sistema de archivos del clus-
ter. ROMIO es una implementación portable y de
alto rendimiento de MPI-IO, optimizada para patrones
de acceso no contiguos, los cuales son comunes en
las aplicaciones paralelas. Un componente clave de
ROMIO, que permite una implementación tan portable
de MPI-IO, es una capa interna de dispositivo ab-
stracto para E/S paralela llamada ADIO (Abstract-
Device Interface for I/O). Es el componente ADIO el
que contiene los módulos que incluyen las funciones
que envı́an las peticiones de E/S de las aplicaciones de
usuario hacia el sistema de archivos paralelo. Es decir,
la capa ADIO Common contienen las funciones co-
munes a todos los sistemas de archivos. Mientras que
AD PVFS contienen las funciones para implementar la
interfaz MPI-IO en el sistema de archivos PVFS2.
3.1 Instrumentación
La instrumentación insertada en el código de los com-
ponentes de MPICH y del sistema de ficheros PVFS2
[5] ha sido utilizada para identificar las funciones invo-
cadas durante la ejecución de una aplicación paralela.
En particular las interacciones de alguna funciones
que son ejecutadas durante el procesamiento de deter-
minadas solicitudes como son las de apertura / cierre,
escritura y lectura de archivos.
En la Figura 3 se muestran, por ejemplo, las fun-
ciones en la capa de ROMIO y de System Interface
de PVFS2, detectadas durante la ejecucion de IOR y
BT-IO clase FULL.
4 Evaluación Experimental
Plataformas como Amazon ofrecen distintos tipos
de instancias de acuerdo al tipo de servicio que se
adquiera. En este caso se desplegó un clúster de HPC
haciendo uso del servicio gratuito de AWS.
4.1 Entorno Experimental
Existen varias herramientas para crear clústeres vir-
tuales de manera automática en la plataforma EC2
de Amazon, algunas son StarCluster o CfnCluster.
Pero en este caso era necesario desplegar un clúster
de forma manual y con una pila de software instru-
mentada ya que el objetivo del trabajo es un análisis
detallado de las diferentes capas que comprenden el
sistema.
En la Figura 4 se pueden ver los entornos fı́sicos y
virtuales con las respectivas configuraciones.
Se creó un clúster con 5 nodos: un master y 4 nodos
de cómputo. La incorporación de PVFS2 obligatoria-
mente debe ser llevada a cabo antes de instalar MPICH
o los benchmarks para que estos programas puedan re-
conocerlo. Tanto en el clúster fı́sico como en el virtual
se utilizó SSH para ejecutar comandos e implementar
las configuraciones. Se optó por asignar cuatro nodos
de E/S o servidores de datos y un servidor de metadatos
o storage. La descripción de las caracterı́sticas de los
clústeres se puede ver en la Tabla 1.
4.2 Aplicación
Los experimentos fueron diseñados para analizar el
comportamiento del sistema frente a la escritura y lec-
tura de tres tamaños de archivos: 1GB, 2GB y 4GB.
Las razones de restringir a estos tamaños se deben al
objetivo de no prolongar demasiado los tiempos de
ejecución y al mismo tiempo no exceder el limitado
espacio de almacenamiento ofrecido por el entorno del
clúster virtual para almacenar datos. Para conseguirlo
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
3
Figure 2: Capas analizadas de la pila de software de E/S
Figure 3: Funciones identificadas en la capa de MPI-IO y PVFS2 del lado del cliente
Figure 4: Clusters Fı́sicos (figura en la izquierda) y Virtuales (figura en la derecha)
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
4
Table 1: Caracterı́sticas de los clústeres utilizados
Componente Clúster Fı́sico Clúster Virtual
Procesador Xeon, i7, AMD Xeon
RAM (por nodo) 8 GiB 1 GiB
Red de almacenamiento 1 Gbps Ethernet Baja a Moderada
Número de Data Server 4 4
Número de MetaData Server 1 1
Librerı́a MPI MPICH versión 3.2.1 MPICH versión 3.2.1
Sistema de Archivos Global PVFS 2 versión 2.8.2 PVFS 2 versión 2.8.2
Sistema Operativo Red Hat Enterprise Linux Red Hat Enterprise Linux
simplemente hubo que utilizar los parámetros adecua-
dos en el caso de IOR. La lı́nea de comandos utilizada
fue:
mpirun -np NP ./IOR -a $API \
-t $TRANSFER_SIZE -b $BLOCK \
-F -o OUTPUT_FILE
En donde:
• -np representa el número de procesos MPI
• -a establece la interfaz o API de E/S
• -t define el tamaño en bytes del buffer de trans-
ferencia
• -F define que cada proceso trabaja sobre su pro-
pio archivo local
• -b define el número de bytes contiguos a escribir
por proceso
• -o se establece el nombre completo del archivo
de prueba
En el caso de BTIO se utilizó la clase W pero hubo
que modificar el código fuente. Puntualmente se reem-
plazó la variable niter por el número de iteraciones
necesarias para lograr el tamaño de archivo deseado.
Ya que la clase seleccionada posee por defecto 200
iteraciones para escribir un archivo de 188 MB. A par-
tir de esta relación se puede determinar fácilmente la
cantidad de iteraciones requeridas para el tamaño de
archivo buscado. En la Tabla 2 se pueden ver las con-
figuraciones para la utilización de los dos benchmarks.
4.3 Resultados
Para mostrar los resultados se han tomado como ejem-
plo la capa AD PVFS2 que contiene las funciones para
implementar la interfaz MPI-IO en PVFS2 y en este
caso las funciones ADIOI PVFS2 WriteContig() y
ADIOI PVFS2 ReadContig(). También la capa Sys-
tem Interface que es una interfaz del lado cliente
que permite la manipulación de los objetos del
sistema de archivos y en particular las funciones
PVFS sys write() y PVFS sys read(). En la
Figure 5: Métricas de IOR
Figura 5 se pueden ver los tiempos obtenidos con el
benchmark IOR.
En la Figura 6 se pueden ver los tiempos obtenidos
con el benchmark BTIO. Las diferencias con el clúster
fı́sico se deben principalmente a las distintas presta-
ciones de hardware conseguidas en los dos entornos
de ejecución pero siguen la misma tendencia.
A pesar que los recursos hardware del clúster fı́sico
son ligeramente mejores a los del clúster virtual, en
todos los casos el virtual presenta un rendimiento con-
siderablemente superior. Se puede tomar esta situación
como confirmación de que la velocidad de red es mu-
cho más inferior en el clúster fı́sico que en el virtual.
Sumado al poco peso que poseen los accesos efectivos
a disco sobre el tiempo de ejecución total del bench-
mark, provoca que el incremento en la complejidad de
la red supera el beneficio que implica poder realizar
múltiples lecturas y escrituras simultáneas en disco en
lugar de hacerlas sólo de a una por vez.
Finalmente, se puede observar que con el clúster
virtual se dispone de un sistema dedicado con el cual
es posible realizar un análisis detallado de la pila de
software de E/S. Esto permite definir la importancia
temporal de los módulos o funciones de la pila rela-
cionados al flujo de datos en los servidores de E/S
VI Jornadas de Cloud Computing & Big Data (JCC&BD2018)
5
Table 2: Configuraciones seleccionadas para IOR y BTIO
Parámetro BTIO IOR
API para E/S (Interfaz) MPI-IO MPI-IO
Tamaño del buffer de transferencia
0,94 MB para 1GB 128 MiB para 1GiB
0,94 MB para 2GB 128 MiB para 2GiB
0,94 MB para 4GB 128 MiB para 4GiB
Tamaño del bloque de datos a escribir por proceso
256 MB para 1 GB 256 MiB para 1GiB
512 MB para 2GB 512 MiB para 2GiB
1 GB para 4GB 1 GiB para 4GiB
Figure 6: Métricas de BT-IO
como en los servidores de metadatos. La relevancia
de conseguir medidas de tiempo en los componentes
de la pila es fundamental ya que como se ha expli-
cado anteriormente, distintos patrones de E/S o cargas
de trabajo provocarán que el sistema se comporte de
diferente manera.
5 Conclusión
El trabajo realizado en Cloud ha permitido identificar
las funciones principales en la capa de MPI y del sis-
tema de ficheros paralelo PVFS2 con mayor impacto
en el comportamiento del sistema de E/S. Las métricas
obtenidas en el clúster virtual no son similares a las en-
contradas en el clúster fı́sico. Las diferencias se deben
principalmente a las distintas prestaciones de hardware
conseguidas en los dos entornos de ejecución. Sin
embargo, los experimentos demuestran que se puede
utilizar el entorno cloud para modificar y medir en el
sistema ya que las medidas obtenidas representan el
comportamiento de la pila.
Para poder usar esa información y esta técnica en
sistemas en producción a nivel de usuario, se está traba-
jando en la implementación de un trazador (wrapper)
para capturar las funciones de interés usando instru-
mentación dinámica, de manera que no sea necesario
recompilar ninguna capa de la pila de software de E/S.
Agradecimientos
This research has been supported by the
MICINN/MINECO Spain under contracts TIN2017-
84875-P.
References
[1] P. Gomez-Sanchez, D. Encinas, J. Panadero,
A. Bezerra, S. Mendez, M. Naiouf, A. D. Giusti,
D. Rexachs del Rosario, and E. Luque, “Using
AWS EC2 as Test-Bed infrastructure in the I/O sys-
tem configuration for HPC applications,” Journal
of Computer Science & Technology, vol. Volumen
16, 11/2016 2016.
[2] R. Thakur, W. Gropp, and E. Lusk, “Data Sieving
and Collective I/O in ROMIO,” in Proceedings of
the The 7th Symposium on the Frontiers of Mas-
sively Parallel Computation, FRONTIERS ’99,
(Washington, DC, USA), pp. 182–, IEEE Com-
puter Society, 1999.
[3] MPICH, “Mpich overview,” 2018.
[4] OrangeFS, “The orangefs project,” 2018.
[5] T. PVFS2, “PVFS 2 File System Semantics Docu-
ment,” tech. rep., PVFS Development Team, 2015.
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
6
H-RADIC: The Fault Tolerance Framework for 
Virtual Clusters on Multi-Cloud Environments 
Ambrosio Royo, Jorge Villamayor, Marcela Castro-León, Dolores Rexachs and Emilio Luque 
CAOS – Computer Architecture and Operating Systems, Universitat Autònoma de Barcelona, Bellaterra 
(Cerdanyola del Vallès), Barcelona 08193, Spain 
pabloambrosio.royo@e-campus.uab.cat, 
{jorgeluis.villamayor,marcela.castro,dolores.rexachs,emilio.luque}@uab.cat 
Abstract 
Even though the cloud platform promises to be 
reliable, several availability incidents prove that they 
are not. How can we be sure that a parallel application 
finishes the execution even if a site is affected by a 
failure? This paper presents H-RADIC, an approach 
based on RADIC architecture, that executes a parallel 
application in at least 3 different virtual clusters or 
sites. The execution state of each site is saved 
periodically in another site and it is recovered in case 
of failure. The paper details the configuration of the 
architecture and the experiments results using 3 
virtual clusters running NAS parallel applications 
protected with DMTCP, a very well-known 
distributed multi-threaded checkpoint tool. Our 
experiments show that the execution time was 
increased between a 5% to 36% without failures and 
27% to 66% in case of failures. 
Keywords: Cloud, Fault-Tolerance, High- 
Performance Computing, RADIC. 
1. Introduction
We know that there aren’t any computers small or big 
safe from failures, we have seen big cloud providers 
fail, Windows Azure had availability problems for the 
Olympic Games in 2012 [1], Amazon Web Services 
had been affected from the extreme weather [2] and 
by human errors [3], also Google Cloud Platform was 
attacked by a low-level software [4] or even Oracle 
Cloud’s wide network error issue that was fixed by 
restarting the network [5]. 
Since communication with a cloud can be lost due 
to a wide range of possible errors, also causes loss of 
computational resources, power consumption and 
money; different authors have worked to prevent 
failures when there are parallel applications with 
message passing running on cloud environments; in 
the work of Villamayor et. al [6] where they propose 
Resilience as a Service (RaaS), a Fault Tolerant (FT) 
framework for High Performance Computing (HPC) 
applications running in a cloud, and Gomez et. al [7] 
propose a multi-cloud FT framework that was capable 
to continue working if any of the cloud sites fail and 
delivered the results on the due date. We have studied 
the previous work and took advantage of the elasticity 
(easy provisioning of “hardware”) of cloud 
computing. 
We propose to take the Redundant Array of 
Distributed Independent Controllers (RADIC) 
architecture and hierarchically scale it up to be 
applied to a fully automated, elastic FT framework for 
virtual clusters running on different cloud 
environments. Capable to protect applications 
running in private or public clouds from fatal fails 
like: loss of nodes during execution and loss of 
communication between clouds. 
The next section presents some related state of the 
art work and the description of the RADIC 
architecture. In section 3, we will describe an overall 
detail of the H-RADIC architecture, fallowed up by 
section 4, a summary of the experiments done from 
the implementation of the H-RADIC architecture, 
after that section 5 with the conclusions, finishing 
with future work in section 6. 
2. Background
In Japan, Bautista-Gomez et. al [8] proposed a low-
overhead high-frequency multi-level checkpoint 
technique, that implement a three level checkpoint 
scheme that compensates for the overhead of the FT 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
7
by dedicating a thread of execution per node. 
 Another group of IEEE members [9] in the USA, 
set up an online two-level checkpoint model for HPC, 
one level deals with logical problems such as 
transient memory errors and the other one deals with 
hardware crashes like node fails, contributing with an 
online solution that determines the optimal 
checkpoint patterns and doesn’t required the 
knowledge of the job length in advance. 
Egwutuoaha et. al [10], from Australia, approached 
the problem by not relaying on spare node prior of a 
fail, aiming to reduce the time and cost of the 
execution on the cloud. 
And of course, the work of Gomez et. al [7] and 
Villamayor et. al [6], that we mention in the 
introduction. 
2.1. RADIC Architecture 
The RADIC architecture is transparent and automatic, 
therefore the application doesn’t have to be modified 
to apply it and there is no need of human intervention, 
also it is elastic since it has the ability to add new 
nodes whenever one crashes [11]. It consists on 
implementing FT for message passing applications, 
by intercepting and masking error which detect and 
manage errors instead of ending the application. 
Taking advantage of the hardware redundancy, 
RADIC needs at least three physical nodes to work so 
the application doesn’t have to stop and start again. It 
works with two distributed software RADIC 
components [12]: Observers and Protectors; there is a 
protector running in each node and one observer for 
every process running in the application, as shown in 
Fig. 1. Additionally, a table named RadicTable is 
used to store the relation between nodes, observers 
andprotectors which is updated by the RADIC 
Components. 
Observer: When the application is launched, a 
software instance is created and attached to every 
processor used in the program, its job is to perform 
checkpoints and intercept the messages of its 
processor and send it to the Protector to store it. 
Protector: It’s in charge to request the observers to 
perform checkpoints and store the checkpoint files in 
its own Stable Storage (SS), and also to verify that the 
node that it’s protecting is working and, in the case, 
that it fails launch the latest checkpoint. 
Fig. 1 - RADIC Architecture 
RADIC defines four functions Protection, Detection, 
Recovery and Error Masking. 
Protection: Observer O3 is in charge of monitor 
Process P3, then O3 gets a Protector TA located in a 
different node NA. At some point TA will ask O3 to get 
the state of it process and send it to TA to be stored in 
TA´s Stable Storage (SS), this is called a checkpoint; 
checkpoints will be done periodically to keep on 
saving the state of the processes during a fault free 
execution. The moment that every T has its 
neighbor’s checkpoint, the RADIC protection will be 
in place. 
Detection: Node NB faults when the process P3 
cannot communicate with another process P2 in the 
same node, that’s when O3 sends the error message to 
TA. Also, a node faults when there is no 
communication between nodes, that is, each protector 
(TA) is in charge of detecting a possible failure in the 
neighbor Node (NB). Each protector keeps a 
heartbeat/watchdog protocol with its neighbors 
Protectors, in this way a fault detection mechanism is 
implemented; in one hand, the Protector TB is 
periodically sending heartbeats to TC, and in the other 
hand, TB is the watchdog of TA, so if TB loses 
communication with both neighbor protectors, TB 
will destroy itself because it has been left alone, if TA 
and TC can’t see TB, then TA will launch the recovery 
and error masking functions. Based on this function, 
RADIC needs at least 3 nodes to work properly. 
Recovery: Protector TA restarts/rolls-back the 
processes running in NB, using the data saved in the 
SS from the last checkpoint, if the system has a spare 
node, the processes will be restarted in it, otherwise 
the processes are restarted in the node (NA) that has 
the checkpoint. 
Error Masking: After the recovery function, when 
the processes have been restarted, the Observers that 
got the error message hide the communication error 
caused from the node failure. The Protector TA sends 
a message to the affected Observers (O0-1 and O4-5) 
with the new address where the processes have been 
recovered, also updates the RadicTable so 
communications are done as usual. 
RADIC has been originally designed to protect a 
parallel application with message passing, recently it 
has been leveraged to work in cloud environments. In 
our work we scale up the architecture to be used for 
parallel application protection, running in several 
virtual clusters on multiple cloud environments. 
3. H-RADIC Architecture
We propose a new protection level of RADIC, the 
Hierarchical RADIC (H-RADIC) architecture, an 
automated and elastic FT framework that protect a 
parallel application running in virtual clusters on 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
8
cloud; requires at least three virtual clusters, each one 
of them protected with the RADIC architecture and 
located in different geographical sites so they don’t 
share any of the physical resources, this will allow to 
identify nodes faults within and between the clusters. 
The architecture works for parallel applications 
with a Message Passing Interface (MPI), that is, 
besides the regular RADIC architecture designed to 
protect from node fails, H-RADIC will protect 
applications from crashing in the event of multiple 
fails; when the virtual nodes fail, the physical nodes 
that the virtual are mounted on fail and/or whenever 
there is loss of communication. H-RADIC will 
perform a diagnostic and then management of the 
error. 
Additionally to all the RADIC components, H-
RADIC has an extra software component, the 
proTector of the Cluster (TC); on every cluster, a 
main node will be defined (controller Node - cN) to 
create the TC´s, which will be in charge of the 
communications between clusters, as it’s shown Fig. 
2. 
3.1. H-RADIC functions 
The H-RADIC architecture implements the RADIC 
functions in each cluster, that is, whenever there is a 
fault, the architecture tries to recover from it by 
applying the RADIC functions. H-RADIC functions 
will process the failures when the RADIC functions 
can’t process them. 
To guaranty the completion of the execution, H-
RADIC transported the RADIC functions to be apply 
into programs running in multi-clusters environments 
and depict its functionality in the following functions: 
Protection: Only while the execution is running 
fault free, checkpoints will be periodically done. 
Once that the Protectors (T) have the checkpoint of 
each of the process, the Cluster Protector (TCY) will 
be in charge of collecting the updates in the Stable 
Storage (SS) of every T in the Cluster (CY). Then, 
TCY must send it to the assigned Cluster Protector 
TCX located in a different cloud to store the Cluster 
Checkpoint (multilevel checkpoint) at the Cluster SS. 
When every TC has a checkpoint of its neighbor C, 
the H-RADIC protection will be activated. 
Detection: This function works the same way as the 
RADIC detection function; TCX is in charge of 
identifying a possible failure in the neighbor Cluster 
CY, using a heartbeat/watchdog protocol. If CY does 
not answer, TCX asks TCZ to verify if there is an error 
with CY, if TCZ confirms that there is no 
communication with CY, Recovery and Error 
Masking functions are triggered. 
Recovery: Cloud Protector TCK restarts/rolls-back 
the process running in CL, using the data saved in the 
cluster SS from the last checkpoint, then TCK checks 
if there is a spare cluster to lunch the checkpoint in it, 
otherwise creates new nodes in CK to restart all the 
processes previously running in the failed CL, then 
updates the RADIC Tables. 
Error Masking: After the recovery function, when 
the processes have been restarted, the Cluster 
Protector hides the communication errors caused by 
the cloud failure, the Cluster Protector TCK sends a 
message to the affected Protectors with the new 
address where the processes have been recovered, 
updating the H-RADIC Table and broadcasting this 
update to every TC in the architecture, then 
communications will be done as usual. 
3.1.1. H-RADIC Recovery function’ options 
After a fault is detected, the recovery function has 
two options to restart a checkpoint; the first one 
checks if there are spare clusters available in another 
cloud, viewed in Fig. 3, the second one checks if there 
are spare nodes in the same cloud, as shown in Fig. 4, 
then the checkpoint files are sent to the nodes that are 
in the spare cluster. 
Fig. 2 - H-RADIC Architecture 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
9
Fig. 3 - H-RADIC Recovery function - spare nodes/cluster 
in another cloud. 
Fig. 4 - H-RADIC Recovery function - spare nodes/cluster 
in the same cloud. 
The main difference between the two restart options 
is the way to store the checkpoints. In the case that 
there is a spare cluster available in other cloud (Fig. 
3), H-RADIC will be working as usual, but if there 
are no spare nodes available in a third cloud, the 
checkpoint will be restarted in the spare nodes of the 
cloud that has the checkpoint. After the restart, the 
two clusters (X and Y’ in Fig. 4) will send their 
checkpoints to Cluster Z and vice versa. 
When the execution is working like the previous 
situation and if a new failure rises in one of the clouds, 
the three clusters will be together in one cloud, as 
shown in Fig. 5, and henceforth, all the checkpoints 
will be stored in one cloud storage.Although this situation will leave the execution 
exposed to the same vulnerabilities, that lead us to 
develop this type architecture. Such vulnerabilities 
like failures in the cloud controller, the storage and 
the physical computer that the virtual nodes are 
mounted on. This vulnerability will now allow us to 
be able to guaranty availability. 
Fig. 5 - H-RADIC Recovery function - spare nodes/cluster 
in the same cloud and not more clouds left. 
4. Experiments
To test the architecture, we mounted 3 clusters 
running on CentOS. Each one of them has a different 
NAS Parallel Benchmark [13] program compiled 
with an implementation of MPI named: MPICH [14]. 
H-RADIC will performing the checkpoints for this 
experiments in a coordinated approach, using the 
open source software package: Distributed Multi-
Threaded CheckPointing (DMTCP) [15]. Each 
cluster has 3 nodes and every node have 8 processors, 
24 processors per cluster. 
The DMTCP allows to work with the checkpoints 
at an application layer of the OSI model, making it 
perfect for virtualized environments. Also, whenever 
a checkpoint is done, it automatically compresses it 
using gzip. 
4.1. Pseudocode of H-RADIC 
Before running the programs, they have to be 
compiled with the MPI implementation and also the 
inventory of nodes have to be depicted in the H-
RADIC Table (Table 1); it’s been established that 
each cluster will have a Cluster Protector, this will be 
the previous row in the table, and it´s expressed as 
(cluster-1), if the program is in cluster Y, the cluster 
protector will be cluster X. If the cluster it’s in the 
first row (cluster X), then cluster protector will be the 
las row in the table (cluster Z), to complete a full loop. 
Table 1 - H-RADIC TABLE 
Cluster Nodes Controller 
Node 
1 clusterX A, B, C A 
2 clusterY D, E, F E 
3 clusterZ G, H, I G 
All the logic described in the H-RADIC functions can 
be summarized in Algorithm 1. 
Algorithm 1 - H-RADIC pseudocode 
1: // FUNCTIONS 
2: function protection (program, cluster, 
ckPTime){ 
3: Send the program to the controllerNode in 
cluster 
4: launch dmtcpCoordinator with the program 
and ckPTime 
5: call detection(cluster, ckPTime) 
6: while 
7: perform checkPoint every ckPTime 
seconds 
8: send checkPoint to (cluster-1) 
9: if program ends 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
10
10: broadcast succesfull end to all HRADIC 
Tables 
11: break while 
12: } 
13: 
14: function detection (cluster, ckPTime){ 
15: // Goes to the HRADIC Table and takes the 
next cluster in the table to protect 
16: establish watchdog protocol between cluster 
and (cluster+1) 
17: while 
18: get heartbeat from (cluster+1) 
19: send heartbeat to (cluster-1) 
20: if heartbeat/watchdogProtocol fails 
21: ask (cluster+2) to establish connection 
with (cluster+1) 
22: if the connection is established 
23: nothing happens 
24: else if (cluster+2) can't see (cluster+1) 
25: recovery(cluster+1, ckPTime) 
26: } 
27: 
28: function recovery (cluster+1, ckPTime){ 
29: search for spareCluster in other clouds or in 
the local cloud 
30: inizialize Nodes in spareCluster = Nodes in 
(cluster+1) 
31: send checkPoint files to nodes in 
spareCluster 
32: call errorMasking(spareCluster, cluster+1) 
33: // Call the protection fuction again, but this 
time run the checkpoint instead of the original 
program 
34: call 
protection(checkPoint,spareCluster,ckPTime) 
35: } 
36: 
37: function errorMasking (spareCluster, 
cluster+1){ 
38: remove (cluster+1) info. in the HRADIC 
Table 
39: add spareCluster info. in the HRADIC Table 
40: broadcast the update to all HRADIC Tables in 
all the clusters 
41: } 
42: 
43: // MAIN 
44: // Launch all the protection functions in parallel 
45: execute protection(bt.C.16, clusterX, 60) 
46: execute protection(lu.C.16, clusterY, 80) 
47: execute protection(cg.C.16, clusterZ, 70) 
4.2. Results 
Calculating the optimal checkpoint interval is a 
controversial subject; for these experiments, all the 
programs were executed several times, this was done 
to identify the average time that each node needed to 
perform a checkpoint and move it to the different 
nodes and also to the cluster protector. 
The experiment is measuring the time that it takes 
the application to finish its execution, in the following 
cases: 1) the application without applying H-RADIC 
but performing checkpoints, 2) the application with 
H-RADIC and without errors or failures and, 3) the 
application with H-RADIC and an induced error. 
Then by taking the increase percentage of time in 2) 
and 3), we got Fig. 6. 
Fig. 6 - H-RADIC percentage of time overhead. 
4.2.1. Overhead Breakdown 
For the calculation of the overhead, we measured 
different time variables (as shown in Table 2): the 
first percentage shown in Fig. 6 is the application 
running with checkpoints as Eq (1), this time is 
considered the point of departure from where we are 
calculating the overhead. 
𝑇𝑇𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 = 𝑝𝑝 + (𝑐𝑐𝑐𝑐𝑝𝑝𝑐𝑐 ⋅ 𝑛𝑛) (Eq. 1) 
In order to establish the RADIC and H-RADIC 
protection, all the checkpoints needed to be copied to 
the protector nodes and the cluster protector node 
respectively. This process is done at the background 
Eq (2) while the application keeps on executing. This 
process is represented in Fig. 2, by the checkpoint’s 
and cluster checkpoint’s lines. Since moving the files 
take some computational resources, it affects the 
program execution time, although its not directly in 
the critical path. 
𝑏𝑏𝑐𝑐𝑏𝑏𝑏𝑏𝑏𝑏 = 𝑐𝑐ℎ𝑐𝑐𝑝𝑝𝑘𝑘𝑘𝑘𝑘𝑘𝑘𝑘 ⋅ 𝑝𝑝𝑏𝑏𝑝𝑝𝑐𝑐𝑘𝑘𝑐𝑐𝑐𝑐 (Eq. 2) 
The Running Time percentage with H-RADIC without 
failure in Fig. 6 is the time that the application took 
to execute considering the RADIC and H-RADIC 
protection in Eq (3). 
𝑇𝑇𝐻𝐻−𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 = 𝑇𝑇𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 + 𝑏𝑏𝑐𝑐𝑏𝑏𝑏𝑏𝑏𝑏 (Eq. 3) 
Finally, the third experiment, the Running Time 
percentage with H-RADIC with failure in Fig. 6 is the 
time that took the framework to restart the execution 
in a spare cluster Eq (4), considering the time to move 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
11
the checkpoint files and the time to restart the 
execution. 
𝑇𝑇𝐻𝐻−𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 & 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 = 𝑇𝑇𝐻𝐻−𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 + 𝑚𝑚𝑝𝑝𝑚𝑚𝑘𝑘 + 𝑏𝑏𝑘𝑘𝑒𝑒𝑐𝑐𝑒𝑒𝑏𝑏𝑐𝑐 
(Eq. 4) 
Table 2 - Time's variables description. 
Variable Description 
Tckpt Execution time with checkpoints 
p Program execution time 
ckpt Time to create a checkpoint 
n Number of checkpoints per execution 
TH-RADIC 
Execution time with H-RADIC
without failures 
ckptSize Checkpoint size in MB 
protect Time to move the ckpt to establish H-RADIC protection. 
bkgrd Unpredictable time impact on p 
TH-RADIC 
&Failure
Execution time with H-RADIC with 
failure 
move Time to move the checkpoint files to 
the spare cluster 
restart Time to restart the application 
In general, we can appreciate that the overhead 
caused by implementing H-RADIC and having 0 
failures, does not really increase the program 
execution time, however if a failure rises, we can see 
the overhead percentage from as low as 22% to as 
high as 66% in time. This bottleneck is mainly due 
because of the time taken to move the checkpoint to 
the nodes in the spare cluster, since the time to restart 
the application once that the checkpoints where in the 
spare cluster is negligible. 
5. Conclusion
The proposal in this paper is based on the RADIC 
architecture, that is capable of assure a successful 
execution of the application even when failures occur. 
We analyzed every component of the framework and 
identified the improvement areas. 
By translating every RADIC concept to H-RADIC 
and taking them to a virtual multi-clusters level, we 
develop a FT framework capable of overcome fatal 
fails like the loss of a full site.The H-RADIC 
architecture fully implements RADIC and the new 
benefits from H-RADIC and it allows us to guarantee 
the completion of the execution in the event of errors 
like, loss of nodes, loss of communication between 
sites or general fails in several sites. It’s a solution 
that can be implemented in virtual and non-virtual 
environments. 
Considering that a traditional FT system, that 
consist on having one or two copies of a full site in 
another one, waiting for the main site to fail, with H-
RADIC, by distributing the work load in different 
sites, the need of resources is way less that the ones 
needed for the traditional FT system. 
Finally, the experiments show us that the overhead 
in most of the programs is reasonable and proves the 
theory behind the concept. 
6. Future Work
Test the architecture implementing semi coordinated 
and no-coordinated checkpoints, to run a single 
program in several virtual clusters at the same time. 
Develop the architecture in a way that if the 
performance is decreasing, it can request more 
resources live to the cloud provider, to assure 
competition before the due date. 
Implement a mechanism that accelerates the 
transfer rate, by improving I/O, use incremental 
checkpoints and/or compress [16] the checkpoints 
even more. 
Acknowledgements 
The first author acknowledges the support from the 
National Science and Technology Council of Mexico 
(Consejo Nacional de Ciencia y Tecnología, 
CONACYT) that sponsored through a scholarship, 
and special thanks to all the team at CAOS and the 
UAB. 
References 
[1] B. Darrow, “Windows Azure outage hits 
Europe,” 26-Jul-2012. [Online]. Available: 
https://gigaom.com/2012/07/26/windows-azure-
outage-hits-europe/. [Accessed: 30-Mar-2018]. 
[2] O. Malik, “Severe storms cause Amazon Web 
Services outage,” 29-Jun-2012. [Online]. 
Available: 
https://gigaom.com/2012/06/29/some-of-
amazon-web-services-are-down-again/. 
[Accessed: 30-Mar-2018]. 
[3] “Summary of the Amazon S3 Service Disruption 
in the Northern Virginia (US-EAST-1) Region,” 
Amazon Web Services, Inc. [Online]. Available: 
https://aws.amazon.com/message/41926/. 
[Accessed: 31-Mar-2018]. 
[4] “Google Cloud Status Dashboard.” [Online]. 
Available: 
https://status.cloud.google.com/incident/storage
/17002. [Accessed: 31-Mar-2018]. 
[5] J. Hult, “Oracle Cloud - unplanned outage - 
November 7, 2017,” JonathanHult.com, 17-
Nov-2017. . 
[6] J. Villamayor, D. Rexachs, and E. Luque, “RaaS: 
Resiliance as a Service – Fault Tolerance for 
High Performance Computing in Clouds,” p. 
Accepted, Mar. 2015. 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
12
[7] A. Gómez, L. M. Carril, R. Valin, J. C. Mouriño, 
and C. Cotelo, “Fault-tolerant virtual cluster 
experiments on federated sites using BonFIRE,” 
Future Gener. Comput. Syst., vol. 34, pp. 17–25, 
May 2014. 
[8] L. Bautista-Gomez, S. Tsuboi, D. Komatitsch, F. 
Cappello, N. Maruyama, and S. Matsuoka, “FTI: 
High Performance Fault Tolerance Interface for 
Hybrid Systems,” in Proceedings of 2011 
International Conference for High Performance 
Computing, Networking, Storage and Analysis, 
New York, NY, USA, 2011, p. 32:1–32:32. 
[9] S. Di, Y. Robert, F. Vivien, and F. Cappello, 
“Toward an Optimal Online Checkpoint 
Solution under a Two-Level HPC Checkpoint 
Model,” IEEE Trans. Parallel Distrib. Syst., vol. 
28, no. 1, pp. 244–259, Jan. 2017. 
[10] I. P. Egwutuoha, S. Chen, D. Levy, B. Selic, and 
R. Calvo, “Cost-oriented proactive fault 
tolerance approach to high performance 
computing (HPC) in the cloud,” Int. J. Parallel 
Emergent Distrib. Syst., vol. 29, no. 4, pp. 363–
378, Jul. 2014. 
[11] L. Fialho, G. Santos, A. Duarte, D. Rexachs, and 
E. Luque, “Challenges and Issues of the 
Integration of RADIC into Open MPI,” in Recent 
Advances in Parallel Virtual Machine and 
Message Passing Interface, Springer, Berlin, 
Heidelberg, 2009, pp. 73–83. 
[12] M. Castro-León, H. Meyer, D. Rexachs, and E. 
Luque, “Fault tolerance at system level based on 
RADIC architecture,” J. Parallel Distrib. 
Comput., vol. 86, pp. 98–111, Dec. 2015. 
[13] “NAS Parallel Benchmarks,” NASA Advanced 
Supercomputing Division. [Online]. Available: 
https://www.nas.nasa.gov/publications/npb.html
. [Accessed: 23-May-2018]. 
[14] “MPICH | High-Performance Portable MPI,” 
MPICH. [Online]. Available:
https://www.mpich.org/. [Accessed: 02-Jun-
2018]. 
[15] J. Ansel, K. Arya, and G. Cooperman, “DMTCP: 
Transparent checkpointing for cluster 
computations and the desktop,” in 2009 IEEE 
International Symposium on Parallel 
Distributed Processing, 2009, pp. 1–12. 
[16] D. Tao, S. Di, X. Liang, Z. Chen, and F. 
Cappello, “Improving Performance of Iterative 
Methods by Lossy Checkponting,” 
ArXiv180411268 Cs, Apr. 2018. 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
13
CLOUD ROBOTICs: Vehículo autónomo conectado a 
AWS 
Manuel Costanzo1, Marcos Boggia1, Ismael Rodríguez1 and Armando De Giusti1,2 
1 Instituto de Investigación en Informática LIDI (III-LIDI), Facultad de Informática, Universidad Nacional de 
La Plata. 
2 Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET), Argentina. 
{mcostanzo, mboggia, ismael, degiusti}@lidi.info.unlp.edu.ar 
Resumen  
El trabajo desarrollado presenta un avance de la 
publicación realizada en el XXIII Congreso 
Argentino de Ciencias de la Computación (CACIC 
2017), con título “Cloud Robotics: Auto Rover 4WD 
y Cuadricóptero controlados remotamente desde 
AWS” [1], en el cual se incorporan algoritmos para 
procesamiento y reconocimiento de imágenes, 
algoritmos para simulación y determinación de ruta 
óptima al destino establecido, algoritmos para 
detección de obstáculos a evitar y espacios 
transitables, con bajo costo computacional. 
Se presenta el despliegue de un sistema multi-robot, 
compuesto por un chasis de auto Rover 4WD con 
cámara de video y sensores integrados, como así 
también de una cámara aérea fija (simulando la 
captura de imágenes desde un cuadricóptero no 
tripulado – Drone), conectados al Cloud público de 
Amazon Web Services (AWS). Asimismo, se 
detallan los prototipos desarrollados, el protocolo de 
comunicación utilizado con el servicio de AWS IoT, 
y los algoritmos implementados para efectuar el 
control remoto del vehículo de cuatro ruedas no 
tripulado, con el fin de llegar a un destino de forma 
autónoma. 
Palabras claves: Autonomous Cars, Amazon Web 
Services, Cloud Robotics, Internet of Things, 
Protocolo MQTT, Herramienta de programación 
visual Node-RED. 
1. Introducción
Los avances en el paradigma de Cloud Computing 
han provocado un factor disruptivo de las TI en la 
industria tecnológica. Según el Instituto Nacional de 
Estándares y Tecnologías del Departamento de 
Comercio de los EEUU (NIST), como en varias 
publicaciones de diversos autores, se ha definido a 
Cloud Computing como: “un paradigma informático 
de cómputo distribuido, que proporciona grandes 
conjuntos de recursos virtuales (como ser hardware, 
plataformas de desarrollo, almacenamiento y/o 
aplicaciones), fácilmente accesibles y utilizables por 
medio de una interfaz de administración web. Estos 
recursos son proporcionados como servicios (del 
inglés, “as a service”) y pueden ser dinámicamente 
reconfigurados para adaptarse a una carga de trabajo 
variable (escalabilidad), logrando una mejor 
utilización y evitando el sobre o sub
dimensionamiento (elasticidad). El acceso a los 
recursos se realiza bajo la demanda de los usuarios, 
en base a un modelo de autoservicio” [2]. 
El modelo de Cloud Computing presenta las 
características y beneficios siguientes: recursos 
disponibles bajo demanda, escalabilidad y 
elasticidad, aprovisionamiento automático de 
recursos y autoservicio. 
Dicho paradigma, brinda al menos tres modelos de 
despliegue: Cloud Público, Cloud Privado y Cloud 
Híbrido [3,4]. 
Por otro lado, considerando la gran influencia de la 
robótica en la sociedad y ladiversidad de servicios 
ofrecidos por robots, nos encontramos que los 
mismos presentan grandes limitaciones en consumo 
de energía, poder de cómputo, capacidad de 
almacenamiento, toma de decisiones, tareas 
cognitivas, etc. 
En el año 2010, comenzaron a surgir proyectos de 
investigación (ej: RoboEarth [5]), que integraban las 
tecnologías de Cloud con los sistemas de robots. Es 
así, que James Kuffner propone el concepto de 
Cloud Robotics, basado en combinar las tecnologías 
de robots con el paradigma de Cloud Computing [6]. 
La idea de Cloud Robotics, permite por medio de 
aplicaciones tratar los datos de los componentes de 
hardware del robot (sensores, actuadores/motores, 
cámaras, microcontroladores, memoria, etc.), sin 
importar las limitaciones de cómputo de las placas 
de desarrollo con microcontroladores y la capacidad 
de almacenamiento de las mismas [7]. En otras 
palabras, este concepto permite a los robots obtener 
resultados de tareas de cómputo intensivo, tales 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
14
como: procesamiento de imágenes, reconocimiento 
de voz, determinación de rutas, confección de 
mapas, acciones cognitivas, etc., sin tratamiento 
local, sino en el Cloud. 
Este paradigma brinda la capacidad de establecer 
escenarios para sistemas de multi-robot, donde cada 
robot se integra de un hardware mínimo; una placa 
microcontroladora con conectividad WiFi permite al 
robot comunicarse con el Cloud y otros robots. Los 
datos de sensores y/o sistemas de adquisición de 
imágenes se procesan en el Cloud y los actuadores 
de cada robot llevarán a cabo las operaciones 
necesarias [8]. 
El propósito de investigación del presente trabajo es 
el despliegue de un sistema de multi-robot, 
inicialmente con dos robots conectados al Cloud 
Público de Amazon Web Services con el fin de 
simular el desplazamiento autónomo de un vehículo 
de 4 ruedas, como así también la gestión de una 
cámara aérea (simulando la captura de imágenes 
desde un cuadricóptero no tripulado - Drone), 
ambos conectados al Cloud público de AWS, donde 
corre una instancia de EC2 con algoritmos de 
procesamiento de imágenes que determinan la ruta 
que debe efectuar el vehículo autónomo para llegar a 
un destino establecido. Para alcanzar tales objetivos, 
se determinó el método de comunicación con el 
Cloud; se registraron los robots como dispositivos o 
“cosas” en el servicio de AWS IoT [9]; también, se 
confeccionaron los prototipos de cada robot y se 
incorporaron los algoritmos para procesamiento y 
reconocimiento de imágenes, algoritmos para 
simulación y determinación de ruta óptima al destino 
establecido, algoritmos para detección de obstáculos 
a evitar y espacios transitables, con bajo costo 
computacional. 
El presente trabajo está estructurado de la manera 
siguiente: en la Sección 2, se introducen algunos 
conceptos elementales. A continuación, la Sección 3, 
presenta los prototipos confeccionados y sus 
componentes. En la Sección 4, se describe el trabajo 
experimental realizado. Por último, la Sección 5, 
expone los resultados obtenidos en relación a esta 
investigación. 
2. Conceptos básicos
2.1. Amazon Web Services 
Es una plataforma de Cloud Público, que provee 
“Infraestructura como servicio”; a través de la 
tecnología de virtualización, provee un gran 
conjunto de recursos de cómputo, como ser, 
almacenamiento y capacidad de procesamiento, que 
pueden ser solicitados a demanda, como así también, 
se adecuan dinámicamente en tamaño conforme la 
necesidad del consumidor. Los servicios más 
destacados de AWS son “Elastic Compute Cloud” 
(EC2), “Simple Storage Service” (S3) y en nuestro 
caso utilizaremos los servicios de “AWS Internet of 
Things” (AWS IoT) [10]. 
2.2. Internet of Things (IoT) 
Es un nuevo paradigma cuya definición deriva de 
considerar “objetos” o “cosas” conectadas a Internet 
por medio de redes Wireless, sean estas de 
tecnología WiFi o 4G LTE, utilizando protocolos de 
comunicación estándar. Dichas “cosas” pueden 
considerarse etiquetas de identificación por radio 
frecuencia (RFID), sensores, actuadores, teléfonos 
móviles, placas de desarrollos, etc. [11]. 
2.3. Protocolo MQTT 
Message Queuing Telemetry Transport [12] es un 
protocolo de comunicación ligero, especialmente 
diseñado para tolerar conexiones intermitentes y 
reducir los requisitos de ancho de banda de la red. 
Desde finales del año 2014, fue presentado como un 
estándar abierto OASIS [13] y se ha convertido en el 
protocolo por excelencia para IoT. Soporta 
comunicación segura con TLS. Maneja tres niveles 
de calidad de servicio: QoS 0: A lo sumo una vez la 
entrega del mensaje. QoS 1: Al menos una vez la 
entrega del mensaje. QoS 2: Exactamente una vez la 
entrega del mensaje. 
Este protocolo, implementa la comunicación de 
mensajes por medio de la publicación/suscripción 
sobre un tópico específico (canal de comunicación), 
como se puede observar en la figura siguiente: 
Fig. 1 MQTT: publicación/subscripción de mensajes. 
2.4. AWS IoT 
Es un servicio que proporciona AWS con el fin de 
conectar, administrar y operar grandes conjuntos de 
dispositivos o cosas. Ofrece mecanismos de 
conectividad y seguridad para la transmisión de 
datos. También, permite que los datos, una vez 
enviados a la plataforma, puedan ser procesados por 
las aplicaciones de análisis masivo de datos (Elastic 
MapReduce), análisis predictivo para aprendizaje 
automático (Amazon Machine Learning), 
almacenamiento en bases de datos, etc. [14]. 
AWS IoT permite conectar fácilmente dispositivos 
al Cloud y a otros dispositivos. El servicio es 
compatible con los protocolos: HTTP, WebSockets 
y MQTT. Amazon ha optado por este último, por 
ende AWS IoT utiliza la especificación del 
protocolo MQTT v.3.1.1 con QoS 0 y 1. 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
15
Cada dispositivo debe ser registrado como una 
“cosa” en AWS IoT, para lo cual se emitirá un 
certificado y un par de llaves privada-pública para el 
mismo. El certificado y la llave privada, junto con el 
certificado de la Entidad Certificantes (CA) de 
Amazon, deberán ser instalados en el dispositivo con 
el fin que este pueda conectarse al servicio de AWS 
IoT previa autenticación necesaria. 
2.5. Node-RED 
Es una herramienta de programación visual, que 
permite programar algoritmos basados en flujos para 
IoT, sin la necesidad de escribir código. Provee de 
un editor de flujo basado en navegador WEB, que 
brinda una amplia paleta de nodos con diversa 
funcionalidad. El flujo se confecciona conectando 
los nodos entre sí. La funcionalidad de cada nodo 
está desarrollada sobre Node.js. Los flujos creados 
son almacenados utilizando JSON, lo cual facilita la 
importación o exportación para compartir los 
mismos [15]. 
3. Prototipos y componentes
Para el presente trabajo se ha ensamblado un chasis 
de robot Rover de cuatro ruedas, que simula un 
vehículo tradicional de propulsión trasera, es decir, 
con un motor que ejerce la transmisión del 
movimiento sobre el eje trasero; también, cuenta con 
la capacidad de orientar las ruedas delanteras para la 
dirección del mismo. Igualmente, se incorpora una 
cámara de video integrada para la detección de 
obstáculos de forma local al vehículo; y se utiliza 
una placa micro-controladora de bajo costo y un 
módulo de expansión compatible, para controlar el 
motor de la tracción trasera y un sensor de 
ultrasonido, como se detallan a continuación: 
3.1. Chasis Rover 4WD con servo S3003 
Es un chasis compuesto de dos capas de acrílico, con 
un motor de 3 a 24v DC y velocidades con carga de 
258 a 347 rpm/min, cuatro ruedas y un servo S3003 
que permite direccionar el chasis con giros de hasta 
45 grados. Sus dimensiones son: 248mm (L) x 
146mm (W) x 70mm (H). 
Fig. 2 Chasis Rover 4WD. 
3.2. Microcontroladora Raspberry Pi 3 
Placade bajo costo de desarrollo que brinda 
conexión WiFi, almacenamiento en memoria 
MicroSD de 32Gb y soporta alimentación de energía 
de 5v DC [16]. 
Fig. 3 Raspberry Pi 3. 
3.3. RaspiRobot Board V3 
Es un módulo de expansión [17] compatible con 
Raspberry Pi 3, que brinda la interfaz de conexión 
entre la placa de desarrollo y los motores; incluye 
una fuente de alimentación conmutada para el 
suministro de energía, tanto de la placa Raspberry Pi 
como de los actuadores. 
Fig. 4 Raspirobot Board V3. 
3.4. Sensor Ultrasónico HC-SR04 
El HC-SR04 es un sensor de distancias por 
ultrasonidos capaz de detectar objetos y calcular la 
distancia a la que se encuentra en un rango de 2 a 
450 cm; cuantifica el delay de la señal, es decir, el 
tiempo que demora la señal en regresar el eco. 
Fig. 5 Sensor ultrasónico HC-SR04. 
3.5. Raspberry Pi Camera Board 
Pi Camera V2.1, es un módulo de video alta calidad 
de 8MP con sensor de imagen Sony IMX219 y un 
lente de foco fijo. Es capaz de tomar imágenes 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
16
estáticas de 3280 x 2464 pixeles como así también, 
capturar vídeo de 1080p30, 720p60 y 640x480p90. 
Fig. 6 Raspberry Pi Camera Board V2.1. 
3.6. Fuente conmutada Step-Down 
Fuente de alimentacióncon regulador Step-Down 
DC-DC XL4015, que brinda una salida regulada de 
1.25 a 36V. 
Fig. 7 Fuente DC Step-Down. 
3.7. Acelerómetro y Giroscopio de 3 ejes 
EL módulo Acelerómetro MPU tiene un giroscopio 
de tres ejes con el que podemos medir velocidad 
angular y un acelerómetro también de 3 ejes con el 
que medimos los componentes X, Y y Z de la 
aceleración. Utilizamos el sensor de giroscopio para 
que el robot pueda posicionarse en la dirección 
correcta. 
Fig. 8 Módulo MPU-6050. 
4. Trabajo experimental
El trabajo de investigación consistió en desarrollar 
una plataforma web que permita controlar 
remotamente, vía internet, el sistema de multi-robot 
que emula un vehículo autónomo de 4 ruedas y una 
cámara de video de un Drone. 
El escenario está compuesto por el Robot Rover 
4WD, que posee una identificación por medio de la 
figura geométrica de un “cuadrado blanco con 
bordes negros”. Así también, se dispone de un punto 
de destino identificado por la figura geométrica 
“circulo blanco con bordes negros” para la detección 
aérea y un “cuadrado blanco con bordes negros” 
para la detección desde el Robot Rover 4WD. Por 
otro lado, los objetos obstáculos están identificados 
por las figuras geométricas de “círculos rojos”. 
Quien se encarga de identificar cada componente es 
el Cloud, por medio de las imágenes provenientes de 
la cámara aérea que emula a un Drone. Una vez 
identificados el Robot Rover 4WD y el punto 
destino sobre el escenario, se calcula el camino 
óptimo para que el vehículo se desplace hacia el 
punto desinto. 
A continuación se describen los procedimientos para 
el procesamiento de imágenes y la determinación del 
camino óptimo. 
4.1. Procesamiento de imágenes 
El procesamiento de imágenes se realiza en una 
instancia de EC2 [18] en el Cloud, utilizando la 
librería OpenCV [19] y lenguaje de programación 
Python [20]. Se implementó un algoritmo que 
permite detectar e identificar sobre una imagen de 
captura aérea, las coordenadas de ubicación del 
Robot Rover 4WD con respecto al punto de destino; 
tomando como base dichas coordenadas se realiza el 
cálculo de la distancia entre el vehículo y el destino, 
como así también, los grados de diferencia entre los 
mismos. 
4.1.1. Cámara aérea 
La cámara aérea emula la captura de video que 
puede realizar un Drone. Dentro del escenario 
experimental se ubicó a una altura de tres metros 
sobre el nivel de la superficie del Robot Rover 
4WD, enfocando el escenario completo. Dicha 
cámara está integrada a una placa de desarrollo 
Raspberry Pi 3. 
Cuando el Robot aéreo recibe una señal vía el 
protocolo MQTT, desde el Cloud, solicitando una 
captura de imágen, el dispositivo realiza la captura 
de video en una resolución de 640x480 pixels, 
luego, disminuye la calidad en un 80% y realiza una 
compresión de la misma en base64, para por último 
enviarla vía MQTT a la instancia EC2, con el fin que 
el Cloud pueda realizar el reconocimiento y 
ubicación del Robot Rover 4WD y el punto de 
destino. 
Todo el procesamiento mencionado se implementó 
con el lenguaje de programación visual Node-RED. 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
17
4.1.2. Cámara local 
El Robot Rover 4WD, posee de forma integrada una 
cámara de video que permite realizar capturas de 
forma local al vehículo. 
Cuando llega una notificación del Cloud, se efectua 
una captura de video y se realiza el procesamiento 
de compresión detallado anteriormente en la cámara 
aérea y se envía la imagen a la instancia EC2 en el 
Cloud. 
A diferencia de la imágen capturada por la cámara 
aérea, en este caso, el punto destino es identificado 
por el reconocimiento de la figura geométrica 
“cuadrado blanco con bordes negros”. 
4.1.3. Instancia EC2 
Cuando la instancia EC2, recibe una imagen, vía 
MQTT, se procede a identificar las figuras 
geométricas en la imágen. En el caso de la imagen 
capturada por la cámara aérea, como ya se ha 
mencionado, se tiene que detectar un “cuadrado 
blanco con bordes negros” para identificar al Robot 
Rover 4WD; y la figura geométrica de un “círculo 
blanco con bordes negros” para identificar al punto 
de destino. Por otro lado, en el caso de la imagen 
capturada por la cámara local del Robot Rover 
4WD, se debe identificar la figura geométrica de un 
“cuadrado blanco con bordes negros” para 
identificar al punto de destino. 
Una vez detectadas las figuras, se prosigue a calcular 
la distancia entre el vehículo y el destino. 
Previamente a este cálculo, es necesario haber 
calibrado las cámaras. Debido a que la visión de las 
cámaras es distinta, ya que la cámara aérea puede 
observar el escenario completo, en cambio, la 
cámara local sólo el punto de destino, la calibración 
de las mismas también difiere. 
La figura 9 presenta el flujo de procesamiento de 
una imagen. 
 Fig. 9 Flujo de procesamiento de imágenes. 
4.1.4. Calibración cámara aérea 
El proceso de calibración se basa en realizar cálculo 
de la medida del ancho (en centímetros) de la figura 
geométrica del “cuadrado blanco con bordes negros” 
del Robot Rover 4WD. El objetivo de la calibración 
es determinar cuántos “centímetros” hay en un pixel. 
Con esta referencia, se podrá conocer la distancia en 
centímetros entre cualquier par de pixels. 
Para lograr tal calibración, se calcula la distancia 
Euclidiana [21] entre dos extremos de la figura 
geométrica del cuadrado, y se divide por el ancho de 
referencia, como se puede observar en el algoritmo 
1. 
Algoritmo 1 Distancia Euclidiana 
1: # Librería para calcular la distancia 
euclidiana en PyTHON 
2: from scipy.spatial import distance as dist 
3: def get_distance(p1, p2, reference): 
4: return dist.euclidean(p1, p2) / reference 
Ejecutado el algoritmo 1, se logra obtener el 
conocimiento de cuántos pixels forman un 
“centímetro”. 
Dicha información es útil para la determinación de 
la distancia en “centímetros” entre el Robot Rover 
4WD y el punto de destino; ahora alcanza con 
realizar el cálculo las coordenadas (x,y) del centro 
de las figuras geométricas, e invocar a la función del 
algoritmo 1, reemplazando los parámetros p1, p2 y 
reference por las coordenadas del Robot Rover 
4WD, las del punto destino y el resultado de la 
calibración respectivamente. 
4.1.5. Calibración cámara local 
Este proceso de calibración [22] difiere del 
anteriormente mencionado, ya que no calcula la 
distancia entre objetos sobre una imágen, por el 
contrario, requiere conocer la distancia entre la 
cámara local y la figura geométrica “cuadrado 
blanco con bordes negros” del punto destino. Para 
estacalibración es necesario contar con dos datos: el 
ancho de la figura geométrica y la distancia en que 
se encuentra el Robot Rover 4WD con respecto de la 
figura al momento de la calibración; con dichos 
datos, se procede a realizar el cálculo de la longitud 
focal de la cámara local por medio de la ecuación 1: 
Longitud_Focal =
𝑊𝐹𝑖𝑔𝑃𝑋 ∗ 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎
𝑊𝑒𝑛𝐶𝑀
 (ecuación 1) 
Donde: 
WFigPX: es el ancho de figura en Pixels 
WenCM: Ancho en centímetros. 
El cálculo de la distancia focal se obtiene tras la 
ejecución del algoritmo 2. 
Algoritmo 2 Longitud Focal 
1: # Librería de Opencv 
2: import cv2 
3: def focal_length(contour, width, distance): 
4: marker = cv2.minAreaRect(contour) 
5: return (marker[1][0] * distance) / width 
6: #marker[1][0] retorna el ancho en pixels 
de la figura geométrica. 
Una vez obtenida la distancia focal, se procede a 
calcular la distancia entre la cámara y cualquier 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
18
objeto en la imagen local, por medio de la 
ecuación 2: 
Dist_Objeto =
𝑊𝑒𝑛𝐶𝑀∗𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑_𝐹𝑜𝑐𝑎𝑙
𝑊𝐹𝑖𝑔𝑃𝑋
 (ecuación 2)
Donde: 
WenCM: Ancho en centímetros. 
WFigPX: es el ancho de figura en Pixels 
La distancia al objeto se obtiene ejecutando el 
algoritmo 3. 
Algoritmo 3 Distancia Objeto 
1: # Librería de Opencv 
2: import cv2 
3: Def 
distance_from_object_to_camera(contour, 
width, focal_length): 
4: marker = cv2.minAreaRect(contour) 
5: return (width * focal_length) / 
marker[1][0] 
4.2. Planificación de camino óptimo 
Una vez finalizada el procesamiento de las imágenes 
y realizado el cálculo de distancia entre el Robot 
Rover 4WD y el punto de destino, se procede a 
determinar el camino óptimo. 
Un camino está compuesto por un conjunto de 
movimientos que guiarán al vehículo autónomo 
desde la posición donde se encuentra, hacia el punto 
de destino, evitando que colisione con los obstáculos 
que se presenten de por medio. Es necesario aclarar 
que si bien el algoritmo de planificación, que se 
detalla a continuación, contempla la identificación y 
el rodeo de los obstáculos, este trabajo se limita a 
que el Robot Rover 4WD alcance el punto de 
destino sin obstáculos de por medio. 
El Robot Rover 4WD puede realizar movimientos de 
giro en grados a derecha e izquierda (de 0 a 180 
grados y de 0 a -180, respectivamente), como así 
también, movimientos para avanzar una determinada 
distancia en centímetros. 
La técnica de planificación elegida es la denominada 
RRT (Rapidly Exploring Random Trees) [23]. Este 
algoritmo se basa en la construcción de un árbol de 
configuraciones que crece buscando a partir de un 
punto origen en forma aleatoria, como se puede 
observar en el algoritmo 4. 
Previamente, se definen algunas variables: 
● self.node_list: es el árbol generado
● self.start, self.end: son las coordenadas de
inicio y de fin respectivamente 
● self.rand_y, self.rand_x: es el espacio de
configuraciones 
● self.expand_dis: es la distancia en el que los
nodos se expanden. En nuestro caso utilizamos la 
distancia euclidiana calculada en la calibración de 
la cámara aérea, por lo que los nodos están 
separados a un centímetro de distancia. 
Algoritmo 4 Algoritmo RRT 
1: def planning(self): 
2: # Flag que indica si encontró el 
destino. 
3: goal_flag = False 
4: # Lista de nodos del path. 
5: self.node_list = [self.start] 
6: for i in range(MAX_ITER): 
7: # Búsqueda aleatoria 
8: if random.randint(0, 100) > 
self.goal_sample_rate: 
9: rnd = 
[random.uniform(self.rand_x[0], 
self.rand_x[1]), random.uniform( 
10: self.rand_y[0], self.rand_y[1])] 
11: else: 
12: rnd = [self.end.x, self.end.y] 
13: # Busca el nodo más cercano. 
14: nind = 
self.get_nearest_list_index(self.node_list, 
rnd) 
15: nearest_node = self.node_list[nind] 
16: theta = math.atan2(rnd[1] - 
nearest_node.y, rnd[0] - nearest_node.x) 
17: new_node = 
copy.deepcopy(nearest_node) 
18: new_node.x += self.expand_dis * 
math.cos(theta) 
19: new_node.y += self.expand_dis * 
math.sin(theta) 
20: new_node.parent = nind 
21: if not self.collision_check(new_node, 
self.path.obstacles): 
22: continue 
23: self.node_list.append(new_node) 
24: # Verifica si se llegó al destino. 
25: dx = new_node.x - self.end.x 
26: dy = new_node.y - self.end.y 
27: d = math.sqrt(dx**2 + dy**2) 
28: if d <= self.expand_dis: 
29: goal_flag = True 
30: print("Goal!!") 
31: break 
En la línea 9, se inserta el nodo inicial en la 
estructura del árbol de nodos. 
En la línea 10, se declara el límite de repeticiones 
del algoritmo. Este límite está dado por el valor que 
se le da a la constante MAX_ITER. 
Entre las líneas 13 y 18 se realiza la búsqueda 
aleatoria del nodo dentro del espacio de 
configuraciones. 
En la línea 22, se obtiene el vecino más próximo de 
VI Jornadas de Cloud Computing & Big Data (JCC&BD 2018)
19
la configuración aleatoria obtenida anteriormente. 
Entre las líneas 21 y 23, se determina el nuevo nodo 
a agregar al árbol realizando un salto (de tamaño 
self.expand_dis * math.cos(theta)) partiendo del 
vecino más cercano y el nodo aleatorio. Si se 
determina, que en el camino no hay una colisión, se 
agrega el nuevo nodo al árbol. Por el contrario, si 
efectivamente hay un obstáculo de por medio, se 
continúa con la iteración siguiente y no se agrega el 
nodo al árbol resultante. 
Entre las líneas 24 y 31, se verifica si se llegó al 
punto destino. Si la distancia entre el nuevo nodo y 
el punto destino es menor a la métrica establecida 
(un centímetro), se termina el procesamiento, 
obteniendo el árbol de nodos. Si la distancia no es 
menor, se continúa con la iteración siguiente. 
Se implementó una interfaz gráfica utilizando node-
red-dashboard [24], que permite visualizar el 
resultado de la ejecución de la simulación del 
algoritmo RRT. 
Se puede observar en la figura 10, el resultado de 
simular la ejecución del algoritmo RRT tomando 
como punto de inicio la ubicación del Robot Rover 
4WD (punto verde), el punto de destino (punto azul) 
y los obstáculos de por medio (puntos rojos). 
Fig. 10 Simulación de la ejecución del algoritmo RRT. 
Como resultado de la planificación se obtiene un 
vector, donde cada una de sus celdas posee una 
coordenada (x,y). Se debe transformar estas 
coordenadas en movimientos. Cada movimiento 
constará de un grado de giro y una distancia en 
centímetros. Para dicha transformación se utilizar el 
algoritmo 5. 
Algoritmo 5 Transformación a movimiento 
1: def load_movements(self, prev_deg): 
2: p1 = None 
3: for p2 in coords: 
4: if p1: 
5: distance = helper.get_distance(p1, 
p2, self.config.pixel_distance) 
6: xDiff = p2[0] - p1[0] 
7: yDiff = p2[1] - p1[1] 
8: degree = 360 - 
(math.degrees(math.atan2(yDiff, 
xDiff))%360) 
9: degree_difference = ((degree - 
prev_deg) + 180) % 360 - 180 
10: prev_deg = degree 
11: self.movements.append(degree_difference, 
distance]) 
12: p1 = p2 
En la Línea 1, se declara el encabezado de la 
función, que consta de un parámetro llamado 
“prev_degree”. Este es el grado inicial del Robot 
Rover 4WD; a partir de este grado se podrá ir 
calculando la diferencia de grado entre los demás 
puntos. 
En la línea 3, comienza el bucle, iterando por todas 
las coordenadas resultantes de la planificación del 
camino. 
En la línea 4, se calcula la distancia Euclidiana ya 
mencionada anteriormente. 
En las líneas 6 y 7, se calculan las diferencias entre 
x2-x1, y2-y1. 
En las líneas 8 y 9, se calculan la diferencia de 
grados entre el punto anterior y un nuevo punto. Los 
grados varían en 0, 180 y 0, -180. 
Por último, en la línea 12 se almacena el 
movimiento. 
4.3. Plataforma WEB 
Se desarrolló una plataforma WEB que brinda una 
interfaz gráfica; esta permite realizar la calibración 
de las cámaras como así también, visualizar el 
resultado de la ejecución del algoritmo