Estado Del Arte de Bandas Transportadoras PDF

 

Proyecto Fin de Carrera Ingeniería e Telecomunicación

Sistema de información de trá ico en cintas transportad ras mediante WSN  Autor: Antonio uárez Reyes Tutor: Daniel G tiérrez Reina

Equation hapter 1 Section 1  1 

Dep. Ingeniería Electrónica Esc ela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2016

i  

 

 

 

Proyecto Fin de Carrera Ingeniería de Telecomunicación

Sistema de información de tráfico en cintas transportadoras mediante WSN Autor: Antonio Suárez Reyes

Tutor: Daniel Gutiérrez Reina Profesor Sustituto Interino

Dep. Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2016

iii

 

 

 

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 

v

 

 

 

 A mi mujer, mujer, María, María, y a mis hijos Vera, Roberto y Antonio

vii

 

 

 

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.  Antonio  Anto nio Suárez Suárez Reyes Reyes Sevilla, 2016

ix

 

 

 

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 reorientando persigue poner la versatilidad las motas utilizadas en cintas redes inalámbricas de sensores su de usomanifiesto en procesos industriales de automatizados basados en transportadoras para implementar una auditoría de productividad en dicho entorno.

xi

 

 

 

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.

xiii

 

 

 

Índice

󰁁󰁧󰁲󰁡󰁤󰁥󰁣󰁩󰁭󰁩󰁥󰁮󰁴󰁯󰁳

󰁩󰁸  󰁩󰁸 

󰁒󰁥󰁳󰁵󰁭󰁥󰁮

󰁸󰁩  󰁸󰁩 

󰁁󰁢󰁳󰁴󰁲󰁡󰁣󰁴

󰁸󰁩󰁩󰁩  󰁸󰁩󰁩󰁩 

󰃍󰁮󰁤󰁩󰁣󰁥

󰁸󰁶  󰁸󰁶 

󰃍󰁮󰁤󰁩󰁣󰁥 󰁤󰁥 󰁔󰁡󰁢󰁬󰁡󰁳  󰁔󰁡󰁢󰁬󰁡󰁳 

󰁸󰁶󰁩󰁩  󰁸󰁶󰁩󰁩 

󰃍󰁮󰁤󰁩󰁣󰁥 󰁤󰁥 󰁆󰁩󰁧󰁵󰁲󰁡󰁳  󰁆󰁩󰁧󰁵󰁲󰁡󰁳 

󰁸󰁩󰁸 󰁸󰁩󰁸  

󰀱 

󰁉󰁮󰁴󰁲󰁯󰁤󰁵󰁣󰁣󰁩󰃳󰁮 1.1.  󰁐󰁲󰁥󰁳󰁥󰁮󰁴󰁡󰁣󰁩󰃳󰁮 󰁤󰁥󰁬 󰁰󰁲󰁯󰁢󰁬󰁥󰁭󰁡 1.2.  󰁏󰁢󰁪󰁥󰁴󰁩󰁶󰁯󰁳 󰁤󰁥󰁬 󰁰󰁲󰁯󰁹󰁥󰁣󰁴󰁯 1.2.1. 󰁄󰁥󰁳󰁣󰁲󰁩󰁰󰁣󰁩󰃳󰁮 󰁤󰁥󰁬 󰁰󰁲󰁯󰁢󰁬󰁥󰁭󰁡 1.2.2. 󰁏󰁢󰁪󰁥󰁴󰁩󰁶󰁯󰁳 󰁤󰁥 󰁬󰁡 󰁳󰁯󰁬󰁵󰁣󰁩󰃳󰁮 1.3.  󰁄󰁥󰁳󰁣󰁲󰁩󰁰󰁣󰁩󰃳󰁮 󰁤󰁥 󰁡󰁬󰁴󰁯 󰁮󰁩󰁶󰁥󰁬 󰁤󰁥 󰁬󰁡 󰁳󰁯󰁬󰁵󰁣󰁩󰃳󰁮 1.󰀴.  󰁄󰁥󰁳󰁣󰁲󰁩󰁰󰁣󰁩󰃳󰁮 󰁥󰁳󰁴󰁲󰁵󰁣󰁴󰁵󰁲󰁡󰁤󰁡 󰁤󰁥󰁬 󰁲󰁥󰁳󰁴󰁯 󰁤󰁥 󰁬󰁡 󰁭󰁥󰁭󰁯󰁲󰁩󰁡

󰀱   󰀱 1  2  2 3 3  󰀴 

󰀲 

󰁁󰁮󰁴󰁥󰁣󰁥󰁤󰁥󰁮󰁴󰁥󰁳 2.1.  󰁅󰁳󰁴󰁡󰁤󰁯 󰁤󰁥󰁬 󰁡󰁲󰁴󰁥 󰁤󰁥 󰁡󰁵󰁤󰁩󰁴󰁯󰁲󰃭󰁡󰁳 󰁤󰁥 󰁰󰁲󰁯󰁣󰁥󰁳󰁯󰁳 󰁩󰁮󰁤󰁵󰁳󰁴󰁲󰁩󰁡󰁬󰁥󰁳 󰁡󰁵󰁴󰁯󰁭󰁡󰁴󰁩󰁺󰁡󰁤󰁯󰁳 󰁢󰁡󰁳󰁡󰁤󰁯󰁳 󰁥󰁮 󰁣󰁩󰁮󰁴󰁡󰁳

󰀵  󰀵 

󰁴󰁲󰁡󰁮󰁳󰁰󰁯󰁲󰁴󰁡󰁤󰁯󰁲󰁡󰁳

󰀵 

2.1.1

󰁁󰁵󰁴󰁯󰁭󰁡󰁴󰁩󰁺󰁡󰁣󰁩󰃳󰁮 󰁤󰁥 󰁰󰁲󰁯󰁣󰁥󰁳󰁯󰁳 󰁩󰁮󰁤󰁵󰁳󰁴󰁲󰁩󰁡󰁬󰁥󰁳

5

2.1.2 󰁔󰁩󰁰󰁯󰁳 󰁤󰁥 󰁣󰁩󰁮󰁴󰁡󰁳 󰁴󰁲󰁡󰁮󰁳󰁰󰁯󰁲󰁴󰁡󰁤󰁯󰁲󰁡󰁳 󰁴󰁲󰁡󰁮󰁳󰁰󰁯󰁲󰁴󰁡󰁤󰁯 󰁲󰁡󰁳 2.1.3 󰁒󰁥󰁤󰁥󰁳 󰁩󰁮󰁤󰁵󰁳󰁴󰁲󰁩󰁡󰁬󰁥󰁳 2.1.4 󰁁󰁵󰁤󰁩󰁴󰁯󰁲󰃭󰁡 󰁤󰁥 󰁰󰁲󰁯󰁣󰁥󰁳󰁯󰁳 󰁩󰁮󰁤󰁵󰁳󰁴󰁲󰁩󰁡󰁬󰁥󰁳 2.2.  󰁅󰁳󰁴󰁡󰁤󰁯 󰁤󰁥󰁬 󰁡󰁲󰁴󰁥 󰁤󰁥 󰁲󰁥󰁤󰁥󰁳 󰁗󰁓󰁎 2.2.1 󰁅󰁬󰁥󰁭󰁥󰁮󰁴󰁯󰁳 󰁤󰁥 󰁬󰁡󰁳 󰁗󰁓󰁎 (󰁮󰁯󰁤󰁯󰁳) 2.2.2 󰁁󰁲󰁱󰁵󰁩󰁴󰁥󰁣󰁴󰁵󰁲󰁡󰁳 󰁹 󰁴󰁯󰁰󰁯󰁬󰁯󰁧󰃭󰁡󰁳 󰁤󰁥 󰁲󰁥󰁤

7 11 14 1󰀵  15 17

󰀳 

󰁁󰁮󰃡󰁬󰁩󰁳󰁩󰁳 3.1.  󰁅󰁮󰁦󰁯󰁱󰁵󰁥 󰁤󰁥󰁬 󰁰󰁲󰁯󰁹󰁥󰁣󰁴󰁯 3.2.  󰁃󰁯󰁮󰁤󰁩󰁣󰁩󰁯󰁮󰁡󰁮󰁴󰁥󰁳 󰁹 󰁣󰁲󰁩󰁴󰁥󰁲󰁩󰁯󰁳 󰁡󰁤󰁯󰁰󰁴󰁡󰁤󰁯󰁳 3.3.   󰁁󰁲󰁱  󰁁󰁲󰁱󰁵󰁩󰁴󰁥 󰁵󰁩󰁴󰁥󰁣󰁴󰁵󰁲 󰁣󰁴󰁵󰁲󰁡 󰁡 󰁤󰁥󰁬 󰁤󰁥󰁬 󰁳󰁳󰁩󰁳󰁴󰁥 󰁩󰁳󰁴󰁥󰁭󰁡 󰁭󰁡 3.󰀴.  󰁆󰁬󰁵󰁪󰁯 󰁤󰁥 󰁩󰁮󰁦󰁯󰁲󰁭󰁡󰁣󰁩󰃳󰁮

󰀱󰀹   󰀱󰀹 1󰀹  20  22  23 

󰀴 

󰁄󰁩󰁳󰁥󰃱󰁯 󰀴.1.  󰁔󰁥󰁣󰁮󰁯󰁬󰁯󰁧󰃭󰁡 󰁵󰁴󰁩󰁬󰁩󰁺󰁡󰁤󰁡

