Páginas

Mostrando las entradas con la etiqueta ubicomp. Mostrar todas las entradas
Mostrando las entradas con la etiqueta ubicomp. Mostrar todas las entradas

martes, 21 de mayo de 2013

[CÓMPUTO UBICUO] Sugerencias de nuestro proyecto

Se tenía planeado una serie de cosas en un principio pero conforme pasó el semestre, modificamos algunas de ellas.

Para el garage inteligente se tenía contemplado lo siguiente:

  • Una puerta que se abriera mediante una aplicación móvil que se comunica via Bluetooth.
  • Una cámara que detecta la presencia de vehículos y que notifica al usuario de esto.
  • Lector de codigos QR mediante la misma cámara para permitir el paso a otras personas.
  • Una web qu el usuario puede acceder para ver el estado del sistema.

Además de pequeñas cosas que surgieron como ideas durante el semestre.

Para el proyecto se realizó una simulación del garage pues no contabamos con alguien que tuviera un garage con las condiciones para realizar el proyecto. Se realizó una simulación en un proto con leds de colores que notifican el estado del garage.

Lo que se logró fué lo siguiente:

  • Implementación de la web, donde el usuario puede acceder al sistema e inclusive abrir el garage desde este mismo. La web tambien permite al usuario generar un codigo QR y compartirlo con un amigo. Ademas de ver el historial de lo que ha sucedido.
  • Creación de una app móvil para acceder al garage utilizando comunicación Bluetooth. Se agrega una contraseña y se configura el dispositivo para comunicarse con el garage.
  • Implementación de códigos QR para abrir la puerta del garage con uno de estos. Mediante la cámara se detecta el QR. El QR tiene una caducidad, y el sistema no permite el paso a quienes tengan uno vencido.
  • Se implementó un sistema de notificaciones por e-mail. Si un usuario con un QR intenta acceder, se notifica al dueño via e-mail para notificar quien entró, si alguien con un QR vencido intentó entrar o si hay un vehiculo obstruyendo el paso.

Qué realicé:

Para el proyecto me enfoqué sobre la aplicación Android, mi meta era crear una app que se comunicara vía Bluetooth con el garage, comunicar al sistema de la posición actual y recibir las notificaciones directamente en el celular.

Por falta de tiempo solo se alcanzó la primera parte, la comunicación Bluetooth con el garage. Todo esto lo realicé "a ciegas" debido a que no tenía a la mano el dispositivo que utilizariamos como garage. Por lo que me vi en la necesidad de agregar una lista de dispositivos Bluetooth aunque no fueran del mismo tipo (mi idea era registrar una serie de direcciones MAC en el web service para solo leer la correcta). Como resultado, el usuario debe conectarse manualmente al dispositivo. La solución que dí fue que la app automaticamente detectara si hay o no dispositivos sincronizados, si no los hay, se abre la ventana de configuración de dispositivos, si si los hay, se muestra una lista de los dispositivos sincronizados (dando por hecho que el usuario sincronizó el celular con el garage). Por ultimo dando dos opciones para abrir y cerrar, y dos botones de configuración de dispositivo y contraseña.

Qué me faltó:

Sincronización GPS, no es difícil pero necesita de comunicación 3G (no tengo), por lo que las pruebas serían difíciles. Utilizar solo la red WiFi para esto no es buena práctica, pues no da un resultado exacto ni aproximado, sino que calcula la posición de otras antenas. Lo recomendado es utilizar una combinación o solo 3G para funcionar correctamente.

Las notificaciones al celular no se implementaron pues esto requiere de una cuenta en Google API y varias cosas que requieren servicios web que no se tenían planeados. Solo nos quedamos con las notificaciones vía email.

Qué faltó en general:

El servicio web quedó completo para lo que teniamos como entregable, pero para lo planeado quedó parcial, pues tenía planeado utilizarlo para la app móvil.

El proyecto iva por buen camino, pero se esperaba implementarlo en un garage real. No hubo coordinación por nuestra parte y  el desarrollo lo hicimos cada quien por separado por lo que no hubo mucha retroalimentación.

Por mi parte creo que necesitabamos contar con más participación en cuanto a reuniones y buscar a alguen dispuesto a prestarnos su garage.

[CÓMPUTO UBICUO] Sugerencias de proyectos finales.


Para esta entrada se mencionan algunas sugerencias para los proyectos finales que se vieron durante la clase.

SeguriLap:

Propósito: Una computadora inteligente capaz de detectar el rostro del usuario y realizar tareas de forma más inteligente.

Que faltó: Por lo que veo no lograron implementar al 100% el sistema de autentificación, pues el reconocimiento facial no es algo sencillo. Por lo que veo implementaron el metodo al que llaman mapeo (line edge maps), es un buen método pero se necesita de un mejor entrenamiento pues el mapeo solo detecta zonas de interés que podrían detectar cosas que no son ojos o boca o nariz. Deben alimentar a la red neuronal con zonas de interés aparte (ojos, boca, nariz por separado). Recomendaría utilizar un sistema que detecte todas las zonas de interés y después descarte lo que es ruido mediante esa red neuronal, pues veo que su cámara detecta cosas que no son de interés, aún así es preciso e hicieron una buena implementación. Por último, lo de reproducción de video no me quedó muy claro como funciona, pero me imagino como, y puede ser una oportunidad de implementar su sistema no solo en login o reproducción de video, sino en distintas aplicaciones.

CarNXP:

Propósito: Un automóvil que se abre con NFC y mediante esto se accede a una serie de funciones.

Qué faltó: La verdad es que su proyecto está muy completo, a pesar de las faltas. Eso si, la integración es una parte crucial pues mediante ella se tendría un mejor control de lo que sucede con el producto. Lo de la lista de reproducción no estoy seguro si sea necesario, aunque los usuarios buscan algo de distracción, pues no lo veía relacionado con su objetivo, pero está bien. Lo de medición de gasto de gasolina no creo que sea una buena forma obtener los datos del gasto propuesto por alguien más, creo que se podría hacer algo más para saber el gasto real mediante el uso de algunos dispositivos, pues un auto nunca consume lo mismo a lo largo de su vida útil.

Despertador inteligente:

Propósito: Un despertador incrustado en una cama que detecta si el usuario está levantado para asegurar que no se le haga tarde, si no, seguirá la alarma.

Qué faltó: Por lo que veo dedicaron mucho a este proyecto, veo que lograron la mayoría de sus objetivos principales, pensaron en varias soluciones. Aunque no lograron comunicar el dispositivo móvil con el Arduino vía Bluetooth, fue una buena idea crear un servicio web, eso si, yo veo su proyecto como un producto de uso local, es decir, las comunicaciones por Internet no son necesarias. La comunicación Bluetooth no es difícil de un Android a un Arduino, solo que se debe tener un control sobre lo que se envía (muchos o pocos bits) y la sincronización, generalmente con uno o dos bits hay buena comunicación.

Galería inteligente:

Propósito: Dar seguridad a obras de alguna galería e iluminarse automaticamente con la proximidad.

Qué faltó: Veo muchas áreas de oportunidad para su idea, pero la dejaron en un punto intermedio entre lo que pudieron lograr y lo que demostraron. Lo de reproducir sonidos mediante el Arduino, podrían pensar en utilizar una computadora central como lo hacen en la mayoría de los productos y simplemente llamar el sonido correcto. Lo de login y las gráficas puede ser un servicio interno y podrían utilizar tales gráficas para crear un servicio web que muestre un ranking de las obras. Veo que el audio es largo, pero no alcancé a notar si se corta cuando no hay nadie, este es el comportamiento que al menos yo esperaría.

Casa segura:

Propósito: Brindar al usuario seguridad en su hogar mediante dispositivos y mecanismos inteligentes.

Qué faltó: Pues faltó mas que nada organización como ustedes lo dijeron, pues su proyecto era muy bueno, estoy seguro que mucha gente desearía tener algo como lo propusieron. Si les faltó algún dispositivo, pudieron pedirlo prestado. Lo de conversión de niveles lógicos, no es algo realmente difícil, y no es necesario tener todo conectado a una misma fuente, pues la comunicación se puede realizar con éxito.

