martes, 30 de abril de 2013

[Lab RT] Actividad 9: Ahorro de energía (Lectura)



Para ésta semana continuamos con los temas de lecturas científicas, ahora el tema es referente a ahorro de energía, el documento seleccionado fue:

...


An Energy-Efficient MAC Protocol with Random
Listen-Sleep Schedule for Wireless Sensor Networks

Sung-Chan Choi∗ , Jang-Won Lee∗ , Yeonsoo Kim† , Hakjin Chong†
∗ Dept. of Electrical and Electronic Engineering, Yonsei University, Seoul, Korea
† Future Technology Laboratory, KT, Seoul, Korea

...

Resumen

En el paper, se prope un protocolo MAC que hace uso eficiente de la energía para redes de sensores inalámbricos. Puesto que los nodos sensores utilizan energía de una batería, reducir el consumo de energía es un tema crítico para prolongar la vida útil de la red.
Para resolver este problema, se utiliza un ciclo de escucha-espera conocido como S-MAC, lo que permite a los nodos apagar su transceptor durante un período de espera. En S-MAC, los nodos sensores tienen un ciclo fijo de actividad y un calendario sincronizado en un clúster virtual. Por lo tanto, en la S-MAC, no es fácil adaptar una variación del entorno de red. Por otra parte, debido a la programación sincronizada, las colisiones de transmisión aumentarán resultando en el desperdicio de energía y de bajo rendimiento. Para hacer frente a tales ineficiencias en S-MAC, se propone un sensor de probabilidad MAC (PS-MAC), en el que cada nodo determina su estado, "escuchar" o "sueño", basado pseudo-aleatoriamente en su propia probabilidad de activación previa y las probabilidades de pre-wakeup de su nodos vecinos en cada intervalo de tiempo. Esto permite que el programa de escucha-dormir mantega cada par transmisor-receptor sincronizado mientras que el del resto de los nodos puede ser asincrónico. Por lo tanto, las colisiones pueden reducirse incluso bajo condiciones de tráfico pesado que resultan en la reducción de desperdicio de energía y el logro de un alto rendimiento. Además, ya que la probabilidad de pre-activación de cada nodo se puede ajustar la adaptación al cambio del entorno de red, mediante el ajuste de forma dinámica probabilidades pre-wakeup de nodos de sensores, el rendimiento del sistema puede ser mejorado aún más.


Introducción


Las redes de sensores inalámbricos tienen diversas aplicaciones, tales como el monitoreo del clima, animales o plantas, el seguimiento de objetivos en campo de batalla, y los edificios o infraestructuras de observación para la defensa. En general, los nodos sensores se hacen funcionar con una pequeña
batería que tiene una cantidad limitada de energía y que no puede ser fácilmente recargada o reemplazada. Por lo tanto, en el sensor inalámbrico redes, reducir el consumo de energía de cada nodo sensor es una de las cuestiones importantes para prolongar la vida de la red.
En un nodo sensor, el consumo de energía se produce en el transceptor cuya utilización está controlada un protocolo de control (MAC).

En la capa MAC, hay varias fuentes principales de desperdicio de energía. La primera de ellas es la escucha ociosa, lo que ocurre cuando un nodo se convierte en el receptor a pesar de que no hay datos para transmitir o recibir. Se ha estudiado que el consumo de energía durante el estado inactivo de escucha es comparable al consumo durante el estado de recepción. La segunda
uno está oyendo, que se produce cuando un nodo recibe y decodifica los paquetes que no estén destinados a la misma. El tercero es una overemitting, que se produce cuando el nodo transmisor transmite un paquete, mientras que el nodo receptor no está preparado para recibir. la última fuente importante de desperdicio de energía es de colisión, que se produce cuando hay transmisiones simultáneas de varios nodos que están dentro del alcance de la interferencia del nodo receptor. 

Para reducir los desperdicios de energía, se propondrán algunos protocolos MAC para redes de sensores inalámbricos.
Estos protocolos se pueden clasificar como:
  • Los protocolos basados en programación suelen utilizar protocolos TDMA, en el que cada nodo sensor  se le asigna uno de los intervalos de tiempo y se puede comunicar sólo en  el intervalo de tiempo asignado. Protocolos basados ​​en TDMA son libres de contención, y por lo tanto, no hay desperdicio de energía causada por  colisiones. Sin embargo, generalmente no es fácil diseñar un sencillo  algoritmo para la asignación de ranura de tiempo, debido a un gran número de nodos sensores y la falta de la unidad central. Además, se requiere sincronización de tiempo elaborada para corregir temporización error causado por la deriva del reloj.
  • Los protocolos basados ​​en contención no son libres de colisiones. Sin embargo, debido a su simplicidad y escalabilidad, se prefieren en la práctica. Hasta el momento, muchos de estos protocolos tienen como objetivo reducir el consumo de energía. S-MAC es uno de los protocolos MAC mejor conocidos por su eficiencia energética en redes de sensores inalámbricos. Adopta una ciclo periodico de escucha-espera para reducir el tiempo de escucha ociosa. Cada nodo apaga su transceptor de radio en un período de espera. Despierta en un período de escucha y puede comunicarse con otros nodos. Este período de escucha se utiliza para el intercambio de paquetes de control tales como SYNC, RTS, CTS y ACK y paquetes de datos. Por otra parte, puesto que cada nodo tiene un ciclo de trabajo fijo, S-MAC no puede adaptarse a la variación de los entorno de red.
Se propone un nuevo protocolo MAC con el concepto de 'escuchar' y 'esperar' para reducir el plazo escucha ociosa. Sin embargo, en contraste con la técnica de sincronizado y la técnica de escucha-espera de otros protocolos, en la propuesta los periodos de escuchar y esperar están determinados pseudoaleatoriamente en las probabilidades de pre-wakeup. Esto permite que el protocolo MAC propuesto operar en un modo asíncrono entre los diferentes pares de transmisor y receptor de nodos. Esto da como resultado un trafico uniformemente distribuido a través de intervalos de tiempo y la reducción de las colisiones.

2. Diseño propuesto



El protocolo MAC propuesto se conoce como "Sensor de Probabilidad MAC (PS-MAC).
PS-MAC es un protocolo de tiempo segmentado como S-MAC. Sin embargo, a diferencia de S-MAC, en el que todos los nodos tienen ciclos de escucha sincronizados y periódicos, y el mismo ciclo de espera, en el protocolo propuesto los pares de nodos transmisor y el receptor tienen ciclos escucha asíncronos y no periódicos y horarios de espera.
Para decidir entre escuchar o esperar en cada segmento de tiempo, cada nodo sensor hace uso de un generador de números pseudoaleatorios y determina su decisión según su probabilidad de preactivación y el número de semillas. Aunque cada nodo sensor determine de manera autónoma su periodo de escucha-espera, los nodos no pueden conocer el de nodos vecinos y podría haber un problema de overemitting que es causada por la la transmisión de paquetes cuando el nodo receptor está todavía en la
modo de suspensión. Para hacer frente a esta situación, los nodos vecinos intercambian sus probabilidades de preactivación y números de semillas. esto permite a cada nodo de saber la programación nodos vecinos, que se llama "programa de pre-activación", ya que en generador pseudo-aleatorio la secuencia generada es una secuencia determinista que depende del número de semillas. Basándose en su propio programa de pre-activacion y en el de sus vecinos, cada nodo determina su tiempo de escucha real y su tiempo de espera por la elección de un intervalo de tiempo como un modo de escucha si tanto algunos de sus nodos vecinos y sí está en el modo de escucha en ese intervalo de tiempo.