󰀲󰀵   󰀲󰀵 2󰀵 

4.1.1 󰁈󰁡󰁲󰁤󰁷󰁡󰁲󰁥 4.1.2 󰁓󰁯󰁦󰁴󰁷󰁡󰁲󰁥 󰀴.2.  󰁄󰁩󰁡󰁧󰁲󰁡󰁭󰁡 󰁤󰁥 󰁣󰁯󰁭󰁰󰁯󰁮󰁥󰁮󰁴󰁥󰁳 4.2.1 󰁄󰁩󰁡󰁧󰁲󰁡󰁭󰁡 󰁕󰁍󰁌 󰁤󰁥 󰁣󰁯󰁭󰁰󰁯󰁮󰁥󰁮󰁴󰁥󰁳 󰁤󰁥 󰁬󰁡 󰁡󰁰󰁬󰁩󰁣󰁡󰁣󰁩󰃳󰁮 󰁐󰁃

25 26 30  30

xv

 

 

󰀵 

󰀶 

4.2.2 󰁄󰁩󰁡󰁧󰁲󰁡󰁭󰁡 󰁤󰁥 󰁣󰁯󰁭󰁰󰁯󰁮󰁥󰁮󰁴󰁥󰁳 󰁔󰁩󰁮󰁹󰁏󰁓 󰀴.3.  󰁃󰁡󰁳󰁯󰁳 󰁤󰁥 󰁵󰁳󰁯 󰁤󰁥 󰁬󰁡 󰁡󰁰󰁬󰁩󰁣󰁡󰁣󰁩󰃳󰁮 󰀴.󰀴.  󰁃󰁲󰁩󰁴󰁥󰁲󰁩󰁯󰁳 󰁤󰁥 󰁤󰁩󰁳󰁥󰃱󰁯 4.4.1 󰁁󰁤󰁡󰁰󰁴󰁡󰁣󰁩󰃳󰁮 󰁤󰁥󰁬 󰁤󰁩󰁳󰁥󰃱󰁯󰀺 󰁂󰁡󰁳󰁥 󰁤󰁥 󰁴󰁩󰁥󰁭󰁰󰁯󰁳 󰀴.󰀵.  󰁄󰁥󰁳󰁣󰁲󰁩󰁰󰁣󰁩󰃳󰁮 󰁤󰁥 󰁬󰁡 󰁩󰁮󰁴󰁥󰁲󰁦󰁡󰁺 󰁤󰁥 󰁵󰁳󰁵󰁡󰁲󰁩󰁯

31 31  3󰀴  36 3󰀸 

󰁒󰁥󰁳󰁵󰁬󰁴󰁡󰁤󰁯󰁳 󰀵.1.  󰁐󰁲󰁯󰁤󰁵󰁣󰁴󰁯 󰁯󰁢󰁴󰁥󰁮󰁩󰁤󰁯 󰀵.2.  󰁃󰁵󰁭󰁰󰁬󰁩󰁭󰁩󰁥󰁮󰁴󰁯 󰁤󰁥 󰁯󰁢󰁪󰁥󰁴󰁩󰁶󰁯󰁳

󰀴󰀱   󰀴󰀱 󰀴1  󰀴3 

󰁃󰁯󰁮󰁣󰁬󰁵󰁳󰁩󰁯󰁮󰁥󰁳

󰀶.1.  󰀶.2.  󰀶.3. 

󰁄󰁥󰁳󰁡󰁲󰁲󰁯󰁬󰁬󰁯 󰁤󰁥󰁬 󰁰󰁲󰁯󰁹󰁥󰁣󰁴󰁯 󰁃󰁯󰁮󰁣󰁬󰁵󰁳󰁩󰁯󰁮󰁥󰁳 󰁌󰃭󰁮󰁥󰁡󰁳 󰁤󰁥 󰁤󰁥󰁳󰁡󰁲󰁲󰁯󰁬󰁬󰁯

󰁁󰁰󰃩󰁮󰁤󰁩󰁣󰁥󰁳  󰁁󰁰󰃩󰁮󰁤󰁩󰁣  󰁁󰁰󰃩 󰁮󰁤󰁩󰁣󰁥 󰁥󰁁 󰁁󰀺󰀺 󰁍󰁡󰁮󰁵󰁡 󰁍󰁡󰁮󰁵󰁡󰁬󰁬 󰁤󰁥 󰁵󰁳󰁵󰁡 󰁵󰁳󰁵󰁡󰁲󰁩󰁯 󰁲󰁩󰁯

󰁒󰁥󰁦󰁥󰁲󰁥󰁮󰁣󰁩󰁡󰁳

󰀴󰀵  󰀴󰀵 

