UNIVERSIDAD DE GRANADA Programa oficial de Doctorado en Tecnologías de la Información y la Comunicación T E S I S D O C T O R A L Sistemas de laboratorios remotos sobre instrumentación de tiempo real: Aplicación a laboratorios de medida de tensión interfacial. Defendida por Jesús Luis Muros Cobos Director Juan A. Holgado-Terriza Departamento de Lenguajes y Sistemas Informáticos Grupo de Investigación en Sistemas Concurrentes Septiembre, 2017
120
Embed
Sistemas de laboratorios remotos sobre instrumentación de ...hera.ugr.es/tesisugr/28032962.pdf · UNIVERSIDAD DE GRANADA . Programa oficial de Doctorado en Tecnologías de la Información
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDAD DE GRANADA
Programa oficial de Doctorado en Tecnologías de la Información y la Comunicación
T E S I S D O C T O R A L
Sistemas de laboratorios remotos sobre
instrumentación de tiempo real: Aplicación a
laboratorios de medida de tensión interfacial.
Defendida por
Jesús Luis Muros Cobos
Director
Juan A. Holgado-Terriza
Departamento de Lenguajes y Sistemas Informáticos
Grupo de Investigación en Sistemas Concurrentes
Septiembre, 2017
Editor: Universidad de Granada. Tesis Doctorales Autor: Jesús Luis Muros CobosISBN: 978-84-9163-536-9URI: http://hdl.handle.net/10481/48348
(McKinley, et al., 2016). En esta tesis nos centraremos en los tensiómetros y goniómetros
como instrumentos útiles en el campo de la química, física, mecánica de fluidos, etc. Los
cuales si bien están siendo automatizados (Yu, et al., 2016), todavía tienen margen de mejora.
Actualmente existen diferentes tipos de tensiómetros y goniómetros tanto creados en las
propias universidades Dinaten (Holgado Terriza, 2002) como comerciales DSA-100 (KRÜSS
GmbH, s.f.) (Future digital scientific, 2017) basados en métodos ópticos, como puede ser ADSA
(Rıo & Neumann, 1997). Estos aparatos generalmente se componen de un ordenador, de una
cámara CCD, de un sistema para la dosificación (motorizada o no) y una base para gotas
sésiles, inclinadas o medidas de energía superficial, siendo el esquema el mostrado en ¡Error!
No se encuentra el origen de la referencia. y un ejemplo se muestra en la Fig. 2. Estos
sistemas tienen algunas desventajas, son instrumentos muy caros, requieren una instalación
compleja, un gran espacio, el manejo es complicado y son muy voluminosos, en los siguientes
capítulos se verán formas de tratar con ellas.
∆𝑝 = 𝛾 (1
𝑅1+
1
𝑅2)
Ecuación 2: Ecuación para la capilaridad de Young-Laplace donde Δp es la diferencia de presión, γ es la tensión superficial y R1 y R2 los radios principales de la gota.
A nivel software, este tipo de sistemas ópticos siguen el esquema que básico mostrado, Fig. 3.
Una vez se abre un proyecto que representa la información de un experimento se obtiene una
imagen, bien del almacenamiento, bien se toma con una cámara. La imagen se procesa para
obtener el perfil de la gota. El método consiste en realizar un proceso de optimización
empleando el modelo teórico de la gota de Young-Laplace Ecuación 2, hasta encontrar unos
valores de tensión superficial, tamaño, presión, ángulo, etc. que definan un perfil de la gota los
Introducción
26
más cercano posible al detectado en la imagen. Los valores que resuelven este perfil teórico
son el resultado de la medida. El proceso puede verse en la Fig. 4
Fig. 2: Instrumento típico basado en el método ADSA.
Fig. 3: Diagrama de flujo del método ADSA para el cálculo de la tensión superficial de una gota pendiente.
En este aspecto, Dinaten, un tensiómetro goniómetro basado en el método ADSA,
desarrollado en la Universidad de Granada por Juan Antonio Holgado Terriza y Miguel Ángel
Cabrerizo Vílchez es un ejemplo. Este instrumento está siendo usado en varias universidades
españolas. Y se ha empleado para la realización de experimentos cuyos resultados han sido
publicados en diversas revistas científicas, congresos, workshop, etc. (Maldonado-Valderrama,
et al., 2014) (del Castillo-Santaella, et al., 2014) (Maldonado-Valderrama, et al., 2013)
(Torcello-Gomez, et al., 2013)
En este trabajo se han realizado modificaciones sobre el tensiómetro/goniómetro de alta
precisión basado en Dinaten. Dichas modificaciones han mejorado la automatización del
sistema para el estudio de la evolución del sistema en fenómenos como la adsorción,
desorción, tensión superficial dinámica, o reología entre otros. Los resultados obtenidos han
sido validados y aceptados por la comunidad científica (Maldonado-Valderrama, et al., 2014)
que demuestran que los mecanismos propuestos ofrecen resultados válidos.
Tensiómetros/ goniómetros y su automatización
27
Se calculan los parámetros
iniciales(Tensión superficial, tamaño de la
gota, etc.)
Se calcula un perfil teórico de la gota (B1,
B2, � Bn) con los parámetros
establecidos
Se calcula el error de la gota
teórica sobre la real usando
una función F
Se optimizan los parámetros para la
generación de las gotas
F no es mínimo
El resultado de
la medición es
dado por los
datos de la gota
teórica
F es mínimo
Se importan los puntos detectados en el
perfil de la gota: (A1,A2�An)
Fig. 4: Calculo de los valores físicos de una gota.
Experimentación con un tensiómetro/goniómetro
Antes de hablar de la experimentación es necesario entender las magnitudes físicas que se
pretenden estudiar.
Como se ha indicado anteriormente los tensiómetros son usados para la medición de tensión
superficial (γ). Esta magnitud física tiende a minimizar la el área de la interfaz entre dos
fluidos. Esto minimización se debe a que las moléculas experimentan una acción con las que
las rodean, creando una fuerza atractiva (fuerzas de Van der Waals). Al encontrarse las
moléculas en equilibrio la fuerza resultante es nula, al menos para las que están en el interior.
Sin embargo en aquellas moléculas que se encuentran cerca o en la interfase la fuerza no
queda compensada por lo que se dirige hacia el interior de la gota, reduciendo el área de la
interfase. Hay que hacer notar que este desequilibrio de fuerzas hace que la energía potencial
sea mayor en las moléculas de la interfase, la contribución energética de todas estas
moléculas se denomina energía superficial. Estas fuerzas son de corto alcance, de ahí que en la
experimentación se empleen gotas.
Experimentación con un tensiómetro/goniómetro
28
Los goniómetros miden el ángulo de contacto, este ángulo viene definido por la tangente de la
interfase liquida-vapor y la superficie sólida. La forma de la gota depositada en una superficie
es controlada por la energía libre de las tres interfases involucradas liquida-vapor, sólido-vapor
y sólido líquido.
Cuando la gota está en equilibrio termodinámico se cumple la ecuación de Young Ecuación 3,
derivada de la ecuación de Young-Laplace Ecuación 2. La importancia de esta ecuación radica
en que a través del ángulo de contacto podemos determinar de forma indirecta propiedades
como el carácter liófobo/liófilo, rugosidad, etc. (Neumann, et al., 2010) (Miller & Neogi, 2007)
de la superficie. Igualmente puede explicar otros fenómenos como adsorción, la extensión,
etc. (Myers & others, 1990) (Adamson, et al., 1967).
𝜎𝑠 = 𝜎𝑠𝑙 + 𝜎𝑙 ∙ 𝑐𝑜𝑠𝜃
Ecuación 3: Ecuación de Young, donde σs, σsl, y σl indican la tensión interfacial solido-vapor, solido-líquido y liquido-vapor respectivamente. Θ define el angulo de contacto.
Tanto en la medida de la tensión superficial en gota pendiente como en la medida del ángulo
de contacto, las gotas se rigen por la ecuación de Young-Laplace Ecuación 2 y cuya única
diferencia en el cálculo viene dada por la deformación producida por la gravedad que se
tomará en un sentido u otro dependiendo del tipo de gota. Esto hace que los instrumentos
usados para medida de tensión superficial y ángulo de contacto sean muy parecidos y que por
tanto muchas veces el mismo instrumento sea un tensiómetro y un goniómetro.
Para estos experimentos se estudian diferentes tipos de gotas:
Pendiente: Este tipo se generan colgando de un capilar y se usa para medir la tensión
superficial e indirectamente para otros valores como la elasticidad y viscosidad.
Pendiente invertida: Se introduce una burbuja de aire en un líquido más denso desde
un capilar en la zona inferior. Se mide la tensión superficial.
Sessile: Esta gota se dispensa sobre una superficie y se mide el ángulo de contacto.
Inclinada: Esta gota se dispensa sobre una superficie que se inclina, midiendo los
ángulos de avance y retroceso.
Cautiva: Si crea desde la zona inferior de una superficie usando un capilar,
normalmente el tamaño de la superficie es muy pequeño pues se pretende medir la
tensión superficial en lugar del ángulo de contacto.
Si bien en el punto anterior, Introducción, se ha comentado como son estos instrumentos y
como realizan los cálculos, no obstante la experimentación es más compleja pues una sola
gota no suele ser suficiente para obtener datos útiles. Con un instrumento de este tipo se
pueden realizar diferentes tipos de experimentos, medida de la tensión superficial, medidas
de ángulo de contacto, medición de energía, medidas de elasticidad, de viscosidad, etc.
Tensiómetros/ goniómetros y su automatización
29
Dependiendo del tipo de experimento se puede requerir un cambio en el tamaño de la gota,
cuando se experimenta con la dinámica de la gota, o el caso opuesto, la estabilización del
fluido manteniendo la gota de forma estática. En otros casos serán necesarios ambos,
mantener estable durante un tiempo para estabilizar el fluido y luego realizar cambios en el
volumen para obtener más datos como la elasticidad. En el caso de las dinámicas es necesario
dosificar el líquido o incluso inclinar la superficie a la vez que se toman imágenes. En el caso de
experimentos donde se requiera mantener la gota estática, una vez dosificada es necesario
mantener la gota durante un tiempo para estabilizar mientras se toman decenas o cientos de
imágenes y medidas. En el caso de que se requiera cambia de la gota mientras se toman
imágenes ha de usarse el mecanismo de dosificación para cambiar el volumen de la gota. Si
bien es posible realizar estas tareas de forma manual, esto conlleva ciertos problemas, por
ejemplo, ni la dosificación, ni la captura de imágenes será uniforme, otro ejemplo es que la
dosificación no será exacta. Además una vez que se acabe será necesario usar un programa
para realizar los cálculos Hay varias posibilidades para solucionar estos problemas:
Uso de captura de video en vez de fotos para luego extraer capturas de forma
uniforme.
Uso de captura de video en vez de fotos con extracción de capturas y calculo
automatizado.
Uso de dosificación motorizada que permita la dosificación exacta y uniforme.
Automatización de las capturas y dosificación con motorización e integración con el
sistema de cálculo.
La última posibilidad es la más compleja y la que permite mayor potencial pues permite
captura de imágenes y dosificar uniformemente a la vez que puede realizar los cálculos. Pero
no solo eso, una buena automatización además permite que se concatenen dosificaciones de
diferentes volúmenes o velocidades a la vez que se toman capturas a diferentes velocidades
dependiendo de necesidades y todo ello manteniendo la precisión del instrumento. Incluso en
los mejores sistemas es posible usar diferentes fluidos simultáneamente aumentando la
capacidad del instrumento.
La automatización tiene más ventajas, combinado con sistemas que permitan la
programación, permite la reproducibilidad del experimento, pues el investigador puede definir
todo lo que se hará en el experimento y emplear esa definición varias veces. Además al hacer
las diferentes tareas de forma automática reducimos la posibilidad de que se den errores
humanos que puedan afectar a los resultados pues los experimentos al repetirse se harán de
la misma forma.
Arquitectura de la automatización
30
Arquitectura de la automatización
Puesto que a través del punto Experimentación con un tensiómetro/goniómetro, se ha
considerado que la automatización de los experimentos facilita el uso y mejora la capacidad de
este tipo de instrumentos. Al comienzo de esta tesis, Dinaten, estaba en funcionamiento con
un sistema de automatización, este tenía un defecto: el sistema de automatización estaba
escrito de forma que cualquier cambio afectaba al núcleo. A partir de ahí se consideró que era
necesario cambiar el sistema a uno que mantuviera todas las capacidades y flexibilidad a la vez
que permitiera crear un núcleo estable que permitiera introducir nuevas tareas sin necesidad
de ser alterado. En este trabajo se propone una arquitectura flexible capaz de mantener un
alto grado de automatización, añadir o eliminar capacidades sin necesidad de alterar el núcleo
y adaptable a cualquier instrumento.
Se consideró necesario definir una arquitectura capaz de adaptarse lo máximo posible,
soportar multi-hebrado y tiempo real. Es cierto que actualmente Dinaten no trabaja en tiempo
real, no obstante, tras meditar sobre las posibilidades de automatización se llegó a la
conclusión de que era mejor crear una arquitectura abstracta útil para cualquier instrumento
que soportará automatización. De esta forma la implementación será la que se adapte a los
detalles dependiendo de las necesidades de cada instrumento. Se ha se han definido tres
tipos de estructuras detalladas a continuación y esquematizadas en Fig. 5:
Dinámica: Estructura capaz de planificar, verificar y ejecutar las acciones dentro de un
vector de contenedores.
Contenedor: Objeto abstracto que puede ejecutar un código. Contiene el tiempo de
activación, la duración total. En caso de ser una ejecución de tiempo real dispondrá de
la información de afinidad a un procesador y núcleo.
Proceso: Objeto que hereda de contenedor y que puede generar varias fases, estas
fases se generaran de forma dinámica cuando, la duración total vendrá definida por el
tiempo de generación de las fases más el tiempo de cada fase.
Fase: Objeto que hereda de contenedor y ejecuta una acción simple, es importante que
las fases sean tan simpes como sea posible y que en caso de tener que realizar varia
tareas simultaneas se empleen varias fases con el mismo tiempo de inicio.
Dinámica
�Fase 1...Fase 1 Fase 2 Fase N
Proceso 2
Fase N
Tensiómetros/ goniómetros y su automatización
31
Fig. 5: Esquema de los distintos elementos.
A partir de estas estructuras un experimento es un vector de contenedores operado por una
dinámica. El uso de fases sencillas independientes permite que se puedan añadir nuevas
funcionalidades con el tiempo sin alterar el código ejecutado por la dinámica y manteniendo la
compatibilidad con los experimentos definidos con anterioridad a los cambios. El
funcionamiento de la dinámica se realiza en cinco etapas explicadas a continuación:
1. Se buscan todos los procesos y se calcula los tiempos en los que se ejecutarán las fases
que componen el proceso.
2. Se crean los temporizadores para cada fase, incluidas las generadas por los procesos de
la forma indicada en
3. Se realiza una simulación para verificar que los datos de ejecución en cada fase son
correctos en base a la configuración del instrumento. Si la dinámica es de tiempo real
se realizará además se verificará que los tiempos son correctos y que dos contenedores
no se ejecutarán en el mismo instante sobre el mismo procesador/núcleo.
4. Se activan los temporizadores.
5. Cuando un temporizador se dispara se ejecuta el contenedor:
a. Si es una fase se ejecuta.
b. Si es un proceso se generan la información necesaria en base al estado del
experimento para las fases correspondientes en el momento de la ejecución.
6. Una vez que todos los procesos y fases han finalizado se procede a las tareas de
limpieza como la liberación de memoria y actualización de la interfaz para informar al
usuario de la finalización, permitir definir o empezar nuevos experimentos, etc.
Dinámica
Fase 1Proceso
1Fase 2
Proceso
2Fase 3
Fig. 6: Ejemplo de funcionamiento, antes de ejecución
Como se ve en el sistema de ejecución de la dinámica definido en esta arquitectura permite
realizar experimentos en tiempo real si el instrumento lo permite y admitiendo varias tareas
simultáneamente, verificando en todo momento que la programación del experimento es
correcta.
Automatización en Dinaten
32
Dinámica
Fase 1 Fase 2 Fase 3
T0 T1 T2 T2 T3
Proceso 1
F1 F2
T1+0.2 T1+0.5
Proceso 1
F1 F2
T1+0.2 T1+0.5
Proceso 1
F1 F2
T3+0.1 T3+0.7
Proceso 1
F1 F2
T3+0.1 T3+0.7
Fig. 7: Ejemplo de funcionamiento, etapa 2
En cuanto al usuario, no es necesario que conozca qué tipos de fases hay o como se realizan.
En la interfaz se le pueden ofrecer tareas complejas incluso obligar a que se ejecuten
secuencialmente de forma que solo tiene que programar los datos del experimento. Una vez
programado el software puede traducir las tareas complejas en procesos o fases y guardar la
información para crear el vector de contenedores que será ejecutado por la dinámica. Un
ejemplo es un experimento en el cual se requiere realizar n mediciones a la vez que se mueven
un actuador durante un tiempo t. El usuario solo dirá que quiere hacer esa tarea, entonces el
software creará las fases necesarias de forma que se programarán las distintas mediciones y el
movimiento del actuador, en este ejemplo pueden ser n+1 fases, n de tipo medición y una de
tipo actuador, de forma que las n fases de medición se realicen de forma secuencial,
calculándose el tiempo de inicio de cada fase de forma que las mediciones se realicen
uniformemente en el tiempo t a la vez la primera fase de medición y la fase de actuador
comenzarán en el instante 0 y la duración total de la fase de actuador será t.
Automatización en Dinaten
Como se ha comentado anteriormente, al comienzo de esta tesis Dinaten ya estaba en
funcionamiento y disponía de un sistema para automatizar los experimentos. En el caso de
Dinaten el experimento estaba basado en un proceso compuesto por fases, la clase dinámica
lee las fases de forma secuencial y ejecuta la información. El problema es que la información
de fase puede conllevar varias tareas simples, capturar una foto, inyectar, cargar, etc.
ejecutadas simultáneamente. Asimismo las tareas simples pueden ser ejecutadas en distintos
tipos de fase. Con el fin de realizar estas tareas la clase dinámica usa una serie de banderas
para decidir que se ejecuta dentro de la fase. El resultado es que en caso de hacer algún
cambio en el funcionamiento de las diferentes fases o añadir nuevas funcionalidades es
necesario modificar la clase dinámica, con los posibles daños colaterales que puede ocasionar,
creando múltiples complicaciones a la hora de mantener el código. Igualmente no permitía el
uso de fases que en función del estado del experimento.
Tensiómetros/ goniómetros y su automatización
33
Una de las aplicaciones de Dinaten es su uso para la realización de reologías, con el fin de
medir entre otras la elasticidad y viscosidad de un fluido. Una de los métodos para realizar la
medición de las propiedades mencionadas es la inyección y extracción de fluido siguiendo un
patrón sinusoidal con varia repeticiones mientras se mide la tensión superficial del líquido.
Tras finalizar las repeticiones se calcula la elasticidad y viscosidad tal y como se muestra en el
trabajo (Myrvold & Hansen, 1998).
La aplicación de este método en Dinaten, no era posible debido a que funciona con inyectores
Hamilton: MicroLab 500, MicroLab 900 y PSD3. Estos inyectores funcionan a través de puerto
serie en el cual reciben las órdenes para la inyección, extracción, cambio de válvula, etc. El
problema radica en que estos dispositivos solo pueden inyectar o extraer líquido de forma
lineal, por tanto no se puede crear una onda sinusoidal directamente.
Una forma de paliar este problema es empleando una función triangular basada en una
inyección y al terminar una extracción repitiendo esta operación tantas veces como se
necesario. Inicialmente los investigadores tenían que hacer la programación de las inyecciones
y extracciones con la captura de imágenes manualmente. Así pues la primera tarea fue crear
un sistema para que el usuario pudiera programar solo una fase de reología que de forma
trasparente de traduce en varias fases de inyección y extracción con captura aun así el hecho
de tener que modificar la clase de dinámica que gestiona que se hace conllevó problemas de
mantenimiento.
Aquí entra la nueva arquitectura que soluciona los problemas de posibles daños colaterales
cuando se añade nueva funcionalidad. Igualmente arquitectura propuesta en este trabajo
permite que se modifiquen las fases en tiempo de ejecución. Esta última característica es
importante para la creación de reologías sinusoidales basadas en área. Como se ha comentado
el inyector empleado en Dinaten solo admite órdenes para la inyección lineal de volumen,
puesto que no hay una relación fija y exacta entre volumen y área, que funcione en todos los
líquidos, como se mostrará más adelante, no es posible hace un sistema que calcule las fases
necesarias para llevar a cabo esta operación en el momento en que el usuario programa su
experimento. Sin embargo Dinaten dispone de un sistema inteligente para calcular la cantidad
de volumen necesaria en una extracción o inyección con el fin de conseguir un cambio
determinado en el área de una gota. Este sistema está diseñado para mantener el área o la
presión de una gota con el paso del tiempo, lo cual es muy útil en experimentos donde es
necesario mantener la gota durante un tiempo largo con el fin de conseguir un estado de
equilibrio en el fluido. Para el caso presentado en esta tesis la parte interesante es sistema que
controla el área. El área de la gota está relacionada con el volumen de la forma en que se
presenta en la Ecuación 4 (Holgado Terriza, 2002) donde k es aproximadamente 1 (Faour, et
al., 1996)
Automatización en Dinaten
34
𝑉13⁄ ≈ 𝑘𝐴
12⁄
Ecuación 4: Relación entre el área y el volumen de una gota
Considerando los incrementos de volumen es posible obtener la Ecuación 5 (Holgado Terriza,
2002)
𝑉(𝑡) − 𝑉(𝑡 − 1) ≈ 𝑘𝐴(𝑡)12⁄ [𝐴(𝑡) − 𝐴(𝑇 − 1)]
Ecuación 5: Relación entre volumen y área cuando hay cambios en el volumen
Para obtener un incremento en el área de la gota es necesario un mayor incremento en el
volumen, puesto que la relación varía según el fluido y las condiciones del experimento como
la temperatura y que la formula no es exacta no es posible definir una cantidad específica.
Para solucionar este problema Dinaten implementa un sistema basado en lógica difusa que
combinado con la Ecuación 5 permite calcular el volumen indicado para alcanzar un área de
gota especifica. Haciendo uso del sistema inteligente y con la nueva arquitectura es posible
crear un método de oscilación que aproxime una onda sinusoidal usando el área de la gota.
El método propuesto para la aproximación sinusoidal se basa en realizar varias fases de
control secuencialmente, cada fase tendrá una duración fija. Puesto que Dinaten no trabaja en
tiempo real puede haber retrasos entre fases debido a varios factores como otras tareas en el
sistema operativo o el retraso de la orden en el inyector que de media es aproximadamente
120ms, es imposible determinar con exactitud el área objetivo en cada fase de antemano. Con
la arquitectura propuesta es posible calcular de forma dinámica el objetivo cada vez que se
ejecuta la nueva fase, de esta forma se corrige cualquier retraso que se pueda dar. El objetivo
es que al inicio de cada fase sabiendo el instante t en el que está y cuánto dura sea posible
determinar el área que se debe alcanzar durante la fase en ejecución. Para ello se evalúa la
Ecuación 6.
𝐴 = sin(𝑡)
Ecuación 6: Área que se debe alcanzar en el instante t
Aplicando el método descrito en el párrafo anterior, se ha creado una versión de Dinaten que
usando los nuevos parámetros sea capaz de realizar reologías basadas en área. Para está
prueba se usó Octopus una configuración hardware con dos inyectores Hamilton PSD/3
equipados con válvulas 8/1 y jeringas de 125μl. Se emplearon fases con una duración de
250ms, se escogió esta duración para dar tiempo suficiente al inyector, el cual tiene un tiempo
de respuesta medio 120ms, de forma que se garantice que durante la fase al menos llega una
orden al inyector, se hicieron reologías de entre dos ciclos y veinte ciclos con una amplitud de
5 mm2 y un periodo de 2.5ms. Para el experimento se usó agua pura. Si bien los resultados aún
son preliminares, el sistema funciona adecuadamente, véase Fig. 8. Esto demuestra que la
Tensiómetros/ goniómetros y su automatización
35
arquitectura que se propone es correcta y cumple con lo que se requiere de ella. No obstante
al ser resultados preliminares se requieren más pruebas para garantizar que no hay algún
error de implementación antes de poner esta versión en producción.
Are
a (m
m)
Tiempo (s)
Fig. 8: Grafica de una reología sinusoidal usando el sistema propuesto, en naranja los datos medidos, en azul puntos teóricos de la función sinusoidal.
Introducción
36
Capítulo 3. Laboratorios virtuales y remotos
Introducción
Los laboratorios remotos y virtuales proporcionan una nueva alternativa de acceso a
instrumentos científicos de alta precisión de un coste elevado tanto en su adquisición como en
su utilización como sucede con los tensiómetros/goniómetros. En función de la tecnología
distribuida utilizada y el protocolo de comunicaciones es posible monitorizar dichos
instrumentos desde cualquier ubicación.
En este caso encontramos una diferencia ente los LR y los LV, mientras los LR realizan el
experimento de forma similar a como se realizaría de forma presencial, los LV realizan una
simulación en base a unos parámetros y un modelo matemático.
Dentro del ámbito universitario es común en carreras técnicas y científicas manejar distintos
tipos de instrumentos de laboratorio. Debido al alto coste de estos equipos, su acceso suele
estar limitado. Además estos instrumentos pueden requerir un entrenamiento específico por
lo que su uso queda restringido a técnicos de laboratorio que, en caso necesario seguirán las
pautas de un investigador, y realizarán los experimentos. Un ejemplo de este tipo de prácticas
las podemos ver en el centro de instrumentación científica de la UGR, donde son los técnicos
los que manejan los instrumentos.
El uso de laboratorios remotos puede facilitar a investigadores el acceso a equipos de
instrumentación a distancia y desde cualquier lugar geográfico para lo cual se necesita trabajar
con arquitecturas cliente-servidor y donde los resultados pueden ser accesibles a través de la
nube. Por otro lado el uso de un servidor que controle dicho instrumento puede introducir
diversos sistemas de control y registro que eviten un uso inadecuado de los equipos. Incluso
pueden permitir el uso de observadores, estos observadores pueden ser estudiantes
aprendiendo a usar los equipos o técnicos especializados que garanticen que no se realizan
tareas peligrosas con el equipamiento.
Actualmente se pueden encontrar diversos LR y LV en diversas áreas del conocimiento en
electrónica (Landin, et al., 2015), uso de láseres o navegación por satélite (Titov, et al., 2016)
en algunos casos, incluso de forma compartida entre diferentes universidades (Kalúz, et al.,
2013), pero incluso con esta diversidad es posible ver que un motivo recurrente es permitir a
los usuarios el acceso desde cualquier lugar a cualquier hora, también se puede apreciar que
normalmente incluyen sistemas de identificación de usuarios, o que usan sistemas para
protegerse (Williams & Browne, 2016) (Zutin, et al., 2016).
Laboratorios virtuales y remotos
37
Uno de los problemas comentados en el estado del arte es incluso cuando se crean LRV
muchas veces son tremendamente específicos (Grosclaude, et al., 2008) impidiendo cualquier
tipo de usabilidad. Para cubrir estos aspectos se propone una arquitectura que defina y
especifique las necesidades a la vez que se plantea un framework que de ejemplo y pueda ser
usado para la construcción de LRV. Este framework pretende facilitar la creación de entornos
remotos para el en nuevos instrumentos y la adaptación de equipos existentes tanto en el
campo de la investigación como en el campo de la educación.
Así pues disponer de un sistema informatizado que permita el acceso a los instrumentos de
forma remota podría mejorar las condiciones de uso para los alumnos mejorando su
rendimiento y su aprendizaje. Algunas de las ventajas pueden ser:
1. Acceso al instrumental sin problemas de horario.
2. Flexibilidad en los horarios especialmente en el caso de los estudiantes que trabajan.
3. Reducción del tiempo de espera para uso de los instrumentos al repartir los usuarios en
toda la jornada.
4. Registros de la actividad de los estudiantes.
5. Eliminación de la necesidad de desplazamientos a centros de instrumentación.
6. Incremento en las medidas de seguridad y limites en los experimentos que los usuarios
pueden realizar.
Obviamente no todo pueden ser ventajas, algunos de los problemas que pueden crear los LVR
son:
1. Problemas de seguridad.
2. Es necesario implementar controles exhaustivos de los usuarios y de que hacen.
3. Fallos en el control de las acciones pueden permitir al usuario realizar tares que no
debería ser capaz.
En el ámbito empresarial los desarrolladores de instrumentos de laboratorio tienen la
necesidad de mostrar a los clientes potenciales las bondades de sus productos. Actualmente
solo pueden hacer uso de marketing y a través de la venta de sistemas de demostración faltos
de muchas características de los dispositivos finales o desplazándose hasta donde está el
cliente. Disponer de un sistema que facilite el acceso remoto a sus componentes permitiría
que los consumidores tuvieran la oportunidad de probar los equipos cualquier lugar antes de
su adquisición independientemente de su localización geográfica. También permitiría que
empresas puedan ofrecer alquiler de equipos de forma temporal para la realización de
experimentos de la misma forma que actualmente algunas empresas ofrecen servicios de
impresión 3D.
Introducción
38
Igualmente estos sistemas pueden ser útiles en el ámbito de la educación, donde se pueden
utilizar en educación a distancia y combinado con eLearning, no obstante esta posibilidad no
se detallará en este trabajo al estar en otro ámbito.
Es cierto que se pueden emplear sistemas como escritorio remoto (RDP) y VNC, sin embargo,
estos sistemas dan acceso completo al usuario al sistema, con los riesgos que ello comporta
de, ahí que en esta propuesta trata de ofrecer una sistema específico que solo permita el
acceso a la instrumentación.
Es cierto que no todos los instrumentos pueden ser adaptados a las exigencias de los sistemas
remotos. Sin embargo existen otras opciones como la monitorización y el uso de móviles que
serán tratadas más adelante.
Esta capitulo se centra en el servidor, que requiere: organizar la arquitectura, que
componentes deberían ser ofrecidos y se propone un caso práctico con el fin de demostrar las
hipótesis propuestas.
En el capítulo anterior se ha hablado de las posibilidades que ofrece la automatización. Esta
automatización permite en el caso de los LVR que el usuario realice una programación de
tareas y las ejecute, evitando cualquier retraso debido al tiempo de reacción humano, a la red,
etc. y permitiendo que pueda realizar experimentos en tiempo real. En el caso de los
monitores, de los que se hablará en el Capítulo 4, donde es necesario observar procesos que
requieren mucho tiempo la automatización permite que el proceso sea dinámico, de forma
que el instrumento adapte las condiciones cuando sea preciso o que al finalizar una
observación automáticamente se comience la siguiente. Así pues añadir automatización a un
instrumento remoto y en especial al monitorizado es un buen complemento pues da mucha
flexibilidad a los estudiantes e investigadores que pueden realizar una programación de tareas
más o menos complejas sobre todo en el casos de monitorización si reducimos la
interactividad al comienzo del experimento podemos obtener todo su potencial, ya que si
todo va bien el investigador no tiene que desplazarse al laboratorio hasta que el experimento
finalice. Así mismo la automatización es un proceso útil en la labor científica, pues una vez
programado el experimento se puede usar en varias ocasiones de la misma forma lo cual
garantizará que los resultados sean reproducibles y evitará que el investigador tenga que
repetir los mismo pasos varias veces lo cual a su vez evitará errores humanos.
Tal y como se verá en el punto Características generales de un laboratorio, se pueden
encontrar características comunes independientemente del tipo de experimentos que se
realizan en cada laboratorio. Por ende aunque puede ser interesante crear un sistema de
laboratorios remotos específico para tensiómetros/goniómetros, se considera más interesante
crear un sistema que pueda ser útil para cualquier laboratorio de forma que pueda ser
aplicado en diversos campos.
Laboratorios virtuales y remotos
39
Los resultados expuestos en este punto han sido publicados en la revista International Journal
of Online Engineering (Muros-Cobos & Holgado-Terriza, 2012)
Características generales de un laboratorio
Conceptualmente a partir de la Fig. 9 podemos determinar que un laboratorio es un lugar con
diversos instrumentos, en el que los investigadores, y estudiantes trabajan realizando
experimentos y que tiene restricciones de acceso para evitar que personal no cualificado
pueda poner en riesgo su salud, la salud de los otros usuarios, el material contenido, etc. Por
tanto se pueden encontrar tres tipos de actores:
Investigadores/técnicos: Personal cualificado que realiza experimentos como parte de
sus tareas profesionales.
Estudiantes: personas que realizan los experimentos como parte de su formación,
generalmente con poca experiencia.
Personal de apoyo: Personal administrativo y de seguridad que se encarga de definir
quién puede acceder a los laboratorios.
Laboratorio
Fig. 9: Imagen conceptual de un laboratorio
A partir del concepto de laboratorio podemos definir las características necesarias para un LVR
en base a los aspectos que definen sus propiedades y tipos más importantes a través de los
distintos aportes hechos al tema. Además una vez tengamos claros cuales son las cualidades
más deseables de un LVR podremos intentar agregarlas a nuestro diseño.
Ubicación La situación u ubicación del laboratorio o de las partes que forman parte del sistema nos
permitirá diferenciar los laboratorios virtuales en función de donde estén situados (Bencomo
& Medina, 2010)
Características generales de un laboratorio
40
Acceso local: el laboratorio virtual se ejecuta en la misma máquina del usuario que va a
acceder al laboratorio. Un ejemplo es el sistema Simulink® dentro del marco de Matlab
(MathWorks, 2011).
Acceso remoto: en esta caso la parte principal de control y monitorización del sistema
se ejecuta en una maquina remota. Esta máquina proporciona una aplicación visor o
navegador a través del cual podemos contactar con la máquina remota. Esta opción
puede disponer de la ventaja de que el usuario no sepa si está ejecutando realmente
instrumentación real o es solo una simulación. Un ejemplo es el sistema SmartScience®
(Smart Science, 2011) empleado en algunas universidades para proveer de acceso a
instrumentos y material educativo relacionado con los experimentos.
En el caso de los laboratorios remotos, éstos siempre se ejecutan por definición de forma
remota. Por lo tanto, el equipamiento del instrumento y el experimento que se va a realizar
ocurren en una ubicación distinta a la ubicación en la que se encuentra el usuario. El sistema
proporciona algún tipo de visor o aplicación cliente para que el usuario pueda iniciar, visualizar
y monitorizar el experimento o el fenómeno que está ocurriendo como si estuviera en la
misma ubicación que el laboratorio.
En contraposición, un laboratorio tradicional sería aquel en el que tanto el equipamiento
como el experimento se encuentran en el mismo ordenador o equipo.
Interactividad La interactividad es la propiedad que determina el grado de interacción que tiene el usuario
con el laboratorio remoto/virtual. El grado de interacción permite la inmersión del usuario en
el laboratorio mejorando su experiencia de usuario. A la hora de crear un laboratorio
remoto/virtual este puede dar acceso a diferentes tipos de instrumentos reales o simulados.
Aquí por tanto debemos caracterizar diferentes situaciones:
No interactivos: estos laboratorios remotos/virtuales disponen de acceso a
instrumentos de medida los cuales no pueden ser alterados por los usuarios. Un
ejemplo es MADAMS (Cicirelli, et al., 2006)
Interactivos: estos entornos, además de tomar medidas permiten el uso de los distintos
dispositivos de forma que el usuario pueda hacer uso completo de la herramienta. Un
ejemplo está en Web-Based Courseware (Gomes, et al., 2000)
Definición de experimentos Independientemente de las características anteriores podemos definir las siguientes
cualidades:
Laboratorios virtuales y remotos
41
Definibles: En estos laboratorios el usuario puede desplegar sus propios
procedimientos o programas y comprobar los resultados. Un ejemplo es LabView®
(National Instrument, 2017)
o Entorno definible: Con este tipo de laboratorios solo podemos definir las
variables con las que se ejecutará un experimento.
o Ejecución definible: En este caso se puede definir las variables iniciales del
experimento, podemos definir las acciones a ejecutar así como su orden de
ejecución. En ciertos casos el LVR puede ser de entorno y ejecución definible.
No definibles: Este software emplea los datos de un experimento concreto ya
definidos, y por tanto el usuario no puede realizar ningún tipo de cambio, sino
ejecutarlo tal y como el desarrollador o autor del laboratorio haya determinado. Un
ejemplo es MADAMS (Cicirelli, et al., 2006)
Verificación Independientemente de cómo se defina el experimento el laboratorio puede permitir el uso
de diferentes tipos de test y pruebas para verificar los resultados.
No verificable: El laboratorio virtual/remoto no permite aplicar ningún tipo de test
sobre el experimento.
Verificable: El laboratorio virtual/remoto permite verificar el experimento con una serie
de pruebas.
o Definible: El usuario puede definir los test o pruebas para verificar la correcta
ejecución del experimento.
o No definible: Los test para la verificación viene predefinidos en el propio
sistema.
Distribución
Como muestra la literatura (Cicirelli, et al., 2006) (Grosclaude, et al., 2008), la localización de
los elementos del laboratorio puede ser variable o no, por lo que éstos que pueden ser:
Centralizado: Todos los instrumentos se conectan a un servidor central el cual
proporcionará acceso a todos los dispositivos para los distintos clientes. Un ejemplo es
SmartScience® (Smart Science, 2011)
Distribuido: Los clientes acceden a los instrumentos los cuales estarán conectados
a distintas máquinas que proporcionaran los distintos servicios. Un ejemplo es Grid
Virtual Laboratory Architecture (Grosclaude, et al., 2008)
Simulación
Los laboratorios suelen ofrecer la posibilidad de realizar una simulación para reproducir el
experimento pudiendo cambiar incluso la configuración inicial. Puede haber varios métodos
Características generales de un laboratorio
42
dependiendo de si usamos un modelo informático o un modelo real a escala como medio de
simulación.
Informática: Los componentes usados en la simulación son imitados por un ordenador.
Simulink® (MathWorks, 2011) emplea este tipo de simulación.
Real: Los componentes usados son componentes reales que imitan un sistema a gran
escala. Por ejemplo MADAMS (Cicirelli, et al., 2006)
Mixta: Emplea tanto componentes virtuales como reales. Un ejemplo es Grid Virtual
Laboratory Architecture (Grosclaude, et al., 2008)
Propósito del laboratorio El desarrollo de un laboratorio virtual/remoto se puede hacer con varios propósitos:
Educativo: Su función es la de formar a estudiantes enseñando como se realizan
determinados experimentos así como analizar los resultados que se obtienen.
Profesional: Están pensados para recrear el comportamiento de un sistema y así poder
verificarlo antes de llevarlo a la práctica.
Mixto: Son laboratorios virtuales/remotos que pueden tener ambos propósitos.
Soporte de video Un laboratorio puede disponer de soporte para video que permita a los usuarios ver lo que
ocurre con la instrumentación.
Con soporte: Admite soporte de video en directo en modo streaming.
Sin soporte: No permite la retransmisión de video.
Instrumentación El objetivo de un laboratorio virtual/remoto es proporcionar acceso a instrumentación.
Dependiendo de las bondades de la implementación podrán incorporarse o no nuevo equipo
así será:
Dinámico: Permite que se añadan, modifiquen o eliminen instrumentos
Estático: Solo soporta los equipos incorporados.
Control de acceso y registro Es muy importante garantizar que el LVR solo puede ser utilizado por personal autorizado,
además debe quedar constancia de quien usa el sistema y como lo usa. Por lo general solo un
usuario empleará el instrumento, no obstante es posible que se permitan observadores:
Personal en formación: Estos observadores podrán ver como se realizan los
experimentos y tiene valor didáctico y no pueden intervenir directamente.
Laboratorios virtuales y remotos
43
Administradores: Observadores que garantizan que no se realicen acciones
inadecuadas y pueden parar el experimento si lo considera necesario. Función útil para
técnicos de laboratorio.
Características de los tensiómetros/goniómetros
Como se ha comentado en puntos anteriores los tensiómetros y goniómetros son
instrumentos usados para medir la tensión superficial y el ángulo de contacto
respectivamente. Es frecuente que los tensiómetros/goniómetros basados en métodos ópticos
cuenten inyectores u otros sistemas controlados por ordenador para dispensar la gota en la
que se va a medir. De la misma forma que se explicó en el Capítulo 1 es posible automatizar
las tareas y los experimentos reduciendo las interacciones directas del usuario con el
instrumento. Igualmente hay dispositivos como el DSA-100 (KRÜSS GmbH, s.f.) que permiten
desde el ordenador mover tanto la posición del capilar como la posición de la plataforma
donde se sitúan las superficies para la medición de ángulo de contacto o como Dinaten el cual
puede manejar diversos líquidos de forma simultánea. Como se ha comentado en puntos
anteriores los tensiómetros y goniómetros son instrumentos usados para medir la tensión
superficial y el ángulo de contacto respectivamente. Es frecuente que los
tensiómetros/goniómetros basados en métodos ópticos cuenten inyectores u otros sistemas
controlados por ordenador para dispensar la gota en la que se va a medir. Tal y como se
explicó en el Capítulo 1 es posible automatizar las tareas y los experimentos reduciendo las
interacciones directas del usuario con el instrumento. Igualmente hay dispositivos como el
DSA-100 (KRÜSS GmbH, s.f.) que permiten desde el ordenador mover tanto la posición del
capilar como la posición de la plataforma donde se sitúan las superficies para la medición de
ángulo de contacto.
Cuando el instrumento tiene las características citadas anteriormente el investigador lo
prepara, sitúa la muestra en el aparato y a partir de ese momento todas las interacciones se
realizan con un ordenador. Esta combinación de elementos permite su uso de forma remota
pues si se dispone de un técnico en el laboratorio, este podría realizar las operaciones previas
y situar los líquidos y/o superficies en el instrumento, a partir de este momento el investigador
podría de forma remota realizar sus experimentos sin necesidad de estar en el laboratorio.
Una vez finalizado el proceso, el técnico procedería a limpiar el instrumento y en caso de ser
necesario prepararlo para el siguiente investigador.
A nivel educativo puede ser útil por ejemplo en los procesos de gota pendiente, donde se
puede disponer de depósitos con diferentes líquidos, incluyendo agua y alcohol para que los
propios estudiantes puedan limpiar el sistema y realizar mediciones en líquidos con diferentes
propiedades. A la vez que siguen la documentación explicativa de lo que ocurre y su
significado físico/químico.
Fases de un experimento
44
Fases de un experimento
Los laboratorios proporcionan distintos tipos de herramientas para la definición y
configuración de un experimento, su puesta en marcha, y la obtención de resultados y su
análisis. Para sistematizar el procedimiento de medida es necesario determinar las distintas
fases que tiene un experimento así como los posibles tipos que podrán o no estar disponibles
en un laboratorio virtual o remoto.
Además de las fases del experimento hemos de tener en cuenta que este proceso requiere
una preparación así pues vamos a dedicar el primer punto a determinar las fases de la
preparación de un experimento. Posteriormente trataremos las fases de un experimento.
Etapa de preparación: En esta etapa se realizarán todos los protocolos previos a la
realización de un experimento. Si esta fase no se realiza correctamente, aunque
ejecutemos de forma perfecta un experimento los datos obtenidos no serán correctos.
o Fase de preparación de materiales: Se seleccionan y determinan los materiales y
herramientas necesarias para la realización de un experimento. Si no puede
realizarse de modo automático, un técnico de laboratorio se encargará de
prepararlos.
o Fase de preparación del entorno: En esta fase se adecuará el entorno de trabajo
al experimento que se vaya a realizar.
o Fase de calibración: Diversos mecanismos de recolección de datos requieren ser
configurados y calibrados antes de sus uso.
Etapa del experimento: Durante esta etapa se realizarán las operaciones del
experimento siguiendo un protocolo establecido. Su correcta ejecución nos permitirá
obtener resultados válidos y reproducibles de un experimento.
o Fase de inicialización: Durante esta fase se establece el entorno en el cual se
desarrollará un experimento. Puede haber dos tipos:
De ejecución definible: En este caso se definirán las acciones a ejecutar
además de las variables del entorno.
De ejecución fija: En este caso las acciones a ejecutar son siempre las
mismas y solo se definen las variables propias para el experimento.
Laboratorios virtuales y remotos
45
o Fase de ejecución: En esta fase se realizará el experimento ejecutando todas las
acciones necesarias. Existen dos posibilidades:
Ejecución interactiva: Con este tipo de ejecución el usuario puede
modificar el experimento durante su realización en tiempo real.
Ejecución no interactiva: Usando este sistema el experimento se realizará
sin permitir ninguna modificación.
o Fase de resultados: Durante este estado se devuelven al usuario los datos
resultantes de las operaciones realizadas durante la ejecución. Hay dos tipos no
excluyentes:
Informe: En este caso los resultados se dan a modo de informe una vez
finalizados los experimentos.
Monitorización: Este tipo de resultados se devuelven en tiempo real
durante la ejecución del experimento, de este modo el usuario puede
visualizar la evolución de las variables de medida.
Arquitectura de un laboratorio remoto
Tras identificar los aspectos que caracterizan un laboratorio, se puede definir un LRV como un
laboratorio compuesto por una serie de elementos: uno o varios instrumentos, un servidor, un
adaptador instrumento-servidor, un cliente y de forma opcional sistemas de captación de
imágenes.
Formalmente, se define como una tupla de elementos:
En esta propuesta se plantea una arquitectura centralizada que se considera puede ofrecer
todo lo necesario para el desarrollo de LVR, dicha arquitectura ha sido empleada para la
creación de un framework que facilite la reusabilidad a la vez que haga que programar un LRV
sea más rápido y sencillo.
La arquitectura centralizada nos aporta una serie de ventajas:
Arquitectura de un laboratorio remoto
46
Facilidad de gestión de usuarios: no se requiere sincronizar nodos ni controlar posibles
interbloqueos generados por el acceso simultáneo desde diferentes puntos.
Se eliminan posibles problemas concurrencia derivados de las limitaciones de usuarios
en los dispositivos.
El cliente queda desacoplado del laboratorio.
Seguridad: los clientes solo pueden acceder a los instrumentos a través del servidor,
por lo que se pueden verificar todas las órdenes antes de procesarlas.
Facilidad de gestión en las políticas de seguridad: Solo se deben configurar las políticas
de seguridad y cortafuegos en un ponto.
Por supuesto también existen inconvenientes:
Se pueden producir cuellos de botella en el servidor.
El número de usuarios simultáneos queda limitado por las capacidades del hardware y
de ancho de banda del servidor.
En caso de caída del servidor cae todo el sistema.
Una violación de la seguridad afecta a todos los usuarios.
Puesto que esta propuesta se enfoca en proporcionar lo necesario para el desarrollo rápido y
fácil de LVRs, la sencillez de la arquitectura se vuelve clave, como se desprende de la lista de
características anteriores la arquitectura centralizada nos provee de una alternativa sencilla.
A nivel lógico, la arquitectura propuesta implica cuatro capas Capa de dispositivos: en esta
capa se encuentras los instrumentos, las cámaras y el software de control en caso de ser
necesario.
Capa adaptadora: en esta capa se encuentran los componentes necesarios para
conectar los instrumentos con el servidor de LVR.
Servidor LVR: esta capa es la que se encarga de organizar todos los datos y ofrecer los
servicios a los clientes. Aunque el LVR opere con instrumentos de tiempo real, esta
capa podrá funcionar sin él pues será la capa adaptadora la que se encargue de hacer el
acople entre sistema de tiempo real y sistema sin tiempo real.
Clientes: en esta capa se encuentran las aplicaciones clientes que permitirán a los
usuarios acceder a los instrumentos y realizar experimentos.
Laboratorios virtuales y remotos
47
Adaptador Adaptador Adaptador
Cap
a d
e
dis
posi
tivo
s
Cap
a
ad
apta
do
raServ
ido
r LV
RC
liente
s
Fig. 10: Capas del LVR propuesto
Debido a su complejidad a continuación se explicará en más detalle las capas adaptadora y de
servidor.
La capa adaptadora tiene la tarea de conectar los instrumentos al servidor y de servir como
último filtro que evite ordenes que puedan dañar los dispositivos. Para ello empelará tantos
adaptadores como sea necesario, de esta forma cada adaptador será específico para el tipo de
instrumento que controle. Al disponer de diferentes adaptadores especializados se pueden
imponer en cada uno tantas restricciones y filtros como sea necesario para evitar que en caso
de error o ataque el instrumento ejecute una orden que pueda dañarlo de forma alguna.
Igualmente el hecho de disponer de varios adaptadores habilita la posibilidad de que cada uno
convierta los datos del formato nativo a uno apto para el servidor. Otra de las ventajas es que
cuando se añada un nuevo instrumento de un tipo diferente no afectará al resto de
dispositivos pues el adaptador será diferente, lo cual reduce el coste de mantenimiento al no
ser necesario hacer cambio en los adaptadores en producción. En consecuencia es posible
Arquitectura de un laboratorio remoto
48
conectar diversos instrumentos con diferentes requisitos, tiempo real, conexiones, protocolos,
etc. como se explicará en los siguientes puntos. Otra posibilidad que se puede dar es que los
adaptadores se deban de desplegar en diferentes ubicaciones y no en el servidor. Esto se debe
a que muchos instrumentos usan conexiones como USB, Firewire, serie, etc. lo cual obliga a
que los adaptadores se desplieguen en el laboratorio y no directamente en el servidor, en este
caso no supone problemas pues pueden instalarse en un ordenador o microcontrolador que
estará conectado a la red de forma que el servidor LVR pueda acceder a los dispositivos.
La capa de Servidor LVR es la más compleja ya que es la encargada de orquestar las acciones
del resto de capas. Esta capa cuenta con varios componentes que permiten controlar las
diversas acciones:
Gestor de instrumentos: este gestor se encarga de conectar con los instrumentos a
través de la capa de adaptadora. Se encarga de gestionar cuando están conectados y de
enviar las correspondientes órdenes a la vez que reciben los datos de las medidas.
Gestor de cámaras: Es un gestor que conectará con las cámaras a través de la capa
adaptadora.
Módulo de video: Este módulo se encarga de suministrar los canales de streaming
ofreciendo las imágenes obtenidas por las cámaras. En caso de ser necesario
recodificará señal para ofrecer una calidad óptima para el cliente.
Gestor de usuarios: Este componente se encarga del almacenamiento de los datos de
usuarios y de realizar el control de acceso de acuerdo a los privilegios que cada persona
tenga cuando se identifica. Además asignara prioridades para el acceso a instrumentos
en función de los grupos.
Módulo de comunicación: En el ámbito educativo o cuando existen observadores es útil
ofrecer un canal de comunicación entre el usuario que realiza el experimento y el resto
de personas conectadas.
Gestor de reservas: Este gestor realiza las tareas de garantizar que los usuarios puedan
reservar el uso de instrumentos y garantizar que sea posible su acceso en la ranura de
tiempo reservada.
Núcleo: este componente se encarga de conectar y orquestar al resto.
La arquitectura mencionada dispone de todos los componentes y recursos para gestionar un
LVR. Los aspectos de tiempo real y seguridad se detallan en los siguientes puntos debido a su
entidad.
A partir de la arquitectura hardware/software explicada, se ha creado un framework que
permita la creación de una forma y sencilla de LVR cuya implementación se detalla en los
puntos siguientes.
Laboratorios virtuales y remotos
49
Control en tiempo real
Es posible que algunos de los instrumentos que se empleen requieran trabajar en un sistema
de tiempo real (STR), para lo cual deben ser capaces de realizar tareas con plazos de
respuestas máximos acotados.
La alta latencia y las tasas de transmisión variables de redes de banda ancha como Internet
impiden que pueda operarse sobre dicha red en tiempo real estricto. Sin embargo, si el cliente
del laboratorio tiene que supervisar o monitorizar los experimentos que se realizan a través
del laboratorio LRV y las tareas que se realizan no deben llevar un control de tiempo real
desde el cliente, es posible limitar la respuesta confiable y en tiempo real sólo en el lado de los
dispositivos (capa 1 de la arquitectura)
En la arquitectura propuesta se plantea que la capa de dispositivos se implemente en un STR,
de forma que pueda controlar el instrumento los requisitos temporales y las restricciones
temporales para cada uno de los procesos y acciones que se realicen.
La capa adaptadora será la encargada de asegurarse de que la lectura de las mediciones y el
envío de órdenes se realizan dentro de un tiempo acotado, siendo necesaria que implemente
todas las herramientas que puedan requerirse para realizar la comunicación.
De esta forma las transferencia de datos desde el instrumento a la capa adaptadora se
realizará en la ranura de tiempo que esté especificada y durante el tiempo máximo asignado
en caso de ser necesario, la capa adaptadora se encargará de comprobar si los datos de la
medición son completos y consistentes, en ese caso será enviada a la capa servidora; en caso
de ser parciales o inconsistentes, se almacenarán hasta recibir el resto de la medición.
Para el caso de las ordenes, si el instrumento dispone de algún tipo de buffer para la
comunicación, la orden será enviada de forma que cuando el instrumento ejecute el proceso
de lectura de ordenes la lea, comprobando si se ha transmitido completamente y añadiéndola
al planificador en caso positivo, en caso de que debido a las restricciones temporales la orden
no se haya transmitido de forma íntegra, se esperará a la siguiente lectura de órdenes.
Si el instrumento no dispone de buffer para las comunicaciones, se deberán de proveer
mecanismos de sincronización que permitan enviar las órdenes en el momento previsto. Para
esto puede ser necesario que la capa adaptadora cuente con dos componentes uno de tiempo
real que se sincronice con el instrumento y que disponga de buffer para las ordenes y otro que
funcione sin tiempo real que orqueste los intercambios de información con entre el
instrumento y el servidor.
Arquitectura de un laboratorio remoto
50
En la
Capa adaptadora
Buffer
Capa adaptadora
Component
e sin
tiempo real
Component
e de tiempo
real
sincronizad
o con buffer
Configuración cuando el instrumento cuenta con buffer en la comuniación
Configuración cuando el instrumento no cuenta con buffer en la
comunicación
Fig. 11 se pueden ver esquemáticamente las diferentes posibilidades expresadas en este
punto.
Capa adaptadora
Buffer
Capa adaptadora
Component
e sin
tiempo real
Component
e de tiempo
real
sincronizad
o con buffer
Configuración cuando el instrumento cuenta con buffer en la comuniación
Configuración cuando el instrumento no cuenta con buffer en la
comunicación
Fig. 11: Esquema de los diferentes tipos de capas adaptadoras para ofrecer soporte de tiempo real
Laboratorios virtuales y remotos
51
Seguridad
El acceso al laboratorio desde cualquier lugar en cualquier instante requiere estudiar las
posibles vulnerabilidades que puede tener el sistema con objeto de reforzar la seguridad. En
propuestas de laboratorios remotos tales como los presentados por (Grosclaude, et al., 2008)
(Williams & Browne, 2016) (Pavón & Ferruz, 2010) no se hace un análisis serio de los posibles
problemas de seguridad que pueden surgir y únicamente se limitan a introducir máquinas
virtuales para aislar espacialmente los distintos laboratorios y utilizar VPN para cifrar la
conexión entre los clientes y la infraestructura (detrás de un servidor web) (Zutin, et al., 2016)
o se limitan a constatar que el riesgo es bajo y por tanto no se requieren medidas especiales
(Lakatoš, et al., 2016). Sin embargo, tal y como se indica en (Broisin, et al., 2017), la seguridad
es una propiedad que debe tenerse en cuenta desde que se conceptualiza un sistema de
laboratorio en la fase de captura de requerimientos. Por lo tanto, el diseño y la
implementación deben realizarse por y para la seguridad.
La inclusión de la seguridad dentro del desarrollo del sistema implica implementar un sistema
mucho más robusto que se manifieste seguro ante vulnerabilidades y la ejecución de distintos
tipos de código malicioso.
La seguridad debe garantizarse en diversos aspectos:
Seguridad de los datos: no se debe permitir que personas no autorizadas puedan
acceder, modificar o borrar los datos de los usuarios.
Seguridad de los dispositivos: Debe evitarse que un usuario malintencionado pueda
acceder directamente a los dispositivos o alterar su configuración.
Seguridad en el acceso: Es necesario controlar quien accede al sistema, como lo hace y
con qué privilegios, al mismo tiempo que se restrinjan ataques de fuerza bruta.
Gestión de turnos y colas: No se puede permitir que un usuario pueda saltarse los
turnos o colas de acceso a los dispositivos.
Se establece una serie de pautas mínimas que protejan el sistema frente a ataques en dos
niveles:
Un ataque directo, en el que se realizan acciones contra el LVR por parte de un usuario
malicioso para aprovecharse del sistema, dañarlo, secuestrarlo, recabar datos privados,
etc.
Un ataque indirecto, se basa en malware distribuido al azar sin objetivos definidos,
principalmente para obtener bots o secuestrar el sistema.
El hecho de que secuestrar el sistema aparezca en ambos tipos de ataque no se debe un error
en la escritura de este documento sino a que la infección por rasonware puede ser distribuida
Seguridad
52
de forma aleatoria con la esperanza de que el ataque tenga éxito como los que afectaron a
empresas como Telefónica en Mayo de 2017 (Muñoz, 2017) o dirigidas de forma específica
como el ataque sufrido por un hotel suizo en el cual los atacantes bloquearon las puertas de
las habitaciones (Bilefsky, 2017).
Con el fin de ofrecer la mayor seguridad posible es necesaria la implementación de las
siguientes medidas:
Usar conexiones SSL con certificados firmados por autoridades o con la clave pública
del servidor almacenada en el cliente, de esta forma se evitarán ataque del hombre en
medio que permitan a usuarios maliciosos se hagan con los datos de acceso al sistema.
Aislar las cámaras e instrumentos del acceso a internet, y sólo permitir dicha conexión a
través del servidor LVR de esta forma se evitará que puedan ser objeto de ataques.
En caso de usar red para las conexiones entre los instrumentos, su adaptadores y el
servidor, esta red deberá ser local o usar una VPN, en cualquiera de los casos debe
estar aislada y ser independiente del resto de redes.
Implementar varias capas de seguridad interna independientes, filtrando las órdenes
tanto en el punto de entrada del sistema como en los gestores de cámaras e
instrumentos como en la capa de adaptadores, de forma que aunque se consiga
introducir una orden desde un cliente que pueda dañar el instrumento, el gestor de
instrumentos o la capa adaptadora devuelvan un error sin llegar a ejecutarla en el
instrumento. Esto supone una latencia de tiempo extra completamente asumible
Establecer copias de seguridad de los datos almacenados de forma que sean
programables y adaptables a las condiciones del sistema donde se encuentre instalado.
Dichas copias se almacenan en ubicaciones aisladas e independientes del servidor de la
plataforma del laboratorio.
Bloquear los archivos de configuración y de datos de forma que ninguna aplicación
externa pueda modificarlos.
Evitar que el servidor donde se encuentra el LVR se destine a más usos.
Aplicar políticas de verificación en dos pasos, al menos cuando la conexión venga de
una localización no esperada como otro país. Con este sistema se puede permitir
conexiones desde cualquier parte a la vez que se ponen controles específicos para
conexiones no esperadas.
Incorporar un número máximo de intentos de identificación que evite la obtención de
contraseñas usando diccionarios o ataques de fuerza bruta.
Si bien es imposible alcanzar la seguridad perfecta, la aplicación de las pautas mencionadas
puede evitar parte de los ataques y mitigar el resto de forma que podamos prevenir daños en
los instrumentos y hacer lo posible por mantener el sistema conectado y funcional para los
usuarios.
Laboratorios virtuales y remotos
53
RVLab, un caso practico
Con el fin de probar que las pautas y arquitecturas definidas anteriormente son válidas se
procedió a crear un framework llamado RVLab. RVLab se presenta como un framework
destinado a facilitar la creación de servidores LVR. Con este fin provee de los servicios
comunes y un diseño especialmente creado para que sea extensible y se pueda adaptar con
facilidad a diversos instrumentos y cámaras. La implementación se ha realizado en C++
empleando el framework QT, este framework permite programar elementos como socket,
hebras, entradas, salidas etc. de forma transparente sin llamadas al sistema, por lo que el
código resultante es multiplataforma, durante el desarrollo el servidor fue probado en
Windows 7 y CentOS 5.
Este framework se ha desarrollado siguiendo las indicaciones expuestas en los puntos
anteriores. En la Fig. 12 se puede apreciar el diagrama de despliegue, aquí podemos ver los
diferentes dispositivos que no tiene por qué estar conectados físicamente al servidor, la capa
adaptadora integrada en el servidor, la capa servidora implementada en RVLab y por ultimo
clientes que pueden ejecutarse en Pc, tablets, etc.
RVLab, un caso practico
54
Fig. 12: Diagrama de despliegue de RVLab.
El framework consta de los varios componentes (Fig. 13), en base a los comentados
anteriormente, los más importantes son:
Núcleo: Proporciona una centralización de las distintas instancias. Proporciona el
servidor XML-RPC (Laurent, et al., 2001) y conecta las llamadas con los destinos a través
de señales.
Gestión de usuarios: Se encargará de los métodos para validar, crear, modificar y
eliminar usuarios. En la implementación se ofrece un gestor basado en archivos XML
con soporte para cifrado AES (Joan & Rijmen, 2002). Este gestor usa una interfaz por lo
deployment Deployment Mo...
«device»Serv er-Mac/Linux/Windows
«executionEnvironment»:RVLab
«device»Camera1
«device»Camera2
«device»cameraN
«device»Instrument1
«device»Instrument2
«device»InstrumentN
«device»PC-Mac/Linux/Windows
«device»Tablet-Android
«executionEnvironment»Driv er
«executionEnvironment»Client
«executionEnvironment»Client
rtsp Usb http
http
Usb, IEEE1394...
Bluetooh
httphttp
Laboratorios virtuales y remotos
55
que puede ser implementado para usar un conector a base de datos o cualquier otro
sistema.
Gestión de cámaras: A la hora de gestionar las cámaras se hará a través de la
configuración dada en el archivo config.xml, en él se definirán los datos de acceso a los
dispositivos de video así como la a marca. De esta forma el gestor puede de forma
dinámica cargar la biblioteca necesaria para el uso de las cámaras, por defecto RVLab
implementa clases para cámaras Vivotek y Axis.
Módulo de video: Este módulo accede a las cámaras, recodifica las imágenes con el
codec h.264 para video y acc para audio en un contenedor transport stream (TS) y crea
los servidores de streamening necesarios. Hay que destacar que estos servidores para
la emisión de video son independientes del núcleo, de forma que en caso de que haya
un exceso de clientes pueden caer los cuadros por segundo (fps), pero esto no afectará
a las operaciones con instrumentos ni a la comunicación con el núcleo.
Instrumentación: El módulo de instrumentación soporta todas las operaciones
correspondientes al equipo científico a usar. A los aparatos se les agregará un gestor de
turnos estándar que se encargará de seleccionar que usuario dispone de los
instrumentos.
Chat: Con el framework se incluye un servidor de chat que permite comunicarse a los
usuarios desde la misma plataforma.
RVLab, un caso practico
56
Fig. 13: Diagrama de componentes de RVLab.
En la Fig. 13 apreciamos como se interconecta los distintos componentes, algo que queda
claro es la existencia de un núcleo al que prácticamente todo queda unido. Así también es
posible ver como se establecen los distintos flujos de datos entre los distintos módulos y los
clientes. Dentro de esos flujos, los streaming multimedia que se generan en los servidores de
video son unos de los principales. También vemos un flujo bidireccional entre el cliente y el
núcleo, este flujo proporcionará la información necesaria para la apertura del resto.
Pruebas y Resultados
Para las pruebas se ha usado un servidor equipado con dos procesadores Intel Xeon E5405 de
cuatro núcleos cada uno a 2Ghz, 4GB de RAM, dos discos duros SAS en RAID 1 de 150GB y una
conexión de 100Mbits/s. Como sistema operativo usa CentOS 5.5 de 64bits. Dentro de este
servidor se ha usado Xen para virtualizar el servidor de prueba, esta máquina virtual cuenta
con cuatro núcleos y 512MB de RAM.
Para la toma de video se han usado tres cámaras: una Vivotek IP7135, una Vivotek PZ7131 y
una Axis M-1054. Como se ve, estas cámaras pertenecen a distintos fabricantes, de hecho su
cmp Component Mo...
Serv er
Video
Turnos Instrumentos
NúcleoUsuarios
«subsystem»http1
«subsystem»http2
«subsystem»httpN
Client
Gestión de datos de
usuarios
Gestión de datos de
grupos
Chat
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
Laboratorios virtuales y remotos
57
funcionamiento es muy distinto. Mientras las cámaras Vivotek emplean el códec MPEG-4 la
Axis usa H-264. Otra de las diferencias es que la cámara PZ7131 es totalmente móvil en los
tres ejes además de emplear zoom óptico. La cámara Axis, que es de alta resolución, soporta
un sistema de movimiento virtual cuando funciona a baja resolución, pues realmente la
cámara esta quieta pero permite mover la imagen y hacer zoom digitalmente. Nuestro
framework puede hacer funcionar el movimiento de ambas cámaras aunque se requieran
protocolos diferentes. Con estos demostramos la extensibilidad y adaptabilidad de nuestro
software ya que permite el uso de estos equipos aun siendo muy diferentes.
Los clientes se ejecutaron sobre 40 máquinas situadas en el aula 3.1 de la escuela técnica
superior de ingenierías de informática y telecomunicación, Fig. 14. Los ordenadores son
Pentium Celeron a 1.7Ghz con 512MB de RAM y 160GB de disco duro.
Fig. 14: Muestra de varios ordenadores ejecutando el cliente de laboratorio remoto.
Las cámaras IP empleadas en el estudio (Vivotek y Axis) tienen fijado un máximo en el número
de clientes conectados simultáneamente en quince usuarios. Por este motivo, se realizaron
pruebas manejando más de quince clientes, y así demostrar que realmente nuestro sistema es
fácilmente escalable y posibilita más usuarios que el uso de los dispositivos directamente.
En este ejemplo se ha contado con ciento cincuenta usuarios registrados en la aplicación,
pertenecientes a cuatro grupos diferentes. Para el caso se disponía de veinte reservas, 14
personales y cinco de grupo. Durante la prueba eran válidas dos reservas una personal de
11:00 a 12:00 y una de grupo de 12:00 a 13:00
Para la obtención de las gráficas se ha fijado la hora de inicio de las pruebas a las 11:39 y a las
12:19, en los cuales estuvieron conectados los cuarenta clientes. A partir de ese momento
empezamos a desconectar los ordenadores, en la última fase, una vez conectados los cuarenta
RVLab, un caso practico
58
clientes se le envió al servidor numerosas peticiones de turno, una de las llamadas más
costosas debido a que tiene que comprobar las reservas realizadas.
En primer lugar hemos realizado una medida del consumo de CPU (4 cuatro núcleos) y su
variación con respecto al tiempo y a los clientes conectados.
Fig. 15: Uso de CPU durante las pruebas
El uso de la CPU es prácticamente constante como demuestra la gráfica presentada en la Fig.
15. Varía relativamente poco en función de los clientes debido a que el mayor esfuerzo se
realiza en la recodificación de las imágenes. Sin embargo hay que tener en cuenta que las
llamadas XML-RPC son procesadas y de hecho vemos que a partir de las 12:15 cuando varios
clientes hicieron peticiones de turno en un corto periodo subió la tasa de uso del procesador.
0102030405060708090
100
11
:39
:01
11
:42
:01
11
:45
:01
11
:48
:01
11
:51
:01
11
:54
:01
11
:57
:02
12
:00
:01
12
:03
:01
12
:06
:01
12
:09
:01
12
:12
:01
12
:15
:01
12
:18
:02
12
:21
:01
12
:24
:01
Po
rce
nta
je d
e u
so
Hora (hh:mm:ss)
Uso de CPU
Uso de CPU
0
100
200
300
400
500
600
11
:39
:01
11
:42
:01
11
:45
:01
11
:48
:01
11
:51
:01
11
:54
:01
11
:57
:02
12
:00
:01
12
:03
:01
12
:06
:01
12
:09
:01
12
:12
:01
12
:15
:01
12
:18
:02
12
:21
:01
12
:24
:01
Me
mo
ría
usa
da
(MB
)
Tiempo (HH:MM:SS)
Consumo de momoria de RVLab
Memoria RAM
Intercambio
Laboratorios virtuales y remotos
59
Fig. 16: Gráfico de memoria usada
En la siguiente gráfica de la Fig. 16 se muestra el consumo de memoria. Como vemos el
consumo de memoria es muy estable, dado que la carga en memoria del programa se debe
principalmente a los archivos XML, y sobre todo a la recodificación del video. En nuestro caso
con la recodificación de tres streaming simultáneos requiere del uso de menos de 600MB de
RAM. Por tanto, la sobrecarga sobre los clientes conectados es mínima y su número causa un
impacto reducido en el uso de la memoria principal.
En la Fig. 17 vemos como la tasa de envío de datos sube conforme conectamos nuevos
clientes. Este es el comportamiento esperado porque a mayor número de clientes, más
información de video debemos de enviar. En este caso tuvimos un pico de 57.5MBits/s, un
cambio muy significativo con respecto a los 26.2Mbits/s aproximadamente cuando hay 15
clientes. Evidentemente en el momento en que empezaron a disminuir los clientes la tasa de
envío cayó. El apagado de los 40 ordenadores en un corto periodo se muestra en la fuerte
caída de envíos que se ve a partir de las 12:19 hasta quedarse en cero a las 12:24 debido a que
no quedaban clientes recibiendo datos. El comportamiento respecto a los picos de carga es el
normal, ya que cuando hay movimiento en las cámaras, se transmiten más datos que cuando
estas están quietas y la imagen trasmitida permanece estática.
Fig. 17: Tasas de envío de datos
0
10
20
30
40
50
60
70
11
:39
:01
11
:42
:01
11
:45
:01
11
:48
:01
11
:51
:01
11
:54
:01
11
:57
:02
12
:00
:01
12
:03
:01
12
:06
:01
12
:09
:01
12
:12
:01
12
:15
:01
12
:18
:02
12
:21
:01
12
:24
:01
Dat
os
en
Mb
its/
s
Hora (hh:mm:ss)
Tasa de envio de datos
Emisión de datos
RVLab, un caso practico
60
Fig. 18: Tasa de recepción de datos
Si bien en este caso también hay una subida en la recepción de datos conforme sube el
número de clientes, ver Fig. 18, la variación no es tan fuerte como en el caso anterior, pues de
1.34 Mbits/s con quince clientes pasamos a un pico máximo de 1.74Mbits/s con cuarenta.
Incluso con cero clientes el ancho de banda consumido es de 0.8 Mbits/s. Estos datos se deben
a que la mayor parte de los bits recibidos son los recibidos de las cámaras, los cuales se siguen
recibiendo aun cuando no hay clientes. De hecho si comparamos la emisión y la recepción
mostradas en la figura 21, vemos que realmente la recepción de datos es casi constante en
comparación con la emisión. Lo cual es perfectamente normal tal y como se ha explicado
antes.
0.000.200.400.600.801.001.201.401.601.802.00
11
:39
:01
11
:43
:01
11
:47
:01
11
:51
:01
11
:55
:01
11
:59
:01
12
:03
:01
12
:07
:01
12
:11
:01
12
:15
:01
12
:19
:01
12
:23
:01
Dat
os
en
Mb
its/
s
Hora (hh:mm:ss)
Tasa de receción de datos
Recepción de datos
Monitorización
61
Capítulo 4. Monitorizacio n
Introducción
A pesar de que los laboratorios remotos proporcionan múltiples ventajas para el acceso y
utilización de instrumentos a distancia, siguen teniendo aspectos complejos de resolver con
respecto a la automatización. Todavía es necesaria la ayuda de un técnico de laboratorio
encargado de las tareas de limpieza del equipo y preparación de los experimentos que se van a
realizar con dichos instrumentos, así como una perfecta sincronización con los investigadores
que van a manejar el instrumento remotamente.
En muchos casos, además el técnico debe pasar por un periodo de aprendizaje para llevar a
cabo dichos experimentos que puede ser más o menos complejo en función de las
características del instrumento y de los experimentos que se pueden llevar a cabo, igualmente
puede ocurrir que el desarrollo de un LVR sea demasiado complejo para la problemática en
cuestión o que los administradores no confíen en que el LVR proteja adecuadamente los
instrumentos. Todo esto puede propiciar que en algunos casos un LVR pueda no ser la mejor
solución. No obstante, en aquellos casos en los que los experimentos requieran una
supervisión continuada durante intervalos de tiempo largos de horas e incluso días para
estudiar el fenómeno asociado al mismo, no es posible mantener la atención de un técnico o
del propio investigador durante el desarrollo del experimento. Un ejemplo son los
experimentos de digestión in-vitro realizados en tensiómetros en el que se requieren un
seguimiento de más de ocho horas (Maldonado-Valderrama, et al., 2014).
En estos casos, un programa monitor puede seguir la evolución del experimento permitiendo
el acceso al investigador desde cualquier dispositivo (e.g., un móvil) y en cualquier lugar como
se realiza en el ámbito sanitario (Hernandez, et al., 2015). No sólo eso, sino que además
pueden notificar al investigador de cualquier incidencia que pueda ocurrir durante la
realización del experimento como en (Ai & Chen, 2011).
La monitorización también es usada ampliamente en el ámbito espacial donde obviamente no
es posible acceder a los datos in situ. (Lindqvist, et al., 2016) (Eparvier, et al., 2015) o en
instrumentos que funcionan a alta velocidad (Evtushenko, et al., 2014). Viendo estos ejemplos
se considera que es necesario proponer nuevos sistemas que se adapten a los requisitos
científicos, a experimentos de larga duración, aprovechando lo mejor de las propuestas
dirigidas al ámbito médico y aeroespacial para el resto de áreas científicas.
Introducción
62
Para ayudar a mejorar el trabajo del investigador, en esta tesis se propone un sistema de
monitorización que permita al investigador estar informado sobre su experimento en su móvil
con dos objetivos:
Registre la evolución del experimento por si el usuario necesita conocer el progreso del
experimento, mostrando datos del experimento con una determinada frecuencia.
Reciba alertas o notificaciones durante el desarrollo de un experimento en cuanto
algunos de los parámetros de medida se encuentren fuera de los márgenes
establecidos previamente.
La monitorización del experimento puede incluir información de otros aspectos del entorno al
experimento como la temperatura, humedad o el estado de la alimentación eléctrica que
puedan afectar al experimento, usando por ejemplo usando mecanismos de fusión de datos a
partir de la lectura de varios sensores como la propuesta por (Rodríguez-Valenzuela, et al.,
2014) De esta forma, el usuario podrá realizar otras actividades mientras el experimento está
en marcha.
La introducción de un sistema monitor aporta algunas ventajas frente al laboratorio remoto:
El instrumento no será controlado por el monitor, como mucho se permitirá una
parada de emergencia.
La adaptación de un instrumento es más sencilla que en el caso de los laboratorios
remotos.
El monitor puede funcionar en segundo plano y solo activarse en caso de necesidad.
La carga computacional en el cliente es baja.
Obviamente también introduce desventajas:
Se pierde el control del instrumento.
Es menos efectivo en el ámbito educativo.
Una de las desventajas expuestas es la perdida de interacción con los instrumentos. Sin
embargo puede ser compensada con el uso de automatización. Al permitir que las tareas se
lleven de forma automática no es necesario que el usuario realice tareas con el instrumento,
basta con que las programe. De esta forma la perdida de interactividad no afecta a la
realización de experimentos que podrán realizarse de la misma forma.
El sistema de monitorización propuesto pretende aportar un nuevo canal de notificación fiable
y tolerante a fallos. Con este fin se propone el uso de dispositivos auxiliares portátiles los
cuales pueden ser alimentados con baterías para hacer frente a pérdidas de electricidad,
conectables al instrumento que se supervisa mediante diversos tipos de protocolos de
comunicación (e.g., Ethernet y Serie), y con conectividad Ethernet o 3G o 4G para transmitir
Monitorización
63
los datos a Internet al dispositivo del investigador. Para evitar que un fallo de internet pueda
afectar a la monitorización, se considera el envío de datos también a través de la red GSM
(explicación de la abreviatura), que posibilita la transmisión de pequeños mensajes.
En caso de error el sistema de notificación alertará al usuario que podrá parar el experimento,
dejar que continúe, usar un sistema remoto en caso de estar disponible o acudir
personalmente al laboratorio para solucionar la fuente del error y empezar el experimento de
nuevo.
Con el fin de mejorar la experiencia de usuario y mantenerlo activo durante la supervisión se
definen dos posibles modos de supervisión.
Modo activo: en este caso los datos se reciben en todo momento para lo cual se
requiere conexión a internet tanto en el cliente como en el servidor de forma
permanente. El sistema mostraría continuamente la evolución de los parámetros
configurados durante la realización de un experimento. Requiere una atención
continuada que puede ser realizada desde cualquier parte.
Modo pasivo: el sistema notificará sólo en caso necesario al investigador mientras se
ejecuta el experimento. El uso de alertas asíncronas ligeras aumenta la tolerancia a
fallos pues en caso de pérdida de internet se puede recurrir al SMS.
Los resultados expuestos en este punto fueron presentados y publicados en el congreso
CIVEMSA 2012 (Muros-Cobos, et al., 2013)
Sistema de monitorización ubicuo
En este trabajo se propone el diseño de un sistema monitor ubicuo que facilite la supervisión
del experimento realizado por un instrumento desde cualquier ubicación mediante la
utilización de dispositivos móviles.
El monitor propuesto en esta tesis se basa en un dispositivo, sistema de monitorización
instrumental (SMI), conectado al instrumento, por cualquier método, que solo realizará
lecturas o tareas muy básicas siendo incapaz de alterar la configuración del instrumento o
interactuar con él. El cliente se conectará, identificando al usuario, con este dispositivo con el
fin de acceder los datos del experimento o de recibir alerta predefinidas o definidas por el
usuario. Debido al uso de móviles esta propuesta va destinada a permitir el modo de ahorro
de energía. Con el fin de incrementar la tolerancia a fallos se emplean múltiples sistemas de
comunicación simultáneamente. Todo ello se realiza preservando la seguridad del sistema.
Las características principales de la propuesta son:
Eliminar la necesidad de conexión en el instrumento.
Sistema de monitorización ubicuo
64
Desacople del instrumento y el móvil.
Múltiples conexiones hacia el exterior en el SMI.
Múltiples conexiones al SMI desde el cliente (SMS, WIFI, 3g-4g).
Sistema de identificación del cliente.
Sistema de notificación basado en todos los sistemas de conexión.
Uso de comunicaciones cifradas.
Los distintos componentes mencionados se han separado en diversos puntos con el fin de
explicar con claridad cada uno de los elementos, se comienza con la arquitectura, se continua
con las comunicaciones instrumento-servidor y servidor-cliente, después se especifica el
sistema de múltiples conexiones, el cliente y para finalizar las pruebas realizadas.
Arquitectura La arquitectura propuesta se basa en tres elementos el instrumento, el SMI y el cliente móvil
como se muestra en la Fig. 19. El instrumento incluye los equipos de medida y el adaptador
para la conexión con el software de control del SMI.
SMI
Fig. 19: Arquitectura del física monitor
EL SMI se despliega sobre un sistema totalmente independiente tanto software como
hardware que desacopla el móvil del instrumento evitando que el instrumento deba
Monitorización
65
conectarse a internet y por tanto reduciendo su exposición a posibles ataques informáticos, a
la vez queda oculto al cliente móvil. Con el fin de aumentar más la seguridad, la comunicación
entre el monitor y el instrumento quedará limitada una señal para verificar que el instrumento
está en funcionamiento y una parada de emergencia de forma que una intrusión en el SMI no
podrá causar daños al instrumento.
Por último el cliente móvil es una app que mostrará los datos recibidos desde el SMI y
permitirá crear las alertas. Las alertas serán creadas en el SMI, como se ha comentado
anteriormente, por motivos de seguridad el SMI no podrá enviar esta clase de información al
instrumento.
Comunicación instrumento-SMI La comunicación entre el instrumento y el SMI se puede crear con cualquier tipo de protocolo
de comunicación como puede ser USB, puerto serie, LAN o cualquier otra conexión disponible.
Sobre la conexión que se establezca se empleará un protocolo de datos para transferir la
información. En la prueba de concepto explicada al final de este capítulo se muestra un
sistema de mensajes sencillo y ligero con el fin de reducir el tiempo necesario para transmitir
los datos, la carga computacional y el uso de memoria. Por supuesto, en las
implementaciones se puede usar cualquier otro método como el estándar IEEE-488.2,
(Standard Commands for Programmable Instrumentation) o un sistema propietario sobre
JSON o XML. Para casos en los que el instrumento funcione en tiempo real se debe reducir el
protocolo al mínimo a la vez que emplear un sistema de comunicación que garantice la
velocidad y tiempo de respuesta de forma que el tiempo de transmisión de datos quede
acotado.
La API creada para la prueba de concepto se detalla en la Tabla 1. El protocolo consiste en una
serie de mensajes para enviar o recibir datos, alertas, patrones y actualizar el estado de las
mediciones.
Tabla 1: API de conexión instrumento-monitor
Function run by embedded device Description
getData Computer send experiment data it there is available.
getStatus
Return status of measurement application (0: no experiment in progress, 1: experiment in progress)
getExperimentsNames Get names of all experiments
startExperiment + String Start the experiment with the name written in the String
Sistema de monitorización ubicuo
66
Function run by embedded device Description
stopExperiment Stop experiment in progress
Function run by computer Description
setPattern + String Send the pattern used to represent information
setData + String… Send data following the pattern desbribeb in setPattern
sendAlert + String[2] Send an alert with two string title and description
Comunicación SMI-cliente
La comunicación entre el SMI y el cliente, requiere al menos de un protocolo reducido para su
funcionamiento en modo pasivo usando SMS. Este protocolo podrá extenderse para ofrecer
mayor funcionalidad cuando el usuario opere usando internet. Aun así en el modo activo es
interesante reducir al máximo el uso de datos. Es cierto que los móviles disponen de gran
capacidad de cálculo y que gracias a los avances de las comunicaciones móviles de 4ª
generación se dispone de un ancho de banda suficiente para transmitir gran cantidad de
datos. Sin embargo, no debemos olvidarnos de que lo móviles funcionan habitualmente con
batería, por lo que es necesario reducir en lo posible la complejidad computacional y de
comunicaciones para reducir el consumo de energía
Para nuestra prueba de concepto se ha creado una API, la cual puede ser consultada en la
Tabla 2 y la Tabla 3. Puesto que el SMI está expuesto a internet puede ser objeto de ataques,
es necesario contar con un sistema de autentificación a la vez que se cifran todas las
comunicaciones. Con el fin de evitar ataques del “hombre en medio” (Callegati, et al., 2009) es
recomendable que el monitor cuente con un certificado digital firmado por una autoridad
certificadora o que la firma del certificado se encuentre registrada en el cliente.
Es necesario ofrecer un sistema de acceso con el fin de que se identifique y registre a los
usuarios. Existen varias alternativas como el uso de certificados digitales personales, de esta
forma cuando se establece la conexión el smartphone usara el certificado digital. En la Fig. 20
se muestra un ejemplo de la secuencia de identificación usando certificados. También es
posible el uso de un usuario y contraseña aunque en este caso es altamente recomendable un
sistema de dos pasos al disponer de un cliente móvil es posible usar un SMS para verificar que
la identificación de forma transparente permitiendo que el cliente lea los SMS recibidos, como
se muestra en la Fig. 21
Monitorización
67
Usuario Cliente SMI.Internet
Identificacion()
mostrarUsuarioValido()
Identificacion(firmaCertificado)
return(usuarioValido)
SMI.Storage
verificaCertificado(firmaCertificado)
return(certificadoValido)
IniciarMonitor()
Fig. 20: Secuencia de autentificación valida usando certificado digital.
Usuario Cliente SMI.internet
identificacion(usuario, contraseña)
identificacion_paso_1(usuario,contraseña)
SMI.SMS SMI.Storage
verificadatos(usuario,contraseña)
return(usuarioValido
inicia2paso(usuario)
getTelefono(usuario)
return(telefono)
enviaSMS(telefono)
identificacion_paso_2(codigoSMS)
return(usuarioValido)
muestraUsuarioValido()
onSMSRecibido(SMS)
iniciarMonitor()
Fig. 21: Ejemplo de autentificación valida, usando dos pasos de forma transparente.
Tabla 2: API sobre internet para la conexión cliente-monitor
Function run by embedded device
Description
Sistema de monitorización ubicuo
68
Function run by embedded device
Description
setPattern + String Send the pattern used to represent information
setData + String… Send data following the pattern desbribeb in setPattern
setAlert + String[2] Send an alert with two string title and description
Function run by client Description
login + String[] Client identifies his socket using user and password
getStatus
Return status of measurement application (0: no experiment in progress, 1: experiment in progress)
getExperimentsNames Get names of all experiments
startExperiment + String Start the experiment with the name written in the String
stopExperiment Stop experiment in progress
getPendingAlert Request pending alert in server
Tabla 3: API SMS para la conexión cliente-monitor
Sms sent by client Description
getCode+String[2] Return a ramdon code
getExperimentsNames+String[2]
Get names of all experiments, it uses it user and code
startExperiment + String[3]
Start the experiment with the name written in the String. It uses it user and code
stopExperiment +String[2]
Stop experiment in progress. It uses his user and code.
Sms sent by server Description
Alert+String[2] It sends an alert with it name and it description.
Los elementos de seguridad mencionados anteriormente no pueden ser aplicados a la interfaz
SMS, en este caso se pueden ofrecer dos alternativas, una versión reducida que límite al
Monitorización
69
máximo el uso de SMS y emplearlos solo para las alertas. O una versión completa donde los
mensajes son enviados desde la aplicación. En este caso se requerirá una identificación válida
a través de internet previa. Durante esta identificación se podrá negociar una contraseña que
posteriormente se empleará para cifrar y descifrar los SMS enviados y recibidos. En caso de
que se decida a implementar la interfaz SMS sin cifrado, lo cual no es recomendable debido a
las debilidades del protocolo SMS. Se propone usar un sistema en dos pasos, en el primero el
usuario se identifica con su usuario y contraseña, como respuesta recibe un token o código
temporal, el resto de peticiones al sistema, durante un periodo de tiempo determinado las
hará empleando el token de forma que se reduce en lo posible la captación del usuario y
contraseña.
Conexiones Uno de los puntos fuertes de esta propuesta es la de emplear notificaciones, estas
notificaciones aseguran que en caso de error el usuario será alertado. Con el fin de garantizar
que el usuario siempre reciba las notificaciones SMI tiene que disponer múltiples conexiones
hacia el exterior: Ethernet, WIFI, 3g, GSM, etc. Al haber varias conexiones en caso de que una
falle el sistema podrá emplear otra que esté disponible. Para que este sistema sea eficaz, es
necesario que haya al menos dos proveedores distintos.
Con el fin de reducir costes y mejorar los tiempos de respuesta, esta propuesta impone un
sistema de prioridades de forma que en condiciones normales se opte por el uso de una red
cableada y en caso de fallo de esta se cambie a inalámbricas anteponiendo WIFI a redes
móviles, la última prioridad debería ser el uso de GSM debido a sus limitaciones.
Puesto que por norma general el cliente no dispondrá de ip fija y puede estar tras un router o
un proxy, será el cliente el encargado de establecer la conexión y mantenerla. Es cierto que los
sistemas de ahorro de energía presentes en los móviles pueden ocasionar al desconexión de
redes wifi, puede que incluso los datos 3g, no obstante el sistema GSM suelen funcionar de
forma diferente por lo que siempre está activo y por tanto se pueden recibir SMS. Otra opción
para contrarrestar estos problemas es que el cliente implemente métodos para saber cuándo
hay un experimento en marcha y durante la duración tomar acciones para evitar que las
directivas de ahorro de energía lo desconecten. Evitar el modo de ahorro energía depende de
dispositivo y sistema operativo donde funcione el cliente, no obstante puede desencadenar un
consumo excesivo de la batería, por lo que debe de usarse con precaución.
Notificaciones
El objetivo principal de este sistema es alertar a los usuarios en caso de que se produzca un
evento previamente programado o crítico. El uso de notificaciones evita que el investigador
tenga que estar pendiente constantemente de del monitor pues en caso de que ocurra algo
Sistema de monitorización ubicuo
70
una notificación avisará del evento al teléfono del usuario pudiendo este tomar las medidas
que considere oportunas.
El proceso que sigue en nuestra propuesta (Fig. 22) es el siguiente:
Fig. 22: Diagrama de flujo para las alertas
1. El instrumento informa del estado actual al SMI.
2. El SMI comprueba si los datos disparan alguna alerta o si se ha producido un evento
externo como perdida de energía.
a. Todo es correcto por lo que se retorna al paso 1.
b. Se producido un evento programado por lo que se pasa al paso 3
3. El sistema verifica las prioridades
a. En caso de que la prioridad sea notificación a través de internet se pasa al paso
4
b. En caso de usar SMS como prioridad se pasa al paso 6
4. El SMI comprueba si dispone de conexión a internet y con el dispositivo
a. En caso afirmativo pasa al paso 5.
b. En caso negativo se procede con el paso 6.
Monitorización
71
5. Notifica a través de internet el evento.
6. Verifica si dispone de cobertura.
a. En caso positivo pasa al paso 7.
b. En caso negativo pasa al caso 4.
7. Notifica a través de SMS que se ha producido un evento.
El hecho de emplear prioridades se debe a que el SMS es más fiable pues la cobertura
suele ser mejor en todos los países además que debido a la baja velocidad tolera mejor el
ruido. Sin embargo dependiendo de la situación puede ser más caro. En cambio internet
suele estar disponible en cualquier laboratorio y suele estar incluido en los gastos propios
de la universidad o empresa. De esta forma se puede regular si se reduce o no el número
de SMS. En cualquier caso nuestra propuesta cuenta con diversas formas de conexión
reduciendo la posibilidad de falta de comunicación al mínimo.
Cliente móvil
Hay dos posibilidades a la hora de crear el cliente móvil. La primera y más recomendable en un
smartphone. Debido a las características de los teléfonos inteligentes estos permiten el uso de
internet así como implementar todas las medidas de seguridad descritas anteriormente.
Igualmente estos teléfonos disponen de pantallas de gran resolución y tamaño así como ancho
de banda, memoria RAM y capacidad de cómputo suficiente para recibir datos simples o
complejos como gráficos de forma constante a la vez que los presenta de lo forma más
adecuada. Todo ello junto a una experiencia de usuario agradable. Igualmente se pueden
añadir capacidades de data-logger de forma que el usuario pueda tener todos los datos del
experimento en el móvil como copia de seguridad en caso de fallo catastrófico en el
instrumento.
Otra posibilidad es usar cualquier tipo de móvil con la interfaz de SMS, sin embargo al no
poder usar una aplicación específica los mensajes deben enviarse en texto plano, usuario y
contraseña incluidos, lo cual lo hace inseguro y por tanto no recomendable. Además este tipo
de interfaz es muy limitada y se basa en la transmisión de datos simples.
En el caso de optar por un cliente nativo móvil es necesario tener en cuenta restricciones,
como se ha comentado en puntos anteriores aunque los smartphones disponen de capacidad
de cómputo y ancho de banda suficiente, reducir el consumo de ambos puede repercutir en
una mayor duración de la batería. En estos casos se debe permitir que el teléfono entre en
estado de hibernación y comprobar las alertas regularmente, pues tenemos la seguridad de
que en caso de estar la conexión no disponible el sistema empleará la interfaz SMS.
Es recomendable que se sigan tres reglas:
Sistema de monitorización ubicuo
72
1. Después de la creación de una nueva conexión, el cliente se identificará con su usuario
y contraseña.
2. En la primera conexión y de forma regular el cliente debe comprobar que SMI dispone
del número de teléfono actualizado.
3. Cuando el móvil este en modo de ahorro de energía deben evitarse las conexiones en
lo posible.
Prueba de concepto Con el fin de demostrar la validez de esta propuesta se presenta un caso práctico desarrollado
para conectarse con Dinaten, el cual permite monitorizar experimentos para el estudio de la
tensión superficial y el ángulo de contacto en líquidos, entre los posibles experimentos están
el estudio se surfactantes, absorción de proteínas en procesos de digestión, monocapas
insolubles, etc.
Los componentes usados para la prueba de concepto son:
Beagleboard xM Rev C con Debian
Conexión Ethernet sobre usb incluida en Beagleboard xM
Tarjeta de red wifi USB con chip Railink e73
Modem GSM-3g USB Huawei e1752
Complemento software para Dinaten. Instrumento “Octopus”
Con el fin de adaptar Dinaten al SMI de nuestro caso práctico se creó un complemento en C++.
Una vez comienza el experimento Dinaten transmite los datos que mide, tensión superficial,
volumen, área, etc. al complemento añadido que los convierte al protocolo establecido de
acuerdo a la APIs presentadas en los puntos anteriores y se encarga de la comunicación vía
LAN a través de la red emulada por el USB de forma que el conector Ethernet incluido en la
Beagleboard quede disponible para las conexiones externas. Igualmente establece el puerto
de escucha para poder parar el experimento en caso de que recibir la orden de parada de
emergencia.
El SMI también está implementado en C++ empleando el framework QT por lo que es
multiplataforma, en este caso fue compilado en el propio microcontrolador para funcionar en
Linux sobre CPU ARM. Para las pruebas se dispuso de tres conexiones a internet
independientes, LAN, Wifi e internet móvil 3G controladas por el SMI a través de comandos
del terminal. Para el uso de SMS se implementaron comandos a través de libgammu (Čihař,
s.f.) y usando el mismo modem GSM. EL orden de preferencia para las conexiones es: LAN,
Wifi, 3G, y SMS. Con respecto a la seguridad se creó un certificado autoafirmado cuya clave
pública fue integrada en el cliente móvil y se inhabilitó cualquier tipo de conexión no segura. El
servidor se creó con la API de QT forzando el uso de SSL (secure sockets layer).
Monitorización
73
Una vez lanzado nuestro SMI este queda a la escucha de las actualizaciones desde el
instrumento o los mensajes desde el cliente. En el caso de actualizaciones desde el
instrumento estas quedas registradas y almacenadas, se admite un máximo de 5
experimentos, almacenados, luego se sobrescriben. Las actualizaciones también son
procesadas para, en caso de ser necesario, lanzar las alertas correspondientes. Una vez el SMI
recibe la conexión de un cliente, comprueba la identidad del usuario y entonces puede
empezar a mandar datos. En caso de alerta verificará si el socket sigue abierto, en caso
afirmativo lanzará la alerta a través de internet, en caso negativo, comprobará la cobertura y
empleará la interfaz SMS, en caso de no haber cobertura lo reintentará hasta conseguirla o
hasta registrar una conexión a internet. Este prototipo solo admite la conexión de un usuario
de forma simultánea.
El cliente móvil se ha implementado de forma nativa para Android y ha sido probado en un
HTC One X con Android 4.1.1. La elección de Android se debe a que es el sistema operativo
móvil más extendido. Además es fácil de probar en u móvil e incluso distribuirlo sin costo
extras y disponía de los conocimientos para hacer la implementación sin aprender a manejar
nuevas tecnologías.
La aplicación dispone una interfaz de usuario responsiva para cualquier dispositivo, con una
lista de las mediciones y la posibilidad de realizar gráficos para los datos. Este cliente ha sido
construido para ser genérico por lo que admite cualquier tipo de dato numérico simple para
ser representado. Una vez el usuario pulsa en el dato, se expande para mostrar otros
secundarios. Con el fin de conectar con el SMI, la app tenía almacenadas las diferentes ips para
las distintas conexiones. De esta forma iba probando una a una hasta conseguir la conexión.
Con el fin de intentar ahorra batería tal y como se ha recomendado en puntos anteriores el
cliente solo actualiza los datos desde el IMS cuando está en primer plano, cuando la aplicación
entra en segundo plano o se apaga la pantalla hay dos posibilidades: no hay experimentos en
marcha, la aplicación pasa a esta de hibernación; hay un experimento en marcha, un servicio
en segundo plano comprobará de forma regular, cada dos minutos, la conexión, si se ha
perdido tratará de reconectar, una vez lo consiga comprobará si hay alertas. En caso de
encontrar una alerta se mostrará una notificación en la barra de estado de Android como se
puede ver en la Fig. 23. En cualquier caso el servicio estará alerta para procesar cualquier SMS
que se reciba para comprobar si se trata de una alerta.
Para probar el funcionamiento se realizó un experimento a la vez que desde el móvil se
monitorizaba, posteriormente se probó el sistema de múltiples conexiones activado y
desactivando las distintas interfaces de red. Debido a las condiciones del laboratorio donde se
encuentra Dinaten no fue posible usar Ethernet, por tanto las pruebas se hicieron con WIFI, 3g
Sistema de monitorización ubicuo
74
y GSM en el SMI. En el móvil se usó WIFI y SMS. Los resultados pueden ser consultados en la
Tabla 4.
Tabla 4: Pruebas del uso de las distintas conexiones
Conexiones activas SMI
Conexiones activas móvil
La alerte se recibió usando
WIFI, 3g, GSM WIFI, GSM Internet
3g, GSM WIFI, GSM Internet
WIFI, GSM WIFI, GSM Internet
WIFI, 3g WIFI, GSM Internet
WIFI WIFI, GSM Internet
3g WIFI, GSM Internet
GSM WIFI, GSM SMS
WIFI, 3g, GSM GSM SMS
3g, GSM GSM SMS
WIFI, GSM GSM SMS
WIFI, 3g GSM SMS
WIFI GSM SMS
3g GSM SMS
GSM GSM SMS
Monitorización
75
Fig. 23: Interfaz de usuario del cliente desarrollado para el caso práctico
Introducción
76
Capítulo 5. Ínstrumentacio n mo vil
Introducción
En los capítulos anteriores hemos desarrollado formas de universalizar y facilitar el uso de
instrumentos, especialmente aquellos destinados a la medida de la tensión interfacial
empleando técnicas que permitan su uso de forma remota o la monitorización de los
experimentos de larga duración. No obstante hay otra posibilidad: el uso de un instrumento
móvil basado en smartphone con un hardware compacto fácil de transportar y barato de
fabricar.
Cada vez es más común ver instrumentos basados en móviles para realizar medidas
avanzadas, como por ejemplo procesamiento de imágenes, tratamientos de datos, diagnosis
clínicas y monitorización (Contreras-Naranjo, et al., 2016) (Uloza, et al., 2015) (Parisi, et al.,
2016) (Cierpka, et al., 2016). En los últimos años los móviles han ganado mucha capacidad
computacional, tanto con CPU multi-cores como en RAM, además los últimos dispositivos del
mercado cuentan con cámaras avanzadas.
Durante la estancia del autor de esta tesis en la Universidad de York en Toronto (Canadá), se
ha investigado en las posibilidades que pueden ofrecer los móviles para medir tensión
superficial, ángulos de contacto y medición de energía directamente sobre el propio
dispositivo móvil. Al emplear móviles podemos crear instrumentos con un costo efectivo de
producción más favorable que los sistemas usados actualmente. Combinando el móvil con
soportes de dosificación impresos en 3D se puede reducir el peso, espacio y complejidad de
instalación (Fig. 24). Los instrumentos creados a nivel de universidad como los fabricados a
nivel comercial suelen emplear cámaras cuyo costo suele estar en 750-1000€, además
necesitan un ordenador para la adquisición de imágenes y realizar los cálculos cuyo costo no
es inferior a 400€. Ambas funciones pueden ser incluidas en un Smartphone de gama media-
alta cuyo costo actual está ronda los 300-350€. Este abaratamiento junto con la reducción de
espacio conseguida con el sistema de dosificación creado (foto necesaria) y la mejora de
interfaces basadas en los estándares móviles puede facilitar su uso a nivel docente.
Instrumentación móvil
77
Fig. 24: Instrumento típico basado en el método ADSA comparado con los elementos de un Smartphone.
Además de la creación de laboratorios remotos y monitores, existe otra posibilidad que
permite universalizar el uso de instrumentos. El uso de impresoras 3D combinado con
dispositivos como los smartphone, que todo el mundo lleva en el bolsillo permite realizar
experimentos con un coste efectivo menor. En este se demuestra que es posible crear un
instrumento que funcione con soportes impresos y se ejecute en un móvil.
Adaptar los sistemas tradicionales a un móvil conlleva varios retos el más importante es la
adaptación a los diferentes tipos de móviles del mercado, ya que disponen de diferentes
tamaños de pantallas, potencia, RAM y sobretodo calidad de la cámara. Otra dificultad es las
derivada de la calibración, estos sistemas sobre todo en gota pendiente son poco tolerantes a
los errores en la calibración. Además los instrumentos tradicionales están creados para
trabajar con imágenes muy limpias generadas en un entorno más controlado que el de
nuestras pruebas de concepto, con nuestro sistema es necesario el uso del zoom digital en la
imagen, lo cual requiere el uso de diferentes mecanismos para garantizar que las medidas
tomadas sobre la imagen son precisas.
El resultado ha sido la creación de cuatro instrumentos desplegados en plataformas Android
para la medición de tensión superficial en gotas pendientes, medición de ángulo de contacto
en gotas sésil, ángulo de contacto en gotas inclinadas y medición de energía superficial.
Para probar este concepto y garantizar la calidad del sistema propuesto se han seguido
diversos pasos para comprobar todas las etapas del cálculo y verificar que el sistema es
confiable.
El primer paso ha sido la creación del núcleo de cálculo y su verificación de forma sistemática
además de probar la tolerancia a errores derivados del reconocimiento de imagen o de las
Núcleo de cálculo
78
condiciones experimentales. El segundo paso fue probar las diferentes posibilidades para el
procesamiento de imagen y resolver los problemas derivados del uso del zoom en la captura
de imágenes. Para finalizar hemos integrado el sistema y verificado su funcionamiento
comparando las medidas con las tomadas por un instrumento comercial (Drop Shape Analysis
de Krüss Machine). Esto instrumento se compone de dos partes la parte software, encargada
de realizar las medidas y la parte hardware, la cual permite fijar el móvil, la jeringa y las
superficies. Aunque el autor de esta tesis ha participado indicando sugerencias sobre el
hardware, este ha sido desarrollado por el Dr. Chen, por tanto no se describirá en esta tesis.
La información expuesta en este capítulo fue presentada en la reunión anual Adhesion
Socciety con la publicación (A. Amirfazli, 2017) y posteriormente aceptada para su publicación
en la revista Colloids and Surfaces A: Physicochemical and Engineering Aspects (Chen, et al.,
2017).
Núcleo de cálculo
El núcleo de cálculo es el subsistema empleado para hallar la tensión superficial o el ángulo de
contacto a partir de una matriz de puntos que define el perfil de la gota detectado de forma
experimental por subsistema de procesamiento de imagen. Este núcleo implementa dos
métodos de cálculo, Young-Laplace, para gotas pendientes, sésil y medición de energía y
polinomial de segundo grado para gotas sésil, inclinada y medición de energía.
El núcleo de cálculo ha sido programado para la resolución de las ecuaciones diferenciales de
Young-Laplace, Ecuación 7, usa como valores iniciales la longitud del perfil (s), 130mN/m
como tensión superficial (γ) y el diferencial de la densidad (∆ρ) y los radios R1 y R2 Fig. 25. A
partir de los datos iniciales se optimiza la distancia entre la curva teórica y la experimental
hasta alcanzar el mínimo dentro de la tolerancia marcada (10-8) tal y como se comentó en el
Capítulo 2.
𝑑𝑥
𝑑𝑠= 𝑐𝑜𝑠𝜃
𝑑𝑦
𝑑𝑠= 𝑠𝑒𝑛𝜃
𝑑𝜃
𝑑𝑠= (
1
𝑅1+
1
𝑅2) ±
∆𝜌𝑔𝑦
𝛾−𝑠𝑖𝑛𝜃
𝑥
Ecuación 7: Ecuaciones diferenciales usadas para la generación de gotas teóricas donde P es la presión de la gota, γ la tensión superficial, ∆ρ el diferencial de densidad, g la gravedad, y la coordenada en el eje de ordenadas , x la coordenada en el eje de abscisas y θ el ángulo de contacto.
Instrumentación móvil
79
Cabe destacar que se han introducido algunos cambios en la forma habitual como la indicada
en (Rıo & Neumann, 1997), en vez de optimizar todos los valores de la curva como el ángulo, la
tensión superficial, etc. de forma simultánea, primero se resuelve de forma aproximada la
curva teórica después se optimiza la posición del ápice, tras esto se optimiza y con estos datos
se realiza una optimización para obtener la medición. Con lo cual se realizan cuatro procesos
de optimización con entre una y tres variables en lugar de uno con cinco. El motivo para este
cambio es que en nuestra implementación el sistema resultante es un 66% más rápido.
Fig. 25: Representación de los radio tomados radios de la gota usados para calcular aproximadamente la presión.
En el caso de uso del método polinómico para cálculo de ángulo de contacto, se coge el 9% de
la gota a partir de la zona del contacto con la superficie y se realiza un ajuste a la curva de
segundo grado, Ecuación 8. La elección del uso de un polinomio de segundo grado y el hecho
de usar el 9% del perfil se debe las pruebas realizadas en (Chini & Amirfazli, 2011) donde
determinan que son las mejores opciones.
𝑦 = 𝑎𝑥2 + 𝑏𝑥 + 𝑐
Ecuación 8 : Ecuación polinómica de segundo grado
Si bien el método de cálculo no es ninguna novedad, su empleo en móviles si lo es, por tanto,
al ser una nueva implementación requiere una verificación a fondo con el fin de garantizar que
si el perfil detectado es bueno, el resultado será preciso. Con este fin se han realizado una
serie de pruebas que se detallarán a continuación. Con el propósito de verificar el
comportamiento del sistema con las diferentes tensiones superficiales y ángulos de contacto
R1
R2
Núcleo de cálculo
80
se ha empleado el programa ALFI (axisymmetric liquid-fluid interfaces), el cual para una
capilaridad (c) Ecuación 9 y una curvatura en el apéndice (b) general el perfil teórico de la gota
junto con los datos de tensión superficial, ángulo de contacto, superficie y volumen. Podemos
usar el perfil generado, el cual es perfecto para validar si nuestro algoritmo.
𝑐 =𝑔 ∗ ∆𝑝
𝛾
Ecuación 9: Ecuación para el cálculo de la capilaridad
Pruebas para gota pendiente
Aunque el método de Young-Laplace es el mismo, al ser distintos tipos de gotas es necesario
realizar pruebas por separado. En este apartado se realizarán las pruebas con gota pendiente y
en el siguiente con gota sessile.
Prueba 1: resolución teórica
En esta prueba se han generado perfiles con ALFI y con ODE45 para verificar que a partir de los
mismos datos obtenemos los mismos perfiles. De esta forma podemos garantizar que la
implementación de las ecuaciones de Young-Laplace es correcta. Se han generado 14 perfiles
con tensiones superficiales de 15mN/m a 80mN/m usando valores aleatoria para b. Las curvas
se componen de 100 puntos con una separación de 0.1mm. El volumen de las gotas generadas
ha variado de 4μl to 24μl.
En la Fig. 26 Fig. 26: Comparación de las gotas generadas por ALFI y ODE45. Se puede apreciar
en ejemplo de como las curvas generados por ambos sistemas son las mismas.
0
0.5
1
1.5
2
-2 -1 0 1 2
Y (
mm
)
X (mm)
Alfi vs fitDrop6 - 20 mN/m
Alfi FitDrop6
Instrumentación móvil
81
Fig. 26: Comparación de las gotas generadas por ALFI y ODE45.
Prueba 2: Optimización
En la prueba 1 se ha verificado que la implementación de las ecuaciones y su resolución para
unos datos dados es correcta. En este paso se plantea el uso del perfil provisto por ALFI como
si fuera el detectado por nuestro subsistema de procesamiento de imagen para calcular la
tensión superficial o el ángulo de contacto. Puesto que al generar los datos con ALFI tenemos
las medidas exactas para poder comparar con nuestro sistema y ver hasta qué punto es
preciso. Tal y como se aprecia en la Tabla 5, el error es mínimo.
Tabla 5: Resultados de usar nuestro sistema de optimización sobre gotas teóricas
Error medio
(mN/m)
Mediana
(mN/m)
Error Máximo
(mN/m)
0.0002 -0.0001 0.0011
En este caso disponemos de los datos de ALFI, los cuales son teóricamente perfectos, sin
embargo en cuando opere en el dispositivo, la unión de la gota con el capilar será
determinado por el usuario. Esto implica que puede haber errores si no se toma suficiente
longitud de la gota. Con el fin de calcular el porcentaje mínimo de gota necesario para
garantizar un mínimo de precisión. Para realizar estas pruebas se han tomado ocho gotas con
tensiones superficiales entre 15 y 80 mN/m y se han cortado múltiples veces hasta determinar
a partir de qué punto el error se dispara. En la Tabla 6se muestra un ejemplo de los cortes
realizados y en la Fig. 27 el perfil grafico donde el error es extremadamente alto.
Tabla 6: Series de cortes en una gota de 30mN/m
Tensión
superficial
medida
(mN/m)
Tensión
superficial
real (mN/m)
Error
(mN/m)
Altura (mm)
29.990121 30 0.009879 2.599
30.04811 30 0.04811 2.4614
30.138149 30 0.138149 2.3732
30.188068 30 0.188068 2.2871
30.085523 30 0.085523 2.1829
30.33954 30 0.33954 2.075
30.194181 30 0.194181 1.9892
30.250204 30 0.250204 1.8579
30.184287 30 0.184287 1.7682
30.521262 30 0.521262 1.6766
31.011784 30 0.811784 1.583
31.634651 30 1.034651 1.4877
Núcleo de cálculo
82
128.237644 30 98.237644 1.3906
29.289325 30 0.710675 1.2922
128.433341 30 98.433341 1.1928
125.834119 30 95.834119 1.0929
129.440837 30 99.440837 0.99303
132.770505 30 102.770505 0.89375
28.752117 30 1.247883 0.79577
Tras analizar los datos se puede ver que el sistema es bastante tolerante y que solo empieza a
dar errores cuando el perfil tomado es demasiado parecido a un círculo. Esto es normal pues si
la porción tomada es muy pequeña es muy circular, y por tanto el efecto de la gravedad es
bajo por lo que los perfiles de gotas de diferentes tensiones superficiales son muy similares,
haciendo que la optimización pueda errar. A continuación en la Tabla 7 podemos encontrar los
resultados de los cortes para las ocho gotas que se han mencionado anteriormente.
Fig. 27: Ejemplo de corte de la gota.
Tabla 7: Porcentaje del perfil mínimo para que el error se encuentre por debajo de 1mN/m.
0
0.5
1
1.5
2
2.5
3
0 0.5 1 1.5
Y (
mm
)
X (mm)
Ejemplo de corte de gotas
Alfi FitDrop6
Instrumentación móvil
83
Tensión
superficial
(mN/m)
Altura de la
gota(mm)
Mínimo
porcentaje de
la gota
15 1.9022 44.58%
20 2.176 63.90%
30 2.599 53.51%
40 2.9989 48.75%
50 3.4923 36.84%
60 3.9523 36.76%
70 3.9842 31.86%
80 4.4519 38.06%
Tomando los datos de la Tabla 7 se puede comprobar que si se cuenta con más de un 65% de
la altura de la gota los resultados son precisos, no obstante se recomienda un mínimo de un
75% con el fin de mantener un margen de error suficiente ante casos que no se hayan dado
en las pruebas de laboratorio.
Prueba 3: Rotación de la gota
Si bien los datos anteriores muestran que el algoritmo funciona correctamente cuando recibe
un buen perfil, lo más seguro es que en casos reales el perfil detectado no sea perfecto. En
estas pruebas se presenta la tolerancia a error cuando la foto no se ha tomado
completamente recta. En estos casos, el perfil estará inclinado hacia un lado.
Para esta prueba se han tomado los 750 perfiles sintéticos creados para la prueba anterior y se
han rotado 0.5º,1º, 2º, 3º y de forma aleatoria entre -3º y 3º. Una vez rotados se ha usado el
sistema de cálculo propuesto para medir la tensión superficial en cada una de las gotas. Los
resultados, Tabla 8, muestran que el sistema es robusto en este tipo de situaciones debido a
que se corrige el ángulo eficazmente durante el cálculo.
Tabla 8: Error en la medida de gotas rotadas.
Angulo Error medio
(mN/m)
Mediana
(mN/m)
Error Máximo
(mN/m)
0º 0.0002 -0.0001 0.0011
0.5º 0.00026 0.0002 0.0013
1º 0.00026 0.0002 0.0013
2º 0.00026 0.0002 0.0014
3º 0.00026 0.0002 0.0014
±3º -0.0018 0.0002 0.4566
Núcleo de cálculo
84
Prueba 4: Transformación de la gota
Con el fin de calcular correctamente la tensión superficial es necesario transformar de pixel a
milímetros en los puntos de perfil. Si la calibración tiene un problema de precisión el resultado
va a ser incorrecto. Con el fin de determinar el grado de robustez de la implementación se han
tomado las 750 gotas sintéticas que se usaron en las pruebas anteriores y se han modificado
para hacerlas más grandes, más pequeñas. Los tamaños para aumentarlas han sido: 5µm,
10µm, 15μm, 20µm y 50µm. Se han determinado estas medidas de forma experimental a
partir la calibración que se obtenía en diversas imágenes.
El método empleado para agrandarlas o reducirlas, dibujado en Fig. 28 ha sido tomar dos
puntos del perfil consecutivos p1 y p2, calcular el punto medio, pm, calcular la recta normal a la
recta que une p1 y p2 y pasa por pm, entonces se ha usado el punto pa y pr que está a distancia d
de la recta que une p1 y p2. Siendo pa y pr el punto agrandado y reducido respectivamente.
Fig. 28: Esquema del método usado para agrandar y reducir el tamaño de las gotas sintéticas.
Los resultados de esta prueba se muestran en la Tabla 9, se puede apreciar que en general y
en caso de tener que decidir usar una gota la versión agrandad es mejor que la reducida
cuando el error se encuentra por debajo de los 20µm y tomar la reducida si es mayor. Estos
resultados serán tenidos en cuenta a la hora de determinar el perfil de la gota. También es
importante tratar de hacer lo posible para reducir el error por debajo de 10µm para mantener
el error acotado dentro de términos razonables (aproximadamente 0.5mN/m).
Tabla 9: Error medido cuando la gota es agrandada o reducida
Distancia Error medio
(mN/m)
Mediana
(mN/m)
Error Máximo
(mN/m)
0µm 0.0002 -0.0001 0.0011
+5µm 0.115 0.111 0.315
-5µm -0.011 0.0005 0.203
+10µm 0.259 0.244 0.503
-10µm 0.135 0.122 0.385
+15 µm 0.312 0.307 0.777
-15 µm 0.448 0.441 0.954
+20µm 1.633 1.560 2.962
-20 µm 0.914 0.886 1.778
+50µm 2.396 2.029 5.909
pa
pr pm
p2
p1
Instrumentación móvil
85
-50µm 0.082 -0.180 4.71
Prueba 5: Aleatorización del perfil de la gota
Si bien debido a la calibración lo normal es que el perfil o se agrande entero o se reduzca en la
misma medida, puede ser que debido al sistema de procesamiento de imagen, a ruido en la
captura, o a la detección del perfil se tomen puntos que no estén exactamente en el perfil.
Para simular esta circunstancia se ha tomado cada punto del perfil y se ha movido de forma
aleatoria dentro de un rango, 5µm, 10µm, 15µm, 20µm y 50µm, y se ha procedido a calcular
la tensión superficial.
En la Tabla 10 podemos ver los resultados que son bastante mejores que en la prueba anterior
debido a que los movimientos en un pixel pueden contrarrestar los de otro. Igualmente para
mantener el error máximo en el orden de 0.5mN/m es recomendable que el error no sea
mayor de 10µm.
Tabla 10: Error medido cuando se mueven los pixeles aleatoriamente.
Distancia Error medio
(mN/m)
Mediana
(mN/m)
Error Máximo
(mN/m)
0µm 0.0002 -0.0001 0.0011
±5µm -0.069 -0.058 0.393
±10µm -0.075 -0.053 0.547
±15µm -0.073 -0.059 0.826
±20µm -0.071 -0.062 0.878
±50µm -0.113 -0.101 2.316
Pruebas para gota sésil Aunque el núcleo de cálculo es el mismo para gota pendiente que para sésil cuando se emplea
el método de Young-Laplace, es posible que no funcione igual de bien. Por ello se han repetido
las pruebas para verificar que el subsistema de cálculo es preciso. La primera prueba se omite
pues no emplea optimización.
Prueba 1: Optimización
En este caso se han tomado los perfiles sintéticos de 75 gotas entre 15mN/m y 89mN/m
generados por ALFI usando un número aleatorio, entre 0.4 y 0.8 para el parámetro b. Cada
gota ha sido cortada reduciendo su altura en 0.1mm y cada vez se ha calculado el ángulo de
contacto, las alturas de las gotas variaban de 2.1mm a 3.6mm. La serie de experimentos han
arrojado ángulos entre 20º y 145º, para un total de 2240 gotas.
Los resultados se pueden ver en la Tabla 11, podemos apreciar que los resultados son bastante
precisos.
Núcleo de cálculo
86
Tabla 11: Error detectado para el calculo de angulo de contacto
Error medio (º) Mediana (º) Error máximo (º)
0.0215 0.0112 0.7773º
Prueba 2: Rotación
Al igual que antes se han rotado las gotas sintéticas y calculado el error par a los 2240
ejemplos, para simular que pasa si la cámara o la superficie no están totalmente niveladas. En
la Tabla 12 se pueden ver los resultados. Al igual que con gotas pendientes el sistema de
cálculo es tolerante al cambio de ángulo.
Tabla 12: Error medido para el ángulo de contacto con el método de Young-Laplace cuando la gota se rota
Angulo Error
medio
(º)
Mediana
(º)
Error
máximo
(º)
Gotas con
error mayor a
1º
Gotas con
error mayor a
2º
0º 0.02 0.011 0.777 0 0
1º 0.043 0.024 0.976 0 0
2º 0.043 0.024 0.976 0 0
3º 0.044 0.023 0.99 0 0
±3º 0.050 0.039 1.1 3 (0.001%) 0
Prueba 3: Transformación de la gota
Al igual que en gota pendiente, la calibración puede afectar al cálculo de por lo que se ha
procedido a agrandar y reducir de la misma forma que se hizo en la prueba 4 de gota
pendiente. Teniendo en cuenta los datos empíricos obtenidos donde la calibración indicaba
que en nuestro sistema un pixel representa generalmente menos de 1010µm se decidió
prescindir de hacer los experimentos cuando los puntos del perfil se agrandan o reducen en
50µm. Como se aprecia en la Tabla 13, en este caso también es mejor contar con gotas más
agrandadas que reducidas.
Tabla 13: Error en el cálculo de ángulo de contacto cuando la gota se agranda o reduce.
Distancia Error
medio
(º)
Mediana
(º)
Error
máximo
(º)
Gotas con
error mayor a
1º
Gotas con
error
mayor a 2º
+0µm 0.02 0.011 0.777 0 0
+ 5µm 0.302 0.256 1.173 11 (0.4911%) 0
+ 10µm 0.346 0.353 1.085 5 (0.22%) 0
+ 15µm 0.387 0.345 1.290 66 (2.95%) 0
+ 20µm 0.510 0.384 2.089 276 (12.32%) 16 (0.71%)
- 5µm 0.385 0.358 2.116 58 (2.59%) 0
- 10µm 0.812 0.776 2.16 500 (22.32%) 2 (0.09%)
Instrumentación móvil
87
- 15µm 0.790 0.773 2.208 861 (38.44%) 7(0.31%)
- 20µm 0.970 0.935 2.208 1053(47%) 128 (5.71%)
Prueba 4: Aleatorización de los puntos del perfil de la gota
Una vez más hemos procedido como en el caso de gota pendiente, tomando cada punto del
perfil sintético y variando su posición de forma aleatoria dentro de una distancia determinada,
5µm, 10µm, 15 µm y 20 µm. Los resultados se muestran en la Tabla 14. Como en casos
anteriores es preciso tratar de evitar un error mayor a 10µm en la detección del pixel que
compone el perfil.
Tabla 14: Error medido cunado los puntos se mueven aleatoriamente.
Distancia Error
medio
(º)
Mediana
(º)
Error
máximo
(º)
Gotas con
error mayor a
1º
Gotas con
error
mayor a 2º
+0µm 0.02 0.011 0.777 0 0
± 5µm 0.337 0.289 2.891 38 (1.69%) 4 (0.17%)
± 10µm 0.416 0.348 2.825 120 (5.37%) 9 (0.4%)
± 15µm 0.548 0.404 3.411 260 (11.60%) 47 (2.09%)
± 20µm 0.860 0.471 3.673 465 (20.76%) 176 (7.86%)
Resumen de las pruebas
En este punto podemos asumir que el sistema de cálculo es fiable y preciso. Asimismo es
tolerante a fallos que se puedan producir en pasos anteriores, aunque obviamente, los errores
en el perfil obtenido van a conllevar una disminución de la precisión del instrumento. Por
tanto serán necesarias ciertas medidas con el fin de aportar el perfil más
Procesamiento de imágenes
Con el fin de encontrar el perfil de la gota, que nos permita realizar el cálculo empleando el
subsistema explicado en el punto anterior, es necesario procesar las imágenes tomadas por la
cámara. Este procesamiento se realiza en dos partes:
Segmentación de la imagen.
Detección de perfil.
Procesamiento de imágenes
88
Fig. 29: Imagen original de la gota
Como hemos visto en el estado del arte, hay diversos métodos para realizar la segmentación.
Es normal el uso de métodos de detección de bordes como Canny o Sobel como en Dinaten.
Estos métodos funcionan muy bien debido a que se usa una luz homogénea de fondo que
satura el sensor creando un gran contraste entre la gota y el fondo. Podemos ver como a partir
de la Fig. 29 tomada en con una cámara <modelo> cómo al usar Canny, Fig. 30, el perfil queda
muy claro y es fácil de encontrar disminuyendo la posibilidad de error.
Fig. 30: Captura de gota procesada usando Canny
La calidad de la imagen Fig. 30, se puede obtener, generalmente, en los sistemas que
implementan ADSA que usan cámaras CCD específicas para uso industrial y de investigación
con zoom óptico. Sin embargo, nuestro sistema tiene una peculiaridad, al usar la cámara
integrada en el smartphone es necesario emplear zoom digital para obtener una imagen
suficientemente grande de la gota que evite problemas de calibración. El problema está en
que el zoom digital introduce ruido en la imagen de forma que los métodos de segmentación
no funcionan adecuadamente. En ejemplo se obtiene al procesar la Fig. 31, si usamos el
Instrumentación móvil
89
método Canny con umbrales automáticos como en Fig. 30 obtenemos la Fig. 32 en la cual es
casi imposible encontrar el perfil de la gota de forma automática, pero incluso si forzamos a
que tenga que ser el usuario el que decida para cada imagen, lo mejor que podemos obtener
queda representado en Fig. 33, podemos probar también con Sobel, Fig. 34, en cualquier caso
no es fácil determinar dónde está el perfil de la gota. Esto se produce porque al actuar el zoom
digital y crear pixeles en base a los vecinos crea información que afecta al funcionamiento de
los métodos basados en bordes.
Fig. 31: Imagen original obtenida con LG G4
Procesamiento de imágenes
90
Fig. 32: Imagen procesada con Canny usando umbrales automáticos
Fig. 33: Imagen procesada con Canny usando umbrales manuales
Fig. 34: Imagen procesada con Sobel
Visto esto se probaron otros sistemas que permitieran trabajar incluso cuando trabajamos con
zoom. Debido a limitaciones temporales se probaron tres tipos diferentes de segmentación, el
método Otsu, basado en multi-thresholding, el método k-means, basado en clustering, y el
método statistical region merging (SRM). Para verificar cual funcionaba mejor se tomaron
varios ejemplos en los cuales se analizó una línea de pixeles en la zona donde se encuentra el
Instrumentación móvil
91
perfil de la gota, se realizaron varios cortes para ver el funcionamiento en varios sectores en la
Fig. 35 se muestran los sectores escogidos. En la Fig. 36 está representado un ejemplo
característico, en él se puede apreciar que tanto Canny como SRM ofrecen varios puntos
candidatos separados por lo que no es sencillo determinar cuál compone el perfil ni seguirlo.
En cambio OTSU y k-means ofrecen un sistema más sencillo de seguir y una forma más fácil de
encontrar la gota, además disponemos de varios pixeles por lo que podemos decidir en base a
la evaluación del sistema de cálculo cual debemos de usar. Debido al rendimiento se decidió
que Otsu para incluirlo en nuestro sistema. Podemos ver la imagen representada en Fig. 31
una vez procesada con Otsu en la Fig. 37.
Fig. 35: Cortes producidos en la gota para verificar el funciónenlo de cada método.
En la Fig. 37 podemos ver que todavía hay ruido, no obstante el perfil de la gota es fácilmente
reconocible.
Una vez disponemos de una imagen intermedia creada con el método Otsu, podemos definir
el perfil de la gota. Para encontrarlo partimos de las posiciones aproximada de los punto de
contacto con la superficie o el capilar aportados por el usuario. A partir de ahí buscamos el
posible punto de contacto más cercano al dado por el usuario. Una vez disponemos de ambos
candidatos, y si la gota es sésil, buscamos si el capilar está insertado en la gota, si es así
buscamos los puntos de contacto gota-capilar. Una vez tenemos todos los datos necesarios,
partimos del punto de contacto izquierdo y empleando un sistema de máscaras, Fig. 38,
Procesamiento de imágenes
92
seguimos el perfil hasta llegar al punto derecho o encontrar el capilar. Si se encuentra el
capilar se repetirá el proceso de búsqueda desde el punto derecho hasta el capilar. Hay que
destacar que el sistema de máscaras se basa en la posición actual y la posición anterior para
definir los posibles candidatos. En caso de que entre los posibles candidatos no se encuentre
una valido, se amplía con nuevos candidatos, si aun así no se encuentra, se toma la dirección
anterior y se vuelve a probar, si tras cinco intentos no se encuentra un candidato valido, el
algoritmo se para e indica que no ha encontrado el perfil de la gota.
Fig. 36: Ejemplo representativo del funcionamiento de los diferentes métodos para un corte determinado
Fig. 37: Imagen procesada usando Otsu
0
50
100
150
200
250
300
0 20 40 60 80 100
Inte
nsi
ty
Pixel
G4 zoom - Cut 2 - Y=3003
Canny
Original
k-means
Otsu
srm
Instrumentación móvil
93
Fig. 38: Mascaras usadas para encontrar el perfil de la gota
Pendant, sessile, tilted y energy
Llegados a este punto se dispone de un sistema de procesamiento de imagen funcional y un
núcleo de cálculo sólido, por tanto se disponen de las herramientas necesarias para el
desarrollo de las apps que usando la cámara del móvil podrán medir los diferentes valores
físicos propuestos, tensión superficial, ángulo de contacto, etc. Para adecuarnos a las distintas
necesidades se han creado cuatro apps:
Pendant: App destinada al cálculo de la tensión superficial, área y volumen de una gota
pendiente usando las ecuaciones de Young-Laplace.
Sessile: Instrumento para calcular el ángulo de contacto y opcionalmente el área y
volumen en gotas sésiles usando las ecuaciones de Young-Laplace o el ajuste
polinómico.
Tilted: Sistema para hallar el ángulo de avance y retroceso de una gota sobre una
plataforma inclinada usando ajuste polinómico.
Energy: Aplicación que mide la energía libre de una superficie con el uso de entre uno
y tres líquidos diferentes tras medir el ángulo de contacto y usando las aproximaciones
de Neumann, Oss and Good, Y Fowkes todos explicado en el apartado ¡Error! No se
encuentra el origen de la referencia..
En estos casos es apropiado llamar al resultado instrumento pues además del software se
dispone de un hardware Fig. 39, creado por el equipo del Prof. Amirfazli del departamento de
ingeniería mecánica de York University.
Pixel anterior
Pixel actual
Candidatos a siguiente pixel
Candidatos a siguiente
pixel extendido
Automatización
94
Fig. 39: Hardware para la realización de experimentos
El software mencionado se ha desarrollado en Android y está programado usando diversas
herramientas. El núcleo de cálculo y el método de Otsu se han implementado en Matlab y
convertido a C usando la herramienta Matlab Coder, el resto del software ha sido programado
en Java.
Se optó por Android por la diversidad de dispositivos que se puede encontrar en el mercado
con este sistema operativo, puntos a su favor fue el hecho de que permite desarrollar,
desplegar y distribuir aplicaciones sin necesidad de ningún pago ni control externo. En el caso
de las implementaciones en Matlab se debe a que dispone de muchas herramientas
matemáticas para cálculo y procesamiento de imagen, este software tiene muy buena
reputación, funciona correctamente y está muy optimizado. Con el uso de la herramienta
Matlab Coder es muy sencillo transformar el código a C, lenguaje conocido entre otras cosas
por su velocidad de ejecución, y que se puede compilar en Android usando el Native
Develoment Kit (NDK) e integrar con el código Java usando Java Native Interface (JNI).
El uso de smartphone aporta nuevas capacidades como el uso de los sensores del móvil para
determinar la inclinación del dispositivo. Como se ha visto en las pruebas, si la foto se toma
con cierto ángulo puede afectar negativamente al resultado. Por tanto podemos evitar que el
usuario pueda tomar una foto si el ángulo es excesivo, igualmente si sabemos el ángulo exacto
en el que está la cámara podemos rotar la imagen para corregirlo y obtener un mejor
resultado.
Automatización
Aunque debido a la interfaz y al estado de desarrollo de la app, la automatización disponible
es limitada, durante el desarrollo se ha procedido a seguir las indicaciones de arquitectura
expresadas en el Capítulo 2 así pues se ha definido una clase basada en Runnable que admite
Instrumentación móvil
95
en su construcción una lista de Object que obviamente deberá procesar. Así mismo se dispone
de un planificador simple que decide cuando se ejecuta las tareas. Actualmente se dispone de los siguientes procesos y fases:
Captura.
o Captura
o Guardado de imagen
Procesamiento de imagen
o Pre-procesamiento
o Detección de perfil
Calculo de los valores físicos.
Por ahora la automatización está limitada a dos posibilidades la captura de imágenes múltiples
y el recalculo de todos a parte de las imágenes de un proyecto. El planificador funciona tal y
como se ha explicado en el apartado ¡Error! No se encuentra el origen de la referencia..
Emplea varias hebras, en la versión actual hasta cuatro, una específica para la captura de
imágenes, y un pool de tres hebras para procesamiento, es capaz de definir temporización
para la toma de imágenes múltiples, así como retrasar los procesos de procesamiento y
calculo cuando el heap de Java está saturándose y evitar que dos fases de pre procesamiento
se ejecuten simultáneamente, esto último se debe a que se pueden producir condiciones de
carrera. Cabe destacar que utiliza las funciones de Android para modificar el estado de
hibernación del dispositivo manteniéndolo activo incluso si el usuario apaga la pantalla. En el futuro con el hardware de dosificación motorizado que se encuentra en desarrollo se
ampliaran las funciones automatizadas que permitirán tares más complejas como la captura a
la vez que se realizan cambios en el volumen de la gota.
Pruebas
Con el fin de probar la app completa (Sessile y Pendant) se han realizado una serie de pruebas
comparando los resultados del instrumento móvil propuesto en este trabajo con el
instrumento Drop Shape Analyzer 100E (DSA100E) de Krüss Machine. Para evitar diferencias
de medida debidas a contaminaciones, errores humanos, alteración de las superficies, etc. se
procedió de la siguiente forma:
Se situó el instrumento aquí presentado en perpendicular el DSA-100. Fig. 40
Los experimentos fueron llevados a cabo por dos personas de forma que se sincronizo
entre ambos la toma de la imagen.
Pruebas
96
Este procedimiento tiene como resultado que se han tomado las imágenes sobre la misma
gota en el mismo instante (dentro del margen de un segundo).
Fig. 40: Esquema representativo de la situación de los experimentos vista desde arriba
Para gota pendiente se ha probado la aplicación Pendant usando tres líquidos diferentes y
comparando los resultados con los obtenidos en DSA. Los fluidos usados han sido: agua,
etilenglicol y dodecano, los resultados se muestran en Tabla 15. Tras analizar los resultados no
se han encontrado diferencias significativas, por lo que queda comprobado que el instrumento
presentado en estas tesis funciona adecuadamente para el caso de gota pendiente.
Tabla 15: Comparación de resultados entre el instrumento Pendant y DSA-100E
Liquid Drop Tensión superficial LG 4 (mN/m)
Tensión superficial DSA-100E (mN/m)
Dodecano 1 24.63±0.107 24.59±0.054
Dodecano 2 23.08±0.18 23.30 ±0.016
Dodecano 3 23.38±0.34 23.24±0.13
Etilenglicol 1 47.29±0.061 47.29±0.11
Etilenglicol 2 47.51±0.21 47.27±0.083
Etilenglicol 3 47.34±0.31 47.12±0.151
Agua 1 72.40±0.229 72.22±0.178
Agua 2 72.47±0.123 72.14±0.442
Agua 3 72.38±0.22 72.64±0.133
Liquid Drop Tensión superficial Nexus 5 (mN/m)
Tensión superficial Nexus 5 (mN/m)
Dodecano 4 23.12±0.092 23.14±0.050
Dodecano 5 23.19±0.075 23.16±0.078
Dodecano 6 23.42±0.187 23.33±0.064
Etilenglicol 4 47.35±0.278 47.72±0.287
Etilenglicol 5 47.64±0.229 47.76±0.531
Etilenglicol 6 47.14±0.21 47.08±0.129
Agua 4 72.34±0.257 72.28±0.100
Instrumentación móvil
97
Agua 5 72.51±0.144 72.30±0.288
Agua 6 72.18±0. 111 72.38±0.229
Con el fin de verificar el comportamiento del instrumento aquí presentado midiendo ángulos
de contacto, se realizó una prueba con tres series de gotas de agua en diferentes superficies:
cristal, polietil-metacrilato (PEMA), superficie de polímero (PS), teflón y una superficie súper
hidrofóbica (SHS).
Tabla 16: resultados de la medida de diferentes gotas de agua sobre cristal
Sessile DSA-100E
Cristal Método Ángulo izq. (º)
Ángulo dcho. (º)
Ángulo izq. (º)
Ángulo dcho. (º)
1 Young-Laplace
28.34 28.34 28.1 28.1
1 Polinomial 33.49 26.1 29.8 24.9
2 Young-Laplace
27.1 27.1 27.5 27.5
2 Polinomial 29.42 32.3 27.4 27.7
3 Young-Laplace
27.86 27.86 28.2 28.2
3 Polinomial 24.34 34.18 27.2 27.6
Tabla 17: Medidas de ángulo de contacto de tres gotas de agua sobre PEMA
Sessile DSA-100E
PEMA Método Ángulo izq. (º)
Ángulo dcho. (º)
Ángulo izq. (º)
Ángulo dcho. (º)
1 Young-Laplace
76.88 76.88 76.4 76.4
1 Polynomial 78.8 73.16 75 74.5
2 Young-Laplace
75.3 75.3 74.4 74.4
2 Polynomial 75.85 77.27 71.9 71
3 Young-Laplace
74.93 74.93 74.4 74.4
3 Polynomial 76.31 70.5 74 71.9
Tabla 18: Ángulo de contacto para tres gotas en superficie PS
Sessile DSA-100E
PS Método Ángulo izq. (º)
Ángulo dcho. (º)
Ángulo izq. (º)
Ángulo dcho. (º)
1 Young- 88.3 88.3 88.4 88.4
Pruebas
98
Laplace
1 Polinomial 85.66 89.09 86.2 85.3
2 Young-Laplace 87.6 87.6 87.9 87.9
2 Polinomial 87.58 90.71 87.1 85.8
3 Young-Laplace 88.68 88.68 88.2 88.2
3 Polinomial 84.85 88 85.7 85.2
Tabla 19: Medidas de tras gotas sobre teflón
Sessile DSA-100E
Teflon Método Ángulo izq. (º)
Ángulo dcho. (º)
Ángulo izq. (º)
Ángulo dcho. (º)
1 Young-Laplace 124.75 124.75 125.6 125.6
1 Polinomial 122.79 121.76 122.3 121.7
2 Young-Laplace 123.29 123.29 123.8 123.8
2 Polinomial 122.57 124.21 119.2 122.2
3 Young-Laplace 127.25 127.25 126.8 126.8
3 Polinomial 127.37 127.86 128.2 122.8
Tabla 20: Resultados de las medidas sobre SHS
Sessile DSA-100E
SHS Método Ángulo izq. (º)
Ángulo dcho. (º)
Ángulo izq. (º)
Ángulo dcho. (º)
1 Young-Laplace 144.62 144.62 145.4 145.4
1 Polinomial 141.59 141.4 141.8 139.2
2 Young-Laplace 162.22 162.22 145.4 145.4
2 Polinomial 142.34 143.8 141.8 139.2
3 Young-Laplace 168.75 168.75 169.1 169.1
3 Polinomial 150.02 154.59 158.5 155.4
Al analizar los gráficos anteriores podemos ver que no hay una diferencia estadística
significativa ya que el propio DSA tiene un error de ±0.3º. Se ha probado el método de ajuste
polinomial y optimización de ecuaciones de Young-Laplace.
Instrumentación móvil
99
En este documento no se presentan resultados de gota inclinada, esto se debe a que no es
posible realizar este tipo de experimentos con ambos sistemas simultáneamente y puesto que
la disposición de la gota puede alterar la geometría de la gota en caso de diferencias de
medidas, no sería posible determinar a qué se debe. No obstante en el caso de gota inclinada
se usa el método polinomial el cual ha sido debidamente verificado y por tanto la medida será
correcta.
Tras analizar los resultados presentados se puede confirmar que el instrumento y que es
posible el uso de móviles para el desarrollo de instrumentación científica.
Conclusiones
100
Capítulo 6. Conclusiones y trabajos futuros
Conclusiones
A partir del trabajo realizado en esta tesis se ha contribuido al campo de la instrumentación
aportando nuevos métodos y técnicas para trabajar con sistemas de instrumentación de alta
precisión que requieren una supervisión continuada durante la realización de experimentos
durante largos periodos de tiempo, y en particular para los tensiómetros/goniómetros que
permiten la medida precisa de la tensión superficial y el ángulo de contacto, entre otros.
Para ello, se han trabajado con varias soluciones en cinco niveles:
1. Mejora de la automatización incluyendo nuevas arquitecturas y métodos para
programar y ejecutar experimentos garantizando la reproducibilidad a nivel de
instrumento y evitando errores humanos. Al tiempo que sienta las bases para que el
uso remoto y la monitorización puedan operar con sistemas de tiempo real.
2. Se ha desarrollado un framework, RVLab, que facilita la construcción de laboratorios
remotos de forma que los usuarios puedan acceder de forma ubicua a los instrumentos
y realizar experimentos como si estuvieran en el laboratorio.
3. La definición de un sistema de monitorización ubicua para el seguimiento del progreso
de los experimentos en cualquier parte a través del uso de dispositivos móviles y recibir
alertas en caso de que algo no vaya como debería, permitiendo que el investigador
pueda abandonar el laboratorio durante experimentos largos.
4. El uso de la automatización que se detalla en esta memoria, junto a los componentes
de RVLab y el monitor descrito, permiten que instrumentos que requieren de tiempo
real sean usados incluso cuando se emplean redes como internet. Esto se debe a que
en esta propuesta se emplean las herramientas de RVLab para programar
experimentos en un entorno sin tiempo real para luego ejecutarlos en el sistema de
tiempo real. En el caso de la monitorización, al introducir un componente intermedio el
instrumento puede funcionar a tiempo real sin verse afectado por comunicaciones no
acotadas en el tiempo.
5. Se ha creado un tensiómetro/goniómetro portable que se usa directamente en el móvil
y dispone de un hardware compacto y ligero para la realización del experimento en
cualquier ubicación, y no necesariamente en el laboratorio. Todo esto se consigue sin
renunciar a la precisión de instrumentos más grandes y pesados.
Conclusiones y trabajos futuros
101
Estas soluciones han definido nuevos métodos que mejoran el uso de la instrumentación
científica al tiempo en que la hacen más accesible.
En esta tesis se han propuesto soluciones conceptuales válidas para la mayoría de
instrumentos, no obstante se ha hecho un especial énfasis en los tensiómetros/goniómetros
con el fin de probar nuestras hipótesis y aplicar los conocimientos generados en un campo
concreto, pues el ámbito de la instrumentación científica es muy extenso.
Trabajo futuro
En el futuro cercano la investigación del autor de esta tesis se centrará en la mejora del
software del instrumento móvil así como la creación de un nuevo software denominado
Constrained para gotas cautivas con el fin de su lanzamiento al mercado. No obstante queda
mucho que investigar como nuevos métodos de procesamiento de imagen más rápidos y
precisos que Otsu, el uso de esta nueva filosofía de instrumentación móvil aplicándola a otros
experimentos en el campo de la física y mecánica de fluidos o la investigación en la mejora de
la arquitectura de automatización propuesta. No obstante aún queda mucho por investigar y
descubrir en el campo de la instrumentación remota con el fin de que realmente se empiece a
aplicar más que en casos particulares completando el framework de servidor propuesto
añadiéndole capacidades para la creación de clientes de forma sencilla y multiplataforma
incluyendo móviles y Tablet. En este aspecto sería interesante añadir funcionalidades para
automatización con el fin de definir una suite que permita desarrollar un LVR completo de la
forma más sencilla y rápida posible. En este ámbito nuevas propuestas dirigidas a la
monitorización podría ser más fáciles y rápidas de aplicar en el futuro.
Lista de publicaciones
Título: Surface Tension Measurement with a Smartphone using a Pendant Drop (In Press) Revista: Colloids and Surfaces. A, Physicochemical and Engineering Aspects Año: 2017 Autores: Huachen, Chen; Muros-Cobos, Jesús Luis; Holgado-Terriza, Juan Antonio; Amirfazli, Alidad Índice de impacto (ISI): 2.174 Índice de impacto (SCImago): 0.797 Cuartil (SCImago): Q2 Título: Distributed Service-Based Approach for Sensor Data Fusion in IoT environments Revista: Sensors Año: 2014 Volumen: 14 Número: 10
Lista de publicaciones
102
Página inicial: 19200 Página final: 19228 Autores: Rodríguez-Valenzuela, Sandra; Holgado-Terriza, Juan Antonio; Gutiérrez-Guerrero, José Miguel; Muros-Cobos, Jesús Luis Índice de impacto (ISI): 2.245 Índice de impacto (SCImago): 0,645 Cuartil (SCImago): Q2 Título: Bile salts at the air-water interface: Adsorption and desorption Revista: COLLOIDS AND SURFACES B-BIOINTERFACES Año: 2014 Volumen: 120 Número: Página inicial: 176 Página final: 183 Autores: Maldonado-Valderrama, Julia; Muros-Cobos, Jesús Luis; Holgado-Terriza, Juan Antonio; Cabrerizo-Vílchez, Miguel Ángel Índice de impacto (ISI): 4.152 Índice de impacto (SCImago): 1,215 Cuartil (SCImago): Q1 Título: A Componentizable Server-Side Framework for Building Remote and Virtual
Laboratories Revista: INTERNATIONAL JOURNAL OF ONLINE ENGINEERING Año: 2012 Volumen: 8 Número: 4 Página inicial: 43 Página final: 51 Autores: Muros-Cobos, Jesús Luis; Holgado-Terriza, Juan Antonio Índice de impacto (SCImago): 0,19 Cuartil (SCImago): Q3
Título de la aportación: Contact Angle Measurement: The Big Instrument versus Small Instrument Nombre del congreso: Annual Meeting of Adhesion Society Año: 2017 Lugar: St. Petersburg, FL, COSTA MESA, CA, USA Autores: Amirfazli, Alidad; Muros-Cobos, Jesús Luis; Chen, Huachen Título de la aportación: Redes de Sensores I2C Inteligentes Nombre del congreso: XXIV Jornadas de Concurrencia y Sistemas Distribuidos Año: 2016 Lugar: Granada, España
Conclusiones y trabajos futuros
103
Autores: Gutiérrez-Guerrero, José Miguel; Holgado-Terriza, Juan Antonio; Muros-Cobos, Jesús Luis; Pomboza, Gonzalo Título de la aportación: Towards sustainability in multi-modal urban planners Nombre del congreso: International Conference on Connected Vehicules and Expo Año: 2014 Lugar: Viena, Austria Autores: Baena-toquero, Manuel; Muros-Cobos, Jesús Luis; Rodríguez-Valenzuela, Sandra; Holgado-Terriza, Juan Antonio Título de la aportación: Desarrollo de sistemas industriales a través de sistemas empotrados basados en Java Nombre del congreso: IV Jornadas de Computación Empotrada Año: 2013 Lugar: - Madrid, España Autores: Gutiérrez-Guerrero, José Miguel; Muros-Cobos, Jesús Luis; Rodríguez-Valenzuela, Sandra; Damas-Hermoso, Miguel Título de la aportación: Monitoring experiments using mobile devices Nombre del congreso: 2013 IEEE International Conference on Computational lntelligence and Virtual Environments for Measurement Systems and Applications Año: 2013 Lugar: Milán, Italia Autores: Muros-Cobos, Jesús Luis; Cabrerizo-Vílchez, Miguel Ángel Título de la aportación: Data Fusion Mechanism based on a Service Composition Model for the Internet of Things Nombre del congreso: Actas de las III Jornadas de Computación Empotrada Año: 2012 Lugar: Elche, España Autores: Rodríguez-Valenzuela, Sandra; Holgado-Terriza, Juan Antonio; Muros-Cobos, Jesús Luis; Gutiérrez-Guerrero, José Miguel Título de la aportación: RVLab: A server-side framework to build remote and virtual laboratories Nombre del congreso: 9th International Conference on Remote Engineering and Virtual Instrumentation Año: 2012 Lugar: Bilbao, España Autores: Muros-Cobos, Jesús Luis; Holgado-Terriza, Juan Antonio Título de la aportación: The OCTOPUS: a new subphase multi-exchange pendant drop tensiometer for in-vitro digestion studies Nombre del congreso: 5th International Workshop BUBBLE AND DROP INTERFACES
Lista de publicaciones
104
Año: 2012 Lugar: Krakow, Polonia Autores: Maldonado-Valderrama, Julia; Cabrerizo-Vílchez, Miguel Ángel; Holgado-Terriza, Juan Antonio; Muros-Cobos, Jesús Luis Título de la aportación: Java para el Desarrollo de Sistemas Empotrados Nombre del congreso: II Jornadas de computación Empotrada Año: 2011 Lugar: Granada, España Autores: Holgado-Terriza, Juan Antonio; Rodríguez-Valenzuela, Sandra; Muros-Cobos, Jesús Luis
Conclusiones y trabajos futuros
105
Bibliografí a
A. Amirfazli, J. M. C. H. C., 2017. Contact Angle Measurement: The Big Instrument versus Small
Instrument. St. Petersburg, FL, USA, Ann. Meeting of Adhesion Soc..
Adamson, A. W., Gast, A. P. & others, 1967. Physical chemistry of surfaces.
Ahene, A. y otros, 2014. Automation Practices in Large Molecule Bioanalysis:
Recommendations from Group L5 of the Global Bioanalytical Consortium. The AAPS Journal,
Jan, Volumen 16, pp. 164-171.
Ai, W. & Chen, C., 2011. Green house environment monitor technology implementation based
on android mobile platform. s.l., s.n., pp. 5584-5587.
Al-Faris, A. Q., Ngah, U. K., Isa, N. A. M. & Shuaib, I. L., 2014. Computer-Aided Segmentation
System for Breast MRI Tumour using Modified Automatic Seeded Region Growing (BMRI-
MASRG). Journal of Digital Imaging, Volumen 27, pp. 133-144.
Anand, R., Kumar, G. A. & Murthy, S., 2012. Mitter; Bitter monitoring system using Android
smartphoneś. s.l., s.n., pp. 1-4.
Andújar, J. M. & Mateo, T. J., 2010. Diseño de Laboratorios Virtuales y/o Remotos. Un Caso
Práctico. Revista iberoamericana de autom\'atica e inform\'atica industrial, Volumen 7, pp. 64-
72.
Anon., s.f. Matlab Consultado el 12 de Diciembre de 2011, s.l.: s.n.
Arthur, C. L. y otros, 1992. Automation and optimization of solid-phase microextraction.
Analytical Chemistry, Volumen 64, pp. 1960-1966.
Bencomo, S. D. & Medina, F. T., 2010. Introducción a la Sección Especial de Laboratorios
Virtuales y Remotos en Automática: Realizaciones y Experiencias. Revista iberoamericana de
autom\'atica e inform\'atica industrial (RIAI), Volumen 7, pp. 5-9.
Beucher, S. & Lantuejoul, C., 1979. Use of watersheds in contour detection. s.l., s.n.
Bilefsky, D., 2017. Hackers Use New Tactic at Austrian Hotel: Locking the Doors. The New York
Times, 30 Enero.
Bojanic, D. C. & Rosen, L. D., 1994. Measuring Service Quality in Restaurants: an Application of
the Servqual Instrument. Hospitality Research Journal, Volumen 18, pp. 3-14.
Lista de publicaciones
106
Bourbeau, P. P. & Ledeboer, N. A., 2013. Automation in clinical microbiology. Journal of clinical
microbiology, Volumen 51, pp. 1658-1665.
Broisin, J., Venant, R. & Vidal, P., 2017. Lab4CE: a Remote Laboratory for Computer Education.
International Journal of Artificial Intelligence in Education, Mar, Volumen 27, pp. 154-180.
Cabezas, M. G., Bateni, A., Montanero, J. M. & Neumann, A. W., 2006. Determination of
Surface Tension and Contact Angle from the Shapes of Axisymmetric Fluid Interfaces without
Use of Apex Coordinates. Langmuir, Volumen 22, pp. 10053-10060.
Callegati, F., Cerroni, W. & Ramilli, M., 2009. Man-in-the-Middle Attack to the HTTPS Protocol.
IEEE Security \& Privacy.
Canessa, E., Fonda, C. & Radicella, S. M., 2002. Virtual laboratory strategies for data sharing,
communications and development. Data Science Journal, Volumen 1, pp. 248-256.
Canny, J., 1986. A Computational Approach to Edge Detection. IEEE Transactions on Pattern
Analysis and Machine Intelligence, Nov, Volumen PAMI-8, pp. 679-698.
Castignani, G., Derrmann, T., Frank, R. & Engel, T., 2015. Driver Behavior Profiling Using
Smartphones: A Low-Cost Platform for Driver Monitoring. IEEE Intelligent Transportation
Systems Magazine, Spring, Volumen 7, pp. 91-102.
Charland, A. & LeRoux, B., 2011. Mobile Application Development: Web vs. Native. Queue,
#apr#, Volumen 9, pp. 20:20--20:28.
Chen, H., Muros-Cobos, J. L., Holgado-Terriza, J. A. & Amirfazli, A., 2017. Surface Tension
Measurement with a Smartphone using a Pendant Drop. Colloids and Surfaces A:
Physicochemical and Engineering Aspects , pp. - .
Chen, H., Tang, T. & Amirfazli, A., 2015. Effects of surface wettability on fast liquid transfer.
Physics of Fluids, Volumen 27, p. 112102.
Chen, X., Song, G. & Zhang, Y., 2010. Virtual and remote laboratory development: A review.
Honolulu, s.n., pp. 3843-3852.
Chen, Z. y otros, 2013. Unobtrusive sleep monitoring using smartphones. s.l., s.n., pp. 145-152.
Chini, S. F. & Amirfazli, A., 2011. A method for measuring contact angle of asymmetric and
symmetric drops. Colloids and Surfaces A: Physicochemical and Engineering Aspects, Volumen
388, pp. 29-37.
Choi, K. y otros, 2009. A Combined Virtual and Remote Laboratory for Microcontroller.. s.l.,
s.n., pp. 66-76.
Conclusiones y trabajos futuros
107
Cicirelli, F. y otros, 2006. MADAMS: A software architecture for the management of networked
measurement services. Comput. Stand. Interfaces, April, 28(4), pp. 396-411.
Cierpka, C., Hain, R. & Buchmann, N. A., 2016. Flow visualization by mobile phone cameras.
Experiments in Fluids, Volumen 57, pp. 1-10.
Čihař, M., s.f. Gammu and Wammu - libgammu. [En línea]
[Último acceso: 03 Septiembre 2017].
Coleman, G. B. & Andrews, H. C., 1979. Image segmentation by clustering. Proceedings of the
IEEE, Volumen 67, pp. 773-785.
Contreras-Naranjo, J. C., Wei, Q. & Ozcan, A., 2016. Mobile Phone-Based Microscopy, Sensing,
and Diagnostics. IEEE Journal of Selected Topics in Quantum Electronics, May, Volumen 22, pp.
392-405.
Couteur, P. L., 2009. Review of Literature on Remote & Web-based Science Labs. BCCampus
Articulation, p. 22.
del Castillo-Santaella, T. y otros, 2014. Improved digestibility of β-lactoglobulin by pulsed light
processing: a dilatational and shear study. Soft matter, Volumen 10, pp. 9702-9714.
Ehrmann, C. H. & Engel, A. E., 1979. A General-Purpose System for Data Acquisition and
Instrument Control. Nuclear Science, IEEE Transactions on, aug. , Volumen 26, pp. 4459-4467.
Eick, S. G., Mockus, A., Graves, T. L. & Karr, A. F., 1998. A Web laboratory for software data
analysis. World Wide Web, 1(2), pp. 55-60.
Eparvier, F. G., Chamberlin, P. C., Woods, T. N. & Thiemann, E. M. B., 2015. The Solar Extreme
Ultraviolet Monitor for MAVEN. Space Science Reviews, Dec, Volumen 195, pp. 293-301.
Evtushenko, G. S. y otros, 2014. Laser monitor for non-destructive testing of materials and
processes shielded by intensive background lighting. Review of Scientific Instruments, Volumen
85, p. 033111.
Faour, G., Grimaldi, M., Richou, J. & Bois, A., 1996. Real-Time Pendant Drop Tensiometer Using
Image Processing with Interfacial Area and Interfacial Tension Control Capabilities. Journal of
Colloid and Interface Science, Volumen 181, pp. 385-392.
Feng, X., Qian, J., Sun, Z. & Wang, X., 2010. Wireless Mobile Monitoring System for Tram Rail
Transport in Underground Coal Mine Based on WMN. s.l., s.n., pp. 452-455.
Lista de publicaciones
108
Ferrera, C., Montanero, J. M. & Cabezas, M. G., 2007. An analysis of the sensitivity of pendant
drops and liquid bridges to measure the interfacial tension. Measurement Science and
Technology, Volumen 18, p. 3713.
Feyyisa, J. L., Daniels, J. L. & Pando, M. A., 2017. Contact angle measurements for use in
specifying organosilane-modified coal combustion fly ash. Journal of Materials in Civil
Engineering, Volumen 29.
Fourment, M. & Gillings, M., 2008. A comparison of common programming languages used in
bioinformatics. BMC Bioinformatics, Volumen 9, p. 82.
Fowkes, F. M., 1964. Attractive Forces at Interfaces. Industrial and Engineering Chemistry,
Volumen 56, pp. 40-52.
Future digital scientific, 2017. Future digital scientific - OCA 15EC. [En línea]
Available at: http://fdsc.com/portfolio/oca-15-ec/
Gamma, E., Helm, R., Johnson, R. & Vlissides, J., 1995. Design Patterns. Boston(MA): Addison-
Wesley.
Gomes, V. G., Choy, B., W.Barton, G. & Romagnoli, J. A., 2000. Web-Based Courseware in
Teaching Laboratory-Based Courses. Global J. Eng. Education, Volumen 4, pp. 65-71.
Good, R. J. & van Oss and Carel, J., 1992. The Modern Theory of Contact Angles and the
Hydrogen Bond Components of Surface Energies. En: M. E. Schrader & G. I. Loeb, edits.
Modern Approaches to Wettability: Theory and Applications. Boston(MA): Springer US, pp. 1-
27.
Grosclaude, E., Luro, F. L. & Bertogna, M. L., 2008. Grid virtual laboratory architecture. Berlin,