ESTUDIO COMPARATIVO DE SISTEMAS OPERATIVOS DE TIEMPO REAL APLICADO A REDES DE SENSORES INALAMBRICAS.

Tamaño: px
Comenzar la demostración a partir de la página:

Download "ESTUDIO COMPARATIVO DE SISTEMAS OPERATIVOS DE TIEMPO REAL APLICADO A REDES DE SENSORES INALAMBRICAS."

Transcripción

1 ESTUDIO COMPARATIVO DE SISTEMAS OPERATIVOS DE TIEMPO REAL APLICADO A REDES DE SENSORES INALAMBRICAS. José Ulloa Suárez. Sociedad Agrícola Ojos Buenos Ltda.

2 INDICE 1 Introducción Desarrollo Características de las redes de sensores Presentación de distintos Sistemas Operativos TinyOS PalOS SOS Comparaciones entre estos Sistemas Conclusiones Referencias

3 1 Introducción Las redes de sensores inalámbricas se insertan bajo un nuevo enfoque en el desarrollo de tecnologías para la obtención de datos, y que son aplicables a variados campos, tales como el policial (seguridad en recintos), industrial (vigilar el estado de maquinarias, de procesos de ensamblaje, etc ), agrícola (sensar estado de la tierra, el crecimiento de los frutos, etc) entre otros. Principalmente estas apuntan a integrar sistemas autónomos, para la obtención conjunta y posterior procesamiento de información. Específicamente hablamos de dispositivos autónomos distribuidos sobre una región de trabajo, capaces de establecer comunicación sin cables entre ellos, y que incluyen además medir variables físico-ambientales, ya sea niveles de temperatura, humedad, etc., para luego enviar los datos obtenidos a un servidor central en el cual se almacenarán y procesarán. A través de redes de sensores, se puede integrar funcionalidades que antes eran independientes unas de otras, con el fin de lograr máxima eficiencia y optimización de recursos. En el presente trabajo se expondrán distintos sistemas operativos que se pueden ejecutar sobre estas plataformas. Primero será necesario contextualizar el problema, por lo que se presentarán las restricciones a cumplir tanto para los dispositivos electrónicos (microprocesadores ó microcontroladores), como para el sistema operativo. De éste ultimo, presentaremos características, comparaciones, y restricciones de uso de algunas de las propuestas presentes hoy. 3

4 2 Desarrollo 2.1 Características de las redes de sensores. Esta sección enseña los requerimientos que forman el diseño de redes de sensores 1 Tamaño físico pequeño y bajo consumo de energía. En cualquier punto de la evolución tecnológica, el tamaño y la energía han restringido el procesamiento, almacenamiento, y las capacidades de interconexión de dispositivos. Obviamente si se reduce el tamaño y la energía, estamos forzando el uso de nuevos tecnologías en hardware y asimismo en software, el cual debe ser capaz de usar de manera eficiente el procesador y la memoria, ocupando un mínimo de energía para la realización de sus tareas. Operaciones de Concurrencia Intensiva. El principal modo de operación de estos dispositivos, consiste en que fluya información de un lugar a otro, con una cantidad reducida de procesos, que se resumen en aceptar un comando, parar, pensar, y responder. Por ejemplo, la información puede ser capturada simultáneamente por sensores, manipulada, y fluir sobre la red hacia el destinatario. Alternativamente, se pueden recibir datos desde otros nodos y por ende deben ser encaminados también a su destino. En general existe poca capacidad de memoria interna, así que el almacenamiento de cantidades grandes de datos, ya sea para enviar o para ser recibidos desde otros nodos debe ser evitado. Por otra parte, cada uno de las reenvios de información (saltos) implica generalmente una gran cantidad de eventos de bajo nivel (interactuar a niveles de capa física y red) que se comunicarán con procesos de niveles superiores (es necesario desempaquetar para obtener información). Diversidad en diseño y uso: La tendencia de los dispositivos de redes de sensores es a dar respuesta a aplicaciones específicas, más que aplicaciones con fines de uso general, por lo cual sólo se compondrán de lo justo y necesario, esto motivado principalmente para reducir los costos. Dado que existe una amplia gama de usos potenciales, nuevos y variados dispositivos físicos irán apareciendo. Además en cualquier dispositivo, es importante montar fácilmente apenas los componentes de software requeridos, de manera de sintetizar el uso de los componentes de hardware. Es por eso, que estos dispositivos requieren un grado inusual de modularidad en el software. Un ambiente genérico de desarrollo es necesario, con el que se permita la construcción de aplicaciones específicas a partir de un espectro de dispositivos existentes, sin necesidad de partir de cero. Operación Robusta. Estos dispositivos serán numerosos, en gran parte desatendidos, y se esperará que tengan un tiempo operacional largo. 1 Para un mayor detalle remítase a la lectura de [1] 4

5 La implementación de técnicas tradicionales de redundancia para garantizar la confiabilidad de unidades individuales, está limitada en muchas ocasiones tanto por el espacio como por la energía. Así realzar la confiabilidad de dispositivos individuales es esencial. Además, es posible aumentar la robustez del uso tolerando fallas individuales del dispositivo. A tal efecto, el sistema operativo que funciona en un solo nodo no debe solamente ser robusto, sino también debe facilitar el desarrollo de usos distribuidos confiables. Además se tienen ciertos parámetros, que no tienen relación con restricciones de hardware, sino más bien con aspectos logísticos, entre las que se destacan: Gastos económicos que se deban incurrir por parte del que desea desarrollar una aplicación. Disponibilidad de información, en el que se incluye manuales, tutoriales y aplicaciones. Existencia de grupos de desarrolladores, de forma de asegurar una constante depuración y perfeccionamiento del sistema disponible. Modelo de programación modular, de forma de adaptarse a nuevas tecnologías, para así por ejemplo reciclar códigos. Antes de presentar los distintos sistemas operativos a analizar, resulta necesario definir ciertos aspectos generales en los sistemas operativos, las metodologías de diseño, y los porque de su aplicación a las redes de sensores inalámbricas. 2.2 Presentación de distintos Sistemas Operativos Múltiples son los sistemas operativos para sistemas embebidos, mas no todos satisfacen las restricciones que imponen las Redes de Sensores Inalámbricas (RSI), motivo por el cual quedan descartados inmediatamente. Así por ejemplo dada las restricciones de tamaño y ahorro de energía de los nodos que conformarán la red, es que todos aquellos microprocesadores que no sean de bajo consumo, quedan descartados. Por lo general entre estos, se incluyen los iguales o superiores a los clasificados como de rango mediano dentro de las categorías de microprocesadores (poseen alta disponibilidad de memoria, consumo mayor de energía, etc.). De esta forma los sistemas operativos también quedan restringidos a funcionar sobre estas arquitecturas. A continuación se presentarán tres de los principales Sistemas Operativos para redes de sensores, que cumplen con los requisitos expuestos TinyOS. El diseño de TinyOS está basado en responder a las características y necesidades de las redes de sensores, tales como integración en un tamaño físico reducido, bajo consumo de energía, operaciones de concurrencia intensiva, diversidad en diseños y usos, y finalmente operaciones robustas para facilitar el desarrollo confiable de aplicaciones. Además se encuentra optimizado en términos de uso de memoria y eficiencia de energía. Existen dos niveles de scheduler, uno para los eventos y otro para las tareas. De esta forma permitimos que los eventos (que son rápidamente ejecutables), puedan 5

6 ser realizados inmediatamente, pudiendo interrumpir a las tareas (que tienen mayor complejidad en comparación a los eventos). El diseño del Kernel de TinyOS está basado en una estructura de dos niveles de planificación: Eventos: Pensados para realizar un proceso pequeño (por ejemplo cuando el contador del timer interrumpe, o atender las interrupciones de un conversor análogo-digital). Además pueden interrumpir las tareas que se ejecutan.. El manejador de eventos es responsable de colocar la tarea en un administrador o planificador, conocido como Scheduler 2 de tareas. Tareas: Pensadas para hacer una cantidad mayor de procesamiento y que no son críticas en tiempo (por ejemplo calcular el promedio en un arreglo). Las tareas se encuentran pensadas para ser ejecutadas en su totalidad, pero la solicitud de iniciar una tarea, y el término de ella son funcionen separadas. Esta característica es propia de la programación orientada a componentes, la cual se presentará en detalle en la sección siguiente. Diseño en TinyOS: Modelo de Componentes. TinyOS ha sido desarrollado sobre NesC, un meta-lenguaje que se deriva de C, y que ha sido diseñado para responder a las necesidades que existen en los sistemas embebidos. Cada componente usa eventos y comandos que rápidamente permitan la transición de un estado a otro. Cada componente se asigna temporalmente al contexto de ejecución mientras duren los cambios del estado. Además se ha agregado a este modelo la noción de tareas, que permiten que las componentes soliciten el contexto de ejecución en la CPU para realizar cómputos o procesamientos duraderos. Estas tareas se ejecutan completamente con respecto a otras tareas, es decir, las tareas no pueden dividirse para comenzar con otra y luego retomarlas, más si pueden ser interrumpidas periódicamente por acontecimientos de una prioridad más alta (eventos). Actualmente se utiliza una cola simple FIFO (primero en entrar, primero en salir) para el scheduler, no obstante un mecanismo alternativo podría ser agregado fácilmente. Una ventaja secundaria de elegir este modelo de programación, es que propaga las abstracciones del hardware en el software. Tal como el hardware responde a cambios de estado en sus pines de entrada/salida, nuestras componentes responden a eventos y a los comandos en sus interfaces. Podemos entonces decir que TinyOS consiste en un pequeño scheduler y un gráfico de componentes. Esto se puede observar en la figura , donde se muestra como se compone una componente, destacando cuatro elementos correlacionados, y que procedemos a detallar continuación: 1. Manejador de comandos. 2. Manejador de eventos 3. Un frame 3 de tamaño fijo y estáticamente asignado, en el cual se representa el estado interno de la componente. 4. Un bloque con tareas simples. 2 Desde ahora en adelante se ocupará este término. 3 En este caso nos referimos a un bloque que proporciona el contexto en cual se ejecuta el programa y se almacenaran las variables. 6

7 Figura : Modelo de componentes de TinyOS y su interacción. La componente declara los comandos que se utilizarán y los eventos a señalizar. Con esta declaración, los gráficos de componentes (modulares) pueden ser compuestos. Este proceso de composición crea capas o niveles de componentes. Componentes de niveles superiores proveen comandos a las de niveles inferiores, y éstos señalan eventos a los componentes de un nivel superior. Para proporcionar una definición abstracta de la interacción de dos componentes vía comandos y eventos, es que se introduce una interfaz bidireccional en TinyOS. Los comandos son peticiones no-bloqueadoras, hechas a componentes de capas inferiores. Un comando proporciona retroalimentación, entregando la información del estado al que lo envió. Típicamente, el manejador de comandos pone los parámetros en el frame y agrega una tarea, en la cola de tareas, para su ejecución. La respuesta que indica si el comando fue aceptado, se puede señalar por un evento. Los comandos dejan los parámetros de las solicitudes en el frame, la necesidad de volver estado así que pospone el trabajo desperdiciador de tiempo fijando una tarea y puede llamar al comando de nivel inferior. Los manejadores de eventos son invocados por eventos de componentes de capas inferiores, o por interrupciones cuando se esta directamente conectado al hardware. Similar a los comandos, el frame será modificado y las tareas agregadas. Ambos, tareas y comandos, realizan un trabajo (fijo y pequeño) similar al de las rutinas de servicio de interrupciones. Eventos pueden llamar comandos, señales de eventos, agregar tareas, pero no pueden ser señalizados por comandos. Los eventos tienen preferencias sobre las tareas, no así viceversa, dispara interrupciones de eventos de niveles inferiores y deposita la información en el frame. Las tareas realizan el trabajo primario. se ejecutan hasta terminar y pueden ser sólo pospuestas por eventos, por ejemplo, el enrutar un paquete que llegó al nodo. Las tareas son encoladas en un planificador de tareas (task scheduler) implementado con FIFO para realizar un retorno inmediato de las rutinas manejadores de eventos y comandos. Debido a su implementación FIFO, las tareas se ejecutan secuencialmente y deben ser cortas. Alternativamente al planificador de tareas FIFO, planificadores basados en prioridades (priority-based) o basados en plazos (deadline-based), pueden ser puestos en ejecución en TinyOS. Su buen desempeño y su desarrollo abierto, han afectado positivamente en el mejoramiento del sistema en sí, e influido en la creación de herramientas que facilitan el diseño y trabajo, tales como simuladores, administradores de bases de datos, máquinas virtuales que permiten reprogramación en línea, etc. 7

8 Además destaca el hecho de contar con una cantidad numerosa de aplicaciones preconstruidas, las que implementan procesamientos de datos y algoritmos de enrutamientos. 8

9 2.2.2 PalOS. Palos está implementado en lenguaje C y por lo tanto facilita emigrar a distintos procesadores. Sin embargo, esto es sólo posible porque la capa de abstracción del hardware está introducida en el software. A continuación en la figura se muestra la esencia del software para una tarea simple. Independiente del Hardware Interfase Independiente, Dependencia con el Hardware (Procesador) figura : Estructura del Software. La capa de abstracción del hardware (Register abstraction) encapsula todos los registros en macros (de esta forma no es necesario estar configurando a nivel de bits). Esto es útil, dado que en el momento que la arquitectura del procesador cambie, sólo bastará con redefinir las macros, mientras que el código principal no necesitará ser modificado. La capa de Driver exporta las funcionalidades del hardware de una específica interfaz física sobre el procesador, a la interfaz independiente (Manager). Un driver es casi independiente del hardware del procesador. Una de las razones de su independencia, es porque distintos procesadores proveen diferentes métodos de implementación para una misma funcionalidad, por lo cual a veces es necesario especificar un orden específico en las líneas de programación. Finalmente los manejadores (managers) componen la funcionalidad exportada de uno o más drivers, los que finalmente interaccionan con el hardware a partir de las necesidades que las tareas deban ir cumpliendo. Tareas y su programación. Cada tarea mantiene una propia cola de eventos. Sin embargo, cada tarea puede poseer una entrada o salida física (probablemente, más tareas serán basadas sobre una interfase física). En la fase de inicialización del programa, cada tarea registra una tarea de eventos en la programación del sistema. Si la tarea 1 desea hablar con la tarea 2, postea un evento en la cola de eventos de la tarea 2, usando una funcionalidad del Programador del Sistema (System Scheduler), para luego la tarea 2 capture ese evento al preguntar al Programador del Sistema si tiene algún evento para él. Este concepto queda reflejado en el siguiente diagrama. 9