󰀴󰀵  󰀴󰀶  󰀴󰀶 

󰀴󰀹   󰀴󰀹 󰀴󰀹  󰀵󰀹  󰀵󰀹 

 

Índice de TTablas ablas Tabla 4–1. Software utilizado

27 

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

32 

Tabla 4–3. Especificaci Especificación ó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 inicialme inicialmente nte

37 

xvii

 

 

 

Í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 Figura 2-7. In-floor towline conveyor

10  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 Figura 3-3. Obtención de medidas mediante la adecuada configuración

20  21 

Figura 3-4. Esquema de funcionamie funcionamiento nto

21 

Figura 3-5. Arquitectura Cliente – Servidor

23 

Figura 3-6. Esquema de comunicaci comunicación ó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 arquitectur arquitecturaa 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 Figura 4-6. Diagrama UML de la aplicación PC

30  30 

xix

 

  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 INTRODUCCIÓN 

  Todo comienzo tiene su encanto. - Johann Wolfgang von Goethe -

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.

E

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

 

  Introducción

󰀲

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 basados ha llevado en latransportadoras. actualidad a escasas auditorías de eficiencia en procesos industriales automatizados en cintas

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 2

 

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

3

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á unamínima iluminancia mínima 200m.lux asísolución como que la disposición cadaéstos piezarequisitos u objeto por permita una distancia sin sombra dede 0,03 Una alternativa, podríaentre sustituir una baliza magnética en cada paquete. En ambos caso, se persigue dar cumplimiento al objetivo c). 3

 

  Introducción

󰀴

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.

4

 

 

2 ANTECEDENTES 

   Lo que no se defin define, e, no no se se puede puede medir medir.. - Lord Kelvin -

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.

E

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. 5

 

  Antecedentes

󰀶

-  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. 6

 

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

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 7

 

  Antecedentes

󰀸

-  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 8

 

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

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

9

 

  Antecedentes

󰀱󰀰

-  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 caminounestá por el sistema de raíles; tiene giros y cambios en elevación formando lazodeterminado 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.

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 

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.

10

 

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

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-Sen (Actuator-Sensor sor 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

11

 

  Antecedentes

󰀱󰀲

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 12

 

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

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. 13

 

Antecedentes

󰀱󰀴 o 

Comunicaciones ma stro – esclavo, esclavo, ppermitiendo ermitiendo un núm número ero reducid reducidoo d esclavos activos.

-  Redes 802.15.4 (ZigBee) o 

Tienen un alcance máximo áximo de uuno noss 75 m, rreq equir uirien iendo do uunn cons consum umoo mí míni nimo ya que la potencia de tr tran anssmisión ión hhab abit it al es de 0 dBm, posibilitan posibilitando do que que,, en fun función ción de s uso, 2 pilas AA sean suficientes para un p riodo entre 6 y 24 meses.

o 

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

o 

Existen equipos coo dinadores, repetidores y terminales.

   

Figura 2-11. Lo otipos de las tecnologías WiFi, Bluetooth y ZigBe

2.1.4  Auditoría de procesos ind striales indust stri rial ales es com como áámb mbit itos os su susc scep epti tibl bles es de a ustar a normativa u Ex Exist isten en ta tanta ntass aud audito itoría ríass de pr proc oces esos indu calida idad, d, de seg seguri uridad dad,, m med edioa ioamb mbien iental tales es,, energ energéti éti as, etc. De entre todas optimizar. Así, tenemos auditorías de cal ellas, nos nos cen centraremos traremos en las auditorías de productividad. Las auditorías de productividad [14] [15] reportan:   mediante eell indicador internacional -  El nivel nivel de pro productividad ductividad real ddeel pprroceso eesstudiado, ccaalculándose me verall all E Equip quipmen mentt Ef Effect fectiven iveness ess (OEE (OEE)) qu quee eng englo lo a la disponibilidad, la de productividad, en inglés ver eficiencia y la calidad. aportan valor po porr ende de su nivel de productividad. En -  La identifi identificació caciónn de pro proceso ceso o tareas que no aportan ansporta ortadora doras, s, aq aquell uellas as lín líneas eas qque ue ap apenas enas se uti utiliz lizan y, por tanto, serían procesos basados en cintas t ansp susceptibles de eliminar. -  La identificación de puntos negros que implican sobrecostes.   rectiv tivas as co como mo ccon onsec secuen uencia cia ddel el análi análisis sis de de los da datos arrojados basados, -  La propuesta de acciones co rec de nu nuevo evo,, en en eell in indic dicado adorr O OE EE, conforme a técnicas de Lean Manufacturing. 14

   

  Sist Sistem emaa de iinf nfor orma mació ciónn de trá tráfi fico en cintas transportadoras mediante WSN

15

En la actualidad actualidad ex existe istenn múltip múltiple les pr propuestas ppaara im implementar au auditorías de pprro uctividad que van desde procesos metrológicos manuales ast asta la la adq adquis isiició ción de ddaato toss más o m men enoos auto tom matizada reportada por los sis sistem temas as ddee inf inform ormaci ación ón ddel el pr proc oceeso auditado. Tal es eell ca caso so de D DOE OEET ET [16 [16]] (v r logotipo en figura 2-12) que se conecta a la red industrial para recoger la in infform rmac ació iónn de lloos ddis isti tinntos tos sist istem emas as de adqu dquis isic ició iónn ddee ddaato toss yyaa in inssta tala laddos (Si (Siemens, Omron, Phoenix Cont Co ntac act,t, …) o ddir irec ecta tame ment ntee ddel el E P (SAP, (SAP, Micr Microso osoft ft Dyna Dynamics mics,, Oracle, Oracle, Sag Sage, e, Cry Cryst stal Reports, …). No obstante, estos sistemas se alim limenta entann de la iinfor nformaci mación ón pree preexis xistente tente que pue e resultar insuficiente o incom inc omple pleta ta ppara ara inf infer erir ir lo loss da datos tos q e requiere el cálculo del OEE.

Figura 2-12. Logotipo de DOEET

2.2.  Estado del arte de r des WSN ado ddel el arte arte de los los proc proces esos os in indu dust stri rial ales es au auto tom matizados basados en cintas De nu nuev evo, o, al igua iguall qque ue en el est estado transportadoras, la temática de las redes WSN es profusa (véase [17], [18] o [19]), m nteniéndose en constante evolución. Es por ello que se abor arán, de forma sintetizada, los aspectos esenciales que faciliten el desarrollo de la la ap aplic licaci ación ón ppro ropu pues esta ta ssigu iguien ien o a [20].

2.2.1  Elementos de las WSN (nodos) están fo form rmada adass por ddisp ispos ositi itivo voss autón autónomo omoss (no (noddos) de reducido tamaño y Las redes redes in inalámbricas alámbricas de sen sensore sores están consumo cons umo,, que rec recoge ogenn info informac rmació ión de su entorno, pudiendo procesarla localmente y comunicarla a un equipo coordinador. De la la ddef efin inic ició iónn ddad adaa ssee ppuuede ede ccoolegir 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 (tra (trans nsce cept ptor or de ra radi dio) o).. A Así sí,, eenn la la ffiigura gura 2-13 2-13 se pres presen enta ta un es esqu quem emaa bbás ásic icoo de de lo loss blo bloques de cada nodo.

15

 

  Antecedentes

󰀱󰀶

Sensor/es

Transmisor / receptor radio

Fuente de energía

CPU / Memoria 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, 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). 16

 

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

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. 17

 

  Antecedentes

󰀱󰀸

Gateway

Router

Sensor

Sensor con enrutamiento

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.

18

 

 

3  ANÁLISIS 

 Lo que no se mide, mide, no se se puede puede mejo mejorar rar.. - Lord Kelvin -

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

E

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.

Condicionantes Elección

Tecnología

Ada ta tadda

Solución óptima

Problema

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.

19

 

  Análisis

󰀲󰀰

Quee m Qu mee ore Condicionantes

Solución actual

Tecnología dada

Bús ueda

Problema O a orte

Solución no existente

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 20

 

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

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. - Luminosidad - Temperatura

- Velocidad - Longitud

Configuración

- Efecto Hall

- Intensidad de tráfico 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.

A

A

d

d

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

B

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.

B

En el instante t3, la mota A ya no se A

d

B

encuentra oculta.

A

d

B

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

Figura 3-4. Esquema de funcionamiento Cada instante de tiempo t i 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: 21

 

  Análisis

󰀲󰀲

V  =

d  t 2

(3–1)

− t 1

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

= V  ⋅

(t 3 − t 1 ) =

 d ⋅ (t 3 − t 1 ) t 2

(3–2)

− t 1

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

n ∆T 

(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: n

 I  =

t 4 i − t 1i ∑ i 1 =

∆ T 

(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 lade mota, éstacaracterísticas. podría reportar el circuito seguido que sería de utilidad en caso de distintos tratamientos en función ciertas

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 22

 

  Sist Sistem emaa de iinf nfor orma mació ciónn de trá tráfi fico en cintas transportadoras mediante WSN

23

ubicaciones remotas. A Assí, ggrráfica ente tendríamos la figura 3-5:

N

N

SI-WSN

N

N

N

N

G

N

N

N

igura 3-5. Arquitectura Cliente – Servidor

3.4.  Flujo de informació motas para im implementar plementar la aplicación y que se requieren de dos motas Considerando que disponemos de dos motas las f nciones de una mota N. para cada medida, a la mota G le incorporaremos, ssiin pérdida de ggeeneralidad, la Nótes Nó tesee qu que, e, en úúltim ltimaa instan instancia cia,, esto sólo supone un incremento de la carga de dicha ota. Así, Así, eell es esqu quema ema de ccom omuni unicac cacion ion s de la aplicación de demostración y, por tanto, el flujo de información que ll lleeva im implí líci cito to,, vie vienne dad dadoo ppoor la la figura 3-6: PC

MOTA A ≡ G+N

Fig ra 3-6. Esquema de comunicación del sistema

23

MOTA B ≡ N

 

  Análisis

󰀲󰀴

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

Aplicación MOTA A

- Recepción datos MOTA B

Aplicación MOTA B

- Detección de tiempos

- Recepción datos MOTA A

- Envío datos PC

- Cálculo de magnitudes

- Detección de tiempos

- Generación de alarmas por baja luminosidad

- Presentación de resultados

- Generación de alarmas por baja luminosidad

- Envío datos MOTA A

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. 24

 

 

4  DISEÑO 

   Lo que no se mejor mejora, a, se degra degrada da siem siempre. pre. - Lord Kelvin -

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

E

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.

25

 

  Diseño

󰀲󰀶

Sensor de efecto Hall Sensor de temperatura Sensor de luminosidad

Botón de usuario

Chip MAC

Botón de reset

µControlador + Radio

UART a USB

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:

26

 

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

27 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

Aplicación meshprog para transferir los desarrollos a la mota Otros

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.

Arquitectura sistemas operativos tradicionales

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

Arquitectura 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.

27

 

  Diseño

󰀲󰀸

-  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.

Main (includes Scheduler) Application (User Components) Active Message Actuating

Sensing

Communication

Mote Hardware 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

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

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

 

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

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.

Otroagrupa de los elelementos TinyOS es de su interfaces. programación en NesC, dialecto del C que código enfundamentales componentes que que configuran se comunican a través De ahí que se un 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 implementados a alto nivel. a funciones callback, son especificados a bajo nivel e

-  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.

Componente Tareas internas

Comandos

Estado interno

Eventos

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. 29

 

  Diseño

󰀳󰀰

Ad hoc Routing Application

Application

Active Messages

Message

Packet

SW

Byte

HW

Bit

Radio packet

Serial packet

Radio byte

UART

RFM

Photo

Temp

ADC

I2C

Clocks

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 30

 

  Sist Sistem emaa de iinf nfor orma mació ciónn de trá tráfi fico en cintas transportadoras mediante WSN

31

Aunque por ssuu simp Aunque simplicid licidad ad no e neces necesari ario, o, hem hemos os hec hecho ho us usoo del del pl plug ugin in de de Ec Ecli lipse eUML2 que permite generar gen erar ddiagr iagramas amas U UML ML a part partir ir de su código.

4.2.2  Diagrama de compone tes TinyOS A continuación mostramos, enforla aplicación que se figu ra nom 4-7,enclatur el ddiagr iagrama deda, com compon ponente entes s TinyO ej ejec ecut utaa eenn la Mo Mota ta A qque ue,, ccon onfo r figura se laencuentra conectada e a la nomencl atura aama uti utiliza lizada, corre correspo sponde nde a la q ede al PC mediante USB.

Figura 4-7. Diagrama de componentes TinyOS de la aplicación Mo aAApp Hemos obtenido dicho diagrama,  sí como como la docu docume ment ntac ació iónn as asoc ocia iada da al mis ism mo, me iante el comando: make cou24 docs

Del mismo modo, generamos el diagrama de componentes TinyOS de la aplicación ue se ejecuta en la Mota B y que mostramos en la figura 4- .  

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

4.3.  Casos de uso de la plicación SIT-WSN es un Sistema de Inform rmaaci cióón ccuy uyoos ddat atoos ssee aalm lmaace cennan para su ppoosterior análisis por otras aplicaciones o módulos. Así, los os únicos actores que intervienen son los objetos ue circulan por las cintas transportadoras y que generan los isti istintos ntos even eventos tos y el co consu nsultor ltor o pe perso rsona na qque ue aacce cce e a los mismos. La información relativa a la temperatura y tensiones de batería se recoge de forma paralela y automática sin que intervenga ningún actor. La figura 4-9 muestra los casos de uso de señalados.

31

 

  Diseño

󰀳󰀲

Genera datos  en su paso sobre las motas 

Solicita informe de velocidades, longitudes, tráfico, temperatura...

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. 01

El Consultor demanda el informe.

02

El sistema ofrece el informe registrados hasta el momento.

Secuencia principal Errores alternativas No. Postcondición

Ninguna.

Notas

No.

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

32

 

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

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.

04

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

05

El Objeto deja al descubierto la primera* mota.

06

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

07

El Objeto deja al descubierto la segunda* mota.

08

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

33

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

03

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

↔

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:

• 

Errores alternativas

transición.

No (03 y 07) • 

Postcondición

Ninguna.

Notas

No.

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

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.

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

33

 

  Diseño

󰀳󰀴

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:

34

 

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

35

periodos

Valor magnitud

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

Id mota 

Tipo

2

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

0: El objeto se encuentra sobre la mota

1: Variaciones de luminosidad

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 Error en la lectura de sensores / comunicac comunicaciones iones 0: No aporta mayor significad significadoo Tabla 4–5. Significado de los campos “Tipo” y “Valor” 35

35

 

  Diseño

󰀳󰀶

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 la comparación de de valores temporales adquiridos múltiplesquesistemas requiere garantizar que éstosparte, utilizan la misma base tiempos – el mismo reloj –desde o, al menos, existe una sincronización previa que simula fehacientemente la unicidad de referencias. 36

 

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

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

37

 

  Diseño

󰀳󰀸

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. 38

 

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

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.

39

 

  Diseño

󰀴󰀰

40

 

 

5  RESULTADOS 

  Todo lo que somos es el resultado de lo que hemos  pensad  pen sado; o; está está fund fundado ado en nuest nuestros ros pen pensam samiento ientoss y está hecho de nuestros pensamientos. - Buda -

nla elvez presente se sistema desarrollan distintos el ejemplos observando lasobjetivos entradas marcados y resultados que secapítulo evalúa el verificando cumplimiento de los el obtenidos capítulo dea Introducción.

E

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

41

 

  Resultados

󰀴󰀲

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. 42

 

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

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 iluminancia mínima 200 luxNacional que debiera estar asegurada inferior en al mínimouna de 300 lux exigidos por eldeInstituto de Seguridad e Higienealenser el Trabajo á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 de cada mota, de 42,95deEUR, asíindustrial como la posibilidad de reutilización en múltiples auditorías porcoste cuanto son independientes la red 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.

43

 

  Resultados

󰀴󰀴

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).

44

 

 

6  CONCLUSIONES 

   La vida es el el arte arte de de sacar sacar conc conclusi lusiones ones suf suficien icientes tes a  partir  par tir de datos datos insu insuficie ficientes ntes.. - Samuel Butler -

ndificultades este últimoencontradas capítulo se arealiza una del descripción desarrollo del señalando alasmodo distintas lo largo mismo; del continuándose conproyecto las conclusiones de impresiones generales y se cierra con las posibles líneas de desarrollo que se han suscitado.

E

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 lapara aplicación sí han una dilatado laslabor expectativas temporales por cuanto se han valorado diversos sectores los queconcreta se realizaba ardua 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 la tecnología programación requerido de pequeños desarrollos ya título formativode para testear ely de usosuysingular adquisición de datostambién de los ha distintos sensores, comunicaciones capacidad de procesamiento del sistema microcontrolador.

45

 

  Conclusiones

󰀴󰀶

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, laexistente aplicación propuesta ha permitido intuir, aenmodo de frontera de posibilidades el compromiso entre la funcionalidad deseada, nuestro caso parametrizada por de la producción, 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.

46

 

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

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.

47

 

  󰀴󰀸

Conclusiones

48

 

 

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:

make cou24 install,1

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:

ls ./build/cou24

o 

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

app.c

main.exe

main.ihex

main.srec.out-1

ident_flags.txt

main.exe.out-1

main.srec

tos_image.xml

o 

wiring-check.xml

azul)) y En la figura 7-1, incluimos el detalle de las instrucciones (destacadas en color azul feedback compilares y“/dev/ttyUSB0”. cargar la aplicación en la Mota de acuerdo alrecibido comandopara “motelist”, (/dev/ttyUSB1 paraAlacuyo Motadescriptor, B).

49

 

  Apéndices

󰀵󰀰

Setting up for TinyOS 2.1.1

asuarez@AP:~/Escritorio/MotaA$ mak  make e cou2 cou24 4 inst install all,1 ,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 -fnescdump='interfaces(!abstract())' -fnescdump='referenced(interfacedefs, components)' -fnescdumpfile=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$ mes  meshpr hprog og -t/ -t/dev dev/tt /ttyUS yUSB0 B0 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! 

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

50

 

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

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:

motelist

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.

Reference

Device

Description

---------- ---------------- --------------------------------------------0001

o 

/dev/ttyUSB0

Silicon Labs CP2102 USB to UART Bridge Controller

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:

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

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:

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!

-  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.

51

 

  Apéndices

󰀵󰀲 Aplicación Mota B:

-  Compilación: o 

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

make cou24 install,2

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:

ls ./build/cou24

o 

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

app.c ident_flags.txt

main.exe main.exe.out-2

main.ihex main.srec

main.srec.out-2 tos_image.xml

wiring-check.xml

-  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:

motelist

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.

Reference

Device

Description

---------- ---------------- --------------------------------------------0001

/dev/ttyUSB0

Silicon Labs CP2102 USB to UART Bridge Controller

0001

/dev/ttyUSB1

Silicon Labs CP2102 USB to UART Bridge Controller

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:

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

o 

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

52

 

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

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:

using tty /dev/ttyUSB1 reading from file ./build/cou24/main.srec.out-2 sending ./build/cou24/main.srec.out-2 -> /dev/ttyUSB1

Opened file ./build/cou24/main.srec.out-2 Opened device /dev/ttyUSB1 ..........................,[i&] Starting transmission.

 

finished!

-  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:

private static String rutaFichero = "/home/asuarez/Escritorio/Carpeta compartida/reporte.csv";

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

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:

javac PrintfSitWsn.java

53

 

  Apéndices

󰀵󰀴

o 

A estos efectos, es necesario que la variable de entorno CLASSPATH incluya “tinyos.ja “tinyos.jar” r” 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:

java PrintfSitWsn.class

o 

En caso correcto, en la pantalla visualizaremos:

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

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

54

 

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

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. pulsando en el botón “Actualizar” que abre un cuadro de diálogo mostrado en laContinuamos figura 7-5 donde seleccionar el archivo reporte.csv

55

 

  Apéndices

󰀵󰀶

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 han fijadode de contenida en lossedatasheets cadaacuerdo sensor.a las exigencias del sistema y a la información

56

 

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

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

57

 

  󰀵󰀸

Apéndices

58

 

 

REFERENCIAS 

[1]

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

[2]

G. Lorenzo Lledó, «Automatizaci «Automatización ó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 nonrigidproducts, 1996.

[6]

D. Nitzan y C. Rosen, Programmable IIndustrial ndustrial 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.wi https://es.wikipedia.org/wi kipedia.org/wiki/AS-interface ki/AS-interface.. [12] I. Electronic, «S «Sistema istema de bus AS-interface,» [En línea]. Av Available: ailable: https://www.ifm.com/obj https://www.ifm.com/obj/ifm_AS/ifm_ASInterface_Catalogue_ES_08.pdf. [13] R. Estepa y A. Estepa, ««Comunicación Comunicación Industriales Inalámbricas,» [En línea]. Available: http://trajano.us.es/docencia/RedesLocalesEnLaIndustria/sld/RedesIndustriales6-5.pdf. [14] «Auditoría de productividad, productividad,»» [En línea]. Available: http://i http://ipyc.net/organizaci pyc.net/organizacion-y-lean/organi on-y-lean/organizacionzacionindustrial/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 http://doeet.com/what-is .com/what-is-doeet/implementa -doeet/implementation. tion.

59

 

  Referencias

󰀶󰀰

[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%252FTrabajoFin alMaster.pdf. [18] J. M. Hinojo Montero, «Estudio e implementaci implementación ó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://ww http://www.mfbarcell.es/ w.mfbarcell.es/conferencias/wsn.pd. conferencias/wsn.pd. [21] «List of wireless sensor nodes,» 28 3 https://en.wikipedia.org/wiki/List_of_wireless_sensor_nodes.

2016.

[En

línea].

Available:

[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-2ISSUE-1-45-48.pdf. [23] Memsic, «MIB600 Ethernet Interface Board,» [En línea]. http://www.memsic.com/userfiles/files/Datasheets/WSN/6020-0055-05_a_mib600-t.pdf.

Available:

[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_Networ ks_A_Survey. [25] UOC, «Hardware COU 1 2,» http://cv.uoc.edu/app/mediawiki14/wiki/Hardware_COU_1_2.

[En

línea].

Available:

[26] «Atmel ATmega640/V-1280/ ATmega640/V-1280/V-1281/V-2560/V V-1281/V-2560/V-2561/V,» -2561/V,» [En línea]. Available: http://www.atmel.com/Images/Atmel-2549-8-bit-AVR-Microcontroller-ATmega640-1280-1281-25602561_datasheet.pdf. [27] «CdS Photoconductive Photocells PDV-P9003,» [En http://www.advancedphotonix.com/wp-content/uploads/PDV-P9003.pdf.

línea].

Available:

[28] «Low-Power Linear Active Thermistor IC ICss 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]. http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/hall/bu52001gul-e.pdf.

Available:

[30] «TinyOS,» [En línea]. Available: http://ti http://tinyos.net/. nyos.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.p df.