Estado Del Arte de Bandas Transportadoras PDF

Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Sistema de información
información de tráfico en cintas
transportadoras mediante WSN
Autor: Antonio Suárez Reyes

Tutor: Daniel Gutiérrez Reina
Equation Chapter 1 Section 1
Dep. Ingeniería Electrónica

Escuela 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, 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 Suárez 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 persigue poner de manifiesto la versatilidad de las motas utilizadas en redes
inalámbricas de sensores reorientando su uso en procesos industriales automatizados basados en cintas
transportadoras para implementar una auditoría de productividad en dicho entorno.
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
Agradecimientos ix
Resumen xi
Abstract xiii
Índice xv
Índice de Tablas xvii
Índice de Figuras xix
1 Introducción 1
1.1. Presentación del problema 1
1.2. Objetivos del proyecto 2
1.2.1. Descripción del problema 2
1.2.2. Objetivos de la solución 3
1.3. Descripción de alto nivel de la solución 3
1.4. Descripción estructurada del resto de la memoria 4
2 Antecedentes 5
2.1. Estado del arte de auditorías de procesos industriales automatizados basados en cintas
transportadoras 5
2.1.1 Automatización de procesos industriales 5
2.1.2 Tipos de cintas transportadoras 7
2.1.3 Redes industriales 11
2.1.4 Auditoría de procesos industriales 14
2.2. Estado del arte de redes WSN 15
2.2.1 Elementos de las WSN (nodos) 15
2.2.2 Arquitecturas y topologías de red 17
3 Análisis 19
3.1. Enfoque del proyecto 19
3.2. Condicionantes y criterios adoptados 20
3.3. Arquitectura del sistema 22
3.4. Flujo de información 23
4 Diseño 25
4.1. Tecnología utilizada 25
4.1.1 Hardware 25
4.1.2 Software 26
4.2. Diagrama de componentes 30
4.2.1 Diagrama UML de componentes de la aplicación PC 30
xv
4.2.2 Diagrama de componentes TinyOS 31
4.3. Casos de uso de la aplicación 31
4.4. Criterios de diseño 34
4.4.1 Adaptación del diseño: Base de tiempos 36
4.5. Descripción de la interfaz de usuario 38
5 Resultados 41
5.1. Producto obtenido 41
5.2. Cumplimiento de objetivos 43
6 Conclusiones 45
6.1. Desarrollo del proyecto 45
6.2. Conclusiones 46
6.3. Líneas de desarrollo 46
Apéndices 49
Apéndice A: Manual de usuario 49
Referencias 59
Índice de Tablas
Tabla 4–1. Software utilizado 27

Tabla 4–2. Especificación del caso de uso “Solicita informe” 32
Tabla 4–3. Especificación del caso de uso “Genera datos” 33
Tabla 4–4. Ejemplo de datos reportados a la aplicación PC 35
Tabla 4–5. Significado de los campos “Tipo” y “Valor” 35
Tabla 4–6. Algoritmo de sincronización previsto inicialmente 37
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 10
Figura 2-7. In-floor towline conveyor 11
Figura 2-8. Bus AS-i en planta de transporte industrial 12
Figura 2-9. Instalación con bus AS-i en laboratorios de automática de la ESI de Sevilla 12
Figura 2-10. Detalle de la conectividad del bus AS-i 13
Figura 2-11. Logotipos de las tecnologías WiFi, Bluetooth y ZigBee 14
Figura 2-12. Logotipo de DOEET 15
Figura 2-13. Esquema de bloques de un nodo 16
Figura 2-14. Diferentes topologías de red 18
Figura 3-1. Proceso de ingeniería genérico 19
Figura 3-2. Enfoque del presente proyecto 20
Figura 3-3. Obtención de medidas mediante la adecuada configuración 21
Figura 3-4. Esquema de funcionamiento 21
Figura 3-5. Arquitectura Cliente – Servidor 23
Figura 3-6. Esquema de comunicación del sistema 23
Figura 3-7. Diagrama de bloques del sistema 24
Figura 4-1. Detalle mota COU_1_2 26
Figura 4-2. Origen de la arquitectura TinyOS 27
Figura 4-3. Arquitectura TinyOS simplificada 28
Figura 4-4. Modelo de componente TinyOS y su interacción 29
Figura 4-5. Gráfico de componentes de una aplicación genérica 30
Figura 4-6. Diagrama UML de la aplicación PC 30
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 -
E
n el contexto actual, marcado por la rápida evolución de múltiples tecnologías, el verdadero valor
añadido se encuentra en ser capaz de detectar las necesidades no atendidas, por cuanto eran impensables
antes de la existencia de dichas tecnologías.
En este sentido, adicionalmente, debe tenerse en cuenta que existen tecnologías que nacieron para dar solución
a determinadas necesidades y que, tras quedar obsoletas por otras tecnologías más específicas o con mejores
prestaciones, han tenido un desarrollo más amplio y con mayor recorrido en otros campos distintos al objetivo
inicial para el que fueron creadas.
Son estos dos principios, el comercial y la flexibilidad y reciclabilidad de la tecnología, los que inspiran el
presente proyecto que ofrece un sistema de información para auditorías de eficiencia de procesos industriales
automatizados basados en cintas transportadoras mediante WSN1 implementada con motas COU 1_2 24 A2.
1.1. Presentación del problema

El diseño de nuevos procesos industriales automatizados basados en cintas transportadoras requiere de un
esfuerzo de integración de diversos sistemas [1] que se agiliza mediante el uso de software de simulación
como ARENA, CPN, GSPN, SIMAN o WITNESS.
En dichas simulaciones intervienen modelos estadísticos simplificados tanto de los procesos de tratamiento o
transformación como de los flujos previstos de entrada y salida a éstos de las piezas o materias a transformar.
La acumulación de errores derivados de las simplificaciones en los citados modelos da lugar a diseños
subóptimos cuyo rendimiento queda enmascarado por las expectativas conservadoras que precisamente
generan las simulaciones realizadas a partir de los mismos y que sólo se manifiestan al compararse con los
mejores resultados de otras plantas o centros cuyos rendimientos esperados eran, a priori, similares.
1 WSN: Redes inalámbricas de sensores, del inglés Wireless Sensor Networks.
1
2 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 ha llevado en la actualidad a escasas auditorías de eficiencia en procesos industriales
automatizados basados en cintas transportadoras.
1.2. Objetivos del proyecto

Con todo lo indicado, el presente proyecto tiene por objetivos:
- Poner el foco en la potencialidad de la tecnología WSN que, por su reducido coste y permitir medidas
en ubicaciones de difícil acceso, posibilita la detección de necesidades no cubiertas. Esto es: nuevos
mercados.
- Evidenciar la flexibilidad y reciclabilidad de los elementos hardware y software que conforman la

WSN.
- De forma paralela, realizar un esfuerzo de integración entre distintas tecnologías.
1.2.1. Descripción del problema

Para facilitar una descripción detallada del problema, con el objetivo de visualizar el contexto, obsérvese la
figura 1-1 que nos sitúa en una planta industrial automatizada basada en cintas transportadoras.
Figura 1-1. Proceso industrial de almacén automatizado
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á una iluminancia mínima de 200 lux así como que la disposición entre cada pieza u objeto permita
una distancia mínima sin sombra de 0,03 m. Una solución alternativa, podría sustituir éstos requisitos por una
baliza magnética en cada paquete. En ambos caso, se persigue dar cumplimiento al objetivo c).
3
4 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 define, no se puede medir.

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

en cintas transportadoras
Este único punto podría ser objeto de múltiples tesis doctorales por lo que realizaremos una síntesis de [2] ya
que, en última instancia, lo que se persigue es situar contextualmente el entorno donde y para el que se
desarrolla la aplicación propuesta.
2.1.1 Automatización de procesos industriales
De una parte, [3] define la automatización de procesos industriales en "el empleo de dispositivos electrónicos o
mecánicos para sustituir trabajo humano" que su reformula manteniendo la esencia.
En [4] ya se relacionó las ventajas de la automatización:
- Aumento de la productividad y consistencia en los productos [5]
- La automatización genera una estabilidad y robustez en el sistema.
- Las tecnologías de automatización no presentan fallos.
- Mejorar las condiciones de trabajo del personal, incrementando la seguridad.
5
6 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
- 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
8 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
- 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
10 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 camino está determinado por el sistema de raíles; tiene giros y cambios en elevación
formando un lazo sin fin.
o En los carros se suspenden ganchos, cestas u otros receptáculos para la carga.
o Se emplean a menudo en fábricas para mover piezas y conjuntos de ensamblaje entre los
principales departamentos de producción.
o Pueden emplearse tanto para reparto como para almacenamiento.
Figura 2-6. Overhead trolley conveyor
- In-floor towline conveyor (cable enterrado) (véase figura 2-7)

o Emplean vehículos con ruedas impulsados por medio de cadenas o cables en movimiento
situados en zanjas en el suelo.
o Las rutas están definidas por las zanjas y cables.
o Es posible el cambio desde un segmento impulsado a otro diferente, proporcionando cierta
flexibilidad en el rutado.
o Los carros emplean clavijas reforzadas de acero para acoplarse a la cadena.
o Dichas clavijas se pueden extraer de la zanja para liberar al carro del avance de la cadena y
realizar las operaciones de carga/descarga.
10
Figura 2-7. In-floor towline conveyor
2.1.3 Redes industriales
2.1.3.1 Redes cableadas

La automatización industrial requiere la conectividad entre sensores - actuadores y los elementos de control.
Hasta la fecha dicha conectividad se ha venido implementando mayoritariamente de forma cableada existiendo
múltiples normas que vienen compitiendo por imponerse, entre las que destacamos, siguiendo a [10]: Profibus,
Fieldbus Foundation, AS-i, LonWorks, Interbus, DeviceNet, MODBUS, HART, ControlNet, WORLFIP, FIP,
e incluso Ethernet.
El análisis detallado de cada una de ellas carece de interés para el presente proyecto. No obstante, sí
desglosaremos el bus AS-i a efectos ilustrativos de los elementos necesarios para la implementación genérica
de dichas redes.
Así, conforme a [11] y [12], el bus AS-i (Actuator-Sensor Interface) fue creado en 1.990 con el objetivo de
minimizar el cableado necesario al incorporar las señales de sensores, actuadores y alimentación en el mismo
cable. Se encuentra definido en el estándar internacional IEC62026-2 y en el europeo EN50295.
Actualmente en su versión 3 admite tanto sensores y actuadores binarios y analógicos, siendo un sistema
monomaestro que facilita gran flexibilidad de topologías. Se caracteriza por un cable amarillo autocicatrizante
(en la figura 2-10 se muestra el detalle de su conectividad) codificado mecánicamente para evitar su
polarización incorrecta que tiene un alcance máximo de 100 metros (300 metros con repetidores) y admite
hasta 248 sensores y 186 actuadores binarios.
Así, con el objetivo de contextualizar visualmente el bus AS-i, en las figuras 2-8 y 2-9 se muestra
respectivamente el rutado de éste en una planta de transporte industrial y una instalación del mismo en los
laboratorios de automática de la ESI de Sevilla
11
12 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
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
14 Antecedentes
o Comunicaciones maestro – esclavo, permitiendo un número reducido de esclavos activos.
- Redes 802.15.4 (ZigBee)
o Tienen un alcance máximo de unos 75 m, requiriendo un consumo mínimo ya que la potencia

de transmisión habitual es de 0 dBm, posibilitando que, en función de su uso, 2 pilas AA sean
suficientes para un periodo entre 6 y 24 meses.
o La velocidad de transmisión puede alcanzar los 250 Kbps, suficiente para la transmisión en
bucles de control industrial.
o Existen equipos coordinadores,

coordin repetidores y terminales.
Figura 2-11. Logotipos de las tecnologías WiFi, Bluetooth y ZigBee
2.1.4 Auditoría de procesos industriales
Existen tantas auditorías de procesos industriales como ámbitos

ámbitos susceptibles de ajustar a normativa u
optimizar. Así, tenemos auditorías de calidad, de seguridad, medioambientales, energéticas, etc. De entre todas
ellas, nos centraremos en las auditorías de productividad.
productividad
Las auditorías de productividad [14] [15] reportan:
- El nivel de productividad real del proceso estudiado, calculándose mediante el indicador internacional
de productividad, en inglés Overall Equipment Effectiveness (OEE) que engloba la disponibilidad,
dispon la
eficiencia y la calidad.
- La identificación de procesos o tareas que no aportan valor por ende de su nivel de productividad. En
procesos basados en cintas transportadoras, aquellas líneas que apenas se utilizan y, por tanto, serían
susceptibles de eliminar.
- La identificación de puntos negros que implican sobrecostes.
- La propuesta de acciones correctivas como consecuencia del análisis de los datos arrojados basados,
de nuevo, en el indicador OEE, conforme a técnicas de Lean Manufacturing.
14
En la actualidad existen múltiples propuestas para implementar auditorías de productividad que van desde
procesos metrológicos manuales hasta la adquisición de datos más o menos automatizada reportada por los
sistemas de información del proceso auditado.
Tal es el caso de DOEET [16] (ver logotipo en figura 2-12)

2 que se conecta a la red industrial para recoger la
información de los distintos sistemas de adquisición de datos ya instalados (Siemens, Omron, Phoenix
Contact, …) o directamente
mente del ERP (SAP, Microsoft Dynamics, Oracle, Sage, Crystal Reports, …).
No obstante, estos sistemas se alimentan de la información preexistente que puede resultar insuficiente o
incompleta para inferir los datos que requiere el cálculo del OEE.
Figura 2-12. Logotipo de DOEET
2.2. Estado del arte de redes WSN
De nuevo, al igual que en el estado del arte de los procesos industriales automatizados basados en cintas
transportadoras, la temática de las redes WSN
WS es profusa (véase [17], [18] o [19]),, manteniéndose en constante
evolución. Es por ello que se abordarán, de forma sintetizada, los aspectos esenciales que faciliten el desarrollo
de la aplicación propuesta siguiendo a [20].
2.2.1 Elementos de las WSN (nodos)

Las redes inalámbricas de sensores están formadas por dispositivos autónomos (nodos) de reducido tamaño y
consumo, que recogen información de su entorno, pudiendo procesarla localmente y comunicarla a un equipo
coordinador.
De la definición dada se puede colegir la estructura física de los nodos que requiere autonomía (alimentación
propia) para la recogida de datos (sensores) que se procesan a nivel local (microcontrolador) y se comunica
(transceptor de radio). Así, en la figura 2-13
2 se presenta un esquema básico de los bloques de cada nodo.
15
16 Antecedentes
Transmisor /
Sensor/es
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, 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
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
18 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, no se puede mejorar.

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

En un gran número de ocasiones, la labor a desarrollar en ingeniería comenzará con un problema inscrito entre
condicionales al que tendremos que dar una solución óptima eligiendo la tecnología que mejor se adapte al
mismo. La figura 3-1 pretende esquematizar dichas situaciones.
Condicionantes
Tecnología Solución
Elección Adaptada
Problema óptima
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
20 Análisis
Solución
Que mejore
actual
Condicionantes
Tecnología
Búsqueda
dada
Problema
Solución
O aporte
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
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 - Velocidad
- Temperatura Configuración - Longitud
- 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.
En el instante t1, la pieza “eclipsa“ a

la mota A.
A d B
En el instante t2, la pieza bloquea la

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

A d B encuentra oculta.
En el instante t4, se desbloquea

A d B finalmente la mota B.
Figura 3-4. Esquema de funcionamiento
Cada instante de tiempo ti se determinará considerando las variaciones en la luminosidad recibida.
De esta forma, la velocidad del objeto, suponiendo ésta constante a lo largo de d, vendrá dada por la expresión
3-1:
21
22 Análisis
d
V = (3–1)
t 2 − t1
La longitud del objeto por la expresión 3-2:
d ⋅ (t 3 − t1 )
L = V ⋅ (t 3 − t1 ) = (3–2)
t 2 − t1
Y la intensidad de tráfico por la expresión 3-3:
n
I= (3–3)
∆T
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:
∑t
i =1
4i − t1i
I= (3–4)
∆T
Así, la información relativa a la intensidad de tráfico permitiría, entre otros, detectar tramos saturados en
procesos en serie que podrían descongestionarse con otras tareas en paralelo o una mayor celeridad en los
procesos posteriores. Igualmente, y de forma adicional, podríamos reportar la temperatura o la luminosidad en
cada punto a otros efectos como aviso de temperaturas anormalmente altas o baja luminosidad lo que
detectaría posibles errores del sistema.
De otra parte, excediendo las posibilidades actuales de nuestra mota, proponemos para futuros desarrollos otra
posible aplicación mediante el uso de etiquetas RFID. Así, añadiendo a cada elemento que circula por las
cintas transportadoras una etiqueta RFID con un número de referencia interna a modo de “MAC” y un lector
RFID en la mota, ésta podría reportar el circuito seguido que sería de utilidad en caso de distintos tratamientos
en función de ciertas características.
3.3. Arquitectura del sistema

La configuración propuesta exige una dedicación a los nodos detectando y reportando los cambios de bruscos
luminosidad por lo que resulta adecuado evitar cualquier otra carga para éstos como pudiera ser la de
enrutamiento lo que nos lleva a una arquitectura centralizada o una solución intermedia con enrutadores.
Del alcance de la tecnología inalámbrica y el ajustado coste de los nodos se colige que la arquitectura más
adecuada es la centralizada de tipo cliente – servidor, pudiendo replicar ésta con otros servidores si se requiere
abarcar distancias mayores.
En el servidor se almacenarán los datos para su posterior análisis o se compartirán en red a equipos en
22
stema de información de tráfico en cintas transportadoras mediante WSN
Sistema 23
ubicaciones remotas. Así, gráficamente tendríamos la figura 3-5:
N N
N N
SI-WSN N N
N
N
N N
Figura 3-5. Arquitectura Cliente – Servidor
3.4. Flujo de información

Considerando que disponemos de dos motas para implementar la aplicación y que se requieren de dos motas
para cada medida, a la mota G le incorporaremos, sin pérdida de generalidad, las funciones de una mota N.
Nótese que,
ue, en última instancia, esto sólo supone un incremento de la carga de dicha mota.
Así, el esquema de comunicaciones de la aplicación de demostración y, por tanto, el flujo de información que
lleva implícito, viene dado por la figura 3-6:
3
PC MOTA A ≡ G+N MOTA B ≡ N
Figura 3-6. Esquema de comunicación del sistema
23
24 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 Aplicación MOTA B
- Recepción datos MOTA B

- Detección de tiempos
- Recepción datos MOTA A - Envío datos PC
- Generación de alarmas por
- Cálculo de magnitudes - Detección de tiempos baja luminosidad
- Presentación de resultados - Generación de alarmas por - Envío datos MOTA A
baja luminosidad
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 mejora, se degrada siempre.

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

4.1.1 Hardware
Para el desarrollo de la presente aplicación se ha hecho uso de:
- 1 Equipo portátil Acer Aspire 1810TZ

- 2 motas COU_1_2 [25]
Por rigurosidad se informa del modelo del equipo informático. Si bien, no se exigen especiales características
al mismo más que conectividad USB.
Sí nos centraremos en las motas COU_1_2 cuyo detalle se muestra en la figura 4-1.
25
26 Diseño
Sensor de
efecto Hall
Sensor de
temperatura
Sensor de Botón de
luminosidad usuario
Chip MAC Botón de reset
µControlador UART a USB

+ Radio
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
Mota PC
Sistema operativo TinyOS programado en NesC Linux Ubuntu 11.04
Entorno de programación Eclipse Eclipse
Librerías TinyOS para NesC TinyOS para Java
Lenguaje de programación NesC Java
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 Recursos limitados:

sistemas operativos - Memoria ajustada Arquitectura TinyOS
tradicionales - Mínimo consumo energético
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
28 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 No pueden anticiparse a otras tareas, lo que las dota de un carácter atómico respecto de las
mismas.
o Su gestión se realiza en una pila FIFO con un número limitado de tareas pendientes. Cuando
28
ésta está vacía, el planificador limita la actividad de la CPU al reloj, minimizando así el
consumo.
El uso adecuado de ambos niveles permite alcanzar un alto rendimiento en aplicaciones con concurrencia
intensiva.
Otro de los elementos fundamentales que configuran TinyOS es su programación en NesC, un dialecto del C
que agrupa el código en componentes que se comunican a través de interfaces. De ahí que se utilicen términos
como arquitectura basada en componentes o modelo de programación orientado a componentes.
A su vez, estos componentes pueden ser:
- Módulos (nombreC.nc) que implementan interfaces con funciones: comandos y eventos.
o Los comandos son especificados a alto nivel e implementados a bajo nivel. Realizan
peticiones que no bloquean al componente de nivel inferior.
o Los eventos, comparables a funciones callback, son especificados a bajo nivel e

implementados a alto nivel.
- Configuraciones (nombreAppC.nc) que conectan interfaces entre sí (denominado wiring y

representado mediante fechas que unen quienes utilizan la interfaz con quienes las proveen).
Lo indicado queda sintetizado en la figura 4-4.
Componente
Estado
Tareas internas interno
Comandos 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
30 Diseño
Application Ad hoc Routing Application
Message Active Messages
Packet Radio packet Serial packet
SW Byte Radio byte UART Photo Temp
HW Bit RFM 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
Aunque por su simplicidad no es necesario, hemos

hemos hecho uso del plugin de Eclipse eUML2 que permite
generar diagramas UML a partir de su código.
4.2.2 Diagrama de componentes TinyOS

A continuación mostramos,, en la figura 4-7,
4 el diagrama de componentes TinyOS de la aplicación que se
ejecuta en la Mota A que, conforme a la nomenclatura utilizada, corresponde a la que se encuentra conectada
al PC mediante USB.
Figura 4-7. Diagrama de componentes TinyOS de la aplicación MotaAApp
Hemos obtenido dicho diagrama,, así como la documentación asociada al mismo, mediante el comando:
make cou24 docs
Del mismo modo, generamos el diagrama de componentes TinyOS de la aplicación

aplicación que se ejecuta en la Mota
B y que mostramos en la figura 4-8.
8.
Figura 4-8. Diagrama de componentes TinyOS de la aplicación MotaBApp
4.3. Casos de uso de la aplicación

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

parale y automática sin
que intervenga ningún actor.
La figura 4-99 muestra los casos de uso de señalados.
31
32 Diseño
1.1.1.1.1
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
El Consultor solicita informe sobre velocidades, longitudes, tráfico, temperatura,

Descripción
tensión de baterías y luminosidad.
Actores Consultor.
Precondición Ninguna.
01 El Consultor demanda el informe.

Secuencia principal
02 El sistema ofrece el informe registrados hasta el momento.
Errores alternativas No.
Postcondición Ninguna.
Notas No.
Tabla 4–2. Especificación del caso de uso “Solicita informe”
32
Nombre 02 - Genera datos
Descripción El objeto genera datos en su paso sobre las motas.
Actores Objeto.
Precondición Ninguna.
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.
Secuencia principal 05 El Objeto deja al descubierto la primera* mota.
07 El Objeto deja al descubierto la segunda* mota.
* Entiéndase primera y segunda mota conforme al sentido del movimiento.
Al no exigirse una longitud mínima del objeto, el sistema registra de

03 ↔ 05 forma transparente las situaciones en las que se intercambian
temporalmente 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:
• Si el siguiente objeto circula en el mismo sentido, el sistema

Errores alternativas
actualizará los registros 02 y 06 conforme a la nueva
No transición.
(03 y 07)
• Si el siguiente objeto circula en sentido contrario, al cubrir en
primera instancia la segunda mota (desde el punto de vista
del caso anterior), el sistema no puede diferenciar este
hecho de una circulación “normal” del objeto anterior. Si
bien, la disparidad de velocidades y longitudes denotará este
hecho.
Postcondición Ninguna.
Notas No.
Tabla 4–3. Especificación del caso de uso “Genera datos”
33
34 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
Número de Valor
Id mota Tipo
periodos magnitud
2 1 10435 0
2 1 10484 1
1 1 10518 0
1 1 10541 1
1 1 13737 0
1 1 13769 1
2 1 13776 0
2 1 13796 1
2 1 16885 1
1 1 19788 0
Tabla 4–4. Ejemplo de datos reportados a la aplicación PC
De esta forma:
- El campo “Id mota” puede ser 1 (mota A) ò 2 (mota B).

- El valor del campo “Número de periodos” / 1024 [s] establece la referencia temporal necesaria para
los cálculos.
Los campos “Tipo” y “Valor” presentan los siguientes posibles valores representados en la tabla 4-5.
Tipo Valor
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 en la lectura de sensores / comunicaciones 0: No aporta mayor significado
Tabla 4–5. Significado de los campos “Tipo” y “Valor”
35
36 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 parte, la comparación de valores temporales adquiridos desde múltiples sistemas requiere garantizar
que éstos utilizan la misma base de tiempos – el mismo reloj – o, al menos, que existe una sincronización
previa que simula fehacientemente la unicidad de referencias.
36
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
38 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
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
40 Diseño
40
5 RESULTADOS
Todo lo que somos es el resultado de lo que hemos

pensado; está fundado en nuestros pensamientos y está
hecho de nuestros pensamientos.
- Buda -
E
n el presente capítulo se desarrollan distintos ejemplos observando las entradas y resultados obtenidos a
la vez que se evalúa el sistema verificando el cumplimiento de los objetivos marcados el capítulo de
Introducción.
5.1. Producto obtenido

Con el objeto de realizar pruebas de validación, situamos los sensores de luminosidad de la pareja de motas a
la distancia conocida de 10 cm, exigiendo los requisitos señalados en el apartado 1.3. En la figura 5-1
mostramos el detalle de la ubicación de las motas.
Figura 5-1. Detalle de ubicación de motas
41
42 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
5.2. Cumplimiento de objetivos

A continuación verificaremos el grado de cumplimiento de los objetivos planteados en el apartado 1.1.2. que
venían dados por:
a) Permitir una rápida instalación y desinstalación.

b) Alcanzar cualquier punto de la planta industrial.
El cumplimiento de ambos objetivos es inherente a la propia tecnología, por su carácter inalámbrico y

el reducido peso de las motas que requiere mínimos elementos de anclaje. No obstante, si las
dimensiones de la planta industrial exceden el alcance ZigBee, se replicaría la arquitectura cliente –
servidor conforme ya se indicó.
c) Realizar las mínimas exigencias al sistema previo, garantizando así la máxima generalidad.
Se ha exigido que:
o Exista una iluminancia mínima de 200 lux que debiera estar asegurada al ser inferior al
mínimo de 300 lux exigidos por el Instituto Nacional de Seguridad e Higiene en el Trabajo en
áreas industriales conforme a [31].
o La disposición entre cada pieza u objeto permita una distancia mínima sin sombra de 0,03 m.
De hecho, habitualmente es mayor para permitir la operatividad de los elementos
mecanizados o automatizados de la cadena industrial. Así, suponiendo una distribución
homogénea de los puntos de luz que garantice el requisito anterior, garantiza el cumplimiento
con independencia de la altura de la pieza.
o La velocidad del objeto entre las motas sea constante. Lo que puede estar asegurado por la
simple elección de ubicaciones y la mínima distancia entre motas.
Se trata, por tanto, de requisitos mínimos que, en esencia, no implican restricciones severas que supongan
pérdida de generalidad o aplicabilidad.
d) Reportar la velocidad y flujo de paquetes así como la longitud de éstos.
Queda evidenciada conforme al apartado anterior con las consideraciones realizadas.
e) Tener un coste inferior al 10% respecto de la opción de ampliar el número de sensores propios del
sistema de automatización, en caso de que ésta sea posible.
Considerando el ajustado coste de cada mota, de 42,95 EUR, así como la posibilidad de reutilización
en múltiples auditorías por cuanto son independientes de la red industrial previa y, especialmente, la
diferencia del coste de mano de obra por la facilidad de instalación de las motas teniendo en cuenta su
reducido tamaño y peso, resulta evidente que el coste total se reducirá de forma ostensible.
43
44 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 arte de sacar conclusiones suficientes a

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

El presente proyecto se ha enfocado con el objetivo de valorar un nuevo nicho de mercado para un sistema
microcontrolador que, por sus características concretas, ha tenido un desarrollo limitado en el ámbito de la
agricultura y que, sin caer en la obsolescencia, apenas se le estima un recorrido útil.
La duración del desarrollo técnico en sí no ha diferido respecto de proyectos similares. No obstante, la

prospección del mercado y la aplicación concreta sí han dilatado las expectativas temporales por cuanto se han
valorado diversos sectores para los que se realizaba una ardua labor de búsqueda y documentación que
finalmente no han tenido reflejo en el actual proyecto aunque sí han resultado muy enriquecedores por cuanto
el conocimiento generado.
De forma adicional, la elección final ha exigido una visión conjunta del tándem mercado – tecnología para
intentar alcanzar una hipotética frontera de posibilidades de la misma.
Ya habiendo seleccionado la aplicación, la primera dificultad ha sido la instalación y configuración del entorno
de desarrollo ya que, aunque existe amplia documentación del sistema operativo TinyOS, los componentes
concretos de la mota y su programación han exigido de la búsqueda de los drivers adecuados.
El aprendizaje de la tecnología y de su singular programación también ha requerido de pequeños desarrollos a

título formativo para testear el uso y adquisición de datos de los distintos sensores, comunicaciones y
capacidad de procesamiento del sistema microcontrolador.
45
46 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, la aplicación propuesta ha permitido intuir, a modo de frontera de posibilidades de producción, el

compromiso existente entre la funcionalidad deseada, en nuestro caso parametrizada por la frecuencia de
muestreo de las cintas transportadoras, y las limitaciones técnicas encabezadas por el consumo energético
mínimo de este tipo de sistemas.
6.3. Líneas de desarrollo

A continuación se relacionan posibles mejoras o líneas de desarrollo del proyecto que, con el mencionado
objetivo comercial, en ocasiones exceden del campo técnico abordado.
Así, con el objeto de optimizar aún más si cabe el rendimiento y posibilidades de nuestra aplicación
proponemos las siguientes mejoras:
- Añadir etiquetas RFID a una muestra de la población de objetos que circulan por las cintas
transportadoras e incluir en la mota un lector RFID con el objeto de obtener un trazado del camino
recorrido detectando tiempos de espera en cola, velocidades de procesos, etc.
- Incluir en la mota un circuito de bajo consumo que, en conjunción con el sensor de luminosidad,
implemente el efecto umbral, realizado actualmente mediante código, generando una interrupción,
con lo que se conseguiría una menor carga del sistema que revertiría en un consumo más ajustado y
una optimización de los tiempos de ejecución que, a su vez, mejoraría la precisión aumentando su
rango de uso.
- Opcionalmente, valorar una alternativa a nivel de sensores que permita registrar las magnitudes
requeridas sin exigir la duplicidad de motas.
46
- 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
48 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 wiring-check.xml

ident_flags.txt main.exe.out-1 main.srec tos_image.xml
o En la figura 7-1, incluimos el detalle de las instrucciones (destacadas en color azul) y

feedback recibido para compilar y cargar la aplicación en la Mota A cuyo descriptor, de
acuerdo al comando “motelist”, es “/dev/ttyUSB0”. (/dev/ttyUSB1 para la Mota B).
49
50 Apéndices
Setting up for TinyOS 2.1.1
asuarez@AP:~/Escritorio/MotaA$ make cou24 install,1

mkdir -p build/cou24
compiling MotaAAppC to a cou24 binary
ncc -o build/cou24/main.exe -Os -fnesc-separator=__ -Wall -Wshadow
-Wnesc-all -target=cou24 -fnesc-cfile=build/cou24/app.c -board= -
DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=100000 -
I/opt/tinyos-2.x/tos/lib/printf -DIDENT_APPNAME=\"MotaAAppC\" -
DIDENT_USERNAME=\"asuarez\" -DIDENT_HOSTNAME=\"AP\" -
DIDENT_USERHASH=0x71b77448L -DIDENT_TIMESTAMP=0x4fa2c6abL -
DIDENT_UIDHASH=0x440e8d5dL -fnesc-dump=wiring -fnesc-
dump='interfaces(!abstract())' -fnesc-
dump='referenced(interfacedefs, components)' -fnesc-
dumpfile=build/cou24/wiring-check.xml MotaAAppC.nc -lm
compiled MotaAAppC to build/cou24/main.exe
18518 bytes in ROM
1002 bytes in RAM
avr-objcopy --output-target=srec build/cou24/main.exe
build/cou24/main.srec
avr-objcopy --output-target=ihex build/cou24/main.exe
build/cou24/main.ihex
writing TOS image
tos-set-symbols build/cou24/main.srec build/cou24/main.srec.out-1
TOS_NODE_ID=1 ActiveMessageAddressC__addr=1
installing cou24 binary using dapa
avrdude -cdapa -U hfuse:w:0x99:m -pm1281 -U
efuse:w:0xff:m -C/etc/avrdude/avrdude.conf -U
flash:w:build/cou24/main.srec.out-1:a
avrdude: can't open device "/dev/parport0": No such file or
directory
avrdude: failed to open parallel port "/dev/parport0"
make: *** [program] Error 1
asuarez@AP:~/Escritorio/MotaA$ meshprog -t/dev/ttyUSB0 -

f./build/cou24/main.srec.out-1
using tty /dev/ttyUSB0
reading from file ./build/cou24/main.srec.out-1
sending ./build/cou24/main.srec.out-1 -> /dev/ttyUSB0
Opened file ./build/cou24/main.srec.out-1

Opened device /dev/ttyUSB0
..............,[i••&]
Starting transmission.
finished!
Figura 7-1.Compilación y carga de la aplicación en la mota A
50
- 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 /dev/ttyUSB0 Silicon Labs CP2102 USB to UART Bridge Controller
o Situados nuevamente en la carpeta MotaA, desde el terminal de gnome, procedemos a la

carga de la aplicación propiamente en la mota A. Para ello ejecutamos:
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:


..........................,[i••&]
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
52 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 main.exe main.ihex main.srec.out-2 wiring-check.xml

ident_flags.txt main.exe.out-2 main.srec tos_image.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

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


..........................,[i��&]
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
54 Apéndices
o A estos efectos, es necesario que la variable de entorno CLASSPATH incluya “tinyos.jar”

que se encuentra en la subcarpeta “lib”.
o O, conforme se ha indicado, en modo depuración, se podría compilar y ejecutar el código de
la aplicación PC haciendo uso del IDE Eclipse cuyo GUI representamos en la figura 7-2:
Figura 7-2. GUI de IDE de Eclipse
o Si la compilación se ha realizado correctamente, habrá generado un archivo de nombre

“PrintfSitWsn.class”
- Ejecución:
o En el mismo entorno tras su compilación, podemos ejecutarla mediante la instrucción:
java PrintfSitWsn.class
o En caso correcto, en la pantalla visualizaremos:
Thread[Thread-1,5,main]serial@/dev/ttyUSB0: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
Aplicación SitWsn:
- Compilación:
o No requiere compilación ya que consiste en un archivo de Microsoft Excel 2007 que
procesará, offline, la información contenida en el archivo reporte.csv generado por la
aplicación PC.
- Ejecución:
o Abrimos el archivo SitWsn.xlsm y procedemos a habilitar el uso de macros siguiendo las
instrucciones que la misma aplicación provee (véase figura 7-3).
Figura 7-3. Ayuda contextual de SitWsn.xlsm
o Tras ello, la aplicación muestra el siguiente aspecto (véase figura 7-4).
Figura 7-4. Pantalla principal de SitWsn.xlsm
o La descripción de cada campo identifica suficientemente su contenido que, no obstante,

aclararemos sobre un informe concreto. Continuamos pulsando en el botón “Actualizar” que
abre un cuadro de diálogo mostrado en la figura 7-5 donde seleccionar el archivo reporte.csv
55
56 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 se han fijado de acuerdo a las exigencias del sistema y a la información
contenida en los datasheets de cada sensor.
56
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
58 Apéndices
58
REFERENCIAS
[1] P. Ponsa y A. Granollers, «Diseño y automatización industrial,» [En línea]. Available:

http://www.epsevg.upc.edu/hcd/material/lecturas/interfaz.pdf.
[2] G. Lorenzo Lledó, «Automatización de una planta industrial,» [En línea]. Available:
https://rua.ua.es/dspace/bitstream/10045/10056/1/Suficiencia%20Gonzalo.pdf.
[3] P. R. y. otros, A Model for Types and Levels of Human Interaction with Automation, vol. 30, 2000.
[4] D. C. W., Design and Analysis of Integrated Manufacturing Systems, National Academies, 1988.
[5] S. R. S. .W, B. P. N y E. B. S., An automated handling system for soft compact shaped non-
rigidproducts, 1996.
[6] D. Nitzan y C. Rosen, Programmable Industrial Automation, 1976, pp. 1259 - 1270.
[7] P. Mirchandani, E. J. Lee y A. Vasquez, Concurrent Scheduling In Flexible Automation, vol. 2, 1988,
pp. 868 - 872.
[8] M. E., Autómatas programables: entorno y aplicaciones, Thomson Learning Ibero, 2005.
[9] F. Gómez-Esterm, «Automatización de sistemas de producción,» [En línea]. Available:

ttp://www.esi2.us.es/~fabio/TransASP.pdf.
[10] Universitat de Valencia, «Redes de comunicación industriales,» [En línea]. Available:

http://www.uv.es/rosado/courses/sid/Capitulo3_rev0.pdf.
[11] «AS-Interface,» 10 11 2014. [En línea]. Available: https://es.wikipedia.org/wiki/AS-interface.
[12] I. Electronic, «Sistema de bus AS-interface,» [En línea]. Available: https://www.ifm.com/obj/ifm_AS-

Interface_Catalogue_ES_08.pdf.
[13] R. Estepa y A. Estepa, «Comunicación Industriales Inalámbricas,» [En línea]. Available:

http://trajano.us.es/docencia/RedesLocalesEnLaIndustria/sld/RedesIndustriales6-5.pdf.
[14] «Auditoría de productividad,» [En línea]. Available: http://ipyc.net/organizacion-y-lean/organizacion-

industrial/auditoria-de-productividad.html.
[15] D. R. Arter, «Auditorías de calidad para mejorar la productividad,» 2003. [En línea]. Available:
http://depa.fquim.unam.mx/amyd/archivero/AUDITORIA_2646.pdf.
[16] «DOEET,» [En línea]. Available: http://doeet.com/what-is-doeet/implementation.
59
60 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ón de técnicas de localización basadas en redes de

sensores sobre tecnología Bluetooth,» [En línea]. Available:
http://bibing.us.es/proyectos/abreproy/11919/fichero/cap2_estado_arte.pdf.
[19] D. M. Archilla Córdoba y F. A. Santamaría Buitrago, «Estado del arte de las redes de sensores
inalámbricos,» 25 09 2013. [En línea]. Available:
http://revistas.udistrital.edu.co/ojs/index.php/tia/article/viewFile/4437/6856.
[20] «Wireless Sensor Network,» [En línea]. Available: http://www.mfbarcell.es/conferencias/wsn.pd.
[21] «List of wireless sensor nodes,» 28 3 2016. [En línea]. Available:

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

http://www.memsic.com/userfiles/files/Datasheets/WSN/6020-0055-05_a_mib600-t.pdf.
[24] M. O. Farooq y T. Kunz, «Operating Systems for Wireless Sensor Networks: A Survey,» [En línea].
Available:
https://www.researchgate.net/publication/51873411_Operating_Systems_for_Wireless_Sensor_Networ
ks_A_Survey.
[25] UOC, «Hardware COU 1 2,» [En línea]. Available:

http://cv.uoc.edu/app/mediawiki14/wiki/Hardware_COU_1_2.
[26] «Atmel ATmega640/V-1280/V-1281/V-2560/V-2561/V,» [En línea]. Available:

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

http://www.advancedphotonix.com/wp-content/uploads/PDV-P9003.pdf.
[28] «Low-Power Linear Active Thermistor ICs MCP9700/9700A MCP9701/9701A,» [En línea].
Available: http://ww1.microchip.com/downloads/en/DeviceDoc/21942e.pdf.
[29] «Omnipolar Detection Hall ICs,» [En línea]. Available:

http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/hall/bu52001gul-e.pdf.
[30] «TinyOS,» [En línea]. Available: http://tinyos.net/.
[31] INSHT, «Enciclopedia de salud y seguridad en el trabajo,» [En línea]. Available:

http://www.insht.es/InshtWeb/Contenidos/Documentacion/TextosOnline/EnciclopediaOIT/tomo2/46.p
df.
60

Estado Del Arte de Bandas Transportadoras PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estado Del Arte de Bandas Transportadoras PDF

Cargado por

Copyright:

Formatos disponibles

Proyecto Fin de Carrera

Autor: Antonio Suárez Reyes

Equation Chapter 1 Section 1

Dep. Ingeniería Electrónica

Sistema de información de tráfico en cintas

Dep. Ingeniería Electrónica

Autor: Antonio Suárez Reyes

Tutor: Daniel Gutiérrez Reina

Acuerdan otorgarle la calificación de:

El Secretario del Tribunal

Tabla 4–1. Software utilizado 27

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

Todo comienzo tiene su encanto.

1.1. Presentación del problema

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

1.2. Objetivos del proyecto

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

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

1.2.1. Descripción del problema

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

1.2.2. Objetivos de la solución

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

b) Alcanzar cualquier punto de la planta industrial.

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

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

1.4. Descripción estructurada del resto de la memoria

3. Análisis. Exponemos el enfoque del proyecto, condicionantes y criterios adoptados, detallando su

4. Diseño. Abordamos la tecnología utilizada, metodología de desarrollo, diagrama de componentes y

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

Lo que no se define, no se puede medir.

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

2.1.1 Automatización de procesos industriales

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.

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

- Integrar la gestión y producción.

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á

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

o Un ejemplo de este tipo de automatización son los PLC (Controladores lógicos

o Se reduce el tamaño de los lotes.

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

2.1.2 Tipos de cintas transportadoras

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

Figura 2-1. Roller conveyor

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

Figura 2-2. Skate-wheels conveyor

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

Figura 2-3. Belt conveyor

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

Figura 2-4. Chain conveyor

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

Figura 2-5. Slat conveyor

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

Figura 2-6. Overhead trolley conveyor