Algoritmo


1. Programa de preactivación


El algoritmo consta de dos etapas:
  1. Determinación del programa de preactivación
  2. Determinación de programa de activación real.
Cada nodo i tiene su propio número de semillas Seedi que se utiliza para generar una secuencia de números pseudo-aleatorios y probabilidad de preactivacion Pi. Cada nodo determina su programa de preactivación en función de su número de semillas y la probabilidad preactivación.
En primer lugar, en cada intervalo de tiempo t, cada nodo i genera un número Ui(t) entre 0 y 1 mediante con el uso de su generador pseudo-aleatorio y su número de semillas. El nodo establece la variable P Li (t) para el intervalo de tiempo t como:
$$ P L_{i} \left ( t \right ) = \begin{cases} & 1 \text{ if } U_{i} \left ( t \right ) \leq P_{i} \\ & 0 \text{ otherwise } \end{cases} $$
Basandose en P Li (t), el nodo i determina su programa de preactivación. Si P Li (t) = 1, el nodo i permanece en el modo de escucha en el intervalo de tiempo t , y si P Li (t) = 0, el nodo i permanece en el modo de suspensión en el intervalo de tiempo t.

La figura 1 ilustra un ejemplo de programación de pre-activación de dos nodos diferentes, el nodo 1 y el nodo 2; ambos tienen la misma probabilidad de pre-activación P1 = P2 = 0.3. Cada número en cada intervalo de tiempo representa un número generado pseudoaleatoriamente según el número de semillas de cada nodo. Desde que el programa de preactivación de cada nodo se determina (pseudo) al azar, cada nodo tiene un horario preactivación asincrónica en PS-MAC.


Después de determinar su programa de preactivación, cada nodo determina su programa de activación real basado en su propio horario preactivación y el de sus vecinos. Cada nodo i determina Lij (t) para cada nodo j su vecino en el intervalo de tiempo t  comparando su horario preactivación y el de preactivación del nodo j de la siguiente manera:
$$ L_{ij} \left ( t \right ) = \begin{cases} & 1 \text{ if } P L_{i} \left ( t \right ) = P L_{j} \left ( t \right ) \\ & 0 \text{ otherwise } \end{cases} $$

Por lo tanto, si Lij (t) = 1, entonces el nodo i y el nodo j se encuentran en modo escucha en sus programas de pre-activacion. Por lo tanto, el nodo i y el nodo j son capaces de comunicarse entre sí en el intervalo de tiempo t si Lij (t) = 1. Por lo tanto, en el programa de activación real, el nodo i esta en modo de escucha, si Lij (t) = 1 para alguno de sus vecinos nodo j.

2. Programa de activación real

El programa de activación de nodo i se determina mediante la realización de este procedimiento para cada uno de sus nodos vecinos. La figura 2 muestra programación de activación real entre el nodo 1 y el nodo 2. En la figura 1, el nodo 1 está en el modo de escucha en intervalos de tiempo de 1, 4,
y 9, y el nodo 2 en las ranuras de tiempo 4, 9, y 10. Por lo tanto, los nodos 1 y 2 estan en el modo de escucha en intervalos de tiempo de 4 y 9 en su programas de activación reales y se pueden comunicar uno con el otro en aquellos intervalos de tiempo.

3. Evaluación del desempeño

3. Topología de la simulación

Se utiliza el simulador NS-2 para las pruebas. Suponemos que la PS-MAC tiene formación SYNC-RTS-CTS como en S-MAC y que el número de semillas y la probabilidad de activación de cada nodo se transmite al vecino los nodos a través de un paquete SYNC. En esta simulación, 15 nodos están desplegados en un círculo regularmente, como se ilustra en la figura. 4. el nodo receptor está situado en el centro de un círculo cuyo radio es 50 metro. Cada nodo en la línea de un círculo transmite paquetes a el nodo receptor. El tiempo de ejecución de la simulación es de 1000 segundos.
Cada nodo sensor en la red experimental tiene un nivel inicial de energía de 100 joules. Un nodo consume una potencia de 500 mW en la transmisión de paquetes, 300 mW en la recepción y de 50 MW en el estado de reposo. Los parámetros del sistema son:

Transmit Power0.5 W
Receive Power0.3 W
Idle Power0.05 W
Radio Transmission Range250 m
Radio Interference Range550 m
Packet Length50 bytes

Para el modelo de tráfico, se utiliza tráfico UDP / CBR. La probabilidad de preactivación de cada nodo PS-MAC se ajusta para que sea 0.3.

4. Consumo de energía total de S-MAC y PS-MAC

La figura 4 muestra el consumo total de energía en comparación con el paquetetiempo entre llegadas. Como se muestra en esta figura, cuando el intervalo de tiempo de llegada es más de 20 segundos, PS-MAC está consumiendo menos energía quee S-MAC. Sin embargo, cuando el tiempo entre llegadas es
menos de 20 segundos, PS-MAC consume más energía que la S-MAC. Esto se debe a una situación de carga de tráfico pesado, el cual resulta en colisiones de paquetes graves en S-MAC. Cuando una colisiónse produce en S-MAC, el nodo emisor realiza al azar un retroceso y regenera el paquete RTS. Sólo después de que el nodo emisor recibe una respuesta de paquete CTS desde el nodo receptor, se transmiten los paquetes. Sin embargo, si aumentan las colisiones, es más probable que los paquetes RTS sólo se transmiten en lugar de la secuencia completa RTS-CTS-DATA-ACK. Por lo tanto, el número de paquetes transmitidos disminuye y S-MAC tiene menos energía el consumo.

5. Proporción de entrega de paquetes de S-MAC y PS-MAC


La figura 5 muestra comparación ente las proporciones de la entrega de paquetes en diferentes intervalos de tiempo. La relación de la entrega de paquetes se define como la relación entre el número de paquetes recibidos con éxito a la de los paquetes transmitidos. Como se muestra en esta figura, PS-MAC tiene una relación de la entrega de paquetes más alto que S-MAC en todas las situaciones.
Por otra parte, cuando el tiempo entre llegadas es inferior a 30 segundos, PS-MAC es mucho mejor que el S-MAC. Esto sucede debido al programa de sincronización en S-MAC, lo que resulta en una gran número de colisiones en situaciones de carga de tráfico pesado. Sin embargo, en PS-MAC, debido a la programación asíncrona los tiempos de escucha-espera entre cada par de nodos, el número de colisiones disminuye proporcionando una relación de entrega de paquetes más alta.

6. Eficiencia energética de PS-MAC relativa a S-MAC

La figura 6 muestra la eficiencia energética de PS-MAC relativa a S-MAC. Se muestra el consumo de energía por paquete transmitido con éxito para cada protocolo. Como se muestra en esta figura, PS-MAC tiene mejor rendimiento que el S-MAC. Por otra parte, como el tráfico cargas se vuelven más pesados​​, PS-MAC proporciona una mayor eficiencia energética que S-MAC. Este resultado nos dice que en S-MAC, el desperdicio de energía es mucho más grande en situaciones de carga más pesadas debido a la mucho mayor número de colisiones en comparación con PS-MAC.



Conclusión

Como se puede ver en los experimentos, me parece que el método propuesto es bastante bueno, ya que, establecer periodos donde los nodos permanecen activos y después entran en espera o dormidos parece ser una solución bastante simple y lógica, que mejor forma de ahorrar energía que apagar los nodos cuando no están haciendo nada.
Como ya puede leer, el único detalle es el establecimiento de dichos intervalos de escucha-espera, ya que se hace de forma pseudoaleatoria, pienso que en este aspecto aún se puede mejorar más. Es de esperarse que en condiciones de tráfico pesado el modelo propuesto se comporte un poco peor, pues los periodos de espera son pseudoaleatorios, una distribución pseudoaleatoria obvio no corresponde al comportamiento real del tráfico en una red, por lo que los nodos pueden entrar en espera aún cuando realmente deben estar despiertos porque la red se los exige. Lo bueno es que este método se puede adaptar a las condiciones de cada red modificando las probabilidades y el número de semillas.
Sin embargo, los experimentos demuestran que el modelo propuesto es mejor a uno ya existente por lo que se puede decir que el experimento fue exitoso.
Como trabajo adicional se puede experimentar con los diferentes parámetros para establecer las probabilidades reales de preactivación que proporcionen resultados mejores en condiciones de congestión alta.


Referencias

An Energy-Efficient MAC Protocol with Random

Listen-Sleep Schedule for Wireless Sensor Networks

Sung-Chan Choi∗ , Jang-Won Lee∗ , Yeonsoo Kim† , Hakjin Chong†
∗ Dept. of Electrical and Electronic Engineering, Yonsei University, Seoul, Korea
† Future Technology Laboratory, KT, Seoul, Korea

** Imágenes tomadas del respectivo paper.

[RT] Tarea 5: Control de congestión

Para ésta semana se tuvieron que realizar las siguientes 3 actividades:

"Desarrollen para ns-2/3 un módulo que permite
  • Crear topologías
  • Generar “patrones” tráfico 
  • Comparar por lo menos dos diferentes esquemas de control de congestión (inventados por ustedes mismos, no anden googleando ni por ideas ni por código)"

1. Crear topologías y habilitar métodos de ruteo


Código que permite crear topologías de tipo:

  • Estrella
  • Anillo
  • Malla
  • Scale-Free
  • Small-World


Además poder habilitar diferentes métodos de ruteo unicast, multicast y adhoc



2. Generar tráfico

Código que permite generar tráfico sobre UDP o TCP, se puede configurar para seguir distintos patrones y distribuciones de probabilidad para hacerlo más realista.



3. Esquemas de control de congestión

Para el control de congestión, diseñe 2 esquemas muy simples, los cuales detectan una congestión basándose si hay o no pérdida de paquetes y la medida que toman para controlar la congestión es controlar la tasa de transferencia directamente.
Los esquemas se comportarían de la siguiente forma:

  • El primero necesita evaluar primeramente las condiciones de consumo de banda ancha, por eso en una primera etapa comienza con una tasa de transferencia pequeña que aumenta linealmente en pasos iguales. Si no se detecta ninguna pérdida entonces la tasa de transferencia comenzara a aumentar exponencialmente, al doble del paso anterior en cada tiempo, hasta llegar al tope de la cantidad de banda ancha disponible para esa conexion. Cuando se detecte la primera pérdida de paquetes entonces la tasa de transferencia cae hasta un 10%, después todo el proceso comienza de la misma forma, los paquetes perdidos se reenvian al estilo fast-retransmit en la primera oportunidad. Con esto espero que las colas de paquetes se vacíen un poco antes de volver a transmitir a la misma eficiencia que antes.
Comportamiento esperado


  • El segundo comienza con un aumento progresivo en la tasa de transferencia, evaluando las condiciones de la red y el consumo mientras aumenta. La tasa de transferencia esta acotada por el máximo de banda ancha disponible, así que, conforme la tasa de transferencia se acerca al tope, esta comienza a frenarse poco a poco, digamos que se comporta como una gráfica logarítmica. Si se detecta una pérdida de paquetes entonces la tasa de transferencia cae un 30% y vuelve a aumentar de la misma forma que antes. De la misma manera, se espera que las colas de datos se vacíen un poco antes de volver a enviar datos. La recuperación también es rápida adoptando los esquemas de fast-recovery y fast-retransmit de los protocolos TCP.
Comportamiento esperado




Sin embargo, la implementación de los esquemas de control de congestión están muy apegados al diseño de los llamados agentes (que suelen representar protocolos de capa 4 [TCP, UDP]).
La correcta implementación requiere tener conocimientos de programación C++ y si es posible, creación de patches para modificar el código existente en NS-2 en partes específicas.
Dentro de la carpeta donde descomprimimos NS-2 habrá una carpeta con el nombre ns-2.35, dentro se  encuentran ordenados por carpetas los diferentes protocolos disponibles.
Si queremos crear un nuevo esquema, agente o protocolo, debemos crear su carpeta ahí y dentro crear por lo menos 2 archivos:

  • Header (*.h): Que como sabemos, en C++ contiene la estructura del nuevo agente, los métodos y atributos.
  • Código (*.cc): Que contiene el desarrollo de los algoritmos necesarios para manipular las colas de datos, tablas de ruteo, estructuras de los paquetes, mensajes, timers, etcétera. Aqui es donde se implementa todo el código.
El tutorial escrito Marc Greis en http://www.isi.edu/nsnam/ns/tutorial/index.html indica de forma precisa como implementar un nuevo agente, en éste caso, emulando a PING.

El tutorial escrito por Elmurod A. Talipov en http://elmurod.net/en/index.php/archives/157 indica la forma de agregar los nuevos agentes a NS-2 y modificar ciertos archivos para recompilar el código fuente y que estén disponibles para las simulaciones con TCL.

Sin embargo, traté de seguir el tutorial con los ejemplos ahí incluidos y terminaba rompiendo el código fuente de NS-2, además de recibir múltiples mensajes de error al correr el makefile.


Referencias

lunes, 29 de abril de 2013

[Lab CU] Actividad 9: Sugerencias para pruebas de usabilidad


Habiendo escuchado la clase de los compañeros sobre las pruebas de usabilidad, redactaremos la retroalimentación de los proyectos junto con algunas sugerencias sobre cómo mejorar los mismos en cuanto a requerimientos.

...

Casa segura (Rene, Raúl, Iván)

La prueba del "hombre detrás de la cortina" estuvo bastante bien ejecutada, fue buena idea realizar sus bocetos en papel para simular la interfaz terminada.

Una recomendación adicional es terminar la interfaz real para probar el comportamiento de los diversos componentes y si interactúan de la forma esperada. Con ello pudieron haber integrado pruebas heurísticas.

Además la inclusión de alguna encuesta o entrevista para responder a aspectos más específicos de su proyecto también hubiera sido muy buena opción.
Y por último, finalizar un prototipo real para hacer pruebas de usabilidad más reales, además de la interfaz para realzar pruebas de usabilidad de la misma.

...

Garage Inteligente (Emmanuel, Max, Carmen, Victor)


Buen proyecto.

Las pruebas de usabilidad fueron variadas y buenas, y la aplicación del framework complementó muy bien y ayudó a comprender mejor a los usuarios.

Sin embargo, en cuanto a las pruebas de usabilidad con el prototipo pienso que se quedaron algo cortos, si bien el prototipo, al ser a escala, no fue el apropiado para probar todas las funcionalidades al 100%, se pudieron haber preparado algunas pruebas tipo "hombre detrás de la cortina" para que los usuarios interactuaran con el mismo.
Para ello pudieron haber probado un prototipo de las diferentes interfaces de acceso, además de pruebas a las interfaces visuales en el smartphone y el servidor.

Las evaluaciones heurísticas pudieron haber servido para diseñar mejor los escenarios ya que les permiten medir el comportamiento del sistema al cambiar el contexto.
Por último, evaluar su prototipo ante condicioens extremas, por ejemplo, fallas en la conexión a internet o en la alimentación eléctrica.

Esas son mis observaciones y sugerencias.

...

Bloqueo mágico de computadora (Obed, Ave, Pedro, Jona)


El proyecto va muy bien y las pruebas de usabilidad me parecieron buenas.
Una prueba de usabilidad buena es haber hecho una prueba de comodidad, ahora se centran solo en la curva de aprendizaje de su sistema, si fue fácil o difícil, si fue rápido o lento, pero no en la comodidad del usuario, una simple pregunta, ¿qué tan cómodo resulto utilizar el sistema?
Para ello pudieron además preparar una prueba de observación mientras el usuario utilizaba el sistema para realizar notas de su comodidad según ustedes cómo lo notaran.

También una preparación de pruebas tipo hombre detrás de la cortina, donde simularán alguna situación más avanzada para el usuario, como si el prototipo ya estuviera en sus fases finales.

Como recomendación adicional, agreguen un sensor de proximidad para detectar cuando el usuario se aleja y determinar una distancia máxima y mínima de detección.
Además complementen su algoritmo, se me ocurre por ejemplo, que detecten los ojos del usuario y hagan track de los mismos, así  cuando ambos ojos dejen de ser detectados (si el usuario gira la cabeza por ejemplo) entonces que el sistema detenga el video, y con el sensor, si el usuario se aleja, que bloquee la pantalla.

Esas son mis recomendaciones

...

Galeria Inteligente (Blanca, Vanessa, Adriana, Rodolfo)


La prueba quedo algo simple para el verdadero alcance de su proyecto, no sabía que su vitrina permanecería en negro mientras ningún usuario se acerque, una recomendación, no lo hagan así ya que en un museo los visitantes suelen acercarse si la obra llama su atención desde que le dan un vistazo lejano, no creo que los visitantes quieran acercarse obra por obra para ir descubriendo que hay ocultas en sus vitrinas.
Según lo que leí sobre su proyecto, al acercarse el usuario, la obra comenzaría a reproducir la descripción de la misma.

Por otro lado, las pruebas con los usuarios estuvieron bien enfocadas, solo falta orientarlas mas a lo que realmente sería su proyecto.
Otras pruebas que les recomiendo son las propias del prototipo, evaluar su comportamiento bajo diferentes condiciones, de iluminación y de detección de objetos. Es importante verificar si su proyecto se comporta de la manera esperada en dichas condiciones.

El proyecto me parece bien, es sencillo por lo que creo con las pruebas realizadas se cubre perfectamente el alcance del mismo

...

Alarma de automóvil (Alex, Ricardo, Sergio, Roberto)


Con el prototipo listo pudieron haber realizado más pruebas de diferentes tipos, pudieron haber analizado el aspecto de la interfaz por ejemplo.
Otra prueba de usabilidad que pudieron realizar es simplemente la observación, durante la sesión de focus group se pudo haber observado el comportamiento de los usuarios mientras utilizaban el sistema, ya fuera el móvil o el de escritorio, y a partir de ahí complementar los datos obtenidos durante la entrevista realizada a los usuarios.

Otro ejemplo de pruebas de usabilidad que pudieron haber realizado son las pruebas heurísticas y verificar si realmente el sistema hace lo que debe de hacer bajo ciertas condiciones de uso.
Las pruebas heurísticas también aplican para los diferentes componentes de sus sistema.

...

Localizador Bluetooth (Omar, Saúl Isaías)


Pienso pudieron haber puesto más énfasis en el prototipo, el recorrido cognitivo estuvo bastante bien, por lo menos bien planeado, también noto que tienen bien establecidas las funciones de su aplicación.
También sen nota que tenían muy bien diseñadas las pruebas, pero todo quedo en hipótesis sobre los resultados que pudieron haber sido.

Algo bien simple, las pruebas tipo "hombre detrás de la cortina", pruebas con sketches, dibujos o bocetos, todo eso pudo servir para realizar pruebas con usuarios y verificar el verdadero sentir de ellos con el sistema. Después lo típico, una serie de preguntas al usuario sobre la curva de aprendizaje, la facilidad de uso, posibles mejoras, qué opciones quitar, etcétera.
Todas las pruebas sustentadas con algo de observación para complementar los apuntes obtenidos en las entrevistas o encuestas.

Y por último, las pruebas heurísticas con su prototipo, si el comportamiento del mismo es el esperado bajo diferentes situaciones, posibles errores y opciones de mejora.

En fin, en cuestiones de pruebas pienso que mis sugerencias cubren lo básico para hallar problemas y oportunidades de mejora en su proyecto.

...

Oficina Inteligente (Lupe, Osvaldo, Triana, Esteban)


El proyecto va bien, pero solo mostraron las pruebas de una parte del mismo.
Para aumentar el alcance de sus pruebas pudieron haber utilizado distintos escenarios y pruebas de tipo "hombre detrás de la cortina", evaluar el desempeño de su proyecto no solo al abrir las puertas, sino de cada una de las alarmas que quieren implementar, cómo se lanzarían las alarmas, cómo se detendrían.

También recomiendo realizar pruebas heurísticas debido a que en el sistema son reconocibles varias etapas, entonces se puede evaluar el comportamiento del sistema en sus diferentes etapas y ver como el sistema se comporta.

Pienso que falto también la implementación de una interfaz sencilla de control para los usuarios que administren el sistema, y así realizar pruebas sobre la misma, heurísticas y de colores por ejemplo.
Por ahora pues pueden ignorar las recomendaciones que el usuario haga del prototipo pues recordemos que aún faltan los procesos necesarios de miniaturización.

Buen proyecto, son todas las recomendaciones

...

Despertador inteligente (Ramón, Cecy, Roberto)


La evaluación heurística resulto un poco limitada, pienso se puede ampliar más análizando los componentes de la interfaz propuesta bajo distintas condiciones.

En cuanto a las pruebas tipo "hombre detrás de la cortina" pienso que estuvieron muy bien aplicadas y se evaluaron muy bien los posibles escenarios del mismo.

En cuanto al diseño del prototipo, pienso se pudieron realizar también pruebas heuristicas del mismo, por ejemplo, qué pasa si el bluetooth no esta activado o si un sensor se desconecta, qué pasa si la fuente de alimentación es retirada o si la batería (en caso de requerirla) tiene poca carga
También sería bueno realizar pruebas de usabilidad de la interfaz propuesta, los colores sobre todo, pienso no sería muy cómodo que la pantalla esté en blanco total a las 5 de la madrugada a menos que se quiera dejar ciego al usuario. Pruebas simples con colores, y diferentes layouts.

Por último, el análisis de tareas también estuvo bien ejecutado, siempre es bueno análizar los posibles escenarios para detectar fallas en la secuencia de las tareas.

Esas son mis sugerencias y observaciones

...


Esas fueron mis observaciones y recomendaciones para los demás proyectos.

