Controlador de balizamiento para turbinas...

CARRERA DE ESPECIALIZACIÓN ENSISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Controlador de balizamiento paraturbinas eólicas

Autor:Agustín Curcio Berardi

Director:Mg. Ing. Eric Pernia (UNQ, FIUBA)

Jurados:Esp. Ing. Edgardo Comas (CITEDEF)

Mg. Ing. Ramiro Alonso (FIUBA)Dr. Ing. Mariano Llamedo Soria (UTN-FRBA, FIUBA)

Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires,entre mayo de 2019 y abril de 2020.

III

Resumen

Este trabajo fue propuesto por la empresa Radiosistemas SRL como una soluciónde balizamiento para parques eólicos. El desarrollo es un controlador de

balizamiento que permite delimitar la extensión de obstáculos que puedenrepresentar un riesgo para la aeronavegabilidad.

Para la realización de este trabajo se aplicaron metodologías relacionadas con lagestión de proyectos, el desarrollo de aplicaciones utilizando sistemas

operativos de tiempo real, protocolos de comunicación, técnicas de testing desoftware y control de versiones distribuido.

V

Agradecimientos

A mis padres, Flavia y Víctor por comprenderme, apoyarme e impulsarme a sermejor persona y profesional.

A mis hermanos, María Sol y Federico por estar siempre.

A Soledad y Pablo Gomez por la revisión y correción de esta memoria.

A mi director Eric Pernia, por su buena predisposición, orientación, aportes ysupervisión durante la realización del presente trabajo.

A todos ellos, muchas gracias.

VII

Índice general

Resumen III

1. Introducción General 11.1. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Sistemas de balizamiento aéreo . . . . . . . . . . . . . . . . . 11.1.2. Normativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.3. Sistemas de balizamiento de referencia . . . . . . . . . . . . 3

1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introducción Específica 52.1. Bloques constitutivos del sistema . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Subsistema de monitoreo y control . . . . . . . . . . . . . . . 62.1.2. Subsistema de comunicación . . . . . . . . . . . . . . . . . . 62.1.3. Subsistema de sincronismo . . . . . . . . . . . . . . . . . . . 6

2.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1. Requerimientos de hardware . . . . . . . . . . . . . . . . . . 62.2.2. Requerimientos de software . . . . . . . . . . . . . . . . . . . 7

2.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.1. Etapas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2. Desgloce de tareas . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3. Entregables del proyecto . . . . . . . . . . . . . . . . . . . . . 9

3. Diseño e Implementación 133.1. Desarrollo de hardware . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1. Plataforma de desarrollo . . . . . . . . . . . . . . . . . . . . . 133.1.2. Arquitectura de hardware . . . . . . . . . . . . . . . . . . . . 133.1.3. Microcontrolador y periféricos asociados . . . . . . . . . . . 153.1.4. Receptor GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.5. Capa física Ethernet . . . . . . . . . . . . . . . . . . . . . . . 203.1.6. Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . 213.1.7. Salidas de alarma . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.8. Diseño del circuito impreso . . . . . . . . . . . . . . . . . . . 22

3.2. Desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2. Tareas del sistema . . . . . . . . . . . . . . . . . . . . . . . . 273.2.3. Servidor web embebido . . . . . . . . . . . . . . . . . . . . . 283.2.4. Sincronismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.5. Control de baliza y alarmas . . . . . . . . . . . . . . . . . . . 343.2.6. Interfaz gráfica y teclas frontales . . . . . . . . . . . . . . . . 36

VIII

4. Ensayos y Resultados 394.1. Pruebas de hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2. Pruebas de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1. Pruebas estáticas . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2. Ensayos de estabilidad del servidor web . . . . . . . . . . . 404.2.3. Ensayos de utilización del procesador . . . . . . . . . . . . . 41

4.3. Ensayos de retrocompatibilidad . . . . . . . . . . . . . . . . . . . . . 43

5. Conclusiones 475.1. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Bibliografía 49

IX

Índice de figuras

1.1. Sistema de balizamiento aéreo. . . . . . . . . . . . . . . . . . . . . . 21.2. Balizamiento de turbinas eólicas. . . . . . . . . . . . . . . . . . . . . 3

2.1. Subsistemas del controlador. . . . . . . . . . . . . . . . . . . . . . . . 52.2. Diagrama AON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3. Diagrama de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1. Plataforma de desarrollo LPCXpresso. . . . . . . . . . . . . . . . . . 143.2. Arquitectura del equipo. . . . . . . . . . . . . . . . . . . . . . . . . . 143.3. Esquemático del CPU. . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4. Esquemático de la memoria EEPROM. . . . . . . . . . . . . . . . . . 163.5. Esquemático del receptor GPS. . . . . . . . . . . . . . . . . . . . . . 173.6. Microstrip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.7. Conductor-backed coplanar waveguide. . . . . . . . . . . . . . . . . 193.8. Esquemático PHY Ethernet. . . . . . . . . . . . . . . . . . . . . . . . 203.9. Esquemático salida analógica de alarma. . . . . . . . . . . . . . . . . 223.10. Esquemático salida digital de alarma. . . . . . . . . . . . . . . . . . 223.11. Capa frontal de cobre del PCB. . . . . . . . . . . . . . . . . . . . . . 233.12. Capa posterior de cobre del PCB. . . . . . . . . . . . . . . . . . . . . 233.13. Imagen renderizada de la placa. . . . . . . . . . . . . . . . . . . . . . 243.14. Fotografía de la placa terminada. . . . . . . . . . . . . . . . . . . . . 243.15. Arquitectura de capas. . . . . . . . . . . . . . . . . . . . . . . . . . . 253.16. Patrón observar y actuar. . . . . . . . . . . . . . . . . . . . . . . . . . 263.17. Patrón segmentación de proceso. . . . . . . . . . . . . . . . . . . . . 263.18. Diagrama de tareas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.19. Diagrama UML de AJAX. . . . . . . . . . . . . . . . . . . . . . . . . 303.20. Vista de monitoreo del equipo. . . . . . . . . . . . . . . . . . . . . . 313.21. Vista de configuración del equipo. . . . . . . . . . . . . . . . . . . . 313.22. Ventana emergente de alarmas. . . . . . . . . . . . . . . . . . . . . . 323.23. Estado de módulos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.24. Señales involucradas en el sincronismo. . . . . . . . . . . . . . . . . 333.25. Diagrama de flujo sincronismo. . . . . . . . . . . . . . . . . . . . . . 343.26. Diagrama de flujo del control de baliza. . . . . . . . . . . . . . . . . 353.27. Diagrama de la MEF del menú. . . . . . . . . . . . . . . . . . . . . . 363.28. Pantallas del controlador. . . . . . . . . . . . . . . . . . . . . . . . . 373.29. Diagrama de la MEF del antirrebote. . . . . . . . . . . . . . . . . . . 37

4.1. Evolución del heap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2. Utilización del procesador. . . . . . . . . . . . . . . . . . . . . . . . . 424.3. Diagrama en bloques del ensayo de retrocompatibilidad. . . . . . . 434.4. Diagrama temporal de señales de sincronismo actual. . . . . . . . . 444.5. Diagrama temporal del sincronismo de ambos equipos. . . . . . . . 444.6. Diferencia temporal entre las señales de sincronismo. . . . . . . . . 45

X

4.7. Diferencia temporal entre las señales de sincronismo post optimi-zación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.8. Diferencia temporal final de las señales de sincronismo. . . . . . . . 46

XI

Índice de Tablas

1.1. Comparación de distinas soluciones de balizamiento. . . . . . . . . 4

2.1. División del trabajo en etapas. . . . . . . . . . . . . . . . . . . . . . . 8

3.1. Impedancia característica del microstrip. . . . . . . . . . . . . . . . . 183.2. Impedancia característica de la línea CBCPW. . . . . . . . . . . . . . 19

4.1. Resultados del análisis estático. . . . . . . . . . . . . . . . . . . . . . 404.2. Resultados del análisis de cobertura. . . . . . . . . . . . . . . . . . . 40

1

Capítulo 1

Introducción General

En este capítulo se hace un acercamiento general al balizamiento de estructuras,las normativas que regulan la actividad y el estudio de soluciones ya disponiblesen el mercado. Finalizado este análisis, se definen los alcances y objetivos deltrabajo.

1.1. Descripción del problema

A medida que la economía global se interconecta cada vez más, la industria dela aviación es uno de los sectores que más crecimiento está experimentando. Soloen el año 2018, las aerolíneas comerciales transportaron cerca de 4,3 billones depasajeros [1]. Aún más impresionante es la estadística de accidentes, ya que enel mismo período se registraron 98 aeronaves accidentadas [1]. Si se relaciona lacantidad de accidentes con el número total de vuelos, se obtiene que por cadamillón de partidas solamente 2,6 estuvieron involucradas en algún tipo de inci-dente. Estos números se lograron gracias a la colaboración y trabajo coordinadode agentes reguladores, fabricantes, sindicatos e institutos de investigación paragenerar normativas que tiendan a mejorar la seguridad continuamente. De estamanera, para garantizar un uso eficiente y seguro del espacio aéreo, se ha dis-puesto el señalamiento o iluminación de objetos con el fin de reducir el peligropara las aeronaves, sin imponer limitaciones de operación por su presencia.

1.1.1. Sistemas de balizamiento aéreo

Los sistemas de balizamiento permiten señalizar distintos tipos de obstáculos enbase a distintas características, como su forma, extensión y altura. En líneas gene-rales, todos están compuestos por dos componentes principales.

Baliza: es una luminaria que se expone por sobre el nivel del terreno para in-dicar la presencia de un obstáculo. Existen de varios colores e intensidadesde acuerdo con el tipo de objeto a señalizar.

Controlador: este equipo se encarga de gestionar el correcto funcionamien-to de la baliza. Tendrá distintas funcionalidades según el tipo de baliza yobstáculo que se debe iluminar. También suele referirse a este equipo comoUnidad de Control de Lámpara Apagada (UCLA) según las disposiciones[2] de la Administración Nacional de Aviación Civil (ANAC). A lo largo deeste documento se encontrarán ambas denominaciones indistintamente.

En la figura 1.1 se muestra un sistema de balizamiento con sus componentes prin-cipales.

2 Capítulo 1. Introducción General

FIGURA 1.1: Sistema de balizamiento aéreo.

1.1.2. Normativa

A nivel global, la Organización de Aviación Civil Internacional (OACI) es la agen-cia de la Organización de las Naciones Unidas (ONU) encargada de estudiar losproblemas de la aviación civil internacional y promover los reglamentos y nor-mas en la aeronáutica mundial. En el Anexo 14 al Convenio sobre Aviación CivilInternacional [3] se establecen los tipos de baliza, su disposición en el obstáculo apartir de parámetros como su altura, extensión, cercanía a aeródromos, etc.

Por otro lado, cada una de los países miembros de la ONU cuenta con una agenciagubernamental encargada de regular la aviación civil dentro de su espacio aéreo.Resulta de interés el caso de Estados Unidos, cuyo ente de gobierno encargadode esta tarea es la Federal Aviation Administration (FAA). La FAA emite regular-mente publicaciones denominadas Advisory Circular (AC), que proporcionan unaguía para certificar que el equipamiento no resulta un peligro para la aeronave-gabilidad. La AC 150/5345-43J [4] determina las especificaciones de los sistemasde balizamiento, mientras que la AC 70/7460-1L [5] representa el estándar pa-ra señalizar e iluminar obstrucciones que han sido identificadas como un peligropara el espacio aéreo navegable. Ambas circulares son utilizadas a lo largo de estetrabajo para justificar decisiones de diseño.

En la Argentina, la ANAC es la autoridad aeronáutica máxima encargada de nor-mar, regular y fiscalizar la aviación civil en el país. Este organismo ha publica-do las Regulaciones Argentinas de Aviación Civil (RAAC), que representan unaadaptación local de la normativa internacional [3] con la incorporación de aspec-tos definidos previamente por la FAA en [4] y [5].

Con el objeto de plasmar las normas anteriormente detalladas en un caso práctico,en la figura 1.2 se muestra un diagrama que define la forma correcta de señalizaruna turbina eólica o aerogenerador de acuerdo con [2]. Si bien el tipo de baliza-miento dependerá de su altura, se incluye el caso de uso que aplicaría a la mayorparte de los parques eólicos instalados en el país.

1.1. Descripción del problema 3

Balizas de media intensidad tipo B (OACI)

o FAA tipo L-864

Turbina eólica con una altura superior a 150 metros

NOTA: La altura de la turbina eólica se determi-na desde la parte superior del rotor mientras está en el punto muerto superior.

FIGURA 1.2: Balizamiento de turbinas eólicas.

1.1.3. Sistemas de balizamiento de referencia

Se han identificado varios sistemas de balizamiento aéreo que fueron tomados co-mo referencia a la hora de desarrollar este trabajo. Casi todos ellos son productosofrecidos por empresas extranjeras, mayoritariamente de origen europeo o nor-teamericano, y representan el “estado del arte” de la industria. Por otro lado, enLatinoamérica existen pocas empresas que comercialicen productos homologa-dos de producción local. En Argentina, en particular, la empresa RadiosistemasSRL cuenta con una solución especialmente diseñada para ser instalada en aero-generadores.

En la tabla 1.1 se realiza una comparación entre distintos sistemas de referencia.

4 Capítulo 1. Introducción General

TABLA 1.1: Comparación de distinas soluciones de balizamiento.

Modelo FTS 370d CIP400-XX RTCH864P

Fabricante Flash Technology Orga BV Radiosistemas SRLAlarmas Contacto seco, Modbus Contacto seco, Modbus Contacto secoSincronismo GPS GPS GPSConectividad WiFi, Ethernet, LTE Ethernet N/AInterfaz LCD de caracteres LCD de caracteres LCD de caracteresMonitoreo Webserver Webserver N/A

1.2. Motivación

Si bien la comparación realizada en la tabla 1.1 considera características genera-les, se puede evidenciar a simple vista que el controlador disponible localmenteno cuenta con algunas funciones que sí son soportadas por fabricantes extranje-ros. En consecuencia, este trabajo fue una propuesta de Radiosistemas SRL paramodernizar su equipo actual, incorporando funcionalidades que se encuentranen falta y volverlo una opción competitiva en el mercado.

1.3. Objetivos y alcance

1.3.1. Objetivos

El objetivo de este trabajo consistió en modernizar la placa controladora de laUCLA modelo RTCH864P de la empresa Radiosistemas SRL. El equipo diseñadopermite realizar un monitoreo en tiempo real de éste, ofrece una experiencia deusuario superior y amplía las capacidades de interconexión con otros sistemas.

1.3.2. Alcance

El trabajo realizado se encontró acotado al siguiente alcance:

Diseño de una nueva placa controladora a partir de las dimensiones físicasde la placa con número de parte 2001240, comercializada por la empresaRadiosistemas SRL.

Desarrollo del software que se ejecutará sobre el sistema embebido, así co-mo también la interfaz web que permite monitorear el equipo de maneraremota.

Fabricación de un prototipo funcional.

Validación del hardware y software a través de pruebas funcionales de la-boratorio.

Por otro lado, quedan fuera del alcance de este trabajo:

Diseño de placa e interfaces de potencia requeridas para el encendido yapagado de una baliza.

Diseño de interfaces mecánicas, ensamblajes o gabinetes para el nuevo equi-po.

5

Capítulo 2

Introducción Específica

En este capítulo se presenta el dispositivo diseñado a través de la descripción desus bloques constitutivos. Se exponen los requerimientos que debe cumplir, asícomo la planificación de su desarrollo.

2.1. Bloques constitutivos del sistema

Durante el desarrollo del equipo se diseñaron subsistemas responsables por unconjunto de funciones básicas. Cada uno de ellos está conformado por módulosde software y hardware. El controlador puede dividirse entonces en tres subsis-temas principales:

Subsistema de monitoreo y control.

Subsistema de comunicación.

Subsistema de sincronismo.

En la figura 2.1 se muestran todos ellos. Cada uno incorpora una o más tareasagrupadas de acuerdo con la función que cumplen. Por otro lado, como es nece-sario compartir el acceso a un único recurso de procesamiento, todas las tareascorren sobre un Real-Time Operating System (RTOS). Éste se encarga de asignartiempos de ejecución a todas ellas en base a eventos asíncronos y un esquema deprioridades predefinido. Para este trabajo se decidió adoptar FreeRTOS [6] comosistema operativo de tiempo real ya que es una biblioteca de software que ocupapoco tamaño, es de fácil implementación y cuenta con amplio soporte debido asu popularidad.

Subsistema demonitoreo y control

Subsistema decomunicación

Subsistema desincronismo

RTOS

Placa de control

FIGURA 2.1: Bloques funcionales del controlador.

6 Capítulo 2. Introducción Específica

2.1.1. Subsistema de monitoreo y control

Este bloque funcional se encarga de controlar el encendido y apagado de la balizaa una tasa de destello constante. Dicha tasa de destello se especifica mediante unaunidad conocida como flashes per minute (FPM). Por otro lado, este subsistemase ocupa de monitorear continuamente las principales variables de estado delequipo para generar acciones según se lo necesite. Por ejemplo, en caso de queno se detecte consumo de corriente en la salida de baliza, se deberá generar unaalarma, la cual se reflejará en las salidas a relé y en las interfaces del subsistemade comunicación.

2.1.2. Subsistema de comunicación

En líneas generales, el subsistema de comunicación permite que el usuario in-teractúe con el equipo. Éste está conformado por un servidor web embebido, undisplay gráfico con botones para navegar a través de la interfaz de usuario y untransceiver RS-485 para el reporte de alarmas que utiliza el protocolo Modbus.

Para poder implementar el servidor web, se requirió utilizar un stack TCP/IP losuficientemente pequeño como para que pudiera ser integrado dentro de un sis-tema embebido. Uno de los stacks que cumple con este requisito es Lightweight IP(lwIP) [7]. Ésta fue la solución adoptada por contar con varios ejemplos disponi-bles en internet que son ofrecidos por los mismos fabricantes de microcontrola-dores.

2.1.3. Subsistema de sincronismo

El subsistema de sincronismo es el responsable de producir la señal de destellode baliza. Mediante una conexión serie a un receptor GPS, el equipo es capazde obtener una referencia temporal absoluta procesando las tramas NMEA 0183.Sin embargo, para garantizar que cada equipo genere una señal sincrónica, esnecesario conocer el momento exacto en el que cada segundo comienza. Por estemotivo, se procesa la señal pulse per second (PPS), convenientemente configuradacomo una salida del receptor GPS. La señal PPS es generada a partir de relojesatómicos, por lo que su exactitud ronda el orden de los nanosegundos.

2.2. Requerimientos

Los requerimientos del trabajo fueron clasificados en requerimientos de hard-ware y software. A su vez, se clasificaron en tres categorías dependiendo de suprioridad.

2.2.1. Requerimientos de hardware

Alta prioridad

1. El controlador deberá contar con un único microcontrolador que eje-cute todas las tareas de éste para reducir su complejidad y lograr uncosto más competitivo.

2.2. Requerimientos 7

2. Se implementará un display gráfico con una resolución mínima de240x320 píxeles con múltiples pantallas de navegación. Adicionalmen-te, se deberá integrar un teclado mínimo para que el usuario puedanavegar a través de ellas.

3. Se deberá incorporar un receptor GPS que utilice el chipset QualcommSiRFstar IV para maximizar la retrocompatibilidad con los equiposexistentes. Además, se adicionará la electrónica que garantice que unaantena GPS activa funcione correctamente.

4. Será necesario incorporar una interfaz Ethernet para dar soporte a lasfunciones de monitoreo remoto.

5. Se requiere la instalación de la electrónica necesaria para soportar lainterfaz Modbus RS-485.

6. Será necesario adicionar una salida de alarma mediante contacto secopara determinar si se ha producido un corte de energía.

7. El sistema deberá cumplir con los requisitos aplicables de la SubparteF de [2] y del Capítulo 3 de [4].

Media prioridad

8. Toda la lógica de control deberá utilizar una tensión de alimentaciónde 3,3 VDC.

Baja prioridad

9. Se deberá monitorear el consumo de la antena GPS activa para facilitarel diagnóstico y consecuente resolución de problemas de sincronismo.

2.2.2. Requerimientos de software

Alta prioridad

1. El software utilizará un sistema operativo de tiempo real para sincro-nizar y ejecutar todas las funciones del equipo.

2. La lógica por la cual se encienden y apagan las balizas deberá ser lamisma que se viene utilizando en los equipos actuales. De esta maneraserá posible que la nueva generación de controladores sea compatiblecon la ya existente.

3. Se necesitará incorporar un servidor web embebido para monitorearde forma remota el equipo. Deberá tener un diseño claro y minimalistaque permita a un operador conocer fácilmente el estado del equipo encualquier momento.

4. Se requerirá que el equipo genere alarmas ante fallas en su funciona-miento.

5. Las alarmas activas deberán ser comunicadas al usuario mediante laactivación de salidas comandadas por relés.


Media prioridad

6. En caso de que se cuente con otros medios de comunicación con elusuario, también deberán notificarse las alarmas activas por dichos ca-nales.

7. Se utilizarán bloques de código que sean modulares y portables paramaximizar su reutilización en otros proyectos.

8. Se implementará control de versiones y herramienta de documenta-ción del código.

Baja prioridad

9. La interfaz de usuario del display gráfico deberá diseñarse para serintuitiva y de fácil utilización.

2.3. Planificación

2.3.1. Etapas del proyecto

Para cumplir con todas las tareas vinculadas al desarrollo de este trabajo de acuer-do con el cronograma de la Carrera de Especialización en Sistemas Embebidos(CESE), se confeccionó una planificación completa en el marco de la materia Ges-tión de Proyectos.

Inicialmente se dividió el proyecto en varias etapas. Asimismo, cada una de ellasse descompuso en tareas a las que se les asignó una duración en horas y un ór-den que se debe respetar para cumplir con el cronograma pautado. La tabla 2.1muestra la duración estimada de cada etapa, que totaliza 595 horas de trabajodistribuidas en jornadas laborables de 16 horas semanales.

TABLA 2.1: Etapas del trabajo realizado.

Etapa Duración estimada

Planificación del proyecto 40 horasInvestigación preliminar 70 horasSelección de plataforma y bibliotecas 20 horasDesarrollo de hardware 130 horasDesarrollo de software 185 horasIntegración del sistema 40 horasProcesos de cierre 110 horas

Resalta a simple vista que solo las tareas de desarrollo de software y hardwarerepresentan aproximandamente el 53% de la carga de trabajo total. Esto tieneque ver con que son etapas de trabajo intensivo, donde se requiere una revisióncontinua de los avances y especial atención para no cometer errores.

2.3.2. Desgloce de tareas

Cada una de las etapas descriptas en la sección anterior fueron a su vez desglo-sadas en múltiples tareas. Se evaluaron las relaciones de dependencia entre cadauna de ellas y se las ordenó en consecuencia.

2.3. Planificación 9

Para estimar la duración total del proyecto se requirió asignar una duración enhoras a cada tarea y plasmar los resultados obtenidos en herramientas gráficasde gestión de proyectos. En la figura 2.2 se muestra el diagrama Activity-on-Node(AON), donde las tareas se relacionan entre sí mediante flechas y se incluye su du-ración. Esta herramienta permite identificar el camino crítico, el cual representa lasucesión de tareas que mayor tiempo demandan para su finalización. Es relevanteconocer las tareas que se encuentran dentro de dicho camino ya que una demora,en alguna de ellas, provocará indefectiblemente un atraso en el cronograma delproyecto; salvo que se tomen medidas correctivas para evitarlo.

Restan por definir las fechas exactas de inicio y fin de cada una de las tareas. Eldiagrama de Gantt es el recurso utilizado para definir dichas fechas y estimar lafecha de finalización del proyecto. Este digrama se puede apreciar en la figura2.3.

2.3.3. Entregables del proyecto

En común acuerdo con el cliente, se han definido los siguientes ítems como partede los entregables del proyecto.

Prototipo de la placa controladora.

Diagrama esquemático del hardware.

Archivos de fabricación del circuito impreso.

Código fuente del controlador.


INICIO24/06/2019

1.1 Plan de proyecto

t = 20

1.2 Análisis defactibilidad

t = 10

1.3 Gestión de calidad

t = 10

2.1 Búsquedainformación stack

TCP/IP

t = 20

2.2 Búsquedainformación web

servers embebidos

t = 20

2.3 Búsquedainformación protocolo

Modbus

t = 20

2.4 Búsquedainformación display

gráfico

t = 10

3.1 Selección deplataforma embebida

t = 10

3.2 Selección driversde bajo nivel y

bibliotecas

t = 10

4.1 Diseño decomponentes

faltantes en CAD PCB

t = 10

4.2 Diseño dediagrama

esquemático

t = 20

4.3 Diseño de circuitoimpreso

t = 40

4.4 Fabricación decircuito impreso

t = 40

4.5 Ensamblado deprototipo

t = 10

4.6 Pruebas yverificación

t = 10

5.1 Desarrollobibliotecas de display

t = 20

5.2 Desarrollobibliotecas de teclado

t = 10

5.3 Desarrollobibliotecas para

implementar stackTCP/IPt = 25

5.4 Desarrollobibliotecas

comunicaciónModbus

t = 25

5.5 Desarrollo webserver /aplicación

web

t = 20

5.6 Desarrollobibliotecas manejo de

datos NMEA 0183

t = 25

5.7 Pruebasfuncionales de cada

módulo

t = 20

5.8 Corrección deerrores

t = 10

5.9 Integración detodas las tareas al

RTOS

t = 30

6.1 Integración defirmware a circuito

impreso

t = 20

6.2 Pruebasfuncionales del

sistema

t = 10

6.3 Corrección deerrores

t = 10

7.1 Confección delmanual de usuario

t = 20

7.2 Redacción dememoria de proyecto

t = 60

7.3 Confección deinforme de avance

t = 10

7.4 Elaboración depresentación final

t = 20

FIN01/03/2020

Referencias

Planificación del proyecto

Investigación preliminar

Selección de plataforma ybibliotecas Integración del sistema

Desarrollo de software

Desarrollo de hardware Procesos de cierre

Camino crítico

FIGURA 2.2: Diagrama AON.

2.3. Planificación 11

2019

, Ctr

320

19, C

tr 4

2020

, Ctr

1

jul

ago

sep

oct

nov

dic

ene

5.8

Cor

recc

ión

de e

rror

es

5.7

Pru

ebas

func

iona

les

de c

ada

mód

ulo

5.6

Des

arro

llo b

iblio

teca

s m

anej

o de

dat

os N

MEA

018

3

5.5

Des

arro

llo w

eb s

erve

r / a

plic

ació

n w

eb

5.4

Des

arro

llo b

iblio

teca

s co

mun

icac

ión

Mod

bus

5.3

Des

arro

llo b

iblio

teca

s pa

ra s

tack

TCP

/IP

5.2

Des

arro

llo b

iblio

teca

s de

tecl

ado

5.1

Des

arro

llo b

iblio

teca

s de

dis

play

5.

Des

arro

llo d

e so

ftw

are

4.6

Pru

ebas

y v

eri�

caci

ón

4.5

Ens

ambl

ado

de p

roto

tipo

4.4

Fab

ricac

ión

de c

ircui

to im

pres

o

4.3

Dis

eño

de c

ircui

to im

pres

o

4.2

Dis

eño

de d

iagr

ama

esqu

emát

ico

4.1

Dis

eño

de c

ompo

nent

es fa

ltant

es d

e CA

D P

CB

4.

Des

arro

llo d

e ha

rdw

are

3.2

Sel

ecci

ón d

river

s de

baj

o ni

vel y

bib

liote

cas

3.1

Sel

ecci

ón d

e pl

ataf

orm

a em

bebi

da

3.

Sele

cció

n de

pla

tafo

rma

y bi

blio

teca

s

2.4

Bús

qued

a in

form

ació

n di

spla

y gr

á�co

2.3

Bús

qued

a in

form

ació

n pr

otoc

olo

Mod

bus

2.2

Bús

qued

a in

form

ació

n w

eb s

erve

r

2.1

Bús

qued

a in

form

ació

n st

ack

TCP/

IP

2. I

nves

tigac

ión

prel

imin

ar

1.3

Ges

tión

de c

alid

ad

1.2

Aná

lisis

de

fact

ibili

dad

1. P

lani

�cac

ión

del p

roye

cto

2020

, Ctr

2

feb

mar

abr

7.4

Ela

bora

ción

de

pres

enta

ción

�na

l

7.3

Con

fecc

ión

de in

form

e de

ava

nce

7.2

Red

acci

ón d

e m

emor

ia d

e pr

oyec

to

7.1

Con

fecc

ión

del m

anua

l de

usua

rio

7.

Proc

esos

de

cier

re

5.9

Int

egra

ción

de

toda

s la

s ta

reas

al R

TOS

6. I

nteg

raci

ón d

el s

iste

ma

6.1

Int

egra

ción

de

�rm

war

e a

circ

uito

impr

eso

6.2

Pru

ebas

func

iona

les

del s

iste

ma

6.3

Cor

recc

ión

de e

rror

es

Fech

a In

icio

24/0

6/20

19

Fech

a Fi

naliz

ació

n01

/03/

2020

FIGURA 2.3: Diagrama de Gantt.

13

Capítulo 3

Diseño e Implementación

El presente capítulo describe el diseño y la forma en que fueron implementadoslos subsistemas definidos en el capítulo 2. Asimismo, se comentan los problemasencontrados durante su desarrollo y las decisiones de ingeniería tomadas pararesolverlos.

3.1. Desarrollo de hardware

Durante las etapas de planificación e investigación preliminar, se evidenció quepara cumplir con el cronograma de la CESE y los objetivos del cliente de formaexitosa, el desarrollo del hardware y software requerirían de gran parte de losrecursos disponibles. Si bien es posible utilizar módulos autocontenidos para es-cribir software de manera eficiente, generalmente es un trabajo hecho a la medidade la aplicación que se busca desarrollar. Asimismo, el lector podría pensar quelo mismo aplica al diseño de hardware sin temor a equivocarse. Si bien esto escierto, una vez resueltos los pormenores de la implementación, es muy simplecrear módulos de hardware que sean reutilizables. Bajo este criterio, se optó porusar una plataforma de desarrollo que contara con los módulos necesarios y asíevitar errores o posibles retrabajos.

3.1.1. Plataforma de desarrollo

Se decidió utilizar como plataforma de desarrollo el kit LPCXpresso, compuestopor las placas LPC1769 LPCXpresso y LPCXpresso Base Board. Éste fue diseña-do por NXP Semiconductors junto con Embedded Artists como una solución quepermite realizar prototipos rápidamente. La LPC1769 monta un microcontroladorcon procesador ARM Cortex-M3. Adicionalmente, la placa integra un circuito in-tegrado de capa física Ethernet de alto rendimiento. Por otro lado, la Base Boardcuenta con todos los componentes que pueden ser requeridos durante el desa-rrollo de un prototipo; esto es: botones, LEDs, encoders y transceivers por nombrarsolamente algunos. En la figura 3.1 se puede observar una fotografía de la placaLPC1769 montada sobre la Base Board.

3.1.2. Arquitectura de hardware

Una vez realizada la elección del procesador, fue posible diagramar la arquitectu-ra general del hardware del equipo. Esto permite conocer todos los módulos queserán necesarios y analizar las relaciones que existen entre cada uno de ellos. Enla figura 3.2 se observa un diagrama en bloques donde se especifica qué bloquespertenecen a cada subsistema y cómo se relacionan entre sí.

14 Capítulo 3. Diseño e Implementación

FIGURA 3.1: LPC1769 LPCXpresso instalada en la placa BaseBoard.

Microcontrolador

Sensores decorriente

Receptor GPS Sensor de luzambiental

Salidas de alarma(contacto seco)

Salidas de baliza(etapa de potencia)

Display y teclado

Ethernet

Salidas de alarma(Modbus)

Placa decontrol

Placa depotencia




RTOS

FIGURA 3.2: Arquitectura de hardware del equipo.

3.1. Desarrollo de hardware 15

3.1.3. Microcontrolador y periféricos asociados

El sistema de procesamiento se basa en el microcontrolador LPC1769FBD100 co-mercializado por NXP Semiconductors. Posee un procesador ARM Cortex-M3 de32 bits y arquitectura Harvard. Adicionalmente cuenta con 512 kB de memoriaFlash, 64 kB de memoria RAM y varios periféricos, como un controlador MACEthernet, cuartro UARTs, dos controladores SPI, dos controladores I2C, un ADCde ocho canales con 12 bits de precisión, varios GPIOs, etc. En la figura 3.3 semuestra el diagrama esquemático correspondiente al CPU del equipo. Se puedeobservar que existen varios jumpers (marcados como JP1, JP2, JP3 y JP4) utilizadoscomo puntos de prueba durante el proceso de diseño.

FIGURA 3.3: Diagrama esquemático del CPU.

Una característica que no se ha mencionado aún es que los procesadores de la fa-milia Cortex-M se encuentran optimizados para ejecutar un RTOS eficientemente.


Por este motivo, al haber seleccionado un procesador de esta gama de productos,se asegura el cumplimiento del requerimiento de hardware número 1.

Por otro lado, se incorporó un componente auxiliar que facilitará la puesta enmarcha del equipo durante la etapa de producción. Se trata de una memoriaEEPROM de 256 Kbit, donde se podrán almacenar parámetros predefinidos; porejemplo: número de parte, número de serie, dirección MAC, dirección IP, etc. Elgrabado de dicha memoria podría realizarse de forma independiente al resto delproceso productivo, lo que brinda mayor versatilidad en caso de que así se lorequiera. En la figura 3.4 se aprecia el esquema de conexión de la memoria.

FIGURA 3.4: Diagrama esquemático de la memoria EEPROM.

3.1.4. Receptor GPS

Durante la etapa de investigación se identificaron varios receptores GPS que po-drían adaptarse al equipo. Sin embargo, la búsqueda se vio en gran medida li-mitada por el requerimiento de hardware número 3. El chipset SiRFstar IV es unasolución de navegación que cuenta con un procesador ARMv7 integrado. Adicio-nalmente, dispone del hardware de radiofrecuencia (RF) necesario para demodu-lar la señal GPS (LNA, filtro SAW, sintetizador, ADC, etc.). Posee alta sensibilidad(-160 dBm) y capacidad para rastrear hasta 48 canales simultáneamente.

No obstante, todavía resta satisfacer el requerimiento de hardware número 8. Laforma usual de medir el consumo en una antena activa consiste en conectar unaresistencia de bajo valor (shunt) en serie con la línea de antena. Así, se provocauna pequeña diferencia de potencial sin afectar al resto del circuito. Esta pequeñacaída de tensión puede ser amplificada cientos o miles de veces con un amplifi-cador operacional hasta obtener un valor que sea interpretable por el conversoranalógico-digital (ADC) del microcontrolador. Si bien es una solución perfecta-mente válida, se deben incorporar más componentes, lo cual incrementaría lacomplejidad del circuito.

La filosofía de este trabajo consiste en buscar soluciones simples para maximi-zar sus chances de éxito. Por esta razón, se seleccionó el receptor RXM-GPS-R4fabricado por Linx Technologies. Este módulo, además de requerir una cantidadmínima de componentes externos, provee en uno de sus contactos un nivel de


tensión que indica si la etapa de RF se encuentra en funcionamiento o no. En con-secuencia, se puede saber si la antena está conectada al receptor muy fácilmentey sin necesidad de adaptar señales. Otra cualidad particularmente útil es la posi-bilidad de generar tramas NMEA 0183 a una frecuencia de 5 Hz, lo que mejorala precisión de los datos obtenidos. En la figura 3.5 se exhibe el circuito completodel receptor.

FIGURA 3.5: Diagrama esquemático del receptor GPS junto consus componentes asociados.

Asimismo se puede observar que la conexión entre el conector de antena (J3) yel receptor GPS (U4) se realiza mediante una línea de transmisión. Esto se debe aque, en radiofrecuencia, las señales pueden moverse de un lugar a otro a travésde antenas o guías de onda. En el caso de las antenas, el campo electromagné-tico se irradia al espacio, mientras que en las guías de onda, éste se encuentraconfinado dentro de un área a lo largo de un camino dado. La línea de transmi-sión es un caso particular de guía de onda, la cual consiste en una configuraciónespecífica de metal y material dieléctrico para dirigir una señal a lo largo de uncamino deseado. Las líneas de transmisión más empleadas en circuitos impresosutilizan como mínimo dos conductores (señal y masa) y un dieléctrico (sustratodel circuito impreso).

Durante este trabajo fue necesario analizar las líneas de transmisión posibles yseleccionar la que mejor se adaptara a las condiciones del trabajo. Es un procesoiterativo, que consiste en realizar aproximaciones sucesivas usando aplicacionesespecialmente desarrolladas para tal fin. De este modo, es posible calcular lascaracterísticas constructivas de la línea, su impedancia característica y otros pará-metros. Durante este proceso, se utilizó la herramienta AppCAD Design Assistant[8] desarrollada por Broadcom Inc.

En una primera instancia, se evaluó la viabilidad técnica de utilizar una línea detransmisión del tipo microstrip. Es la línea del tipo planar más simple que se puedeencontrar, formada únicamente por dos conductores. En la figura 3.6 se muestraun diagrama de ésta junto con sus principales parámetros constructivos.


W

H T Lεr

FIGURA 3.6: Esquema de una línea del tipo microstrip.

Antes de comenzar a realizar cálculos, se identificaron aquellas constantes queson impuestas por el diseño y que en consecuencia no se pueden modificar:

El material del sustrato será FR-4 (constante dieléctrica de 4,6). No es facti-ble utilizar sustratos especiales para radiofrecuencia.

El ancho máximo de la traza (W) será igual al del contacto de entrada deantena del GPS (0,7 mm). Se busca evitar así desadaptaciones en la línea.

El espesor de cobre (T) será el estándar de 35 µm.

La impedancia característica de la línea de transmisión deberá ser de 50ohms.

La frecuencia de operación será la de la banda L1 de GPS, con frecuenciacentral en 1.575,42 MHz.

Dadas las restricciones descriptas anteriormente, solo es posible modificar el es-pesor del sustrato. Así fue como se realizaron varias iteraciones asignando espe-sores disponibles en el mercado. Los resultados se muestran en la tabla 3.1.

TABLA 3.1: Impedancia característica del microstrip en funcióndel espesor de sustrato.

H Impedancia característica

0,6 mm 62,79 ohms0,8 mm 72,29 ohms1,0 mm 79,86 ohms1,2 mm 86,14 ohms1,6 mm 96,18 ohms2,0 mm 104,04 ohms

De los resultados obtenidos, se puede concluir que con un circuito impreso de 0,6mm de espesor, se podrá obtener un microstrip con el valor de impedancia máscercano a 50 ohms. Sin embargo, dicho sustrato carece de rigidez estructural yvolvería muy endeble el circuito, motivo por el cual no es factible utilizar unalínea de transmisión de este tipo.

Luego de un análisis más exhaustivo, se encontró que una línea del tipo Conductor-Backed Coplanar Waveguide (CBCPW) podría adaptarse muy bien a los requeri-mientos planteados. A diferencia del microstrip, una línea CBCPW cuenta con dos


conductores más que se ubican en el mismo plano que el conductor principal y unplano de masa en el lado opuesto. Esta disposición permite concentrar el campoelectromagnético entre los conductores del mismo plano, otorgando mayor flexi-bilidad a la hora de elegir el ancho del conductor principal (W). En la figura 3.7se ilustra el diagrama de este tipo de línea.

W

H εr T

G

L

FIGURA 3.7: Esquema de una línea del tipo CBCPW.

A diferencia del microstrip, la línea CBCPW cuenta con un parámetro adicional(G) que representa la separación entre el conductor principal y los planos de ma-sa. Si se modifica esta nueva distancia junto con el espesor del circuito impreso,se obtendrán los resultados de la tabla 3.2. Es importante resaltar que la distanciaG tendrá un mínimo de 6 mils (0,1524 mm), ya que ésta es la distancia mínimarecomendada por la mayoría de fabricantes de circuitos impresos. Las iteracio-nes se hicieron para espesores de sustrato de 1,2 mm y 1,6 mm por ser medidascomunes, sin diferencias de costos entre sí y con buena resistencia mecánica.

TABLA 3.2: Impedancia característica de la línea CBCPW en fun-ción del ancho de sustrato y distancia al plano de masa.

H / G Impedancia característica

1,2 mm / 6 mils 46,70 ohms1,2 mm / 7 mils 49,20 ohms1,2 mm / 8 mils 51,30 ohms1,2 mm / 9 mils 53,20 ohms1,2 mm / 10 mils 54,80 ohms1,6 mm / 6 mils 47,70 ohms1,6 mm / 7 mils 50,40 ohms1,6 mm / 8 mils 52,60 ohms1,6 mm / 9 mils 54,60 ohms1,6 mm / 10 mils 56,40 ohms

Es de notar que los resultados obtenindos presentan poca dispersión a pesar deque se han modificado dos parámetros al mismo tiempo. De esta manera, existenvarias combinaciones de H y G que satisfacen el requisito de 50 ohms. El criteriode selección consistió en adoptar el mayor valor de G posible. Así, se buscó maxi-mizar la cantidad de proveedores que contaran con la capacidad tecnológica paraproducir el Printed Circuit Board (PCB). En conclusión, se empleó en el diseño H= 1,2 mm y G = 10 mils, donde se obtuvo una impedancia característica de 54,80ohms. Habrá entonces una pequeña desadaptación que resulta aceptable por lautilización de antenas de alta ganancia y la alta sensibilidad del receptor.


3.1.5. Capa física Ethernet

Si se quiere que un equipo se conecte a una red de área local (LAN) y que funcio-ne como host de un sitio web (requerimiento de hardware número 4), es necesarioproveerle de cierta interfaz que le permita interpretar determinadas señales decomunicación analógicas. Es decir, se encargará de recibirlas, decodificar sus con-tenidos y enviarlos a capas superiores para su procesamiento. Los mismo aplicaen el sentido inverso, o sea, que pueda recibir información desde capas superio-res, la codifique y finalmente la transmita hacia la red. Este tipo de hardware seconoce como Physical Layer (PHY) o circuito de capa física. Formalmente la PHYconecta un Medium Access Control (MAC) con un medio físico. En el caso de unared cableada, será un cable Ethernet de pares cruzados.

El microcontrolador seleccionado cuenta con un controlador MAC para conexio-nes Ethernet, por lo que resta diseñar el circuito PHY. Tal cual se comentó en lasección 3.1.1, la placa de desarrollo LPC1769 cuenta con un transceiver Ethernet,mientras que los componentes faltantes de capa física (conector RJ-45 entre otros)se encuentran montados en la Base Board. El chip es el LAN8720A comercializadopor Microchip Technology. Las características principales se describen a continua-ción:

Compatible con IEEE802.3/802.3u (Fast Ethernet de 100 Mbps).

Compatible con ISO 802-3/IEEE 802.3 (10BASE-T).

Funciones de auto-negociación del link.

Detección y corrección automática de polaridad.

Interfaz RMII para comunicarse con la MAC.

A la hora de incorporar este circuito al equipo se utilizó el mismo diseño imple-mentado en la placa LPC1769 Rev.D. Dicho circuito se muestra con mayor detalleen la figura 3.8.

FIGURA 3.8: Diagrama esquemático de la capa física de Ethernet.


3.1.6. Interfaz de usuario

El requerimiento de hardware número 2 fue uno de los más específicos, por loque solamente fue necesario buscar los displays gráficos más populares y verifi-car que cuenten con el soporte adecuado. La mayoría de ellos son pantallas deviejos teléfonos celulares devenidas en simples componentes, listos para ser in-tegrados en cualquier proyecto. Debido a su bajo costo y amplia disponibilidaden el mercado, se eligió una pantalla basada en el controlador ILI9341 fabricadopor Ili Technology Corp (Ilitek). Cuenta con una resolución de 320x240 píxeles,soporta hasta 65.535 colores y se comunica a través de interfaz Serial PeripheralInterface (SPI).

Por otro lado, se han incorporado cinco botones que permiten enviar distintoscomandos al equipo y navegar a través de la interfaz de usuario. Cada uno deellos se describe brevemente a continuación.

BUTTON UP: permite desplazarse por las pantallas del controlador en sen-tido ascendente.

BUTTON OK: permite ingresar y salir a cada una de las pantallas del con-trolador.

BUTTON DOWN: permite desplazarse por las pantallas del controlador ensentido descendente.

OVERRIDE: permite forzar de manera manual el encendido de la baliza.Forma parte del requerimiento de hardware número 7.

RESET: reinicia todo el sistema.

3.1.7. Salidas de alarma

El último bloque de hardware que resta implementar es el de las salidas de alar-mas. Se identifican en este sentido dos tipos: salidas analógicas y salidas digitales.El primero de ellos utiliza relés para alertar a algún sistema de monitoreo externosobre la existencia de una alarma. Esta alarma se reporta mediante un contac-to seco, es decir, sin diferencia de potencial aplicada. Si bien existen sistemas decontrol más modernos, resulta importante que el equipo cuente con esta funcio-nalidad ya que aún forma parte de las exigencias del requerimiento de hardwarenúmero 7. En la figura 3.9 se muestra el circuito de una de estas salidas.

Para finalizar con este apartado, resta cumplir con el requerimiento de hardwarenúmero 5. Las salidas digitales de alarma permiten reportar dichos eventos a unsistema de gestión a través del protocolo Modbus. En el caso particular de esteequipo, se decidió utilizar Modbus RTU sobre el estándar de capa física RS-485.El transceiver elegido es el ISL83483 de la firma Renesas Electronics Corporation.Es un dispositivo que soporta velocidades de transferencia de hasta 250 kbps yopera en modo half duplex. Como solamente se deben informar códigos de alar-ma, su rendimiento resulta más que apropiado. La figura 3.10 ilustra el circuitoesquemático de este componente.


FIGURA 3.9: Diagrama esquemático de una de las salidas de alar-ma por contacto seco.

FIGURA 3.10: Diagrama esquemático de la salida digital de alar-mas por protocolo Modbus.

3.1.8. Diseño del circuito impreso

Una vez finalizado el diagrama esquemático, fue posible llevar a cabo el ElectricalRule Check (ERC) en busca de posibles cortocircuitos, conexiones ilegales y con-tactos flotantes entre otros chequeos. Posteriormente, se generó el archivo netlisty se dibujó el circuito impreso. Se tuvieron en consideración, para las reglas de di-seño del proyecto, las limitaciones explicadas en el apartado 3.1.4. Por otra parte,las dimensiones físicas de la placa ya se encontraban definidas. Esto responde aque se busca que el nuevo diseño pueda instalarse sobre el hardware ya existente,por lo que, además de respetar dichas dimensiones, se tuvo en cuenta la posiciónde los contactos de interconexión y agujeros de sujeción mecánica.

En las figuras 3.11 y 3.12 se visualiza la capa frontal y posterior de cobre res-pectivamente. También se incroporó la capa con leyenda de componentes paracomprender mejor su disposición final. Por otro lado, en la figura 3.13 se muestra


una imagen renderizada del circuito, mientras que en la figura 3.14 se incluye unafotografía del circuito ya fabricado, con sus respectivos componentes instalados.

FIGURA 3.11: Vista de la capa frontal de cobre del circuito impresojunto con leyenda de componentes.

FIGURA 3.12: Vista de la capa posterior de cobre del circuito im-preso junto con leyenda de componentes.


FIGURA 3.13: Imagen renderizada de la placa, vista desde unplano cenital.

FIGURA 3.14: Fotografía de la placa tomada desde un plano ceni-tal.

3.2. Desarrollo de software 25

3.2. Desarrollo de software

Un objetivo personal del autor fue desarrollar software de manera profesional. Deesta forma, se intentó estructurar el código en bloques funcionales que permitansu reutilización en el futuro, se realizaron comentarios donde fue necesario, sedividió el proyecto en archivos autocontenidos y se documentó todo el procesomediante control de versiones.

3.2.1. Arquitectura

Una buena práctica de desarrollo de software consiste en adoptar patrones de di-seño. Éstos son formas estandarizadas de resolver problemas comunes de diseñode software. Además de adaptarse a distintos tipos, permiten resolverlos de for-ma eficiente, sin necesidad de invertir recursos en soluciones que aparentan sernovedosas.

Para armar la estructura básica del programa y cumplir con los requerimientosde software número 1 y 7, se adoptó una arquitectura en capas para separar ydesacoplar todo lo posible sus partes componentes. Esto garantiza que el códigosea portable, modular y de fácil mantenimiento. En la figura 3.15 se aprecia undiagrama con las distinas capas de software que forman parte del equipo.

Hardware

LPCOpen

Board Drivers Custom Drivers

FreeRTOS

lwIP TCP/IP Stack

HardwareAbstractionLayer (HAL)

OperatingSystem (OS)

Libraries TinyGPS

Application

FIGURA 3.15: Diagrama de capas del programa desarrollado.

Ya definida la estructura general del programa, se identificaron otros patronesaplicables. Éstos podrían usarse como base para el desarrollo de las tareas que seejecutan en la última capa:

Observar y actuar: se caracteriza por analizar valores de entrada recopila-dos a partir de distintas fuentes, como sensores y otros procesos. Si uno deesos valores indica que surgió alguna condición excepcional, se inician ac-ciones para llamar la atención del usuario hacia dicho valor y, en ciertoscasos, realizar alguna acción en respuesta. Este patrón de diseño se podráaplicar a las tareas del subsistema de monitoreo y control. La adaptaciónde éste se ilustra mediate el diagrama en bloques de la figura 3.16. Por otrolado, este esquema garantiza el cumplimiento de los requerimientos de soft-ware número 4, 5 y 6.


Segmentación de proceso: consiste en separar secuencias de datos enviadasdesde un proceso a otro a través de un pipeline. Usualmente, los procesos ge-nerador y consumidor cuentan con algún mecanismo de sincronismo paraque puedan ejecutarse a destiempo. En el caso de la aplicación, el subsiste-ma de sincronismo podría adoptar este patrón ya que el receptor GPS seráquien produzca la secuencia de datos y la inserte en un buffer (que actuarácomo pipeline) para luego poder fragmentarlos y obtener la información deinterés. En la figura 3.17 se muestra este patrón aplicado al subsistema desincronismo.

Valores desensores

Proceso de monitoreo

Valores adesplegar

Proceso de análisis

Proceso de despliegueProceso de alarma

Alarmas porcontacto seco

(relé)

Alarmas porModbus


Sensor decorriente de baliza

Tensión en contactoRFPWRUP

Sensor de luzambiental

FIGURA 3.16: Diagrama en bloques del patrón observar y actuaraplicado a la aplicación.

DatosproducidosProceso productor

(receptor GPS)

Datosconsumidos

Proceso buffer

Flujoprocesado

Proceso consumidor

Lógica de destello

Despliegue

FIGURA 3.17: Diagrama en bloques del patrón segmentación deproceso aplicado a la aplicación.


3.2.2. Tareas del sistema

A partir de los patrones definidos en la subsección anterior, se pueden definir lastareas que formarán parte de la aplicación. El diagrama de la figura 3.18 deta-lla cómo las tareas interactúan y cómo se vinculan con el mundo exterior. Paraque el lector comprenda sus principios de funcionamiento, a continuación se lasdescribe brevemente.

vParserTask

Se encarga del parsing de la trama NMEA 0183. Este proceso consiste ensegmentar la cadena de datos enviada por el receptor GPS para obtener lainformación de interés. La recepción se realiza a través de una rutina deinterrupción de la UART2 y se utiliza un semáforo (GpsDataSemaphore)para sincronizar su ejecución. También se usa interrupción externa del tipopin change (EINT3) para asegurar un correcto procesamiento de los datos.Una vez obtenida la información, se vuelca en una cola (xQueueForTime)para ser consumida por vBeaconTask.

vBeaconTask

Esta tarea se encarga de generar la señal de destello de baliza a una tasadeterminada. La información de sincronismo se recibe a través de una co-la. Adicionalmente, asume la responsabilidad de relevar constantemente elconsumo de corriente de baliza para determinar si se necesita producir unaalarma. Este comportamiento permite garantizar que los requerimientos desoftware número 2 y 4 se cumplan.

vEthernetTask

Durante el arranque del equipo, esta tarea configura el stack TCP/IP y losregistros sociados con la MAC y PHY. Por otro lado, es resposable por ini-ciar los servicios asociados con el servidor web embebido y monitorear elestado de la PHY regularmente. Es el bloque funcional que permite cumplircon los requerimientos de software número 6 y 9.

vDisplayTask

En líneas generales, esta tarea es responsable por la gestión de la interfaz deusuario. Monitorea el estado de los botones frecuentemente y actualiza lapantalla gráfica en respuesta a las acciones del usuario o bien ante eventosgenerados por el propio equipo. Satisface los requerimientos de softwarenúmero 3 y 6.

Debido a la forma en que se deben ejecutar las tareas vParserTask y vEthernet-Task, se decidió asignar a todas las tareas del sistema la misma prioridad. Como latransferencia de datos es casi constante en esas dos tareas, es muy probable que alasignarles una prioridad mayor que a las restantes (para garantizar que no hayapérdida de datos), el scheduler no asigne un time slice de ejecución a las de menorprioridad y simplemente nunca puedan correr. Al asignar la misma prioridad ygarantizando que ninguna de ellas presente un comportamiento bloqueante, esposible acercarse más al concepto de multi-tasking.


UART2 Interrupt Handler

FreeRTOSScheduler




vEthernetTask

vDisplayTask

vParserTask

vBeaconTask

GpsDataSemaphore

xQueueForTime

EINT3 Interrupt Handler

Interrupcionesexternas

Recursos decomunicación

FIGURA 3.18: Diagrama en bloques de las tareas del programa.

3.2.3. Servidor web embebido

Para desarrollar el servidor web embebido se utilizó como base una aplicaciónprovista por lwIP [9] junto con un ejemplo incluido en la biblioteca LPCOpen[10]. También se usaron como material de consulta las notas de aplicación deAtmel [11] y ST Microelectronics [12].

Antes de implementar el servidor web, se debe comentar brevemente la forma enque este tipo de aplicación interactúa con el stack TCP/IP. Para ello, lwIP ofrecedistintos tipos de Application Programming Language (API), a saber:

Raw API: es una API no bloqueante basada en eventos. Esto significa quese necesita la definición de una serie de funciones o callbacks para distintostipos de eventos relacionados con el stack. En caso de incidencia de algunode ellos, el core de lwIP ejecutará dichas funciones. Es la que presenta mayorrendimiento y ocupa menor tamaño en memoria. La desventaja que estotrae aparejado es que su implementación es más dificultosa.

Netconn API: es una API secuencial desarrollada en base a la Raw API.Presenta un nivel de abstracción más alto, por lo que es más fácil de im-plementar. Como utiliza el paradigma bloqueante de open-read-write-close,deberá usarse siempre acompañada de un sistema operativo.


Socket API: ofrece una implementación de los sockets BSD. Está construidasobre la Netconn API y la principal ventaja que ofrece es la portabilidadentre plataformas. Fuera de esta característica, presenta un rendimiento si-milar a Netconn API.

La implemetación detallada en [10] fue desarrollada utilizando la Raw API juntocon FreeRTOS. Un lector perspicaz podría sospechar que el mecanismo de call-backs no es thread-safe sin adicionar algún mecanismo de protección. Es por estemotivo que se usan semáforos para procesar los datos desde la PHY y todas lasfunciones de este tipo se ejecutan desde un mismo hilo de ejecución o thread. Su-pongamos un escenario en donde se ha recibido un dato. Básicamente, cuandoocurre una interrupción proveniente de esa interfaz, se analiza si se correspondecon una transmisión o una recepción. En base al origen, se avisa mediante un se-máforo a una tarea (en nuestro ejemplo, será una tarea de recepción). Ésta, a suvez, llama al callback asociado para que el dato sea procesado. Una vez que el datoestá listo, se necesita que recorra el stack TCP/IP. Así es como, a través de una ta-rea que se encuentra bloqueada a la espera de nueva información, eventualmenteel dato atraviesa todas las capas hasta llegar a la aplicación.

Hechas las aclaraciones pertinentes respecto de lwIP, es posible avanzar con ladescripción de la aplicación. El servidor web implementado soporta los siguien-tes servicios:

HyperText Transfer Protocol 2.0 (HTTP 2.0)

Es un protocolo sin estado, orientado a transacciones y que respeta el es-quema petición/respuesta entre un cliente y un servidor. Posibilita que lasconexiones sean persistentes, evitando que se abra una conexión por cadanueva solicitud TCP. Esto mejora el rendimiento de la conexión y es un fea-ture que se necesita para soportar AJAX.

Server Side Includes (SSI)

Son un conjunto de directivas que se incluyen dentro de las páginas HTML.Se evalúan en el servidor cada vez que el cliente solicita el sitio web. De estamanera, SSI permite añadir contenido generado de forma dinámica. Esto selogra agregando una etiqueta dentro del código HTML del sitio web delformato <--#etiqueta-->. Cuando un cliente realiza una petición delsitio web (archivo con extensión .shtml), el servidor hace un parsing de lapágina web y cuando encuentra la etiqueta, la reemplazará por un valordeterminado.

Asynchonous JavaScript And XML (AJAX)

Es una técnica de desarrollo web para crear aplicaciones interactivas. Es-tas aplicaciones se ejecutan en el cliente, es decir, en el navegador de losusuarios mientras se mantiene la comunicación asíncrona con el servidoren segundo plano. Así es posible mostrar cambios en la pagina web sin te-ner que actualizar todo el sitio. Cuando se lo utiliza junto con SSI, el clienteserá responsable por solicitar regularmente un archivo con extensión .ssi o.shtml y ubicar su contenido en lugares específicos de la página web. En lafigura 3.19 se muestra el diagrama UML de una transacción AJAX.


Common Gateway Interface (CGI)

Es una interfaz para servidores web que le permite a un cliente solicitar da-tos de un programa ejecutado en dicho servidor y devolver una respuesta.En lwIP solamente se soporta el método GET, y puede administrar hasta 16parámetros codificados en la Uniform Resource Identifier (URI).

Navegador Servidor web

AJAX loop timeout

Creación del objetoXMLHttpRequest

Envío de HttpRequestProcesamiento de

HttpRequest

Creación derespuesta

Envío de datos al navegador

Procesamiento de losdatos usando JavaScript

Actualización delcontenidos de la página

FIGURA 3.19: Diagrama UML de una transacción AJAX.

Para incorporar la aplicación web personalizada de acuerdo a los requerimientosdel trabajo, es necesario ejecutar un script llamado makefsdata.exe provistojunto con el ejemplo de lwIP. Este pequeño programa toma la estructura de ar-chivos completa de un sitio web y genera el archivo fuente fsdata.c que podrágrabarse en la ROM del microcontrolador.

Finalmente, en las figuras 3.20 y 3.21 se muestran las capturas de pantalla co-rrespondientes al sitio web implementado. Éste cuenta con dos pestañas o vistasprincipales: Monitoring view y Configuration. En la primera de ellas es posible ob-servar todos los parámetros del equipo que resultan de interés durante las tareasde monitoreo. Por otro lado, en la vista Configuration se pueden cargar parámetrosrelevantes al funcionamiento del equipo.

La vista Monitoring view fue dividida en cuatro secciones que se enumeran a con-tinuación.

Site Information: contiene toda la información relacionada con la identidaddel equipo. Resulta pertinente recordar que este controlador será instaladoen un parque eólico, por lo que habrá varios instalados y cada uno sobre


Esta imagen ha sido removida de la memoria para su publicación online ya que el presente trabajo

tiene �nes comerciales.

FIGURA 3.20: Vista de monitoreo del servidor web del equipo.

Esta imagen ha sido removida de la memoria para su publicación online ya que el presente trabajo

tiene �nes comerciales.

FIGURA 3.21: Vista de configuración del servidor web del equipo.

un aerogenerador distinto. Por este motivo resulta importante contar coninformación que lo identifique inequívocamente dentro del complejo.

Light Units: en esta columna se muestran cada una de las balizas que seencuentran conectadas al equipo.


Synchronization: provee información sobre los módulos que conforman elsubsistema de sincronismo.

Alarms: incluye el estado de todas las alarmas que es capaz de generar elequipo. Adicionalmente, cuando el usuario posiciona el mouse sobre algunade ellas, aparecerá una pequeña ventana que indica las posibles causas delproblema y pasos recomendados para realizar un troubleshooting. Esto sepuede apreciar con mayor detalle en la figura 3.22.

Al igual que para el firmware, el código del sitio web se escribió para ser modulary escalable. Así es que cada elemento del equipo se grafica como un módulo. Estacaracterística permitiría agregar más módulos de tamaño predefinido si así se lorequiriera en un futuro. Además, cada uno puede mostrar información específicay conocer mediante un indicador en la esquina superior derecha el estado delmismo. Al momento de escribir esta memoria, se soportan tres colores: verde si elfuncionamiento es el esperado, rojo para indicar si existe algún probema y gris sies una funcionalidad no soportada. La figura 3.23 muestra estas tres posibilidadescon mayor detenimiento.

Esta imagen ha sido removida de la memo-ria para su publicación online ya que el pre-sente trabajo tiene

�nes comerciales.FIGURA 3.22: Ventana emergente con información adicional de

alarmas.

Esta imagen ha sido removida de la memoria para su publi-cación online ya que el presente trabajo

tiene �nes comerciales.FIGURA 3.23: Posibles estados de los módulos.

Para finalizar con esta subsección, tal como se pudo ver en la figura 3.21, la vis-ta Configuration permite cargar parámetros de configuración esenciales para elequipo, como ser: nombre, código de identificación, provincia, país, dirección IP,máscara de red y puerta de enlace. El envío de este formulario se realiza medianteuna petición GET y funciones de CGI en el servidor.


3.2.4. Sincronismo

Los receptores de GPS se comunican con otros equipos a través del protocoloNMEA 0183, el cual consiste en sentencias de caracteres en formato ASCII quese transmiten a intervalos regulares de tiempo. Adicionalmente, la mayoría deellos proporcionan una señal PPS que cambia al estado alto durante el comienzode cada segundo. En la figura 3.24 se muestra la dependencia temporal entre laseñal de PPS y la de sincronismo (SYNC).

FIGURA 3.24: Señales involucradas en la tarea de sincronismo.

Para aplicaciones donde el foco se centra en conseguir una referencia temporalestable y precisa, resultan de vital importancia ambas fuentes de información. Es-to se debe a que la mayoría de los receptores disponibles en el mercado envíanlas sentencias NMEA una tras otra, por lo que no existe una referencia temporalque indique en qué momento se envía una sentencia luego de haber iniciado elsegundo. Debido a esto, una aplicación que recibe una sentencia no sabe si hasido enviada al comienzo del segundo, al final o instantes antes de que comien-ce uno nuevo. Esto explica la razón por la que la señal PPS es requerida paraque el sincronismo sea correcto. Las sentencias NMEA simplemente reportan eltiempo, el cual puede ser enviado aleatoriamente durante el transcurso del se-gundo. Por otro lado, la señal PPS indica el comienzo de cada segundo, por loque la combinación de ambas resulta indispensable para tener una fuente fiablede sincronismo.

La señal de sincronismo, además de generarse a partir de los datos GPS, debegenerarse de forma autónoma en caso de que exista un problema con el receptor.Así, ni bien se inicia el programa, la tarea vParserTask activa un temporizador ala espera de que el GPS se inicialice por primer vez (cold start). Si una vez pasadoeste tiempo de espera no se reciben datos, se producirá la señal SYNC a partir deun temporizador local al equipo y se generará una alarma de sincronismo. Éstaes la forma de llamar la atención del usuario e informar que el funcionamientodel equipo se encuentra degradado. De acuerdo con [4], ésta es una situaciónaceptable pero que debe ser remediada cuanto antes.

Para procesar las sentencias NMEA, se adaptó la biblioteca TinyGPS1 desarrolla-da originalmente en lenguaje C++ por Mikal Hart a lenguaje C puro. Por otrolado, se aprovecharon los buffers circulares del LPC1769 para almacenar una tra-ma NMEA en su totalidad de una sola vez. Esto alivia la carga sobre el procesadory el parsing se vuelve más eficiente.

En la figura 3.25 se muestra el diagrama de flujo de la recepción y procesamientode las tramas enviadas por el receptor GPS a través del puerto serie.

1http://arduiniana.org/libraries/tinygps/

http://arduiniana.org/libraries/tinygps/


Sí

¿Semáforodisponible?

Activar temporizadorsi no estaba activo

(T = 0)

Se toma el semáforo(GpsDataReady)

Se procesa lainformación con

encode( )

No

¿Fin de cuenta(T = 1)?

No

No¿Se recibió PPS?

Se procesan lossegundos (T = 0, S = 0

y NO_SYNC = 0)

Inserción desegundos en cola(xQueueForTime)

Sí

Activar temporizadorsi no estaba activo

(S = 0)

Sí

Reportar alarma (NO_SYNC = 1)

No

Sí

¿Fin de cuenta?

FIGURA 3.25: Diagrama de flujo del proceso de sincronismo.

3.2.5. Control de baliza y alarmas

Con la información generada de la tarea de sincronismo, vBeaconTask se encar-ga de generar la secuencia de destello de baliza. De acuerdo al requerimiento desoftware número 2, los destellos ocurrirán a una tasa fija de 30 FPM. A continua-ción, se evaluará el estado del sensor de luz ambiental mediante polling del canaldel conversor ADC asociado. Si se detecta un valor de tensión, significa que es dedía (MODE = DAY) y que en consecuencia no se deberá encender la baliza. Si encambio esta lectura no arroja ningún valor, entonces se da la condición de noche(MODE = NIGHT), por lo que será necesario activar la baliza.


Por otro lado, cuando la baliza se encuentre encendida, esta tarea tendrá que rea-lizar un polling de los canales de ADC que se encuentran muestreando las salidasde los sensores de corriente. Si se mide un consumo distinto al nominalmente de-clarado, se generará una alarma. Dicha alarma será convenientemente informadaal subsistema de comunicación.

En la figura 3.26 se muestra el diagrama de flujo de la tarea vBeaconTask.

Sí

¿Datos disponiblesen la cola?

Generación salidaSYNC

Sí

No

¿Es de noche?

Evaluación sensorde luz ambiental

Encendido / apagadode baliza

Sí

No¿Baliza encendida?

No

Evaluación sensorde corriente

Sí No¿Consumo normal?

Generación dealarma

FIGURA 3.26: Diagrama de flujo del proceso de control de balizay alarmas.


3.2.6. Interfaz gráfica y teclas frontales

Este proceso requiere mantener actualizado el contenido de la pantalla de for-ma continua. Sin embargo, también es necesario conocer el estado de los botonessimultáneamente, ya que al recibir un comando, se debe actualizar la presenta-ción. Como ambas funciones se encuentran muy vinculadas entre sí, se decidióque fueran llevadas a cabo por una misma tarea. En el caso particular de estaaplicación se la denominó vDisplayTask.

Se encontró que una de las mejores formas de implementar las funciones de estatarea era mediante Máquinas de Estados Finitos (MEF). Para la función que ma-neja la pantalla gráfica, la MEF diseñada se muestra en la figura 3.27. Esta funcio-nalidad se encarga solamente de mostrar información del equipo en tiempo real.No obsante, para acceder a esa información, se necesita proveer de un menú quele permite al usuario navegar a través de las distintas pantallas de informacióndel equipo.

Los eventos que producen cambios en los estados son el accionamiento de losbotones BUTTON UP y BUTTON DWN respectivamente. Por otro lado, a conti-nuación se describe cada uno de los estados posibles de esta MEF.

Initial: en este estado se muestra la pantalla de bienvenida al equipo, queaparece ni bien se lo enciende o reinicia. Se corresponde con la figura 3.28a.

SystemInfo: es el estado en el cual se muestra la pantalla con la informaciónmás importante del equipo. Se puede observar en las figuras 3.28b y 3.28c,dependiendo de si el sistema se encuentre alarmado o no.

GpsInfo: como su nombre lo sugiere, en este estado se muestran los datosde GPS. Se lo puede apreciar en la figura 3.28d.

NetworkInfo: en este caso, el estado mostrará los datos de la conexión dered actualmente configurados. La figura 3.28e se corresponde con dicho me-nú.

Initial

Muestra el mensaje debienvenida al equipo.

BUTTON_UP

BUTTON_DWN

SystemInfo

Muestra la pantalla coninformación general del sistema.

BUTTON_UP

BUTTON_DWN

NetworkInfo

Muestra la pantalla coninformación de red.

BUTTON_DWN

BUTTON_UP

GpsInfo

Muestra la pantalla coninformación del GPS.

FIGURA 3.27: Diagrama UML de la MEF que muestra el menú delequipo.


error

You are about to access a private system. This system is for the use of authorized users only. Any unauthorized access or attempts may be punished under the applicable local legislation.

radiosistemasSystem Status

Mode of Operation: NightL-864 Status: OKL-810 Status: OKGPS: Synchronized

SYSTEM NORMALcheck

help

a) b)

System StatusMode of Operation: NightL-864 Status: 7701 codeL-810 Status: OKGPS: Synchronized

SYSTEM ALARMEDnotifications_onꂐ띏��

help

c)

GPS StatusUTC Time: 20:07:04UTC Date: 31/03/20Antenna Status: OKSatellites: 7

SYSTEM NORMALcheck

my_location

d)

Network StatusIP: 192.168.1.130Submaks: 255.255.255.0Gateway: 192.168.1.1

SYSTEM NORMALcheck

swap_vert

e)

FIGURA 3.28: Distintas pantallas que forman parte del menú delcontrolador.

Resta por describir la MEF, que se ocupa de la lectura de los botones frontales. Seutiliza únicamente para eliminar los efectos no deseados que produce el antirre-bote cuando se pulsa un botón. En la figura 3.29 se muestra el diagrama de ésta.Para facilitar su comprensión, se describen a continuación todos sus estados:

Button up: se estará en este estado cuando el botón no está pulsado.

Button falling: es el estado en el que el botón está comenzando a ser presio-nado.

Button down: en este estado el botón está presionado.

Button rising: estado en el que el botón está siendo liberado.

Botón presionadoButton up

Tiempo transcurrido > 40 ms y botón liberado


Button rising


Tiempo transcurrido > 40 ms y botón presionado

Button falling

Botón liberadoButton down

FIGURA 3.29: Diagrama UML de la MEF antirrebote.

39

Capítulo 4

Ensayos y Resultados

En este capítulo se describe la estrategia de pruebas adoptada para comprobarque el comportamiento del equipo es acorde a lo esperado. Adicionalmente, sedetallan los problemas encontrados durante el proceso y cómo pueden influir enel proceso de diseño del software y hardware.

4.1. Pruebas de hardware

Estos primeros ensayos se centraron en verificar el correcto funcionamiento decada uno de los módulos de hardware por separado. En otras palabras, se probócada uno de ellos junto con sus drivers asociados de forma independiente. Debidoen gran medida a la estrategia adoptaba para desarrollar este trabajo, se verificóque todos ellos funcionaban correctamente. No obstante, se identificó un proble-ma en el circuito de la PHY.

A pesar de que la interfaz PHY funcionaba sin inconvenientes cuando se encendíael equipo, cada vez que éste se reiniciaba, el microcontrolador perdía la comuni-cación con ella. Luego de revisar las hojas de datos del LAN8720A junto con elcircuito esquemático de la placa usada como referencia (LPCXpresso 1769 Rev.D1), se identificó una diferencia en la línea de reset. En la Rev. B de dicha pla-ca (utilizada durante el desarrollo del software), la conexión del terminal nRSTdel LAN8720A se realiza a través del contacto identificado como RSTOUT delmicrocontrolador. Por otro lado, en la Rev. D1 (utilizada para diagramar el cir-cuito esquemático del equipo) esa conexión se realiza de forma directa a la líneageneral de reset. Esta diferencia que parece menor a simple vista genera un com-poramiento inestable en el LAN8720A.

La línea general de reset se activa mediante un botón. Cuando se lo acciona, dosplacas de metal entran en contacto para realizar un cortocircuito entre la tensiónde fuente y masa. Si estas placas no son perfectas, pueden dejar de hacer contactoy volver a hacerlo muchas veces antes de que exista una presión estable que lasmantenga unidas. Un microcontrolador puede leer un botón millones de vecespor segundo, por lo que interpretará que se ha activado la línea de reset mu-chísimas veces. Este problema es conocido como switch bounce y se resuelve contécnicas de hardware, software o una combinación de ambas. El LPC1769 cuen-ta con un circuito disparador Schmitt que le permite filtrar la señal y obviar losrebotes. Por otro lado, el LAN8720A no cuenta con un mecanismo similar, por loque nunca debería ser reiniciado de este modo. Adicionalmente, luego de haber-se enviado la señal de reset, debe garantizarse que ésta permanezca sin cambiosdurante un tiempo especificado. Si esto no sucede, es posible que el chip no logre

40 Capítulo 4. Ensayos y Resultados

detectar correctamente el nivel de tensión en el contacto PHYAD0, volviéndolomuy inestable. Este comportamiento era el que generaba los problemas duranteel reinicio.

La solución que se encontró fue realizar un puente entre la línea nRST y RSTOUT,asemejándolo con el circuito implementado en la Rev. B de la placa. Luego dehaber realizado esta corrección, no se volvió a detectar ningún otro problema condicha interfaz.

4.2. Pruebas de software

4.2.1. Pruebas estáticas

Se decidió implementar pruebas estáticas para mejorar la calidad del trabajo rea-lizado. No obstante, el desarrollo de dichas pruebas competiría con el resto de lasactividades por recursos temporales escasos, motivo por el cual se decidió reali-zar pruebas unitarias en aquellos módulos críticos al funcionamiento del equipo.Así, se realizaron análisis estáticos de las tareas vParserTask y vBeaconTask. Seutilizó Ceedling para ejecutar las pruebas unitarias en combinación con Gcov pa-ra generar análisis de cobertura. En la tabla 4.1 se pueden observar los resultadosde las pruebas estáticas, mientras que en la tabla 4.2 los correspondientes a los decobertura.

TABLA 4.1: Resultados del análisis estático.

Tarea Cantidad de tests Exitosos Fallidos

vParserTask 2 2 0vBeaconTask 3 3 0

TABLA 4.2: Resultados del análisis de cobertura.

Tarea Líneas ejecutadas Saltos ejecutados

vParserTask 7/7 (100 %) 5/6 (83,3 %)vBeaconTask 9/9 (100 %) 2/2 (100 %)

4.2.2. Ensayos de estabilidad del servidor web

Duante las pruebas a nivel sistemas se detectó que el rendimiento del servidorweb no era el adecuado. Por este motivo, se procedió a realizar un debugging másdetallado para conocer el estado de las tareas realacionadas con dicha fucionali-dad. Se descubrió un problema vinculado a la gestión de memoria dinámica, queproducía que el equipo dejara de funcionar de forma aleatoria. Ésta fue una fallagrave que debía ser atendida cuanto antes.

Luego de extensas sesiones de depuración, se encontró que siempre que ocu-rrían esos fallos catastróficos, el equipo terminaba ejecutando el handler llamadovApplicationMallocFailedHook, lo cual dio una idea de que el problemaestaba en el sistema de asignación de memoria. El código del ejemplo [10] imple-mentaba el esquema de memoria heap_3 de FreeRTOS. Dicha implementación loúnico que hace es enmascarar las funciones malloc() y free() provistas en la

4.2. Pruebas de software 41

biblioteca estándar de C para que sean seguras cuando se las utiliza en un RTOS(thread safe).

En ambientes embebidos, donde la cantidad de memoria es muy limitada, losalgoritmos que implementan dichas funciones no son los más capaces para ad-ministrar este escaso recurso. Por lo que mediante los ensayos realizados se ve-rificó que, dependiendo de la cantidad de conexiones HTTP que se establecieranal mismo tiempo, el equipo podría fallar inesperadamente a causa de una fallaen la función malloc(). A su vez, ésta puede fallar porque no ha sido capaz deecontrar memoria para asignar a la función que se la haya solicitado.

En una primera instancia, se incrementó el tamaño del heap disponible. Si bienparecía ser una solución válida al problema en cuestión, lo único que se logrófue que se requiriera de una mayor cantidad de conexiones para provocar la fa-lla. Entonces, al analizar el heap, se verificó que la memoria presentaba una altafragmentación. Así, si en algún momento se solicitaba un bloque de memoria queno cabía entre los disponibles, malloc() fallaba y todo el sistema colapsaba. Deesta forma, se necesitaba algún mecanismo que permitiera administrar la memo-ria más eficientemente. Por suerte, FreeRTOS provee otros esquemas de memoriaque se pueden adaptar a distintas aplicaciones. Analizando cada uno de ellos, sellegó a la conclusión de que el esquema heap_4 sería una solución aceptable.

El esquema de memoria heap_4 de FreeRTOS implementa un algorítmo del tipofirst fit para asignar bloques de memoria y permite combinar bloques adyacentesen bloques más grandes, de forma de evitar el riesgo de fragmentación. Adicio-nalmente, bajo este esquema, la memoria es instanciada de forma estática lo quebrinda mayor determinismo en comparación con malloc() y free().

En la figura 4.1 se muestra cómo el heap se va fragmentando a medida que laejecución del programa avanza. En t = 30 se aprecia una situación donde la me-moria se ha fragementado bastante debido a múltiples conexiones HTTP, algoque resulta esperable considerando que se utiliza AJAX. De haber empleado elheap_3, esta fragmentación continuaría hasta que los bloques disponibles fue-sen tan pequeños que provocarían la falla de malloc(). Como en la figura se haimplementado el heap_4, se puede apreciar que en t = 40 la fragmentación hadisminuido a pesar de haber conexiones activas. Finalmente, a partir de t = 50, alno haber más conexiones HTTP activas, el heap vuelve a su estado inicial.

4.2.3. Ensayos de utilización del procesador

Durante la etapa de debugging, se verificó que el software permanecía muchotiempo en la tarea vEthernetTask. Esta situación no es deseada, ya que indicabaque esa tarea se estaba ejecutando constantemente, sin dejar que tareas con me-nor prioridad pudieran ejecutarse. Al revisar las estadísticas de uso del CPU severificó que el 100 % del tiempo se estaba ejecutando dicha tarea. Esto se debía engran medida a que el código implementado estaba constantemente haciendo unpolling de la interfaz Ethernet en busca de algún cambio (el cable se desconectó,se modificó el modo de transferencia o la velocidad de transmisión).

Para solucionar este inconveniente, se agregó una demora mediante la funciónvTaskDelay() de FreeRTOS para que el estado de la interfaz Ethernet sea revi-sado periódicamente. Sin embargo, no fue posible encontrar una frecuencia ópti-ma a la cual monitorear dicha interfaz. Se decidió entonces que esta revisión se


60,06% asignado; sin conexión HTTP activa


60,06% asignado; con conexión HTTP activa

t = 0

t = 10

t = 20

t = 30

t = 40

t = 50

t = 60





Utilización de heapTi

empo

[min

utos

]

FIGURA 4.1: Evolución de la estructura del heap a medida que pasael tiempo.

haría una vez por segundo. El uso del procesador una vez hecho este cambio sepuede observar en la figura 4.2. La colecta de los datos se realizó durante apro-ximadamente 40 minutos. A las 19:26 el equipo se encendió por primera vez ydurante la prueba se realizaron varias conexiones HTTP.

Para finalizar este ensayo, se pudo comprobar que a diferencia de lo que sucedíaen un primer momento, la tarea IDLE se ejecuta y que las tareas vParserTask yvBeaconTask representan poca carga para el sistema.

0

20

40

60

80

100

120

19:26 19:28 19:30 19:32 19:34 19:36 19:38 19:40 19:42 19:44 19:46 19:48 19:50 19:52 19:54 19:56 19:58 20:00 20:02

Uso

del

CPU

[%]

Hora

IDLE receive_thread tcpip_thread txclean_thread vBeaconTask vDisplayTask vEthernetTask vParserTask

FIGURA 4.2: Utilización del procesador por cada una de las tareas.

4.3. Ensayos de retrocompatibilidad 43

4.3. Ensayos de retrocompatibilidad

Un ensayo clave consistió en comparar cómo se comportaba el sistema desarro-llado junto al equipo de generación actual. Esto se debe principalmete a dos mo-tivos.

1. Es posible que un equipo de generación actual falle y requiera ser reempla-zado por uno de nueva generación. Se necesita entonces que sea un reem-plazo directo y que se soporten las mismas funcionalidades.

2. La mayoría de los parques eólicos son construidos por etapas. Es factibleun escenario en el que, durante la primera etapa de construcción, se hayaninstalado equipos de primera generación y que durante las ampliacionesse hayan instalado los nuevos equipos. Resulta fundamental que el sincro-nismo sea exactamente el mismo para no comprometer el rendimiento delsistema de balizamiento en su conjunto.

Para llevar a cabo estos ensayos, se armó el setup que se muestra en la figura4.3. Ambos equipos fueron conectados a una misma fuente de alimentación y seprocuró que las dos antenas GPS se instalen en una posición con vista clara alcielo, tal cual sucedería en una situación de uso real.

FIGURA 4.3: Diagrama en bloques del setup utilizado para el ensa-yo de retrocompatibilidad.


Durante la primera medición, se verificó que el equipo de generación actual ge-neraba la señal de sincronismo a partir del flanco descendente de la señal PPS.Según se pudo indagar con las personas vinculadas al desarrollo de dicho equi-po, el tratamiento de la señal PPS se realiza a través de una rutina de interrupciónexterna. La figura 4.4 muestra las señales del controlador actual.

A

B

PPS SYNCA B

FIGURA 4.4: Diagrama temporal de las señales de sincronismo delcontrolador actual.

Si bien se tuvo en cuenta esta característica temporal para el desarrollo del nuevocontrolador, se verificó que el tiempo de procesamiento de las tramas NMEA yde la señal PPS podía variar un poco y que se encontraba entre 150 y 200 milise-gundos. Esto significaba que de considerar el flanco descendente para activar laseñal de sincronismo, habría mucha diferencia entre un equipo y otro. La soluciónencontrada fue utilizar el flanco ascendente. La figura 4.5 muestra las dos señalesdel nuevo controlador (A y B) junto con las dos señales del controlador actual (Cy D).

A

B

A

C

D

PPS (Nuevo) B SYNC (Nuevo) PPS (Actual)C D SYNC (Actual)

FIGURA 4.5: Diagrama temporal de las señales de sincronismo deambos controladores.

Si se amplía la señal anterior en alguno de los flancos descendentes, será posiblever la diferencia de tiempo que existe entre la transición del estado alto al bajode las señales PPS (A y C) con las señales de salida SYNC (B y D) de amboscontroladores. En la figura 4.6 se muestra esta situación en detalle.

Obsérvese que la señal B transiciona aproximadamente 35 milisegundos despuésde que lo hace la señal D. Asimismo, como la señal B se genera en un sistema quese ejecuta sobre un RTOS, si se extiende este análisis a todas las transiciones queocurren a lo largo de un minuto, se podrá verificar que la demora no es siemprela misma. Por lo que se ha visto, la transición puede ocurrir en apenas 10 milise-gundos como hacerlo, en el peor de los casos, en 120 milisegundos. Cabe recordartambién que la señal B se produce a partir del flanco ascendente de la señal A, porlo que entre un evento y otro pueden transcurrir 210 milisegundos en el mejor delos casos.

4.3. Ensayos de retrocompatibilidad 45

A

B

C

D

A PPS (Nuevo) B SYNC (Nuevo) PPS (Actual)C D SYNC (Actual)

35 ms

4 ms

235 ms

FIGURA 4.6: Diferencia temporal entre las señales de sincronismode ambos controladores.

Con esta información, se buscó reducir el tiempo que le tomaba al sistema com-pletar dicha transición. Se realizaron ajustes en las prioridades de las tareas vPar-serTask y vBeaconTask sin impacto alguno. Esto significaba que el RTOS atendíalas interrupciones en tiempo y forma, priorizaba la ejecución de las tareas vin-culadas a ellas; pero así y todo existía algo fuera de su alcance que impactabafuertemente en el tiempo de procesamiento.

Como en casi todos los problemas que presentan algún tipo de complejidad, noexiste una sola causa que los origine. En este caso, lo que afectaba el tiempo deprocesamiento era la enorme cantidad de datos que se recibían por el puerto seriey la velocidad a la que se transferían. La primera optimización en este sentidoconsistió en deshabilitar todas las tramas NMEA 0183 que no fueran útiles parala aplicación. Así, solamente quedaron activas las tramas GPRMC y GPGGA paraobtener la hora en formato UTC, fecha, posición y cantidad de satélites a la vista.Por otro lado, se incrementó la tasa de transferencia del receptor GPS a 5 Hz. Estoscambios obligaron a aumentar la velocidad de transferencia del puerto serie paraque no haya pérdida de información en la comunicación. De esta manera, se pasóde 9.600 baudios a 115.200 baudios. La figura 4.7 muestra el mismo diagramatemporal que la figura 4.6 luego de haber implementado los cambios descriptos.

A

B

C

D


150 ms 50 ms

4 ms

FIGURA 4.7: Diferencia temporal entre las señales de sincronismode ambos controladores luego de la optimización.


De acuerdo con esta última medición, fue posible reducir el tiempo que requierela señal B en cambiar de estado luego de recibir un flanco ascendente en A. Estoindica que todo el procesamiento es más rápido y que, en consecuencia, la señalB estará aproximadamente 50 milisengundos por delante de la señal D. Ésta esuna situación deseada, ya que le permite al procesador atender otras tareas hastaque se detecte un flanco descendente de la señal A, momento en el cual deberíainmediatamente realizar la transición correspondiente en su salida. La forma derealizar esta modificación en el comportamiento del sistema fue haciendo que laentrada de la señal A ejecutara una interrupción ante cualquier cambio de nivel.La figura 4.8 muestra el diagrama temporal luego de esta última modificación.

A

B

C

D


4 ms

FIGURA 4.8: Diferencia temporal final de las señales de sincronis-mo de ambos controladores.

Como se puede apreciar en la figura 4.8, se ha reducido la demora en la transiciónde la señal de sincronismo B de forma considerable. Para cuantificar esta mejoraen el tiempo de transición y darle una noción más clara al lector sobre ésta, si seincrementara la velocidad de muestreo del analizador lógico lo suficiente comopara distinguir una diferencia temporal entre ambos flancos, se descubriría quees de tan sólo 16 microsegundos.

47

Capítulo 5

Conclusiones

En este capítulo se realiza una conclusión sobre el trabajo realizado hasta el mo-mento y se lo evalúa. También se presentan las posibilidades de trabajo futuro,oportunidades de mejora y cambios que se requieren para transformarlo en unproducto terminado.

5.1. Trabajo realizado

Este trabajo logró desarrollar de forma exitosa un prototipo de controlador pa-ra balizamiento aéreo. Se demostró la factibildad técnica de soportar múltiplesfuncionalidades complejas con un solo microcontrolador mediante el uso de unRTOS. Adicionalmente, desde la perspectiva del aseguramiento de la calidad, severificó el cumplimiento de todos los requerimientos propuestos al inicio del tra-bajo. Por este motivo, se puede concluir que su objetivo fue cumplido de formasatisfactoria.

Por otro lado, en la opinión del autor, este desarrollo sirvió para sentar las basesde una nueva metodología de trabajo en una empresa que produce equipamientoelectrónico en el país. Una metodología que permite adaptarse a los cambios soli-citados por el cliente de forma ágil, empleando los recursos disponibles eficiente-mente y donde una detallada planificación maximiza las chances de éxito. Desdeun punto de vista técnico, se incorporó el concepto de diseñar para la excelenciacomo una forma de mejorar la calidad y la competitividad de un producto. Todoeste aprendizaje será aplicado a nuevos proyectos que desarrolle la empresa.

Desde el punto de vista de la gestión de riesgos, se presentó la dificultad de reci-bir algunos componentes en tiempo y forma. Afortunadamente, dichas demorasno afectaron el cronograma original del proyecto por no encontrarse dentro delcamino crítico. Así, fue posible posponer su realización hasta que resultara nece-sario.

Durante el desarrollo de este trabajo se aplicaron conocimiento adquiridos a lolargo de la CESE. Todas las asignaturas fueron importantes para incoporar nue-vos conceptos y experiencias requeridas para el desarrollo de un sistema embebi-do. A continuación se detallan las que tuvieron mayor relevancia:

Gestión de Proyectos en Ingeniería: se elaboró un Plan de Proyecto, pu-diendo contar desde el comienzo con una planificación clara del trabajo arealizar.

48 Capítulo 5. Conclusiones

Programación de Microprocesadores: se utilizaron buenas prácticas de pro-gramación, especialmente aplicables al lenguaje C. Se implementó códigomodular, separado en archivos, con comentarios cuando fue necesario.

Ingeniería de Software en Sistemas Embebidos: fue posible generar especi-ficaciones de requerimientos, identificar casos de uso y aplicar patrones dediseño de software. Además, todo el código fuente fue documentado me-diante Git.

Arquitectura de Microprocesadores: se emplearon los conocimientos adqui-ridos sobre la arquitectura ARM Cortex M a fin de comprender las funcio-nes involucradas en el cambio de contexto. Asimismo, resultó de gran utili-dad conocer el esquema de interrupciones anidadas para configurar correc-tamente las prioridades de todas las fuentes de interrupción.

Sistemas Operativos de Tiempo Real (I y II): estas dos asignaturas fueronimprescindibles para diseñar correctamente las tareas como también los me-dios para comunicarlas y compartir datos.

Testing de Software en Sistemas Embebidos: se aplicaron herramientas deanálisis estático de código vistos durante la asignatura. Por otra parte, fue-ron relevantes los conocimientos relacionados con la realización de pruebasunitarias de software, ensayos de sistema y de aceptación.

5.2. Trabajo futuro

Como se estableció al comienzo de esta memoria, el dispositivo desarrollado essolamente un prototipo. Esto quiere decir que es factible que se deban realizarcambios en su diseño. En este sentido, se identificaron errores y oportunidadesde mejora aplicables tanto al hardware como al software, que deberían ser priori-zados en caso de que se desee continuar con este trabajo.

Si se considera el hardware del equipo, es necesario solucionar el problema queexiste en la línea de reset del chip de PHY. También se notó durante el desarrolloque dicho circuito integrado es propenso a trabajar a temperaturas elevadas, porlo que se debería incrementar la cantidad de cobre disponible debajo de él paraasistir en la disipación de calor. Por otro lado, se deben revisar los agujeros desujeción de la pantalla gráfica, ya que de utilizar separadores metálicos y aplicarun elevado torque durante su fijación, se podría causar un cortocircuito.

Desde el punto de vista del software, en primer lugar sería deseable actualizar laversión de FreeRTOS. Este trabajo fue realizado sobre la versión 7.5.3, mientrasque la versión actual es la 10.3.1. Adicionalmente, se identificó una oportunidadde mejora mediante la adición de separadores a las distintas pantallas que mues-tra el equipo. Por último, es posible optimizar aún más los recursos del sistema(memoria y uso del procesador) e incoporar un watchdog para mejorar la robustezdel equipo.

49

Bibliografía

[1] International Civil Aviation Organization. The World of Air Transport in2018. https://www.icao.int/annual-report-2018/Pages/the-world-of-air-transport-in-2018.aspx. 2018. (Visitado 2018).

[2] Regulaciones Argentinas de Aviación Civil - Parte 154, Diseño de aeródromos.2.a ed. RAAC 154. Administración Nacional de Aviación Civil. Mar. de2019.

[3] Normas y métodos recomendados internacionales - Anexo 14 al Convenio sobreAviación Civil Internacional, Volumen I, Diseño y operaciones de aeródromos.8.a ed. Anexo 14. Organización de Aviación Civil Internacional. Jun. de2018.

[4] Specification for Obstruction Lighting Equipment. 10.a ed. 150/5345-43J.Federal Aviation Administration. Mar. de 2019.

[5] Obstruction Marking and Lighting. 12.a ed. 70/7460-1L. Federal AviationAdministration. Abr. de 2015.

[6] FreeRTOS. Real-time operating system for microcontrollers.https://www.freertos.org/. 2020. (Visitado 2020).

[7] lwIP. A Lightweight TCP/IP stack.https://savannah.nongnu.org/projects/lwip/. 2019. (Visitado 2019).

[8] Broadcom Inc. AppCAD Design Assistant.https://www.broadcom.com/appcad. 2020. (Visitado 2020).

[9] lwIP Lightweight IP stack. HTTP server.https://www.nongnu.org/lwip/2_0_x/group__httpd.html. 2018.(Visitado 2018).

[10] Getting started with the LPCOpen Ethernet Examples. 1.a ed. DOC-332724.NXP Semiconductors. Sep. de 2016.

[11] Using the lwIP Network Stack. 1.a ed. AT04055. Atmel Corp. Mar. de 2014.[12] LwIP TCP/IP stack demonstration for STM32F2x7xx microcontrollers. 1.a ed.

AN3384. NXP Semiconductors. Oct. de 2011.

https://www.icao.int/annual-report-2018/Pages/the-world-of-air-transport-in-2018.aspx

https://www.icao.int/annual-report-2018/Pages/the-world-of-air-transport-in-2018.aspx

https://www.freertos.org/

https://savannah.nongnu.org/projects/lwip/

https://www.broadcom.com/appcad

https://www.nongnu.org/lwip/2_0_x/group__httpd.html

Controlador de balizamiento para turbinas...

Documents

Transcript of Controlador de balizamiento para turbinas...