Proyecto Fin de Carrera Ingeniería de …bibing.us.es/proyectos/abreproy/12366/fichero/Sistema+de...Flujo de información 23 4 Diseño 25 4.1. Tecnología utilizada 25 4.1.1 Hardware

Proyecto Fin de CarreraIngeniería de Telecomunicación

Sistema de infortransportadoras mediante WSN

Autor: Antonio Suárez Reyes

Tutor: Daniel Gutiérrez Reina

Escuela Técnica Superior de Ingeniería

i

Equation Chapter 1 Section 1

Proyecto Fin de Carrera Ingeniería de Telecomunicación

Sistema de información de tráfico en cintas transportadoras mediante WSN

Antonio Suárez Reyes

Daniel Gutiérrez Reina

Dep. Ingeniería Electrónica


Universidad de Sevilla

Sevilla, 2016

Equation Chapter 1 Section 1

mación de tráfico en cintas

iii

Proyecto Fin de Carrera Ingeniería de Telecomunicación

Sistema de información de tráfico en cintas

transportadoras mediante WSN

Autor:


Tutor:

Daniel Gutiérrez Reina

Profesor Sustituto Interino

Dep. Ingeniería Electrónica


Universidad de Sevilla Sevilla, 2016

v

Proyecto Fin de Carrera: Sistema de información de tráfico en cintas transportadoras mediante WSN

Autor: Antonio Suárez Reyes

Tutor: Daniel Gutiérrez Reina

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2016

El Secretario del Tribunal

vii

A mi mujer, María, y a mis hijos

Vera, Roberto y Antonio

ix

Agradecimientos

Aprovecho estas líneas para agradecer especialmente el apoyo de dos inestimables compañeros con los que comencé esta andadura, D. Juan Carlos Lozano Galeano y D. Luis Marmolejo Vidal, así como del resto de la promoción V y de aquellos con los que pude compartir pupitre durante el curso 2012-2013.

Gracias a mis profesores, de quienes guardo un cariñoso recuerdo y que despertaron en mí el entusiasmo por la investigación y por la excelencia.


Sevilla, 2016

xi

Resumen

La rápida evolución de la tecnología genera fuertes incertidumbres en los distintos fabricantes tecnológicos que, en ocasiones, no recuperan la inversión realizada en I+D+i por la pronta obsolescencia del producto desarrollado. No obstante, previo a descartar dicho desarrollo, parece lógico realizar un estudio de mercado suficientemente amplio que pueda detectar nichos no atendidos y en donde podríamos reciclar nuestro producto.

Así, el presente proyecto persigue poner de manifiesto la versatilidad de las motas utilizadas en redes inalámbricas de sensores reorientando su uso en procesos industriales automatizados basados en cintas transportadoras para implementar una auditoría de productividad en dicho entorno.

xiii

Abstract

The quick evolution of technology generates high uncertainties in the various technology manufacturers which, sometimes, do not get back the investment made in R+D due to the rapid obsolescence of the developed product. However, prior to rule out such development, it seems logical to make a market study large enough to detect market niches which are not served and where we could give a second chance to our product.

Thus, this project aims to demonstrate the versatility of the motes used in wireless sensor networks reorienting its use in automated industrial processes based on conveyor belts to implement a productivity audit there.

xv

Índice

Agradecimientos ix

Resumen xi

Abstract xiii

Índice xv

Índice de Tablas xvii

Índice de Figuras xix

1 Introducción 1 1.1. Presentación del problema 1 1.2. Objetivos del proyecto 2

1.2.1. Descripción del problema 2 1.2.2. Objetivos de la solución 3

1.3. Descripción de alto nivel de la solución 3 1.4. Descripción estructurada del resto de la memoria 4

2 Antecedentes 5 2.1. Estado del arte de auditorías de procesos industriales automatizados basados en cintas

transportadoras 5 2.1.1 Automatización de procesos industriales 5 2.1.2 Tipos de cintas transportadoras 7 2.1.3 Redes industriales 11 2.1.4 Auditoría de procesos industriales 14

2.2. Estado del arte de redes WSN 15 2.2.1 Elementos de las WSN (nodos) 15 2.2.2 Arquitecturas y topologías de red 17

3 Análisis 19 3.1. Enfoque del proyecto 19 3.2. Condicionantes y criterios adoptados 20 3.3. Arquitectura del sistema 22 3.4. Flujo de información 23

4 Diseño 25 4.1. Tecnología utilizada 25

4.1.1 Hardware 25 4.1.2 Software 26

4.2. Diagrama de componentes 30 4.2.1 Diagrama UML de componentes de la aplicación PC 30

4.2.2 Diagrama de componentes TinyOS 31 4.3. Casos de uso de la aplicación 31 4.4. Criterios de diseño 34

4.4.1 Adaptación del diseño: Base de tiempos 36 4.5. Descripción de la interfaz de usuario 38

5 Resultados 41 5.1. Producto obtenido 41 5.2. Cumplimiento de objetivos 43

6 Conclusiones 45 6.1. Desarrollo del proyecto 45 6.2. Conclusiones 46 6.3. Líneas de desarrollo 46

Apéndices 49 Apéndice A: Manual de usuario 49

Referencias 59

xvii

Índice de Tablas

Tabla 4–1. Software utilizado 27

Tabla 4–2. Especificación del caso de uso “Solicita informe” 32

Tabla 4–3. Especificación del caso de uso “Genera datos” 33

Tabla 4–4. Ejemplo de datos reportados a la aplicación PC 35

Tabla 4–5. Significado de los campos “Tipo” y “Valor” 35

Tabla 4–6. Algoritmo de sincronización previsto inicialmente 37

xix

Índice de Figuras

Figura 1-1. Proceso industrial de almacén automatizado 2

Figura 2-1. Roller conveyor 7

Figura 2-2. Skate-wheels conveyor 8

Figura 2-3. Belt conveyor 8

Figura 2-4. Chain conveyor 9

Figura 2-5. Slat conveyor 9

Figura 2-6. Overhead trolley conveyor 10

Figura 2-7. In-floor towline conveyor 11

Figura 2-8. Bus AS-i en planta de transporte industrial 12

Figura 2-9. Instalación con bus AS-i en laboratorios de automática de la ESI de Sevilla 12

Figura 2-10. Detalle de la conectividad del bus AS-i 13

Figura 2-11. Logotipos de las tecnologías WiFi, Bluetooth y ZigBee 14

Figura 2-12. Logotipo de DOEET 15

Figura 2-13. Esquema de bloques de un nodo 16

Figura 2-14. Diferentes topologías de red 18

Figura 3-1. Proceso de ingeniería genérico 19

Figura 3-2. Enfoque del presente proyecto 20

Figura 3-3. Obtención de medidas mediante la adecuada configuración 21

Figura 3-4. Esquema de funcionamiento 21

Figura 3-5. Arquitectura Cliente – Servidor 23

Figura 3-6. Esquema de comunicación del sistema 23

Figura 3-7. Diagrama de bloques del sistema 24

Figura 4-1. Detalle mota COU_1_2 26

Figura 4-2. Origen de la arquitectura TinyOS 27

Figura 4-3. Arquitectura TinyOS simplificada 28

Figura 4-4. Modelo de componente TinyOS y su interacción 29

Figura 4-5. Gráfico de componentes de una aplicación genérica 30

Figura 4-6. Diagrama UML de la aplicación PC 30

Figura 4-7. Diagrama de componentes TinyOS de la aplicación MotaAApp 31

Figura 4-8. Diagrama de componentes TinyOS de la aplicación MotaBApp 31

Figura 4-9. Casos de uso de SIT-WSN 32

Figura 5-1. Detalle de ubicación de motas 41

Figura 5-2. Informe SitWsn de la prueba realizada 42

Figura 7-1.Compilación y carga de la aplicación en la mota A 50

Figura 7-2. GUI de IDE de Eclipse 54

Figura 7-3. Ayuda contextual de SitWsn.xlsm 55

Figura 7-4. Pantalla principal de SitWsn.xlsm 55

Figura 7-5. Formulario de selección del reporte.csv 56

Figura 7-6. Información del número de errores 56

Figura 7-7. Alarmas y menú contextual 57

1

1 INTRODUCCIÓN

n el contexto actual, marcado por la rápida evolución de múltiples tecnologías, el verdadero valor añadido se encuentra en ser capaz de detectar las necesidades no atendidas, por cuanto eran impensables antes de la existencia de dichas tecnologías.

En este sentido, adicionalmente, debe tenerse en cuenta que existen tecnologías que nacieron para dar solución a determinadas necesidades y que, tras quedar obsoletas por otras tecnologías más específicas o con mejores prestaciones, han tenido un desarrollo más amplio y con mayor recorrido en otros campos distintos al objetivo inicial para el que fueron creadas.

Son estos dos principios, el comercial y la flexibilidad y reciclabilidad de la tecnología, los que inspiran el presente proyecto que ofrece un sistema de información para auditorías de eficiencia de procesos industriales automatizados basados en cintas transportadoras mediante WSN1 implementada con motas COU 1_2 24 A2.

1.1. Presentación del problema

El diseño de nuevos procesos industriales automatizados basados en cintas transportadoras requiere de un esfuerzo de integración de diversos sistemas [1] que se agiliza mediante el uso de software de simulación como ARENA, CPN, GSPN, SIMAN o WITNESS.

En dichas simulaciones intervienen modelos estadísticos simplificados tanto de los procesos de tratamiento o transformación como de los flujos previstos de entrada y salida a éstos de las piezas o materias a transformar.

La acumulación de errores derivados de las simplificaciones en los citados modelos da lugar a diseños subóptimos cuyo rendimiento queda enmascarado por las expectativas conservadoras que precisamente generan las simulaciones realizadas a partir de los mismos y que sólo se manifiestan al compararse con los mejores resultados de otras plantas o centros cuyos rendimientos esperados eran, a priori, similares.

1 WSN: Redes inalámbricas de sensores, del inglés Wireless Sensor Networks.

E

Todo comienzo tiene su encanto.

- Johann Wolfgang von Goethe -

Introducción

2

2

Es en este contexto en el que se hace necesaria una auditoria que arroje luz sobre el posible gap entre la eficiencia real del proceso en su conjunto y la potencialidad del mismo. No obstante, dicha auditoría puede requerir múltiples medidas en diferentes puntos de las instalaciones, muchos de ellos de difícil acceso y donde puede no llegar cableada la habitual red industrial (AS-i, Profibus, Device Net, Compobus, CAN BUS, LONWorks, etc.) para la comunicación con sensores y actuadores implicados en la automatización.

La no existencia de soluciones de bajo coste que justifiquen el estudio junto con la defensa de la idoneidad del diseño inicial ha llevado en la actualidad a escasas auditorías de eficiencia en procesos industriales automatizados basados en cintas transportadoras.

1.2. Objetivos del proyecto

Con todo lo indicado, el presente proyecto tiene por objetivos:

- Poner el foco en la potencialidad de la tecnología WSN que, por su reducido coste y permitir medidas en ubicaciones de difícil acceso, posibilita la detección de necesidades no cubiertas. Esto es: nuevos mercados.

- Evidenciar la flexibilidad y reciclabilidad de los elementos hardware y software que conforman la WSN.

- De forma paralela, realizar un esfuerzo de integración entre distintas tecnologías.

1.2.1. Descripción del problema

Para facilitar una descripción detallada del problema, con el objetivo de visualizar el contexto, obsérvese la figura 1-1 que nos sitúa en una planta industrial automatizada basada en cintas transportadoras.

Figura 1-1. Proceso industrial de almacén automatizado

3

3 Sistema de información de tráfico en cintas transportadoras mediante WSN

Se trata de un almacén automatizado donde se mezclan cintas transportadoras de tipo roller conveyors (rodillos) tanto de impulso mecánico como gravitatorio y belt conveyors (cintas planas). Así, aun suponiendo un patrón homogéneo de entrada de paquetes, el paso por los diferentes tipos de cintas, algunas de las cuáles con deslizamientos, y especialmente la reclasificación en los distintos procesos, genera patrones de salida aleatorios.

Con el objetivo de realizar una auditoría exhaustiva orientada a la optimización del proceso podemos requerir conocer dichos patrones en cada punto de la planta.

Sin embargo, es posible que las variables de control necesarias para la automatización del mismo fueran más reducidas y la red industrial no alcance, ni esté preparada para incorporar nuevos sensores en lugares remotos.

De forma adicional, el objetivo que perseguimos – una auditoría de eficiencia de procesos – no parece sugerir la instalación de nuevos sensores permanentes que puedan incrementar el coste de la misma y de su posterior mantenimiento.

Ante este problema, exigimos que la solución a desarrollar cumpla los siguientes objetivos.

1.2.2. Objetivos de la solución

La solución a implementar deberá verificar los siguientes objetivos:

a) Permitir una rápida instalación y desinstalación.

b) Alcanzar cualquier punto de la planta industrial.

c) Realizar las mínimas exigencias al sistema previo, garantizando así la máxima generalidad.

d) Reportar la velocidad y flujo de paquetes así como la longitud de éstos.

e) Tener un coste inferior al 10% respecto de la opción de ampliar el número de sensores propios del sistema de automatización, en caso de que ésta sea posible.

1.3. Descripción de alto nivel de la solución

La solución propuesta está basada en sensores de reducido tamaño y consumo. Su alimentación autónoma y su comunicación inalámbrica facilitarán alcanzar cualquier punto de la planta industrial sin necesidad de cableado adicional, favoreciendo así la consecución de los objetivos a) y b).

Se exigirá una iluminancia mínima de 200 lux así como que la disposición entre cada pieza u objeto permita una distancia mínima sin sombra de 0,03 m. Una solución alternativa, podría sustituir éstos requisitos por una baliza magnética en cada paquete. En ambos caso, se persigue dar cumplimiento al objetivo c).

Introducción

4

4

En cada punto situaremos dos sensores que reportarán velocidades y flujo de paquetes así como la longitud de los mismos (objetivo d) comunicándose entre sí y con el resto formando una red inalámbrica de sensores (WSN).

Los sensores tienen un coste limitado y son reutilizables en posteriores auditorías por lo que dicha inversión podría repercutirse entre todas, amortizándose de forma acelerada. Del mismo modo, ya que la instalación y desinstalación será rápida, apenas existirá mano de obra. Ambos extremos minimizan el coste del servicio de forma que se pueda ajustar para cumplir el objetivo e).

1.4. Descripción estructurada del resto de la memoria

La presente memoria se encuentra estructurada en los siguientes puntos principales:

1. Introducción. En él describimos a alto nivel el problema a resolver así como su origen, los objetivos que planteamos con el presente proyecto y la solución acorde a éstos.

2. Antecedentes. Se trata del estado del arte tanto del problema propuesto así como de las soluciones actuales.

3. Análisis. Exponemos el enfoque del proyecto, condicionantes y criterios adoptados, detallando su arquitectura así como el flujo de información de la aplicación.

4. Diseño. Abordamos la tecnología utilizada, metodología de desarrollo, diagrama de componentes y casos de uso así como la descripción de la interfaz de usuario.

5. Resultados. Ofrecemos distintos ejemplos describiendo los resultados obtenidos con los que se evalúa el sistema verificando el cumplimiento de los objetivos marcados.

6. Conclusiones. Detallamos el desarrollo del proyecto señalando las dificultades encontradas, aportando las conclusiones derivadas del mismo y proponiendo líneas de desarrollo futuro.

Apéndice A: Consiste en el manual del usuario.

5

2 ANTECEDENTES

n este capítulo se ampliará el contexto iniciado en la presentación y descripción del problema presentando el estado del arte de las auditorías de procesos industriales automatizados basados en cintas transportadoras así como de las redes WSN.

2.1. Estado del arte de auditorías de procesos industriales automatizados basados en cintas transportadoras

Este único punto podría ser objeto de múltiples tesis doctorales por lo que realizaremos una síntesis de [2] ya que, en última instancia, lo que se persigue es situar contextualmente el entorno donde y para el que se desarrolla la aplicación propuesta.

2.1.1 Automatización de procesos industriales

De una parte, [3] define la automatización de procesos industriales en "el empleo de dispositivos electrónicos o mecánicos para sustituir trabajo humano" que su reformula manteniendo la esencia.

En [4] ya se relacionó las ventajas de la automatización:

- Aumento de la productividad y consistencia en los productos [5]

- La automatización genera una estabilidad y robustez en el sistema.

- Las tecnologías de automatización no presentan fallos.

- Mejorar las condiciones de trabajo del personal, incrementando la seguridad.

E

Lo que no se define, no se puede medir.

- Lord Kelvin -

Antecedentes

6

6

- Realizar las operaciones imposibles físicamente para el operador humano.

- Mejorar la disponibilidad de los productos, pudiendo generar las cantidades necesarias en el momento preciso.

- Integrar la gestión y producción.

En primer lugar [6], posteriormente [7] y por último [8] diferencian 4 tipos de automatización:

- Automatización fija. Las restricciones que presentan los equipos de fabricación van a condicionar la secuencia de producción. Este tipo de automatización presenta las siguientes características:

o Está constituida por una secuencia sencilla de operaciones.

o Requiere una gran inversión debido a la demanda de equipos muy especializados.

o Posee unos elevados ritmos de producción

o No se adapta a variaciones de la demanda.

- Automatización programable. Se aplica en sistemas de fabricación donde el equipo de producción está diseñado para realizar cambios en la secuencia de operaciones según los diferentes productos. Es adecuada para la fabricación por lotes y no permite realizar cambios en la configuración de los productos. A continuación indicamos una serie de características que completan la definición.

o Existencia de un periodo previo para la fabricación de los distintos lotes.

o Para realizar lotes de productos distintos, se introducen cambios en el programa y en la disposición física de los elementos.

o Se realiza una gran inversión en equipos de aplicación general como por ejemplo las máquinas de control numérico.

o Un ejemplo de este tipo de automatización son los PLC (Controladores lógicos programables) y los robots.

- Automatización flexible. Surge con el objetivo de subsanar algunas de las deficiencias presentadas por la automatización programable. Está capacitada para producir cambios en los programas y en la relación existente entre los elementos del sistema de fabricación. Un ejemplo de automatización flexible son las máquinas de control numérico.

7


- Automatización integrada. Su objetivo es la integración dentro del sistema productivo de los distintos tipos de automatización. Presenta las siguientes características.

o Se reduce el tamaño de los lotes.

o Existe una mayor diversificación del producto en muchos casos superior a la automatización flexible.

o Permite agilizar los plazos de entrega del producto.

o Su implantación está justificada en procesos de producción discretos y en continuos. Por ejemplo tiene una gran implantación en industrias químicas.

2.1.2 Tipos de cintas transportadoras

Las cintas transportadoras son, conforme hemos visto, elementos fundamentales en el esquema de los procesos industriales automatizados. No obstante, la propia esencia de éstas va a introducir desviaciones respecto al comportamiento del sistema en su conjunto. Así, resulta conveniente conocer los distintos tipos de cintas transportadoras que existen en la actualidad [9]:

- Roller conveyors (rodillos) (véase figura 2-1)

o Forma muy común de cinta

o Tubos (rodillos) perpendiculares a la dirección de avance

o Armazón fijo que eleva la cinta del suelo desde varios decímetros a algo más de un metro.

o Pallets planos o bandejas portando la carga

o Impulsadas mecánicamente o gravitatorias

o Tipo gravitatorio: el camino desciende una pendiente suficiente para superar la fricción de los rodillos.

o Usadas para el reparto de cargas durante las operaciones de procesado, y almacenamiento automático. También en aplicaciones de distribución.

o También usadas para operaciones de clasificación y combinado.

Figura 2-1. Roller conveyor

Antecedentes

8

8

- Skate-wheels conveyors (con ruedas) (véase figura 2-2)

o Operativamente similares a los rodillos.

o Pequeñas ruedas como las de los “patines” montadas sobre ejes rotatorios conectados al armazón.

o Pallet, bandeja, u otro contenedor.

o Aplicaciones similares a las de los rodillos, excepto que las cargas deben ser en general más ligeras al estar los contactos entre carga y cinta mucho más concentrados.

Figura 2-2. Skate-wheels conveyor

- Belt conveyors (cintas planas) (véase figura 2-3)

o 2 formatos comunes:

� cintas planas para pallets, piezas o incluso ciertos tipos de materiales en masa.

� cintas huecas para materiales en masa.

o Los materiales se sitúan en la superficie de la cinta.

o La cinta forma un lazo continuo

� reparto del material.

� retorno (generalmente vacío).

o La cinta se soporta con un armazón con rodillos u otros soportes espaciados entre sí varios decímetros.

o A cada extremo de la cinta están los rodillos motores (“poleas”) que impulsan la cinta.

Figura 2-3. Belt conveyor

9


- Chain conveyors (con cadenas) (véase figura 2-4)

o Lazos de cadena sin fin en una configuración arriba-abajo alrededor de ruedas dentadas motorizadas, en los extremos del camino.

o Puede haber una o más cadenas operando en paralelo para formar la cinta.

o Las cadenas viajan a lo largo de canales que proporcionan soporte para las secciones flexibles de la cadena. 2 opciones:

� Las cadenas se desplazan por canal.

� Las cadenas usan rodillos para montarse al canal.

Figura 2-4. Chain conveyor

- Slat conveyors (con listones) (véase figura 2-5)

o Plataformas individuales, llamadas listones o tablillas, conectadas a una cadena continua en movimiento.

o Aunque el mecanismo impulsor es la cadena, funciona en gran medida como una cinta plana.

o Las cargas se sitúan sobre la superficie plana de las tablillas y se desplazan con ellas.

o Los caminos son generalmente en línea recta, pero dada la posibilidad de introducir curvas en el camino mediante ruedas dentadas (engranadas a la cadena), las cintas con listones pueden tener giros en su lazo continuo.

Figura 2-5. Slat conveyor

Antecedentes

10

10

- Overhead trolley conveyors (véase figura 2-6)

o Un carro (trolley) es un soporte con ruedas moviéndose en un raíl elevado del que puede colgar la carga.

o Una cinta de carros es una serie de múltiples carros igualmente espaciados a lo largo de los raíles mediante una cadena sin fin o cable.

o La cadena o cable está unida a una rueda que proporciona energía al sistema.

o El camino está determinado por el sistema de raíles; tiene giros y cambios en elevación formando un lazo sin fin.

o En los carros se suspenden ganchos, cestas u otros receptáculos para la carga.

o Se emplean a menudo en fábricas para mover piezas y conjuntos de ensamblaje entre los principales departamentos de producción.

o Pueden emplearse tanto para reparto como para almacenamiento.

Figura 2-6. Overhead trolley conveyor

- In-floor towline conveyor (cable enterrado) (véase figura 2-7)

o Emplean vehículos con ruedas impulsados por medio de cadenas o cables en movimiento situados en zanjas en el suelo.

o Las rutas están definidas por las zanjas y cables.

o Es posible el cambio desde un segmento impulsado a otro diferente, proporcionando cierta flexibilidad en el rutado.

o Los carros emplean clavijas reforzadas de acero para acoplarse a la cadena.

o Dichas clavijas se pueden extraer de la zanja para liberar al carro del avance de la cadena y realizar las operaciones de carga/descarga.

11


Figura 2-7. In-floor towline conveyor

2.1.3 Redes industriales

2.1.3.1 Redes cableadas

La automatización industrial requiere la conectividad entre sensores - actuadores y los elementos de control. Hasta la fecha dicha conectividad se ha venido implementando mayoritariamente de forma cableada existiendo múltiples normas que vienen compitiendo por imponerse, entre las que destacamos, siguiendo a [10]: Profibus, Fieldbus Foundation, AS-i, LonWorks, Interbus, DeviceNet, MODBUS, HART, ControlNet, WORLFIP, FIP, e incluso Ethernet.

El análisis detallado de cada una de ellas carece de interés para el presente proyecto. No obstante, sí desglosaremos el bus AS-i a efectos ilustrativos de los elementos necesarios para la implementación genérica de dichas redes.

Así, conforme a [11] y [12], el bus AS-i (Actuator-Sensor Interface) fue creado en 1.990 con el objetivo de minimizar el cableado necesario al incorporar las señales de sensores, actuadores y alimentación en el mismo cable. Se encuentra definido en el estándar internacional IEC62026-2 y en el europeo EN50295.

Actualmente en su versión 3 admite tanto sensores y actuadores binarios y analógicos, siendo un sistema monomaestro que facilita gran flexibilidad de topologías. Se caracteriza por un cable amarillo autocicatrizante (en la figura 2-10 se muestra el detalle de su conectividad) codificado mecánicamente para evitar su polarización incorrecta que tiene un alcance máximo de 100 metros (300 metros con repetidores) y admite hasta 248 sensores y 186 actuadores binarios.

Así, con el objetivo de contextualizar visualmente el bus AS-i, en las figuras 2-8 y 2-9 se muestra respectivamente el rutado de éste en una planta de transporte industrial y una instalación del mismo en los laboratorios de automática de la ESI de Sevilla

Antecedentes

12

12

Figura 2-8. Bus AS-i en planta de transporte industrial

Figura 2-9. Instalación con bus AS-i en laboratorios de automática de la ESI de Sevilla

13


Figura 2-10. Detalle de la conectividad del bus AS-i

2.1.3.2 Redes inalámbricas

En los últimos años viene proliferando el uso de redes inalámbricas en entornos industriales motivadas por la no necesidad de cableado que favorece la instalación de sensores – actuadores en ubicaciones en las que anteriormente se descartaban por no justificar suficientemente el incremento de costes.

Entre las tecnologías con mayor auge, cuyos logotipos se muestran en la figura 2-11, y sus características más relevantes en relación a los entornos industriales destacamos, siguiendo a [13]:

- Redes 802.11 (Wifi)

o Son redes robustas frente al ruido e interferencias, especialmente tras la incorporación de la tecnología MiMo. Dependiendo de los equipos utilizados (antenas, repetidores, …) pueden cubrir superficies arbitrariamente extensas de hasta 500 m – 1 km con un coste reducido.

o La velocidad de transmisión alcanza los 300 Mbps permitiendo, incluso, aplicaciones en tiempo real. No obstante, en dichos entornos industriales, habitualmente, el volumen de datos es exiguo así como la velocidad necesaria.

o Entorno de difusión mediante el uso del canal en modo semidúplex.

- Redes 802.15.1 (Bluetooth)

o Son redes de corto alcance. En aplicaciones industriales se usa la clase 1, con un consumo de 100 mW (elevado), alcanzando entorno a 100 m.

o Velocidades de transmisión de hasta 3 Mbps en capa física, lo que supone un bajo rendimiento para tráfico en tiempo real.

14

o Comunicaciones maestro

- Redes 802.15.4 (ZigBee)

o Tienen un alcance máximo de unos 75 m, requiriendo un consumo mínimo ya que la potencia de transmisión habitual es de 0 suficientes para un periodo entre 6 y 24 meses.

o La velocidad de transmisión puede alcanzar los 250 Kbps, suficiente para la transmisión en bucles de control industrial.

o Existen equipos coordin

Figura 2-11. Logotipos de las tecnologías WiFi, Bluetooth y ZigBee

2.1.4 Auditoría de procesos industriales

Existen tantas auditorías de procesos industriales como ámbitoptimizar. Así, tenemos auditorías de calidad, de seguridad, medioambientales, energéticas, etc. De entre todas ellas, nos centraremos en las auditorías de productividad

Las auditorías de productividad [14] [15]

- El nivel de productividad real del proceso estudiado, calculándose mediante el indicador internacional de productividad, en inglés Overall Equipment Effectiveness (OEE) que engloba la disponeficiencia y la calidad.

- La identificación de procesos o tareas que no aportan valorprocesos basados en cintas transportadoras, aquellas líneas que apenas se utilizan y, por tanto, serían susceptibles de eliminar.

- La identificación de puntos negros

- La propuesta de acciones correctivasde nuevo, en el indicador OEE, conforme a técnicas de Lean Manufacturing.

14

Comunicaciones maestro – esclavo, permitiendo un número reducido de esclavos activos.

Tienen un alcance máximo de unos 75 m, requiriendo un consumo mínimo ya que la potencia de transmisión habitual es de 0 dBm, posibilitando que, en función de su uso, 2 pilas AA sean suficientes para un periodo entre 6 y 24 meses.

La velocidad de transmisión puede alcanzar los 250 Kbps, suficiente para la transmisión en bucles de control industrial.

Existen equipos coordinadores, repetidores y terminales.

Logotipos de las tecnologías WiFi, Bluetooth y ZigBee

Auditoría de procesos industriales

Existen tantas auditorías de procesos industriales como ámbitos susceptibles de ajustar a normativa u optimizar. Así, tenemos auditorías de calidad, de seguridad, medioambientales, energéticas, etc. De entre todas

auditorías de productividad.

[15] reportan:

real del proceso estudiado, calculándose mediante el indicador internacional de productividad, en inglés Overall Equipment Effectiveness (OEE) que engloba la dispon

identificación de procesos o tareas que no aportan valor por ende de su nivel de productividad. En procesos basados en cintas transportadoras, aquellas líneas que apenas se utilizan y, por tanto, serían

identificación de puntos negros que implican sobrecostes.

propuesta de acciones correctivas como consecuencia del análisis de los datos arrojados basados, de nuevo, en el indicador OEE, conforme a técnicas de Lean Manufacturing.

Antecedentes

esclavo, permitiendo un número reducido de esclavos activos.

Tienen un alcance máximo de unos 75 m, requiriendo un consumo mínimo ya que la potencia dBm, posibilitando que, en función de su uso, 2 pilas AA sean

La velocidad de transmisión puede alcanzar los 250 Kbps, suficiente para la transmisión en

Logotipos de las tecnologías WiFi, Bluetooth y ZigBee

os susceptibles de ajustar a normativa u optimizar. Así, tenemos auditorías de calidad, de seguridad, medioambientales, energéticas, etc. De entre todas

real del proceso estudiado, calculándose mediante el indicador internacional de productividad, en inglés Overall Equipment Effectiveness (OEE) que engloba la disponibilidad, la

por ende de su nivel de productividad. En procesos basados en cintas transportadoras, aquellas líneas que apenas se utilizan y, por tanto, serían

como consecuencia del análisis de los datos arrojados basados,


En la actualidad existen múltiples propuestas para implementar auditorías de productividad que van desde procesos metrológicos manuales hasta la adquisición de datos más o menos automatizada reportada por los sistemas de información del proceso auditado.