Alarma de automóvil inteligente:

Propósito: Brindar seguridad al automóvil de forma inteligente mediante una alarma.

Qué faltó: Veo que hicieron un intento por crear una alarma que se comunica con un móvil, debo decir que utilizar GPS no es difícil por lo que creo que se pudo realizar con éxito, los servicios web pudieron implementarlos localmente, no me queda claro cual es el intermediario entre las comunicaciones que se realizan. Las notificaciones debieron implementarse mediante ese servicio web, es decir, Bluetooth no es confiable a más de 10 metros de distancia, suponiendo que no hay obstrucciones.

Localizador inteligente:

Propósito: Mantener una serie de objetos localizados en un área determinada.

Qué faltó: No me queda muy claro como localizan los dispositivos, me imagino que mediante Bluetooth. Me esperaba que localizara cualquier objeto con algún RFID tag o equivalente. Por lo que veo solo es una alarma que alerta al usuario que un dispositivo está fuera del rango. Hay que pensar en que pasaría si el dispositivo se apaga, pues no se puede tener el Bluetooth encendido por siempre.

Oficina inteligente:

Propósito: Ingresar a la oficina mediante una sola llave además de que esto brindará servicios.

Qué faltó: Aunque su demo demuestra un funcionamiento básico, es cierto que pueden utilizar todo esto para varias funciones, en este caso solo simularon mediante software, pero esto se puede extender fácilmente a implementar el sistema en un ambiente real. Faltó un servicio local o web que controle lo que está ocurriendo. También mencionan la unificación del sistema en lugar de usar módulos separados, yo creo que no es mucho problema pero si es importante mantener todo el sistema comunicado, pueden utilizar comunicación inalámbrica pues me imagino que los sensores estarán dispersos y separados.

martes, 14 de mayo de 2013

[CÓMPUTO UBICUO] Lab 11: Sugerencias de privacidad

Para esta entrada se realizan sugerencias en cuanto a privacidad en los proyectos, basadas en el contnido de las presentaciones de la semana pasada.

Alarma inteligente:

En realidad la comunicación Bluetooth corre el mismo riesgo que cualquier otro tipo de comunicación, así que si desean seguridad necesitarán implementar algún mecanismo de encriptación de datos.

Para los datos del GPS iguamente pueden utilizar encriptación de datos visibles solo desde algún modo solo disponible para el usuario. Además de limitar su uso, eso quiere decir que solo utilizarlo en cuanto sea necesario y no todo el momento.

Tambien agregar a sus avisos de privacidad y terminos y condiciones de uso todas las advertencias sobre el uso de datos y a que se limitan estos usos, además de dar a conocer quienes pueden ver esta información y con que privilegios cuenta.

Computadora inteligente:

En sí es muy poca la información personal que almacenan y además lo hacen en forma local, aunque si es importante que dén a conocer al usuario mediante algún aviso de privacidad la forma en que utilizan estos pocos datos.

Además de que implementen seguridad mediante encriptación de datos con alguna contraseña, para operaciones de escritura sobre archivos delicados, o cambios en el sistema, pues cualquiera puede llegar con una fotografía de un rostro registrado y acceder a la sesión.

Oficina inteligente:

Su sistema trabaja con información muy importante y que podría caer en manos equivocadas, es importante que utilicen algún mecanismo de seguridad para evitar clonaciones de los RFID tags y mencionarlo en sus terminos de uso y avisos de privacidad.

Mencionar tambien que datos personales se utilizan, como operan con ellos y quienes tienen acceso a ellos, ademas del nivel de privilegios que cuentan los usuarios.

Alarma de dispositivos inteligente:

En realidad no importa la localización del archivo de configuración si implementan un buen cifrado.

Otra cosa es que existen formas de detectar si el dispositivo está rooteado, quizá sería una buena opción tratar de proteger los datos contra posibles amenazas que dejar a que el usuario se encargue, ya que tener el dispositivo rooteado probablemente no es legal para el fabricante del dispositivo, pero Android da la posibilidad, por lo que se contempla más bien como algo opcional.

Galería inteligente:

No hacen uso de datos muy relevantes, pero si es importante que tengan avisos de privacidad y documentos de terminos y condiciones, esto sería para quienes adquieren su producto y no para los visitantes de la galería. También informar en esos mismos documentos, que tipo de información se recauda y quienes podrían tener acceso a ella.

Despertador inteligente:

No es muy seguro manejar información de bases de datos directamente con una app, tendrían que crear servicios web como inermediarios para comunicar la base de datos con la app, pues la app puede ser facilmente descompilada y obtener información muy importante.

Casa inteligente:

Creo que estar notificando al usuario a cada momento de lo que hace no es una buena idea, pero pueden utilizar su sustema de niveles para regular estas notificaciones, desde notificar cualquier cambio importante cada vez, hasta hacer todo de forma transparente sin notificaciones. Y poner todo esto en su aviso de privaidad y terminos de uso.

CarNXP:

Es importante que mantengan un sistema de seguridad y de cifrado de datos pues manejan demaciada información. También tratar de buscar una forma para evitar o manejar una situación de clonacion de NFC tags.

martes, 7 de mayo de 2013

[CÓMPUTO UBICUO] Lab 10: Privacidad

A Privacy-Preserving UBICOMP Architecture
1. Introducción

El concepto popular de computación ubicua inició con el artículo de Mark Weiser en 1991, donde introduce la visión de una persona interactuando con cientos de computadoras en forma inalámbrica interconectadas y distribuidas en el ambiente físico. Su objetivo era enfatizar en ayudar a la persona en su vida diaria.

El objetivo del artículo es presentar una arquitectura para la computación ubicua que preserva las preferencias de privacidad en forma de políticas personales de privacidad. Un objetivo secundario es discutir la naturaleza de la privacidad y de como las preferencias de privacidad personales podrían ser especificadas en una política de privacidad adecuada para la computación ubicua.

El trabajo está enfocado para un ambiente ubicuo con las siguientes características:
  • Los dispositivos de computación ubicua están conectados localmente así como globalmente vía Internet.
  • Los dispositivos locales pertenecen a un humano o una organización.
  • Los usuarios humanos emplean estos dispositivos para compartir información local y globalmente. Un usuario quien comparte información es llamado "partícipe de datos". El que observa la información es llamado "observador de datos". Un usuario puede ser tanto uno como otro.


2. Políticas de privacidad para computación ubicua.

2.1 Privacidad

Como fue definido en 1997 por Goldberg, privacidad se refiere a la habilidad de los individuos para controlar la colección, retención y distribución de información acerca de ellos mismos.

2.2 Uso de políticas de privacidad

Dar a un individuo o partícipe de datos el control sobre su infracción privada se realiza de la siguiente manera. El partícipe de datos especifica en una política personal de privacidad como quiere que el observador trate su información. Por otra parte, el observador especifica en su política personal de privacidad que información personal requiere del partícipe y como planea manejar ésta información. Ambas políticas deben ser compatibles antes de que el proceso de compartir comience.

Una vez que inicia el proceso de compartir, el observador tiene que cumplir con su política. Deben de existir mecanismos infalibles para asegurar la conformidad de ambos.

2.3 Políticas de privacidad de legislación

Los cuerpos legislativos de todo el mundo han promulgado legislaciones para dar al individuo control sobre su información personal. Han definido la información personal y especificado las obligaciones a las organizaciones proveedoras de servicios con respecto a las políticas de privacidad personales de los consumidores. Estas legislaciones puede ser usada como base para definir el contenido de las políticas personales de privacidad.

El contenido de las politicas de privacidad personales es genérico ya que está basado en la legislación que aplica mundialmente. Puede ser especializada para ambientes ubicuos probando contra un conjunto de preguntas dadas por Hong y otros para el análisis de riesgos de privacidad. Esta prueba identificará que contenidos de la política de privacidad corren riesgos en ambientes ubicuos y por lo tanto necesitan ser revisadas. Como resultado se tendrá una política personal de privacidad para ambientes ubicuos que satisface las legislaciones.

El nombre de esta prueba es PRAQ:
  1. ¿Quienes son los usuarios del sistema? ¿Quienes son los participes de datos, aquellos que comparten la información? ¿Quienes son los observadores de datos, aquellos que ven la información?
  2. ¿Qué tipo de información personal es compartida? ¿Bajo que circunstancias?
  3. ¿Cuál es el valor propuesto para compartir información personal?
  4. ¿Cuales son las relaciones entre los partícipes y los observadores? ¿Cuál es el nivel de naturalieza y simetría de confianza? ¿Que incentivos de información de los partícipes, los observadores tienen que proteger?
  5. ¿Hay algún potencial de observadores maliciosos? ¿Qué tipo de información personal les interesa?
  6. ¿Hay otros interesados o terceros que pudieran verse afectados directa o indirectamente por el sistema?
  7. ¿Cómo se recopila la información personal? ¿Quién tiene el control sobre las computadoras y sensores utilizados para recopilar información?
  8. ¿Como se comparte la información personal? ¿Pueden los participes aceptar o rechazar o seleccionar cualquiera de las dos? ¿Pueden los participes entregar su información o son los observadores los que obtienen esa información de algún medio?
  9. ¿Qué tanta información es compartida? ¿Es discreta y de una sola vez? ¿Es continua?
  10. ¿Cuál es la calidad de la información compartida? ¿En qué nivel se encuentra, en cuestión de espacios, la información (calle, cuarto, edificio, etc.)? ¿Es en tiempo real o se hace un recopilatorio de varios días u horas? ¿Es anónimo, seudónimo, o es con personas específicas?
  11. ¿Qué tan larga es la información presonal? ¿Donde se guarda? ¿Quien puede acceder a ella?

3. Arquitectura ubicua de preservación de privacidad

3.1 Requerimientos

Dado el sistema ubicuo y el uso de políticas de privacidad para proteger la información del partícipe, los requerimientos son los siguiente:
  1. El entorno ubicuo tiene dispositivos que se asume tienen capacidades de realizar las tareas atribuidas anteriormente descritas en la sección 1.
  2. El uso de políticas de privacidad es como la descrita en la sección 2.2.
  3. Antes de usar un dispositivo del sistema ubicuo para compartir información personal u observar información, el usuario debe iniciar una sesión en el dispositivo para identificarse.
  4. La información relativa a los observadores de datos en línea se puede consultar en cualquier momento en cualquier dispositivo del sistema.
  5. Después de iniciar sesión y antes de compartir información, el partícipe debe realizar los siguientes pasos:
    1. Solicitar quienes son los observadores en linea.
    2. Completar su política de privacidad (previamente almacenada como una plantilla sin observadores de datos identificados) al decidir que los observadores de datos recibirá su información privada basada en el uso de políticas. Presentar su política de privacidad para el sistema.
    El sistema automáticamente solicitará las políticas de los observadores y checar la compatibilidad. Por cada opción compatible, se conectará con el observador de tal política.
  6. Después de iniciar sesión y antes de observar información, el observador debe enviar su política de privacidad al sistema cuando se le solicite. 
  7. Para los usuarios que son tanto participes como observadores deben realizar ambos pasos.
3.2 Diseño de arquitectura

Esta sección describe el diseño de la arquitectura para preservación de datos para satisfacer los requerimientos anteriores.

El diseño tiene los siguientes componentes:

Red local y global: Se asume que son del tipo más común (WiFi, Ethernet, IrDA, Bluetooth para el caso local, el Internet mismo para el caso global).

Controlador de privacidad: Este componente tiene las siguientes funciones:
  • Solicitar las políticas de privacidad de los observadores y partícipes.
  • Asegurar que los observadores cumplan la política de los partícipes.
  • Forma conexiones entre los partícipes y los observadores que tengan compatibilidad entre sus políticas de privacidad.
  • Los controladores de cada red local realizan esto para los pares observador y partícipe dentro de la red. Si un participe comparte información con un observador en redes distintas, los controladores de cada red deben comunicarse antes de iniciar a compartir datos.
Interfaces: Los dispositivos en el entorno local necesitan interfaces que trabajen junto con el controlador de privacidad para poder dar mantenimiento de políticas de privacidad.

4. Evaluación

Algunas fortalezas de la arquitectura presentada son:
  • Confirma las preferencias de privacidad especificados personalmente.
  • Puede ser usada para todos los tipos de sesiones.
  • Alta escalabilidad.
Algunas debilidades son:
  • Puede ser difícil de adaptar la arquitectura propuesta en una arquitectura ya existente.
  • Desde la arquitectura propuesta abarca la totalidad de Internet, puede ser difícil para los usuarios que interactúan de países con culturas muy distintas llegar a un acuerdo sobre las políticas.
La arquitectura, en términos de fortaleza, permite a cada usuario especificar sus preferencias de privacidad en una política de privacidad. Permite una sesión de preservación de privacidad entre observadores y partícipes. Cada controlador de privacidad sirve solo en su red local, o se comunica con otros controladores de otras redes para establecer comunicación entre redes.

En términos de debilidades, es cierto que podría ser difícil adaptar esta arquitectura a las existentes entornos ubicuos. La arquitectura propuesta es mejor aplicada a nuevos entornos ubicuos. La dificultad para obtener una política de privacidad entre usuarios de distintos países no es en realidad un problema único de la arquitectura propuesta. De hecho sería un problema de cualquier arquitectura que une a los usuarios. Ésta arquitectura beneficia a los usuarios al permitirles negociar en primer lugar.


5. Conclusión:

Se propuso una arquitectura híbrida, globalmente de punto a punto, localmente centralizada para sistemas de computación ubicua.

El artículo promueve el trato de la privacidad de forma más personal que de costumbre en otras arquitecturas, donde el usuario tiene que estar de acuerdo con políticas predefinidas. Al contrario de estos, el usuario puede potencialmente negar o autorizar la información compartida. Así como también puede solicitar que información desea ver de los demás.

Desde mi punto de vista, parece ser un sistema muy eficaz en cuanto a seguridad, puesto que el usuario solo da a conocer los datos que desea durante un lapso de tiempo dado por la sesión. Así como solo podrá ver lo que los demás usuarios acordaron.

El sistema de compatibilidad de políticas es necesario, pues funciona como un filtro para aquellos que desean comunicarse con los datos dados.

Quizá sea una debilidad el hecho de que al ser una arquitectura relativamente nueva y que por lo tanto sea difícil adaptar los sistemas anteriores a esta o que la arquitectura se tenga que manejar en forma local y que su forma global se vea limitada por las zonas culturales.

Personalmente creo que se trata de una arquitectura eficiente de manejo de privacidad en ambientes ubicuos y que se podría adaptar a las legislaciones nuevas para poder ser estandarizada en los sistemas ubicuos.


Referencias:

[1] G. Yee, "A Privacy-Preserving UBICOMP Architecture" (artículo presentado en Proceedings of the 2006 International Conference on Privacy, Security, and Trust, Octubre 30 – Nobiembre 1, 2006)

martes, 30 de abril de 2013

[CÓMPUTO UBICUO] Lab 9: Recomendaciones en evaluación de usabilidad

Como se ha hecho antes, en esta entrada daré unas recomendaciones a los equipos en base a sus presentaciones de evaluación de usabilidad.

Alarma Inteligente:

A mi parecer usan diseños que van acorde a su proyecto, interfaces sencillas con pocos controles. En cuanto a lo del sistema de apagado, creo que una alarma inteligente debe estar 24/7 sin interrupción salvo cuando la llave correcta es introducida, entonces funcionaría de forma pasiva. Otra cosa es que el usuario debe de poder activar la alarma de forma remota para el rastreo GPS (recordemos los robos a mano armada). Para esto funciones de envió de datos deben activarse cada cierto tiempo definido por el usuario, o bien cuando suceda un evento sospechoso (forcejeo de cerraduras, vidrios rotos, etc).

Computadora inteligente:

La mayoría del software tiene un mini tutorial de uso que solo aparece al primer inicio, sería bueno agregar algo así, sería mejor si este mini tutorial funcionara de la forma en que ustedes lo plantean (reconocimiento facial, control por voz, etc) y que sea accesible por un comando de voz si el usuario necesita más de una vez para familiarizarse.

Oficina inteligente:

Su proyecto, en cuestión de usabilidad, es muy simple pero eficiente, los usuarios solo necesitan su tag para acceder a las funcionalidades de la oficina. Como se los decía uno de los usuarios, traten de poner el lector en una posición visible y llamativa. Podrían implementar un panel de configuración, donde los usuarios se identifican con su tag y les permite configurar las opciones que den.

Recordatorio inteligente:

Me parece que hacen muy buen uso de las interfaces propuestas. Como mencionan, es mejor usar un lenguaje mas familiar para los usuarios. También sería bueno hacer un pequeño recorrido sobre las funciones al inicio de la aplicación solo la primera vez que se accede.

Galería inteligente:

Deberían aprovechar aún más las posibilidades que plantean. Pueden hacer un sistema que reconoce un número de personas frente a la obra y automáticamente inicie la descripción o algo así, y que diferencie cuando hay una persona o varias. Para una persona el sistema podría activarse cuando alguien está a una distancia moderada, si la persona se acerca más entonces activar las narraciones de la obra o algo así. Dentro de lo que cabe, me parece un estupendo proyecto.

Despertador inteligente:

Pues su manejo de usabilidad es muy bueno, el usuario no necesita apagar la alarma, solo despertarse. ¿Han pensado si el usuario vuelve a acostarse después de la alarma? Creo que sería una buena idea poner una especie de rango de tiempo en que no hay nadie en la cama.

Casa inteligente:

Pues parece una interfaz móvil con buena usabilidad, pero al estar en un ambiente ubicuo, creo que se podrían usar otro tipo de llaves electrónicas como los RFID tags o algo así.

CarFxP:

Todo está muy bien, solo que hay que buscar una forma en que los usuarios se sientan seguros.

martes, 23 de abril de 2013

[CÓMPUTO UBICUO] Lab 8: Técnicas de estudio de usabilidad para sistemas de cómputo ubicuo

User-centered Evaluations of Ubicomp Applications


Jean Scholtz1, Larry Arnstein2, Miryung Kim2, Tim Kindberg3, & Sunny Consolvo4
1National Institute of Standards and Technology, 100 Bureau Drive, Gaithersburg, MD 20899
jean.scholtz@nist.gov
2Department of Computer Science & Engineering, University of Washington, Box 352350 Seattle, WA 98195-2350

{larrya, miryung}@cs.washington.edu

3Hewlett-Packard Laboratories, 1501 Page Mill Road, MS 1138, Palo Alto, CA, 94304-1126

timothy@hpl.hp.com
4Intel Research Seattle, 1100 NE 45th St, 6th Floor; Seattle, WA 98105
sunny@intel-research.net 


Link: http://intel-research.net/Publications/Seattle/062120021256_55.pdf

En el paper se discute cómo el evaluar las aplicaciones de cómputo ubicuo presentan algunos retos en investigación sobre aquellos asociados a las aplicaciones tradicionales como lo son las de escritorio y las móviles.

1. Propiedades de las aplicaciones de cómputo ubicuo e implicaciones para evaluacion.

Se proponen varias propiedades que son características de la computación ubicua. A partir de eso se pensó en los aspectos que podrian tener implicación para evaluación.

Las características fueron:

Integración física: Kindberg y Fox usan ese término para describir el uso de sensores o actuadores para unir un sistema a entidades físicas. Como lo son objetos que vemos día con día y que no están asociados con alguna funcionalidad eléctrica como: papeles, tazas, mochilas, etc.

Esta abarca el uso de tecnologías de cómputo ubicuo en actividades como experimentos de laboratorio o visitas a un muséo.

Interoperabilidad espontanea: Los sistemas tradicionales como los sistemas de escritorio funcionan con una configuración de manera que cuando se agrega nuevo hardware/software requieren de alguna actualización o cambio en la configuración.

En la computación ubicua se busca eliminar eso, estos estan en constante cambio, los usuarios y los dispositivos dejan el sistema continuamente, el sistema no puede apagarse, y el usuario espera que el sistema esté disponible una vez que se entra en el cuarto, edificio, etc.

Por eso se le llama interoperabilidad espontanea, ya que se adapta al cambio de forma pasiva, cambiando circuunstancias sin entretener al usuario.

Con estas características se elabora la lista de aspectos que puedan tener implicacones para evaluar.
  • Intercalación: Un aspecto de la integración física es que las aplicaciones ubicuas están diseñadas para intercalar las actividades del usuario que no estén relacionadas con dispositivos como computadoras. Para que las aplicaciones ubicuas sean utiles, no debe haber interrupciones en estas actividades.
  • Diseño de interacción: Es importante evitar interacciones con ratón o teclado. Esto es porque interactuar con ciertas actividades via habla, gestos o manipulaciones fisicas de objetos son más apropiadas. Algunas mediciones deberian ser: que tan natural es la interacción, que tan robusto es el reconocimiento de interacciones para ser usable, grado de soporte para usuarios novatos y expertos. Estas evaluaciones toman lugar a menudo en ambientes colaborativos, así que es necesario capturar y sincronizar multiples interacciones.
  • Interferencias de contexto y actividad: Algunos sistemas ubicuos utilizan la información proporcionada por los sensores y actuadores para hacer inferencias acerca de lo que el usuario está haciendo, su posición, y qué acciones serían útiles para el usuario. Los evaluadores deben medir la precisión de las inferencias y la adecuación de las acciones resultantes adoptadas por el sistema. También deben evaluar lo fácil que es para el usuario para deshacer las acciones deseadas.
  • Límites de Responsabilidad: Puede ser difícil para el usuario para determinar lo que la aplicación ubicua puede hacer y la división de responsabilidades entre el usuario y la aplicación. Esto es particularmente cierto ya que los usuarios se mueven entre diferentes entornos ubicuos. Por ejemplo, un usuario puede preguntarse si la "habitación inteligente" localizará automáticamente sus diapositivas sobre la base de la agenda, o si tiene que llevar físicamente sus diapositivas. Las evaluaciones de los limites deben recoger casos en que hay algo que el usuario espera que suceda pero no es así.
  • Seguridad y privacidad: Las cuestiones de privacidad y la confianza se producen cuando los usuarios interactúan con los ambientes ubicuos inalámbricos, sobre todo cuando no estan familiarizados con los ambientes ubicuos. Los evaluadores deben determinar si el usuario entiende lo que los registros quedan atrás (si existen) después de que deja el ambiente ubicuo. Si se guarda la información, el usuario tiene que entender que va a tener acceso a esa información y cómo se va a utilizar.Los investigadores necesitan explorar diferentes formas de transmitir la seguridad y la privacidad de la información a los usuarios, el nivel de transmisión de datos que necesitan ser aprobados explícitamente por los usuarios, y qué niveles se de datos acordó implícitamente utilizar en la aplicación. Las evaluaciones de la seguridad y la privacidad deben consistir en datos cuantitativos y valoraciones subjetivas por parte de los usuarios del sistema. Calificaciones cuantitativas pueden identificar incidentes en los que los usuarios se niegan a permitir o intentan prohibir el sistema de obtención de datos. Calificaciones subjetivas pueden pedir a los usuarios lo cómodos que se sienten con el sistema, cómo y dónde se creen se están utilizando los datos del sistema y de que tan ciertas son sus respuestas.

2. Trabajo previo en la evaluación de aplicaciones ubicuas

Classroom 2000: Prepara un áula de aprendizaje equipada con tecnologíaque captura y organiza lecturas en forma que puede ser facilmente accesada en otro momento. Su evaluacion fue de 2 etapas: en su primer prototipo fue evaluada en una escala pequeña sin un control de grupos, despues tuvo una segunda evaluacion, esta vez sumativa con un sistema más robusto que involucraba 60 clases en distintas instituciones.

Su evaluación fué la más extendida hasta ahora reportada. Tomó 18 meses y el uso de varios prototipos en 60 cursos de licenciatura y posgrado y una variedad de universidades. Se usaron grupos de control. Los evaluadores reunieron estadisticas cuantitativas de uso, datos cualitativos del impacto de aprendizaje. Estos datos proporcionaron una visión global de como los instrumentos del aula alteraron la experiencia de clases, así como la forma en que modificba el comortamiento de los estudiantes fuera de clase.

Tivoli: Es un capturador de reuniones. Fué evaluado en 60 reuniones acerca de la propiedad intelectual en Xerox PARC sobre un periodo de 2 años. La informacion fue obtenida de varias formas: grabaciones en video, entrevistas, logs, etc.

3. Viendo a futuro.

Las aplicaciones ubicuas implican mucho más que "computacion". Puesto a que están situadas en entornos fisicos y cambian la forma en que las personas interactuan con estos entronos.

Los casos de estudio ilustran las propiedades de la computacion ubicua que identifican las necesidades de un conjunto nuevo de medidas de evaluación. Muestran algunas de las dificultades que se plantean en la práctica.

Hay una necesidad de desarrollar tecnicas de evaluación que incluyan captura de datos y metodos de análisis para direccionar las propiedades de la computacion ubicua a un ciclo de diseño mas temprano.

martes, 16 de abril de 2013

[CÓMPUTO UBICUO] Lab 7: Técnicas de localización en interiores y/o exteriores. Resumen de paper.

Scout: Outdoor Localization Using Active RFID Technology


Xin Huang, Ramakrishna Janaswamy, Aura Ganz
Department of Electrical and Computer Engineering
University of Massachusetts Amherst, MA 01003
{xhuang; janaswamy; ganz}@ecs.umass.edu



La localización hoy en día es esencial, sin embargo, utilizar los métodos clasicos como el uso de GPS o derivados, son metodos no muy buenos a la hora de buscar objetos pequeños de poder limitado. En el paper se presenta una tecnología llamada "Scout", un sistema de localización sencillo y facil de usar. Utiliza sistemas RFID activos y algoritmos probabilisticos de localización. Se investiga el rendimiento de dependencia en un numero de sistemas y parametros ambientales.

1. Introducción:
Las comunicaciones inalámbricas, computadoras portátiles y sensores inteligentes, son cada vez más populares en la vida diaria y suponen un plus a la computación ubicua y espacios inteligentes donde los objetos fisicos se comunican con los usuarios.

Se busca desarrollar sistemas que puedan ser utilisados en distintos escenarios como seguimiento vehicular, manejo de desastres, educación, espacios de información, etc. El paper se enfoca en la localización fuera donde se propone la tecnología Scout, que provee una solución efectiva y de bajo costo para hacer seguimiento de un gran número de objetos pequeños.

En estos días se utiliza tecnologías como GPS o posicionamiento celular con técnicas como triangulación, o usando otras tecnologías como "angulo de llegada" (AOA), "tiempo de llegada" (TOA), etc. Sin embargo, debido a su gran tamaño y sus costos no tan accesibles, ademas de el gasto de energía que tienen, no son buenos sistemas para el uso que se desea dar.

La tecnología RFID es barata y utiliza poca energía, además de que son de tamaño pequeño. Debido a su potencial, son un candidato perfecto para convertirse en candidato para la localización en masas.

2. Systema Scout:
El sistema Scout utiliza sistemas RFID de largo alcance, similar al sistema Mantis, que opera a 433MHz dando un rango de 500 metros.

2.1 Layout de red:

El sistema consiste en 3 niveles:

  • Servidores
  • Lectores RFID
  • Tags RFID


Los Tags RFID son de 2 tipos, de objeto y de referencia, los tags de objeto son ID's unicos para cada cosa que se está siguiendo. LOa tags de referencia sirven para calibrar parametros ambientales, tambien poseen un ID único. Una vez activadas, los tags emitirán una señal periodicamente con sus ID's.

Los lectores RFID son parte escencial del uncionamiento; Toda el área está cubierta por lectores RFID conectados en red. Los lectores reciben información del ID de los tags, así como su RSSI, por lo que pueden medir la intensidad de señal. Al estar conectados en red se puede triangular la posición de un objeto con su tag.

Los servidores están conectados de tal forma que al menos un tag puede alcanzar un servidor.

El sistema Scout funciona de la siguiente manera:

Una vez iniciado, los lectores empezarán a detectar señal RSSI de los RFID tags. Si están localizados en un rango de lectura, el lector recolecará su información y la enviará a los servidores. Los servidores estimarán la posición utilizando algoritmos de localización provabilística.

2.2 Esquema de localización probabilistica:

El algoritmo propuesto estima la localización de los objetos basado en la información dada por el RSSI de los tags de los objetos y tambien por los tags de referencia de los provistas por los lectores. Sin embargo, ocurren ciertos errores asociados con la propagación RF. Esto hace a que ciertos factores causen variaciones aleatorias en la señal recibida. Esto hace imposible crear una relacion determinista entre la señal RSSI y la distancia de propagación.

EL algoritmo de Scout es robusto a este tipo de errores causados por variaciones en la propagación. Se adapta a las condiciones ambientales para funcionar con los siguientes pasos:
  • Se calibra los parametros de propagación usando los tags de referencia.
  • Se estima la distancia entre el objeto y los lectores basado en el modelo probabilistico anteriormente descrito.
  • Se aplica una interface Bayesiana para determinar la localización.
EL algoritmo se basa en las siguientes suposiciones:
  1. Cualquier objeto localizado en el area puede ser detectado por al menos tres lectores RFID.
  2. Los lectores tienen posición conocida y constantemente se calibran.
  3. Hay un tag de referencia por cada lector, y su localización es conocida.
  4. EL poder de transmisión de todos los tags es idéntica.
3. Simulación:

En esta sección se evalua el rendimiento del esquema propuesto, primero se desarrolla una medida de desempeño para añadir presición. Despues se ilustra los resultados visuales que representan las areas resultantes estimadas para multiples objetos. Finalmente se investiga el desempeño de dependencia del esquema sobre el número de parametros ambientales, algoritmos, sistemas, etc.

Se denotó la medida como Error de Distancia Media (AED). La entrada del algoritmo es un estimado del área que está compuesta por varias celdas en grid.

AED es el error entre el objeto y los puntos grid dentro del área estimada. Refleja la presición del algoritmo, entre mas pequeño sea el número, mejor presición.

Para visuaizar, se utilizó MATLAB, se simuló una detección básica. Se consideraron factores ambientales representados por variables aleatorias Gaussianas.

4. Conclusión:

En el paper se presenta una solución para sistemas de localización abiertos basados en tags RFID activos. Así como una aproximación del algoritmo probabilístico para localización usando solo señal RSSI.

Se presentan varias simulaciones donde se toman en cuenta las variables que da el entorno. Así como otras variables agregadas como ruido aleatorio, recursividad, etc.

Se llega a la conclusión de que el sistema es viable para ser un candidato de bajo costo y efectivo para ser candidato para la localización de objetos abierta.

martes, 9 de abril de 2013

[CÓMPUTO UBICUO] Lab 6: Sugerencias Software y Hardware


Para este laboratorio se hacen de nuevo sugerencias pero esta vez sobre hardware y software de una forma más concisa.

Alarma inteligente

Es un buen proyecto y lo establecen muy bien, sin embargo muchos autos ya tienen GPS incluido, claro que hay que pensar que no todos tienen GPS pero la pregunta sería, ¿Cúal sería la solución para quienes ya tienen un GPS?. Otra cosa es que una conexión 3G podria ser algo cara, utilizar un dispositivo móvil que a su vez ya incluye la tecnología GPS podría ser una buena alternativa.

Oficina personalizada

En general dieron una buena presentación, definiendo todo lo que utilizarán y muy organizado. Sin embargo en donde mencionan la parte de los "Clientes" creo que utilizar un dispositivo móvil que ya tenga estas tecnologías o alguna alternativa es mas fácil. Solo necesitarían crear una app para esto.

Buscar cosas por bluethoot

Muy buen proyecto, es práctico y muy útil. Podrían agregar una especie de monitor de objetos, es decir, una aplicación móvil o web que tenga un log de las ultimas posiciones y el total de objetos registrados, ya que si la posición del log es la misma que la posición actual, puede haber ahorro de energía.

Galería inteligente

Me parece que hay mucho más que agregar al proyecto. Cámaras que detecten movimiento serían muy útiles, aún mejor si logran detectar personas. Estas tienen mayor rango en una zona que los sensores de proximidad. Y una sugerencia independientemente de si usan sensores o cámaras, sería que si la persona se acerca por unos segundos, entonces empiece la reproducción del sonido, ya que sería algo molesto que alguien pase por una obra que no le interesa y empiece la descripción.

Casa inteligente

Cerrar y abrir puertas y un simulador de presencia, como que le falta algo. Cosas como apagar el televisor si no hay nadie o controlar la iluminación de la misma forma suenan a casa inteligente. Hablan de seguridad pero no queda muy claro que utilizarán para esta o como piensan implementarla.

CarNXP

Creo que la música sale sobrando pero está bien. Usar algoritmos que calculen la distancia recorrida pueden ser útiles, pero Google tiene web services que ya hacen eso. Calcular cuanta gasolina se gasta es algo demasiado variable, depende mucho de la velocidad del automovil.

lunes, 4 de marzo de 2013

[CÓMPUTO UBICUO] Lab 5: Catálogo y Proveedores

Para este laboratorio se hará una lista de los proveedores de artículos que probablemente necesitemos además de tales artículos.

HARDWARE

El proyecto consiste en un garage automático que se abre vía smartphone o web service. Necesitaremos el siguiente hardware:

  • Smartphone para controlar el garage.
  • Adaptadores Bluetooth para comunicar el garage.
  • Computadora conectada al garage que lee el web service.
  • Servomotores (para simular el garage en una maqueta).
  • Arduino para interconectar todo.
Smartphone

La mayoría de nosotros cuenta con un smartphone con las características necesarias para el prototipo; Android 2.2 o mayor, WiFi, Bluetooth, etc.

Personalmente cuento con un celular chino con estas características, se trata del Star X12 (clon barato del Xperia X12) que me regaló mi papá.
Aunque no es muy rápido, me sacó de apuros en "Ingeniería de dispositivos móviles" además de que me ayuda en mi trabajo en algunas ocaciones. Desde luego esta solo es una de las varias terminales de prueba.

Bluetooth

Este es para conectarlo a un arduino que será el núcleo del garage. Servirá para comunicarse con el smartphone que correrá alguna aplicación para abrir el garage. La comunicación debe ser preferentemente de forma autónoma, es decir, el usuario lo único que tiene que hacer es acercarse con su móvil al garage dentro de su auto.

Para esto he visto algunas piezas por internet que pueden ser de interés:
  • Bluetooth serial converter UART interface 9600 bps.
  • Bluetooth Shield.
UART

Esta pieza permitiría comunicación bluetooth entre arduino y smartphone.
Tiene un precio de 28 dolares (envío no incluido) pero se puede encontrar hasta en 14 dolares si se busca bien.

La tienda EIO (Electronic Inventory Online) lo tiene, la cual se especializa en productos de electrónica. Cuentan con servicio al cliente y existe la capacidad de verificar el estado del pedido.

El enlace es el siguiente:

Bluetooth Shield

Se trata de un shield para arduino que cuenta con comunicación serial para establecer comunicación. Su precio en Seeedstudio es de 23 dolares. Lo curioso es que este shield contiene el UART, hace mucho más sencilla su programación.
Es compatible con Android e iOS, inclusive con otros dispositivos.

Seedstudio es una tienda de electrónica online especializada en microcontroladores, sobre todo porque tienen su propio clon de arduino con algunas mejoras (Seeeduino). Además venden todo tipo de electrónica, así como robótica entre otras cosas.

El enlace es el siguiente:

Computadora

Para este prototipo conectaremos el arduino directamente a una computadora para leer el web service. Podemos usar cualquier computadora, pero por motivos de comodidad es mejor usar una pequeña.

Se habló ligeramente de la posibilidad de conseguir una Raspberry Pi, una computadora con procesador ARM con poder suficiente para realizar esta tarea.
Los precios son variados dependiendo de la tienda, los envíos tardan hasta 6 semanas. Sin embargo se pueden conseguir vía mercadolibre a precios regulares.

Servomotores

Se planea hacer una versión miniatura de el garage, para ello necesitaremos motores para darle movimiento. Estos motores irán conectados al arduino quien los controlará.

Para esto busqué un poco más cerca, en 5hz-electrónica. Tienen el SM-S3317S, un pequeño servo de 360º de giro. Podría servir para levantar la puerta mediante una cadena.
Su precio es de 220 pesos en 5hz-electrónica.


Arduino

El centro de todo estará en el arduino, ya que es el que controlará el garage, recibirá la señal de abrir, etc. Y tampoco me fui lejos, 5hz también tiene arduinos y de varias versiones. Yo tengo mi propio arduino que compré en sexto semestre y aun no se quema. Pero como está expuesto a "accidentes" debemos contar con respaldo.
Este es el arduino UNO R3, el que compré y el que sigue funcionando. Se adquiere por un precio de 370 pesos y es muy práctico.


SOFTWARE

Para el software se utilizarán las herramientas habituales:
  • Python, para escribir (tentativamente) los web services y parte de la comunicación entre arduino y la computadora.
  • Java, para escribir la aplicación Android.
  • Software de arduino.
  • PHP, HTML, SQL posiblemente para complementar el web service.
Para escribir las aplicaciones en android se requiere de un kit; el Android SDK, que contiene las librerias de android necesarias. Tambien viene incluido la IDE Eclipse que se está haciendo un estandar para programar en Java.

La ventaja de utilizar Java y Android es que se puede programar un mismo proyecto en distintas plataformas.

El enlace es:

Adicionalmente se utilizará el software para programar el arduino, tambien es multiplataforma y es de facil uso. Su lenguaje tiene una sintaxis similar a C. Incorpora muchos ejemplos y es compatible con muchas placas no solo arduino, sino tambien las mismas hechas por los usuarios.

Su enlace es:

Fuentes:

lunes, 25 de febrero de 2013

[CÓMPUTO UBICUO] Lab 4: Recomendaciones y comentarios

Automóvil Seguro
  • Algo que ya se mencionó durante la clase y de menor importancia, es el uso de "radio buttons" en lugar de "checkboxes" para las encuestas, que aunque no influya en gran medida en el proyecto, quizá algunos de los datos tengan más de una opción señalada.
  • No seleccionaron las preguntas "obligatorias" tal cual, si bien muchas de las preguntas "opcionales" parecen de mayor o igual importancia.
  • Entrando a lo que es el proyecto, muchas de las características que mencionan como posibles adiciones, podrian encajar perfectamente en el mismo proyecto, como la forma de controlar la alarma; las opciones son vía móvil, vía internet, vía control remoto, cuando en realidad controlar la alarma remotamente vía internet a través del móvil es posible.
  • En si hay poca planeación, sus conclusiones solo muestran una especie de idea general de lo que recolectaron de los usuarios, y no una idea de lo que ahora harán en base a esos resultados.

  • La encuesta está a un nivel de lenguaje un poco elevado para un usuario común, podría causar un poco de confusión al encuestado y hacer a que responda solo por responder. Quizá enfocar las preguntas un poco más al proyecto.
  • No muestran gráficos muy detallados, solo muestran unos cuantos, quizá debieron mostrar gráficos para preguntas de importancia mayor como el inicio de sesión ideal o problemas frecuentes de privacidad.
  • El proyecto suena muy bien, pero hablan de una aplicación grande, es decir, abarcan cuestiones de seguridad y de entretenimiento, la idea no es mala, pero si podrían dividir un poco cada cosa. Además tiene mucho potencial no solo para esas cuestiones, facilmente se podría hablar de cosas como autentificación en sitios web, cajeros automáticos, etc.

Oficina Personalizada
  • La parte de la encuesta me parece muy buena, se cubrieron varios aspectos de lo que pretenden hacer, sin embargo no concluyen, o al menos no recuerdo unas palabras acerca de lo que ahora implementarán como siguiente paso.
  • Lo de las luces automáticas son cosas que ya existen y son ampliamente personalizables, cosa que les ahorraría mucho trabajo, sin embargo imagino que harán su propia versión. Deben de tomar en cuenta cosas como ahorro energético, ya que la luz de los focos es lo que generalmente gasta más energía. Se les sugiere utilizar energía renobable, pues utilizar un sistema de recarga solar no es mala idea (Claro está que hablamos de una versión a escala por ahora).

  • Como se mencionó en clase, creo que utilizan un lenguaje un poco elevado para un usuario común, y eso causaría confusiones. Sin embargo logran entenderse.
  • La idea creo que es mejor que la enfoquen a alguna aplicación móvil, ya que es igual de fiable. Imaginando un escenario, una persona prefiere comprar un smartphone a cada uno de los de su familia, ya que ofrece mucho más, y existen API's que ayudarían mucho en este proyecto. Google Code ofrece la mayoría de lo que necesitan si deciden ir por el rumbo de smartphone.
  • Si deciden irse por el rumbo de un dispositivo de localización, aun así pueden integrar servicios como Twitter y Facebook para estar más en contacto.

  • Una idea muy buena pero la opinión de sus encuestados no es lo que esperaba (en especial por lo de los dinosaurios). Creo que la encuesta debió ser a personas que están más en contacto con estos lugares. No estoy seguro si fue así, pero se debió encuestar a gente que trabaja en los museos o a personas que salen de ellos.
  • La idea de interacción con el smartphone ya existe, pero es muy básica, en mi opinión pueden hacer algo mejor de los que ya lo intentaron. Además no solo dar soporte a un museo o galería en específico, sino tratar de "vender" el producto a varios museos.

  • Todo está bien, pero pienso que si tuviera algo así en días que estoy enfermo entonces sufriría unos minutos. Imagino que planean alguna clase de panel de control que diera la opción de suspender la alarma por las próximas horas y que al finalizar el tiempo pregunte al usuario si desea reanudar o suspender por otro periodo de tiempo.

  • La idea del simulador de presencia es excelente y algo inesperado, la verdad nunca había pensado en algo parecido, quizá la idea existía pero nunca la he visto en marcha. Tomen en cuenta cosas como ahorro energético si continúan con esa idea.
  • Deberían tener en mente implementar un panel de control en linea para ver el estado de las cerraduras, por si al usuario se le olvida.

  • Solo en cuanto a la perdida de dispositivo, seria fatal que descubrieran el uso del smartphone. Creo que se debería de contar con un sistema de apagado. Es decir, que en caso de perder el smartphone llave, acceder vía internet a la configuración y dar de baja el dispositivo, de esa manera permitir utilizar el vehículo sin el dispositivo, mas que con su propia llave de fábrica.

martes, 19 de febrero de 2013

[CÓMPUTO UBICUO] Lab 3: Técnicas de diseño conceptual

Diseño conceptual

Cuando se trabaja bajo el análisis conceptual de una situación, nos referimos a la abstracción de hechos reales de los cuales se emite un concepto o es posible hacer una idea de ello. Para ello se necesitan requerimientos previamente formulados por los usuarios. Con estos se puede iniciar a la creación de un esquema conceptual con el cual se podrá realzar una descripión de alto nivel. Para manipular el esquema se utiliza un modelo conceptual que proporciona un conjunto de símbolos (estándares) para su creación.

Algunas fases del diseño conceptual y sus características son:

Teorías/especulación: Para algunas personas, diseño conceptual no es mas que la fabricación de prototipos, y eventualmente se convertirán en productos o bien solo un diseño futurista que no es práctico.

Significancia: El diseño conceptual es solo la primera fase de un diseño donde los dibujos son el foco principal, que se componen de planos y secciones simples.

Características: Fases específicas, o pasos, del diseño conceptual que son necesarias para transferir las ideas hacia los requisitos. Incluyen una descripción o definición general del concepto

Tipos de conceptos:

  • Textuales: Descripción de la idea del producto que generalmente consiste en la descripción de lo que uno puede hacer con la idea del producto.
  • Pictográficos: Son representaciones visuales de la idea general del uso del producto. Dependiendo del producto, estas son simples o complejas en cuanto al tipo de uso o la idea del producto.
  • Animaciones: Un concepto nuevo que consiste en recrear la idea del uso del producto mediante el uso de animaciones. Generalmente un video también encaja en este tipo de concepto, ya que muestra literalmente como se usa tal producto.
  • Mock-ups: son un tipo de prototipo que sólo muestra las características externas de una idea de producto.
Diseño contextual

Es un metodo de diseño centrado en el usuario que permite entender mejor el entorno donde se trabaja y las necesidades que se tienen que cumplir los sistemas interactivos que para ellos se desarrollan.

H. BEYER y K. HOLTZBLATT son los máximos exponentes del diseño contextual, describen el proceso que guía a los equipos de diseño en el mencionado conocimiento y comprensión para rediseñar el trabajo de las personas mediante la ayuda de nuevos sistemas software.

El proceso incorpora una gran cantidad de técnicas centradas en el usuario en un proceso de diseño integado que se dividen en seis partes diferentes:
  • Integración contextual: Revela detalles y motivaciones implicitas en el trabajo de las personas, hace del cliente y su trabajo necesidades reales de los diseñadores y crea un conocimiento compartido para el equipo.
  • Modelado de trabajo: Proporciona un lenguaje para hablar sobre el trabajo a compartir por los equipos y por medio de una serie de modelos se representa el trabajo de los clientes que ayudan a analizar los datos recogidos. Los modelos son:
    • El modelo de Flujo define cómo se divide el trabajo entre varias personas y cómo éstas se coordinan para realizar dicho trabajo.
    • El modelo Cultural identifica procesos culturales y políticas de actuación que condiciona el trabajo.
    • El modelo de Secuencias muestra detalladamente los pasos seguidos para el seguimiento de las diferentes tareas.
    • El modelo Físico representa el entorno físico en el que se realiza el trabajo incluyendo el espacio de trabajo, el posicionamiento de los objetos y como es que todos estos elementos influyen en la forma de trabajo.
    • El modelo de Artefactos muestra como se utilizan y estructuran los diferentes objetos durante el transcurso del trabajo.
  • Consolidación: Proporciona un mapa de la población de los clientes o usuarios, facilita la identficación de las necesidades del cliente mostrando la estructura organizacional que utilizan los usuarios mientras realizan su trabajo.
  • Rediseño del trabajo: Orienta al equipo para mejorar el trabajo evitando que este se "deje llevar" por la tecnología.
  • Diseño del Entorno del Usuario: Mantiene la coherencia del sistema desde el punto de vista del usuario capturando la estructura, la funcionalidad y el flujo del sistema. A su vez orienta al equipo de diseño en el uso del sistema y no tanto en la interfaz de usuario o en la implementación. 
  • Maquetas y tests con clientes: Las principales virtudes de esta parte son que permite determinar errores en el nuevo diseño incluso antes de empezar con la codificación a la vez que crea el clima necesario para que los usuarios se involucren en el diseño del sistema como si de unos socios tecnológicos se tratara.

martes, 12 de febrero de 2013

[CÓMPUTO UBICUO] Lab2: Desarrollos similares (Tecnologías emergentes).

En esta entrada para el laboratorio de sistemas inteligentes hablaré sobre 3 productos que encontré entre las patentes y que tienen una función similar al proyecto que desarrollaremos a lo largo del semestre.

Los productos son:

Passive automatic door opener.
Fully automatic garage door opener.
Monitored radio frequency door edge sensor.

Passive automatic door opener

Consiste en una puerta conectada en red a un sistema GPS que monitorea constantemente la posición de un dispositivo ubicado en el vehículo. Un vehículo equipado con un controlador GPS y un receptor es capaz de controlar tal sistema basado en las posiciones preferidas del usuario.


El equipo consiste en:

  • Un sistema de monitoreo GPS conectado a alguna red local en el hogar que controla la puerta. Busca señales de un dispositivo que concuerde con el identificador y al encontrarlas monitorea su posición hasta llegar a un destino seleccionado por el usuario.
  • Un receptor GPS montado al vehículo que mantiene la posición del vehículo.
  • Un transmisor de señales que se comunica con el sistema del hogar una vez que se encuentren en un rango aceptable de comunican.
  • Un sistema de cámaras que detecta el vehículo una vez dentro del garage. (Completamente opcional. El mismo sistema establece la posición del vehículo dentro para cerrar las puertas)
  • Además de varios dispositivos mecánicos que sirven para abrir y cerrar la puerta. Estos van conectados al sistema de monitoreo.


Fully automatic garage door opener

Un sistema automático para abrir y cerrar la puerta del garage que funciona a través de infrarrojos. Un dispositivo infrarrojo detecta cuando el vehículo está frente a la puerta.

La idea es sencilla, en el interior y el exterior hay sensores infrarrojos que detectan la posición de un objeto, un sistema montado en el vehículo para controlar la puerta a cierta distancia, y una serie de sistemas mecánicos que controlan la puerta.
  • Los sistemas infrarrojos están colocados fuera y dentro del garage, por fuera esta colocado uno que detecta un objeto al cortar el haz de luz infrarroja.
  • En el suelo hay un segundo sistema que detecta la posición del vehículo mediante una fotocelda ubicada debajo del motor que verifica que se trata realmente del vehículo del usuario, es controlado por el primero y el encargado de abrir la puerta.
  • Dentro del garage hay un tercer sistema que detecta cuando el vehículo está dentro, es un sistema de cámaras e infrarrojos que verifican la posición correcta, y es el que se encarga de cerrar la puerta.
  • Por ultimo una serie de sistemas mecánicos que abren y cierran la puerta.

Monitored radio frequency door edge sensor

El tercer sistema se trata de un sensor para abrir y cerrar la puerta no solo del garage, está pensado para implementación más allá del proyecto.

Consiste en un sensor que detecta la proximidad vía radiofrecuencia. El sistema puede ser semi-automático o automático dependiendo de las preferencias del usuario. También cuenta con sistemas que  detectan obstrucciones para evitar daños.

El sistema completo consiste en lo siguiente:

  • Un sistema de radiofrecuencia montado al vehículo, un transceptor se encuentra enviando señales desde el vehículo y se sincroniza con el sistema montado en el hogar. Cuando la frecuencia es mayor, el sistema abre la puerta.
  • Un sistema de radiofrecuencia igual al del vehículo pero en lugar de enviar, recibe señales.
  • Un control remoto opcional que abre la puerta al recibir la frecuencia correcta.
  • Un sistema de detección de proximidad, si un obstáculo en la puerta impide abrirla o cerrarla correctamente, este hará a que mantenga su estado actual, aun cuando el sistema este activo.

Conclusiones

Los 3 sistemas a mi parecer son bastante buenos y útiles, además de implementables en el proyecto. Pero algunas cosas habría que modificarlas. 

En el caso del sistema GPS, es una excelente idea mantener conectado el vehículo a un sistema de posicionamiento global, pero mantener un sistema en el hogar parece muy trivial, aun cuando solo sirve para detectar la posición del vehículo. Desde mi punto de vista, una mejor implementación, y que fue una de las primeras ideas del proyecto, era un sistema que estuviera conectado a un servicio web que monitoreara las posiciones cada sierto tiempo en base a su posición actual. Esto debido a que es mucho más barato y las posiciones son más exactas que utilizar un sistema GPS hogareño.

El caso de los infrarrojos, es también muy buena, pero susceptible a que alguien haga el mal. El infrarrojo del suelo detecta una fotocelda brillante, puesta bajo el motor del vehículo. Cualquiera podría conseguir una fotocelda y obstruir el haz de luz para simular un vehículo. Otra desventaja es que en algún golpe, el vehículo puede rayar o perder la fotocelda.

El ultimo sistema es el más fiable y barato, un par de tranceptores que al encontrar su propia frecuencia puedan interactuar. Ademas de un sistema que detecte obstaculos, este ultimo suena a una implementacion que puede servir no solo al proyecto de nosotros, sino a cualquier proyecto. Las desventajas mas directas son que el usuario aveces tendria que interactuar cuando la radiofrecuencia no funcione correctamente, debido a que es más debil y facil de perder en frecuencias cortas. La solucion es usar tranceptores de mayor potencia o buscar la comunicación via dispositivos wi-fi.

Fuentes

Link 1
Link 2
Link 3

lunes, 11 de febrero de 2013

[CÓMPUTO UBICUO] Lab1: Desarrollos similares (Tecnologías existentes)

Para esta entrada hablaré de 3 productos que ya se han implementado. Seleccioné los siguientes productos:

Craftsman's AssureLink.
BT Mate.
NiO WiFi Garage Door Opener.

Craftsman's AssureLink.

Se trata de un sistema que se conecta a cualquier dispositivo móvil compatible para poder abrir la puerta del garage entre otras cosas como encender las luces del porche o del interior.

AssureLink se conecta a través de ethernet al router de la casa para poder operar y comunicarse con móviles de sistema operativo Android, iOS, BlackBerry, etc.


Además puede ser monitoreado desde cualquier parte del mundo, ya que los usuarios pueden iniciar secion desde una web para controlar el sistema, o bien, el sistema dispone de una aplicación en la applestore para hacer la misma función.

Una de las cosas interesantes es que mediante el servicio telefónico se puede dar permisos a los usuarios para acceder a las funciones de AssureLink.

BT Mate.

Se trata de una aplicación para Android que se conecta con un dispositivo bluetooth para abrir la puerta del garage. Para esto se tiene que hacer una modificación a un sistema mecánico para adaptarle un receptor bluetooth.

BT Mate permite conectarse a múltiples sistemas al mismo tiempo con el uso de un solo dispositivo. Además permite el uso de un auricular como controlador. Siendo esta función la que la hace una aplicación de paga.

Para hacerla funcionar es necesario tener un sistema controlador para la puerta e instalarle un receptor, generlamente los receptores se venden en tiendas de electrónica. Los desarrolladores recomiendan utilizar algún sistema ya fabricado, ya que también se puede utilizar uno hecho en casa pero no se garantiza el funcionamiento.

NiO WiFi Garage Door Opener.

Es un sistema muy simple que consiste en un dispositivo para abrir la puerta del garage a través de la conección WiFi. El sistema se conecta a internet y puede ser controlado desde cualquier dispositivo en el mundo o bien se puede conectar a la red local y ser controlado por cualquiera en la misma red.


El sistema es sencillo pero muy potente, ya que cualquiera podría desarrollar alguna aplicación libre para controlarlo, lo que supone ventajas de acceso sin tener que acceder a la propia pagina web.

Para controlarlo, es necesario autentificarse. Ya que el mismo sistema brinda una interfaz web sencilla para su control.

Conclusiones

Desde mi punto de vista, creo que los servicios que ofrecen los anteriores son muy útiles pero les falta algo. La mayoría de estos sistemas esperan que el usuario posea una red y que sepa configurarla, cosa que no se da en todos los casos.

AssureLink por ejemlo, espera que tengamos un sistema de red para poder ser controlado, sin el es imposible utilizarlo, al igual que NiO.

Por otro lado NiO, no requiere de mucha configuración de red, de hecho una vez conectado el sistema, ya ofrece una pequeña interfaz web para controlarlo localmente. Pero se ve que puede ser mejor utilizable, como AssureLink, ya que permite controlar, no solo el garage, sino todo un sistema cableado.

BT Mate es una buena aplicación, pero espera a que el usuario tenga un sistema ya instalado, no hay problema con ello, solo que su precio quizá sea muy elevado para lo que ofrece.

Por ultimo, mencionar que en los 3 casos se ven grandes oportunidades de mejora, y muchas posibilidades para hacer crecer el proyecto, tomando un poco de cada ejemplo.

Fuentes:
AssureLink
NiO
BT Mate