jueves, 25 de abril de 2013

[IT] Extra points: Dictionary based encoding

Un método de codificación que encontré para está actividad se llama Byte-Pair encoding.

Es uno de los métodos por diccionario más simples que existen.

El procedimiento es muy simple, cuando se encuentran un par de bytes consecutivos y ducho par se repite varias veces en el texto, entonces dicho par de bytes es reemplazado por un byte que no se éste utilizando.
El algoritmo se detiene cuando ya no hay más pares de bytes consecutivos.
Es necesario almacenar el diccionario para poder recuperar la información

Ejemplo 


Codificación

Iniciamos con una cadena de caractéres, con un largo aleatorio, por ejemplo

dcbdbdababdbacbbdabaaaacacacaa


Nuestro alfabeto sería:

 alpha = [a,b,c,d]

Por lo que tenemos los bytes desde "e" hasta "z" si quitamos los caractéres de control y signos de puntuación.

Comienzamos a recorrer la lista para buscar por pares de caractéres:

Iteración 1: Encontramos el par que más se repite bd, asignamos un byte no utilizado:

bd : e

Identificamos:

d c b d b d a b a b d b a c b b d a b a a a a c a c a c a a
     e   e                     e

Sustituimos:

d c e e a b a b d b a c b e a b a a a a c a c a c a a

Iteración 2: Encontramos el par que más se repite ab, asignamos un byte no utilizado:

ab : f

Identificamos:

d c e e a b a b d b a c b e a b a a a a c a c a c a a
         f   f               f

Sustituímos:

d c e e f f d b a c b e f a a a a c a c a c a a

Iteración 3: Encontramos el par que más se repite ca, asignamos un byte no utilizado:

ca : g

Identificamos:

d c e e f f d b a c b e f a a a a c a c a c a a
                                   g   g   g
Sustituímos:

d c e e f f d b a c b e f a a a a g g g a


Iteración 4: Encontramos el par que más se repite aa, asignamos un byte no utilizado:

aa : h

Identificamos:

d c e e f f d b a c b e f a a a a g g g a
                           h   h

Sustituímos:

d c e e f f d b a c b e f h h g g g a


Iteración 5: Encontramos el par que más se repite, aqui encontramos varios pares que se repiten solo una vez (ee, ff, hh, gg), asignamos un byte no utilizado a cada una:

ee : i
ff : j
hh : k
gg : l

Identificamos:

d c e e f f d b a c b e f h h g g g a
     i   j                 k   l

Sustituímos:

d c i j d b a c b e f k l g a

Como ya no hay bytes juntos que se repitan, entonces podemos terminar la ejecución, los resultados serían:

dcbdbdababdbacbbdabaaaacacacaa = 30 carácteres
dcijdbacbefklga = 15 caractéres.

Y el diccionario quedaria

  • bd : e
  • ab : f
  • ca : g
  • aa : h
  • ee : i
  • ff : j
  • hh : k
  • gg : l

Decodificación

Para la decodificación, primeo debemos girar el diccionario y ordenarlo de forma inversa para buscar por las coincidencias hasta que no encontremos ninguna más:

Cadena original: dcijdbacbefklga

Identificamos: l
Sustituimos por: gg

d c i j d b a c b e f k l g a

Queda:

d c i j d b a c b e f k g g g a

Identificamos: k
Sustituimos por: hh

d c i j d b a c b e f k l g a

Queda:

d c i j d b a c b e f h h g g g a

Identificamos: j
Sustituimos por: ff

d c i j d b a c b e f h h g g g a
Queda:

d c i f f d b a c b e f h h g g g a
Identificamos: i
Sustituimos por: ee

d c i f f d b a c b e f h h g g g a

Queda:

d c e e f f d b a c b e f h h g g g a
Identificamos: h
Sustituimos por: aa

d c i f f d b a c b e f h h g g g a

Queda:

d c e e f f d b a c b e f a a a a g g g a
Identificamos: g
Sustituimos por: ca

d c e e f f d b a c b e f a a a a g g g 

Queda:

d c e e f f d b a c b e f a a a a c a c a c a a
Identificamos: f
Sustituimos por: ab

d c e e f f d b a c b e f a a a a c a c a c a a

Queda:

d c e e a b a b d b a c b e a b a a a a c a c a c a a

Identificamos: e
Sustituimos por: bd

d c e e a b a b d b a c b e a b a a a a c a c a c a a

Queda:

d c b d b d a b a b d b a c b b d a b a a a a c a c a c a a

Y asi se hace el deflate de los datos.


Referencias:

[PDF] Byte pair encoding: a text compression scheme that accelerates pattern matching.
  • Yusuke Shibatay
  • Masayuki Takeday
  • Takuya Kiday, Shuichi Fukamachiz
  • Ayumi Shinoharay, Takeshi Shinoharaz
  • Setsuo Arikaway
    • Dept. of Informatics, Kyushu University 33, Fukuoka 812-8581, Japan
    • f yusuke, kida, takeda, ayumi, arikawag @i.kyushu-u.ac.jp
      • Dept. of Arti cial Intelligence, Kyushu Institute of Technology, Iizuka 320-8520, Japan
      • f fukamati, shinog @ai.kyutech.ac.jp
      • [IT] Homework 4: Adaptative methods

        For the homework of this week, we had to design an algorithm to turn our implementation of Huffman's Coding into an adaptative implementation of Huffman's coding.

        ...

        Hipotesis


        Since the Huffman's coding needs to build a binary tree, there is a possibility to improve the three construction.
        So, my approaching is to improve the tree construction everytime when a new node is added to it.

        A common Huffman's coding tree looks like tihis:


        When the structure of the tree is too deep,  we will get very large huffman codes for the less frequent letters.

        Maybe, rebalancing the tree in each run, shorters codes could be generated and a little more space could be saved.

        So, my approaching is center the huffman's coding in the frequencies of the character to reconstruct and rebalance the tree in each run and get a structure like this:


        Where we can get more and shorter codes.

        It's expected that this implementation will be more resource and time expensive, but also it's expected that the final results will be better.
        ...



        There is no code :(


        I don't have enough time to complete the homework this time, I hope don't fail with the other ones.

        martes, 23 de abril de 2013

        [Lab RT] Actividad 8: Mecanismos de control de congestión


        Para ésta semana continuamos con los temas de lecturas científicas, ahora el tema es referente a mecanismos de control de congestión, el documento seleccionado fue:

        ...


        RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime
        Streams in the Internet


        Reza Rejaie, Mark Handley, Deborah Estrin
        University of Southern California
        Information Sciences Institute
        Marina Del Rey, CA 90292
        { reza, mjh, estrin} @ isi.edu

        ...

        1. Introducción


        El Internet ha venido experimentando un aumento explosivo en el uso de aplicaciones de stream de audio y video. Dichas aplicaciones son bastante sensitivas a retrasos, cambios en las tasas de transferencia y necesitan tener un buen grado de confiabilidad, para esto se utilizan mecanismos QoS de punto a punto.
        A pesar de todo esto, el Internet no garantiza bajos niveles de retrasos o un buen nivel de banda ancha disponible, por lo que el servicio provisto no es ni controlable ni predecible. Estas fallas en los mecanismos QoS no frenan el crecimiento de las aplicaciones de stream.
        En redes compartidas, los sistemas reaccionan a las congestiones adaptando sus tasas de transferencia, para evitar que el sistema colapse; así mismo, adaptan su uso de banda ancha para que todos los flujos e información puedan coexistir sobre la misma conexión. Lo sistemas que toman estas medidas se conocen como "buenos ciudadanos".

        La porción de tráfico dominante en Internet esta basado en TCP, por lo que es más viable implementar mecanismos de control de congestión que sean amigables con el entorno de dicho protocolo. Esto quiere decir que las aplicaciones de stream de datos deben tener la misma cantidad de banda ancha promedio sobre una sesión TCP que permanezca activa en el mismo camino y bajo las mismas condiciones de latencia y pérdida de paquetes.

        Se hace uso de una arquitectura que se encarga de proveer streams codificados por capas y almacenados en Internet, el enfoque principal es el uso de un servidor web o de video bajo demanda que provea acceso a una gran variedad de contenido multimedia para un gran número de clientes. La meta es que las aplicaciones de reproducción en tiempo real sean buenos ciudadanos. La idea es separar el control del tráfico del control de errores porque el primero depende del estado de la red mientras que el segundo es especifico de la aplicación.

        Las tasas de transferencia de los servidores son continuamente adaptadas por el protocolo RAP (Rate Adaptation Protocol), y dicho módulo es exclusivo para el control de congestiones y la detección de pérdidas. El gestor de capas adapta la calidad del stream transmitido de acuerdo a la tasa de transferencia especificada por el RAP y trata de enviar la mayor cantidad de capas posibles según la cantidad de banda ancha disponible. Durante un viaje de ida y vuelta algunas capas pueden perderse, por lo que se hace uso de un buffer en el lado del cliente para almacenarlas y ordenarlas temporalmente, así mismo, para hallar dónde faltan capas. El buffer ayuda a la retransmisión selectiva de capas las cuales son determinadas por el gestor de retransmisión. La banda ancha agregada utilizada por el servidor y por el gestor de retransmisión no debe exceder la banda ancha especificada por el RAP.

        El paper presenta el diseño y evaluación del protocolo RAP a través de simulaciones, como método de control de congestión  adecuado para aplicaciones unicast de streams en tiempo real, asi como para otras aplicaciones compatibles. La meta es lograr que RAP se comporte correctamente y se amigable en TCP.


        2. Trabajos relacionados


        El estudio de mecanismos de control de congestión no es nuevo, sin embargo, el estudio de mecanismos de control de congestión amigables con TCP en redes de mejor intento es un poco más limitado.
        Una aproximación común para la adaptación de tasas de transferencia es utilizar métodos de codificación adaptativa mediante el ajuste de los parámetros de los codecs basándose en el estado de la red. Sin embargo, esto no es muy recomendable ya que hace un uso intensivo del CPU para codificar los diferentes streams de los diferentes clientes.
        Existe, por ejemplo, el protocolo SCP que es una versión modificada de TCP que utiliza un método parecido al TCP-Vegas para adaptar las tasas de transferencia, sin embargo, SCP no es muy amigable con TCP, por lo que para TCP se basa en el RTT calculado (Round Trip delay time).


        3. Protocolo RAP


        El protocolo fue implementado desde el principio. Básicamente, el protocolo envía todos los paquetes numerados secuencialmente, el destino de los paquetes reconoce los paquetes lo que provee un sistema de retroalimentación en la comunicación. Cada mensaje ACK contiene una secuencia de números que corresponde con la información entregada por el paquete. Utilizando la retroalimentación, la fuente RAP puede detectar las pérdidas. Durante el diseño del mecanismo de adaptación, se hallaron 3 problemas:

        a) Función de decisión

        El esquema de adaptación se basa en 2 reglas simples

        • Si no se detecta congestión, aumentar periódicamente la tasa de transferencia.
        • Si se detecta congestión, reducir inmediatamente la tasa de transferencia.
        El RAP utiliza los mensajes de pérdidas como señales de congestión, y los tiempos de espera y las separaciones en las secuencias para detectar las pérdidas.
        Mantiene un RTT (round trip delay time) estimado, al igual que en TCP, llamado SRTT y calcula el timeout utilizando el algoritmo de Jacobson/Karel. 
        A diferencia de TCP, RAP puede enviar varios paquetes antes de recibir un nuevo ACK que permita recalcular el RTT estimado.
        Para la deteccion de perdidas basado en ACK, RAP utiliza la misma intuición que el fast-recovery en TCP. Si una fuente RAP recibe un ACK, implica la entrega de tres paquetes después de perder uno.


        b) Algoritmo de incremento/decremento

        El algoritmo de incremento/reducción. En ausencia de pérdidas, la tasa de transferencia ira incrementándose en buena forma.
        El algoritmo es controlado ajustando la separación entre paquetes, dicho ajuste depende de la tasa de transferencia y el tamaño del incremento, también depende de una constante de tiempo.

        c) Frecuencia de decisión

        Especifica que tan seguido se actualiza la tasa de transferencia. La frecuencia de ajuste optimo depende del delay en la retroalimentación. Los delays en la retroalimentación son iguales a un RTT. Esto sugiere que los esquemas basados en la tasa de transferencia no deben actualizarse mas de una vez por RTT, cambios muy frecuentes pueden causar oscilaciones inesperadas y ocasionar que el sistema no responda.
        RAP realiza los ajustes una vez por SRTT. El tiempo entre dos ajustes es llamado step.


        Pérdidas agrupadas

        En una red compartida basada en el mejor esfuerzo con un alto nivel de multiplexing estadístico, se observa que el patrón de pérdidas se acerca mucho a un comportamiento aleatorio.
        Ésto dificulta el control de las pérdidas ajustando solamente la tasa de transferencia.
        RAP requiere de un mecanismo para identificar donde se concentran las pérdidas y saber si estan relacionadas a un mismo evento de congestión. La pérdida de un paquete resulta en un retroceso, los paquetes pendientes en la cola, llamada cluster, tienen un número de secuencia que se enumeran desde la ultima perdida hasta el momento en que sucede la siguiente pérdida.
        Un evento de pérdida define un nuevo evento de congestión.


        Random Early Detection Gateway

        Parece existr un acuerdo general en la comunidad para desarrollar Random Early Detection gateways para mejorar el desempeño del trafico TCP.
        El manejo de la cola de paquetes en RED intenta mantener un tamaño promedio pequeño y también acomodar una gran cantidad de paquetes para evitar el desbordamiento del buffer.
        Uno de los principales problemas en el control de congestión en TCP es intentar recuperarse de multiples perdidas dentro de un mismo periodo. Esto se debe a que durante un desbordamiento se tiran todas las colas de datos.
        Idealmente, los gateways RED deben estar configurados de tal manera que cada flujo experimenta como máximo una sola pérdida por RTT. Bajo estas circunstancias, los flujos de TCP pueden recuperar de manera eficiente a partir de una sola pérdida sin experimentar un tiempo de espera de retransmisión. Intuitivamente, siempre y cuando un gateway RED funcione en su región ideal, RAP y TCP obtienen una parte igual de ancho de banda ya que ambos utilizan el algoritmo AIMD. Sin embargo, si la longitud media de la cola supera el umbral máximo, RED comienza a descartar paquetes con una probabilidad muy alta. En este punto, RAP y TCP empiezan a comportarse de forma diferente. Cuando el TCP normal experimenta pérdidas múltiples dentro de una ventana, se somete a un tiempo de espera de retransmisión y sus control de congestión divergen del algoritmo AIMD.

        Se espera observar una mejora sustancial en el rendimiento mediante la implementación de RED aunque sólo impide que el búfer se desborde y causando la pérdida de ráfaga. Este comportamiento limita la divergencia de control de congestión de TCP del algoritmo AIMD.
        Como parámetros RED dependen estrechamente del comportamiento del tráfico total, es difícil mantener el trafico RED en su región ideal debido a los cambios de tráfico con el tiempo.
        Por lo tanto, la configuración de RED sigue siendo un tema de investigación.


        4. Simulación


        El objetivo de la simulación presentada es explorar las propiedades de RAP y su capacidad de hacer frente al trafico TCP, su interacción con gateways RED.
        Las simulaciones demuestran que RAP es amigable bajo el protocolo TCP.
        Las simulaciones se realizaron utilizando el simulador NS2 y se comparo con TCP Tahoe, Reno, NewReno, Sack y con experimentos del mundo real.
        La topología de la simulación se muestra en la siguiente imagen:



        Las especificaciones de la simulación son:
        • La conexión entre SW1 y SW2 siempre tiene un cuello de botella y el nodo SW1 es el inicio del cuello de botella.
        • Los switches implementan un scheduler tipo FIFO y una cola tipo drop-tail, con excepción en las simulaciones RED.
        • Son m conexiones tipo RAP desde los nodos R1 ... Rm, hasta los nodos P1 ... Pm.
        • Las conexiones comparten la banda ancha en el cuello de botella con n flujos TCP desde las fuentes T1 ... Tn, hasta los receptores S1 .. Sn.
        • Los datos y los paquetes ACK son similares para RAP y TCP.
        • Todas las conexiones cuentan con el mismo delay
        • El tamaño del buffer en SW1 tiene cuatro veces mas banda ancha RTT.
        • Todas las simulaciones correrán hasta que muestren un comportamiento estático.
        • Todos los flujos TCP son sesiones de tipo FTP con una cantidad infinita de información.
        • La banda ancha promedio es medida por el número de paquetes durante los últimos tres cuartos del tiempo de la simulación para ignorar el comportamiento transitorio del principio
        Los parámetros de la simulación son:

        Packet size100 bytes
        ACK Size40 bytes
        Bottleneck delay20 ms
        B/W per flow5 Kbytes/s
        B/W of Side Links1.25 Mbytes/s
        Tot. Delay of Side Links6 ms
        Simulation Length120 sec
        TCP Maximum Window1000
        TCP Timeout Granularity100 ms

        5. Conclusiones y trabajo futuro


        Aunque alcanzar una buena compatibilidad con TCP  en una amplia gama de parámetros de la red es extremadamente difícil, RAP alcanza razonablemente este objetivo. Se diseño y evalúo un mecanismo de adaptación de la tasa de transferencia para emular la propiedad de temporización ACK de TCP. Los resultados muestran que la adaptación de la tasa de transferencia la coexistencia de ambos protocolos a un nivel más amplio. La divergencia del control de congestión de TCP respecto al algoritmo AIMD suele ser la causa principal de la falta de equidad de TCP en casos especiales. Este problema se manifiesta con mayor claridad con Reno y Tahoe, mientras que tiene un impacto más limitado en Sack.
        Si los gateways RED son debidamente configurados, se puede alcanzar una capacidad de intercambio ideal entre protocolos.
        RAP es un componente esencial de la arquitectura de extremo a extremo para la reproducción de flujos unicast en tiempo real a través de redes de mejor esfuerzo. Se ha desarrollado una "adaptación de calidad" mecanismo que ajusta sin problemas la calidad de una reproducción de vídeo codificada en capas, mientras que su velocidad de transmisión es controlada por RAP.


        Referencias


        Imágenes tomadas del paper.

        [Lab CU] Actividad 8: Usabilidad en sistemas de cómputo ubicuo


        Para ésta semana continuamos con los temas de lecturas científicas, ahora el tema es referente a técnicas de usabilidad en sistemas de cómputo ubicuo, el documento seleccionado fue:

        ...


        Usability Evaluation Framework for Ubiquitous Computing Device

        Han Joon Kim, Jong Kyu Choi, YongGu Ji
        Yonsei University Information and Industrial Engineering
        khjoon@yonsei.ac.kr, jk.choi@yonsei.ac.kr, yongguji@yonsei.ac.kr

        ...

        1. Introducción

        La aparición y mejoramiento de algunos dispositivos tecnológicos como los celulares y asistentes personales (PDA), junto con el desarrollo de nuevas tecnologías, han permitido que se tenga un mejor acceso a la información gracias a las tecnologías de comunicación inalámbricas.
        Con ello, han aparecido nuevos ambientes en los cuales se utilizan estos dispositivos.
        Segun el ISO 9241-11, la usabilidad constituye la efectividad, eficiencia y satisfacción donde un grupo especifico de usuarios realizan una serie de tareas en un ambiente particular. Posteriormente Preece dice que la usabilidad es hacer que los usuarios realicen una tarea de forma segura, efectiva, eficiente y disfrutable.
        Debido a los cambios en los ambientes de interacción con dispositivos, es necesario el desarrollo de un adecuada evaluación de usabilidad orientada a los nuevos paradigmas de la computación ubicua.
        Entonces, el estudio se centra en los pasos para el desarrollo de un framework de pruebas de usabilidad en dispositivos de cómputo ubicuo.


        2. Background

        En el año 2006, en el Simposio Internacional de Sistemas de Computo Ubicuo (International Symposium on Ubiquitous Computing Systems), se hizo énfasis en las 5C y los 5Any que la computación ubicua tiene:
        • Computing, Comunication, Connection, Contents, Calm
        • Anytime, Anywhere, Any-network, Any-device, Any-service
        Hansmann hizo una diferenciación de los dispositivos de computación persasiva en cuatro aspectos:
        • Controles inteligentes: Por ejemplo, control de temperatura en la casa u oficina
        • Aparatos inteligentes: Por ejemplo, quioscos digitales y ATM's
        • Acceso a la información: Por ejemplo, smartphones y PDA's
        • Sistemas de entretenimiento: Por ejemplo, videojuegos y reproductores multimedia
        Las caracteristicas de todo sistema de cómputo ubicuo de acuerdo a 3 investigaciones son:
        • M. Weisser: Invisibilidad, serenidad, ubicuidad, transparencia
        • Burnett & Rainsford: Universalidad, utilidad, usabilidad, ubicuidad.
        • uKoreaForum2006: 5C y 5Any

        Evaluación de la usabilidad

        Existen ciertos conceptos relacionados: computación pervasiva, computación nomádica, inteligencia ambiental y computación consciente del contexto, son utilizadas bajo el mismo concepto.
        1. Usabilidad relacionada al contexto: El contexto es muy importante en el diseño de productos tecnológicos. Cada producto tiene sus propias características dependiendo del contexto de uso. La usabilidad de cada producto puede variar en cada uno, los investigadores Bevab & MacLeod explican que para medir la usabilidad general de los productos es esencial evaluar cada uno es su ambiente, usuarios y tareas representativas, pasa así tener un entendimiento más profundo del contexto de uso del producto.
        2. Usabilidad móvil: Los ambientes móviles difieren de los típicos ambientes estáticos. El investigador Barnard hace énfasis en que es necesario evaluar de forma especifica estos ambientes, ya que el movimiento afecta la perspectiva y análisis del estudio.
        3. Sitema de evaluación ubicua: Killijian presenta un método para la evaluación práctica de los sistemas ubicuos móviles. J. Scholtz y Consolvo  presentan un framework para la evaluación de aplicaciones de cómputo ubicuo, centrándose en los puntos de atención, adopción, credibilidad, modelo conceptual, interacción, impacto y efectos secundarios ocasionados. Cada una con sus respectivos indicadores y mediciones. A pesar de todo, es necesario centrarse en todo el sistema de evaluación de todo el sistema y no solo en el aspecto de usabilidad.

        3. Framework

        Modificando la forma de descomposición del contexto, se esta sugiriendo una nueva metodología de evaluación que se refleje en el usuario, la tarea y el dispositivo.
        Dada la información del usuario en un dispositivo, se puede hacer una selección del usuario y de la tarea principal a realizar. Ésta es una especificación de la información del contexto del dispositivo y posteriormente es utilizada en la lista de chequeo de evaluación. Tomando en cuenta las caracteristicas de cada dispositivo, es posible ramificar los dispositivos mediante su usabilidad ubicua.



        Factores de evaluación

        Existen diversos factores de evaluación tomados de investigaciones existentes, algunos de ellos son eficiencia, efectividad y satisfacción, sin embargo, todos ellos derivan de métodos generales de evaluación. Algunos factores de evaluación para dispositivos ubicuos son:
        1. Adaptabilidad: Que se juste a los cambios en el contexto.
        2. Controlabilidad: Poder controlarse en cualquier circunstancia.
        3. Interconectividad: Entre varios dispositivos para la compartición de información.
        4. Movilidad: El usuario puede cargar con el dispositivo a donde sea.
        5. Previsibilidad: Con base en experiencias pasadas, saber el comportamiento de antemano.
        6. Simplicidad: Interfaces e instrucciones son simples de entender.
        7. Transparencia: Proveer el estatus del sistema tanto en reposo o en ejecución.
        8. Claridad: Toda información provista por el dispositivo es clara y comprensible.
        9. Accesibilidad: Abierto a todo quien lo desee.
        10. Afecto: Satisfacción general en todo le sistema.
        11. Compatibilidad: Con todos los modelos mentales, usuarios y dispositivos.
        12. Consistencia: Presentación similar ante contextos, propósitos y terminología similares.
        Existen alrededor de 26 factores a evaluar, recopilados de investigaciones pasadas, otros factores son efectividad, eficiencia, prevención de errores, retroalimentación, perdón, ayuda, facil de aprender, memorable, multi-hilo, responsivo, seguro, entre otros.


        Áreas de evaluación

        El dispositivo se descompone en distintos elementos fundamentales para su evaluación, y así obtener el grado de usabilidad del mismo.
        Los factores anteriormente mencionados se pueden aplicar para evaluar cada componente del dispositivo: LUI, GUI, PUI (Logical User Interface, Graphical User Interface, Physical User Interface), cada elemento se evalúa por separado.
        LUI es la conexión lógica, como el flujo de trabajo y las interacciones, que son la base del GUI. GUIes la representación del software gráficamente en una pantalla, son los elementos con los que el usuario interactúa directamente. PUI es la interacción que es controlada por los usuarios de manera física. LUI y GUI están unidas por el software. PUI es el hardware, las formas de interacción desde el exterior.

        1. LUI
          • Software de aplicación: Programas o funciones provistos en el sistema
          • Estructura del menú: Estructura y contenido de la información
          • "Consciencia" del sistema: Notificaciones al usuario sobre el estado del sistema
          • Aceptación del sistema: Nivel de aceptación del sistema por parte del usuario
        2. GUI
          • Indicadores: Elemento que representa el estado del sistema
          • Iconos: Figuras que representan información del sistema
          • Menus: Indican funciones que el usuario puede elegir
        3. PUI
          • Teclas de control: Para control del sistema
          • Pantallas táctiles: Para el control del sistema
        4. Hardware
          • Pantallas: Salidas visuales del sistema
          • Cuerpo: El exterior del dispositivo

        Contexto de uso

        El contexto de uso queda definido al identificar el tipo de usuario, tipo de dispositivo, tipo de tarea y tipo de uso. Esto provee la información necesaria sobre el ambiente y las condiciones o situaciones en las cuales el usuario utiliza su dispositivo.
        Tipicamente, usuario se divide en novato y experto.
        Los dispositivos se dividen en portable, music player, PDA, UMPC, smartphone, videojuego.
        Una buena evaluación de contexto toma en cuenta diferentes contextos de uso y cada uno es evaluado con sus propios factores.


        Método de evaluación

        De los 26 posibles factores de evaluación, se tomaron los primeros 7, después se combinan en una tabla de evaluación. El símbolo "+" significa que esa área debe ser evaluada y cada factor puede afectar distintas áreas. Los resultados horizontales representan el puntaje total en la evaluación de usabilidad por área de evaluación.
        Un ejemplo de tabla de evaluación puede ser la siguiente imágen:


        5 Conclusión

        El sistema propuesto esta basado en la información del contexto de uso. En éste sistema, los componentes de los productos y dispositivos son generalizados y entonces cada uno de ellos es evaluado utilizando los factores de usabilidad. Los 26 factores de usabilidad que son utilizados estan basados en las características de los sistemas de cómputo ubicuo. Utilizando un nivel de estándarización de factores, componentes, puntajes, se puede comparar la usabilidad entre diferentes dispositivos.

        El sistema ayudará a mejorar el desempeño y la usabilidad de los productos evaluados.


        6 Referencias:
        • Todas las imágenes tomadas del paper.
        • http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4682020

        [Lab VC] Actividad 6: Detección de agujeros

        La actividad de esta semana es complemento de la tarea de la clase, es un preprocesamiento para la detección de agujeros en un objeto.
        Los requisitos de la tarea son:
        • Dibujen encima de casa imagen una recta para cada pico del histograma lateral; independientemente para horizontal y vertical.
        • Las intersecciones deberían coincidir con los agujeros.

        Para lograr dibujar el histograma, se debieron normalizar los valores del histograma ya que éstos eran demasiado altos.

        Es posible obtener el histograma de todas las imágenes, y se puede hacer un histograma por cada uno de los colores (RGB) o en escala de grises para calcular los niveles de iluminación.

        Un agujero es una hendidura en algún objeto, por consiguiente, causa una variación en la iluminación general de la imagen, es posible detectar  un agujero midiendo estas variaciones utilizando histogramas laterales, uno para el largo de la imagen y otro para el ancho.

        Éste es un ejemplo de los histogramas de una imágen genérica:




        Actividad


        Se utilizaron las siguientes imágenes :

        Original
        Escala de grises

        Resultados:


        Original
        Histograma horizontal
        Histograma vertical
        Histograma horizontal sobrepuesto
        Histograma vertical sobrepuesto
        Intersecciones


        Los histogramas sobrepuestos, es necesario ver la imagen con un 100% de zoom, después se podrá ver en las orillas derecha e inferior las formas de los histogramas.

        Los resultados de la detección de los agujeros se muestran en esta entrada

        Código


        En el repositorio encuentran la implementación completa en código, la carpeta marcada como Tarea 7.



        Como el código para detectar los agujeros permaneció igual, solo adjunto la rutina que dibuja todos los resultados del preprocesamiento.


        Fin de a actividad.