Tal es el caso de DOEET [16] (ver logotipo en figura 2información de los distintos sistemas de adquisición de datos ya instalados (Siemens, Omron, Phoenix Contact, …) o directamente del ERP (SAP, Microsoft Dynamics, Oracle, Sage, Crystal Reports, …).

No obstante, estos sistemas se alimentan de la información preexistente que puede resultar insuficiente o incompleta para inferir los datos que requiere el cálculo del OEE.

2.2. Estado del arte de redes WSN

De nuevo, al igual que en el estado del arte de los procesos industriales automatizados basados en cintas transportadoras, la temática de las redes WSevolución. Es por ello que se abordarán, de forma sintetizada, los aspectos esenciales que faciliten el de la aplicación propuesta siguiendo a

2.2.1 Elementos de las WSN (nodos)

Las redes inalámbricas de sensores están formadas por dispositivos autónomos (nodos) de reducido tamaño y consumo, que recogen información de coordinador.

De la definición dada se puede colegir la estructura física de los nodos que requiere autonomía (alimentación propia) para la recogida de datos (sensores) que se procesan a (transceptor de radio). Así, en la figura 2

15


la actualidad existen múltiples propuestas para implementar auditorías de productividad que van desde procesos metrológicos manuales hasta la adquisición de datos más o menos automatizada reportada por los sistemas de información del proceso auditado.

(ver logotipo en figura 2-12) que se conecta a la red industrial para recoger la información de los distintos sistemas de adquisición de datos ya instalados (Siemens, Omron, Phoenix

mente del ERP (SAP, Microsoft Dynamics, Oracle, Sage, Crystal Reports, …).

No obstante, estos sistemas se alimentan de la información preexistente que puede resultar insuficiente o incompleta para inferir los datos que requiere el cálculo del OEE.

Figura 2-12. Logotipo de DOEET

Estado del arte de redes WSN

De nuevo, al igual que en el estado del arte de los procesos industriales automatizados basados en cintas transportadoras, la temática de las redes WSN es profusa (véase [17], [18] o [19]), manteniéndose en constante evolución. Es por ello que se abordarán, de forma sintetizada, los aspectos esenciales que faciliten el

siguiendo a [20].

Elementos de las WSN (nodos)

Las redes inalámbricas de sensores están formadas por dispositivos autónomos (nodos) de reducido tamaño y consumo, que recogen información de su entorno, pudiendo procesarla localmente y comunicarla a un equipo

De la definición dada se puede colegir la estructura física de los nodos que requiere autonomía (alimentación propia) para la recogida de datos (sensores) que se procesan a nivel local (microcontrolador) y se comunica

en la figura 2-13 se presenta un esquema básico de los bloques de cada nodo.

15

la actualidad existen múltiples propuestas para implementar auditorías de productividad que van desde procesos metrológicos manuales hasta la adquisición de datos más o menos automatizada reportada por los

que se conecta a la red industrial para recoger la información de los distintos sistemas de adquisición de datos ya instalados (Siemens, Omron, Phoenix

mente del ERP (SAP, Microsoft Dynamics, Oracle, Sage, Crystal Reports, …).

No obstante, estos sistemas se alimentan de la información preexistente que puede resultar insuficiente o

De nuevo, al igual que en el estado del arte de los procesos industriales automatizados basados en cintas , manteniéndose en constante

evolución. Es por ello que se abordarán, de forma sintetizada, los aspectos esenciales que faciliten el desarrollo

Las redes inalámbricas de sensores están formadas por dispositivos autónomos (nodos) de reducido tamaño y su entorno, pudiendo procesarla localmente y comunicarla a un equipo

De la definición dada se puede colegir la estructura física de los nodos que requiere autonomía (alimentación nivel local (microcontrolador) y se comunica

bloques de cada nodo.

Antecedentes

16

16

Figura 2-13. Esquema de bloques de un nodo

Lógicamente, la implementación física admite una doble posibilidad:

- Integrar todos los componentes en una única placa dando lugar a un menor coste de producción y mayor robustez.

- Separar el sistema de adquisición de datos (sensores) del sistema de procesamiento y comunicaciones en placas independientes con conectividad entre ambas generando una mayor versatilidad al poder seleccionar el conjunto de sensores necesario.

En la distinta bibliografía se usa el término mota para designar a la placa que implementa el sistema de procesamiento y comunicaciones. Si bien, también se utiliza denotando al sistema completo de una única placa, siendo sinónimo de nodo. Puede obtenerse una profusa comparativa de las distintas motas en [21] y en [22].

Existen otros dos elementos propios de las WSN como es el Gateway y los enrutadores. El primero es el elemento que permite interconectar la red de sensores con una red TCP/IP (ej. MIB600 [23]) con el objetivo de facilitar el acceso a los datos recogidos. Los segundos se dan en contextos de arquitecturas distribuidas donde los nodos deben colaborar entre sí para hacer llegar los datos al Gateway. Dicha colaboración implica un coste de computación y, por ende, de consumo. Los enrutadores asumen dicha labor eliminado la carga de los nodos.

2.2.1.1 Sensores

En cuanto al conjunto de sensores, el rango de posibilidades que ofrece el mercado es amplio estando sólo limitado por la idoneidad para la aplicación a desarrollar. Así, encontramos placas con sensores de temperatura, humedad en aire / suelo, velocidad del viento, sonido, radiación solar, efecto Hall, posición GPS, presión barométrica, etc.

2.2.1.2 Transmisores / receptores de radio

Las tecnologías inalámbricas más utilizadas para los transmisores / receptores de radio coinciden con las expuestas en el caso de redes industriales, es decir:

- 802.11 (WiFi)

- 802.15.1 (Bluetooth)

- 802.15.4 (sobre el que se soporta ZigBee, XBee, 6LoWPAN o WirelessHART).

Sensor/es Transmisor / receptor radio

CPU / Memoria

Fuente de energía

17


No obstante, considerando las exigencias relativas al consumo y el habitual reducido volumen de información, una extensa mayoría ha optado por ZigBee con velocidades de 250 Kbps y alcances de hasta 75 – 100 metros lo que limita las aplicaciones y la topología de la red.

2.2.1.3 CPU / Memoria

Del mismo modo que el caso anterior, la limitación del consumo viene perfilando la CPU utilizada pudiendo citar, entre otras, las familias:

- Atmel ATmega

- TI MSP430

- ARM Cortex Mx

La memoria, a su vez, depende de la CPU y aplicación a desarrollar, siendo habituales RAM de 4 KB, memorias de programa (normalmente de tipo EEPROM) de 128 KB, y memorias flash de 512 KB. No obstante, el rango es amplio.

2.2.1.4 Sistema operativo

En los nodos que componen las WSN corre un sistema operativo que, con el mismo objetivo de reducción del consumo, se ha ajustado reduciendo o incluso eliminando procesos accesorios no básicos.

Existe un conjunto amplio de sistemas operativos utilizados (véase [24]) entre los que destacamos:

- TinyOS.

- ContikiOS.

- FreeRTOS.

2.2.1.5 Fuente de energía

Considerando el reducido tamaño y consumo, las 2 pilas AA se han convertido prácticamente en un estándar de facto que vienen aceptando las distintas placas.

2.2.2 Arquitecturas y topologías de red

Dentro de la arquitectura centralizada, donde los nodos se comunican directamente con el Gateway, encontramos la topología en estrella. De otra parte, en la arquitectura distribuida, donde los nodos sólo se comunican con otros nodos a su alcance, encontramos una topología mallada que exige funciones de enrutamiento a los nodos.

Existen soluciones intermedias, haciendo uso de enrutadores que descargan a los nodos de las labores de enrutamiento.

En la figura 2-14 se muestran las diferentes topologías de red comentadas.

Antecedentes

18

18

Figura 2-14. Diferentes topologías de red

La arquitectura distribuida sugiere, conforme se ha indicado, un enrutamiento de los datos para los que, a su vez, existen distintos modelos. Entre ellos:

- Broadcast.

- Multi-hops.

- Clústers.

- Data-Centric.

Gateway Router Sensor Sensor con enrutamiento

19

3 ANÁLISIS

n el presente capítulo se abordará el enfoque desde el que se realiza el proyecto, los condicionantes y criterios adoptados que lo parametrizan así como la descripción detallada de su arquitectura que, de forma implícita, determina el flujo de información de la aplicación.

3.1. Enfoque del proyecto

En un gran número de ocasiones, la labor a desarrollar en ingeniería comenzará con un problema inscrito entre condicionales al que tendremos que dar una solución óptima eligiendo la tecnología que mejor se adapte al mismo. La figura 3-1 pretende esquematizar dichas situaciones.

Figura 3-1. Proceso de ingeniería genérico

Otra posibilidad es la de un fabricante tecnológico que debe explorar nuevos mercados para la tecnología de la que ya dispone. Con este fin, la solución que aporte debe ser mejor, en algún aspecto, respecto de las existentes. La otra opción es responder a problemas no planteados hasta el momento. Éste es el enfoque del presente proyecto que se muestra en la figura 3-2.

E

Elección

Solución

óptima

Condicionantes

Problema

Tecnología Adaptada

Lo que no se mide, no se puede mejorar.

- Lord Kelvin -

Análisis

20

20

Figura 3-2. Enfoque del presente proyecto

No obstante a lo anterior, el análisis se realizará suponiendo un proceso de ingeniería genérico donde la tecnología se encuentra preseleccionada pasando ésta a integrarse dentro de los condicionantes del problema a resolver.

3.2. Condicionantes y criterios adoptados

Conforme a la cita de Lord Kelvin con la que iniciamos el presente capítulo “Lo que no se mide, no se puede mejorar”, la adquisición de datos se erige como un elemento imprescindible para la optimización de procesos en general.

No obstante, la recogida de información puede conllevar, en ocasiones, un elevado coste económico, en particular si el origen de la misma se encuentra geográficamente disperso.

En este marco, una red de sensores inalámbricos de bajo coste de instalación y mantenimiento se antoja especialmente útil para cualquier aplicación de características similares.

En el capítulo 1 se ha descrito suficientemente el contexto concreto en el que se desarrolla el presente proyecto y los objetivos del mismo. Así, a modo de resumen, nos encontramos ante un proceso industrial automatizado basado en cintas transportadoras donde queremos realizar una auditoría del tráfico de elementos en múltiples puntos de control de dichas cintas con el objetivo de determinar su eficiencia para, en su caso, proponer modificaciones en el diseño con el fin de incrementar su productividad.

Adicionalmente, conocemos la tecnología con la que vamos a implementar la adquisición de dichos datos. En este sentido, disponemos de motas dotadas de sensores de temperatura, luminosidad y efecto Hall que, a su vez, permiten conocer el estado de la tensión de alimentación y comunicarse entre ellas formando la citada red inalámbrica de sensores.

De este modo, conforme representa la figura 3-3, debemos realizar una configuración de las motas de forma que, a partir de las medidas de variables principales (temperatura, luminosidad…) puedan derivarse otras

Búsqueda

Solución

actual

Tecnología

dada

Que mejore

Solución

no existente O aporte

Condicionantes

Problema

21


secundarias (número de elementos, longitudes, velocidades, …) evidenciando que la potencialidad de las mismas tiene un mayor recorrido que la mera captación de datos.

Figura 3-3. Obtención de medidas mediante la adecuada configuración

Así, situaremos dos motas en dos puntos fijos próximos a la ubicación elegida en la cinta transportadora y separadas entre sí por una distancia conocida de forma que cuando un elemento circule por ésta, “eclipse” dichas motas.

Veamos gráficamente en la figura 3-4 el principio de funcionamiento donde A y B señalan la posición de las motas y d la distancia entre las mismas.

Figura 3-4. Esquema de funcionamiento

Cada instante de tiempo ti se determinará considerando las variaciones en la luminosidad recibida.

De esta forma, la velocidad del objeto, suponiendo ésta constante a lo largo de d, vendrá dada por la expresión 3-1:

- Velocidad

- Longitud

- Intensidad de tráfico

- Luminosidad

- Temperatura

- Efecto Hall

Configuración

d

d

d

B A d

B A

B A

B A

En el instante t1, la pieza “eclipsa“ a la mota A.

En el instante t2, la pieza bloquea la mota B. En el ejemplo se ha supuesto, sin que sea un requisito, que la longitud de la pieza es superior a d.

En el instante t3, la mota A ya no se encuentra oculta.

En el instante t4, se desbloquea finalmente la mota B.

Análisis

22

22

(3–1)

La longitud del objeto por la expresión 3-2:

(3–2)

Y la intensidad de tráfico por la expresión 3-3:

(3–3)

Donde n es el número de objetos que han circulado en el periodo ∆T.

O bien, con una interpretación más propia de redes de telecomunicaciones, considerarla como una medida de la ocupación de la cinta mediante la expresión 3-4:

(3–4)

Así, la información relativa a la intensidad de tráfico permitiría, entre otros, detectar tramos saturados en procesos en serie que podrían descongestionarse con otras tareas en paralelo o una mayor celeridad en los procesos posteriores. Igualmente, y de forma adicional, podríamos reportar la temperatura o la luminosidad en cada punto a otros efectos como aviso de temperaturas anormalmente altas o baja luminosidad lo que detectaría posibles errores del sistema.

De otra parte, excediendo las posibilidades actuales de nuestra mota, proponemos para futuros desarrollos otra posible aplicación mediante el uso de etiquetas RFID. Así, añadiendo a cada elemento que circula por las cintas transportadoras una etiqueta RFID con un número de referencia interna a modo de “MAC” y un lector RFID en la mota, ésta podría reportar el circuito seguido que sería de utilidad en caso de distintos tratamientos en función de ciertas características.

3.3. Arquitectura del sistema

La configuración propuesta exige una dedicación a los nodos detectando y reportando los cambios de bruscos luminosidad por lo que resulta adecuado evitar cualquier otra carga para éstos como pudiera ser la de enrutamiento lo que nos lleva a una arquitectura centralizada o una solución intermedia con enrutadores.

Del alcance de la tecnología inalámbrica y el ajustado coste de los nodos se colige que la arquitectura más adecuada es la centralizada de tipo cliente – servidor, pudiendo replicar ésta con otros servidores si se requiere abarcar distancias mayores.

En el servidor se almacenarán los datos para su posterior análisis o se compartirán en red a equipos en

12 tt

dV

−=

( )( )

12

1313

tt

ttdttVL

−

−⋅=−⋅=

T

nI

∆=

T

tt

I

n

i

ii

∆

−

=

∑=1

14


ubicaciones remotas. Así, gráficamente tendríamos

Figura

3.4. Flujo de información

Considerando que disponemos de dos motas para implementar la aplicación y que se requieren de dos motas para cada medida, a la mota G le incorporaremos, sin pérdida de generalidad, las funciones de una mota N. Nótese que, en última instancia, esto sólo supone un incremento de la carga de dicha mota.

Así, el esquema de comunicaciones de la aplicación de demostración y, por tanto, el flujo de información que lleva implícito, viene dado por la figura 3

Figura

SI-WSN

PC

23

stema de información de tráfico en cintas transportadoras mediante WSN

ubicaciones remotas. Así, gráficamente tendríamos la figura 3-5:

Figura 3-5. Arquitectura Cliente – Servidor

Flujo de información

Considerando que disponemos de dos motas para implementar la aplicación y que se requieren de dos motas para cada medida, a la mota G le incorporaremos, sin pérdida de generalidad, las funciones de una mota N.

ue, en última instancia, esto sólo supone un incremento de la carga de dicha mota.

Así, el esquema de comunicaciones de la aplicación de demostración y, por tanto, el flujo de información que la figura 3-6:

Figura 3-6. Esquema de comunicación del sistema

N

G

N

N N

N

N N

MOTA A ≡ G+N

23

Considerando que disponemos de dos motas para implementar la aplicación y que se requieren de dos motas para cada medida, a la mota G le incorporaremos, sin pérdida de generalidad, las funciones de una mota N.

ue, en última instancia, esto sólo supone un incremento de la carga de dicha mota.

Así, el esquema de comunicaciones de la aplicación de demostración y, por tanto, el flujo de información que

N N

N N

MOTA B ≡ N

Análisis

24

24

En cada dispositivo correrá una aplicación cuyas funciones representamos de forma sintetizada en el diagrama de bloques mostrado en la figura 3-7:

Figura 3-7. Diagrama de bloques del sistema

Donde los datos circularán conforme al flujo Aplicación PC � Aplicación Mota A � Aplicación Mota B, y las posibles órdenes de control, de ser necesarias, en sentido contrario.

A continuación ampliamos y justificamos cada función:

Aplicación Mota B

- Detecta cambios bruscos en el sensor de luminosidad registrando si se encuentra “libre” u “oculto”.

- Recoge, periódicamente, el valor de la temperatura y tensión de baterías.

- Envía dichos datos a la MOTA A.

Aplicación Mota A

- Recibe datos de la MOTA B asignándole la referencia temporal.

- Detecta cambios bruscos en el sensor de luminosidad registrando si se encuentra “libre” u “oculto” así como el instante de tiempo en que sucede.

- Recoge el valor de luminosidad comparándola con patrones para detectar la falta de visibilidad y generar la correspondiente alarma.

- Envía dichos datos al PC.

Aplicación PC

- Recibe datos de la MOTA A señalizados con su procedencia (MOTA A o B) y los almacena.

- Realiza el cálculo de las magnitudes previstas: velocidad, longitud e intensidad de tráfico a la que es posible añadir sentido del tráfico mediante la comparación de tiempos.

- Informa y alerta, en función de los umbrales establecidos, sobre la temperatura, tensión de baterías y luminosidad.

- Presenta los resultados mediante una interfaz al efecto.

Obsérvese que en la distribución de tareas hemos procurado minimizar la carga de las aplicaciones que se ejecutan en las motas en detrimento de la aplicación del PC, limitando así el consumo de éstas.

Aplicación PC

- Recepción datos MOTA A

- Cálculo de magnitudes

- Presentación de resultados

- Recepción datos MOTA B

- Envío datos PC

- Detección de tiempos

- Generación de alarmas por baja luminosidad

Aplicación MOTA A Aplicación MOTA B

- Detección de tiempos

- Generación de alarmas por baja luminosidad

- Envío datos MOTA A

25

4 DISEÑO

n este capítulo abordaremos la descripción de la tecnología utilizada, tanto el hardware como el software, haciendo especial hincapié en la arquitectura del sistema operativo. Igualmente trataremos la metodología de desarrollo, diagramas de componentes y casos de uso así como la descripción de la

interfaz de usuario.

4.1. Tecnología utilizada

4.1.1 Hardware

Para el desarrollo de la presente aplicación se ha hecho uso de:

- 1 Equipo portátil Acer Aspire 1810TZ

- 2 motas COU_1_2 [25]

Por rigurosidad se informa del modelo del equipo informático. Si bien, no se exigen especiales características al mismo más que conectividad USB.

Sí nos centraremos en las motas COU_1_2 cuyo detalle se muestra en la figura 4-1.

E

Lo que no se mejora, se degrada siempre.

- Lord Kelvin -

Diseño

26

26

Figura 4-1. Detalle mota COU_1_2

La mota está basada en el microcontrolador ATmega1281 de 8 bits con 128 KB de memoria Flash, 4 KB de memoria EEPROM y 8 KB de memoria RAM cuyos mayores detalles así como de los sensores de luminosidad, temperatura y efecto Hall relacionados son accesibles en las respectivas referencias a los correspondientes datasheets.

- Microcontrolador ATmega1281 [26].

- Sensor de luminosidad [27].

- Sensor de temperatura [28].

- Sensor de efecto Hall [29].

4.1.2 Software

En la tabla 4-1 mostramos la relación de software utilizado:

Sensor de temperatura

Sensor de luminosidad

Chip MAC

Botón de usuario

Botón de reset

UART a USB µControlador + Radio

Sensor de efecto Hall

27


Mota PC

Sistema operativo TinyOS programado en NesC Linux Ubuntu 11.04

Entorno de programación Eclipse Eclipse

Librerías TinyOS para NesC TinyOS para Java

Lenguaje de programación NesC Java

Otros

Aplicación meshprog para transferir los desarrollos a la mota

Microsoft Excel 2007

Tabla 4–1. Software utilizado

En el próximo apartado ahondaremos, por su singularidad, en el sistema operativa TinyOS y en su arquitectura.

4.1.2.1 Arquitectura TinyOS

La arquitectura TinyOS [30] surge, conforme se simboliza en la figura 4-2, de la necesidad de adaptar la arquitectura de sistemas operativos tradicionales a los limitados recursos de los dispositivos donde se ejecuta TinyOS.

Figura 4-2. Origen de la arquitectura TinyOS

Se trata, por tanto, de una arquitectura aligerada de aquellos elementos prescindibles. Así:

- No existe un núcleo del sistema operativo que administre el hardware, en su lugar se realiza una manipulación directa del mismo.

- No se lleva a cabo la administración de procesos ya que, en cada momento, sólo habrá un proceso en ejecución.

- No se trabaja con memoria virtual, sino con un único espacio lineal de direcciones físicas.

- No existe asignación dinámica de memoria ya que dicha asignación se realiza en tiempo de compilación.

Recursos limitados: - Memoria ajustada - Mínimo consumo energético

Arquitectura TinyOS Arquitectura

sistemas operativos

tradicionales

Diseño

28

28

- No se generan señales vía software o excepciones, trabajándose en su lugar con llamadas a funciones.

Con todo ello conseguimos el objetivo de minimizar el tamaño de la memoria y la sobrecarga del sistema, lo que nos lleva, a su vez, al esquema habitual de la arquitectura TinyOS mostrado en la figura 4-3.

Figura 4-3. Arquitectura TinyOS simplificada

En él hemos utilizado las denominaciones inglesas para evitar traducciones inexactas y poco adecuadas.

Del mismo modo, se incluye explícitamente a modo de referencia dónde se ubicaría el hardware de la mota, cuya cercanía con las aplicaciones de usuario puede sugerir una fuerte dependencia que, sin embargo, TinyOS consigue evitar.

De hecho, TinyOS se caracteriza, además de por la ya referida limitación de recursos y del consumo energético, por facilitar un entorno cuasi-transparente del hardware sobre el que se ejecuta.

De esta forma, TinyOS permite dos niveles de planificación:

- Eventos

o Actúan de forma similar a las interrupciones, teniendo prioridad sobre las tareas, lo que les permite cierta garantía en términos de tiempos de ejecución.

o Se utilizan en procesos pequeños tales como transiciones de estados.

o Pueden anticiparse a otros eventos.

o Son independientes de la planificación FIFO aplicada a las tareas.

- Tareas

o Menos prioritarias que los eventos por lo que su uso no está recomendado para procesos con fuertes requerimientos temporales.

o Orientadas a una mayor carga de procesamiento.

o No pueden anticiparse a otras tareas, lo que las dota de un carácter atómico respecto de las mismas.

o Su gestión se realiza en una pila FIFO con un número limitado de tareas pendientes. Cuando

Mote Hardware

Actuating

Sensing Communication

Active Message

Application (User Components)

Main (includes Scheduler)

29


ésta está vacía, el planificador limita la actividad de la CPU al reloj, minimizando así el consumo.

El uso adecuado de ambos niveles permite alcanzar un alto rendimiento en aplicaciones con concurrencia intensiva.

Otro de los elementos fundamentales que configuran TinyOS es su programación en NesC, un dialecto del C que agrupa el código en componentes que se comunican a través de interfaces. De ahí que se utilicen términos como arquitectura basada en componentes o modelo de programación orientado a componentes.

A su vez, estos componentes pueden ser:

- Módulos (nombreC.nc) que implementan interfaces con funciones: comandos y eventos.

o Los comandos son especificados a alto nivel e implementados a bajo nivel. Realizan peticiones que no bloquean al componente de nivel inferior.

o Los eventos, comparables a funciones callback, son especificados a bajo nivel e implementados a alto nivel.

- Configuraciones (nombreAppC.nc) que conectan interfaces entre sí (denominado wiring y representado mediante fechas que unen quienes utilizan la interfaz con quienes las proveen).

Lo indicado queda sintetizado en la figura 4-4.

Figura 4-4. Modelo de componente TinyOS y su interacción

Véase igualmente las figuras 4-7 y 4-8 como ejemplo de wiring referido a nuestra aplicación.

Por último, con el objeto de tener una visión global de la arquitectura, incluimos el gráfico de componentes de una aplicación genérica en la figura 4-5.

Tareas internas Estado interno

Componente

Comandos Eventos

Diseño

30

30

Figura 4-5. Gráfico de componentes de una aplicación genérica

4.2. Diagrama de componentes

En los siguientes apartados abordaremos el diagrama UML de componentes de la aplicación que se ejecuta en el PC y el de componentes TinyOS y sus relaciones.

4.2.1 Diagrama UML de componentes de la aplicación PC

La aplicación que se ejecuta en el PC es una modificación de la clase PrintfClient a la que hemos denominado PrintfSitWsn. Es por ello que su diagrama UML se limita al representado en la figura 4-6.

Figura 4-6. Diagrama UML de la aplicación PC

Ad hoc Routing Application Application

Active Messages

Radio packet

Radio byte

Message

Packet

Byte

Bit

Serial packet

Photo Temp SW

RFM

UART

ADC I2C Clocks HW


Aunque por su simplicidad no es necesario, hemogenerar diagramas UML a partir de su código.

4.2.2 Diagrama de componentes TinyOS

A continuación mostramos, en la figura 4ejecuta en la Mota A que, conforme a la nomenclatura utilizada, corresponde a la que se encuentra conectada al PC mediante USB.

Figura 4-7. Diagrama de componentes TinyOS de la aplicación MotaAApp

Hemos obtenido dicho diagrama, así como la documentación asociada al mismo, mediante el comando:

Del mismo modo, generamos el diagrama de componentes TinyOS de la aplicacB y que mostramos en la figura 4-8.

Figura 4-8. Diagrama de componentes TinyOS de la aplicación MotaBApp

4.3. Casos de uso de la aplicación

SIT-WSN es un Sistema de Información cuyos datos se almacenan para su posterior análisis por otras aplicaciones o módulos. Así, los dos únicos actotransportadoras y que generan los distintos eventos y el consultor o persona que accede a los mismos.

La información relativa a la temperatura y tensiones de batería se recoge de forma paraleque intervenga ningún actor.

La figura 4-9 muestra los casos de uso de señalados.

make cou24 docs

31


Aunque por su simplicidad no es necesario, hemos hecho uso del plugin de Eclipse eUML2 que permite generar diagramas UML a partir de su código.

Diagrama de componentes TinyOS

, en la figura 4-7, el diagrama de componentes TinyOS de la aplicación que se conforme a la nomenclatura utilizada, corresponde a la que se encuentra conectada

Diagrama de componentes TinyOS de la aplicación MotaAApp

, así como la documentación asociada al mismo, mediante el comando:

Del mismo modo, generamos el diagrama de componentes TinyOS de la aplicación que se ejecuta en la Mota 8.

Diagrama de componentes TinyOS de la aplicación MotaBApp

Casos de uso de la aplicación

WSN es un Sistema de Información cuyos datos se almacenan para su posterior análisis por otras aplicaciones o módulos. Así, los dos únicos actores que intervienen son los objetos que circulan por las cintas transportadoras y que generan los distintos eventos y el consultor o persona que accede a los mismos.

La información relativa a la temperatura y tensiones de batería se recoge de forma parale

9 muestra los casos de uso de señalados.

31

s hecho uso del plugin de Eclipse eUML2 que permite

el diagrama de componentes TinyOS de la aplicación que se conforme a la nomenclatura utilizada, corresponde a la que se encuentra conectada

Diagrama de componentes TinyOS de la aplicación MotaAApp

, así como la documentación asociada al mismo, mediante el comando:

ión que se ejecuta en la Mota

Diagrama de componentes TinyOS de la aplicación MotaBApp

WSN es un Sistema de Información cuyos datos se almacenan para su posterior análisis por otras res que intervienen son los objetos que circulan por las cintas

transportadoras y que generan los distintos eventos y el consultor o persona que accede a los mismos.

La información relativa a la temperatura y tensiones de batería se recoge de forma paralela y automática sin

Diseño

32

32

Figura 4-9. Casos de uso de SIT-WSN

En las siguientes tablas 4-2 y 4-3 se especifican ambos casos de uso donde, conforme señalan la pre / post condición, son independientes ya que el sistema genera los datos con independencia de que se soliciten o no informes al respecto.

Del mismo modo, el consultor puede demandar un informe que contendrá los datos almacenados hasta el momento. Si no existen datos, el informe estará en blanco.

Nombre 01 - Solicita informe

Descripción El Consultor solicita informe sobre velocidades, longitudes, tráfico, temperatura, tensión de baterías y luminosidad.

Actores Consultor.

Precondición Ninguna.

Secuencia principal 01 El Consultor demanda el informe.

02 El sistema ofrece el informe registrados hasta el momento.

Errores alternativas No.

Postcondición Ninguna.

Notas No.

Tabla 4–2. Especificación del caso de uso “Solicita informe”

1.1.1.1.1

Genera datos

en su paso sobre las motas

Solicita informe de velocidades,

longitudes, tráfico, temperatura...

33


Nombre 02 - Genera datos

Descripción El objeto genera datos en su paso sobre las motas.

Actores Objeto.

Precondición Ninguna.

Secuencia principal

01 El Objeto cubre la primera* mota.

02 El sistema registra este hecho así como el instante en que sucede

03 El Objeto cubre la segunda* mota.


05 El Objeto deja al descubierto la primera* mota.


07 El Objeto deja al descubierto la segunda* mota.


* Entiéndase primera y segunda mota conforme al sentido del movimiento.

Errores alternativas

03 ↔ 05 Al no exigirse una longitud mínima del objeto, el sistema registra de forma transparente las situaciones en las que se intercambian temporalmente los pasos 03 y 05.

No

(03 y 07)

Si como consecuencia de un cambio de cinta justo en el momento en que atraviesa las motas, no se cubre y descubre la segunda de ellas:

• Si el siguiente objeto circula en el mismo sentido, el sistema actualizará los registros 02 y 06 conforme a la nueva transición.

• Si el siguiente objeto circula en sentido contrario, al cubrir en primera instancia la segunda mota (desde el punto de vista del caso anterior), el sistema no puede diferenciar este hecho de una circulación “normal” del objeto anterior. Si bien, la disparidad de velocidades y longitudes denotará este hecho.

Postcondición Ninguna.

Notas No.

Tabla 4–3. Especificación del caso de uso “Genera datos”

Diseño

34

34

4.4. Criterios de diseño

A diferencia de otros proyectos del ámbito agrícola donde las magnitudes temperatura y luminosidad varían lentamente, la funcionalidad propuesta confiere al factor tiempo un carácter determinante obligando a que el sistema realice un muestreo constante que condiciona el diseño del mismo.

Así, la velocidad máxima de los objetos determina la frecuencia mínima de muestreo de la variable controlada para evitar que éstos puedan pasar “inadvertidos”.

Además, cuanto mayor es dicha frecuencia, mayor es el consumo energético, cuyo ajuste es, igualmente, uno de los objetivos fundamentales en el diseño de cualquier sistema empotrado.

Nos encontramos, por tanto, ante la necesidad de una solución de compromiso que impondrá limitaciones en la funcionalidad perseguida implementada mediante la tecnología descrita.

Así, las motas se erigen como meras sondas remotas que únicamente colectan y reportan datos a la aplicación que se ejecuta en el PC que, a su vez, los almacena para su posterior tratamiento e interpretación por los clientes, descargando así al sistema de actividades que podrían suponer una merma en el rendimiento y, con éste, de la funcionalidad.

Todo ello determina el sentido del flujo de datos descrito en la figura 3-7: Aplicación PC � Aplicación Mota A � Aplicación Mota B, eliminando cualquier posible orden de control en sentido contrario cuya atención limite, aún más, la frecuencia de muestreo.

De esta forma, el diseño se atiene al previsto en el planteamiento inicial.

De otra parte, el valor de luminosidad se encuentra en el rango [0, 1023] que, aún con luz constante en un entorno controlado, presenta una variación de unas 100 unidades en torno al punto de equilibrio.

Las pruebas realizadas con objetos móviles conforme a la figura 5, nos muestran un decremento mínimo del valor de luminosidad de 325 unidades cuando éstos se encuentran sobre la mota, retornando aproximadamente al valor inicial tras dejar la mota descubierta.

Así, hemos definido un umbral que, a modo de histéresis, evitará falsos positivos. Cuando dicho umbral es superado, entendemos que el objeto ha entrado o abandonado la zona de control, procediéndose a reportar la información al efecto.

La información llega a la aplicación PC en una cadena con formato CSV cuyo significado exponemos sobre la siguiente captura real mostrada en la tabla 4-4:

35


Id mota Tipo Número de

periodos

Valor

magnitud

2 1 10435 0

2 1 10484 1

1 1 10518 0

1 1 10541 1

1 1 13737 0

1 1 13769 1

2 1 13776 0

2 1 13796 1

2 1 16885 1

1 1 19788 0

Tabla 4–4. Ejemplo de datos reportados a la aplicación PC

De esta forma:

- El campo “Id mota” puede ser 1 (mota A) ò 2 (mota B).

- El valor del campo “Número de periodos” / 1024 [s] establece la referencia temporal necesaria para los cálculos.

Los campos “Tipo” y “Valor” presentan los siguientes posibles valores representados en la tabla 4-5.

Tipo Valor

1: Variaciones de luminosidad 0: El objeto se encuentra sobre la mota

1: El objeto ha abandonado la mota

2: Tensión de batería [0, 1023] que determina la tensión de batería

3: Temperatura [0, 1023] que determina la temperatura

4: Indicador de baja luminosidad 0: No aporta mayor significado

99: Error en la lectura de sensores / comunicaciones 0: No aporta mayor significado

Tabla 4–5. Significado de los campos “Tipo” y “Valor”

Diseño

36

36

Además, el diseño permitirá atender los casos de uso previstos por cuanto:

- Detecta y reporta a la aplicación PC variaciones superiores a un determinado umbral del valor de luminosidad muestreado cada TIEMPO_MUESTREO / 1024 segundos tanto en la mota A como B.

- Reporta periódicamente a la aplicación PC los valores de tensión de baterías y temperatura en el rango [0, 1023].

- Reporta alertas por baja luminosidad generadas cuando ésta desciende por debajo del UMBRAL_BAJA_LUMINOSIDAD en el TIEMPO_DETECCION_BAJA_LUMINOSIDAD.

- Almacena en un documento .csv dicha información para su posterior procesamiento y presentación.

- Ofrece al usuario una herramienta simple con la obtener y visualizar los resultados obtenidos.

Los objetivos del proyecto establecidos en el apartado 1.2 se centran en el ámbito de la programación en nesC sobre TinyOS de las motas COU_1_2, por lo que la aplicación PC se limita a almacenar los datos recibidos en un archivo con formato CSV (Comma Separated Values) que es un estándar de facto para el intercambio de datos cuya adquisición y tratamiento puede llevarse a cabo tanto desde aplicaciones ofimáticas como por cualquier otra herramienta desarrollada al efecto.

Así, atendiendo igualmente al objetivo de integración de sistemas, dejando en evidencia la facilidad para trabajar con este tipo de formatos y considerando la práctica empresarial habitual de utilizar hojas de cálculo para la manipulación de datos en formato tabla, haremos uso de la herramienta Microsoft Excel para, mediante su tratamiento automatizado, mostrar el análisis de los datos adquiridos mediante las motas que pueden encontrarse a kilómetros de distancia.

En este sentido, se facilita el archivo “SitWsn.xlsm” que requiere de Microsoft Excel 2007 donde se ha programado mediante VBA la interfaz para la adquisición y tratamiento de los datos contenidos en “reporte.csv”. Para su uso es necesario, por tanto, habilitar macros.

Finalmente, hemos de aclarar que el uso de los leds en ambas motas corresponde a la representación de los tres bits menos significativos de un contador que se incrementa con cada transición (entrada o salida) de objetos.

Se trata, lógicamente, de una utilidad de testeo que, con objeto de minimizar el consumo, podría excluirse en la aplicación definitiva.

4.4.1 Adaptación del diseño: Base de tiempos

En este punto queremos enfatizar cómo hemos adaptado nuestra aplicación a la arquitectura TinyOS que lógicamente ha condicionado el diseño de la misma.

Las funcionalidades propuestas exigen fuertes restricciones temporales así como el mayor sincronismo posible por lo que, conforme se ha detallado en el apartado anterior, han sido implementadas mediante eventos.

De otra parte, la comparación de valores temporales adquiridos desde múltiples sistemas requiere garantizar que éstos utilizan la misma base de tiempos – el mismo reloj – o, al menos, que existe una sincronización previa que simula fehacientemente la unicidad de referencias.

37


La resolución de esta necesidad, esencial para la aplicación propuesta, ha obligado a adoptar distintos enfoques que han ido evolucionando en función de las incidencias detectadas alrededor de dos cuestiones fundamentales que detallamos en los siguientes apartados.

4.4.1.1 Reloj del sistema

Nuestras aplicaciones disponen de un temporizador base (componente TimerMilliC) cuyo periodo permite muestrear los valores de los distintos sensores.

Así, en primer lugar, con el objetivo de minimizar el número de temporizadores necesarios para optimizar el rendimiento del sistema, creamos una variable contador que se incrementaba con cada disparo del mismo.

No obstante, las distintas simulaciones pusieron de manifiesto que la evolución de dicho contador no era lineal con el tiempo sino que dependía fuertemente de la carga del sistema proporcional al tráfico de objetos.

De este modo, pasamos a implementar el reloj local mediante el componente LocalTimeMilliC cuyo comportamiento sí se ajustaba al previsto.

4.4.1.2 Sincronización de relojes

Para sincronizar los relojes locales de ambas motas, creamos inicialmente el siguiente protocolo que muestra la tabla 4-6:

Mota Acción

A Arranca

B Arranca

B Obtiene RelojLocal(B)

B Envía RelojLocal(B) a Mota A

A Recibe RelojLocal(B)

A Calcula diferencia := RelojLocal(A) - RelojLocal(B)

...

B Envía ValorSensor, RelojLocal(B) a Mota A

A Recibe ValorSensor, RelojLocal(B)

A Asigna ValorSensor, RelojLocal(B) + diferencia

Tabla 4–6. Algoritmo de sincronización previsto inicialmente

Diseño

38

38

Así, la mota A recibía, a modo de timeStamp, el reloj de la mota B cuya diferencia con el suyo propio repercutía para el resto de medidas.

Sin embargo, volvemos a comprobar que dicha diferencia no permanece constante haciendo que determinados sucesos parezcan adelantarse al momento en que realmente ocurren. De hecho, conforme al comando get de la interface LocalTime, el temporizador puede llegar a detenerse cuando el procesador entra en modo de bajo consumo.

De otra parte, la opción de realizar una sincronización previa a cada dato enviado resulta subóptimo debido a las exigencias del sistema en términos energéticos y de tiempos de respuesta.

4.4.1.3 Solución implementada

Ante las dificultades para ajustar la funcionalidad prevista a las limitaciones del sistema, decidimos realizar la siguiente prueba:

- Creamos un único reloj local en la mota A que asignará referencias temporales a sus medidas y a las que recibe de la mota B.

- Situamos muy próximos los sensores de luminosidad de ambas motas y, sobre éstos, una lámpara que encendemos y apagamos alternativamente de forma que las medidas puedan entenderse simultáneas.

- El análisis estadístico de una muestra elevada de las diferencias temporales entre la mota A y B, nos permite aproximar la distribución de dicha variable aleatoria mediante una normal de media 18 y desviación típica 10 (donde un valor de 1024 corresponde a 1 segundo).

Los resultados de las pruebas realizadas mediante esta solución no sólo son coherentes conforme a lo esperado, sino que, además, acotan y minimizan el error a centésimas de segundo que, hasta el momento, se situaba en el orden de varias décimas de segundo, lo que resultaba incompatible con la funcionalidad deseada.

Obsérvese que, de forma añadida, eliminamos el reloj local de la mota B, minimizando los recursos necesarios de ésta que revertimos en la captación de los valores periódicos de la tensión de baterías y temperatura, requeridos para los otros casos de uso.

4.5. Descripción de la interfaz de usuario

En la figura 5-2 se muestra la interfaz de usuario de la aplicación PC. Se trata de una interfaz adaptada a la demostración del presente proyecto realizado con 2 motas. En la aplicación real, el conocimiento se encuentra implícito en los múltiples registros del reporte CSV que, en función del número de registros, podría integrarse en una base de datos para su mejor gestión, y en las ubicaciones de las distintas motas dadas por el consultor dentro de la cadena de cintas transportadoras, siendo susceptible de desarrollar un módulo específico de análisis para detectar circunstancias susceptibles de optimizar.

Así, en un primer resumen se muestra el número de objetos que han transitado la cinta durante el tiempo de evaluación, el propio tiempo de evaluación y la intensidad de tráfico calculada conforme a la expresión 3-3.

39


También se informa sobre la última temperatura reportada, la tensión de baterías y la indicación sobre si la luminosidad es adecuada o no para poder llevar a cabo la aplicación. Se continúa con los registros de cada objeto identificado éstos por su orden y mostrando su longitud, sentido y velocidad.

Diseño

40

40

41

5 RESULTADOS

n el presente capítulo se desarrollan distintos ejemplos observando las entradas y resultados obtenidos a la vez que se evalúa el sistema verificando el cumplimiento de los objetivos marcados el capítulo de Introducción.

5.1. Producto obtenido

Con el objeto de realizar pruebas de validación, situamos los sensores de luminosidad de la pareja de motas a la distancia conocida de 10 cm, exigiendo los requisitos señalados en el apartado 1.3. En la figura 5-1 mostramos el detalle de la ubicación de las motas.

Figura 5-1. Detalle de ubicación de motas

E

Todo lo que somos es el resultado de lo que hemos

pensado; está fundado en nuestros pensamientos y está

hecho de nuestros pensamientos.

- Buda -

Resultados

42

42

Se utilizan dos objetos de longitudes conocidas (0,065 m y 0,12 m). Con el primero de ellos se realizan 6 transiciones a distintas velocidades y sentidos. Con el segundo otras 11 transiciones. En la figura 5-2 se presentan los resultados generados:

Figura 5-2. Informe SitWsn de la prueba realizada

El número de objetos y sentidos coinciden plenamente con la prueba realizada.

En cuanto a las longitudes, para el primer objeto se obtienen 6 medidas de longitud siendo la inferior 0,050 m y la superior 0,080 m, ambas distanciadas 0,015 m sobre la longitud real del objeto, de 0,065 m, lo que supone un error del 23,08%. Si bien, la media de las distintas medidas coinciden con la citada longitud del objeto.

Para el segundo objeto se obtienen 11 medidas siendo la inferior 0,11 m y la superior 0,15 m, igualmente ambas distanciadas 0,02 m respecto de su longitud real de 0,13 m generando un error del 18,18%. El promedio es de 0,1282 m situándose próximo a los 0,13 m del objeto.

Las diferencias respecto de los valores de longitudes obtenidas se deben a los errores de precisión derivados de la variación del valor de luminosidad, de la diferencia de sincronismo entre motas y de la frecuencia de muestreo, siendo esta última la de mayor peso por cuanto las pruebas posteriores arrojadas con objetos de 0,50 m generan errores decrecientes en el rango del 4%.

De otra parte, en relación a las velocidades calculadas, aunque no se disponen de datos exactos de las reales, pruebas realizadas con objetos con velocidades conocidas han generado errores similares a los informados para las longitudes, siendo coherente con la propagación de errores de las expresiones 3-1 y 3-2.

43


5.2. Cumplimiento de objetivos

A continuación verificaremos el grado de cumplimiento de los objetivos planteados en el apartado 1.1.2. que venían dados por:

a) Permitir una rápida instalación y desinstalación.

b) Alcanzar cualquier punto de la planta industrial.

El cumplimiento de ambos objetivos es inherente a la propia tecnología, por su carácter inalámbrico y el reducido peso de las motas que requiere mínimos elementos de anclaje. No obstante, si las dimensiones de la planta industrial exceden el alcance ZigBee, se replicaría la arquitectura cliente – servidor conforme ya se indicó.

c) Realizar las mínimas exigencias al sistema previo, garantizando así la máxima generalidad.

Se ha exigido que:

o Exista una iluminancia mínima de 200 lux que debiera estar asegurada al ser inferior al mínimo de 300 lux exigidos por el Instituto Nacional de Seguridad e Higiene en el Trabajo en áreas industriales conforme a [31].

o La disposición entre cada pieza u objeto permita una distancia mínima sin sombra de 0,03 m. De hecho, habitualmente es mayor para permitir la operatividad de los elementos mecanizados o automatizados de la cadena industrial. Así, suponiendo una distribución homogénea de los puntos de luz que garantice el requisito anterior, garantiza el cumplimiento con independencia de la altura de la pieza.

o La velocidad del objeto entre las motas sea constante. Lo que puede estar asegurado por la simple elección de ubicaciones y la mínima distancia entre motas.

Se trata, por tanto, de requisitos mínimos que, en esencia, no implican restricciones severas que supongan pérdida de generalidad o aplicabilidad.

d) Reportar la velocidad y flujo de paquetes así como la longitud de éstos.

Queda evidenciada conforme al apartado anterior con las consideraciones realizadas.

e) Tener un coste inferior al 10% respecto de la opción de ampliar el número de sensores propios del sistema de automatización, en caso de que ésta sea posible.

Considerando el ajustado coste de cada mota, de 42,95 EUR, así como la posibilidad de reutilización en múltiples auditorías por cuanto son independientes de la red industrial previa y, especialmente, la diferencia del coste de mano de obra por la facilidad de instalación de las motas teniendo en cuenta su reducido tamaño y peso, resulta evidente que el coste total se reducirá de forma ostensible.

Resultados

44

44

No obstante, la proporción concreta depende de las características de la planta donde se desarrolla el proceso en sí (ubicación, dimensiones, distribución…), la red industrial preexistente, y la posibilidad o no de añadir sensores a dicha red (suponiendo que ésta alcanza cada punto deseado).

45

6 CONCLUSIONES

n este último capítulo se realiza una descripción del desarrollo del proyecto señalando las distintas dificultades encontradas a lo largo del mismo; continuándose con las conclusiones a modo de impresiones generales y se cierra con las posibles líneas de desarrollo que se han suscitado.

6.1. Desarrollo del proyecto

El presente proyecto se ha enfocado con el objetivo de valorar un nuevo nicho de mercado para un sistema microcontrolador que, por sus características concretas, ha tenido un desarrollo limitado en el ámbito de la agricultura y que, sin caer en la obsolescencia, apenas se le estima un recorrido útil.

La duración del desarrollo técnico en sí no ha diferido respecto de proyectos similares. No obstante, la prospección del mercado y la aplicación concreta sí han dilatado las expectativas temporales por cuanto se han valorado diversos sectores para los que se realizaba una ardua labor de búsqueda y documentación que finalmente no han tenido reflejo en el actual proyecto aunque sí han resultado muy enriquecedores por cuanto el conocimiento generado.

De forma adicional, la elección final ha exigido una visión conjunta del tándem mercado – tecnología para intentar alcanzar una hipotética frontera de posibilidades de la misma.

Ya habiendo seleccionado la aplicación, la primera dificultad ha sido la instalación y configuración del entorno de desarrollo ya que, aunque existe amplia documentación del sistema operativo TinyOS, los componentes concretos de la mota y su programación han exigido de la búsqueda de los drivers adecuados.

El aprendizaje de la tecnología y de su singular programación también ha requerido de pequeños desarrollos a título formativo para testear el uso y adquisición de datos de los distintos sensores, comunicaciones y capacidad de procesamiento del sistema microcontrolador.

E

La vida es el arte de sacar conclusiones suficientes a

partir de datos insuficientes.

- Samuel Butler -

Conclusiones

46

46

Finalmente, el ajuste de la base de tiempos ha sido, del mismo modo, objeto de distintos rediseños al efecto.

6.2. Conclusiones

En primer lugar, del referido estudio de mercados, se colige la potencialidad de la tecnología que, aunque en determinados sectores sí ha tenido una penetración razonable, existe un amplio recorrido que garantiza el avance de la misma.

No obstante, en dicho avance sería de especial utilidad la unificación de conocimientos relativos a la tecnología que se encuentran distribuidos en múltiples manuales, proyectos y documentación técnica en general, mucha de la cual no supone de especial aportación por cuanto es inexacta, está duplicado, incompleta u obsoleta.

Por otra parte, de forma genérica, resulta especialmente estimulante en cualquier proyecto la orientación comercial de la aplicación a desarrollar y el planteamiento de objetivos ambiciosos, permitiendo así detectar y afrontar las dificultades con las que enriquecerse.

En concreto, la aplicación propuesta ha permitido intuir, a modo de frontera de posibilidades de producción, el compromiso existente entre la funcionalidad deseada, en nuestro caso parametrizada por la frecuencia de muestreo de las cintas transportadoras, y las limitaciones técnicas encabezadas por el consumo energético mínimo de este tipo de sistemas.

6.3. Líneas de desarrollo

A continuación se relacionan posibles mejoras o líneas de desarrollo del proyecto que, con el mencionado objetivo comercial, en ocasiones exceden del campo técnico abordado.

Así, con el objeto de optimizar aún más si cabe el rendimiento y posibilidades de nuestra aplicación proponemos las siguientes mejoras:

- Añadir etiquetas RFID a una muestra de la población de objetos que circulan por las cintas transportadoras e incluir en la mota un lector RFID con el objeto de obtener un trazado del camino recorrido detectando tiempos de espera en cola, velocidades de procesos, etc.

- Incluir en la mota un circuito de bajo consumo que, en conjunción con el sensor de luminosidad, implemente el efecto umbral, realizado actualmente mediante código, generando una interrupción, con lo que se conseguiría una menor carga del sistema que revertiría en un consumo más ajustado y una optimización de los tiempos de ejecución que, a su vez, mejoraría la precisión aumentando su rango de uso.

- Opcionalmente, valorar una alternativa a nivel de sensores que permita registrar las magnitudes requeridas sin exigir la duplicidad de motas.

47


- Modificar la aplicación PC para que almacene los registros en una base de datos creada al efecto y que aúne la información de los sistemas de información del proceso industrial, permitiendo la adquisición de conocimiento para la posterior implementación de funcionalidades de valor añadido.

Conclusiones

48

48

49

APÉNDICES

Apéndice A: Manual de usuario

Con el objetivo de realizar un manual sintético que no redunde en los conceptos ya tratados en apartados anteriores, supondremos que el usuario dispone de unos conocimientos básicos acerca de los mismos.

De esta forma, abordaremos cómo compilar y utilizar cada elemento software que compone nuestra aplicación. Éstos se entregan separados en cuatro carpetas: MotaA, MotaB, PC y SitWsn.

Debe tenerse en cuenta al efecto el software y hardware del que se dispone conforme a los apartados 4.1.1 y 4.1.2. Así, tenemos:

Aplicación Mota A:

- Compilación:

o Desde el terminal de gnome, situados en la carpeta MotaA, ejecutamos la instrucción:

o Además de las indicaciones mostradas por pantalla acerca de la correcta consecución de la operación conforme a la figura 7-1, este comando genera una estructura de carpetas, que cuelgan de MotaA, así como un conjunto de archivos cuyos nombres podemos visualizar mediante la instrucción:

o Si la compilación se ha realizado satisfactoriamente, debemos obtener el siguiente listado:

o En la figura 7-1, incluimos el detalle de las instrucciones (destacadas en color azul) y feedback recibido para compilar y cargar la aplicación en la Mota A cuyo descriptor, de acuerdo al comando “motelist”, es “/dev/ttyUSB0”. (/dev/ttyUSB1 para la Mota B).

make cou24 install,1

ls ./build/cou24

app.c main.exe main.ihex main.srec.out-1 wiring-check.xml

ident_flags.txt main.exe.out-1 main.srec tos_image.xml

Apéndices

50

50

Figura 7-1.Compilación y carga de la aplicación en la mota A

Setting up for TinyOS 2.1.1

asuarez@AP:~/Escritorio/MotaA$ make cou24 install,1

mkdir -p build/cou24

compiling MotaAAppC to a cou24 binary

ncc -o build/cou24/main.exe -Os -fnesc-separator=__ -Wall -Wshadow -Wnesc-all -target=cou24 -fnesc-cfile=build/cou24/app.c -board= -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=100000 -I/opt/tinyos-2.x/tos/lib/printf -DIDENT_APPNAME=\"MotaAAppC\" -DIDENT_USERNAME=\"asuarez\" -DIDENT_HOSTNAME=\"AP\" -DIDENT_USERHASH=0x71b77448L -DIDENT_TIMESTAMP=0x4fa2c6abL -DIDENT_UIDHASH=0x440e8d5dL -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/cou24/wiring-check.xml MotaAAppC.nc -lm

compiled MotaAAppC to build/cou24/main.exe

18518 bytes in ROM

1002 bytes in RAM

avr-objcopy --output-target=srec build/cou24/main.exe build/cou24/main.srec

avr-objcopy --output-target=ihex build/cou24/main.exe build/cou24/main.ihex

writing TOS image

tos-set-symbols build/cou24/main.srec build/cou24/main.srec.out-1 TOS_NODE_ID=1 ActiveMessageAddressC__addr=1

installing cou24 binary using dapa

avrdude -cdapa -U hfuse:w:0x99:m -pm1281 -U efuse:w:0xff:m -C/etc/avrdude/avrdude.conf -U flash:w:build/cou24/main.srec.out-1:a

avrdude: can't open device "/dev/parport0": No such file or directory

avrdude: failed to open parallel port "/dev/parport0"

make: *** [program] Error 1

asuarez@AP:~/Escritorio/MotaA$ meshprog -t/dev/ttyUSB0 -f./build/cou24/main.srec.out-1

using tty /dev/ttyUSB0

reading from file ./build/cou24/main.srec.out-1

sending ./build/cou24/main.srec.out-1 -> /dev/ttyUSB0

Opened file ./build/cou24/main.srec.out-1

Opened device /dev/ttyUSB0

..............,[i••&]

Starting transmission.

finished!

51


- Carga:

o Conectamos la mota A en uno de los puertos USB de nuestro equipo.

o Para confirmar la referencia asignada al dispositivo debemos ejecutar, desde el terminal de gnome, la instrucción:

o La respuesta de la misma debe ser similar a la siguiente, donde observamos que podemos acceder a la mota A a través de /dev/ttyUSB0.

o Situados nuevamente en la carpeta MotaA, desde el terminal de gnome, procedemos a la carga de la aplicación propiamente en la mota A. Para ello ejecutamos:

o Nótese que debemos utilizar, dentro del primer argumento, la referencia obtenida de la instrucción anterior.

o Inmediatamente a continuación reseteamos la mota presionando el botón de reset que es el situado más próximo al conector USB de la mota, con lo que en el terminal de gnome debemos visualizar:

- Ejecución:

o Una vez cargada, la ejecución de la aplicación es automática, sólo requiriendo que la mota esté conectada a un puerto USB del equipo donde se ejecute la aplicación PC para su alimentación y comunicación de datos.

motelist

Reference Device Description

---------- ---------------- ---------------------------------------------

0001 /dev/ttyUSB0 Silicon Labs CP2102 USB to UART Bridge Controller

meshprog -t/dev/ttyUSB0 -f./build/cou24/main.srec.out-1






..........................,[i••&]


finished!

Apéndices

52

52

Aplicación Mota B:

- Compilación:

o Desde el terminal de gnome, situados en la carpeta MotaB, ejecutamos la instrucción:

o Además de las indicaciones mostradas por pantalla acerca de la correcta consecución de la operación conforme a la figura 7-1, este comando genera una estructura de carpetas, que cuelgan de MotaB, así como un conjunto de archivos cuyos nombres podemos visualizar mediante la instrucción:

o Si la compilación se ha realizado satisfactoriamente, debemos obtener el siguiente listado:

- Carga:

o Aunque no es imprescindible, para mayor uniformidad, no desconectaremos la mota A del equipo. De esta forma, conectamos la mota B en otro puerto USB.

o Para confirmar la referencia asignada al dispositivo debemos ejecutar, desde el terminal de gnome, la instrucción:

o La respuesta de la misma debe ser similar a la siguiente, donde observamos que podemos acceder a la mota B a través de /dev/ttyUSB1 ya que la anterior referencia corresponde a la mota A.

o Situados nuevamente en la carpeta MotaB, desde el terminal de gnome, procedemos a la carga de la aplicación propiamente en la mota B. Para ello ejecutamos:

o Nótese que debemos utilizar, dentro del primer argumento, la referencia obtenida de la

make cou24 install,2

ls ./build/cou24

app.c main.exe main.ihex main.srec.out-2 wiring-check.xml

ident_flags.txt main.exe.out-2 main.srec tos_image.xml

motelist

Reference Device Description

---------- ---------------- ---------------------------------------------



meshprog -t/dev/ttyUSB1 -f./build/cou24/main.srec.out-2

53


instrucción anterior.

o Inmediatamente a continuación reseteamos la mota presionando el botón de reset que es el situado más próximo al conector USB de la mota, con lo que en el terminal de gnome debemos visualizar:

- Ejecución:

o Una vez cargada, la ejecución de la aplicación es automática, sólo requiriendo su alimentación mediante baterías o la conexión a un puerto USB de cualquier equipo encendido.

Aplicación PC:

- Compilación:

o Con el objetivo de facilitar su uso, considerando que la aplicación será utilizada siempre desde un mismo equipo con una configuración conocida, ésta se ha diseñado de forma que no requiera parámetros para su ejecución. A estos efectos se exige que la mota A se encuentre conectada vía USB en /dev/ttyUSB0 y la existencia en el PC de la estructura de carpetas implícita en la variable rutaFichero.

o De esta forma, previo a su compilación, debemos verificar estos extremos y, en su caso, realizar las modificaciones oportunas sobre la variable rutaFichero (línea 17) y source (línea 56) del archivo PrintfSitWsn.java. Estos valores, ajustados al equipo donde y para el que se ha diseñado, son:

o De otra parte, aunque el conjunto de archivos y directorios situados en la carpeta PC se encuentran preparados para su compilación y ejecución en Eclipse, también podemos acceder a la subcarpeta “src” y compilar la misma en modo comando mediante:






..........................,[i��&]


finished!

private static String rutaFichero = "/home/asuarez/Escritorio/Carpeta

compartida/reporte.csv";

String source = "serial@/dev/ttyUSB0:19200";

javac PrintfSitWsn.java

Apéndices

54

54

o A estos efectos, es necesario que la variable de entorno CLASSPATH incluya “tinyos.jar” que se encuentra en la subcarpeta “lib”.

o O, conforme se ha indicado, en modo depuración, se podría compilar y ejecutar el código de la aplicación PC haciendo uso del IDE Eclipse cuyo GUI representamos en la figura 7-2:

Figura 7-2. GUI de IDE de Eclipse

o Si la compilación se ha realizado correctamente, habrá generado un archivo de nombre “PrintfSitWsn.class”

- Ejecución:

o En el mismo entorno tras su compilación, podemos ejecutarla mediante la instrucción:

o En caso correcto, en la pantalla visualizaremos:

o A continuación se recibirán los registros derivados de la circulación de vehículos que, a efectos informativos, se mostrarán por pantalla en el mismo formato que se almacenan en el reseñado archivo reporte.csv

java PrintfSitWsn.class

Thread[Thread-1,5,main]serial@/dev/ttyUSB0:19200: resynchronising

55


Aplicación SitWsn:

- Compilación:

o No requiere compilación ya que consiste en un archivo de Microsoft Excel 2007 que procesará, offline, la información contenida en el archivo reporte.csv generado por la aplicación PC.

- Ejecución:

o Abrimos el archivo SitWsn.xlsm y procedemos a habilitar el uso de macros siguiendo las instrucciones que la misma aplicación provee (véase figura 7-3).

Figura 7-3. Ayuda contextual de SitWsn.xlsm

o Tras ello, la aplicación muestra el siguiente aspecto (véase figura 7-4).

Figura 7-4. Pantalla principal de SitWsn.xlsm

o La descripción de cada campo identifica suficientemente su contenido que, no obstante, aclararemos sobre un informe concreto. Continuamos pulsando en el botón “Actualizar” que abre un cuadro de diálogo mostrado en la figura 7-5 donde seleccionar el archivo reporte.csv

Apéndices

56

56

Figura 7-5. Formulario de selección del reporte.csv

o Tras seleccionarlo y pulsar en aceptar, el sistema lo procesa y nos indica el número de errores detectados como el mostrado en la figura 7-6 entre los que se incluyen las incidencias en comunicaciones y transiciones doblemente señalizadas.

Figura 7-6. Información del número de errores

o El informe que genera un reporte.csv concreto se visualiza en la figura 5-2.

o El informe nos indica el número de objetos que han circulado durante el tiempo transcurrido [segundos] y, a partir de éstos, la intensidad de tráfico [objetos / segundos].

o También nos ofrece la temperatura [ºC], la tensión de baterías [V] y una alarma que nos informa si la luminosidad es adecuada o no.

o Asimismo, se genera una alarma por temperatura extrema si ésta es inferior a 0ºC ò superior a 40 ºC. De otra parte, se genera una alarma por tensión baja de baterías si es inferior a 2,60 V. Estos valores se han fijado de acuerdo a las exigencias del sistema y a la información contenida en los datasheets de cada sensor.

57


o Igualmente, la alarma por baja luminosidad exige que el valor de ésta (considerando su rango ADC [0, 1023]) sea inferior a 550 durante 8 segundos.

o Si seleccionamos la celda donde se indica el valor de la temperatura o la tensión de baterías se nos habilita un menú contextual que nos informa al efecto (véase figura 7-7).

Figura 7-7. Alarmas y menú contextual

Apéndices

58

58

59

REFERENCIAS

[1] P. Ponsa y A. Granollers, «Diseño y automatización industrial,» [En línea]. Available: http://www.epsevg.upc.edu/hcd/material/lecturas/interfaz.pdf.

[2] G. Lorenzo Lledó, «Automatización de una planta industrial,» [En línea]. Available: https://rua.ua.es/dspace/bitstream/10045/10056/1/Suficiencia%20Gonzalo.pdf.

[3] P. R. y. otros, A Model for Types and Levels of Human Interaction with Automation, vol. 30, 2000.

[4] D. C. W., Design and Analysis of Integrated Manufacturing Systems, National Academies, 1988.

[5] S. R. S. .W, B. P. N y E. B. S., An automated handling system for soft compact shaped non-rigidproducts, 1996.

[6] D. Nitzan y C. Rosen, Programmable Industrial Automation, 1976, pp. 1259 - 1270.

[7] P. Mirchandani, E. J. Lee y A. Vasquez, Concurrent Scheduling In Flexible Automation, vol. 2, 1988, pp. 868 - 872.

[8] M. E., Autómatas programables: entorno y aplicaciones, Thomson Learning Ibero, 2005.

[9] F. Gómez-Esterm, «Automatización de sistemas de producción,» [En línea]. Available: ttp://www.esi2.us.es/~fabio/TransASP.pdf.

[10] Universitat de Valencia, «Redes de comunicación industriales,» [En línea]. Available: http://www.uv.es/rosado/courses/sid/Capitulo3_rev0.pdf.

[11] «AS-Interface,» 10 11 2014. [En línea]. Available: https://es.wikipedia.org/wiki/AS-interface.

[12] I. Electronic, «Sistema de bus AS-interface,» [En línea]. Available: https://www.ifm.com/obj/ifm_AS-Interface_Catalogue_ES_08.pdf.

[13] R. Estepa y A. Estepa, «Comunicación Industriales Inalámbricas,» [En línea]. Available: http://trajano.us.es/docencia/RedesLocalesEnLaIndustria/sld/RedesIndustriales6-5.pdf.

[14] «Auditoría de productividad,» [En línea]. Available: http://ipyc.net/organizacion-y-lean/organizacion-industrial/auditoria-de-productividad.html.

[15] D. R. Arter, «Auditorías de calidad para mejorar la productividad,» 2003. [En línea]. Available: http://depa.fquim.unam.mx/amyd/archivero/AUDITORIA_2646.pdf.

[16] «DOEET,» [En línea]. Available: http://doeet.com/what-is-doeet/implementation.

Referencias

60

60

[17] C. S. Regoli Almada, «Diseño de un método de enrutamiento activo para redes inalámbricas de sensores (WSN),» 10 06 2013. [En línea]. Available: http://bibing.us.es/proyectos/abreproy/70429/fichero/Tesis_Master_Carolina_Regoli%252FTrabajoFinalMaster.pdf.

[18] J. M. Hinojo Montero, «Estudio e implementación de técnicas de localización basadas en redes de sensores sobre tecnología Bluetooth,» [En línea]. Available: http://bibing.us.es/proyectos/abreproy/11919/fichero/cap2_estado_arte.pdf.

[19] D. M. Archilla Córdoba y F. A. Santamaría Buitrago, «Estado del arte de las redes de sensores inalámbricos,» 25 09 2013. [En línea]. Available: http://revistas.udistrital.edu.co/ojs/index.php/tia/article/viewFile/4437/6856.

[20] «Wireless Sensor Network,» [En línea]. Available: http://www.mfbarcell.es/conferencias/wsn.pd.

[21] «List of wireless sensor nodes,» 28 3 2016. [En línea]. Available: https://en.wikipedia.org/wiki/List_of_wireless_sensor_nodes.

[22] S. R. N. S. Mridula Maura, «Current Wireless Sensor Nodes (Motes): Performance metrics and Constraints,» [En línea]. Available: http://ijarece.org/wp-content/uploads/2013/08/IJARECE-VOL-2-ISSUE-1-45-48.pdf.

[23] Memsic, «MIB600 Ethernet Interface Board,» [En línea]. Available: http://www.memsic.com/userfiles/files/Datasheets/WSN/6020-0055-05_a_mib600-t.pdf.

[24] M. O. Farooq y T. Kunz, «Operating Systems for Wireless Sensor Networks: A Survey,» [En línea]. Available: https://www.researchgate.net/publication/51873411_Operating_Systems_for_Wireless_Sensor_Networks_A_Survey.

[25] UOC, «Hardware COU 1 2,» [En línea]. Available: http://cv.uoc.edu/app/mediawiki14/wiki/Hardware_COU_1_2.

[26] «Atmel ATmega640/V-1280/V-1281/V-2560/V-2561/V,» [En línea]. Available: http://www.atmel.com/Images/Atmel-2549-8-bit-AVR-Microcontroller-ATmega640-1280-1281-2560-2561_datasheet.pdf.

[27] «CdS Photoconductive Photocells PDV-P9003,» [En línea]. Available: http://www.advancedphotonix.com/wp-content/uploads/PDV-P9003.pdf.

[28] «Low-Power Linear Active Thermistor ICs MCP9700/9700A MCP9701/9701A,» [En línea]. Available: http://ww1.microchip.com/downloads/en/DeviceDoc/21942e.pdf.

[29] «Omnipolar Detection Hall ICs,» [En línea]. Available: http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/hall/bu52001gul-e.pdf.

[30] «TinyOS,» [En línea]. Available: http://tinyos.net/.

[31] INSHT, «Enciclopedia de salud y seguridad en el trabajo,» [En línea]. Available: http://www.insht.es/InshtWeb/Contenidos/Documentacion/TextosOnline/EnciclopediaOIT/tomo2/46.pdf.

Documents

Proyecto Fin de Carrera Ingeniería de …bibing.us.es/proyectos/abreproy/12366/fichero/Sistema+de...Flujo de información 23 4 Diseño 25 4.1. Tecnología utilizada 25 4.1.1 Hardware