10 figura Programador del Sistema. Para un correcto funcionamiento de esta estructura de software, es necesario que un timer maneje la periodicidad con que una tarea registra eventos. La forma en que se implementa es a través de una tarea timer. Esta posee tres colas : la primera para interactuar con las demás tareas recibe el envío de otras tareas-, la otra conocida como Cola Delta, en la cual se ordenan los distintos eventos dependiendo del tiempo de expiración y que finalmente son enviados a la cola de Eventos Expirados, para su posterior ejecución. Es importante mencionar ahora que el código del programa consta de un ciclo infinito (loop), en el cual todas las tareas son llamadas secuencialmente. Un modelo de esto sería lo siguiente: void main() { initall(); while(1) { TASK1(); TASK2(); TASKn(); 10

11 2.2.3 SOS 4. SOS es un sistema operativo desarrollado en la Universidad de California, específicamente en el NESL (Networked & Embedded Systems Laboratory). SOS es un sistema operativo para redes de sensores que procura remediar algunos de las limitaciones propias de la naturaleza estática de muchos de los sistemas precursores a éste (por ejemplo TinyOS). SOS implementa un sistema de mensajería que permite múltiples hebras entre la base del sistema operativo y las aplicaciones, las cuales pasan a ser módulos que pueden ser cargadas o descargadas en tiempo de ejecución sin interrumpir la base del sistema operativo. El principal objetivo de SOS es la reconfigurabilidad. Ésta se define como la habilidad para modificar el software de nodos individuales de una red de sensores, una vez que estos han sido desplegados físicamente e inicializado su funcionamiento. En el caso de encontrar un problema, en caso de no contar con esta solución, habría sido necesario recolectar todos los nodos para poder modificar su software. La capacidad de dinámicamente agregar o remover módulos, permite la construcción de software mucho más tolerante a fallas. Esto presenta dos grandes ventajas: uno es el hecho de poder realizar updates fácilmente, y el otro es la capacidad de anular el funcionamiento de algún módulo defectuoso, de algún nodo que pertenece a la red. Arquitectura del sistema. Además de las técnicas tradicionales usadas en el diseño de sistemas embebidos, las características del kernel de SOS son: Módulos cargados dinámicamente. Programación flexible de prioridades. Simple subsistema de memoria dinámica. Las capas de abstracción de hardware y drivers son las mismas que las descritas en la sección para el sistema PalOS. A continuación se muestra un esquema de la arquitectura de SOS. 4 Información obtenida desde 11

12 figura Capas funcionales de SOS. Para mayor información acerca de las características y funcionamiento de SOS remétase a leer el paper A dinamic Operating System for Sensor Nodes [3] 12

13 2.3 Comparaciones entre estos Sistemas. A continuación mostramos cuadros comparativos entre los distintos sistemas operativos presentados. En este primer cuadro se comparan en función de ciertos parámetros, el diseño y funcionalidad de los distintos sistemas operativos. SOS TinyOS PalOS Versión estable y Madurez del Código Base Version inicial aprontándose la versión 2.0 Versión estable. Plataformas actualmente soportadas AVR and ARM AVR,MSP430 AVR,ARM. Sensores Soportados MTS310 (sensor board), xbow Crossbow series Los disponibles en los módulos MK-II. 5 Aplicaciones Soportadas En desarrollo Establecidas Establecidas Documentaci ón Tutorial Básico Multiple, repositorio. Básica. Lenguaje de Programación C nesc C Para tareas implementa FIFO 7, interrupciones controladas por eventos. Controlada por eventos. Scheduling 6 Colas de Prioridad Localización en Memoria Dinámica Estática Estática Comunidad de Desarrollador es Reciente Muchos Muchos Tabla 1: Comparaciones entre los sistemas. 5 Plataforma de red de sensores inalámbricos desarrollado en la Universidad de California. 6 Programador o administrador de las tareas del sistema operativo. 7 Modelo que se define en las colas como primero en entrar es el primero en salir. 13

14 A continuación un cuadro que resume las principales variables a considerarse para la toma de una decisión. TinyOS PalOS SOS Lenguaje Flexibilid ad y Dinamism o. Madurez Plataform as Soporte Programado en nesc, lenguaje especialmente diseñador para el funcionamiento de las redes de sensores inalámbricas Si bien no incorpora ni comunicación entre tareas, ni manejo dinámico de componentes en el sistema nativo, existen aplicaciones que permiten su incorporación, sin disminuir el desempeño. Versiones estables y en constante desarrollo Escrito en ansi C Permite comunicación entre procesos. A través de las colas de eventos Versión estable la define el Loop Principal descrito en la sección de PalOS. Escrito en ansi C Permite manejo dinámico de memoria y modificaciones al vuelo Aún se encuentra en proceso de estandarización. AVR, MSP430 y Microchip AVR y ARM AVR y ARM Mucha Documentación y grupos de apoyo. Tutoriales Tutorial Básico Tabla 2. Principales variables a considerarse. 14

15 3 Conclusiones. Dada las características de las redes de sensores inalámbricas, se hace crítico el uso de tecnología estable y con perspectivas a futuro. Si bien los tres sistemas estudiados satisfacen las restricciones expuestas en la sección 2.1, la existencia de una base sólida sobre la cual comenzar a desarrollar las aplicaciones, contando con la información necesaria, es esencial y crítica. SOS presenta una propuesta innovadora, que integra dentro de su sistema, ciertas carencia que sistemas estándares (TinyOS) presentan, tales como la capacidad de insertar y remover módulos de software (para actualizaciones por ejemplo), como el hecho de implementar usos de memoria dinámica. Estas características pueden ser implementadas en sistemas como TinyOS, pero demandan un mayor esfuerzo y un alto nivel de complejidad (máquinas virtuales). Lamentablemente, inherente a su génesis, su desarrollo se encuentra pasos atrás en lo que a estabilidad y robustez de sistema se refiere. PalOS resulta ser una propuesta más débil, su desarrollo y estudio por parte de grupos de usuario es bastante pobre principalmente debido a la simplicidad de su sistema. A criterio, PalOS resulta ser una solución a considerar para sistemas que implementan aplicaciones simples. Hoy en día TinyOS se define como el estándar para las redes de sensores inalámbricas, debido principalmente a su extenso uso por parte de desarrolladores de aplicaciones para este tipo de sistemas. La gran cantidad de grupos de trabajo, el soporte existente en documentación, las plataformas soportadas (gran disponibilidad de librerías que sólo deben ser cargadas en el momento de desarrollar una aplicación), las múltiples aplicaciones desarrolladas, su madurez y finalmente el amplio uso (que verifica su funcionalidad) hace de TinyOS la alternativa más segura y conveniente en la hora de tomar una decisión. En lo que a nuestro proyecto se refiere (redes de sensores inalámbricos aplicados a la agricultura), las características y ventajas de TinyOS son de gran importancia, y es por eso que se trabajará con éste. Sin embargo, dada las características de SOS, estaremos revisando constantemente el desarrollo y los avances que éste pueda presentar, de forma de estar al tanto y poder ir así analizando las innovaciones que éste genere. 15

16 4 Referencias. [1] System Architecture Directions for Networked Sensors Jason Hill, Rober t Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister Depar tment of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA [2] Motivations Behind SOS Roy Shea, Simon Han, Ram Rengaswamy February 20, 2004 [3] A Dynamic Operating System for Sensor Nodes Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler and Mani Srivastava University of California, Los Angeles 16

17 Estudio y Análisis de las Características de TinyOS. 17

18 Índice 1 Introducción Desarrollo Conociendo a TinyOS Qué es TinyOS? Qué es necesario para su funcionamiento? Cómo comenzar Introducción a TinyOS NesC TinyOS Tipos de Componentes Ejemplo de una componente Implementación de una componente Ejemplo de una aplicación completa Modelo de Comunicación Componentes contenidas en TinyOS Conclusiones Referencias Anexos AM Communication Paradigm Active Messages Overview Tiny Active Messages Implementation

19 5 Introducción En el presente documento se presentarán las características del sistema operativo TinyOS, desarrollado en la Universidad de Berkeley como sistema base para la construcción de aplicaciones en sistemas embebidos, específicamente redes de sensores inalámbricas (RSI). El objetivo y alcance de este documento es discutir características que TinyOS posee, abarcando tópicos que van desde responder preguntas tales como qué es? o qué se necesita para su funcionamiento?, para pasar luego a ver la filosofía de su implementación y funcionamiento, su lenguaje de programación, el estudio de los modelos de ejecución y de componentes, hasta presentar a modo de resumen una lista de las componentes existentes y que pueden utilizarse para una implementación. Durante este trabajo se mencionará bastante el término componente. La metodología de diseño en programación para el trabajo sobre este tipo de sistemas, es conocida como programación orientada a componentes, y se encuentra referido a la forma en que se conciben las aplicaciones, las cuales se diseñan de forma modular, definiendo entradas y salidas a ésta. Además siguiendo la idea de separar para lograr un mejor entendimiento y facilidad en el diseño, es que se definen dos tipos de componentes: los módulos, y de configuración. En la medida en que se avance en la lectura de este documento, se irá asimilando mejor esta idea. 19

20 6 Desarrollo. 6.1 Conociendo a TinyOS Qué es TinyOS? TinyOS en un sistema operativo para trabajar con redes de sensores, desarrollado en la Universidad de Berkeley. TinyOS puede ser visto como un conjunto de programas avanzados, el cual cuenta con un amplio uso por parte de comunidades de desarrollo, dada sus características de ser un proyecto de código abierto (Open Source 8 ). Este conjunto de programas contiene numerosos algoritmos, que nos permitirán desde generar enrutamientos, como también aplicaciones preconstruidas para sensores. Además soporta diferentes plataformas de nodos de sensores 9, arquitecturas bases para el desarrollo de aplicaciones. Como veremos más adelante, el lenguaje en el que se encuentra programado TinyOS es un meta-lenguaje que deriva de C, cuyo nombre es NesC. Además existen variadas herramientas que ayudan el estudio y desarrollo de aplicaciones para las redes de sensores, que van desde aplicaciones para la obtención y manejo de datos, hasta sistemas completos de simulación. Sin duda esta respuesta puede ampliarse bastante, y es objetivo de este documento presentar todas las características que TinyOS posee, y por ende lo definen Qué es necesario para su funcionamiento? Aunque puede trabajar en otras plataformas, las plataformas apoyadas son Linux (RedHat 9), Windows 2000, y Windows XP. Es importante mencionar que el proyecto se inicio sobre BSD (Unix), por lo cual para el funcionamiento en Windows se hace necesario la instalación de Cygwin, un simulador de plataformas unix, siendo necesario tener básicos conocimientos acerca de este entorno. Además muchas de las herramientas disponibles se encuentran desarrolladas para plataformas JAVA, por tanto también es necesaria su instalación. La instalación de éstas en sistema Windows se realiza de forma transparente, puesto que existe un paquete ejecutable, el cual además realiza toda la configuración del sistema. La programación de dispositivos se puede realizar a través de distintos puertos, dependiendo del módulo con el que se cuente. Estos pueden ser serial, paralelo o ethernet. Es entonces necesario contar con al menos uno de estos puertos en el PC Cómo comenzar. Tal como se mencionaba, TinyOS es un proyecto de la Universidad de Berkeley, es por esto que el foco principal de información se encuentra en la página del proyecto presente en el servidor de ésta. A continuación se mencionan algunos links importantes. Dirección x/doc/tutorial/index.html Contenido Página Principal del Proyecto. Sección donde se pueden bajar las ultimas versiones del sistema operativo Página con el soporte para TinyOS Tutorial on-line En la Universidad de California, Berkeley el desarrollo de los nodos de sensores se ha basado en los Motes, más información en 20

21 6.2 Introducción a TinyOS. Control de Versiones (CVS) de TinyOS, en el se pueden encontrar tanto aplicaciones que se encuentran en desarrollo para implementarse con TinyOS, como el desarrollo del código fuente de éste. Tabla Principales links. El diseño de TinyOS está basado en responder a las características y necesidades de las redes de sensores, tales como reducido tamaño de memoria, bajo consumo de energía, operaciones de concurrencia intensiva, diversidad en diseños y usos, y finalmente operaciones robustas para facilitar el desarrollo confiable de aplicaciones. Además se encuentra optimizado en términos de uso de memoria y eficiencia de energía. El diseño del Kernel de TinyOS está basado en una estructura de dos niveles de planificación. Eventos: Pensados para realizar un proceso pequeño (por ejemplo cuando el contador del timer se interrumpe, o atender las interrupciones de un conversor análogo-digital). Además pueden interrumpir las tareas que se están ejecutando. Tareas: Las tareas son pensadas para hacer una cantidad mayor de procesamiento y no son críticas en tiempo (por ejemplo calcular el promedio en un arreglo). Las tareas se ejecutan en su totalidad, pero la solicitud de iniciar una tarea, y el término de ella son funciones separadas. Esta característica es propia de la programación orientada a componentes, la cual se presentará en detalle en la sección siguiente. Con este diseño permitimos que los eventos (que son rápidamente ejecutables), puedan ser realizados inmediatamente, pudiendo interrumpir a las tareas (que tienen mayor complejidad en comparación a los eventos). El enfoque basado en eventos es la solución ideal para alcanzar un alto rendimiento en aplicaciones de concurrencia intensiva. Adicionalmente, este enfoque usa las capacidades de la CPU de manera eficiente y de esta forma gasta el mínimo de energía. Ahora bien, tal como se mencionaba en la sección 2.1.1, TinyOS se encuentra programado en NesC, un lenguaje diseñado para reflejar las ideas propias del enfoque de componentes, incorporando además un modelo de programación que soporta concurrencia, manejo de comunicaciones y fácil interacción con el medio (manejo de hardware). TinyOS y NesC se encuentran profundamente relacionados, es por eso que a continuación presentaremos un pequeño resumen con algunas de las características de este lenguaje. 21

22 6.3 NesC. NesC es un meta-lenguaje de programación basado en C, orientado a sistemas embebidos que incorporan el manejo de red. Además soporta un modelo de programación que integra el manejo de comunicaciones, las concurrencias que provocan las tareas y eventos y la capacidad de reaccionar frente a sucesos que puedan ocurrir en los ambientes donde se desempeña (por ejemplo, sensar). También realiza optimizaciones en la compilación del programa, detectando posibles carreras de datos que pueden ocurrir producto de modificaciones concurrentes a un mismo estado, dentro del proceso de ejecución de la aplicación. Además simplifica el desarrollo de aplicaciones, reduce el tamaño del código, y elimina muchas fuentes potenciales de errores. Básicamente NesC ofrece: Separación entre la construcción y la composición. Hay dos tipos de componentes en NesC: módulos y configuraciones. Los módulos proveen el código de la aplicación, implementando una o más interfaces. Estas interfaces son los únicos puntos de acceso a la componente. Las configuraciones son usadas para unir las componentes entre sí, conectando las interfaces que algunas componentes proveen con las interfaces que otras usan. Interfaces bidireccionales: tal como ya se explicaba anteriormente las interfaces son los accesos a las componentes, conteniendo comandos y eventos, los cuales son los que implementan las funciones. El proveedor de una interfaz implementa los comandos, mientras que el que las utiliza implementa eventos. Unión estática de componentes, vía sus interfaces. Esto aumenta la eficiencia en tiempos de ejecución, incrementa la robustez del diseño, y permite un mejor análisis del programa. NESC presenta herramientas que optimizan la generación de códigos. Un ejemplo de esto es el detector de carreras de datos, en tiempo de compilación. Finalmente y a modo de resumen, mencionamos los principales aspectos que el modelo de programación NesC ofrece y que deben ser entendidos para el entendimiento del diseño con TinyOS: 1. Tal como se mencionó el modelo de NesC está formado por interfaces y componentes. 2. Una interfaz puede ser usada o puede ser provista, las componentes son módulos o configuraciones. 3. Una aplicación se verá representada como un conjunto de componentes, agrupados y relacionados entre sí, tal como se observa en la figura

23 Figura Aplicación. 4. Las interfaces se utilizan para operaciones que describen la interacción bidireccional; el proveedor de la interfaz debe implementar comandos, mientras que el usuario de la interfaz debe implementar eventos. 5. Existen dos tipos de componentes: 5.1. Módulos, que implementan especificaciones de una componente Configuraciones, que se encargarán de unir (wire) diferentes componentes en función de sus interfaces, ya sean comandos o eventos. En la figura se muestra un diagrama de bloques en el que se describe el proceso de compilación para una aplicación TinyOS. Mayor información acerca de NesC, remítase al Manual de Referencia del Lenguaje [1]. Ahora bien, comprendido estos conceptos, es posible dar el paso siguiente hacia el entendimiento del diseño en TinyOS. Figura Compilación de una aplicación TinyOS. 23

24 6.4 TinyOS. TinyOS posee un modelo de programación característico de los sistemas embebidos: el modelo de componentes. Tal como se ha mencionado TinyOS esta escrito en NesC, lenguaje que surge para facilitar el desarrollo de este tipo de aplicaciones. A continuación se presentan las ideas de este modelo. Arquitectura basada en componentes: TinyOS se encuentra construido sobre un conjunto de componentes de sistema, las cuales proveen la base para la creación de aplicaciones. En la figura se muestra el modelo de una componente. Conectar estas componentes, usando un conjunto de especificaciones detalladas, es lo que finalmente definirá una aplicación. Este modelo es esencial en sistemas embebidos para incrementar la confiabilidad, sin sacrificar desempeño. Concurrencia en tareas y en eventos: Las dos fuentes de concurrencia en TinyOS son las tareas y los eventos. Las componentes entregan tareas al planificador, siendo el retorno de éste de forma inmediata, aplazando el cómputo hasta que el planificador ejecute la tarea. Las componentes pueden realizar tareas siempre y cuando los requerimientos de tiempo no sean críticos. Para asegurar que el tiempo de espera no sea muy largo, es que se recomienda programar tareas cortas, y en caso de necesitar procesamientos mayores, se recomienda dividirlo en múltiples tareas. Las tareas se ejecutan en su totalidad, y no tiene prioridad sobre otras tareas o eventos. Así tambien los eventos hasta completarse, pero estos sí pueden interrumpir otros eventos o tareas, con el objetivo de cumplir de la mejor forma los requerimientos de tiempo real. Todas las operaciones de larga duración deben ser divididas en dos estados: la solicitud de la operación y la ejecución de ésta. Específicamente si un comando solicita la ejecución de una operación, éste debiese retornar inmediatamente mientras que la ejecución queda en mano del planificador, el cual deberá señalizar a través de un evento, el éxito de la operación. Una ventaja secundaria de elegir este modelo de programación, es que propaga las abstracciones del hardware en el software. Tal como el hardware responde a cambios de estado en sus pines de entrada/salida, nuestras componentes responden a eventos y a los comandos en sus interfaces. Ahora se tiene claro que las aplicaciones TinyOS son construidas por componentes. Una componente provee y usa interfaces. Estas interfaces son el único punto de acceso a la componente. Además una componente estará compuesta de un espacio de memoria y un conjunto de tareas. A continuación se detallan los cuatro elementos que conforman una componente: 2 Manejador de comandos. 3 Manejador de eventos 4 Un frame 10 de tamaño fijo y estáticamente asignado, en el cual se representa el estado interno de la componente. 5 Un bloque con tareas simples. En la figura se muestra el modelo gráfico de una componente, en la cual se observan los elementos mencionados anteriormente. 10 En este caso nos referimos a un bloque que proporciona el contexto en cual se ejecuta el programa y se almacenaran las variables. 24

25 Figura : Modelo de componentes de TinyOS y su interacción. Los comandos son peticiones hechas a componentes de capas inferiores. Estos generalmente son solicitados para ejecutar alguna operación. Existen dos posibles casos de uso de los comandos. El primero es para operaciones bifase, donde los comandos retornan inmediatamente, no generando bloqueos por la espera de la ejecución, es decir, una vez que realizan la petición, el planificador será el encargado de ejecutar lo solicitado, generando un evento que indique el fin de la operación. El otro es el caso de realizar una operación no bifase, donde ésta se realizará completamente, y por tanto no habrá evento retornado. Los manejadores de eventos son invocados por eventos de componentes de capas inferiores, o por interrupciones cuando se está directamente conectado al hardware. Similar a los comandos, el frame será modificado y las tareas agregadas. Los eventos son capaces de interrumpir tareas, no así viceversa. Las tareas se ejecutan hasta terminar y pueden ser sólo interrumpidas por eventos (podríamos decir que eventos tienen mayor prioridad). Las tareas son entregadas a un planificador (task scheduler) que en este caso está implementado con método FIFO. Debido a esta implementación, las tareas se ejecutan secuencialmente y no deben ser excesivamente largas. Alternativamente al planificador de tareas FIFO, puede ser reemplazado por planificadores basados en prioridades (priority-based) ó por planificadores basados en plazos (deadline-based), los cuales pueden ser implementados sobre TinyOS Tipos de Componentes. En general las componentes se clasifican en una de estas categorías: Abstracciones de Hardware: Mapean el hardware físico en el modelo de componentes de TinyOS. Por ejemplo, en el módulo que se observa en la figura , la componente de radio RFM, es representativa de esta clase, ya que exporta comandos para manipular los pines de entrada-salida conectados al RFM y entrega eventos, informando a otras componentes acerca del bit de transmisión o recepción. Su frame contiene información acerca del estado actual de la componente (si se encuentra transmitiendo o recibiendo, la tasa de transferencia de bits, etc). El RFM detecta las interrupciones del hardware que se transforman en el bit de evento de RX o en el bit TX, dependiendo del modo de operación. 25

26 Hardware Sintético: Los componentes de hardware sintéticos simulan el comportamiento del hardware avanzado. Un buen ejemplo de tal componente es el Radio Byte (véase el figura ). Intercambia datos de entrada o salida del módulo RFM y señaliza cuando un byte ha sido completado. Las tareas internas realizan la codificación y decodificación de los datos. Conceptualmente, esta componente es una máquina de estado que podría ser directamente modelada en el hardware. Desde el punto de vista de los niveles superiores, esta componente provee una interfaz, funcionalmente muy similar a la componente de abstracción de hardware UART 11 : proporcionan los mismos comandos y señalan los mismos eventos, se ocupan de datos del mismo tamaño, e internamente realizan tareas similares (buscando un bit o un símbolo de inicio, realizando una codificación simple, etc.). Componente de alto nivel: Realizan el control, enrutamientos y toda la transferencia de datos. Un representante de esta clase es el módulo de mensajes ( messaging module ), presentado en la figura Éste realiza la función de llenar el buffer de los paquetes antes de la transmisión y envía mensajes recibidos a su lugar apropiado. Además, las componentes que realizan cálculos sobre los datos o su agregación, entran en esta categoría. Figura : Grafo de componentes para un sistema MultiHop. Otra de las características de TinyOS es que el modelo de componentes permite la fácil migración a otro hardware, dada la abstracción de hardware que se logra con el modelo de manejo de eventos. Además, la migración es particularmente importante en las redes de sensores, ya que constantemente aparecen nuevas tecnologías, donde de seguro los diseñadores de sistemas querrán explorar el compromiso entre la integración a nivel físico, los requerimientos de energía, y el costo del sistema, requerimientos claves para la optimización Ejemplo de una componente. Una componente típica que incluye un frame, eventos, comandos y tareas es mostrada en la figura Universal Asynchronous Receiver-Transmitter 26

27 Gráficamente, la componente se presenta como un conjunto de tareas, un bloque de estado (frame del componente), un conjunto de comandos (triángulos al revés), un conjunto de manejadores (triángulos), flechas para abajo para los comandos que utiliza, y flechas para arriba (prepicadas) para los comandos que señala. En la figura se muestra el código de esta componente. Como se puede observar el módulo principal se divide en dos partes: una que contiene las interfaces provistas y la otra que contiene las que utiliza. Es deber del programador hacer coincidir los formatos de eventos y comandos entre las distintas interfaces. De todas formas errores son verificados en tiempo de compilación. Figura : Representación gráfica de la componente Active Messages (AM). 27

28 Figura Archivo que describe la componente Implementación de una componente. En TinyOS las componentes se unen en tiempo de compilación, considerando las especificaciones dadas en las componentes de configuración, es decir, se unen respetando las relaciones declaradas por las interfaces. Para facilitar la composición, cada interfaz está descrita en el inicio de cada archivo de componentes. Éste entrega una lista de los comandos que acepta y los eventos que manipula, como también el conjunto de eventos que señaliza y los comandos que usa. Podemos visualizar el modelo como una caja negra, donde solo se ven entradas y salidas. La completa descripción de estas interfaces superiores e inferiores, son usadas en el tiempo de compilación para generar automáticamente archivos de cabecera. Todo esto es manejado por el compilador de lenguaje NesC. Un claro ejemplo en que el compilador debe verificar múltiples uniones, es que si un evento simple debe ser manejado por varias componentes, en tiempo de compilación el código será automáticamente generado para enviar el evento a tantos lugares como sea necesario Ejemplo de una aplicación completa. En la siguiente figura se muestra una vista simplificada de una aplicación implementada con TinyOS. Cada nodo representa una componente, y las flechas representan las uniones de las interfaces. Cada flecha es rotulada con el correspondiente nombre de la interfaz. 28

29 Figura : Aplicación Surge. La aplicación se llama Surge, y tiene como función sensar periódicamente una variable, que en este caso es luminosidad, para luego ser enviada a través de la red inalámbrica. El objetivo de esta aplicación es entregar el valor medido a la base. Para eso cada nodo es capaz de identificar a un nodo padre, el cual le permitirá llegar a la estación base. La aplicación solo debe incorporar las partes que necesita de TinyOS, como son el código de inicio de sistema (MAIN), el temer (Timer), un sensor (Photo), acceso a los leds (Leds), y enrutamiento de mensajes Multihop (Multihop). Además explícitamente se especifican las dependencias de ambiente en función de las interfaces. La aplicación requiere un timer (interfaz Timer), un sensor (interfaz ADC), leds (interfaz Leds) y finalmente comunicación (interfaz Send) Modelo de Comunicación. Una pregunta a resolver es cómo se manejarán los mensajes en la red? Sin duda implementar socket en protocolo TCP/IP no es una buena idea, dado que se necesitaría excesiva memoria para almacenar los paquetes que van llegando además de los bloqueos que se generan mientras no se lea el mensaje. También es necesario evitar el excesivo tráfico sobre la red, por lo cual mensajes de recibo, secuencias de retransmisión, etc. son inaceptables. La solución propuesta es trabajar con la metodología de Active Messages. Para su funcionamiento cada mensaje debe contener el nombre de un manejador de eventos. Para esto el que envía debe declarar un buffer en el frame, para así colocar el nombre del manejador, luego solicitar el envío y esperar que llegue la respuesta de realizado. El receptor entonces se encarga de invocar el correspondiente manejador de eventos. De esta forma no se generan bloqueos o esperas en el receptor, el comportamiento es similar a que ocurriese un evento, y el almacenamiento es simple. Para más detalles se adjunta en el anexo el material disponible. 29

30 6.5 Componentes contenidas en TinyOS. Muchos son los componentes a nivel de sistema que se incluyen en TinyOS. Además existe una colección de ejemplos de aplicaciones que demuestran los usos del sistema TinyOS. En la siguiente figura se muestran los componentes contenidos en la versión 1.0 de TinyOS. Figura Lista de componentes contenidos en TinyOS

31 7 Conclusiones. TinyOS es un sistema operativo de código abierto, diseñado para las redes de sensores inalámbricas. Ofrece una arquitectura basada en componentes, que permite la innovación y rápida puesta en práctica de aplicaciones para este tipo de sistemas, mientras se reduce al mínimo el tamaño del código, según los requisitos inherentes en redes de sensores (memoria y energía, por ejemplo). NesC y TinyOS se encuentran profundamente relacionados, cualquier avance o desarrollo de uno se verá reflejado en el otro. Es por esto que se hace necesario en su totalidad el buen manejo de este lenguaje. Aunque hay algunas tareas que son críticas en tiempo, como son el manejo de la comunicación por radiofrecuencia o el obtener datos de algún sensor, TinyOS no se focaliza en dar garantías estrictas de Tiempo Real. Esto se refleja en que si frente a la llegada de algún evento, puede ocurrir que no sea posible la atención, éste y su información será perdido. Ahora bien, estas falencias son muy bien compensadas con el modelo de manejo de eventos. TinyOS esta programado sobre un lenguaje estático, por lo cual no existen asignaciones de memoria de manera dinámica y los gráficos de llamados quedan totalmente definidos en el tiempo de compilación. Esto facilita enormemente el análisis de programas, y por ende la detección de errores. La biblioteca de componentes de TinyOS incluye protocolos de red, servicios distribuidos, manejadores de sensores, y herramientas de adquisición de datos, que pueden ser ocupadas directamente, o manipuladas para responder a necesidades más específicas. El modelo de manejo de eventos en la ejecución de TinyOS permite una administración al detalle de la energía, aún permitiendo mantener toda la flexibilidad que los sistemas de comunicación e interfaces físicas imponen. Se debe tener cuidado con que se produzcan carreras de datos, esto debido a modificaciones concurrentes a un estado compartido. El compilador NesC es capaz de detectar posibles problemas de este tipo, mas es el usuario el que reparará el error. TinyOS ha migrado a varias plataformas, corroborando de esta forma su estabilidad y su verificación de funcionamiento. Además se han desarrollado aplicaciones capaces de realizar simulaciones, herramienta que una amplia comunidad utiliza para desarrollar y probar varios algoritmos y protocolos. Continuamente grupos numerosos de desarrolladores están contribuyendo código al sitio del sourceforge, y están trabajando activamente. 31

32 8 Referencias. [1] nesc 1.1 Language Reference Manual David Gay, Philip Levis, David Culler, Eric Brewer May [2] The nesc Language : A Holistic Approach to Networked Embedded Systems David Gay Philip Levis Robert von Behren [3] System Architecture for Wireless Sensor Networks Jason Lester Hill B.S. (University of California, Berkeley) 1998 M.S. (University of California, Berkeley) 2000 [4] Introduction to TinyOS. KD Kang. 32

33 Anexos. 8.1 AM Communication Paradigm A key piece of TinyOS is the communication model it supports. Instead of scaling a PC based communication models down, we believe that it is beneficial to tailor the communication system to meet the needs of these devices. To accomplish this, we have used the Active Messages communication model as primary building blocks for networking in TinyOS Active Messages Overview Active Messages (AM) is a simple, extensible paradigm for message-based communication widely used in parallel and distributed computing systems [35]. Each Active Message contains the name of an application-level handler to be invoked on a target node upon arrival and a data payload to pass in as arguments. The handler function serves the dual purpose of extracting the message from the network and either integrating the data into the computation or sending a response message. The network is modeled as a pipeline with minimal buffering for messages. This eliminates many of the buffering difficulties faced by communication schemes that use blocking protocols or special send/receive buffers. To prevent network congestion and ensure adequate performance, message handlers must be able to execute quickly and asynchronously. Although Active Messages has its roots in large parallel processing machines and computing clusters, the same basic concepts can be used to the meet the constraints of networked sensors. Specifically, the lightweight architecture of Active Messages can be leveraged to balance the need for an extensible communication framework while maintaining efficiency and agility. More importantly, the event based handler invocation model allows application developers to avoid busy-waiting for data to arrive and allows the system to overlap communication with other activities such as interacting with sensors or executing other applications. It is this event centric nature of Active Messages which makes it a natural fit for TinyOS Tiny Active Messages Implementation In bringing Active Messages out of the high performance parallel computing world and down into this low power design regime, we have attempted to preserve the basic concepts of integrating communication with computation and matching communication primitives to hardware capabilities. The overlap of computational work with application level communication is essential. Execution contexts and stack space must never be wasted because applications are blocked, waiting for communication. The Active Messages communication model can be viewed as a distributed event model where networked nodes send each other events. While quite basic, we believe that all applications can be built on top of this primitive model. In order to make the Active Messages communication model a reality, certain primitives must be provided by the system. We believe that the three required primitives are: best effort message transmission with acknowledgements, addressing, and dispatch. More demanding applications may need to build more functionality on top of these primitives, but that is left for the applications developer to decide. By creating the minimal kernel of a communication system, all applications will be able to build on top of it. Additionally, it is likely that there will be a large variety of devices with different physical communication capabilities and needs. By building the communication kernel as separate components in the 33

34 TinyOS component model, developers can pick and choose which implementations of the basic components they need. This can take the form of selecting from a collection of delivery components that perform different levels of error correction and detection. However, by providing a consistent interface to communication primitives, application developers can easily transfer their applications to different hardware platforms. Just as there will be various implementations of the core components for the developer to choose from, various other extensions will be available, such as reliable delivery. This is similar to the design of Horus [37], which attempted to have modular PC-based communication protocols where application developers could choose from a variety of building blocks including encryption, flow control, and packet fragmentation. It is extremely advantageous to be able to customize protocols when dealing with network sensors due to their extreme performance constraints and their large diversity of physical hardware. 34

35 Estudio y Análisis de los Requisitos de TinyOS. 35

36 Indice 1 Introducción Desarrollo Requerimientos de software para el servidor de desarrollo de aplicaciones con TinyOS Disponibilidad de librerías de TinyOS, para las distintas plataformas Requerimientos de memoria Conclusiones

37 9 Introducción. El siguiente documento presenta los requerimientos que deben ser considerados para iniciarse en el manejo y uso de software para las redes de sensores inalámbricas, específicamente TinyOS. Primero se comenzará describiendo algunos de los requerimientos en el servidor de desarrollo para aplicaciones de TinyOS, mencionando el proceso de instalación y configuración, y algunas observaciones respecto a la disponibilidad de librerías y componentes. Luego se entregará un resumen con los principales microcontroladores ocupados, los transceiver y las principales librerías existentes para el desarrollo de aplicaciones. Finalmente se discutirá la restricción de memoria que nos impone TinyOS, para la elección de un microcontrolador. 37

38 10 Desarrollo Requerimientos de software para el servidor de desarrollo de aplicaciones con TinyOS. Aunque puede trabajar en otras plataformas, las plataformas compatibles son Linux (RedHat 9), Windows 2000, y Windows XP. Para el funcionamiento en Windows se hace necesario la instalación de Cygwin 12, un simulador de plataformas unix, siendo necesario tener básicos conocimientos acerca de este entorno. Además muchas de las herramientas disponibles se encuentran desarrolladas para plataformas Java, por tanto también es necesaria su instalación (http://java.sun.com). La instalación en sistema Windows se realiza de forma transparente, puesto que existe un paquete ejecutable, el cual además realiza toda la configuración del sistema. En el caso de trabajar sobre linux, se hace necesario tener un mayor conocimiento, dado que es necesario instalar los paquetes (rpms) de forma manual. De la misma forma, si se quieren ocupar las herramientas existentes en Java, será necesario instalar el compilador y el entorno de ejecución (máquina virtual) de éste. Toda la información se puede encontrar en El lenguaje en el cual se deben programar las aplicaciones de TinyOS es NesC, un meta-lenguaje derivado de C, el cual implementa las abstracciones propias del diseño orientado a componentes. El manual de referencia para el aprendizaje de este lenguaje se encuentra disponible en la siguiente dirección: Además existen herramientas tanto para la generación de documentación de los programas (revisar ), como documentación para utilizar el compilador de NesC y su front-end 13 (http://www.tinyos.net/tinyos- 1.x/doc/nesc/ncc.html). A continuación detallo cierta información relevante par a la instalación del entorno de desarrollo en Linux. Existen problemas en la instalación de ciertas herramientas (aplicaciones java que necesiten interactuar con algún puerto de entrada/salida, ya sea serial o paralelo), ya que no existe la API Java Comunication, y es necesario obtener de la página de RXTX 14 el archivo rxtx disponible en Una vez solucionado esto, se pudo realizar una correcta instalación. Los paquetes ocupados fueron: avarice cvs-1.i386.rpm avr-binutils i386.rpm avr-gcc-3.3tinyos-1.i386.rpm avr-insight-pre6.0cvs.tinyos-1.3.i386.rpm Entorno gráfico de trabajo

39 avr-libc cvs-1.i386.rpm graphviz i386.rpm nesc i386.rpm tinyos-tools i386.rpm Los detalles de los pasos a seguir se encuentran en la siguiente página: Sobre el soporte disponible para distintas plataformas de nodos. Al revisar el directorio en el cual se instala TinyOS, específicamente el directorio /tinyos-1.x/tos/platform se pueden encontrar las plataformas soportadas. La siguiente lista muestra el resultado obtenido: tinyos-1.x/tos/platform/avrmote tinyos-1.x/tos/platform/mica tinyos-1.x/tos/platform/mica128 tinyos-1.x/tos/platform/mica2 tinyos-1.x/tos/platform/mica2dot tinyos-1.x/tos/platform/pc Este resultado se obtiene de la instalación de la versión estable de TinyOS Para obtener un completo soporte de las nuevas plataformas existentes será necesario actualizar nuestro software a la última versión existente. A continuación se detallan algunas observaciones sobre los cambios en las versiones de TinyOS. Al revisar los cambios significativos entre una versión y otra, detallados en la página Feb2005cvs/doc/changes-minor-releases.html, se puede encontrar que en la distribución de TinyOS se inicia el soporte para la plataforma Telos, y su microcontrolador MSP430. Además es importante destacar que desde la versión se incluye un nuevo sistema de reprogramación a través de la red para los nodos. La aplicación se llama Deluge y tal como se mencionaba permite programar una nueva imagen del programa a ejecturarse en el nodo de forma inalámbrica. Más información se encuentra disponible en Desde la versión de TinyOS se hace necesario instalar una nueva versión del compilador de NesC, una versión que sea superior a la El no realizar esto impide la actualización. Es importante mencionar que en esta versión del compilador se realizaron cambios que impiden poder trabajar con el mismo código escrito para aplicaciones creadas sobre versiones inferiores de TinyOS. Se puede bajar desde donde se debe 39

40 seleccionar el tipo de plataforma (linux o windows) para luego poder bajarlo. También se destaca que desde la versión 1.1.7, gran parte del desarrollo se ha basado en implementar y mejorar librerías para la plataforma Telos, lo que incluye mejoras con el uc MSP430. Observaciones sobre el hardware necesario para la programación. En lo que a hardware se refiere para la programación de los dispositivos, ya sean plataformas existentes (motes) o plataformas creadas, será necesario tener disponible al menos uno de los siguientes puertos del computador donde se trabaje: serial, paralelo, ethernet o usb. El puerto dependerá de la interfaz de comunicación que el módulo posea. Sólo de esta forma será posible la programación y emulación de aplicaciones. 40

41 10.2 Disponibilidad de librerías de TinyOS, para las distintas plataformas. Muchas de las librerías disponibles en la distribución de TinyOS, pertenecen a la configuración e implementación de aplicaciones sobre plataformas desarrolladas ya sean por Universidades o por empresas. A continuación se muestran las plataformas disponibles con su respectivo microcontrolador y transceiver y librerías. Platafor ma Microcontrol ador Fabricante microcontrola dor Transceiv er Fabrica nte Trancei ver Librerías wec AT90S2313 AVR TR1000 RFM No se incluyen en distribución de TinyOS Rene AT90S2313 AVR TR1000 RFM No se incluyen en distribución de TinyOS Atmega8 Atmega8 AVR TR1000 RFM Clock, I 2 C, ADC, EEPROM, UART, avrmote Atmega8 AVR TR1000 RFM I 2 C, ADC, LRFM, UART, Watchdog, Internal Flash, avr_eeprom, mica Atmega103 AVR TR1000 RFM ByteEeprom, eeprom, ChannelMon, MicaHighSpeedRa dio, RadioTiming, Range, SlavePin,SPI, Watchdog. mica128 Atmega128 AVR CC1000 Chipcon Clock, I 2 C, UART (extiende a mica) mica2 Atmega128 AVR CC1000 Chipcon ADC, CC1000, UART, MacBAckoff, SPI, Power Management, MacControl, SysTime, Voltage, Flash. Mica2dot Atmega128 AVR CC1000 Chipcon Flash, UART, C I 2, Leds, Voltage, micaz Atmega128 AVR CC2420 Chipcon ADC, CC2420, Power Management, SPI, Timers, PhotoTemp, Voltage, AM. Rene2 Atmega163 AVR TR1000 RFM RF, Clock. telos MSP430F149 HCS08 MSP430 Texas Instrumentos HCS08 CC2420 Chipcon ADC, C I 2, SPI,UART, Power Management, Internal Flash, 41

42 Motorola telosb MSP430F1611 Texas Instruments. Internal Voltage, Internal Temp, Internal Clock, CC2420 CC2420 Chipcon DS2411, LSTM25P (Serial ID), I 2 C (incorpora cosas de telos) TCM120 PIC18F452 Microchip TCM120 EnOcean ADC, AM, Clock, PowerManagemen t, UART, OceanRadioContro l Tabla Plataformas con su respectivo Microcontrolador, transceiver y librerías. TinyOS se encarga de proveer componentes que permiten que estos microcontroladores se relacionen con sensores, transceivers y otros dispositivos de entrada salida; además permitan mapear las funcionalidades del microcontrolador al software, logrando una abstracción de la programación en sus niveles mas altos, lo cual facilita la exportabilidad del código a otras plataformas, en caso de ser necesario. Con todo esto las tareas para lo cual la aplicación ha sido desarrollada podrán ser realizadas. Entre las principales componentes encontramos: conversores análogo-digital (ADC), comunicación I 2 C, comunicación serial (Standard e inalámbrica), timers, asignación de memorias. Toda la información de los módulos y librerías desarrolladas para las distintas plataformas de nodos y sensores, se encuentra reunida en las distribuciones del sistema TinyOS, como también en la página del servidor CVS del proyecto. Para la obtención del listado completo, recomendamos dirigirse a específicamente en el directorio tos, donde se podrán ver todos los códigos necesarios para el trabajo. 42

43 10.3 Requerimientos de memoria. Para tomar una decisión acerca del microcontrolador a ocupar, es necesario tener claro los requerimientos de memoria tanto de programa como de datos. En la tabla se muestran los requerimientos de tres aplicaciones Surge, Maté, TiniDB. Tabla Aplicaciones y tamaño del código. En la tabla se muestra en detalle el tamaño de código ocupado por la aplicación Surge, presente en la distribución de tinyos. Como se puede observar el tamaño de código de programa es de aproximadamente 17K, mientras que la memoria de datos es de 1K app. 43

44 Tabla Componentes, tamaño de código y datos en memoria. Es importante mencionar que solo las componentes TinyOS, C runtime y RealMain son requeridas para toda aplicación, mientras que las otras componentes, sólo son incluidas cuando son necesarias. En caso de optimizar el código (inlined) se puede ahorrar aproximadamente 2K de memoria de programa, lo cual ademas trae ahorro de procesamiento en CPU, aproximadamente un 15%, tal como se mostraba en la figura

45 11 Conclusiones Gran parte del desarrollo de aplicaciones en TinyOS, ha sido hecho para plataformas desarrolladas por empresas o universidades (motes), por lo cual muchas de las librerías disponibles se encuentran atadas a las componentes de hardware que estos sistemas poseen. Esta atadura no es estricta, ya que dado el modelo de componentes, y las abstracciones de hardware que se implementan, la migración a otros sistemas se puede realizar con un mínimo de esfuerzo. A modo de resumen, podemos mencionar que en lo que a procesadores se refiere, la familia AVR de la empresa Atmel, es sin duda la más soportada, producto de años de trabajo sobre este tipo de arquitectura. Aparece luego la familia MSP430 de la empresa Texas Instruments, la cual presenta un procesador con increíble capacidad para el manejo de energía, restricción fundamental en este tipo de sistema. También podemos mencionar los avances realizados en la familia PIC18F y en el microcontrolador motorota HCS08, la cual también ha sido soportada. En lo que a requerimientos para la ejecución de TinyOS sobre alguna arquitectura, resulta importante destacar la memoria por parte de la aplicación base, siendo aproximadamente del orden de 4Kb, magnitud bajísima si consideramos que hoy en día la mayoría de los procesadores fácilmente pueden traer 60 Kb de memoria para programa (Caso de MSP430, por ejemplo). 45

46 Referencias. [1] System Architecture Directions for Networked Sensors Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA [2] MPR/ MIB User s Manual Crossbow. Rev. A, August 2004 [3 MTS/MDA Sensor Board User s Manual Wireless Sensor Networks Crossbow. [4] CVS Sourceforge. 46

47 Informes Segunda Etapa. 47

48 Indice 1 Lenguaje NesC Introducción Desarrollo El ambiente de programación Archivos en NesC Conociendo el lenguaje a partir de aplicaciones simples Optimización Conclusiones Abstracción de Hardware Introducción Desarrollo Arquitectura Aplicaciones para un módulo de Hardware específico Conclusiones Descripción del Entorno de Desarrollo Introducción Desarrollo Instalación de TinyOS y el sistema de desarrollo Compilando aplicaciones TinyOS Descripción de las herramientas disponibles Descripción de pasos a seguir para la configuración y uso de los Motes CrossBow y el Gateway MIB600 en las herramientas MoteView 1.0, Serial Forwarder y Surge View Conclusiones Referencias

49 12 Lenguaje NesC 12.1 Introducción. En el siguiente trabajo se profundizaran los conocimientos adquiridos en el lenguaje de programación NesC. El análisis se iniciará presentando primero el ambiente de trabajo, para luego ya entrar de lleno en las características del lenguaje, comenzando por discutir los tipos de archivos y las convenciones de nombres que existen para poder realizar desarrollos que sean compatibles en esquema con los oficiales. Luego se explicarán los conceptos básicos de la programación en nesc, apoyándose principalmente en dos aplicaciones ejemplos: Blink y Surge. Finalmente se analizarán algunos los problemas de carreras de datos y se profundizará en la optimización que nesc puede lograr en la compilación. 49

50 12.2 Desarrollo El ambiente de programación Lo primero es bajar desde los archivos de instalación y seguir las instrucciones que se siguen en 1.x/doc/install.html. TinyOS dispone de una IDE, la cual se puede obtener desde Ésta IDE se encuentra escrita en Java, por lo que se hace necesario contar con este entorno para su posterior ejecución. La herramienta, pese a su sencillez, facilita el desarrollo ya que destaca sintaxis reconocidas como instrucciones, tiene comunicación directa con el bash de cygwin lo que facilita la compilación, tiene un wizard para la creación de proyectos, entre otras características Archivos en NesC Los archivos de NesC se clasifican en tres tipos: Interfaces, módulos, configuraciones. En la siguiente tabla se muestra un ejemplo para cada uno de estos archivos, y una breve descripción de su función. Tipo Descripción Ejemplo Interfaz Modulo Configurac ión Declara los servicios que se proveen y los servicios que se usarán. Se encuentran en el directorio /tos/interface. Provee el código de la aplicación, implementando una o más interfaces. Acá se declara como se unirán las distintas componentes, realiza control de flujo. StdControl. nc BlinkM.nc Blink.nc Tabla Tipos de Archivos, descripción y un ejemplo. También es importante mencionar que existe una convención de nombres para los archivos a ser creados. En la tabla se muestran el procedimiento a seguir. Identificador Reglas para el nombramiento Ejemplo Interfaces Verbos o Sustantivos Casos mezclados: VerboSustantivo ADC SendMsg Componentes Sustantivos, que terminan con C : Cuando son componentes que proveen interfaces TimerC TimerM M: Módulos, implementan el código de la aplicación Archivos Todos los archivos llevan el sufijo.nc TimerC.nc TimerM.nc Comandos, eventos y Tareas Verbos, caso de ser mezclas se debe VerboSustantivo Par Comando/Evento se debe agregar el sufijo Done o Complete sendmsg putdone 50

51 Variables Constantes Sustantivos, en caso de ser mezcla debe ser verbosustantivo Todo con mayúscula, y con underscore para las separaciones entre palabras bool state TOS_BCAST_AD DR Tabla Convenciones de nombres 51

52 12.2.3Conociendo el lenguaje a partir de aplicaciones simples Generalidades del lenguaje: Blink. Blink es un programa muy simple, cuya única función es hacer parpadear un led, el cual se encuentra disponible en las plataformas de desarrollo (mica, micaz, etc). Pese a su simplicidad, abarca muchos de los principales tópicos a entender en la programación con NesC. Archivos necesarios: BlinkM.nc: Define el módulo blink e implementa las interfaces. Blink.nc: Define la componente, es el archivo de configuración top-level.se encargará de unir el módulo BlinkM a otras componentes que la aplicación blink necesite. SingleTimer.nc: Es una componente que se extiende de TimerC, y que será usada por blink. A continuación se muestra Blink.nc configuration Blink { implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC; Código : Blink.nc Se puede observar que las componentes en uso son: Main, BlinkM, SingleTimer, LedsC. NesC usa flechas para definir las relaciones entre las interfaces. Para entender esto, se debe pensar que la flecha -> significa ligado a (traducción de bind to ). Así por ejemplo tenemos que la interfaz ubicada a la izquierda queda ligada a una implementación especificada a la derecha. En otras palabras, la componente que usa una interfaz está a la izquierda, y la componente que provee una interfaz está a la derecha. Main indica cual será la componente que se ejecutará primero en cualquier aplicación de TinyOS. En este caso corresponde a StdControl, la cual es una componente que inicializa y ejecuta la aplicación de TinyOS. Cada componente debe proporcionar ésta interfaz. Dentro del directorio de trabajo se encuentra definida en tos/interfaces/stdcontrol.nc. A continuación se muestra esta interfaz: 52

53 interface StdControl { command result_t init(); command result_t start(); command result_t stop(); Código : StdControl.nc Resulta importante aclarar la función que realizan los comandos init, start y stop. init() : ésta puede ser llamadas múltiples veces, pero nuca será llamada después de un start() o un stop(). Es importante mencionar que si se llama a uno de estos comandos en una componente, se debe también hacer el llamado en las subcomponentes. Continuando con el análisis del programa: Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; Estas dos líneas unen la interfaz StdControl a las interfaces StdControl de BlinkM y SingleTimer. De ésta forma se cumple por ejemplo que SingleTimer.StdControl.init() y BlinkM.StdControl.init() sean llamadas por Main.StdControl.init(). De la misma forma se aplica esta regla para los comandos start() y stop(). Para continuar este análisis se hace necesario el estudio del módulo BlinkM. A continuación se muestra de forma resumida el código de éste. module BlinkM { provides { interface StdControl; uses { interface Timer; interface Leds; // Continued below... Código : BlinkM.nc Se puede notar que este módulo provee la interfaz StdControl y usa las interfaces Timer y Leds. El archivo Timer es el siguiente: interface Timer { command result_t start(char type, uint32_t interval); command result_t stop(); event result_t fired(); Código : Timer.nc En este caso start() especifica el tipo de timer y el intervalo en el cual el timer expira. Es importante mencionar que la unidad del intervalo es en milisegundos, mientras que tipos válidos serían TIMER_REPEAT y TIMER_ONE_SHOT. 53

54 El evento fired() es señalizado cuando el intervalo especificado ha finalizado. Acá queda de manifiesto la características bi-direccional de las interfaces, ya que como se observa tenemos comandos y eventos dentro de esta interfaz. Interfaz proveedor debe implementar comandos. Comandos son llamados por el usuario. La interfaz usada debe implementar eventos. Los eventos son llamados por el proveedor pero manejados por el que las usa. Ahora que se tienen definidas las interfaces como las relaciones que existen entre ellas, se hace necesario escribir la implementación. implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000) ; command result_t StdControl.stop() { return call Timer.stop(); event result_t Timer.fired() { call Leds.redToggle(); return SUCCESS; Código : Implementación de Blink. La especificación de componentes es implementada con un esquema similar a la programación de códigos C. Es en este código donde queda definido el funcionamiento de nuestra aplicación. Como se puede observar cuando el evento Timer.fired() es capturado, el Leds.redToggle() hace parpadear el led rojo que se encuentra en la plataforma con la cual se trabaja. 54

55 Interfaces Parametrizadas. Observemos el siguiente código de programa: configuration SingleTimer { provides interface Timer; provides interface StdControl; implementation { components TimerC; Timer = TimerC.Timer[unique("Timer")]; StdControl = TimerC; Qué significa la línea?: SenseM.Timer -> TimerC.Timer[unique("Timer")]; Una interfaz parametrizada permite a una componente proveer múltiples instancias de esta interfaz la cual se encuentra caracterizada por un valor asignado ya sea en tiempo de ejecución o en tiempo de compilación. Es necesario primero comentar que una componente es capaz de proveer múltiples instancias de una interfaz y asignarles diferentes nombres, por ejemplo: provides { interface StdControl as foocontrol; interface StdControl as barcontrol; Es así como las interfaces parametrizadas son exactamente una generalización de esta misma idea. Podemos además observar que la componente TimerC declara: provides interface Timer[uint8_t id]; En otras palabras, prove 256 diferentes instancias de la interfaz Timer. Es este caso, se quiere que TinyOS pueda manejar múltiples timers de forma independiente y personalizadamente. Cuando se dice TimerC.Timer[algunval], se está especificando que BlinkM.Timer debería ser unido a una instancia de la interfaz Timer especificada por el valor (algunval) encerrado entre paréntesis cuadrado. Este puede ser cualquier número positivo de 8 bits. Para evitar conflictos de uso de valores es que existe la posibilidad de usar la función contante unique(), la cual genera en tiempo de compilación un identificador único, en este caso se ocupa así: unique("timer") Éste generará un identificado único asociado a Timer, de manera tal de que cada vez que se coloque la misma sentencia, se creará otro identificador que garantiza no tener conflictos. 55

56 Carreras de datos y Concurrencia en NesC: SurgeM Las carreras de datos ocurren debido a modificaciones que se realizan de manera concurrente a estados compartidos dentro de la ejecución del programa. NesC es capaz de detectar este tipo de problemas. Ocurre que en TinyOS el código se ejecuta de dos formas: Asincrónicamente (en respuesta a interrupciones) Sincrónicamente (para la ejecución de tareas). Las carreras de datos se presentarán principalmente en estas dos situaciones: Cualquier modificación a un estado compartido desde un código asincrónico es una condición potencial de carrera de datos. Cualquier modificación de un estado compartido desde un código sincrónico, que es también modificado desde un código asincrónico es una condición potencial de carrera de datos. La solución para no tener nunca este problema es que cualquier modificación a un estado compartido solo es con un código sincrónico o con una sección atómica. Una sección atómica puede entenderse como la desactivación de las interrupciones durante unos pocos ciclos de ejecución. Es necesario recordar que esto considera la ejecución bi-fase, ya que el hecho de definir una tarea como atómica tiene relación a que cuando entra a contexto de ejecución esta se considera como un entero. En el caso de que se conozca que no hay problema de carreras de datos, pero el compilador si encuentra alguno, se puede definir como norace. La concurrencia en NesC está profundamente relacionada con los códigos asincrónicos, ya que son las interrupciones las que generan múltiples solicitudes de ser atendidas. Para manejarla, NesC provee dos herramientas: secciones atómicas y tareas. En el código mostrado a continuación Timer.fired y ADC.dataReady son códigos asincrónicos. El evento Timer.fired es señalizado periódicamente, así ADC.getData es llamado para obtener un nuevo dato. Como busy es accedido por un código asincrónico su uso es protegido por una declaración de atómica que realiza un test-and-set de la variable. Una vez que el valor haya sido obtenido, el ADC.dataReady es señalizado. El envío del mensaje no es una operación de tiempo crítico, por lo cual se procede a postear una tarea: senddata. Postear implica que la operación se realizará cuando el procesador este desocupado. Se deben ocupar con sumo cuidado las declaraciones atómicas, ya que al deshabilitar las interrupciones el sistema se vuelve menos seguro y se pueden perder eventos. module SurgeM{... implementation{ bool busy; 56

57 norace uint16_t sensorreading; event result_t Timer.fired(){ bool localbusy; atomic { localbusy = busy; busy = true; if(!localbusy) call ADC.getData(); return SUCCESS; task void senddata(){ adcpacket.data = sensorreading; call Send.send(&adcPacket, sizeof adcpacket.data); return SUCCESS; event result_t ADC.dataReady(uint16_t data){ sensorreading = data; post senddata(); return SUCCESS;... //implementation 57

58 12.2.4Optimización. Como con la detección de carreras de datos, nesc explota las restricciones del modelo de componentes para realizar un análisis estático y optimización. El compilador permite optimizaciones extensas entre componentes relacionadas, lo que incluye mejorar la propagación de constantes, y la eliminación de subexpresiones comunes. Las optimizaciones reducen eficientemente el uso de la memoria de programa, como también la sobrecarga en la ejecución de las aplicaciones. Las dos principales fuentes de reducción de códigos son: Eliminación de códigos muertos, es decir recortar todas las definiciones redundantes, o códigos que no realizen ninguna función, lo que generalmente reduce cerca de un 9% del total. In-lining también reduce el código cerca de un 16%. In-lining sólo crea un 1% de mejora en la utilización de la CPU. Códigos intensivos en CPU no estan dominados por llamados de funciones. Inlining corresponde a una optimización que realiza el compilador, reemplazando todo aquel código que se especifico como inlining en el lugar donde se realiza el llamado. En la siguiente figura podemos observar el efecto de inlining sobre la memoria ocupado por el programa y su desempeño. Figura Comparación de aplicaciones con optimización y sin optimización 58

59 12.3 Conclusiones. NesC es un lenguaje de programación que presenta grandes ventajas para el desarrollo de aplicaciones en sistemas embebidos, específicamente en las redes de sensores inalámbricas. Éste presenta valiosas herramientas para una correcta programación de aplicaciones, primero abstrayendo las características de modularidad que presentan las redes de sensores, facilitando el entendimiento y la implementación de programas para estos sistemas. Además nos entrega herramientas que facilitan el desarrollo, como es el uso de interfaces parametrizadas, como también la verificación y detección de posibles problemas en tiempo de ejecución como son las carreras de datos. NesC es un lenguaje que está en constante desarrollo y cuyo principal objetivo es facilitar la implementación de aplicaciones para sistemas de redes de sensores, lo cual nos garantiza un constante crecimiento en robustez y adaptabilidad a las nuevas necesidades. 59

60 13 Abstracción de Hardware Introducción En el siguiente trabajo se presentaran las principales características del modelo de abstracción de hardware que se ha implementado en el sistema operativo TinyOS. El objetivo principal es poder entender como TinyOS se logra relacionar con los distintos módulos de hardware, ya sean entradas/salidas, buses de datos y mecanismos disponibles para la administración de energía. Este informe se basa principalmente en estudios realizados con las plataformas de redes de sensores inalámbricas Telos, la cual incorpora un microcontrolador MSP430. También se irá haciendo mención a algunas de las características de las plataformas anteriores, basadas principalmente en microcontroladores Atmel. 60

61 13.2 Desarrollo Una de las principales metas en la programación de sistemas operativos es lograr portabilidad a distintas plataformas. Para poder lograr esto se hace necesario tener un esquema que sea capaz de abstraerse del hardware, misión para nada fácil. Específicamente las redes de sensores imponen una gran eficiencia en el uso de recursos (ahorro de energía es esencial), por lo que la modularidad que se quiere alcanzar a través de este módelo no debe comprometer estas variables. A continuación se presenta el modelo propuesto para el desarrollo de aplicaciones a partir de la versión de tinyos (específicamente para plataformas con MSP430), y que será base para la versión 2.0 de este sistema operativo Arquitectura. El presente estudio se basa en la siguiente estructura de organización. Figura Arquitectura de la Abstracción de Hardware La arquitectura presenta tres distintas capas de componentes. Cada capa posee responsabilidades y depende de las interfaces que proveen las capas inferiores. El objetivo principal de la inserción de estas capas, es permitir que el programador de aplicaciones logre una mayor independencia del hardware, teniendo en conocimiento las definiciones de las capas inferiores. A continuación se procede a explicar cada una de las capas: Hardware Presentation Layer (HPL) Esta capa se ubica exactamente por sobre el hardware. Su principal tarea es presentar las capacidades del hardware usando los conceptos nativos del sistema operativo. Ellos acceden al hardware de manera usual, ya sea a través de 61

62 solicitudes de memoria o interactuando con los puertos de entrada/salida, mientras que inversamente el hardware solicita los servicios a través de la señalización de interrupciones. Es por medio de este canal, que el HPL esconde las dificultades y diferencias de hardware, exportándolas a una interfaz más fácil de usar (específicamente a través de llamado de funciones) para el resto del sistema. Está claro que las interfaces quedan completamente definidas por las capacidades del módulo de hardware, pero dado que es necesario lograr un esquema común, y una óptima integración con el resto de la arquitectura es que cada componente HPL debe tener: Inicialización, partida y detención (Initialization, starting y stopping) Comandos get y set para los registros controlan las operaciones de hardware. Habilitar/deshabilitar las interrupciones. Rutinas de Servicios de Interrupciones Es importante mencionar que las rutinas de servicios de interrupciones son sólo las operaciones más críticas en tiempo, y se delega el resto del proceso a componentes de niveles superiores que poseen un conocimiento más extenso acerca del estado del sistema. La estructura de HPL facilita la manipulación del hardware. En lugar de usar macros y nombres de registros cuyas definiciones se encuentran definidas en los archivos de cabeceras (*.h) de las librerías del compilador, el programador puede ahora acceder al hardware a través de una interfaz mucho mas amistosa. Un ejemplo podría ser lo que ocurre en muchas de las plataformas existentes con el módulo USART, ya que generalmente los microcontroladores poseen dos. Ellas son funcionalmente idénticas, pero son accedidas a través de registros diferentes y genera diferentes vectores de interrupciones. Acá entonces es cuando el HPL actúa, escondiendo estas diferencias bajo una interfaz consistente, haciendo la programación mucho más abstracta. Al programador solo le bastaría un nuevo recableado (rewiring) sin necesidad de modificar el código de la implementación Hardware Adaptation Layer (HAL) Se puede decir que esta capa representa la parte esencial de este tipo de arquitectura. Ella usa las interfaces provistas por las componentes de la HPL para construir las abstracciones que serán utilizadas por el programador, y que esconden la complejidad natural asociado con el uso de recursos de hardware. Es importante mencionar que debido a los requerimientos de las redes de sensores, es que en esta capa las abstracciones deben ser adaptadas a un dispositivo en concreto. Esta capa presenta un compromiso entre proveer de la mejor forma las abstracciones, sin comprometer eficiencia por conveniencia. Exporta modelos específicos por campos, en lugar de abstracciones sobrecargadas y limitadas. Es decir, por ejemplo en vez de trabajar con una interfaz timer, crear una interfaz alarma, en la cual se dejan atrás ciertas restricciones impuestas por hardware y se construyen aplicaciones con una base en común. En la sección 2.2 se explica mejor este caso Hardware Interface Layer (HIL) 62

63 Esta última capa se encarga de convertir las abstracciones HAL de un hardware específico, en interfaces independientes del hardware. Estas interfaces proveen abstracciones independientes de la plataforma, lo que simplifica el desarrollo de aplicaciones ya que se esconden las diferencias de hardware. Esta capa no existía dentro del contexto de desarrollo de aplicaciones en las versiones inferiores a tinyos Esta capa es la que entrega la mayor flexibilidad, al permitir desarrollo de aplicaciones olvidándose del tipo de hardware que se esta ocupando. Existe un número de versión para cada iteración de una interfaz HIL, lo cual permite aún más incrementar los niveles de funcionalidad. Ya para finalizar se hace necesario mencionar que para un desempeño óptimo, la aplicación para una plataforma específica podría evitar las componentes del tipo HIL y directamente acceder a las interfaces HAL, ya que así se provee un acceso completo a los módulos de hardware. La decisión debe tomarse dependiendo del tipo desarrollo y el fin de éste. Cual es la utilidad de ocupar esta capa? 63

64 13.2.2Aplicaciones para un módulo de Hardware específico. Tal como ya se mencionaba en la introducción, este nuevo esquema nace con la implementación de la plataforma con el microcontrolador MSP430 (telos). Para las versiones anteriores el esquema solo constaba de dos niveles, muy similares a las dos capas inferiores de este nuevo modelo, pero usa una filosofía diferente en la separación de funcionalidades para las abstracciones superiores. A continuación mostramos un diagrama funcional del microcontrolador MSP430F149. Clock System 60 KB Flash 2 KB RAM 12-Bit ADC USART0 USART1 RISC CPU 16-Bit 16-Bit 16-Bit Bus Conv 4-Bit 8-Bit MAB MDB TimerA TimerB. I/O port 1/2 Interrupt Capability I/O port 3-6 Figura Diagrama Funcional del MSP430 Acá se observan las componentes del MSP430, que se encontraban incorporadas en la versión de TinyOS Main M HPLInit M BusArbitration BusArbitration C M MSP430InterruptC MSP430Interrupt M MSP430Clock M HPLSpi M HPLUSART0 M HPLUARTM HPLUARTC HPLUSART1 M Main HPLInitC MSP430ClockC ADCM MSP430ADC12 M TimerC Timer M MSP430TimerC MSP430Timer M RefVolt M HPLADC12 M ADCC MSP430ADC12C RefVoltC Figura Componentes de la abstracción de hardware del MSP430 A continuación se estudiaran y analizaran los principales módulos que componen una típica plataforma de redes de sensores inalámbricas. 64

65 65

66 Proccesing Unit. El microcontrolador es la parte principal de una plataforma de WSNs. Abstraer las diferencias entre los variados MCU 15 es el primer paso hacia un sistema operativo más exportable. Mucho de esto se encuentra incluido en que nesc es un lenguaje de programación con una suite de compilación similar (gcc). Por ejemplo las librerías estándares distribuidas con el compilador crea los códigos necesarios para el funcionamiento del microcontrolador, ya sea definir las variables globales, el puntero del stack y la tabla de vectores de interrupciones. TinyOS se encarga de proveer distintos mecanismos para acceder a las funcionalidades del microcontrolador. Por ejemplo para los pines externos de la MCU, tinyos provee la capacidad de cambiar su dirección y su función (I/O de propósito general o alguna función específica, por ejemplo ADC). Todas las macros se encuentran definidas en los archivos hardware.h de cada plataforma. También TinyOS se encarga de negociar con las distintas formas de acceder a los registros, usando los archivos de cabeceras (.h) disponibles en las librerías standard. Es importante mencionar que no se pretende aplicar el modelo de tres capas a la MCU, ya que las características del compilador más los archivos hardware.h, son suficientemente eficientes Power Management La administración de la energía es sin duda una tarea crítica para garantizar una larga vida de los dispositivos de redes de sensores. Cada microcontrolador tiene un perfil diferente de administración de la energía. Este perfil se compone de los distintos niveles de bajo consumo, como también del tiempo que demora en despertar, es decir, el tiempo que demora en pasar del estado dormido (sleep) a activo. La relevancia de estos estados, es el ahorro de energía producto de los distintos niveles de corriente consumida para cada modo. En el caso de las plataformas basadas en los microcontroladores Atmel, donde el tiempo que demora en despertar es de unos pocos milisegundos, se usa una componente HAL que evalúa cuando el próximo evento del timer ocurrirá, y sólo coloca al microcontrolador en modo sleep si el tiempo es mayor que lo que demoraría en despertar. En cambio el MSP430 demora alrededor de 6 microsegundos, por lo que apenas la MCU no esta procesando, se procede a cambiar a bajo consumo de energía, específicamente al modo sleep. En ambos casos, antes de pasar al modo sleep, una componente HAL verifica si algún módulo de hardware necesita que la MCU este activa. Adicionalmente todos los servicios, incluyendo las componentes HAL y HPL tienen funciones de inicialización, start y stop. Cuando un servicio no esta ocupando algún módulo de hardware, este podría llamar la función stop de las componentes HPL o HAL. Al hacer esto se desactivan los módulos para el ahorro de energía, pero también ser remueven las dependencias sobre los módulos de hardware para entrar al modo sleep. Estas ventajas se logran principalmente gracias al diseño de hardware que poseen los microcontroladores, donde la gran mayoría de los módulos se encuentran 15 Micro Controller Unit 66

67 conectados a la MCU. En la medida que se agreguen más dispositivos externos, se harán necesarios nuevos mecanismos para el manejo de la energía. 67

68 Clocks y Timers. El principal problema que se encuentra acá es que diferentes microcontroladores pueden proveer diferentes números de timers, de registros de comparación y captura, diferentes modos de contar, distintos factores de escalas y diferencias en la resolución. A continuación se muestra lo que ocurre para MSP430 y para Atmel. MSP430 Atmel Atmega Dos timers diferentes de 16-bits. 1 Uno con tres registros de comparación/captura y el otro con ocho. 2 Cada uno puede poseer cuatro factores de escalamiento. 3 Cada registro de comparación permite distintas interrupciones dependiendo del estado final del contador. Dos timers de 8-bit, cada uno con preescalable de 10 bits y un registro comparador. Dos timers de 16-bit cada uno con tres registros de comparación y limitado en preescalar. El módulo ocupado para las aplicaciones de Atmel era TimerM. Este módulo no pudo ser adaptado al microcontrolador MSP430, por lo que se diseñó una nueva interfaz que se llamó Alarm, que accede al tiempo actual y permite setear alarmas en el futuro relativo a tiempo atrás. Cada interfaz debe describir la resolución de la alarma que provee, tal como TMilli, T32khz, TMicro.De esta forma cada plataforma exporta un número de interfaces, que corresponderán al numero máximo de alarmas soportadas por la plataforma. Sin la capa de presentación, la adaptación del hardware estaría atada a muchos recursos y especificaciones de la MCU. Los flags de overflow, el tiempo actual dado por el hardware, y las configuraciones de los registros del sistema son accesibles desde la HPL. El HAL usa estas primitivas para construir las interfaces de Alarm accesibles en el HAL. En la capa HIL se provee la independencia de la plataforma, además resulta importante mencionar que todos los timers, por ende las alarmas, serán de 32 bits. En el caso de que los timers sean menores que 32 bits (definido por el hardware), en la capa HAL se emulan como si fueran de 32. De esta forma la capa HIL expone un reloj nativo de 32 bits para las aplicaciones y servicios de sincronización Conversor Análogo-Digital. Tal como el caso de los timers, el mayor desafío en definir la abstracción de hardware para un conversor análogo/digital es negociar con las capacidades y variabilidad del hardware. Principalmente los módulos ADC pueden diferir en su resolución, el número de canales a ser muestreados y convertidos, y el soporte de modos de conversión especiales. Si se compara el modulo conversor de MSP430 con el de Atmel ATmega, notaríamos grandes diferencias. El módulo ADCM en TinyOS provee comandos para disparar una conversión simple y para iniciar una conversión que se repite constantemente en un canal. El problema es que fue diseñada para el procesador Atmel, el cual no puede modificar el tiempo en que se mantiene la muestra (sample-and-hold) o una referencia de voltaje individual para canales diferentes. También no soporta modos de conversión en secuencia. Para solucionar esto, es que se diseño una nueva abstracción del ADC, en el que se incorpora el diseño de las tres capas que se presentan en este trabajo. 68

69 La clave se encuentra en la capa HAL, la que extiende los conceptos incluidos en el módulo ADCM desarrollado para Atmel, específicamente la capacidad de convertir y configurar todos los canales de conversión disponibles. También para clarificar los cuatro modos de conversión que el MSP430 presenta, se han separado en las interfaces: MSP430ADCSingle y MSP430ADC12Multiple para conversión simple y múltiple respectivamente. Cada una provee dos comandos, los que permiten seleccionar si la conversión será una sola vez o periódicamente. De esta forma se cuenta con interfaces que manejan de mejor manera todas las capacidades disponibles en el nuevo microcontrolador, incluso aumentando el nivel de abstracción de éstas Bus de Datos. Todo microcontrolador se relaciona con dispositivos digitales externos a través de algún bus standard de datos. Entre ellos podemos encontrar SPI/USART, UART, I2C y 1-Wire. Sólo un subconjunto de estos, son provistos por hardware, siendo necesario entonces implementar los otros con rutinas de software que ocupan pines digitales I/O de uso general. La abstracción que se propone, debe ser capas de exportar el manejo del reloj de control incluyendo los modos sincrónicos y asincrónicos, factores que pre-escalan el reloj, generación de baud-rate,etc. Además se debe incorporar la capacidad de manejar el consumo de energía (por ejemplo en el caso de que una UART no esté transmitiendo datos, esta debe ser desactivada). La funcionalidad de la capa HPL presenta dos rutas, una para los datos y otra para el control. Control: Permite configurar la fuente del reloj principal, pre-escalar y seleccionar el baud-rate. Las interrupciones pueden ser habilitadas o deshabilitadas acá. A través de esta interfaz los dispositivos pueden ser apagados para ahorrar energía. Datos: Esta interfaz se encarga del recibimiento y transmisión de bytes a través de los registros de hardware, así como también reportar interrupciones cuando se recibe algún dato. Acá hay un ejemplo para la plataforma MSP430: 69

70 interface HPLUSARTControl { async command void enableuart(); async command void disableuart(); async command void enableuarttx(); async command void disableuarttx(); async command void enableuartrx(); async command void disableuartrx(); async command void enablespi(); async command void disablespi(); async command void setmodespi(); async command void setmodeuart_tx(); async command void setmodeuart_rx(); async command void setmodeuart(); async command void setclocksource( uint8_t source); async command void setclockrate( uint16_t baudrate, uint8_t mctl); async command result_t disablerxintr(); async command result_t disabletxintr(); async command result_t enablerxintr(); async command result_t enabletxintr(); async command result_t istxintrpending(); async command result_t isrxintrpending(); async command result_t istxempty(); async command result_t tx(uint8_t data); async command uint8_t rx(); interface HPLUSARTFeedback { async event result_t txdone(); async event result_t rxdone(uint8_t data); Figura USART para MSP430 También se da soporte a los casos en que más de un protocolo es necesario, dándose soporte a todos estos a través de un simple módulo de hardware. Esto se puede hacer debido a una componente que se encarga de arbitrar el bus. A continuación se muestra esta interfaz: interface BusArbitration { async command result_t getbus(); async command result_t releasebus(); event result_t busfree(); Figura Interfaz que se encarga de controlar el manejo del bus. interface AlarmTMilli { Ejemplo de Relación async entre las command distintas uint32_t Capas. get(); async command bool isset(); Para observar mejor como async es command que se relacionan void cancel(); las distintas capas de la abstracción de hardware, async y command así entender void la set(uint32_t funcionalidad t0, y uint32_t potencialidad dt); de cada una de ellas, se mostrará async un event ejemplo void : fired(); Clock y Timer. Como se explico en la sección se creó una interfaz alarm para poder abstraerse de las características propias de cada hardware (MSP o AVR) configuration AlarmC { provides interface AlarmTMilli as AlarmTimerMilli; provides interface AlarmT32khz as AlarmTimer32khz; provides interface AlarmT32khz as Alarm32khz1; provides interface AlarmT32khz as Alarm32khz2; //... provides interface AlarmTMicro as AlarmMicro1; provides interface AlarmTMicro as AlarmMicro2; provides interface AlarmTMicro as AlarmMicro3; 70 //...

71 interface Timer { command result_t setperiodic(uint32_t dt); command result_t setoneshot(uint32_t dt); command result_t stop(); command bool isset(); command bool isperiodic(); command bool isoneshot(); command uint32_t getperiod(); event result_t fired(); 71

72 13.3 Conclusiones Se han presentado las funcionalidades que tinyos proporciona, desde el punto de vista de un esquema de abstracción de hardware, el cual genera un balance entre los diferentes requerimientos de las aplicaciones de redes de sensores y la creciente necesidad de construir sistemas más portables y fáciles de depurar. El modelo presentado se encarga de ir poco a poco, desde las capas inferiores hacia arriba, logrando una independencia de la arquitectura de hardware, pero al mismo tiempo sin ir perdiendo el uso de las capacidades de éste. Antes de iniciarse en el desarrollo de aplicaciones es crítico lograr el entendimiento de este modelo, pues sólo así se podrá reutilizar códigos existentes, facilitando el desarrollo de aplicaciones específicas orientadas a resolver problemas concretos. Es importante mencionar que dependiendo del hardware a ocupar es que se debe realizar un estudio más acabado de las librerías, ya que son bastante extensas y complejas. Una vez que se hayan definido estos, más el conocimiento adquirido al entender el modelo de capas presentado en este trabajo, el desarrollo de aplicaciones debiera ser un paso no muy complejo. 72

73 14 Descripción del Entorno de Desarrollo Introducción En el siguiente trabajo se presentará una breve descripción del entorno de trabajo que nos ofrece tinyos, y se describirá el procedimiento para poder trabajar con los sensores disponibles en el instituto 3ie. En principio se analizarán las herramientas disponibles, las que podemos clasificar en de modo consola o modo grafico. Luego se describirán los pasos a seguir para trabajar con los dispositivos disponibles y las herramientas propuestas anteriormente. 73

74 14.2 Desarrollo Instalación de TinyOS y el sistema de desarrollo. TinyOS es un sistema operativo que cuenta con muchas herramientas para el desarrollo de aplicaciones específicas, que pueden realizar diferentes funciones, ya sea obtención de datos desde sensores, transmisión de paquetes de información a traves de la red, etc. El foco principal de información se encuentra en la página del proyecto. A continuación se mencionan algunos links importantes. Dirección d.html html 1.x/doc/tutorial/index.html /tinyos/ Contenido Página Principal del Proyecto. Sección donde se pueden bajar las ultimas versiones del sistema operativo Página con el soporte para TinyOS Tutorial on-line. Control de Versiones (CVS) de TinyOS, en el se pueden encontrar tanto aplicaciones que se encuentran en desarrollo para implementarse con TinyOS, como el desarrollo del código fuente de éste. Tabla Principales links. La instalación de TinyOS puede llevarse a cabo tanto para plataformas Linux como para Windows. En este caso, enfocaremos nuestro trabajo a las herramientas disponibles para windows, las cuales son proporcionadas por la empresa Crossbow, las cuales facilitan bastante el trabajo con los Motes pues proporcionan interfaces gráficas, para la mayoría de las labores a realizarse (programación, pruebas de conectividad, obtención de datos, etc) Consideraciones de la distribución de Crossbow. Los siguientes archivos son instalados al ejecutar el binario tinyos is.exe TinyOS TinyOS Tools nesc Cygwin Support Tools 74

75 Java 1.4 JDK & Java COMM 2.0 Graphviz AVR Tools avr-binutils avr-libc avr-gcc avarice avr-insight También se hace necesaria la instalación de un update, en el caso de la distribución de la empresa crossbow es la versión tinyos-1.1.7july2004cvs- 1.cygwin.noarch.rpm Es importante mencionar que en la página de tinyos, específicamente se pueden encontrar las versiones mas actuales de el paquete tinyos, siendo la ultima versión de éste la Una vez realizado esto, tinyos debiese quedar completamente instalado en el sistema. Como bien se sabe, el ambiente de trabajo es en Cygwin, un entorno unix que corre sobre windows, por lo que para proceder a trabajar con las herramientas de tinyos debemos correr esta aplicación. La empresa Crossbow a desarrollado aplicaciones que no se encuentran disponibles en la instalación de tinyos, y que deben ser copiadas directamente por el usuario al directorio de trabajo correspondiente, esto es tinyos-1.x/contrib/xbow Verificación de la instalación. Lo primero sería entrar a Cygwin. Cambiar al directorio opt/tinyos-1.x/tools/scripts/ y ejecutar toscheck. $ cd opt/tinyos-1.x/tools/scripts $./toscheck Si todo está bien instalado debiese la última línea de la salida standard decir lo siguiente: $ toscheck completed without error 75

76 14.2.2Compilando aplicaciones TinyOS Para la compilación de aplicaciones la siguiente sintaxis debe ser ocupada: $ make <plataforma> Donde <plataforma> debe corresponder a una de las soportadas por la versión de tinyos. En el caso de tener instalada la versión básica de la distribución, es decir, tinyos 1.1.0, las plataformas soportadas serán: Mica, mica2, mica2dot y pc. Es necesario por ende instalar el upgrade para poder trabajar con micaz (plataforma de los motes que se poseen). En el caso de instalar versiones superiores, por ejemplo tinyos , las plataformas soportadas además de las mencionadas anteriormente son: Micaz, Telos, snms_schema, Telos_hc08, Telosa, Telosb y Tmote. También es importante mencionar que a la compilación se pueden agregar ciertos extras, destacando entre ellos la posibilidad de generar la documentación de la aplicación. $ nesdoc <Directorio> <aplicación> 76

77 14.2.3Descripción de las herramientas disponibles Para el trabajo con los motes existen variadas herramientas, que van desde aquellas que trabajan en consola, hasta interfaces gráficas. Estas últimas se encuentran disponibles en el directorio /tos/tools/ siendo las más importantes las que se encuentran en en el directorio subdirectorio java SerialForwarder Esta es una aplicación Java la cual sirve para abrir un socket en el servidor que contiene la conexión por algún puerto al gateway de la red de sensores inalámbricos. De esta forma, la información de la red puede ser obtenida desde cualquier pc conectado a internet Surge GUI Es una herramienta entregada por la empresa Crossbow para trabajar con los motes, que puede ser descargada desde la página de la empresa, específicamente desde Surge-view está diseñado para trabajar con los motes, permitiendo obtener datos de los estados de conexión que hay entre los distintos nodos, proporcionando una interfaz gráfica de distribución de los nodos en el espacio. Es importante mecionar que tambien se dispone de una versión libre, la que se puede cargar de la siguiente forma: $java net.tinyos.surge.mainclass <num_nodos> Mote-View Se obtiene de la misma forma que Surge GUI. MOTE-VIEW esta diseñado para ser una interfaz entre el usuario y los nodos de una red inalámbrica de sensores. MOTE-VIEW provee al usuario herramientas que simplifican la distribución fisica de los nodos y el monitoreo de estos. Además facilita el conectarse a base de datos, donde se pueden analizar y graficar las variables obtenidas. Más información se puede encontrar en el manual de usuario, disponible al instalar esta aplicación Descripción de pasos a seguir para la configuración y uso de los Motes CrossBow y el Gateway MIB600 en las herramientas MoteView 1.0, Serial Forwarder y Surge View Configurar MIB600 Conectar MIB600 (Gateway) al transformador de 5 V, teniendo mucho cuidado de que el switch del MIB600 se encuentre en la posición SW1 (5V). Conectar cable de red (ethernet) al MIB600. Correr programa DeviceInstaller y ejecutar Search hasta que encuentre el MIB600 (UDS-10/Cobox 5.x), puede demorar unos segundos, en caso que no tenga IP asignada el MIB600, o que la asignada no sea una IP válida en nuestra LAN, habrá que asignar una IP manualmente que sea acorde a la LAN donde uno se encuentre conectado. 77

78 Configurar Motes (programar). El MIB600 debe estar apagado. Conectar Mote en el Gateway en modo Off y sin pilas. Encender MIB600 y conectar red. Abrir Mote View, entrar en la pestaña Tools y luego en Program Mote. En la ventana que se abre, entrar en la pestaña Settings y luego en Interface Board Settings, una vez adentro elegir MIB600 y colocar la dirección IP asignada al MIB600. Luego en la ventana Mote Config que ya esta abierta, elegir el archivo a cargar en el mote, para este caso el archivo surge_2420_hp. Luego colocar un mote ID y un group ID (en nuestro caso 125)(OJO: al mote que va a quedar en el MIB600 configurarlo con ID 0). Elegir la frecuencia y canales, lo más importante acá es que se elija RadioBand Luego pulsar Program. Repetir el último paso con todos los motes que se desee trabajar, pero asignándole mote ID diferentes. Cada vez que se cambie un mote en el MIB600 desconectar primero la corriente y luego quitar cambiar motes. Además como se desconecta y conecta el MIB600, este se demora un par de minutos en recuperar su IP Ver Datos de la red en Mote View 1.0 Luego una vez configurado todos los motes, ponerle pilas a los motes que no se encuentren en el MIB600, agregarle las placas sensoras, y ponerlos en estado ON. Al mote que se encuentra en el MIB600 también ponerlo en estado ON. Para conectar el mote que trabajara junto al MIB600, acordarse de que tanto este como el mote se encuentren apagados al momento de conectarse, luego conectar a la corriente el MIB600, y conectarlo a la red, para por último colocar en estado ON el mote. Una vez hecho esto comprobar que el MIB600 tenga asignado una IP válida. Luego en el Mote View ingresar a la pestaña Window y luego en Server Configuration, elegir connect, y en Table Name elegir surge_results, por último Aceptar. Luego ir a Log Data, elegir Host y colocar los datos correspondientes, luego en XMesh Application poner Surge y por último Start. A los pocos minutos deberían empezar a verse los datos recogidos desde los sensores. 78

79 Uso de Surge View Iniciar programa Serial Forwarder, en Server Port colocar 9001, en Mote Communications colocar y luego Start Server, si esta todo bien configurado y los motes encendidos debería empezar a incrementarse los paquetes recibidos. Ir mediante mediante una consala cygwin o DOS hasta el directorio Surge View, y ejecutar la aplicación surge con la siguiente línea: surge

80 14.3 Conclusiones Tinyos proporciona un set de herramientas para la creación de aplicaciones, proporcionando además programas para la depuración y prueba de éstas. Según sea la plataforma a ocupar, es que se dispondrán de más o menos herramientas. Es importante mencionar que para plataformas MSP430 existe el uso de JTAG, el cual además de proporcionar la grabación de aplicaciones, también facilita la emulación. 80

81 15 Referencias [1] Mote-View (Manual de Usuario) [2] Getting Started Guide Rev.B, August 2004, Document [3] Información disponible en página [4] Flexible Hardware Abstraction for Wireless Sensor Networks 81

82 Informes Segunda Etapa. 82

83 Índice 1 Tossim Introducción Desarrollo Compilador: Modelo de Ejecución Modelo de la Red Inalámbrica Servicios de Comunicación Emulación de Hardware Ejecución de Tossim y TinyViz Conclusiones Aplicaciones más importantes Introducción Desarrollo Conclusiones Inyectando comandos en la red Introducción Desarrollo Conclusiones Referencias Anexos Anexo A- Data Link Layer: TinyOS Networking (AM and Below)

84 16 Tossim Introducción En el presente trabajo se mostrará la aplicación Tossim y las múltiples herramientas que esta posee, profundizando principalmente en la aplicación Java TinyViz. Básicamente Tossim provee un completo entorno de simulaciones para redes de sensores inalámbricas, abarcando tanto el comportamiento de ésta como red, como también la ejecución de la aplicación en cada nodo, posibilitando de esta forma la depuración de aplicaciones que se estén desarrollando. A continuación se muestran los conceptos básicos que enmarcan el funcionamiento de esta herramienta, para luego presentar su funcionamiento y llegar a la aplicación de ésta en programas reales. 84

85 16.2 Desarrollo Tossim es un completo simulador para las redes de sensores inalámbricas, el cual captura todo el comportamiento e interacción de los motes en una red. Posee muchas características que lo hacen una herramienta útil y casi esencial para el desarrollo y depuración de aplicaciones. A continuación se muestra un esquema que define la arquitectura de tossim, la cual podemos dividir en 5 partes: Soporte para compilar la estructura propia de TinyOS (make pc). Cola de eventos, que simula las interrupciones. Realiza pequeñas modificaciones a las componentes de abstracciones de hardware, de forma de poder interactuar con el entorno de simulación Mecanismos para el trabajo con el conversor ADC y con el transceiver del modelo de comunicación inalámbrica (radio model). Comunicación con otros programas externos que permitirán la interacción con la simulación, de la misma forma como se realizaría con una red inalámbrica real. Figura Arquitectura de Tossim: Frames, eventos, modelos, componentes y servicios Tossim ejecuta el mismo código que el que funcionará en un mote cualquiera, y sólo cambiará algunas componentes de bajo nivel (ADC,Clock,RFM). Las interrupciones de hardware, que ocurren en un mote real, son simuladas a partir simulador de eventos discreto. Podemos imaginar a Tossim como un grafo dirigido (figura 1.2.2), en el cual los vértices (A,B,C,etc) corresponden a los nodos, mientras que las uniones o lazos son los enlaces, los que poseen una probabilidad de error de bit, lo cual permitirá modelar dos de los problemas típicos de este tipo de configuraciones: Terminal oculto, transmisión con condiciones perfectas pero en el que igual hay pérdidas aleatorias. 85

86 En lo que a conexión con aplicaciones externas se refiere, Tossim es capaz de comunicarse a través de un socket TCP/IP, con herramientas que nos permitirán monitorear el estado de la red. Figura Forma de un grafo dirigido Compilador: Al compilar una aplicación TinyOS para un PC, el principal cambio en comparación al archivo generado para un mote es el manejo de variables en la memoria. En la figura siguiente se muestran los dos códigos generados al compilar una aplicación Figura Cuadro comparación de Códigos. La forma en que se genera el ejecutable que funciona con el simulador es escribiendo: $ make pc Recordemos que al agregar ciertos extras, como docs se genera la documentación. Una vez realizado esto, en el directorio build/pc/ se encontrará un fichero ejecutable llamado main.exe. Es éste el que al ejecutarse generará la simulación. Además existen ciertas opciones que se detallan a continuación: 86

87 Usage:./build/pc/main.exe [options] num_nodes [options] are: -h, --help Display this message. -gui pauses simulation waiting for GUI to connect -a=<model> specifies ADC model (generic is default) options: generic random -b=<sec> motes boot over first <sec> seconds (default: 10) -ef=<file> use <file> for eeprom; otherwise anonymous file is used -l=<scale> run sim at <scale> times real time (fp constant) -r=<model> specifies a radio model (simple is default) options: simple static lossy -rf=<file> specifies file input for lossy model (lossy.nss is default) -s=<num> only boot <num> of nodes -t=<sec> run simulation for <sec> virtual seconds num_nodes number of nodes to simulate Figura Opciones para la ejecución de Tossim. 87

88 16.2.2Modelo de Ejecución. La clave para entender como se ejecutan las aplicaciones, es tener presente el simulador de eventos (en reemplazo a las interrupciones por hardware). Este se va a encargar de realizar por software por ejemplo la obtención de un valor en el conversor ADC, señalizando a la componente que corresponde que el evento ha ocurrido. En el modelo de ejecución solo existe una gran diferencia a lo que ocurre en un nodo real, esta se debe a que los eventos son generados por software, lo cual impide que el manejador de interrupciones pueda desplazar la ejecución de tareas. Además es importante mencionar que cada nodo estará funcionando a 4 Mhz, tal como ocurre en los nodos reales. Esto se aplica tanto para las tareas como para los eventos, logrando de esta forma obtener resultados que corresponden de manera fiel a lo que ocurre en la realidad. También ayuda a esto el hecho de que al iniciar una simulación se escoge un tiempo aleatorio para iniciar la ejecución de la aplicación en cada uno de los nodos, modelando de esta forma el comportamiento real que se tiene al iniciar los nodos de una red de sensores Modelo de la Red Inalámbrica. El modelo de la red inalámbrica consiste en un grafo dirigido (figura 1.2.1) el cual asigna una probabilidad de error a cada enlace. Existe una diferencia entre la probabilidad de falla entre los nodos (A,B) al de los nodos (B,A), es decir, son asimétricos. Cada nodo tendrá su propia visión de la red, es decir, escuchará y transmitirá cuando el canal este libre. Es importante mencionar que la simulación no modela las cancelaciones producto de RF. Tossim presenta dos modos de operación en respuesta a los distintos tipos de redes que pueden existir: Static (lossy) : Sirve para probar protocolos en caso de MultiHop, con lo cual tossim permite visualizar los saltos que la información realiza entre un nodo y otro, hasta llegar a la estación base. Simple : Útil para probar protocolos en ausencia de MultiHop, por lo que permite estudiar situaciones de terminales ocultos, en el que un nodo no escucha a los otros nodos, por lo que dependiendo del protocolo intentará transmitir (aumentando el ruido) o no transmitirá nunca Servicios de Comunicación. Tal como se mencionaba al inicio de este trabajo, existen aplicaciones de PC que son capaces de monitorear, manejar y actuar sobre la red de sensores, al comunicarse con Tossim a través de un puerto serial virtual, el cual simulará la conexión de un estación base (gateway) al computador. Específicamente nos referimos a SerialForwarder, la cual al conectarse al nodo cero de la simulación, posibilita la obtención de datos desde la red de sensores. 88

89 16.2.5Emulación de Hardware. Tossim emula el comportamiento del hardware de las capas inferiores, específicamente: ADC Clock EEPROM Componentes de secuencia de boot Componentes de la comunicación inalámbrica (Radio Stack) Un aspecto importante en la emulación del hardware es que se mantiene el comportamiento bi-fase que se propone con la programación en NesC; esto se ve reflejado por ejemplo en el conversor ADC, ya que para proveer el dato existe una función externa que se encargará de esta labor, lo cual luego provocará la señalización dataready() como respuesta al comando getdata(). En el caso del Transceiver, el manejo es de forma especial. Para poder entenderlo es recomendable primero leer el anexo A, donde se explica el funcionamiento de la capa de enlace de datos de forma resumida. Para la Simulación de la red, se modelan tres tasas de muestreo para la transmisión y recepción de paquetes: 40Kbps Transmisión de datos 20 Kbps Recepción del simbolo de inicio. 10 Kbps Para el envío del simbolo de inicio. Esto se logra cambiando los períodos entre los eventos del reloj del Radio. Bajo la simulación se mantiene el concepto del manejador de eventos [2], cuando un mote transmite el bit de sincronización, chequea si algún otro mote que pueda oírlo está en estado de escucha. En el caso de que exista alguno, el nodo encola un evento de transmisión inalámbrica (Radio) para el receptor, representando la ocurrencia de una captura de entrada. Este modelo incorpora los problemas de distancia, es decir la perdida de datos producto de la falta de potencia en el transmisor. El modelado ha sido comparado con pruebas reales (revisar estudio en publicación [4]) bajo ciertas condiciones y configuraciones de la red, verificando que se acomoda muy bien a la realidad. Mostramos en la figura los gráficos obtenidos en esta simulación. 89

90 Figura Resultados de pérdida de datos. 90

91 16.2.6Ejecución de Tossim y TinyViz Como se explico en la sección 1.2.1, al compilar la aplicación con el comando make pc (modo simulación) se crea un archivo ejecutable main.exe. Una de las herramientas muy útiles que nos provee Tossim es la DBG (debug). Para entender mejor su funcionamiento primero se debe aclarar que el lenguaje NesC permite agregar instrucciones, en el código de la aplicación, del tipo dbg (dbg(dbg_<variable reservada>, "<Texto>");) la cual proporciona una especie de printf (escritura por la salida estandar, pantalla) en el momento de ejecución del simulador. Luego así podemos seleccionar que tipo de mensajes dbg queremos observar. Por ejemplo, si lo que interesa es ver sólo los mensajes del tipo AM (active message) bastaría que yo configurara como variable de entorno DGB=am, donde am seria la variable reservada, específicamente escribiría: export DBG=am. Así como existen estas variables reservadas, también se pueden agregar flags proporcionados por el usuario. En este caso se debe agregar en el código de la aplicación lineas del tipo: dbg(dbg_<tipo>, " ); Donde tipo puede ser: usr1, usr2, usr3, temp. En la tabla se muestran las opciones validas para realizar el debug. all: Enable all available messages boot: Simulation boot and StdControl clock: The hardware clock task: Task enqueueing/dequeueing/running sched: The TinyOS scheduler sensor: Sensor readings led: Mote leds crypto: Cryptographic operations (e.g., TinySec) route: Routing systems am: Active messages transmission/reception crc: CRC checks on active messages packet: Packet-level transmission/reception encode: Packet encoding/decoding radio: Low-level radio operations: bits and bytes logger: Non-volatile storage adc: The ADC i2c: The I2C bus uart: The UART (serial port) prog: Network reprogramming sounder: The sounder on the mica sensor board time: Timers sim: TOSSIM internals queue: TOSSIM event queue simradio: TOSSIM radio models hardware: TOSSIM hardware abstractions simmem: TOSSIM memory allocation/deallocation (for finding leaks) usr1: User output mode 1 usr2: User output mode 2 usr3: User output mode 3 temp: For temporary use Tabla : Opciones para debug (DBG). Otro aspecto importante es que dada la compilación cruzada de la aplicación (NesC -> C), es que podemos ocupar la herramienta GNU de depuración para archivos C (tambien llamada dbg). Esta herramienta nos permitiría realizar un debug completo (con breakpoints, etc) sobre la aplicación que se haya creado. El 91

92 único inconveniente es que este debug al realizarse en el código C generado, dificultará la depuración del código escrito como aplicación (en NesC). TinyViz : Aplicación Grafica para Tossim. TinyViz es una herramienta escrita en lenguaje Java, que permite visualizar, controlar, y analizar una simulación de Tossim. Provee un interacción en línea, al ser capaz de modificar parámetros como ADC, Modo de la comunicación inalámbrica, etc., propios tanto de cada nodo como de las redes de sensores. Posee un sistema de Plugins los cuales permiten una mejor simulación al considerar variables físicas en la simulación, además de facilitar el desarrollo de nuevas herramientas. De esta forma el usuario interactúa con la simulación habilitando (cargando ) estos plugins los que van a proveer la funcionalidad deseada. El directorio donde se encuentran es tools/java/net/tinyos/sim/plugins. Podemos clasificar estos plugins de dos tipos, dependiendo de su direccionalidad: Envían mensajes a Tossim Reciben salidas generadas por Tossim. A continuación se muestra una captura de este sistema. Figura TinyViz. Los pluggins disponibles son: Debug messages: Muestra una ventana con todos los mensajes de debug generados por la simulación. Se pueden seleccionar nodos y también aplicar filtros para seleccionar que tipo de mensaje se desea observar. Es importante mencionar que los mensajes mostrados dependen del valor 92

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN UNICIENCIA 24 pp. 83-89 2010 IMPLEMENTACIÓN DE UN SERVIDOR FTP UTILIZANDO EL MODELO CLIENTE/SERVIDOR MEDIANTE EL USO DE SOCKETS EN LENGUAJE C UNIX CON EL FIN DE MEJORAR LOS TIEMPOS DE RESPUESTA EN LA RED

Más detalles

Sistemas Operativos. Tema 1. Arquitectura Básica de los Computadores

Sistemas Operativos. Tema 1. Arquitectura Básica de los Computadores Sistemas Operativos. Tema 1 Arquitectura Básica de los Computadores http://www.ditec.um.es/so Departamento de Ingeniería y Tecnología de Computadores Universidad de Murcia Sistemas Operativos. Tema 1 Arquitectura

Más detalles

Estructura del Sistema Operativo. Módulo 2. Estructuras de Sistemas Operativos

Estructura del Sistema Operativo. Módulo 2. Estructuras de Sistemas Operativos Estructura del Sistema Operativo Módulo 2 Estructuras de Sistemas Operativos Servicios de Sistemas operativos Interfaz de Usuario del Sistema Operativo Llamadas a Sistema Tipos de Llamadas a Sistema Programas

Más detalles

Wireless Sensor Network in a nuclear facility: A technology aplication proposal

Wireless Sensor Network in a nuclear facility: A technology aplication proposal Wireless Sensor Network in a nuclear facility: A technology aplication proposal CNEA,IB (1) U. FASTA (2) Maciel, F. 1 - Fernández, R. O. 1 - Vilugron, R. M. 2 This work presents an overview of a pretended

Más detalles

Spectrum Power TG - Descripción General

Spectrum Power TG - Descripción General El Spectrum Power TG ha sido diseñado teniendo en consideración las necesidades específicas de la industria eléctrica. Este sistema puede operar tanto bajo ambiente Windows y Linux. Arquitectura del Sistema

Más detalles

Telecontrol y Monitoreo de Sistemas Eléctricos a través de una Red de Área Local Inalámbrica

Telecontrol y Monitoreo de Sistemas Eléctricos a través de una Red de Área Local Inalámbrica Telecontrol y Monitoreo de Sistemas Eléctricos a través de una Red de Área Local Inalámbrica Amhed Ashid Ramos Díaz, Angel Benjamín López Martínez Universidad Politécnica de Sinaloa. Niños Héroes #1413,

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

Etapas del desarrollo

Etapas del desarrollo Capítulo 4 Etapas del desarrollo Este capítulo documenta la aplicación del modelo presentado anteriormente, para el caso de la detección y clasificación de eventos sísmicos sobre señales digitales. El

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Objetos Distribuidos - Componentes. Middleware

Objetos Distribuidos - Componentes. Middleware Objetos Distribuidos - Componentes Middleware Middleware Component Oriented Development Arquitecturas 3 Tier Middleware es el software que: conecta y comunica los componentes de una aplicacion distribuida

Más detalles

ADAPTACIÓN DE REAL TIME WORKSHOP AL SISTEMA OPERATIVO LINUX

ADAPTACIÓN DE REAL TIME WORKSHOP AL SISTEMA OPERATIVO LINUX ADAPTACIÓN DE REAL TIME WORKSHOP AL SISTEMA OPERATIVO LINUX Autor: Tomás Murillo, Fernando. Director: Muñoz Frías, José Daniel. Coordinador: Contreras Bárcena, David Entidad Colaboradora: ICAI Universidad

Más detalles

Fundamentos de Sistemas Operativos

Fundamentos de Sistemas Operativos Fundamentos de Sistemas Operativos Sistemas Informáticos Fede Pérez Índice TEMA Fundamentos de Sistemas Operativos 1. - Introducción 2. - El Sistema Operativo como parte de un Sistema de Computación 2.1

Más detalles

APLICACIONES OPEN SOURCE PARA EL MONITOREO DE REDES IP. Ing. Yubaira Boyer Digitel, Caracas E-mail: yubira_boyer@digitel.com.ve

APLICACIONES OPEN SOURCE PARA EL MONITOREO DE REDES IP. Ing. Yubaira Boyer Digitel, Caracas E-mail: yubira_boyer@digitel.com.ve 1 APLICACIONES OPEN SOURCE PARA EL MONITOREO DE REDES IP. Ing. Yubaira Boyer Digitel, Caracas E-mail: yubira_boyer@digitel.com.ve RESUMEN. El Código abierto es el término por el que se conoce al software

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Módulo 2 Comunicación

Módulo 2 Comunicación Sistemas Distribuidos Módulo 2 Comunicación Facultad de Ingeniería Departamento de Informática Universidad Nacional de la Patagonia San Juan Bosco Comunicación en Sistemas Distribuidos Modelos de Comunicaciones

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

A continuación resolveremos parte de estas dudas, las no resueltas las trataremos adelante

A continuación resolveremos parte de estas dudas, las no resueltas las trataremos adelante Modulo 2. Inicio con Java Muchas veces encontramos en nuestro entorno referencias sobre Java, bien sea como lenguaje de programación o como plataforma, pero, que es en realidad Java?, cual es su historia?,

Más detalles

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos.

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos. Contenidos Sistemas operativos Tema 3: Estructura del sistema operativo Componentes típicos del SO Servicios del SO Llamadas al sistema Programas del sistema El núcleo o kernel Modelos de diseño del SO

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co. Universidad Pedagógica y Tecnológica de Colombia. Colombia

Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co. Universidad Pedagógica y Tecnológica de Colombia. Colombia Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co Universidad Pedagógica y Tecnológica de Colombia Colombia Amézquita-Mesa, Diego Germán; Amézquita-Becerra, Germán; Galindo-Parra, Omaira

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Desarrollo de una plataforma de enseñanza de laboratorio para educación a distancia.

Desarrollo de una plataforma de enseñanza de laboratorio para educación a distancia. UNIVERSIDAD NACIONAL EXPERIMENTAL POLITECNICA ANTONIO JOSE DE SUCRE VICERRECTORADO PUERTO ORDAZ DEPARTAMENTO DE INGENIERIA ELECTRONICA TRABAJO DE GRADO Desarrollo de una plataforma de enseñanza de laboratorio

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Tema: Introducción a la Plataforma Arduino

Tema: Introducción a la Plataforma Arduino Facultad: Ingeniería Escuela: Electrónica Asignatura: Interfaces y Periféricos Tema: Introducción a la Plataforma Arduino Objetivos Específicos. Conocer la plataforma de hardware libre Arduino 2. Desarrollar

Más detalles

Integración HMI-PLC. una ventaja competitiva real.

Integración HMI-PLC. una ventaja competitiva real. La manufactura esbelta es una poderosa herramienta probada que aumenta la eficiencia en los procesos de producción. Conceptos y prácticas similares que eliminan "desperdicios" (equipo innecesario y los

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Sistemas con Microcontroladores y Microprocesadores

Sistemas con Microcontroladores y Microprocesadores Sistemas con Microcontroladores y Microprocesadores Objetivos Al terminar el curso, el estudiante estará capacitado para: 1. Entender funcionalmente cómo trabaja un sistema de computadora: Describir los

Más detalles

Redes de comunicación

Redes de comunicación Redes de comunicación Conmutación de circuitos Conmutación de paquetes Dpt. Arquitectura de Computadores 1 Redes conmutadas Conmutación (nodos) de los datos que se reciben de una estación emisora hasta

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

TEMA 1: VISIÓN GENERAL DE LOS SISTEMAS OPERATIVOS

TEMA 1: VISIÓN GENERAL DE LOS SISTEMAS OPERATIVOS TEMA 1: VISIÓN GENERAL DE LOS SISTEMAS OPERATIVOS 1. Concepto de Sistema Operativo. Funciones Un sistema operativo (S.O.) es un programa o conjunto de programas de control que tiene por objeto facilitar

Más detalles

Concepto de Procesamiento Distribuido y Centralizado

Concepto de Procesamiento Distribuido y Centralizado Concepto de Procesamiento Distribuido y Centralizado Procesamiento Centralizado: En la década de los años 50 s las computadoras eran máquinas del tamaño de todo un cuarto con las siguientes características:

Más detalles

(Advanced Communications Function / Virtual Telecomunications Access Method) Función avanzada de comunicaciones/método virtual a telecomunicaciones

(Advanced Communications Function / Virtual Telecomunications Access Method) Función avanzada de comunicaciones/método virtual a telecomunicaciones Las arquitectura de red como la ISO, OSI, IBM SNA, DEC DNA, TCP/IP, estan diseñadas para mostrar la vista lógica de las comunicaciones de red independientes de la implementación física. El modelo OSI describe

Más detalles

DATALOGGER USANDO NIOS II

DATALOGGER USANDO NIOS II DATALOGGER USANDO NIOS II Luis Enrique Campoverde Rugel (1), Washington Adrián Velásquez Vargas (2), Ing. Ronald Ponguillo (3) (1) (2) (3) Facultad de Ingeniería en Electricidad y Computación (1) (2) (3)

Más detalles

Sistema de Control Domótico

Sistema de Control Domótico UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN ELECTRÓNICA Y AUTOMATICA PROYECTO FIN DE CARRERA Sistema de Control Domótico a través del bus USB Directores:

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

AcuServer Servidor de Archivos Remoto de Alto Rendimiento

AcuServer Servidor de Archivos Remoto de Alto Rendimiento AcuServer Servidor de Archivos Remoto de Alto Rendimiento RESUMEN EJECUTIVO AcuServer es una tecnología de servidor de datos remoto que ofrece un seguro e inmediato acceso a datos indexados, relativos

Más detalles

Estructura de buses para control de AGV

Estructura de buses para control de AGV Estructura de buses para control de AGV Con el concepto moderno de sistemas internetworking, se plantea una estructura de control para un vehículo autónomo, considerando al mismo como una celda de proceso

Más detalles

Unicenter Asset Management versión 4.0

Unicenter Asset Management versión 4.0 D A T A S H E E T Unicenter Asset Management versión 4.0 Unicenter Asset Management es una completa solución para gestionar los activos TI de su entorno empresarial de forma activa. Proporciona funciones

Más detalles

Christian Bolívar Moya Calderón

Christian Bolívar Moya Calderón UNIVERSIDAD SAN FRANCISCO DE QUITO Software Orientado a Sistemas de Control HMI/Scada usando Recursos Libres y de Código Abierto, desarrollado sobre Plataforma Linux Christian Bolívar Moya Calderón Tesis

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

Convivencia. Gestión del Sistema de Entrada/Salida

Convivencia. Gestión del Sistema de Entrada/Salida Convivencia Gestión del Sistema de Entrada/Salida Dra. Carolina Carolina Mañoso Mañoso Dpto. Dpto. Imformática Informática y y Automática.UNED Introducción (1/2) El sistema de Entrada/Salida es la parte

Más detalles

Curso de Android con Java

Curso de Android con Java Todos los Derechos Reservados Global Mentoring Experiencia y Conocimiento para tu Vida 1 Este es un tiempo único para el mundo de los celulares, en particular de los Smartphones. Este tipo de dispositivos

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Capítulo 4: Capa Red - I

Capítulo 4: Capa Red - I Capítulo 4: Capa Red - I ELO322: Redes de Computadores Tomás Arredondo Vidal Este material está basado en: material de apoyo al texto Computer Networking: A Top Down Approach Featuring the Internet 3rd

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

SISTEMA UNIFICADO DE CONTROL EN TIEMPO REAL (SUCTR)

SISTEMA UNIFICADO DE CONTROL EN TIEMPO REAL (SUCTR) SISTEMA UNIFICADO DE CONTROL EN TIEMPO REAL (SUCTR) Sistema Unificado de Control en Tiempo Real - SUCTR: El sistema unificado de control en tiempo real, en adelante SUCTR, es un sistema de administración

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Herramienta para la construcción de un cluster y la distribución de carga entre los nodos

Herramienta para la construcción de un cluster y la distribución de carga entre los nodos Herramienta para la construcción de un cluster y la distribución de carga entre los nodos Rubén A. González García 1, Gabriel Gerónimo Castillo 2 1 Universidad Juárez Autónoma de Tabasco, Av. Universidad

Más detalles

Universidad de Guadalajara

Universidad de Guadalajara Universidad de Guadalajara Centro Universitario de Ciencias Económico-Administrativas Maestría en Tecnologías de Información Ante-proyecto de Tésis Selection of a lightweight virtualization framework to

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

General Parallel File System

General Parallel File System General Parallel File System Introducción GPFS fue desarrollado por IBM, es un sistema que permite a los usuarios compartir el acceso a datos que están dispersos en múltiples nodos; permite interacción

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Curso 5007437. Capítulo 4: Arquitectura Orientada a Servicios. Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007

Curso 5007437. Capítulo 4: Arquitectura Orientada a Servicios. Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007 Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007 Capítulo 4: Arquitectura Orientada a Servicios Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es

Más detalles

Sistemas Distribuidos. (Arquitecturas)

Sistemas Distribuidos. (Arquitecturas) (Arquitecturas) Dr. Víctor J. Sosa Sosa vjsosa@cinvestav.mx II-1 Arquitecturas Los SD son los sistemas de software más complejos Nortel Networks crea switches los cuales pueden contener entre 25-30 millones

Más detalles

Diferenciadores entre ediciones de Bases de Datos Oracle Octubre de 2011. Standard Edition One. Express Edition. Standard Edition

Diferenciadores entre ediciones de Bases de Datos Oracle Octubre de 2011. Standard Edition One. Express Edition. Standard Edition Diferenciadores entre ediciones de Bases de Datos Oracle Octubre de 2011 Características Express Standard One Standard Enterprise Procesamiento Máximo 1 CPU 2 Sockets 4 Sockets Sin límite Memoria RAM Máxima

Más detalles

Introducción a LabVIEW FPGA y CompactRIO

Introducción a LabVIEW FPGA y CompactRIO Introducción a LabVIEW FPGA y CompactRIO Familia de Productos Embebidos de LabVIEW Tecnología FPGA Interconexiones Programables Bloques Lógicos Bloques de E/S Importancia de FPGA en Sistemas Alta Confiabilidad

Más detalles

Router, Enrutador o Encaminador

Router, Enrutador o Encaminador Router, Enrutador o Encaminador Un router es un tipo especial de computador. Cuenta con los mismos componentes básicos que un PC estándar de escritorio. Tiene una CPU, memoria, bus de sistema y distintas

Más detalles

Estructura del Sistema Operativo. Módulo 2. Estructuras de Sistemas Operativos

Estructura del Sistema Operativo. Módulo 2. Estructuras de Sistemas Operativos Estructura del Sistema Operativo Módulo 2 Estructuras de Sistemas Operativos Servicios de Sistemas operativos Interfaz de Usuario del Sistema Operativo Llamadas a Sistema Tipos de Llamadas a Sistema Programas

Más detalles

CONTROL NUMÉRICO COMPUTERIZADO BAJO SISTEMA OPERATIVO GNULINEX PARA MÁQUINAS DE CORTE

CONTROL NUMÉRICO COMPUTERIZADO BAJO SISTEMA OPERATIVO GNULINEX PARA MÁQUINAS DE CORTE XIII CONGRESO INTERNACIONAL DE INGENIERÍA DE PROYECTOS Badajoz, 8-10 de julio de 2009 CONTROL NUMÉRICO COMPUTERIZADO BAJO SISTEMA OPERATIVO GNULINEX PARA MÁQUINAS DE CORTE Álvarez F. Marcos A. Martínez

Más detalles

TRANSMISION DE DATOS Intercambio de datos (en forma de ceros y unos) entre dos dispositivos a través de un medio de Tx.

TRANSMISION DE DATOS Intercambio de datos (en forma de ceros y unos) entre dos dispositivos a través de un medio de Tx. ASIGNATURA: REDES DE COMPUTADORE I Lectura 1. TEMAS: REPASO FUNDAMENTOS DE LAS COMUNICACIONES Transmisión de datos Estándares y organizaciones de normalización. FUNDAMENTOS DE LA INTERCONECTIVAD DE REDES.

Más detalles

Tipos de comunicación La comunicación puede ser:

Tipos de comunicación La comunicación puede ser: Unidad 3. Procesos concurrentes 3.3 Semáforos (informática) Un semáforo es una variable especial (o tipo abstracto de datos) que constituye el método clásico para restringir o permitir el acceso a recursos

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Innovación para su Contact Center. Business Rules. Personalice al máximo la experiencia del cliente, aplicando reglas de negocio

Innovación para su Contact Center. Business Rules. Personalice al máximo la experiencia del cliente, aplicando reglas de negocio Innovación para su Contact Center Business Rules Personalice al máximo la experiencia del cliente, aplicando reglas de negocio ÍNDICE DATA SHEET 1. Introducción... 4 2. Características principales... 4

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

INTERFACE DE TRANSFERENCIA DE DATOS A TRAVÉS DEL BUS USB

INTERFACE DE TRANSFERENCIA DE DATOS A TRAVÉS DEL BUS USB INTERFACE DE TRANSFERENCIA DE DATOS A TRAVÉS DEL BUS USB Ing.Pedro Ignacio Martos, pmartos@fi.uba.ar Facultad de Ingeniería, Universidad de Buenos Aires Resumen: En aplicaciones de control que requieren

Más detalles

IVista: es la interfaz con la que el Presentador se comunica con la vista.

IVista: es la interfaz con la que el Presentador se comunica con la vista. Capítulo 3 MODELO DE DISEÑO 3.1 Arquitectura Modelo-Vista-Presentador La arquitectura Modelo-Vista-Presentador (MVP) [11] separa el modelo, la presentación y las acciones basadas en la interacción con

Más detalles

Tema 1 Introducción. Arquitectura básica y Sistemas Operativos. Fundamentos de Informática

Tema 1 Introducción. Arquitectura básica y Sistemas Operativos. Fundamentos de Informática Tema 1 Introducción. Arquitectura básica y Sistemas Operativos Fundamentos de Informática Índice Descripción de un ordenador Concepto básico de Sistema Operativo Codificación de la información 2 1 Descripción

Más detalles

1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.

1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones. Módulo Profesional: Servicios en Red. Código: 0227. Resultados de aprendizaje y criterios de evaluación. 1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.

Más detalles

Análisis de desempeño y modelo de escalabilidad para SGP

Análisis de desempeño y modelo de escalabilidad para SGP Análisis de desempeño y modelo de escalabilidad para SGP Este documento es producto de la experiencia de Analítica en pruebas de stress sobre el software SGP. Estas pruebas se realizaron sobre un proceso

Más detalles

MS_10747 Administering System Center 2012 Configuration Manager

MS_10747 Administering System Center 2012 Configuration Manager Administering System Center 2012 Configuration Manager www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso describe cómo

Más detalles

WAN y Enrutamiento WAN

WAN y Enrutamiento WAN WAN y Enrutamiento WAN El asunto clave que separa a las tecnologías WAN de las LAN es la capacidad de crecimiento, no tanto la distancia entre computadoras Para crecer, la WAN consta de dispositivos electrónicos

Más detalles

ID:1374 INTEGRO. SERVICIOS TELEMÁTICOS EN LA NUBE. Sánchez Rodríguez, Alfredo. Cuba RESUMEN

ID:1374 INTEGRO. SERVICIOS TELEMÁTICOS EN LA NUBE. Sánchez Rodríguez, Alfredo. Cuba RESUMEN ID:1374 INTEGRO. SERVICIOS TELEMÁTICOS EN LA NUBE. Sánchez Rodríguez, Alfredo. Cuba RESUMEN La Plataforma de Servicios Telemáticos desarrollada por SOFTEL bajo la denominación de: proyecto INTEGRO, constituye

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Fundamentos de Redes de Computadoras

Fundamentos de Redes de Computadoras Fundamentos de Redes de Computadoras Modulo III: Fundamentos de Redes de Area Extendida (WAN) Objetivos Redes conmutadas Circuito Paquetes Conmutación por paquetes Datagrama Circuito virtual Frame Relay

Más detalles

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características

Más detalles

Herramientas de soporte para temas de Comunicación de Datos. Guillermo Rigotti. UNICEN Fac. de Ciencias Exactas

Herramientas de soporte para temas de Comunicación de Datos. Guillermo Rigotti. UNICEN Fac. de Ciencias Exactas Herramientas de soporte para temas de Comunicación de Datos Guillermo Rigotti UNICEN Fac. de Ciencias Exactas ISISTAN Grupo de Objetos y Visualización Pje. Arroyo Seco, (7000) Tandil, Bs. As. Argentina

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

Organización del Computador 1. Máquina de von Neumann Jerarquía de Niveles

Organización del Computador 1. Máquina de von Neumann Jerarquía de Niveles Organización del Computador 1 Máquina de von Neumann Jerarquía de Niveles Inicios de la computación Turing y Church sientan las bases teóricas de la computación Máquina de Turing Máquina teórica compuesta

Más detalles

Bach Bachiller de Ingeniería Informática, Universidad Católica San Pablo, Perú, 2013.

Bach Bachiller de Ingeniería Informática, Universidad Católica San Pablo, Perú, 2013. Universidad Católica San Pablo Facultad de Ingeniería y Computación Escuela Profesional de Ciencia de la Computación SILABO CS225T. Sistemas Operativos (Obligatorio) 2015-2 1. DATOS GENERALES 1.1 CARRERA

Más detalles

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx Contenido Middleware: Introducción Definición Genealogía Aplicaciones actuales: Servicios Web Computación

Más detalles

En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de

En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de datos y la tipología de redes que se emplean. Además este

Más detalles

Software Libre / Código Abierto Programa de contenidos

Software Libre / Código Abierto Programa de contenidos Software Libre / Código Abierto Programa de contenidos Resumen Se presenta a continuación la organización de un curso de cincuenta horas cuyo fin es dar a conocer la base ideológica que sostiene a los

Más detalles

RADIODIFUSIÓN Cabeceras de audio y vídeo

RADIODIFUSIÓN Cabeceras de audio y vídeo RADIODIFUSIÓN Cabeceras de audio y vídeo 36 La cabecera de Rohde & Schwarz rompe con tradiciones anticuadas La nueva R&S AVHE100 para DVB de Rohde & Schwarz demuestra que las cabeceras pueden ser ultracompactas,

Más detalles

Capítulo 6: Instrumentación: Diseño del Sistema de H2O

Capítulo 6: Instrumentación: Diseño del Sistema de H2O Capítulo 6: Instrumentación: Diseño del Sistema de H2O Digital Media Server El video en demanda a través del web aún está restringido a las grandes empresas que pueden pagar por contar por un servicio

Más detalles

GRID COMPUTING MALLA DE ORDENADORES

GRID COMPUTING MALLA DE ORDENADORES GRID COMPUTING MALLA DE ORDENADORES Introducción Concepto Compartir potencia computacional; Aprovechamiento de ciclos de procesamiento; El Grid Computing se enmarca dentro de la tecnología de computación

Más detalles

SEDA. Servicio Ejecución Distribuida de Aplicaciones. Dossier de Presentación. Versión 1.0

SEDA. Servicio Ejecución Distribuida de Aplicaciones. Dossier de Presentación. Versión 1.0 SEDA Servicio Ejecución Distribuida de Aplicaciones Dossier de Presentación Versión 1.0 2 SEDA Edificio RD Sistemas 1 ÍNDICE 1 ÍNDICE 3 2 EVOLUCIÓN TECNOLÓGICA DE RDSISTEMAS5 3 ARQUITECTURA SEDA 6 3.1

Más detalles

DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ

DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ 1 DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ CORPORACION UNIVERSITARIA MINUTO DE DIOS TECNOLOGIA EN INFORMATICA SOACHA 2012 2 DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA

Más detalles

SIMATIC Sensors. El nuevo software SIMATIC RF-MANAGER 2008. Para gestionar sistemas RFID con toda facilidad. Folleto técnico Abril de 2008

SIMATIC Sensors. El nuevo software SIMATIC RF-MANAGER 2008. Para gestionar sistemas RFID con toda facilidad. Folleto técnico Abril de 2008 El nuevo software SIMATIC RF-MANAGER 2008 Para gestionar sistemas RFID con toda facilidad Folleto técnico Abril de 2008 SIMATIC Sensors www.siemens.com/rf-manager Homogéneo y flexible Para gestionar sistemas

Más detalles

UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS MODELO DE GESTION WBEM PARA ADMINISTRACION DE REDES

Más detalles

Compiladores y Lenguajes de Programación. Maria de Guadalupe Cota Ortiz

Compiladores y Lenguajes de Programación. Maria de Guadalupe Cota Ortiz Compiladores y Lenguajes de Programación Maria de Guadalupe Cota Ortiz Organizaciones que rigen las normas para estandarización de Lenguajes de Programación IEEE (Instituto de Ingenieros Eléctricos y Electrónicos)

Más detalles

Administración de memoria: Funciones y operaciones

Administración de memoria: Funciones y operaciones Administración de memoria: Funciones y operaciones Facultad de Ingeniería, UNAM Instituto de Investigaciones Económicas, UNAM Índice Introducción 1 Introducción 2 3 4 5 El administrador de memoria Es otra

Más detalles

INDICE. Prefacio Parte 1: sistemas operativos tradicionales

INDICE. Prefacio Parte 1: sistemas operativos tradicionales INDICE Prefacio Parte 1: sistemas operativos tradicionales 1 1 Introducción 1.1 Qué es un sistema operativo? 1.1.1 El sistema operativo como una maquina extendida 3 1.1.2 El sistema operativo como controlador

Más detalles

Introducción a redes Ing. Aníbal Coto Cortés

Introducción a redes Ing. Aníbal Coto Cortés Capítulo 5: Ethernet Introducción a redes Ing. Aníbal Coto Cortés 1 Objetivos En este capítulo, aprenderá a: Describir el funcionamiento de las subcapas de Ethernet. Identificar los campos principales

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles