escuela de ingeniería de telecomunicación y electrónica · 2020. 5. 17. · escuela de...

Escuela de Ingeniería de

Telecomunicación y Electrónica

Trabajo Fin de Máster

Diseño de un prototipo para la identificación dedrones mediante el sistema AIS

Titulación: Máster Universitario en Ingeniería deTelecomunicaciónAutor: D. Nicolás Molina PadrónTutores: Dr. Francisco José Cabrera Almeida

Dr. Víctor Alexis Araña PulidoFecha: Febrero de 2017





Hoja de Firmas

Firma de los tutores

Fdo.: Dr. Francisco JoséCabrera Almeida

Fdo.: Dr. Víctor AlexisAraña Pulido

Firma del alumno

Fdo.: D. Nicolás Molina Padrón

Fecha: Febrero de 2017





Hoja de Evaluación

Calificación:

Presidente Secretario Vocal

Fdo.: Fdo.: Fdo.:

Fecha: Febrero de 2017

We are what we pretend to be,so we must be careful about what we pretend to be.

Kurt Vonnegut

Agradecimientos

A mis padres y mi hermano, por apoyarme durante el transcurso de toda la carrera,

soportar mis nervios y malas caras constantes y aún así, seguir alegrándose cuando

traigo buenas noticias. Al resto de mi familia, que directa o indirectamente siempre

me han animado a alcanzar mis metas, y a mis amigos y amigas, que me permitían

desconectar un poco de los estudios cuando venían los picos de estrés.

A mis compañeros de clase, que sin duda fueron el apoyo que necesité para resistir

durante los momentos de mayor tensión en el máster. También a los compañeros del

IDeTIC, Jaime y Baltasar, que me ayudaron en la última etapa de este trabajo con

muchas ganas y paciencia.

A mis tutores Francis y Víctor, por toda la ayuda y las oportunidades que han

puesto a mi disposición un año más, y por las que siempre les estaré agradecido.

ix

Índice general

I Memoria 1

1. Introducción 3

1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4. Vinculaciones del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Sistemas UAV 11

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Descripción de la aeronave . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3. Descripción de la estación terrena . . . . . . . . . . . . . . . . . . . . . 18

2.4. Protocolo MAVLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.1. Tipos de datos y tramas MAVLink . . . . . . . . . . . . . . . . 20

2.4.2. Mensajes MAVLink . . . . . . . . . . . . . . . . . . . . . . . . . 22

xi

xii ÍNDICE GENERAL

3. Sistema AIS 25

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1. Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.2. Dispositivos comerciales . . . . . . . . . . . . . . . . . . . . . . 28

3.2. Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.1. Características radio y de enlace . . . . . . . . . . . . . . . . . . 30

3.2.2. Esquema de acceso al medio . . . . . . . . . . . . . . . . . . . . 31

3.2.3. Estructura de mensajes AIS . . . . . . . . . . . . . . . . . . . . 32

3.2.4. Tipos de mensajes AIS . . . . . . . . . . . . . . . . . . . . . . . 34

3.3. Estándar NMEA0183 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.2. Formato y tipos de mensajes . . . . . . . . . . . . . . . . . . . . 37

3.3.3. Ejemplos de mensajes NMEA . . . . . . . . . . . . . . . . . . . 38

4. Desarrollo del prototipo 41

4.1. Diagrama de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2. Transceptor AIS clase B . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.2. Conexiones de alimentación . . . . . . . . . . . . . . . . . . . . 43

4.2.3. Conexiones de interfaces serie . . . . . . . . . . . . . . . . . . . 44

ÍNDICE GENERAL xiii

4.2.4. Conexiones de RF . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.5. Configuración del dispositivo . . . . . . . . . . . . . . . . . . . . 46

4.3. Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.2. Microprocesador . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.3. Unidad de memoria . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.4. Interfaces de comunicación y alimentación . . . . . . . . . . . . 50

4.3.5. Configuración del dispositivo . . . . . . . . . . . . . . . . . . . . 52

4.4. Antena VHF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.5. Antena GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5. Integración del prototipo 59

5.1. Interconexionado hardware . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.1. Configuración del transpondedor AIS clase B . . . . . . . . . . . 61

5.1.2. Montaje del prototipo inicial . . . . . . . . . . . . . . . . . . . . 62

5.1.3. Integración del prototipo en un dron experimental . . . . . . . . 64

5.2. Firmware de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.1. Captura de valores angulares . . . . . . . . . . . . . . . . . . . . 66

5.2.2. Creación de mensaje HDT . . . . . . . . . . . . . . . . . . . . . 67

5.2.3. Envío de mensaje HDT por UART . . . . . . . . . . . . . . . . 68

xiv ÍNDICE GENERAL

6. Verificación y pruebas del sistema 71

6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2. Descripción de la instalación . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2.1. Arqueta de comunicaciones del IDeTIC . . . . . . . . . . . . . . 73

6.2.2. Servidor Linux del IDeTIC . . . . . . . . . . . . . . . . . . . . . 74

6.3. Verificación y pruebas del prototipo integrado . . . . . . . . . . . . . . 76

6.3.1. Verificación de mensajes AIS transmitidos y recibidos . . . . . . 77

6.3.2. Comparativa de resultados obtenidos a través de la API de Ma-

rineTraffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.3.3. Verificación mediante herramientas software de visualización de

tráfico marítimo . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7. Conclusiones 85

7.1. Resultados y revisión de objetivos . . . . . . . . . . . . . . . . . . . . . 85

7.2. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

II Presupuesto 93

Presupuesto 95

P.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

P.2. Costes de materiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

P.2.1. Materiales hardware . . . . . . . . . . . . . . . . . . . . . . . . 96

ÍNDICE GENERAL xv

P.2.2. Materiales software . . . . . . . . . . . . . . . . . . . . . . . . . 97

P.2.3. Otros conceptos de gastos materiales . . . . . . . . . . . . . . . 98

P.3. Amortización del inmovilizado material . . . . . . . . . . . . . . . . . . 98

P.4. Trabajo tarifado por tiempo empleado . . . . . . . . . . . . . . . . . . 100

P.5. Aplicación de impuestos y coste total . . . . . . . . . . . . . . . . . . . 101

III Anexos 103

A. Procedimiento de asignación de un identificador MMSI 105

B. Divulgación de resultados 109

C. Vistas del software proAIS2 121

D. Lista de códigos implementados 127

D.1. Generación y envío de mensajes HDT propios del prototipo . . . . . . . 127

D.2. Almacenamiento y filtrado de mensajes AIS recibidos del prototipo . . 129

Índice de figuras

1.1. Ejemplo de placa no estandarizada para la identificación de drones . . . 4

1.2. Monitorización de buques en Las Palmas de Gran Canaria, España . . 5

1.3. Diagrama de bloques del prototipo . . . . . . . . . . . . . . . . . . . . 7

1.4. Comunicaciones desde la estación AIS BMT-IDeTIC . . . . . . . . . . 8

2.1. Estructuras aerodinámicas de los UAVs . . . . . . . . . . . . . . . . . . 11

2.2. Clasificación de drones tipo multicóptero . . . . . . . . . . . . . . . . . 12

2.3. Ángulos de navegación en un UAV . . . . . . . . . . . . . . . . . . . . 13

2.4. Partes de la estructura de soporte de un dron . . . . . . . . . . . . . . 15

2.5. Conexiones en una unidad ESC de un dron . . . . . . . . . . . . . . . . 15

2.6. Batería LiPo Zippy 5000 20C . . . . . . . . . . . . . . . . . . . . . . . 16

2.7. Unidad de control de vuelo ArduPilot . . . . . . . . . . . . . . . . . . . 17

2.8. Unidad de telemetría de 3D Robotics para drones . . . . . . . . . . . . 18

2.9. Interfaz de Mission Planner . . . . . . . . . . . . . . . . . . . . . . . . 19

2.10. Interfaz de APM Planner . . . . . . . . . . . . . . . . . . . . . . . . . . 19

xvii

xviii ÍNDICE DE FIGURAS

2.11. Elementos en una comunicación UAV-estación terrena con MAVLink . 20

2.12. Formato de una trama MAVLink . . . . . . . . . . . . . . . . . . . . . 21

3.1. Proceso de comunicación compartida entre estaciones AIS . . . . . . . 27

3.2. Arquitectura OSI del sistema AIS . . . . . . . . . . . . . . . . . . . . . 30

3.3. Esquema de codificación y modulación en AIS . . . . . . . . . . . . . . 30

3.4. Campos de una trama AIS . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5. Tipos de esquema de acceso al medio en AIS en función del ámbito de

aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6. Estructura básica de un mensaje AIS . . . . . . . . . . . . . . . . . . . 33

3.7. Líneas de comunicación NMEA0183 genéricas para talker y listener . . 36

4.1. Diagrama de bloques del prototipo . . . . . . . . . . . . . . . . . . . . 41

4.2. Dimensiones y conectores del módulo Cobalt . . . . . . . . . . . . . . . 42

4.3. Pines del conector Hirose DF13-40P-1.25V del módulo Cobalt . . . . . 43

4.4. Indicadores LED en el módulo Cobalt SRT-Marine . . . . . . . . . . . 44

4.5. Conectores para las antenas de VHF y GPS del módulo Cobalt . . . . . 46

4.6. Placa BeagleBone Black . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7. Diagrama de bloques del procesador de la placa BeagleBone Black . . . 49

4.8. Conectores y botones de la placa BeagleBone Black . . . . . . . . . . . 50

4.9. Pinout de la placa BeagleBone Black . . . . . . . . . . . . . . . . . . . 51

ÍNDICE DE FIGURAS xix

4.10. Conexión, edición y ejecución de un script en Python para BeagleBone

Black . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.11. Configuración de rc.local para el lanzamiento automático de scripts . 53

4.12. Modelo de antena de VHF con banda magnética seleccionado . . . . . . 54

4.13. Modelo de antena de VHF Motorola PMAD4095A . . . . . . . . . . . . 55

4.14. Medidas adicionales del COE sobre las antenas de VHF utilizadas . . . 56

4.15. Modelo de antena de GPS Trimble 66800-52-SP . . . . . . . . . . . . . 57

5.1. Diagrama de bloques del prototipo inicial . . . . . . . . . . . . . . . . . 60

5.2. Diagrama de bloques del prototipo final . . . . . . . . . . . . . . . . . . 60

5.3. Conexión y configuración del módulo Cobalt con el software proAIS2 . 62

5.4. Conexiones entre los módulos del prototipo inicial . . . . . . . . . . . . 63

5.5. Montaje físico del prototipo inicial . . . . . . . . . . . . . . . . . . . . 63

5.6. Integración física del prototipo en un dron experimental . . . . . . . . . 64

5.7. Etapas del algoritmo para la creación y envío de un mensaje AIS tipo

HDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1. Instalación general del sistema de pruebas para el prototipo . . . . . . 72

6.2. Disposición de instalación de la arqueta de comunicaciones del IDeTIC 73

6.3. Conexiones en la estación receptora AIS BMT-IDeTIC dentro de la ar-

queta de comunicaciones del IDeTIC . . . . . . . . . . . . . . . . . . . 74

6.4. Flujo de ejecución de los scripts implementados . . . . . . . . . . . . . 76

xx ÍNDICE DE FIGURAS

6.5. Identificación del prototipo sobre la plataforma web de MarineTraffic . 83

6.6. Identificación del prototipo sobre el software OpenCPN . . . . . . . . . 83

C.1. Vista de configuración en proAIS2 . . . . . . . . . . . . . . . . . . . . . 122

C.2. Vista de monitorización de señal GNSS en proAIS2 . . . . . . . . . . . 123

C.3. Vista de monitorización de embarcaciones en proAIS2 . . . . . . . . . . 123

C.4. Vista de verificación de estado en proAIS2 . . . . . . . . . . . . . . . . 124

C.5. Vista de comandos recibidos y transmitidos en proAIS2 . . . . . . . . . 125

Índice de tablas

2.1. Características técnicas del módulo de telemetría de 3D Robotics . . . 18

2.2. Descripción de los campos del mensaje MAVLINK_MSG_ID_ATTITUDE . . 22

3.1. Periodo de actualización de mensajes AIS en función de la velocidad . . 34

3.2. Clasificación de los tipos de mensajes AIS . . . . . . . . . . . . . . . . 35

4.1. Limitaciones para las antenas de VHF y GPS en el módulo Cobalt . . . 46

4.2. Parámetros de la antena de VHF con base magnética para el módulo

Cobalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3. Parámetros de la antena de VHF Motorola PMAD4095A para el módulo

Cobalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4. Parámetros de la antena de GPS Trimble 66800-52-SP para el módulo

Cobalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1. Tramas NMEA contenidas en los mensajes AIS transmitidos por el pro-

totipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2. Muestra de mensajes AIS dinámicos decodificados y con formato tabular 79

6.3. Mensaje AIS tipo 18 del prototipo con campos de datos desglosados . . 80

xxi

xxii ÍNDICE DE TABLAS

6.4. Mensaje AIS tipo 24 del prototipo con campos de datos desglosados . . 80

6.5. Mensajes AIS obtenidos desde la API de MarineTraffic . . . . . . . . . 81

P.1. Costes de materiales fungibles hardware . . . . . . . . . . . . . . . . . . 96

P.2. Costes de materiales no fungibles software . . . . . . . . . . . . . . . . 97

P.3. Otros costes materiales . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

P.4. Costes asociados al inmovilizado material . . . . . . . . . . . . . . . . . 99

P.5. Trabajo tarifado por tiempo empleado . . . . . . . . . . . . . . . . . . 101

P.6. Costes totales del Trabajo Fin de Máster . . . . . . . . . . . . . . . . . 101

Resumen

El número de aplicaciones que involucran el uso de los drones o UAVs (Unmanned

Aerial Vehicle) se ha incrementado notablemente en los últimos años, obligando a

las autoridades gubernamentales de muchos países, entre ellas España, a establecer

regulaciones estrictas en materia de estas aeronaves. Estas normativas restringen el

uso de los drones en las ciudades, así como en zonas de confluencia aérea comercial,

con el objetivo de garantizar la seguridad de los ciudadanos y evitar un mal uso de

estas nuevas tecnologías.

En este sentido, la normativa española cuenta con algunos problemas no resueltos en

lo que respecta a la identificación de estas aeronaves. La normativa vigente indica que

todo UAV debe estar identificado con un número de serie y otros datos que permitan

reconocer al propietario de esta aeronave, pero no existe una solución estándar a este

problema. Tradicionalmente, la solución más común consiste en incorporar una placa

de identificación en el fuselaje de la aeronave, aunque no resulta una solución óptima

cuando el UAV está realizando una operación de vuelo. Por ello, existe la necesidad

de encontrar un sistema inalámbrico que permita la identificación remota de estos

dispositivos.

Una posible solución a este problema radica en el sistema AIS (Automatic Identi-

fication System), un sistema de comunicaciones marítimas por radiofrecuencia que se

emplea para la identificación de buques y conocer sus parámetros más significativos,

como son la velocidad o el rumbo. Cada embarcación que integra este sistema es capaz

de identificarse de forma unívoca con un código denominado MMSI (Maritime Mobile

Service Identity), y luego transmitir y recibir datos sobre el resto de embarcaciones.

xxiii

xxiv ÍNDICE DE TABLAS

De esta manera, es posible evitar colisiones y además, conocer el estado del tráfico

marítimo en todo momento.

Para ello, el IDeTIC (Instituto para el Desarrollo Tecnológico y la Innovación en

Comunicaciones) propone en este trabajo el aprovechamiento del sistema AIS para

la identificación de drones mediante la integración de un prototipo embarcado en un

dron experimental, permitiendo identificar a la aeronave y transmitir sus parámetros

más significativos de forma autónoma. Esta solución, que presenta numerosas ventajas

en términos de alcance y costes económicos, permite sustituir el método tradicional

para la identificación de drones adoptado en la actualidad, solventando los principales

problemas que derivan de esta solución.

Tras la implementación y verificación del prototipo, las pruebas llevadas a cabo

muestran resultados satisfactorios que permiten concluir la viabilidad del prototipo y

las virtudes que supone la adopción de este sistema a nivel comercial. Por ello, más

allá de los resultados expuestos en este trabajo, se plantean futuras mejoras de este

prototipo para lograr una mayor repercusión social que motive la sustitución definitiva

del método de identificación tradicional de UAVs.

Palabras clave: AIS (Automatic Identification System), Dron, MMSI (Maritime

Mobile Service Identity), Prototipo, UAV (Unmanned Aerial Vehicle).

Abstract

The number of applications which involve the use of drones or UAVs (Unmanned

Aerial Vehicle) has increased significantly in the last years, and this fact has coerced the

governments of many countries, for instance Spain, into establishing strict regulations

for these aircrafts. These regulations restrict the use of drones in the cities, as well as

air confluence areas, and so guarantee the citizens’ security and avoid the wrong use

of this technology.

In this sense, the Spanish regulation has some problems which have not been solved

yet with regards to the UAVs identification. The current regulation shows that every

UAV must be identified with a serial number and other data which allow to know the

owners of these aircrafts, but there is not a standardised solution for this problem.

Traditionally, the common solution consists of a identification plate embedded in the

drone’s fuselage, but this is not the optimal solution when the UAV is flying. For this

reason, there exists a need to find a wireless system to allow the remote identification

of these devices.

A possible solution to this problem is AIS (Automatic Identification System), a

marine radiocommunication system which is used for vessels identification and to know

the most meaningful parameters, such as speed or course. Each vessel which integrates

this system can be able to identify itself uniquely by means of a code named MMSI

(Maritime Mobile Service Identity), and then transmit and receive data about the other

vessels. In this way, it is possible to avoid collisions and moreover, to know the state

of marine traffic at all times.

xxv

xxvi ÍNDICE DE TABLAS

For that purpose, IDeTIC (Instituto para el Desarrollo Tecnológico y la Innovación

en Comunicaciones) proposes in this research project an exploitation of AIS system to

identify UAVs by means of an embedded prototype in an experimental drone, which

enables to identify itself and transmit the most important parameters autonomously.

This solution, that has a lot of advantages in terms of range and price, allows to

substitute the traditional method for drones identification that is used nowadays, and

solves the main problems which entangles the previous solution.

After the implementation and verification of the prototype, the tests carried out

show successful results which allow to conclude that this prototype is suitable and

show the potential benefits of adopting this system for commercial applications. For

these reasons, beyond the results which have been obtained in this work, some future

improvements for this prototype have raised to achieve a higher impact and so, propel

the definitively substitution of the tradicional method for UAV identification.

Keywords: AIS (Automatic Identification System), Drone, MMSI (Maritime Mobile

Service Identity), Prototype, UAV (Unmanned Aerial Vehicle).

Acrónimos

Siglas Descripción

ADC Analog-to-Digital Conversion

AIS Automatic Identification System

API Application Programming Interface

AtoN Aids-to-Navigation

COE Coeficiente de Onda Estacionaria

COG Course Over Ground

CSTDMA Carrier-Sense Time Division Multiple Access

CSV Comma-Separated Values

DDR3 Double Data Rate type three Synchronous Dynamic

Random-Access Memory

eMMC Embedded Multi-Media-Card

ESC Electronic Speed Control

FATDMA Fixed-Access Time Division Multiple Access

FM Frequency Modulation

GMSK Gaussian Minimum-Shift Keying

GNSS Global Navigation Satellite System

GPIO General Purpose Input/Output

GPS Global Positioning System

HDMI High-Definition Multimedia Interface

HDOP Horizontal Dilution of Precision

HDT Heading True

I2C Inter-Integrated Circuit

xxvii

xxviii ÍNDICE DE TABLAS

IDeTIC Instituto para el Desarrollo Tecnológico y la Innovación en

Comunicaciones

IMO International Maritime Organization

IMU Inertial Measurement Unit

IP Internet Protocol

ITDMA Incremental Time Division Multiple Access

ITU International Telecommunication Union

LiPo Lithium Polymer

MISO Master Input Slave Output

MMSI Maritime Mobile Service Identity

MOSI Master Output Slave Input

NMEA National Marine Electronics Association

NRZI Non-Return to Zero Inverted

OSI Open System Interconnection

PWM Pulse-Width Modulation

RATDMA Random Access Time Division Multiple Access

RF Radio Frequency

RISC Reduced Instruction Set Computer

SAR Search and Rescue

SART Search and Rescue Transponder

SFTP SSH File Transfer Protocol

SPI Serial Peripheral Interface

SPS Standard Positioning Service

SOG Speed Over Ground

SOLAS Safety of Life at Sea

SOTDMA Self-Organized Time Division Multiple Access

SRAM Static Random Access Memory

SSH Secure Shell

TDMA Time Division Multiple Access

UART Universal Asynchronous Receiver-Transmitter

UAV Unmanned Aerial Vehicle

USB Universal Serial Bus

ÍNDICE DE TABLAS xxix

UTC Universal Time Coordinated

VHF Very High Frequency

WGS84 World Geodetic System 84

Parte I

Memoria

1

Capítulo 1

Introducción

1.1. Antecedentes

En los últimos años, el creciente interés que ha despertado el uso de los vehículos

aéreos no tripulados o UAV (Unmanned Aerial Vehicle) ha supuesto un impacto crucial

en numerosos ámbitos de la sociedad. Esta tecnología, que inicialmente estaba única-

mente a disposición de las autoridades militares [1], es utilizado hoy día para múltiples

propósitos relacionados con el ámbito empresarial o el ocio, ya que facilitan ciertas

labores de automatización de procesos o para operaciones vigilancia en las ciudades,

entre otras aplicaciones [2].

Sin embargo, la inmersión de los UAVs o drones en la sociedad actual puede derivar

en un uso inapropiado de los mismos. Desde hace algunos años, subyace una preocupa-

ción sobre el uso de esta tecnología para apoyar operaciones terroristas o de vigilancia

no autorizada sobre la población [3]. En este sentido, los gobiernos de numerosos países

han establecido leyes que garantizan la privacidad de los ciudadanos mediante la res-

tricción de uso de estos dispositivos. En el caso de España, los drones son regulados en

virtud del Real Decreto-Ley 8/2014 [4] y el Artículo 50 de Ley 18/2014 [5], que esta-

blecen el marco jurídico aplicable a este tipo de aeronaves para garantizar la seguridad

aérea y permitir, a su vez, el auge de estas tecnologías en beneficio de la ciudadanía.

De esta manera, se establecen los términos que debe cumplir el propietario de un UAV,

la zona de operación, el peso máximo e incluso, la identificación de la aeronave.

3

4 1.1. Antecedentes

La vigente normativa española en materia de UAVs establece que toda aeronave civil

pilotada de forma remota debe incorporar algún elemento que permita identificarla, así

como el número de serie y la empresa operadora de la aeronave como contacto. Sin

embargo, la legislación no ha alcanzado una estandarización del método empleado por

los usuarios de drones para identificar sus dispositivos, y de forma tradicional se ha

utilizado una placa metálica solapada al fuselaje del dron, donde se incluyen los datos

obligatorios que fija la normativa (figura 1.1).

Fabricante:

Modelo:

Número de serie:

Empresa operadora:

Datos de contacto:

Figura 1.1: Ejemplo de placa no estandarizada para la identificación de drones

Sin embargo, este método resulta ineficiente cuando el dron se encuentra sobrevo-

lando una zona no autorizada o que induce un riesgo sobre la seguridad, como puede

ocurrir en las áreas próximas a los aeropuertos, que en el peor de los casos obliga a las

autoridades a abatirlo. En este sentido, el método tradicional resulta tedioso, además

de una solución primitiva en comparación con los sistemas inalámbricos.

La estricta regulación en materia de drones no ha mermado el interés por esta nue-

va tecnología, sino que ha propiciado que un gran número de investigadores evalúen el

uso de los UAVs como apoyo sobre sus proyectos, tanto en el sector empresarial como

académico. Entre los centros españoles que estudian la tecnología UAV se encuentra

el IDeTIC (Instituto para el Desarrollo Tecnológico e Innovación en Comunicaciones),

que desde 2011 ha centrado parte de su actividad en el desarrollo de proyectos nacio-

nales y europeos donde los drones basados en la tecnología de 3D Robotics [6] son el

componente crucial. En virtud de estos proyectos, el IDeTIC ha planteado numerosas

aplicaciones que implican el uso de drones, desde tecnología RF para drones ligeros [7]

hasta sistemas aéreos para el seguimiento de líneas de fuego [8], y sobre estas aplica-

ciones se han propuesto diversas ofertas de Trabajos Fin de Título [9] [10] [11] [12] que

han permitido consolidar los conocimientos adquiridos acerca de la tecnología UAV.

1. Introducción 5

Es por ello que el IDeTIC, atendiendo a la ausencia de estandarizaciones para el

método de identificación de drones, plantea en este Trabajo de Fin de Máster una

alternativa al método tradicional utilizado para este propósito. Para ello, se combina

la línea de trabajo de los UAVs con una línea incipiente que aborda el IDeTIC desde

2014, que es el sistema AIS.

El sistema AIS (Automatic Identification System) es un estándar para las comuni-

caciones marítimas ubicado en la banda de VHF marina [13], que permite obtener los

parámetros característicos de los buques que lo integran, como son la velocidad o la

posición, entre otros (figura 1.2). Este sistema es de uso obligatorio desde 2003, cuando

la IMO (International Maritime Organization), en relación al Convenio SOLAS (Safety

of Life at Sea), establece que cualquier embarcación que supere un tonelaje bruto supe-

rior a 500 toneladas, 300 toneladas y que realice travesías internacionales o destinadas

al transporte de pasajeros, debe incluir un transpondedor AIS abordo para monitorizar

su actividad y así evitar posibles colisiones o desastres en alta mar [14].

Figura 1.2: Monitorización de buques en Las Palmas de Gran Canaria, España

Cuando una embarcación quiere incorporarse en el sistema AIS necesita obtener un

identificador único denominado MMSI (Maritime Mobile Service Identity). Se trata de

un código de 9 dígitos provisto por la autoridad marítima correspondiente del país de

origen de la embarcación, que en el caso de España corresponde a la Dirección General

de la Marina Mercante, que asigna un MMSI a una embarcación tras el pago de las

tasas correspondientes que fija el Ministerio de Fomento [15].

6 1.2. Objetivos

Desde 2013, el IDeTIC (Instituto para el Desarrollo Tecnológico e Innovación en

Comunicaciones) mantiene un convenio marco con WoW Group, empresa matriz de

la compañía MarineTraffic, líder en la monitorización de buques a través del sistema

AIS. Gracias a este convenio, el IDeTIC posee una estación de monitorización AIS

denominada BMT-IDeTIC instalada en el Campus de Tafira (Gran Canaria, España),

que tiene acceso a la red de MarineTraffic y sirve como nodo para la monitorización de

buques que navegan cerca de las costas de la isla de Gran Canaria.

En base al convenio con MarineTraffic, el IDeTIC ha comenzado a evaluar las

posibilidades que ofrece el sistema AIS [16], y en combinación con la amplia experiencia

que ha adquirido este instituto de investigación en materia de drones, se plantea el

desarrollo de este proyecto. Con ello, se pretende desarrollar un sistema embarcado

en drones basado en el sistema AIS, que permita al dron identificarse incluso cuando

se encuentre en el aire, de forma que sea una alternativa al método tradicional que

se emplea en virtud de la normativa española. Además, los primeros planteamientos

de este proyecto han sido acogidos favorablemente a través del concurso de ideas de

la Primera Convocatoria de Premios Talento y Compromiso CajaSiete 2015, donde se

obtuvo el primer premio [17].

1.2. Objetivos

El principal objetivo de este Trabajo Fin de Máster consiste en desarrollar un proto-

tipo basado en el sistema AIS que, al ser integrado sobre un dron experimental, permita

que el dispositivo pueda enviar su propia identificación al resto de estaciones AIS, ade-

más de otros parámetros del dron, como puede ser el rumbo. Para ello, el prototipo es

capaz de generar comandos NMEA particulares con datos del dron, obtenidos a través

de la información paramétrica que envía la aeronave a través del protocolo MAVLink.

En la figura 1.3 se presenta el diagrama de bloques del prototipo, donde se muestra

una visión general de los principales módulos que integran el prototipo y su relación

con el dron experimental.

1. Introducción 7

PILOTO AUTOMÁTICODEL UAV MICROCONTROLADOR TRANSCEPTOR AIS

CLASE B ANTENAVHF

ANTENAGPS

Figura 1.3: Diagrama de bloques del prototipo

Cuando el prototipo envía sus datos, la estación receptora AIS BMT-IDeTIC, ins-

talada en el Campus de Tafira, recoge estos datos y los empaqueta para posteriormente

enviarlos por la red. De esta manera, los datos de red se envían a un socket del servi-

dor de MarineTraffic, asignado previamente al IDeTIC por esta entidad. Una vez los

datos son almacenados en el servidor de MarineTraffic, son procesados y filtrados para

obtener únicamente aquellos valores que son de interés comercial, y a través de una

API (Application Programming Interface) propia de MarineTraffic pueden llegar a los

usuarios de MarineTraffic. En el caso del IDeTIC, se hace uso de un servidor Linux

donde se almacenan estos datos con ayuda de un grupos de scripts. De esta manera,

es posible acceder a estos datos mediante una conexión SSH (Secure Shell) al servidor

Linux del IDeTIC, presentándose los datos en la terminal de comandos de UNIX, aun-

que la opción más rápida consiste en conectarse al servidor SFTP (SSH File Transfer

Protocol) propio del IDeTIC y acceder a los ficheros donde están alojados los datos

enviados por la API de MarineTraffic.

Además, durante la elaboración de este Trabajo Fin de Máster se ha instalado una

placa Raspberry Pi en la arqueta de comunicaciones en la que se ubica la estación

AIS BMT-IDeTIC, que al conectarse al puerto serie del receptor AIS permite acceder

a los datos que realmente recibe el receptor, y no aquellos que MarineTraffic muestra

en su API. De este modo, es posible activar y configurar la Raspberry Pi a través de

una conexión remota vía Telnet y posteriormente, extraer los datos sin tratamiento

que recibe la estación AIS BMT-IDeTIC y almacenarlos en ficheros sobre el servidor

Linux del IDeTIC, entre los que se encuentra la información emitida por el prototipo

diseñado (figura 1.4).

8 1.3. Estructura de la memoria

Receptor AISBMT-IDeTIC

Servidor deMarineTrafficInternet

Procesado y tratamientode los datos AIS recibidos

Socket paraBMT-IDeTIC

Socket paraotras estacionesConexión

Ethernet

Ordenadorpersonal

ConexiónSFTP

ConexiónSSH

Peticiónde acceso

Descargade datos

APIMarineTraffic

Raspberry Pi 3

Servidor Linuxdel IDeTIC

USB

Telnet

Ethernet

Figura 1.4: Comunicaciones desde la estación AIS BMT-IDeTIC

Por último, el prototipo desarrollado se embarca en un dron experimental para es-

tudiar su viabilidad de integración sobre estas aeronaves, haciendo uso de la instalación

previamente comentada para la realización de las pruebas necesarias para alcanzar los

objetivos de este Trabajo Fin de Máster.

1.3. Estructura de la memoria

La memoria de este Trabajo Fin de Máster se organiza en función de siete capítulos,

cuya temática se describe de forma breve en los siguientes puntos:

Capítulo 1: se detallan los motivos y antecedentes que justifican el desarrollo

de este trabajo, así como los objetivos planteados y la organización temática de

la memoria.

Capítulo 2: se introducen los conceptos fundamentales sobre los vehículos aéreos

no tripulados, que son utilizados durante el resto de la memoria.

Capítulo 3: se introducen los conceptos fundamentales sobre el sistema AIS, que

son utilizados durante el resto de la memoria.

1. Introducción 9

Capítulo 4: se presenta el diagrama de bloques del prototipo, junto a los módulos

que lo componen y la descripción técnica asociada a estos dispositivos.

Capítulo 5: se explica la interconexión entre los módulos del prototipo y la

programación de su firmware de control.

Capítulo 6: se describen las pruebas llevadas a cabo para verificar el funcio-

namiento del prototipo, además de la infraestructura necesaria para apoyar las

medidas llevadas a cabo.

Capítulo 7: se detallan los resultados obtenidos y las conclusiones alcanzadas

en virtud de los objetivos planteados, además de darse una visión global sobre

las posibles líneas futuras que pueden originarse a partir de este prototipo.

Además, se incluye la bibliografía empleada y el presupuesto que conlleva la ejecu-

ción de este Trabajo Fin de Máster. Del mismo modo, se incluyen como anexos toda

aquella información relevante que no se detalla durante la redacción de los capítulos

de esta memoria.

1.4. Vinculaciones del proyecto

Se hace constar en este documento que parte del contenido y/o resultados que se

presenten en este Trabajo Fin de Máster están sujetos a cláusulas de confidencialidad

con la empresa MarineTraffic, lo que se declara a los efectos oportunos en virtud del

vigente Reglamento de Trabajos Fin de Título de la Escuela de Ingeniería de Teleco-

municación y Electrónica de la Universidad de Las Palmas de Gran Canaria.

Capítulo 2

Sistemas UAV

2.1. Introducción

Se conoce como UAV (Unmanned Aerial Vehicle) o dron a una aeronave que puede

realizar diferentes tareas en vuelo sin necesidad de ser manejada por un piloto humano

[18]. De esta manera, el usuario puede modificar el movimiento del dron a través de

un protocolo de comunicación compartido entre el dron y una estación terrena de

control. Además, estos vehículos aéreos suelen clasificarse en función de su estructura

aerodinámica en tipo avión, con una estructura de aeronave de ala fija y orientados

principalmente hacia usos militares, y tipo multicóptero, con una estructura de aeronave

de ala rotatoria y utilizados en ámbitos muy diversos, como indica la figura 2.1.

(a) UAV tipo avión (b) UAV tipo multicóptero

Figura 2.1: Estructuras aerodinámicas de los UAVs

11

12 2.1. Introducción

En lo que respecta a los drones tipo multicóptero, es importante señalar que existe

otra clasificación en función del número de elementos rotatorios que presente. En la

figura 2.2 se presentan algunos de estos dispositivos, clasificados a razón de su número

de rotores como simples o dobles.

Tricóptero simple Cuadricóptero simple Hexacóptero simple

Octacóptero simple Tricóptero dedoble rotor

Cuadricóptero dedoble rotor

Figura 2.2: Clasificación de drones tipo multicóptero

Al igual que ocurre con cualquier aeronave, un dron está sujeto a tres movimientos

angulares en el espacio, denominados ángulos de navegación, y son yaw, pitch y roll

[19], tal y como se presenta en la figura 2.3, y cumplen las siguientes características:

Yaw. También llamado guiñada, es el movimiento angular sobre el eje vertical

perpendicular a la aeronave, y permite conocer el rumbo de la misma.

Pitch. También llamado cabeceo, es el movimiento angular sobre el rumbo de la

aeronave, que puede marcar su inclinación por delante o por detrás, indicando si

se encuentra en ascenso o descenso.

Roll. También llamado alabeo, es el movimiento angular sobre el rumbo de la

aeronave, que marca la inclinación a izquierda o derecha de las alas o los rotores, y

permite a la aeronave sortear obstáculos o estabilizar su vuelo frente a condiciones

ambientales adversas.

2. Sistemas UAV 13

Yaw

Pitch

Roll

Figura 2.3: Ángulos de navegación en un UAV

En la actualidad, los drones tipo multicóptero gozan de autonomía suficiente para

desempeñar las tareas que un usuario les planifique. En este sentido, la automatización

de los UAVs es el factor primordial que persiguen las empresas de base tecnológica que

emplean esta tecnología, lo que trasciende en un gran número de aplicaciones, tanto

civiles como militares, donde el uso de estos dispositivos comienza a ser indispensa-

ble para determinadas tareas. Sin embargo, el principal problema que presenta esta

tecnología radica en la eficiencia y duración de las baterías, y sobre este aspecto, el

IDeTIC mantiene un convenio con la compañía WSN para evaluar nuevos métodos que

favorezcan la autonomía energética de estos dispositivos [20].

En lo que respecta al ámbito comercial, la compañía 3D Robotics se sitúa en los

primeros ranking de ventas de la tecnología UAV, principalmente en la gama de drones

multicópteros. Esta compañía opera desde 2007 y es pionera en la democratización

de los drones, dado que entre su línea de productos destacan los equipos de montaje

por piezas de drones, que no solamente permiten al usuario adquirir destreza en el

montaje de drones, sino que ofrece total libertad para modificar los diseños iniciales

hasta conseguir la unidad de vuelo que el usuario desee. Además, 3D Robotics mantiene

unos precios considerables en su gama de productos, ya que no solamente pretende

que estos drones sean utilizados en entornos empresariales o académicos, sino incluso

como entretenimiento, ofertando también piezas de recambio y módulos adicionales

compatibles con sus modelos.

14 2.2. Descripción de la aeronave

2.2. Descripción de la aeronave

Los drones están diseñados para cumplir tareas similares a las que haría una aerona-

ve de pequeño tamaño, facilitando su control y despliegue. Por ello, puede desgranarse

en cinco elementos fundamentales sobre una misma estructura física, que son:

Estructura de soporte.

Unidades de propulsión y sustentación.

Unidad de alimentación.

Controlador de vuelo.

Módulo de comunicaciones vía radio.

A continuación, se explica cada uno de estos elementos del dron desde la óptica de

la tecnología desarrollada por 3D Robotics, dado que no solamente es la que mayor

extensión de uso presenta hoy día, sino que además el grupo de investigación en materia

de UAVs del IDeTIC utiliza los productos de este fabricante para desarrollar diversas

aplicaciones embarcadas en drones multicópteros.

Estructura de soporte

Cada dron está conformado por una estructura metálica o de fibra de carbono que

le permite sostener el resto de elementos necesarios para su funcionamiento. De este

modo, la estructura de soporte está formada por tres partes fundamentales (figura 2.4):

Brazos. Permiten soportar la unidad de propulsión y sustentación del dron, o lo

que es lo mismo, sus rotores y hélices.

Patas. Se encargan de mantener la estabilidad del dron en tierra cuando se

produzca el aterrizaje o al inicio del vuelo.

Bandeja central. Permiten alojar la unidad de control del dron, así como el

módulo de comunicaciones, de alimentación y la carga de pago que transporta

este dispositivo.

2. Sistemas UAV 15

Brazos Bandeja central

Patas

Figura 2.4: Partes de la estructura de soporte de un dron

Unidades de propulsión y sustentación

Los drones vuelan gracias al movimiento de los rotores que se alojan en los brazos

de su estructura de soporte. Cada uno de estos elementos de propulsión y sustenta-

ción están constituidos por un motor y las hélices, activos a partir de la unidad de

alimentación de la aeronave y que se controlan por medio de una unidad denominada

ESC (Electronic Speed Control), que entrega al motor las revoluciones necesarias para

iniciar, mantener o finalizar la etapa de vuelo del dispositivo de manera adaptable, tal

y como se representa en el esquema de la figura 2.5.

Rotor

ESC Batería LiPo

ArduPilot

Figura 2.5: Conexiones en una unidad ESC de un dron

16 2.2. Descripción de la aeronave

Unidad de alimentación

Normalmente, la alimentación de un multicóptero está basada en baterías tipo

LiPo (Lithium Polymer), como es el caso de las baterías Zippy 5000 20C (figura 2.6),

constituidas por tres celdas que entregan un voltaje de 11.1 V mediante una conexión

con el módulo ArduPilot por el puerto Power port, con una capacidad de 5000 mAh.

Figura 2.6: Batería LiPo Zippy 5000 20C

Estas baterías tienen la ventaja de ser lo suficientemente ligeras como para no

incurrir en un peso excesivo sobre el dron, además de tener una gran capacidad de

almacenamiento de carga. A pesar de ello, su coste en el mercado suele ser superior al

de otros modelos también utilizados en estos drones, y tanto el tiempo de autonomía

como el de vida de estas baterías suele ser inferior al de otros modelos comerciales [21].

Controlador de vuelo

El controlador de vuelo de un dron es la unidad que permite automatizar las fun-

ciones de guiado de la aeronave sin necesitar la intervención de seres humanos, es decir,

que mediante un sistema electrónico con acceso a las funciones electromecánicas del

dron, es posible automatizar o controlar su movimiento y las tareas que se le quieran

planificar.

Para ello, la solución comercial más extendida en la actualidad se basa en la pla-

taforma ArduPilot (figura 2.7). Se trata de un dispositivo basado en la plataforma de

microcontroladores Arduino MEGA 2560 que, a través de un firmware open source

denominado Arducopter toma el control de la unidad inercial o IMU (Inertial Mea-

surement Unit) del dron a través del protocolo de comunicación que comparte con la

estación terrena.

2. Sistemas UAV 17

Figura 2.7: Unidad de control de vuelo ArduPilot

En este sentido, el controlador de vuelo controla la estabilización y navegación

autónoma del dron haciendo uso de una unidad GPS integrada en la aeronave. Con

ello, la plataforma ArduPilot presenta un gran número de ventajas que la establecen

como una de las principales opciones que toman los usuarios de drones para incorporar

la unidad de control de vuelo en sus dispositivos, y son las siguientes:

Sencillez en la instalación y configuración del firmware.

Permite realizar misiones basadas en waypoints, sin necesidad de la intervención

humana.

Soporta hasta 8 canales de radiocontrol, 4 puertos serie y 2 vías de telemetría

sobre un mismo módulo compacto.

Compatibilidad con estaciones terrenas gratuitas.

Configuración de despegue y aterrizaje autónomos.

Módulo de comunicaciones vía radio

Con el objetivo de comunicar datos de monitorización del dron a la estación terrena,

es necesario incorporar una unidad de telemetría que transmita y reciba comandos

según el protocolo de comunicación fijado entre el dron y la estación terrena. Uno de

los modelos comerciales de unidad de telemetría más utilizados en materia de drones

son los proporcionados por 3D Robotics (figura 2.8), que cumplen las características

recogidas en la tabla 2.1.

18 2.3. Descripción de la estación terrena

Figura 2.8: Unidad de telemetría de 3D Robotics para drones

Tabla 2.1: Características técnicas del módulo de telemetría de 3D Robotics

Parámetro ValorFrecuencia 433 MHzAlimentación en transmisión 3.7 – 6 V, 100 mAAlimentación en recepción 3.7 – 6 V, 25 mAVelocidad de transmisión por radio 57.6 MbpsVelocidad de transmisión por cable 115.2 Mbps

2.3. Descripción de la estación terrena

La estación terrena consta de un software que permite la configuración, control y

monitorización del dron por medio de un protocolo de comunicaciones, que en el caso

de los multicópteros suele ser MAVLink. En este sentido, en el mercado hay distintas

opciones para implementar una estación terrena software, siendo las más habituales

Mission Planner y APM Planner.

La estación terrena Mission Planner es la plataforma más utilizada con el con-

trolador de vuelo ArduPilot. Se trata de una plataforma basada en software libre,

únicamente disponible para Windows, que permite realizar operaciones en el dron tan-

to en el momento del vuelo como previamente (si es necesario modificar determinados

parámetros para corregir su vuelo) o tras el aterrizaje (lo que permite revisar los pa-

2. Sistemas UAV 19

rámetros de vuelo y así corregir los posibles fallos que se produzcan). De esta manera,

está habilitada para diferentes funcionalidades, entre las que destacan las siguientes:

Introducir waypoint de Google Earth u otras plataformas similares.

Configurar los ajustes del ArduPilot y cargar el firmware, en la versión que se

desee.

Seleccionar los comandos de misión mediante desplegables.

Descargar los archivos de vuelo para su posterior análisis.

Simular el vuelo del dron por medio de una interfaz gráfica ejecutada desde un

ordenador personal.

Por otro lado, la estación terrena APM Planner es una plataforma de software libre

y disponible tanto para Windows como UNIX, con funcionalidades muy similares a

las de Mission Planner y sin modificar en gran medida su interfaz, tal y como puede

compararse en las figuras 2.9 y 2.10.

Figura 2.9: Interfaz de Mission Planner Figura 2.10: Interfaz de APM Planner

2.4. Protocolo MAVLink

El protocolo MAVLink (Micro Air Vehicle Link) es una biblioteca de mensajes que

se utiliza para establecer un canal de comunicación entre un UAV y una estación base

[22], tal y como se refleja en la figura 2.11.

20 2.4. Protocolo MAVLink

Estación terrena Unidad UAV

Unidad de telemetría dela estación terrena

Unidad de telemetría dela unidad UAV

Software de controlde vuelo ArduPilot

Figura 2.11: Elementos en una comunicación UAV-estación terrena con MAVLink

Este protocolo puede utilizar determinadas funciones en un dispositivo integrado en

un UAV y que va a recibir o enviar datos a la aeronave. De esta forma, permite importar

cabeceras de ficheros sobre los scripts propios que ejecuta el dispositivo integrado en el

dron, y de esta manera, extraer la información de la aeronave en todo momento. Estos

ficheros están escritos en el lenguaje C, pero a través de una herramienta software

llamada wrapper puede compatibilizar la programación en C con otros lenguajes de

programación, como puede ser Python o Ruby. Por tanto, MAVLink es capaz de enviar

tramas de datos a través del puerto serie hacia la estación terrena o hacia el UAV,

permitiendo al usuario crear mensajes personalizados a los que se les asocia un código

con una o más funciones.

2.4.1. Tipos de datos y tramas MAVLink

Los tipos de datos con los que trabaja el protocolo MAVLink son caracteres (char),

variables sin signo de 8 bits (uint8_t, int8_t), 16 bits (uint16_t, int16_t), 32 bits

(uint32_t, int32_t) y 64 bits (uint64_t, int64_t), y números en coma flotante de

32 bits (float) y 64 bits (double), además de un tipo de variable sin signo de 8 bits

propio de MAVLink que se rellena automáticamente, sin posibilidad de ser editado

(uint8_t_MAVLink_version).

A partir de estos tipos, el protocolo MAVLink puede intercambiar tramas o paquetes

con una longitud comprendida entre 8 y 263 bytes, donde cada campo lo compone un

byte dispuesto en una cadena de bytes que marca, a grandes rasgos, las cabeceras de

la trama, el payload y el checksum, tal y como se indica en la figura 2.12.

2. Sistemas UAV 21

SXT LEN SEQ SYS COMP MSG Payload CKA CKB

Trama MAVLink (8 - 263 bytes)

Figura 2.12: Formato de una trama MAVLink

A continuación, se especifica el significado de cada uno de los campos que aparecen

en la figura 2.12 y que presenta una trama MAVLink :

STX, indica el comienzo de una nueva trama, pudiendo tomar los valores en he-

xadecimal 0xFE y 0x55, dependiendo de la versión de MAVLink.

LEN, indica el tamaño del payload, y puede tomar valores entre 0 y 255.

SEQ, indica la secuencia de la trama y permite saber si se ha perdido algún

paquete, tomando valores entre 0 y 255.

SYS, es el identificador del sistema, es decir, del UAV o de la estación terre-

na, dependiendo cuál de los dos sistemas envía la trama. Puede tomar valores

comprendidos entre 1 y 255.

COMP, es el identificador del componente, es decir, de las unidades embarcadas en

el dron o conectadas con la estación terrena. Puede tomar valores comprendidos

entre 0 y 255.

MSG, indica el número del identificador del mensaje, marcando el significado del

payload y cómo debe ser decodificado. Puede tomar valores comprendidos entre

0 y 255.

Payload, señala la información que se desea transmitir en el paquete MAVLink,

y puede tomar valores comprendidos entre 0 y 255.

CKA y CKB son los valores del checksum asociado a la trama MAVLink para su

verificación de envío.

22 2.4. Protocolo MAVLink

2.4.2. Mensajes MAVLink

La biblioteca de MAVLink integra un total de 108 mensajes específicos para UAV

que permiten extraer determinados parámetros del dron [23], como puede ser su po-

sición, la velocidad en cada una de las direcciones marcadas en un sistema de ejes

cartesianos o sus ángulos de navegación. Sin embargo, en virtud de los objetivos de

este Trabajo Fin de Máster, en este apartado solamente se evalúa un tipo de mensaje

que permite extraer la información de los ángulos de navegación del UAV, denominado

MAVLINK_MSG_ID_ATTITUDE.

El mensaje MAVLINK_MSG_ID_ATTITUDE tiene el identificador 30 en la biblioteca

MAVLink. Este mensaje permite extraer los valores de los ángulos de navegación del

UAV expresados en radianes, así como la velocidad angular en radianes por segundo,

tal y como se indica en la tabla 2.2.

Tabla 2.2: Descripción de los campos del mensaje MAVLINK_MSG_ID_ATTITUDE

Campo Tipo Descripción

time_boo_ms uint32_tTiempo en milisegundos desde que arranca el bootdel sistema.

roll floatValor angular del roll, expresado en radianes y convalores comprendidos entre +π y −π.

pitch floatValor angular del pitch, expresado en radianes ycon valores comprendidos entre +π y −π.

yaw floatValor angular del yaw, expresado en radianes y convalores comprendidos entre +π y −π.

rollspeed floatVelocidad angular sobre el roll, expresada en ra-dianes por segundo.

pitchspeed floatVelocidad angular sobre el pitch, expresado en ra-dianes por segundo.

yawspeed floatVelocidad angular sobre el yaw, expresado en ra-dianes por segundo.

Cuando se necesita obtener los valores de los ángulos de navegación o la velocidad

angular asociada, una opción muy extendida consiste en importar la biblioteca desa-

rrollada por Lorenz Meier en C++, accesible desde GitHub [24], que permite llamar a

las funciones que monitorizan los parámetros del dron y extraerlos. De este modo, las

funciones que extraen los ángulos de navegación del UAV son las siguientes:

2. Sistemas UAV 23

Función getYaw(). Extrae el valor del yaw del UAV y lo retorna como un valor

de tipo float.

Función getPitch(). Extrae el valor del pitch del UAV y lo retorna como un

valor de tipo float.

Función getRoll(). Extrae el valor del roll del UAV y lo retorna como un valor

de tipo float.

Cabe señalar que el usuario puede modificar estas funciones para que la variable

angular obtenida no esté expresada en radianes, sino en grados, realizando una simple

conversión angular antes de devolver la variable.

Capítulo 3

Sistema AIS

3.1. Introducción

A raíz de la catástrofe naval del Titanic en 1912, la mejora de la seguridad de

las travesías marítimas pasó a convertirse en un objetivo global donde se sumaron

prácticamente todas las naciones de la Tierra. Como respuesta a este desastre, en 1914

se crea el Convenio SOLAS (Safety Of Life At Sea) para establecer aquellas normas

y recomendaciones que, bajo consenso internacional, garantizaran la seguridad de los

seres humanos al embarcarse en una travesía marítima [25]. De esta manera, en 1948

la ONU crea un organismo para regular la normativa internacional consensuada en

el Convenio SOLAS, al que se le llama IMO (International Maritime Organization).

El objetivo de este organismo es incorporar enmiendas y revisiones sobre los puntos

establecidos en el Convenio SOLAS, además de promover tecnologías que favorezcan la

seguridad marítima. En este sentido, el sistema AIS (Automatic Identification System)

toma partida como un sistema valioso para monitorizar las embarcaciones en todo

momento y así evitar posibles colisiones o accidentes de diversa índole en el mar [26].

Sin embargo, no fue hasta 1991 cuando se publica el primer documento acerca de

las especificaciones técnicas del sistema AIS [27]. Este estándar, actualmente regulado

por las autoridades marítimas de cada país, es propuesto por la ITU (International

Telecommunication Union) a través de la recomendación ITU-R M.1371, que actual-

mente se encuentra en su quinta versión desde 2014 [28]. El sistema AIS se concibe

25


como un estándar internacional y de libre acceso, incorporado por un gran número de

embarcaciones en la actualidad y desde 2002, obligatorio para los siguientes tipos de

embarcaciones [29]:

Cualquier embarcación con un tonelaje bruto superior a 500 toneladas.

Embarcaciones con un tonelaje bruto de más de 300 toneladas y que realicen

travesías internacionales.

Cualquier buque destinado al transporte de pasajeros, independientemente de su

tonelaje bruto.

Dado que el propio estándar del sistema alude a una clasificación entre los dis-

positivos AIS clase A, de mayores prestaciones y costes elevados, y AIS clase B, con

prestaciones y precios más moderados, son los equipos AIS clase A los que deben ser

integrados de forma obligatoria en las embarcaciones que cumplan al menos uno de

los requisitos anteriores. Sin embargo, hay embarcaciones no sujetas a esta normativa,

como son los buques militares y aquellas embarcaciones que prestan un servicio no

comercial a un Estado, que no están obligadas a identificarse en el sistema, pero sí

pueden integrarlo si se considera oportuno.

En definitiva, AIS es un sistema de radiocomunicación punto a punto en la banda

de VHF, que cuenta con un esquema TDMA propio y que permite la identificación y

monitorización de aquellas embarcaciones que disponen de un transpondedor de este

sistema a bordo. Dicho de otra manera, permite a una embarcación con un transpon-

dedor AIS conocer numerosos parámetros sobre el resto de embarcaciones que integran

este sistema y se encuentran en su zona de cobertura, como pueden ser la posición,

velocidad, rumbo o incluso, los puertos de origen y destino (figura 3.1) [30]. Con ello,

cada embarcación está identificada de manera unívoca a través de un código de 9 dígi-

tos decimales denominado MMSI (Maritime Mobile Service Identity), que es asignado

por la autoridad marítima competente de cada país. En el caso de España, el organismo

que asigna un MMSI a un equipo AIS mediante una solicitud previa es la Dirección

General de la Marina Mercante.

3. Sistema AIS 27

Satélite GPS

Embarcaciones conAIS clase A y AIS clase B

Estación satelital AIS

Satélite AIS

Estación de controly vigilancia para

tráfico marino

Figura 3.1: Proceso de comunicación compartida entre estaciones AIS

3.1.1. Ventajas y desventajas

El sistema AIS se reconoce como uno de los sistemas de comunicaciones marítimas

de mayor relevancia debido a una serie de ventajas frente a otros sistemas con propósitos

similares [31]. Algunas de las ventajas más importantes que presenta este sistema son

las siguientes:

Presenta una gran robustez frente a las adversidades meteorológicas (niebla, llu-

via o calima, entre otros), el estado del oleaje y los elementos orográficos que

circundan a la estación.

El alcance máximo de un único transpondedor AIS puede llegar hasta 100 millas

náuticas, aumentando considerablemente si existen nodos intermedios, además

de existir cobertura satelital mediante satélites como ORBCOMM y exactEarth.

Es un sistema autogestionado, de manera que cada estación controla el envío y la

recepción de los mensajes, desvinculando su operatividad de las estaciones base.


La estandarización del sistema es internacional.

En comparación con otros sistemas de comunicaciones marítimas, el coste de los

equipos y su mantenimiento es relativamente bajo.

No obstante, AIS es un sistema proclive a ser utilizado para respaldar operaciones

de piratería, terrorismo y pesca ilegal, ya que muchas embarcaciones están exentas de

identificarse en el sistema de forma obligatoria. En este sentido, las funcionalidades y

garantías que ofrecen otras tecnologías, como puede ser el radar, superan claramente

al sistema AIS en términos de seguridad y privacidad.

3.1.2. Dispositivos comerciales

La demanda latente en lo que concierne a la tecnología electrónica como elementos

de apoyo en las travesías marítimas, tanto para embarcaciones comerciales como de

recreo, favorece la existencia de un gran número de compañías dedicadas a la venta

y distribución de equipos AIS. Además, numerosas empresas hacen uso de la tecnolo-

gía AIS para ofrecer servicios de monitorización y seguimiento de embarcaciones, que

resultan útiles en numerosas disciplinas.

En la actualidad, la compañía puntera en tecnología AIS es Sofware Radio Techno-

logy, conocida como SRT-Marine, una empresa británica fundada en 1987 que cuenta

con una larga experiencia en AIS y otras tecnologías hardware y software para sistemas

de radiocomunicación. Los productos desarrollados por esta empresa copan cerca del

90 % de la tecnología AIS utilizada en la actualidad, y entre los servicios que ofrece

destacan los siguientes:

Diseño de equipos hardware personalizados, a petición del cliente.

Módulos AIS funcionales para ser integrados en cualquier entorno.

Soluciones software relacionadas con el mantenimiento y la configuración de equi-

pos AIS.

3. Sistema AIS 29

Por otro lado, CML Microcircuits ofrece una gama de productos similar a la de

SRT-Marine. Esta compañía oferta distintas líneas de productos para aplicaciones de

radiofrecuencia [32], donde destaca una línea particular para comunicaciones marítimas.

En esta línea se ofertan diferentes modelos de chips y equipos de evaluación para

transpondedores y receptores AIS y SAR, pensados para su integración en aplicaciones

electrónicas particulares.

El resto de compañías dedicadas a la venta y distribución de equipos AIS están

orientadas hacia la integración de receptores y transpondedores en embarcaciones. De-

bido a su volumen de ventas, son notables las compañías Comar Systems, Digital Yatch,

Milltech Marine y Em-Trak para la adquisición de transpondedores y receptores AIS

de instalación inmediata, así como otros elementos imprescindibles como pueden ser

antenas VHF y splitters. Sin embargo, hay que considerar que la mayor parte de es-

tas compañías basan sus diseños en la tecnología desarrollada por SRT-Marine, y que

incluso adaptan el software propio esta compañía para sus productos.

Finalmente, las principales empresas dedicadas a ofrecer servicios a partir de la

información recogida por el sistema AIS son MarineTraffic y exacEarth. Ambas com-

pañías se dedican a la venta de estadísticas e históricos de datos sobre el tráfico ma-

rítimo. En el caso de MarineTraffic, ofrece un servicio gratuito de monitorización de

embarcaciones en la web a partir de la información recogida por su red de receptores

AIS en todo el mundo, disponible también para Android e iOS. De esta forma, cual-

quier usuario puede acceder a la web de MarineTraffic y consultar el estado del tráfico

marítimo en todo momento y en numerosos lugares del planeta, salvo en algunas zonas

donde la cobertura es satelital y por tanto, de pago.

3.2. Descripción del sistema

Las características técnicas del sistema AIS están descritas en la recomendación

ITU-R M.1371-5 en función de su arquitectura OSI (Open System Interconnection),

aunque únicamente están descritos los niveles desde la capa física hasta la capa de

transporte, dejando los niveles superiores relativos a la presentación y tratamiento de

los datos a elección del usuario (figura 3.2).

30 3.2. Descripción del sistema

Nivel Físico

Nivel de Enlace

Nivel de Red

Nivel de Transporte

Subcapa MAC Subcapa DLS Subcapa LME

Nivel de Sesión, Presentacióny Aplicación

Parámetros radio y esquemas de modulacióny codificación

Sincronismo y formato de tramas, esquemade acceso al medio

Formato de mensajes AIS y mecanismosde envío y recepción por la red

No existe ninguna estandarización sobreestos niveles OSI en AIS

Figura 3.2: Arquitectura OSI del sistema AIS

3.2.1. Características radio y de enlace

El sistema AIS opera en la banda de VHF marina sobre dos frecuencias llamadas

AIS-1 (161.975 MHz) y AIS-2 (162.025 MHz), con una canalización de 25 KHz. Además,

presenta una codificación de línea NRZI Non-Return to Zero Inverted) a 9600 bps, de

forma que tras la codificación, los bits generados se modulan con una modulación

específica denominada FM-GMSK (Frequency Modulation - Gaussian Minimum Shift

Keying), que pondera la forma de onda de los bits con una envolvente gaussiana,

seguido de una modulación analógica en frecuencia (figura 3.3).

Modulación GMSK

Modulación FM

Modulación FM-GMSK

CodificaciónNRZI

Figura 3.3: Esquema de codificación y modulación en AIS

Por otro lado, el formato de tramas del sistema AIS lo forman seis campos relativos

al preámbulo o secuencia de inicio, los flags o cabeceras de inicio y fin, el campo de

datos de la trama, un código de redundancia cíclica de 16 bits y un campo adicional

que se relaciona con el sincronismo de la trama, tal y como aparece en la figura 3.4.

3. Sistema AIS 31

Preámbulo

Cabecerainicial

Datos CRC

Cabecerafinal

Buffer temporal

0x55 0x55 0x55 0x7E 168 bits 16 bits 0x7E 24 bits

Figura 3.4: Campos de una trama AIS

3.2.2. Esquema de acceso al medio

En lo que respecta al esquema de acceso al medio, AIS emplea un esquema de acceso

tipo TDMA que depende de la clase de AIS del equipo y el ámbito de aplicación. De

esta manera, los dos esquemas fundamentales en AIS son SOTDMA (Self-Organized

Time Division Multiple Access), empleado por los equipos AIS clase A, y CSTDMA

(Carrier Sense Time Division Multiple Access), propio de los equipos AIS clase B. Tam-

bién existen otros esquemas como RATDMA (Random Access Time Division Multiple

Access), FATDMA (Fixed Access Time Division Multiple Access) o ITDMA (Incre-

mental Time Division Multiple Access), que se usan para respaldar a los dos esquemas

de acceso principales o para aplicaciones específicas de AIS, como son AtoN (Aids-to-

Navigation), SAR (Search and Rescue) o SART (Search and Rescue Transponder) [33],

tal y como se refleja en la figura 3.5.

SAR SART AtoN AIS clase A AIS clase B Estación base AIS

No está definidoen el estándar

SOTDMAmodificado

FATDMARATDMA

SOTDMARATDMAITDMA

CSTDMA FATDMARATDMA

Figura 3.5: Tipos de esquema de acceso al medio en AIS en función del ámbito deaplicación

En cualquier caso, ambos esquemas principales operan de tal forma que los equipos,

sincronizados sobre un tiempo común UTC (Universal Time Coordinated) que extraen

de la red GNSS, compiten por el acceso a un slot de tiempo de 26.67 ms, y en caso de

estar ocupados, se autogestionan para no colisionar con los equipos que ya han accedido

al slot y así poder acceder a aquellos que se encuentren libres.


En este sentido, el esquema de acceso SOTDMA presenta tres modos de operación

fundamentales que se describen a continuación [34]:

Modo autónomo y continuo. Los equipos AIS clase A están continuamente

emitiendo y recibiendo mensajes AIS, a menos que ocurra un fallo en el equipo,

se desconecte o cambie el modo de operación.

Modo asignado. La autoridad competente de cada país programa este modo en

función del área donde se realice una travesía marítima.

Modo interrogación. Una estación AIS solicita a otra una respuesta sobre algún

parámetro o sencillamente, sobre el estado de la misma.

Con este esquema, las estaciones monitorizan durante un minuto el estado del canal

y cómo otras estaciones acceden a los slots. Una vez conocidos los slots libres, la estación

accede a uno de ellos y se presenta al resto de equipos AIS que operan en una misma

región de cobertura. En el momento en el que expire el tiempo de acceso al primer slot,

la estación busca otro slot libre y accede a él, y así sucesivamente de forma organizada

sin interferir en la operación del resto de equipos.

Por el contrario, el esquema de acceso CSTDMA monitoriza el nivel de ruido de

fondo de los canales AIS y así establecer un umbral que le permita discernir entre ruido

(no hay actividad en el slot) y señal (el slot está ocupado). Aunque los equipos que

operan con CSTDMA son totalmente compatibles con los que emplean SOTDMA, la

prioridad de acceso la tienen los equipos con SOTDMA, dado que son AIS clase A y

por tanto, su uso es obligatorio y resulta prioritaria su conexión frente a equipos AIS

clase B que están exentos del cumplimiento obligatorio de incorporación del sistema

AIS en la embarcación.

3.2.3. Estructura de mensajes AIS

El campo de datos de una trama AIS contiene un mensaje conformado por un

identificador (MSG ID), un código MMSI, la información contenida y el estado de la

comunicación, tal y como se representa en la figura 3.6.

3. Sistema AIS 33

MSG ID MMSI Información del mensajeEstado de comunicación

Campo de datos de la trama AIS

Figura 3.6: Estructura básica de un mensaje AIS

El identificador de mensaje consta de 6 bits e indica el tipo de mensaje AIS que

se envía o recibe en una trama, existiendo un total de 27 mensajes AIS para diferen-

tes propósitos, mientras que el identificador MMSI consta de 30 bits representados

mediante 9 dígitos decimales, siendo un identificador único para cada equipo AIS y es

asignado a cada equipo por la autoridad reguladora del país donde opera. Por otro lado,

el estado de comunicación provee al sistema de la información necesaria para conocer

el estado de los slots durante su acceso al medio e indicar el estado de sincronismo del

sistema por medio del sistema GPS.

Por último, la información del mensaje depende del tipo de mensaje AIS, y se

relaciona intrínsecamente con la naturaleza de la información que se comunica. En este

sentido, la preponderancia de la información compartida por el sistema AIS se clasifica

en los siguientes tipos:

Información estática, que no varía en ningún momento y sirve para identificar

de forma unívoca a cada equipo, como puede ser el MMSI o las dimensiones de

la embarcación.

Información dinámica, que se actualiza constantemente y señala aquellos pa-

rámetros variables del sistema, como puede ser la posición o la velocidad.

Información de travesía, que permiten al usuario introducir manualmente

información relevante para la travesía marítima, principalmente como apoyo para

otros sistemas de comunicación a bordo.

Otra información, destacando los mensajes de texto cortos que se emplean para

garantizar la seguridad en el mar o informar de una situación de alerta, con un

propósito similar a la llamada digital selectiva.


Cabe señalar que la información transmitida influye en el periodo de envío de los

mensajes junto a la clase de AIS del equipo. Cuando una embarcación está atracada

en un puerto o no realiza ningún desplazamiento, la velocidad es nula y por tanto, los

datos estáticos se envían cada 6 minutos, independientemente de la clase de AIS del

equipo. Por el contrario, cuando una embarcación se desplaza durante una travesía o

realiza alguna maniobra en el mar, sus datos dinámicos se actualizan en función de la

velocidad de la embarcación, tal y como se presenta en la tabla 3.1.

Tabla 3.1: Periodo de actualización de mensajes AIS en función de la velocidad

Velocidad Periodo de actualizaciónAIS clase AInferior a 3 nudos para buques anclados o amarra-dos 3 minutos

Superior a 3 nudos para buques anclados amarra-dos 10 segundos

Entre 0 y 14 nudos 10 segundosEntre 0 y 14 nudos con cambio de rumbo 3 segundosEntre 14 y 23 nudos 6 segundosEntre 14 y 23 nudos con cambio de rumbo 2 segundosSuperior a 23 nudos 2 segundosSuperior a 23 nudos con cambio de rumbo 2 segundosAIS clase BInferior a 2 nudos 3 minutosSuperior a 2 nudos 30 segundosComentarios 1 nudo = 0, 514 m/s

A excepción de AIS clase A y clase B, los otros tipos de AIS no dependen de la

velocidad para fijar la tasa de actualización de mensajes. De este modo, el periodo de

actualización de los equipos AIS SAR y las estaciones base AIS es de 10 segundos,

mientras que el de AIS AtoN es de 3 minutos.

3.2.4. Tipos de mensajes AIS

En la tabla 3.2 se presentan los tipos de mensajes AIS recogidos en la normativa y

clasificados en función del identificador del tipo de mensaje que presentan. Este sistema

cuenta con 63 mensajes en total, pero la normativa vigente solamente especifica los 27

primeros, indicando que del mensaje 28 al 63 se reservan para usos futuros.

3. Sistema AIS 35

Tabla 3.2: Clasificación de los tipos de mensajes AIS

MSG ID Descripción de la información1, 2, 3 Informe de posición de equipos AIS clase A4 Informe de posición de estaciones base AIS5 Datos estáticos y de viaje de equipos AIS clase A6, 7, 8 Información de reconocimiento, binaria y broadcast9 Posición de equipos SAR10, 11 Información del tiempo UTC12, 13, 14 Información binaria y de reconocimiento segura15 Cambio al modo interrogación16 Cambio al modo asignado17 Información broadcast de la red GNSS18, 19 Informe de posición normal y extendido de equipos AIS clase B20 Reserva de slots para estaciones base AIS21 Informe de posición de equipos AtoN22, 23 Cambio a otros modos de las estaciones base AIS24 Datos estáticos de equipos AIS clase A25, 26 Información binaria no programada27 Informe de posición para equipos AIS de largo alcance

3.3. Estándar NMEA0183

Desde el tercer cuarto del siglo XX, el creciente número de equipos de radiocomu-

nicación a bordo de las embarcaciones comenzó a ser un problema para quienes tenían

que lidiar con equipos de diferentes fabricantes o integrar nuevos equipos al sistema

sin sustituir los antiguos. El número de cables que intervenían en la conexión de es-

tos sistemas, además de las dificultades de configuración de algunos equipos, obligó

a la asociación NMEA (National Marine Electronics Association), dedicada a la ne-

gociación de estándares para los productos electrónicos marítimos entre los distintos

fabricantes, a establecer un protocolo que facilitara la operación de los usuarios con los

sistemas a bordo de las embarcaciones.

De este modo, en 1980 se propuso una primera versión de un estándar que permitía

comunicar entre sí los equipos a bordo, independientemente del modelo del equipo,

al que se llamó NMEA0180. Esta primera versión fue modificada dos años después

con el estándar NMEA0182, hasta que finalmente, en 1983 se propuso el protocolo

NMEA0183, convirtiéndose en el estándar de referencia para toda la electrónica naval.

36 3.3. Estándar NMEA0183

En la actualidad, este estándar es acogido por numerosos sistemas de comunicaciones

navales, desde GPS hasta radares, entre los que destaca el sistema AIS. Sin embargo,

aunque NMEA0183 sigue vigente en la actualidad, en los últimos años ha sido sustituido

por la nueva versión NMEA2000 [35], aunque el proceso de sustitución no está tomando

un ritmo muy acelerado, por lo que NMEA0183 sigue siendo la versión más utilizada.

3.3.1. Introducción

El estándar NMEA0183 es el principal protocolo que siguen los equipos electrónicos

navales para comunicarse entre sí. Se trata de un código de señales habilitado para

transmitir y recibir datos de los equipos que se alojan en la embarcación. De esta

manera, cuando un dispositivo opera bajo el estándar NMEA0183, interpreta el formato

de los mensajes de este protocolo e identifica al equipo y la información que recibe.

En lo que respecta a sus características físicas, este estándar opera a una tasa de

símbolo de 4800 baudios a través de un bus serie, siguiendo un protocolo con un bit

de start y un bit de stop, sin incluir ningún bit de paridad. Para la última versión de

NMEA0183, los niveles de señal oscilan entre los +5 y 0 V, aunque si se crea una red

de equipos conectados bajo este mismo protocolo donde algunos de ellos son equipos

obsoletos, se puede incrementar la tensión hasta ±15 V.

Generalmente, el estándar NMEA0183 diferencia para cada equipo un único talker

y al menos un listener. El talker representa a las líneas de comunicación relativas a la

transmisión, mientras que el listener se asocia a las líneas de comunicación en recepción,

tal y como se presenta en la figura 3.7.

Canal A, TX

Canal B, TX

Canal A, RX

Canal B, RX

Figura 3.7: Líneas de comunicación NMEA0183 genéricas para talker y listener

Cabe señalar que a pesar de ser un protocolo estandarizado, los fabricantes de

equipos de radioelectrónica naval no han llegado a ningún consenso en lo que respecta

3. Sistema AIS 37

al código de colores de los cables del equipo. En este sentido, la norma general es

que dado dos canales A y B, los canales de recepción toman colores blanco y marrón,

mientras que los de transmisión son de color amarillo y verde, respectivamente. Sin

embargo, hay una gran cantidad de equipos que no se guían por esta norma, de manera

que lo recomendable es consultar siempre el manual de usuario del equipo.

3.3.2. Formato y tipos de mensajes

De forma general, un mensaje NMEA presenta una estructura basada en un código

ASCII de 6 bits donde se indica el tipo de dispositivo que transmite el mensaje, la

información que se da a conocer al resto de los equipos con los que se comunica y la

verificación del mensaje transmitido mediante el cálculo de un checksum, tal y como se

indica a continuación:

$yyXXX,ZZZZ...ZZ,Z*xx <0D><0A>

!yyXXX,ZZZZ...ZZ,Z*xx <0D><0A>

De esta manera, la interpretación de los distintos campos que conforman las posi-

bles estructuras de mensajes NMEA presentadas anteriormente queda detallada en los

siguientes puntos:

$ y ! son los posibles delimitadores iniciales del mensaje.

yy son 2 dígitos que indican el tipo de dispositivo que envía el mensaje.

XXX son 3 dígitos que marcan el tipo de dato que contiene el mensaje.

ZZZZ...ZZ son el contenido del mensaje, que dependen del tipo de mensaje y la

información que se está transmitiendo en cada momento.

xx son 2 dígitos hexadecimales de checksum, que se obtienen a partir del cálculo

de la OR-exclusiva sobre los dígitos anteriores del mensaje, incluyendo las comas,

salvo los delimitadores iniciales del mensaje.

<0D><0A> son los dígitos hexadecimales de carriage return y line feed, respecti-

vamente, y marcan la finalización del mensaje.


En relación a este Trabajo Fin de Máster, los principales dígitos para la identifi-

cación de dispositivos son AI (referencian a dispositivos AIS), GP (referencian a la red

GPS) y HE (referencian a dispositivos autónomos que envían comandos NMEA a otros

dispositivos).

3.3.3. Ejemplos de mensajes NMEA

Con el objetivo de incidir en la semántica de los comandos NMEA, a continuación

se presenta un ejemplo de un mensaje NMEA transmitido por una estación AIS:

!AIVDM,1,1,,B,13EmhtPP1:NqMAd@6Eoncww:0@FD,0*56

En el inicio del mensaje, el identificador !AIVDM indica que se trata de un mensaje

transmitido por un equipo AIS (AI) en la banda de VHF por un equipo distinto al que

lo transmite (VDM). Si fuera el propio equipo AIS el que transmite y recibe el mensaje,

aparecería AIVDO. Con la sentencia consecutiva, 1,1„B, se sabe que el mensaje se recibe

por el canal AIS-1 y es de tipo 1, correspondiente a los informes de posición, y que el

equipo es de tipo AIS clase B.

Respecto al contenido del mensaje, 13EmhtPP1:NqMAd@6Eoncww:0@FD, saber que es

de tipo 1 posibilita la identificación de los valores que se reciben en función del formato

del mensaje. Este contenido está codificado con 6 bits, de manera que se debe trasladar

a un formato de 8 bits y asignar los valores binarios recibidos en función de los campos

indicados por el estándar ITU-R M.1371-5. De este modo, los principales campos de

interés de este mensaje son los siguientes:

ID del mensaje: 1

MMSI: 224227570

SOG (Speed Over Ground): 7.4 nudos

Longitud: 15.4102567 grados

Latitud: 28.1351983 grados

3. Sistema AIS 39

COG (Course Over Ground): 171.1 grados

Por último, se indica el checksum del mensaje (0*56), que se calcula a partir de una

OR-exclusiva iterada sobre cada uno de los valores que existen entre el preámbulo ! y

la última coma previa al checksum. Por tanto, se puede concluir que al tratarse de un

informe de posición, es necesario obtener el identificador MMSI de la embarcación, las

coordenadas donde se ubica y su velocidad y rumbo.

Se puede realizar un ejercicio similar con los mensajes NMEA relativos a la red GPS,

que al no estar codificados con 6 bits como los mensajes AIS, resulta más intuitiva su

interpretación. Para ello, se supone el siguiente mensaje de ejemplo:

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

El identificador GPGGA al inicio del mensaje indica que se trata de información GPS

(GP) para mejorar la precisión de la medida (GGA). Seguidamente, los datos que contiene

el mensaje se interpretan de forma sencilla con los campos indicados a continuación:

Tiempo UTC del sistema: 12:35:19

Latitud: 48d 07.038’ N

Longitud: 01d 131.000’ E

Longitud: 15.4102567 grados

Indicador de calidad de precisión: 1 (GPS en modo estándar SPS)

Número de satélites en cobertura: 8

HDOP: 0.9

Altitud: 545.4 metros

Altura geodésica para el modelo WGS84: 46.9 metros

Al igual que con el resto de comandos NMEA, el último parámetro (*47) indica

el checksum calculado a partir de los datos anteriores. Fundamentalmente, todos los


datos introducidos en este mensaje muestran no sólo la ubicación de un punto sobre la

Tierra, sino que también aportan información relevante para la mejora de la precisión

de la información del GPS.

Por último, otro ejemplo que destaca por su sencillez son los mensajes para disposi-

tivos autónomos que se comunican a través del protocolo NMEA. Un ejemplo de estos

mensajes es el siguiente:

$HEHDT,214.5,T*2D

En este ejemplo, el identificador $HEHDT indica que se trata de un dispositivo autó-

nomo (HE) que indica su orientación angular en el plano (HDT). Por tanto, solamente es

necesario indicar el ángulo de orientación, que es 214.5 grados, y finalizar el mensaje

con el checksum calculado a partir de la información previa del mensaje.

Capítulo 4

Desarrollo del prototipo

4.1. Diagrama de bloques

El diagrama de bloques de la figura 4.1 expresa el prototipo que se desarrolla en

este Trabajo Fin de Máster, que está formado por un microcontrolador BeagleBone

Black y un transpondedor AIS clase B basado en el módulo Cobalt de SRT-Marine,

además de las antenas de VHF marino y GPS.

Transceptor AIS clase BSRT Marine Cobalt

MicrocontroladorBeagleBone Black

Controlador de vuelo del droneArduPilot

Antena GPS

Antena VHF

ComandosMAVLink

ComandosNMEA0183

Figura 4.1: Diagrama de bloques del prototipo

En este diagrama, el dron comunica sus propios datos con formato MAVLink al

microcontrolador BeagleBone Black mediante el módulo ArduPilot, vía puerto serie.

De esta manera, los datos son recogidos por el microcontrolador y, mediante el firm-

ware implementado en el microcontrolador, únicamente procesa los datos relativos a la

orientación del dron. Con estos datos, el firmware construye un mensaje con formato

NMEA y lo envía cada segundo por el puerto serie que va conectado al transceptor

AIS clase B Cobalt, que finalmente envía estos mensajes a través de la antena VHF.

41

42 4.2. Transceptor AIS clase B

Cabe destacar que el módulo Cobalt también emite de forma automática otros tipos

de mensajes AIS relativos a la posición, velocidad y rumbo del dron, que los construye

internamente a partir de la información que recibe de la antena GPS.

4.2. Transceptor AIS clase B


El módulo Cobalt de SRT-Marine [36] es un transpondedor AIS clase B completa-

mente integrado en un dispositivo compacto, que permite transmitir mensajes AIS tipo

13, 18, 19 y 24, además de recibir la mayoría de tipos de mensajes AIS que describe

el estándar ITU-M.1371-5 y decodificar los mensajes GPS. Se trata de un dispositivo

de bajo consumo de potencia, tamaño reducido, y su flexibilidad lo establece como

un candidato ideal para su adaptación y configuración en numerosas soluciones con el

sistema AIS, que van desde su integración en transpondedores AIS comerciales hasta

aeronaves y satélites.

Este módulo dispone de un conector board-to-board Hirose DF13A-40DP-1.25V(91)

en la parte superior de su estructura, que consta de 40 pines relacionados con la confi-

guración y el control del mismo. A su vez, incluye dos conectores de RF Hirose U.FL-

R-SMT-1 en los que se conectan las antenas de VHF marítimo y GPS (figura 4.2).

70 mm55 mm

13.8 mmConector paraantena GPS

Conector paraantena VHF

Diodos LED paraindicación de status

Conector para interfazserie y de alimentación

Figura 4.2: Dimensiones y conectores del módulo Cobalt

El conector Hirose DF13A-40DP-1.25V(91) permite al usuario acceder a las cone-

xiones externas del módulo Cobalt, clasificadas de la siguiente forma (figura 4.3):


Conexiones de alimentación: relativas a las tensiones y corrientes externas que

necesita el dispositivo para operar correctamente, además de un pin configurable

que permite su activación.

Conexiones de interfaces serie: incluye los puertos que emplea el estándar

AIS (NMEA0183 y NMEA2000), además de los puertos USB, SPI y USER_IO.

Conexiones de interfaces RF: referidas a los conectores para las antenas de

VHF y GPS.

40

39

38

37

36

35

34

33

32

31

30 28 26 24 22 20 18 16 14 12 10 8 6 4 2

1357911131517192123252729

Interfaz de alimentación

Toma de tierra

Interfaz USER_IO

Interfaz SPI

Interfaz USB

Interfaz NMEA0183

Interfaz NMEA2000

Sin conexión

VIN

(+)

USE

R_IO

_8

VIN

(+)

VIN

(-)

VIN

(-)

USE

R_IO

_6

USE

R_IO

_4

USE

R_IO

_0

USE

R_IO

_1

USE

R_IO

_2

GN

D

NM

EA01

83_T

X1_A

NM

EA01

83_T

X1_B

nAIS

_OFF

NM

EA01

83_R

X1_A

NM

EA01

83_T

X2_A

NM

EA01

83_T

X2_B

NM

EA01

83_R

X2_A

N2K

_NET

_C

N2K

_NET

_C

3V3_

EXT

USE

R_IO

_3

SPI_

MIS

O

GN

D

USB

_VBU

S

NC

NM

EA01

83_R

X1_B

NM

EA01

83_R

X2_B

N2K

_NET

_L

N2K

_NET

_H

USE

R_IO

_9

USE

R_IO

_7

USE

R_IO

_5

SPI_

MO

SI

SPI_

SCK

SPI_

SDIO

_CS

USB

_DP

USB

_DM

USB

_GN

D

GN

D

Figura 4.3: Pines del conector Hirose DF13-40P-1.25V del módulo Cobalt

4.2.2. Conexiones de alimentación

El módulo Cobalt se alimenta con tensiones continuas nominales de entrada com-

prendidas entre 9.6 V y 31.2 V. Para ello, este módulo dispone de 5 pines de alimen-

tación en el conector Hirose DF13-40P-1.25V(91), además de los pines de referencia


a tierra y un circuito de protección contra polaridades inversas. Cabe señalar que el

módulo Cobalt tiene un consumo de potencia en el momento de la transmisión de en-

tre 1 W y 5 W. Esta característica permite que el módulo Cobalt se mantenga en un

modo de bajo consumo cuando únicamente recibe datos, y solamente cuando envía un

mensaje AIS genera un pico de potencia y vuelve a su estado de bajo consumo.

4.2.3. Conexiones de interfaces serie

Las conexiones de la interfaz serie del módulo Cobalt se ubican en el conector

Hirose DF13-40P-1.25V(91), con un total de 30 pines referidos a las distintas interfaces

provistas en este dispositivo. Además, se integran 4 diodos LED de distinto color que

se activan en función de los estados marcados por estas interfaces, tal y como aparece

en la figura 4.4.

StatusFaultTx timeoutPower / OK

Pin 40 Pin 2

Pin 1Pin 39

Figura 4.4: Indicadores LED en el módulo Cobalt SRT-Marine

Las interfaces serie del módulo Cobalt a las que tiene acceso el usuario mediante el

conector Hirose DF13A-40DP-1.25V(91) son las siguientes:

Interfaz USB. Esta interfaz consta de 4 pines, dos de ellos referidos a los datos

de entrada y salida (D+ y D−, respectivamente) y otros para las conexiones de

alimentación (VCC = +5 V) y tierra (GND). Mediante esta interfaz, y con ayuda


del software propio del dispositivo, es posible configurar los datos estáticos del

módulo Cobalt y monitorizar su actividad si se conecta a un ordenador.

Interfaz SPI. Esta interfaz cuenta con 4 pines referidos a las cuatro señales

básicas del protocolo SPI, que son MOSI (Master Output Slave Input), MISO

(Master Input Slave Output), señal de sincronismo y señal de enable. De esta

manera, es posible conectarse a una memoria SD integrada en el módulo Cobalt,

que opera en modo SPI, y extraer los datos almacenados en el transpondedor y/o

realizar ampliaciones futuras del sistema.

Interfaz NMEA0183. Esta interfaz consta 2 canales bidireccionales asociados a

8 pines, que a su vez se relacionan con la recepción y transmisión de mensajes AIS

bajo el protocolo NMEA0183. De estos pines, 4 de ellos están relacionados con

la recepción y los otros 4 con la transmisión, y se presentan en parejas dado que

actúan como entradas y salidas diferenciales. Se trata de una interfaz necesaria

para conectar el módulo Cobalt a otros instrumentos de navegación marítima.

Interfaz NMEA2000. Esta interfaz consta de 4 pines relacionados con la trans-

misión y recepción de mensajes AIS bajo el protocolo NMEA2000, donde dos de

ellos se relacionan con los datos transmitidos y recibidos, y los otros dos para la

alimentación y tierra.

Interfaz USER_IO. Esta interfaz está formada por 10 pines relacionados con

el estado del dispositivo, que se marca mediante 4 diodos LED integrados en el

dispositivo, y con el control de escritura y lectura de la memoria SD en modo

SPI. Es por ello que esta inferfaz se asocia a las futuras expansiones que se deseen

hacer con el módulo Cobalt.

4.2.4. Conexiones de RF

El módulo Cobalt dispone de dos conectores Hirose U.FL-R-SMT-1 para conectar

las antenas de GPS y VHF (figura 4.5), existiendo además ciertas limitaciones sobre los

parámetros característicos de las antenas de VHF y GPS que se conectan al módulo,

recogidas en la tabla 4.1.


Conector para antena GPS

Conector para antena VHF

Figura 4.5: Conectores para las antenas de VHF y GPS del módulo Cobalt

Tabla 4.1: Limitaciones para las antenas de VHF y GPS en el módulo Cobalt

Parámetro Conector VHF Conector GPSImpedancia 50 Ω 50 ΩFrecuencia 156 – 162 MHz 1.575 GHzGanancia 3 dBi > 20 dBCOE 2:1

4.2.5. Configuración del dispositivo

El módulo Cobalt se configura a través de un software específico desarrollado por

SRT-Marine llamado proAIS2, que se puede adquirir de forma gratuita para las pla-

taformas Windows y UNIX. Este software permite tanto la configuración de los datos

estáticos del dispositivo como la monitorización del estado del mismo y los mensajes

AIS recibidos y transmitidos, además de servir como interfaz para enviar comandos

NMEA al módulo Cobalt.

El software proAIS2 presenta cinco vistas con las que el usuario puede interactuar,

explicadas más extensamente en el anexo C, y son las siguientes:

Configuration. Permite la conexión del módulo Cobalt y la configuración de los

datos estáticos del dispositivo (nombre y tipo de la embarcación, MMSI, código

de llamada selectiva, ubicación de las antenas...). También permite configurar la

tasa binaria de salida del dispositivo.

GNSS Status. Permite la monitorización y representación gráfica de los niveles

de la relación portadora-ruido de los satélites de GPS, así como determinar el


número de satélites que el módulo Cobalt está recibiendo en todo momento y sus

parámetros asociados.

Other Vessels. Permite la recepción y monitorización del resto de embarcaciones

que integran un transpondedor AIS y se encuentran en la zona de cobertura del

módulo Cobalt, mostrando toda la información relevante de cada embarcación

(nombre, clase de transpondedor, posición, velocidad...).

Diagnostic. Permite la revisión de los parámetros característicos del módulo

(estado de las conexiones y características propias del software) e incluso, el

número de mensajes recibidos y transmitidos por los dos canales del dispositivo.

Serial Data. Permite la monitorización y el almacenamiento de los mensajes

AIS recibidos y transmitidos, así como habilitar el envío de comandos NMEA

por parte del usuario.

4.3. Microcontrolador


La placa BeagleBone Black [37] es un sistema empotrado de desarrollo basado en

un procesador ARM Cortex A8 que ejecuta un sistema operativo Linux, actualmente

en su versión Debian 8.6 Jessie (figura 4.6). Esta placa está dotada de una gran po-

tencia y capacidad de ejecución para diversas actividades en tiempo real sobre un gran

número de aplicaciones. Además, cuenta con un gran número de entradas y salidas que

le permite conectarse con diferentes dispositivos e interfaces, destacando su reducido

consumo de potencia y el bajo coste de las mismas, siendo un competidor inmediato de

otras plataformas destinadas a propósitos similares, como son Raspberry Pi o Arduino.

Los elementos principales de la BeagleBone Black, al igual que ocurre con otras

plataformas de microcontroladores, se pueden esquematizar en tres grupos bien dife-

renciados, que son los siguientes:

48 4.3. Microcontrolador

Figura 4.6: Placa BeagleBone Black

Microprocesador.

Unidad de memoria.

Interfaces externas y de alimentación.

La programación de estas placas resulta sencilla, ya que permite la ejecución de

scripts en el lenguaje Python [38], que destaca por su sencillez de sintaxis, aunque

también es posible programarlas en otros lenguajes como C y C++. No obstante, la

extensión de uso de la BeagleBone Black es inferior a la de la Raspberry Pi, de manera

que no hay comunidades tan amplias para compartir las novedades y problemas que

pueden aparecer durante la configuración de estas placas.

4.3.2. Microprocesador

El microprocesador integrado en la BeagleBone Black es el modelo Texas Instru-

ments Sitara XAM3359AZCZ100, un procesador Cortex-A8 de 32 bits con arquitectura

RISC que cuenta con una frecuencia de reloj de 1 GHz y 512 MB de memoria DDR3L.

En lo que se refiere a las interfaces de entrada y salida de este microprocesador, cabe

señalar aquellas interfaces a las que el usuario tiene acceso en la placa BeagleBone

Black. En la figura 4.7 se presenta una descripción de estas interfaces, destacando la

inclusión de hasta 6 puertos UART, 2 puertos SPI, 3 canales PWM y 3 puertos I2C,

que suelen ser las interfaces de mayor interés para el usuario.


UART

SPI

I2C

CAN

6

Interfaces serie Interfaces del sistema

McASP

2

3

2

2

Watchdog Timer

RTC EDMA

eCAP3 eQEP3

eHRPWM3

Timer8

JTAG/ETB

ADC 12 bits8

MMC/SD/SDIO3

GPIO

USB 2.0 OTG / PHY2

Puerto EMAC2

Interfaces paralelo

ARM Cortex-A8 Gráficas, display y otras interfaces del microprocesador

Interfaces principales

Procesador Otras interfaces

Buses de interconexión L4 y L5

SDRAM DDR3

Flash 16 bit NAND/NOR

Memoria del sistema

Figura 4.7: Diagrama de bloques del procesador de la placa BeagleBone Black

4.3.3. Unidad de memoria

La unidad de memoria de la BeagleBone Black se compone de una memoria SRAM

y una memoria flash integradas en el placa, siendo esta última ampliable mediante una

memoria micro-SD. Con ello, a continuación se muestran las principales características

técnicas que presentan estos dos tipos de memorias:

Memoria SRAM. Se basa en tecnología DDR3 y tiene una capacidad de 512

MB, repartida en 16 módulos a 800 MHz.

Memoria flash. Se basa en tecnología flash eMMC y tiene una capacidad de

2 o 4 GB, donde se ejecuta el sistema operativo, además de poder ser ampliada

mediante una tarjeta micro-SD.


4.3.4. Interfaces de comunicación y alimentación

La placa BeagleBone Black cuenta con una serie de interfaces de comunicación que

permiten la interconexión de la misma con otros dispositivos, o bien para su propia

alimentación, tal y como se indica en la figura 4.8.

Conector DC externa

Conector Ethernet

Debugger

Conector micro-HDMI

Tarjetamicro-SD

Conector mini-USB

BotónRESET

BotónPOWER

BotónSWITCH

Conectoresde expansión

Conector USB

Figura 4.8: Conectores y botones de la placa BeagleBone Black

De este modo, las interfaces externas y de alimentación de las que dispone esta

placa son las siguientes:

Conector de alimentación externa. Permite alimentar a la placa con 5 V y

una corriente menor que 2 A, lo que resulta necesario a veces si se incorporan

módulos o si se utilizan muchos puertos de entrada y salida, obligando a la placa

a exceder los 500 mA del conector USB.

Conector Ethernet. Mediante un conector RJ45 se provee a la placa de cone-

xión a Internet, actuando como puerto Ethernet 10/100 o de alta velocidad sobre

la red cableada.

Conector micro-HDMI. Permite conectar a la placa una pantalla HDMI, so-

portando resoluciones de hasta 1920x1080 píxeles a 24 Hz.


Conectores mini-USB y USB. Por un lado, con estos conectores es posible

alimentar a la placa sin necesidad del conector de alimentación externa, pero tam-

bién es posible conectarse al sistema operativo de la BeagleBone Black mediante

un puerto Ethernet virtual por SSH e intercambiar los datos que procesa.

Además de los conectores mencionados anteriormente, la placa contiene dos ristras

de conectores de expansión que proveen a la BeagleBone Black de 90 pines asociados

a las interfaces ADC, PWM, GPIO, I2C y UART, además de los pines relativos a la

alimentación y referencia a tierra (figura 4.9). Estos conectores permiten enlazar otros

módulos y circuitos a la placa en función de la aplicación a desarrollar.

P8 P9

Figura 4.9: Pinout de la placa BeagleBone Black

La placa BeagleBone Black también cuenta con una serie de diodos LED integrados

para indicar el estado de la placa y tres botones accesibles al usuario con las siguientes

funcionalidades:

RESET, para reiniciar el sistema operativo de la placa.

POWER, que al presionarse permite a la placa tanto activarse como ponerse en

modo suspensión, así como restaurar el estado del procesador.

BOOT, que permite cambiar el modo de arranque de la placa, ya sea mediante la

memoria FLASH integrada o desde la tarjeta microSD incorporada.


4.3.5. Configuración del dispositivo

Para comenzar a programar una BeagleBone Black, el primer paso consiste en

realizar una conexión SSH a través de la terminal de comandos hacia la dirección por

defecto [email protected], que no incluye ninguna contraseña. También es posible

asignar una dirección IP dentro de la subred donde se ubica la placa BeagleBone Black

para realizar su configuración y programación sin necesidad de utilizar la dirección

asignada por defecto. Una vez realizado este paso, es posible programar aquellos ficheros

que se deseen ejecutar sobre la BeagleBone Black a través de tres posibles métodos:

Mediante la programación de scripts en Python e importando sobre los mismos la

biblioteca Adafruit_BBIO, haciendo uso del editor de textos nano que incorpora

la distribución de Linux que integra la placa.

A través de BoneScript, usando un lenguaje basado en JavaScript y el entorno

de programación en la Nube Cloud9.

Por medio de la programación de ficheros en C, accediendo al directorio de ficheros

de Linux y usando el editor de textos nano.

La primera de las tres opciones anteriores goza de mayor popularidad, dado que el

lenguaje Python resulta sencillo para los usuarios con cualquier nivel de experiencia,

además que la biblioteca que ofrece Adafruit satisface un gran número de funcionali-

dades de la placa. Para ello, basta con introducir el comando nano para abrir el editor

de texto propio del sistema e incluir con un import la biblioteca de Adafruit al inicio

del código. Una vez el script esté programado, se almacena asignándole un nombre

seguido de la extensión .py y se ejecuta, mediante el comando python, seguido del

nombre asignado a este script.

En la figura 4.10 se presentan los pasos de conexión con la BeagleBone Black, así

como la edición y ejecución de un fichero Python.


Conexión con la BeagleBone Black

Apertura del editor de texto y ejecucióndel script programado en Python

Figura 4.10: Conexión, edición y ejecución de un script en Python para BeagleBoneBlack

Cuando se desea integrar la BeagleBone Black para controlar un sistema autónomo,

suele ser conveniente modificar el fichero rc.local para que el script que se desea

ejecutar una vez se inicie el programa, ubicado en home, sea lanzado tras el encendido

de la placa. Para ello, se añaden las líneas señaladas en la figura 4.11 para forzar el

arranque del script cuando se activa el sistema.

Figura 4.11: Configuración de rc.local para el lanzamiento automático de scripts

54 4.4. Antena VHF

4.4. Antena VHF

Con respecto a la selección de una antena de VHF marítimo apropiada para el

prototipo desarrollado, se diferencia entre el modelo escogido para las pruebas iniciales,

que incluye una base magnética de soporte, y la antena embarcada en el dron. De este

modo, la antena de VHF marítimo escogida para las pruebas iniciales del prototipo

presenta las características señaladas en la tabla 4.2, usando para su conexión con el

módulo Cobalt un cable Hirose U.FL a SMA hembra, tal y como se presenta en el

diagrama de la figura 4.12.

Tabla 4.2: Parámetros de la antena de VHF con base magnética para el módulo Cobalt

Parámetro ValorImpedancia 50 ΩBanda de frecuencia 156 – 174 MHzFrecuencia central 162 MHzGanancia 1.5 dBi

COE 1.2:1Conector SMA machoAltura 400 mmPeso 60 g

400 mm

Base magnéticacon diámetro de25 mm

SMA macho

Conector U.FL a SMApara la conexión conel módulo Cobalt

Figura 4.12: Modelo de antena de VHF con banda magnética seleccionado


Sin embargo, la selección de una antena de para AIS adecuada para ser embarcada

en un dron, en lo que respecta al peso y las dimensiones, no es una tarea evidente. En la

actualidad, se han realizado estudios para determinar si es viable utilizar la tecnología

microstrip para implementar antenas de VHF propias para el sistema AIS [39], pero a

nivel comercial no existen productos con estas características. Por ello, la antena esco-

gida para este prototipo es el modelo Motorola PMAD4095A, que también se emplea

para walkie-talkies en la banda de VHF marítimo (figura 4.13), y sus dimensiones, peso

y características radio son aceptables, tal y como se indica en la tabla 4.3.

Tabla 4.3: Parámetros de la antena de VHF Motorola PMAD4095A para el móduloCobalt

Parámetro ValorImpedancia 50 ΩBanda de frecuencia 160 – 174 MHzFrecuencia central 162 MHzGanancia 2 dBi

COE 2:1Conector SMA machoAltura 11 cmPeso 20 g

11 cm

Conector SMAhembra

Transición SMA-SMA machopara conectar la antena alcable Hirose U.FL-SMA

Figura 4.13: Modelo de antena de VHF Motorola PMAD4095A

Con el fin de caracterizar ambas antenas de una forma más precisa, en la figura 4.14

se presentan sus medidas de COE para la frecuencia de 162 MHz, realizadas a través

de un analizador de redes. Para esta frecuencia, el COE se mantiene para la antena

de VHF con base magnética, pero mejora considerablemente para la antena de VHF

56 4.5. Antena GPS

portable con un COE de 1.4:1.

(a) Medida de COE para antena de VHF con basemagnética

(b) Medida de COE para antena de VHF portable

Figura 4.14: Medidas adicionales del COE sobre las antenas de VHF utilizadas

4.5. Antena GPS

La antena de GPS escogida para este prototipo es el modelo Trimble 66800-52-SP,

que presenta las características señaladas en la tabla 4.4. Esta antena se conecta con el

módulo Cobalt a través de un cable Hirose U.FL a SMA hembra, tal y como se indica

en la figura 4.15.

Tabla 4.4: Parámetros de la antena de GPS Trimble 66800-52-SP para el módulo Cobalt

Parámetro ValorImpedancia 50 ΩFrecuencia central 1575.42 MHz ± 3 MHzPolarización CircularCOE 1.2:1Conector SMA machoDimensiones 37.4 mm × 34 mm × 12.9 mmPeso 25 g


Conector U.FL a SMApara la conexión conel módulo Cobalt

SMA machoAntena GPS

Látigo de 1 metro

Figura 4.15: Modelo de antena de GPS Trimble 66800-52-SP

Capítulo 5

Integración del prototipo

5.1. Interconexionado hardware

Con el objetivo de conectar todos los módulos que deben incorporarse al prototipo,

es necesario realizar dos etapas de integración. Previamente, es necesario realizar una

integración básica de los módulos para verificar su correcto funcionamiento y estudiar

las conexiones necesarias para habilitar las actividades que ejerce el prototipo. Final-

mente, se realiza la integración de este prototipo en un dron experimental a partir de la

sustitución de ciertos elementos inviables debido a su peso y tamaño, y posteriormente

su ensamblado en la aeronave.

La etapa previa a la integración y configuración del prototipo en un dron experi-

mental exige que el elemento fundamental de este prototipo, que es el transpondedor

AIS clase B basado en el módulo Cobalt, sea configurado de forma independiente con

los datos estáticos (nombre, MMSI, tipo de vehículo...) solicitados previamente por la

Dirección General de la Marina Mercante. De esta manera, el módulo Cobalt es capaz

de transmitir sus datos al resto de estaciones AIS e identificarse en el sistema.

En la figura 5.1 se representa el diagrama de bloques del montaje de integración

inicial del prototipo desarrollado.

59

60 5.1. Interconexionado hardware

Transpondedor AIS clase BSRT-Marine Cobalt


Antena VHF marítimocon soporte magnético

Antena GPScon soporte magnético

Fuente de alimentaciónPROMAX FAC-662B

Figura 5.1: Diagrama de bloques del prototipo inicial

Por otro lado, algunos elementos utilizados en la integración inicial se sustituyen,

como ocurre con la fuente de alimentación, por otros módulos integrables en un dron,

mientras que las conexiones entre el microcontrolador y el transpondedor AIS se man-

tienen inalterables. De esta manera, se atiende principalmente a la manera de embarcar

estos componentes en la aeronave y con ello, integrar el prototipo final con el que se

realiza la verificación final.

En la figura 5.2 se representa el diagrama de bloques del montaje de integración

final del prototipo desarrollado y embarcado en un dron.

Transpondedor AIS clase BSRT-Marine Cobalt


Antena VHF marítimoportable

Antena GPScon soporte magnético

Batería para UAVZippy 5000 20C

Figura 5.2: Diagrama de bloques del prototipo final


5.1.1. Configuración del transpondedor AIS clase B

Previamente a la interconexión entre el transceptor AIS clase B Cobalt y la placa

BeagleBone Black, es necesario configurar los datos estáticos del módulo Cobalt por

medio de la habilitación de un nombre y un MMSI, asignados por la Dirección General

de la Marina Mercante. El procedimiento llevado a cabo para esta solicitud se detalla

en el anexo A de esta memoria, por lo que a continuación solamente se indican cuáles

son los datos asignados al módulo Cobalt que integra el prototipo desarrollado.

En términos de este Trabajo Fin de Máster, el módulo Cobalt se enmarca en el tipo

de embarcación número 99, que se destina a estaciones habilitadas para usos distintos a

los que habitualmente se destinan estos dispositivos. Con ello, Dirección General de la

Marina Mercante asigna un el MMSI de número 111224515 a la estación con nombre

IDETIC DRONE AIS. En el momento que se conozcan estos datos, es posible configurar

el módulo Cobalt a través del software proAIS2.

Para ello, se conecta a través de USB el módulo Cobalt con un ordenador personal

que ejecute el software proAIS2. Cabe señalar que para la conexión por USB entre el

módulo Cobalt y el ordenador personal, es necesario construir un cable propio, soldado

y recubierto con un tubo termoretráctil, a partir de un conector USB tipo A macho y

cuatro cables con pines adaptables al conector Hirose DF13 que se encuentra integrado

en el módulo Cobalt.

Una vez el software proAIS2 detecta el puerto del dispositivo (AIS Virtual COM), se

habilita la conexión y se accede a la vista de configuración. Luego, se rellenan los campos

referentes al MMSI, el nombre y el tipo de la embarcación con los datos asignados por

la Dirección General de la Marina Mercante. Finalmente, estos datos se vuelcan sobre el

módulo Cobalt, sin posibilidad de revertir la configuración, y apareciendo un mensaje

de alerta que indica que el número de MMSI asignado debe ser válido de cara al marco

legislativo del país. Una vez se aceptan las condiciones de configuración, el módulo ya

se encuentra operativo para iniciar la transmisión de mensajes AIS con ayuda de las

antenas de VHF marino y GPS. Este proceso de configuración se representa a través

de un esquema en la figura 5.3.


Ordenadorpersonal

MóduloCobalt

Antena deVHF marino

Antena deGPS

Figura 5.3: Conexión y configuración del módulo Cobalt con el software proAIS2

5.1.2. Montaje del prototipo inicial

Los dos módulos fundamentales que forman parte del prototipo que se plantea en

este Trabajo Fin de Máster son el microcontrolador, a través de la placa BeagleBone

Black, y el transpondedor AIS clase B, basado en el módulo Cobalt de SRT-Marine,

que se conectan a través de una interfaz serie USB. Además, el módulo Cobalt precisa

una alimentación de al menos 12.6 V para la transmisión de los datos, de modo que

inicialmente se debe conectar sus pines relativos a la alimentación a una fuente de

alimentación externa.

En lo que respecta a la conexión USB, la BeagleBone Black utiliza sus pines para

la UART1 para enviar y recibir, en caso de ser necesario, los comandos NMEA que

es capaz de interpretar el módulo Cobalt, tal y como se representa en el esquema

de la figura 5.5, y se conectan además las antenas de VHF con base magnética y

de GPS a los conectores SMA hembra señalados. Finalmente, se ejecuta el firmware

implementado en la BeagleBone Black para transmitir los datos generados al módulo

Cobalt y seguidamente, por la antena de VHF.


Transceptor AIS clase BSRT-Marine Cobalt


UART1_TX

UART1_TX

12.6 V 0 V

VCC (5 V)

GND

Conector para antena de GPS

Conector para antena de VHF

Figura 5.4: Conexiones entre los módulos del prototipo inicial

En la figura 5.5 se presenta el montaje físico del prototipo inicial que se implementa

durante la fase de interconexión del prototipo.

Módulo Cobalt

Antena GPS Antena VHFOrdenador personal

Fuente de alimentación

Figura 5.5: Montaje físico del prototipo inicial


5.1.3. Integración del prototipo en un dron experimental

Para la integración hardware del prototipo en un dron experimental, basado en el

tricóptero DIY Y6 de 3D Robotics, es necesaria la sustitución de ciertos elementos

habilitados para su integración en esta aeronave. Además de la inclusión de nuevos

elementos como son el controlador de vuelo ArduPilot y la batería LiPo para la ali-

mentación del UAV, los elementos que requieren ser sustituidos para la integración del

prototipo sobre el dron experimental son los siguientes:

La antena VHF con base magnética se sustituye por una antena VHF portable,

modelo Motorola PMAD4095A, debido a su pequeño tamaño y bajo peso, además

de la conservación de las características radio respecto a la antena VHF inicial.

Por razones de peso y dimensiones, fuente de alimentación pasa a ser una ba-

tería LiPo, modelo TATTU 1300mAh 25C, que entrega una tensión de 12.6 V,

suficiente para habilitar la transmisión de mensajes por parte del módulo Cobalt.

De esta manera, en la figura 5.5 se presenta el montaje físico realizado sobre el dron

con los elementos previamente integrados en el prototipo inicial y los nuevos elementos

para la transmisión en VHF y la alimentación de la aeronave.

Antena GPS

Antena VHF

Módulo Cobalt

Batería LiPo

ArduPilot

BeagleBone Black

Power-Bank

Figura 5.6: Integración física del prototipo en un dron experimental


Cabe señalar que con el objetivo de alimentar a la placa BeagleBone Black, es nece-

sario incluir un dispositivo Power-Bank conectado al puerto mini-USB de la placa. Este

dispositivo, fundamentalmente utilizado para la alimentación de dispositivos móviles en

situaciones donde no es posible recargarlos a través de la toma eléctrica convencional,

entrega una tensión de 5 V, suficiente para alimentar a la BeagleBone Black y permitir

la ejecución del firmware implementado en la misma.

5.2. Firmware de control

La creación de mensajes AIS propios con formato NMEA es una de las funcionalida-

des que incluye el prototipo diseñado, y permite el envío de parámetros específicos del

dron dentro del campo de datos del mensaje seleccionado para este propósito. Por ello,

el firmware de control que se programa en la BeagleBone Black permite crear un tipo

de mensaje HDT (Heading True), empleado para obtener la orientación de dispositivos

externos al equipo AIS a partir de la información paramétrica recogida del dron.

Tras una configuración previa del dron, el proceso para desarrollar este firmware

de control comienza con la captura de los valores de yaw que entrega el dron en todo

momento. Estos valores se actualizan a medida que el dron varíe su rumbo, y se integran

en el formato de mensaje HDT creado previamente sobre un script en Python. De este

modo, cuando se completa el campo de datos del mensaje, se calcula el checksum

asociado y se vuelca sobre el mensaje final, que se envía a través de una UART de la

placa BeagleBone Black hasta el módulo Cobalt. Con ello se consigue enviar, a través

del módulo Cobalt, un mensaje propio que contiene un parámetro característico del

dron, como es el yaw, siendo escalable para otros posibles parámetros que quieran

enviarse con este prototipo.

El hecho de elegir el yaw para el desarrollo de mensajes NMEA propios se debe

a que el valor que se envía coincide con el del COG (Course Over Ground), que se

transmite automáticamente desde el dispositivo Cobalt en los mensajes AIS tipo 18, lo

que permite constatar la viabilidad de creación de mensajes propios. En la figura 5.7

se presentan las fases que conforman el algoritmo que se implementa en un script de

Python sobre la BeagbleBone Black.

66 5.2. Firmware de control

Captura de datos angularesdel dron en MAVLink

Creación de mensaje AIStipo HDT sin checksum

Cálculo del checksum demensaje AIS tipo HDT

Creación de mensaje AIStipo HDT con checksum

Envío del mensaje AIStipo HDT por la UART

Figura 5.7: Etapas del algoritmo para la creación y envío de un mensaje AIS tipo HDT

En los siguientes puntos se explica cada una de estas fases y su implementación en

Python. El código completo de este script se encuentra en el anexo D.1.

5.2.1. Captura de valores angulares

La biblioteca MAVLink, al ser instalada en el controlador de vuelo del dron, permite

acceder a toda la información paramétrica de la aeronave. Con ello, la lectura de los

parámetros relativos a los ángulos de navegación de un dron se recogen en un fichero

en C++ llamado attitude_module, que integra las funciones para capturar y devolver

los valores de yaw, pitch y roll del dron, entre otros parámetros.

Cuando este fichero se ejecuta, genera un fichero llamado attitude_execute donde

se almacenan los valores actualizados de los ángulos de navegación del dron. Por tanto,

en el script de Python donde se desarrolla el firmware de control del prototipo, se hace

una llamada a este fichero con la función call, que habilita el uso de la función getYaw

para la obtención de los valores actualizados del yaw del dron.


1 import os

2 call (./ attitude_execute , shell = true)

3 yaw = get_yaw ()

5.2.2. Creación de mensaje HDT

Para la formación del mensaje HDT, se declara una variable llamada data como

string que incluye la cabecera $HEHDT, junto al valor del yaw del dron capturado con

la función getYaw() importada previamente y el parámetro true, T, que se ubica antes

del cálculo del checksum.

1 yaw = getYaw ()

2 data = "$HEHDT ," + yaw + ",T*"

A partir de la formación de este mensaje, es posible obtener su checksum calculando

de forma iterada la OR-exclusiva entre los caracteres consecutivos que se ubican en el

campo de datos. Para ello, el código asociado a este cálculo determina, a partir de los

delimitadores $ y !, el inicio del mensaje, mientras que el final se indica a partir del de-

limitador *. De esta manera, a partir de los datos ubicados entre ambos delimitadores,

se calcula con un bucle la OR-exclusiva entre caracteres consecutivos del contenido del

mensaje, y finalmente, se obtiene el checksum asociado. Por último, se vuelve a formar

un string con el mensaje con checksum, que se almacena en la variable message.

1 # inicializacion de inicio y fin de mensaje

2 end = data.find(’*’)

3 start = 0

4 if data [0] in (’$’,’!’):

5 start = 1

6 if -1 != end:

68 5.2. Firmware de control

7 data = data[start:end]

8 else:

9 data = data[start :]

10

11 # calculo de checksum

12 sum = 0

13 for k in data:

14 sum = sum ^ ord(k)

15 sumHex = " %x" % sum

16 if len(sumHex) == 1:

17 sumHex = ’0’ + sumHex

18 checksum = sumHex.upper ()

19 message = data + "*" + str(checksum)

5.2.3. Envío de mensaje HDT por UART

Una vez creado el mensaje HDT con el contenido del yaw y el checksum asociado,

se habilita el puerto serie UART1 de la BeagleBone Black para realizar la transmisión

del mensaje hasta el módulo Cobalt. Para ello, es necesario importar desde la biblio-

teca Adafruit_BBIO las funciones relativas a la UART del dispositivo, y seguidamente

habilitar la UART1 mediante la función setup.

1 import Adafruit_BBIO.UART as UART

2

3 # codigo del programa

4

5 UART.setup("UART1")


Seguidamente, se habilita el puerto ttyO1 de la placa y se le asocia una velocidad de

9600 baudios, de manera que es posible abrir y cerrar el puerto a partir de las funciones

open y close, respectivamente.

1 ser = serial.Serial(port = ’/dev/ttyO1’, baudrate = 9600)

2 ser.close ()

3 ser.open()

Por último, se establece una condición que indica que si el puerto declarado está

abierto, se escriba sobre éste el contenido del mensaje NMEA generado anteriormente.

Para ello, es necesario declarar la condición mediante el uso de la función isOpen, que

devuelve un valor verdadero siempre que el puerto asociado no haya sido cerrado, y

finalmente escribir el mensaje HDT a través de la función write.

1 if ser.isOpen ():

2 ser.write(message)

Capítulo 6

Verificación y pruebas del sistema

6.1. Introducción

Tras la integración del prototipo en el dron experimental, se realizan diversas prue-

bas para verificar si el funcionamiento del prototipo diseñado presenta un comporta-

miento satisfactorio que permita su viabilidad de integración en un UAV. Para ello, es

necesario realizar una instalación previa que permita verificar el envío de los mensa-

jes AIS generados por el prototipo de una forma sencilla, y que además posibilite la

recuperación de estos mensajes para su posterior análisis.

A continuación, se describen brevemente las pruebas fundamentales que se llevan

a cabo para la verificación del prototipo, además de la descripción de la instalación

puesta a punto para la realización de las pruebas. Con ello, las pruebas realizadas en

este punto se clasifican en dos grupos:

Verificación de los mensajes transmitidos por el prototipo mediante la consulta de

los ficheros almacenados, donde se analiza tanto la trama NMEA correspondiente

al MMSI del prototipo, que es recibida en la estación AIS BMT-IDeTIC, como

los datos extraídos tras solicitarlos a la API de MarineTraffic.

Verificación gráfica de los mensajes transmitidos por el prototipo a partir de la

aplicación OpenCPN y la plataforma web de MarineTraffic para la visualización

de estaciones AIS.

71

72 6.2. Descripción de la instalación

6.2. Descripción de la instalación

La instalación necesaria para realizar las pruebas de comunicación con el prototipo

diseñado consta de dos elementos fundamentales, que son los siguientes:

Arqueta de comunicaciones, donde se instala la estación receptora AIS BMT-

IDeTIC cedida por MarineTraffic, y que posteriormente envía sus datos como

paquetes de red a través de una Raspberry Pi a la que se accede mediante una

conexión Telnet.

Servidor Linux, donde se alojan los scripts ejecutados para el almacenamiento y

tratamiento de los datos recibidos por la estación receptor AIS BMT-IDeTIC.

En la figura 6.1 se presenta el diagrama de bloques general de la instalación, con

todos los elementos mencionados anteriormente, además del prototipo desarrollado.

Otros equipos Receptor AISBMT-IDeTIC

Raspberry Pi

RegletaSwitch

Scripts propios

Conexión API MarineTraffic

Conexión remota

Ordenadorpersonal

Prototipo

Fuente dealimentación

Toma eléctrica

Toma Ethernet

AntenaVHF

AntenaVHF

AntenaGPS

Estación de pruebas AIS del Pabellón B(EITE, Campus de Tafira)Estación receptora AIS BMT-IDeTIC

(Edif. Polivalente II, Campus de Tafira)

Servidor Linux IDeTIC(Edif. Polivalente II, Campus de Tafira)

Servidor MarineTraffic

Conexiones serie

Conexiones de red

Alimentación

Leyenda

Figura 6.1: Instalación general del sistema de pruebas para el prototipo


6.2.1. Arqueta de comunicaciones del IDeTIC

La instalación de la arqueta de comunicaciones del IDeTIC se ubica en la azotea del

Edificio Polivalente II del Parque Científico y Tecnológico, en el Campus de Tafira (Las

Palmas de Gran Canaria, España). En esta arqueta se incluyen diversos sistemas de

comunicación utilizados por el IDeTIC, entre los que se encuentra la estación receptora

AIS BMT-IDeTIC (figura 6.2), basada en un receptor AIS Comar SLR-300N.

Receptor AIS Comar SLR-300N

Raspberry Pi 3

Equipo switch

Otros equiposde comunicación

Regleta dealimentación

Figura 6.2: Disposición de instalación de la arqueta de comunicaciones del IDeTIC

A través de una conexión Ethernet, esta estación receptora envía sus datos a una

dirección y un puerto del servidor de MarineTraffic, y por medio de una API los usuarios

pueden acceder a la información AIS capturada por este dispositivo. Sin embargo, la

orientación comercial de esta API cercena numerosos datos AIS que no son de interés

comercial, y únicamente cuenta con aquellos mensajes que resultan significativos para

un estudio estadístico del tráfico marítimo cercano a la estación o la recolección de

datos para su posterior visualización gráfica en la plataforma web de MarineTraffic.

Por ello, debido a la necesidad de acceder a todos los datos que recibe y decodifica

la estación BMT-IDeTIC, se opta por incluir una placa Raspberry Pi 3 que, mediante

una conexión serie con el receptor AIS, es capaz de capturar los datos AIS recibidos

y ejecutar un daemon de Linux llamado ser2net, que convierte estos datos serie en

74 6.2. Descripción de la instalación

paquetes de red. De esta manera, habilitando una conexión Telnet con la Raspberry

Pi sobre una dirección IP y un puerto dados, es posible acceder a los datos desde la

terminal de comandos de cualquier sistema operativo (figura 6.3).

BMT-IDeTIC Raspberry Pi 3 Switch

12 V 5 V 12 V

USB Ethernet Ethernet

230 V

Figura 6.3: Conexiones en la estación receptora AIS BMT-IDeTIC dentro de la arquetade comunicaciones del IDeTIC

6.2.2. Servidor Linux del IDeTIC

Con el fin de almacenar los datos recibidos por la estación AIS BMT-IDeTIC, el

IDeTIC cuenta con un servidor Linux instalado en el Edificio Polivalente II del Campus

de Tafira, al que se puede acceder remotamente a través de una conexión SSH o SFTP,

y que aloja los contenidos de los proyectos que se llevan a cabo en este centro. En este

servidor se pueden ejercer dos vías de funcionamiento para la obtención y visualización

de los datos recogidos por la estación AIS BMT-IDeTIC, que son los siguientes:

A través de scripts propios en Bash, se puede realizar una llamada a la API de

MarineTraffic para visualizar y almacenar los datos recogidos por la estación AIS

BMT-IDeTIC.

Mediante la implementación de scripts propios en Python, se pueden extraer y

decodificar los mensajes AIS que salen del puerto serie de la estación AIS BMT-

IDeTIC y enviarlos a través de la utilidad ser2net como paquetes de red.

Por un lado, los ficheros en Bash permiten obtener los valores de la API de Marine-

Traffic y almacenarlos en diferentes formatos, entre los que destacan los formatos CSV

(Comma-separated values) y XML (eXtensible Markup Language). De esta manera,

es posible volcar el registro de todos los mensajes AIS obtenidos por la estación AIS


BMT-IDeTIC sobre un fichero Excel o un servidor web, facilitando así su posterior

consulta y tratamiento para diferentes aplicaciones.

Por otro lado, el número masivo de mensajes recibidos por la estación AIS BMT-

IDeTIC provoca que la detección de aquellos mensajes propios del prototipo desarro-

llado resulte tediosa. Por ello, se justifica el desarrollo de los scripts en Python para

poder recoger los mensajes AIS decodificados por el equipo de la estación AIS BMT-

IDeTIC a través de su puerto serie. Estos scripts permiten almacenar los mensajes

AIS en bruto y evitar el cercenamiento que realiza MarineTraffic al filtrar únicamente

aquellos campos que son de interés comercial. Los dos scripts en Python principales

para este propósito son los siguientes:

ais_bmtidetic.py, una biblioteca de libre acceso [40] que permite decodificar los

mensajes AIS en formato NMEA que se introducen en su entrada. Originalmente,

este script incluye una sección de código que permite dar distintos formatos a las

tramas AIS, de manera que se elimina y se vuelca en un nuevo script denominado

ais.py, al que se llama cuando se desee mostrar los datos AIS recibidos de forma

desglosada u otras funcionalidades programadas en el mismo.

servertel2.py, un código propio, incluido en el anexo D.2, que abre una co-

nexión Telnet sobre una dirección y un puerto dados en donde la Raspberry Pi

vuelca sucesivamente los datos recogidos vía puerto serie por la estación AIS

BMT-IDeTIC. De este modo, filtra a través de una condición únicamente aque-

llos mensajes AIS que contengan un MMSI que coincida con el del prototipo, y

finalmente los almacena en dos ficheros de texto junto con la fecha y hora de

almacenamiento, que son los siguientes:

- bmtidetic_file_parsed: se almacenan los mensajes AIS codificados con

NMEA que son transmitidos por el prototipo desarrollado.

- bmtidetic_file_raw: a partir de los mensajes AIS del prototipo, hace una

llamada a una de las funciones del script ais_bmtidetic.py y vuelca el

contenido decodificado de la trama AIS, presentado de forma tabulada.

En la figura 6.4 se representa el flujo de ejecución de todos los scripts que se ejecutan

para la realización de las pruebas presentadas a continuación.

76 6.3. Verificación y pruebas del prototipo integrado

Importar

servertel2.py bmtidetic_file_raw.txt

bmtidetic_file_parsed.txt

ais_bmtidetic.py

ais.py

Ejecutar yalmacenaren fichero

Introducirficheros

Mensajes conotros formatos

Conexión Telnet(dirección, puerto)

Datos AIS en CSV

API de MarineTraffic Ficheros Bash

propios del IDeTIC

Datos recibidos de la estación AIS

BMT-IDeTIC

Tratamiento de los datos AIS

Conexiónserie conser2net

Figura 6.4: Flujo de ejecución de los scripts implementados

6.3. Verificación y pruebas del prototipo integrado

Para la realización de las pruebas de transmisión y recepción de los mensajes AIS

relativos al prototipo desarrollado, es necesaria la ejecución de los ficheros comenta-

dos en el apartado anterior. De esta manera, se obtiene durante un cierto periodo de

tiempo los mensajes AIS transmitidos por el prototipo y posteriormente, recibidos por

la estación AIS BMT-IDeTIC y almacenados en el servidor Linux del IDeTIC sobre

ficheros de texto. Aquellos mensajes que se corresponden únicamente con el prototipo

se filtran a partir de su MMSI, representándose junto a los campos asociados a los

mensajes y en formato de tramas con formato NMEA.


Además, aprovechando la utilidad que aporta la API de MarineTraffic, se realiza una

comparativa entre los valores almacenados en ficheros CSV a través de esta API y los

que se obtienen tras la ejecución de los scripts comentados anteriormente. Finalmente,

se comprueba a través de dos herramientas software de visualización de estaciones AIS

que el prototipo transmite los datos recogidos y es identificable, de forma gráfica, a

través de este tipo de aplicaciones.

6.3.1. Verificación de mensajes AIS transmitidos y recibidos

En los ficheros de texto bmtidetic_file_parsed y bmtidetic_file_raw se alma-

cenan todos los mensajes AIS del prototipo, filtrados a partir del MMSI asignado y

enviados durante un periodo de 24 horas. Inicialmente, los parámetros a los que se

atiende para las pruebas son los siguientes:

MMSI, formado por 9 dígitos que identifican a la estación AIS.

STATUS, indica el tipo de embarcación que contiene a la estación AIS.

TIMESTAMP, indica la fecha y hora de llegada de cada mensaje AIS.

LAT, indica la latitud en formato decimal.

LON, indica la longitud en formato decimal.

SPEED, indica la velocidad a la que se desplaza la estación AIS.

COG, indica el rumbo de la estación AIS.

HDT, indica el rumbo de la estación AIS señalada por el dispositivo GPS con el

que se comunica el piloto automático del dron a través de comandos MAVLink.

El parámetro TIMESTAMP permite monitorizar los tiempos de llegada y almacena-

miento de los mensajes durante el periodo de pruebas. Debido a que durante el periodo

indicado se recibe un total de 240 mensajes AIS tipo 24 (estáticos) y 480 mensajes AIS

tipo 18 (dinámicos), es necesario tomar una muestra de 10 mensajes significativos en

tiempos consecutivos dos a dos.


En la tabla 6.1 se representan 10 tramas AIS del prototipo, recibidas durante el

periodo de pruebas y almacenadas en el fichero bmtidetic_file_raw, donde se pueden

distinguir tanto mensajes AIS estáticos como dinámicos.

Tabla 6.1: Tramas NMEA contenidas en los mensajes AIS transmitidos por el prototipo

Mensajes AIS en formato NMEA!AIVDM,1,1„A,B1b4Vhh00?fD8D40wssJWwl5oP06,0*4D 17:30:42, 02/02/17!AIVDM,1,1„A,B1b4Vhh00?fD8>40wrWJWwlUoP06,0*72 17:33:43, 02/02/17!AIVDM,1,1„A,H1b4VhmSC=D5j0Q0000000000000,0*3D 21:36:40, 02/02/17!AIVDM,1,1„B,H1b4VhmSC=D5j0Q0000000000000,0*3E 21:42:41, 02/02/17!AIVDM,1,1„A,B1b4Vhh00?fD8U40wsoJWwl5oP06,0*40 02:00:40, 03/02/17!AIVDM,1,1„B,B1b4Vhh00?fD8LT0wr3JWwl5oP06,0*67 02:03:41, 03/02/17!AIVDM,1,1„A,B1b4Vhh00?fD8QT0wsWJWwl5oP06,0*1C 10:27:41, 03/02/17!AIVDM,1,1„B,B1b4Vhh00OfD8J40wqGJWwl5oP06,0*06 10:30:06, 03/02/17!AIVDM,1,1„B,B1b4Vhh00?fD8G40wsJKWwS5oP06,0*4A 17:24:42, 03/02/17!AIVDM,1,1„A,B1b4Vhh00OfD8L40wtrKWwSUoP06,0*6D 17:27:41, 03/02/17

Atentiendo al TIMESTAMP, se observa que en los periodos consecutivos dos a dos, la

duración de llegada entre mensajes AIS es de 3 minutos. Estos mensajes se corresponden

con los tipo 18, como se comprueba seguidamente a través de la decodificación de

la trama, que son los que indican la información dinámica del prototipo (velocidad,

rumbo, ubicación...). Por otro lado, los mensajes consecutivos con una duración entre

ellos de 6 minutos, indicados con color rojo en la tabla 6.2, se corresponden con los

mensajes estáticos, que únicamente envían información relativa al MMSI o el nombre

de la estación AIS, entre otros.

Seguidamente, se analizan los mensajes AIS dinámicos recogidos en la tabla 6.1

pero decodificados y representados en formato tabular. De este modo, se representan

en la tabla 6.2n los mensajes almacenados en el fichero bmtidetic_file_parse, donde

se pueden apreciar los datos dinámicos decodificados y representados en función de los

campos indicados al inicio de este punto de la memoria.


Tabla 6.2: Muestra de mensajes AIS dinámicos decodificados y con formato tabular

MMSI LAT LONG SPEED COG HDT STATUS TIMESTAMP111224515 28.07 -15.4538 0 341.9 341.6 99 17:30:42, 02/02/17111224515 28.07 -15.4538 0 341.9 341.5 99 17:36:43, 02/02/17111224515 28.07 -15.4538 0 341.9 341.5 99 02:00:40, 03/02/17111224515 28.07 -15.4538 0 341.9 341.6 99 02:03:41, 03/02/17111224515 28.07 -15.4538 0 341.9 341.6 99 10:27:41, 03/02/17111224515 28.07 -15.4538 0 248.9 248.3 99 10:30:06, 03/02/17111224515 28.07 -15.4538 0 248.9 248.3 99 17:24:42, 03/02/17111224515 28.07 -15.4538 0 248.9 248.2 99 17:27:41, 03/02/17

Atendiendo al parámetro TIMESTAMP de esta tabla, se observa que los parámetros

dinámicos se mantienen constantes durante aproximadamente 16 horas. Sin embargo,

aproximadamente a las 10:30 horas, se hace mover el dron apuntando a otra dirección,

por lo que los valores angulares del parámetro COG varían significativamente. Al no

haber desplazamiento del dron, la velocidad (SPEED) se mantiene nula y por tanto, el

periodo de envío de los mensajes estáticos se mantiene en 3 minutos, tal y como indica

el estándar. Lo mismo ocurre con la ubicación del dron, dada a través de la latitud y

longitud (LAT y LON), que al no variar la ubicación de la aeronave, siempre marcan el

mismo valor.

Además, se comprueba que el campo HDT es prácticamente idéntico al de COG, con

diferencias menores de 1o que se deben a las desviaciones en los datos GPS del dron, ya

que al realizar estas pruebas dentro de un recinto cerrado, la precisión de las medidas se

reduce. Por otra parte, en lo que respecta a los parámetros estáticos, el parámetro MMSI

indica el identificador propio del prototipo (111224515), mientras que con STATUS se

indica que el prototipo se encuentra a bordo de una estación AIS de tipo 99, clasificada

como otros tipos de embarcaciones. Por tanto, los valores configurados en el módulo

Cobalt coinciden con los indicados en la tabla 6.2.

Finalmente, con el objetivo de visualizar otros formato de tramas AIS, se ha-

ce una llamada al script ais.py para cambiar el formato de presentación a partir

de la información almacenada en los ficheros de texto bmtidetic_file_parsed y

bmtidetic_file_raw. En las tablas 6.3 y 6.4 se presenta un ejemplo de mensaje AIS

tipo 18 y tipo 24, respectivamente, sobre los que se les aplica el formato desglosado

que se ejecuta desde el script ais.py.


Tabla 6.3: Mensaje AIS tipo 18 del prototipo con campos de datos desglosados

Parámetro ValorMessage Type 18Repeat Indicator 0MMSI 111224515Regional reserved 0Speed Over Ground 0.0Position Accuracy 1Longitude -15.4537666667Latitude 28.0711133333Course Over Ground 248.9True Heading 248.3Time Stamp 7Regional reserved 0CS Unit 1Display flag 0DSC flag 1Band flag 1Message 22 flag 1Assigned 0RAIM flag 1Radio status 917510

Tabla 6.4: Mensaje AIS tipo 24 del prototipo con campos de datos desglosados

Parámetro ValorMessage Type 24Repeat Indicator 0MMSI 111224515Part Number 1Ship Type 99Vendor ID SMTE2Call SignDimension to Bow 0Dimension to Stern 0Dimension to Port 0Dimension to Starboard 0


6.3.2. Comparativa de resultados obtenidos a través de la API

de MarineTraffic

En virtud de los resultados obtenidos en las pruebas anteriores, es posible hacer una

comparación entre estos resultados y los que automáticamente se obtienen a través de

la API de MarineTraffic. En este sentido, con la API se generan ficheros CSV de los

datos recibidos por todas las estaciones AIS circundantes, pero se realiza el mismo

filtrado en función del MMSI del prototipo que se aplica en las pruebas anteriores. De

esta manera, se almacenan los mensajes recibidos durante un periodo de 24 horas en

la misma fecha y hora en que se comienzan a realizar las pruebas iniciales.

Con ello, se extraen estos mensajes AIS almacenados en el servidor Linux del IDe-

TIC como ficheros CSV durante el periodo indicado. Seguidamente, se toma una mues-

tra de 10 mensajes que coincida con los mensajes tomados en la muestra de la tabla

6.2, en virtud de los tiempos de almacenamiento del mensaje sobre el fichero, tal y

como se refleja en la tabla 6.5.

Tabla 6.5: Mensajes AIS obtenidos desde la API de MarineTraffic

MMSI LAT LON SPEED COG STATUS TIMESTAMP111224515 28.0711 -15.4538 0 341.9 99 2016-12-02T17:30:06111224515 28.0711 -15.4538 0 341.9 99 2016-12-02T17:36:4111224515 28.0711 -15.4538 0 341.9 99 2016-12-03T02:00:06111224515 28.0711 -15.4538 0 341.9 99 2016-12-03T02:03:06111224515 28.0711 -15.4538 0 341.9 99 2016-12-03T10:27:06111224515 28.0711 -15.4538 0 248.9 99 2016-12-03T10:30:42111224515 28.0711 -15.4538 0 248.9 99 2016-12-03T17:24:05111224515 28.0711 -15.4538 0 248.9 99 2016-12-03T17:27:41

Por tanto, si se comparan los valores de las tablas 6.2 y 6.5, exceptuando el pará-

metro HDT que no entrega la API de MarineTraffic, se observa que salvo los tiempos de

recepción de los mensajes, el resto de parámetros coinciden. Esto se debe a que el servi-

dor de MarineTraffic toma su propio tiempo del sistema cuando recibe un mensaje AIS

y lo procesa para su posterior envío, por lo que los tiempos marcados en los mensajes

pueden diferenciarse hasta un máximo de 2 minutos con respecto a los recibidos origi-

nalmente a través de la estación AIS BMT-IDeTIC. Sin embargo, esta prueba permite

constatar que los mensajes del prototipo se reciben correctamente, ya sea a través de


la instalación implementada para realizar las pruebas de verificación anteriores como a

través de la API de MarineTraffic. En este último caso, cabe considerar que los datos

decodificados están limitados en contenido, apareciendo únicamente aquellos campos

más relevantes a nivel comercial.

6.3.3. Verificación mediante herramientas software de visuali-

zación de tráfico marítimo

Otra forma de comprobar el funcionamiento del prototipo es a través de herramien-

tas software destinadas a la monitorización de embarcaciones sobre mapas en tiempo

real. En este sentido, las utilidades más conocidas son la plataforma web de MarineTraf-

fic, de acceso gratuito salvo cuando se requiere una conexión satelital, y la aplicación

gratuita OpenCPN, que permite el seguimiento de embarcaciones en tiempo real de

forma similar a como opera la plataforma de MarineTraffic.

Además, para cada una de estas utilidades existen apps para las plataformas An-

droid e iOS, que permiten consultar el tráfico marino de una región o realizar el segui-

miento de una determinada embarcación desde un dispositivo móvil. Esto supone una

ventaja fundamental en términos de portabilidad frente a los ordenadores personales,

en los que tradicionalmente se ejecutan estas utilidades software. Por tanto, conociendo

el MMSI asignado al prototipo desarrollado, con identificador 111224515, y que el dron

se ubica en el Campus de Tafira, en Gran Canaria, es posible trasladarse sobre esta

región en la visualización de mapas de estas utilidades y consultar, entre las estacio-

nes AIS que aparecen, cuál se corresponde con el prototipo desarrollado, que toma el

nombre de IDETIC DRONE AIS.

En la figura 6.5 se representa la identificación del prototipo sobre la aplicación

web de MarineTraffic, donde se puede observar el identificador MMSI asignado y otros

parámetros relevantes, como su velocidad y curso.


Figura 6.5: Identificación del prototipo sobre la plataforma web de MarineTraffic

Por otro lado, a través del software OpenCPN es posible habilitar una conexión

Telnet sobre la dirección y puerto asignados para la recepción de datos de la estación

AIS BMT-IDeTIC, y posibilitar la visualización sobre una carta de navegación de

la información transmitida por el prototipo (figura 6.6). Al igual que la plataforma

de MarineTraffic, se presentan los valores más relevantes que transmite el prototipo,

incluyendo además el campo HDT que indica el yaw de la aeronave.

Figura 6.6: Identificación del prototipo sobre el software OpenCPN

Capítulo 7

Conclusiones

7.1. Resultados y revisión de objetivos

Tras la realización de las pruebas de verificación del prototipo, se puede concluir que

los elementos que conforman el sistema son viables en función los objetivos planteados

en este Trabajo Fin de Máster. De este modo, se ha logrado establecer un prototipo

con capacidad para ser embarcado en un dron y transmitir su identificación a partir de

sus datos estáticos y dinámicos, además de un parámetro adicional relativo a uno de

los ángulos de navegación del dron mediante la creación de un mensaje AIS propio.

Con ello, el módulo Cobalt cumple con las expectativas volcadas sobre el diseño

preliminar del prototipo, de tal forma que en relación a los objetivos planteados en

este trabajo, y también sobre futuras mejoras del prototipo, es un elemento hardware

que se ajusta a las necesidades del prototipo. Del mismo modo, la placa BeagleBone

Black ofrece suficiente potencia de procesamiento como para manejar la captura de

datos del dron y el posterior envío de mensajes AIS propios, demostrando capacidad

para adaptarse a la comunicación con el controlador de vuelo del dron a través del

protocolo MAVLink.

Por otro lado, algunos elementos integrados en el dron pueden ser sustituidos por

otros más adecuados para futuras aplicaciones orientadas a la realización de pruebas

de vuelo. En este sentido, la necesidad de incorporar dos baterías para hacer funcionar

85

86 7.2. Líneas futuras

el prototipo afecta directamente al peso del dron, y por tanto, a su periodo de autono-

mía. Por este motivo, queda latente la necesidad de replantear el sistema para utilizar

una única batería que abastezca tanto a la unidad transceptora AIS como al resto de

elementos integrados en la aeronave. En este sentido, se requiere previamente una ca-

libración precisa para integrar el prototipo en el dron, de forma que la reorganización

de los módulos no afecten a la sustentación de la aeronave en ningún momento.

En virtud de los objetivos planteados en este Trabajo Fin de Máster, las pruebas

de verificación del prototipo han mostrado resultados favorables que han permitido

identificar aquellos elementos sujetos a modificaciones, posibilitando su escalabilidad

en pruebas futuras, principalmente en la fase de vuelo, y orientar su uso hacia un marco

comercial con la colaboración de MarineTraffic.

7.2. Líneas futuras

Tras la realización de este Trabajo Fin de Máster, se plantea la posibilidad de abrir

otras líneas de trabajo a partir de los resultados obtenidos y el análisis de las virtudes y

defectos detectados durante la realización de las pruebas de verificación del prototipo.

Entre las posibilidades planteadas, destacan las siguientes:

Realización de pruebas de vuelo con el prototipo embarcado en un dron ex-

perimental, analizando la ubicación del prototipo previamente para la correcta

calibración de la aeronave.

Estudio de la cobertura satelital del prototipo desarrollado para verificar si la

señal puede ser recogida por la red de satélites AIS, sin necesidad de elementos

hardware adicionales.

Estudio de otros tipos de mensajes AIS, así como la implementación de mensajes

propios adicionales que permitan la transmisión de otros parámetros relevantes

del dron, como puede ser la altura a la que se encuentra durante el vuelo.

Bibliografía

[1] M. J. Boyle, “The costs and consequences of drone warfare,” International Affairs,

vol. 89, no. 1, pp. 1–29, 2013.

[2] Ó. Díaz Cantos, “Drones y su aplicación en materia de seguridad y salud en el

trabajo,” 2015.

[3] G. J. Knezo, “Possible impacts of major counter terrorism security actions on

research, development, and higher education,” DTIC Document, 2002.

[4] P. N.-C. Contreras, “Modalidades de contratación y empleo joven: novedades del

Real Recreto-Ley 8/2014, de 4 de julio, de aprobación de medidas urgentes para

el crecimiento, la competitividad y la eficiencia),” Actualidad laboral, no. 10, p. 1,

2014.

[5] B. Ley, “18/2014,” Sección 6a, Artículo, vol. 50.

[6] F. Bi and R. Mac, “Drone maker 3D Robotics raises $50 million in latest round.

Forbes,” 2015.

[7] R. TEC2014-60283-C3-2-R, “Frontal de RF direccional y de doble banda para

drones ligeros multicópteros,” MINECO, Enero, 2015.

[8] F. B. Ref. Sivu2015, “Sistema de visión umbral térmico georreferenciado. Apli-

cación al seguimiento de líneas de fuego en incendios forestales,” Ministerio de

Agricultura, Alimentación y Medioambiente, Enero, 2015.

[9] J. Batista, “Caracterización y evaluación de un UAV multirrotor para la obtención

y georreferenciación de imágenes: estudio de viabilidad y demostrador,” Proyecto

Fin de Carrera, Universidad de Las Palmas de Gran Canaria, Julio, 2014.

87

88 BIBLIOGRAFÍA

[10] A. Trujillo, “Sistema de sujeción a líneas de alta tensión mediante UAV multirrotor:

prueba experimental del sistema de guiado autónomo,” Trabajo Fin de Grado,

Universidad de Las Palmas de Gran Canaria, Julio, 2014.

[11] P. Mena, “Guiado de UAV multirrotor asistido por imagen: aplicación a un sistema

de recarga distribuido,” Proyecto Fin de Carrera, Universidad de Las Palmas de

Gran Canaria, Julio, 2015.

[12] J. A. Godoy, “Planificación de ruta de vuelo de un UAV en tiempo real,” Trabajo

Fin de Grado, Universidad de Las Palmas de Gran Canaria, Julio, 2015.

[13] K. Hasegawa, K. Hata, K. Niwa, and J. Fukuto, “Transmission evaluation of Ship-

borne Automatic Identification System (AIS) in congested waterways,” in ITS

Telecommunications, 2008. ITST 2008. 8th International Conference on, pp. 18–

23, IEEE, 2008.

[14] B. J. Tetreault, “Use of the Automatic Identification System (AIS) for Mariti-

me Domain Awareness (MDA),” in Proceedings of OCEANS 2005 MTS/IEEE,

pp. 1590–1594, IEEE, 2005.

[15] “Solicitud MMSI.” http://www.fomento.gob.es/MFOM/LANG_CASTELLANO/

DIRECCIONES_GENERALES/MARINA_MERCANTE/RADIOCOMUNICACIONES/MMSI/.

Accessed: 2016-09-11.

[16] F. Cabrera, N. Molina, M. Tichavska, and V. Arana, “Automatic Identification

System modular receiver for academic purposes,” Radio Science, vol. 51, no. 7,

pp. 1038–1047, 2016. 2015RS005895.

[17] “Control de Operaciones de Dron a través del Sistema AIS. Premio Talento y

Compromiso Cajasiete 2015.” https://www.researchgate.net/publication/

289522517_Control_de_Operaciones_de_Dron_a_traves_del_Sistema_AIS_

Premio_Talento_y_Compromiso_Cajasiete_2015. Accessed: 2016-09-11.

[18] A. Cavoukian, Privacy and drones: Unmanned Aerial Vehicles. Information and

Privacy Commissioner of Ontario, Canada Ontario, Canada, 2012.

BIBLIOGRAFÍA 89

[19] S. Franchini and Ó. L. García, Introducción a la ingeniería aeroespacial. Escuela

Técnica Superior de Ingenieros Aeronáuticos, Universidad Politécnica de Madrid,

2008.

[20] S. W. Space 1999 Telecom, “Convenio con WSN para la mejora de la autonomía

de los UAVs,” BOULGPC, Junio, 2016.

[21] B. Carrasco, J. Alberto, et al., “Integración de un UAV (vehículo aéreo no tripu-

lado) en la plataforma robótica ARGOS,” 2015.

[22] G. Crespo Quirós et al., “Sistema de enlace robusto para la teleoperación de un

UAV (vehículo aéreo no tripulado) en la plataforma robótica ARGOS,” 2015.

[23] L. Meier, J. Camacho, B. Godbolt, J. Goppert, L. Heng, M. Lizarraga, et al.,

“MAVLink: micro-air vehicle communication protocol,” Online]. Tillgänglig:

http://qgroundcontrol. org/mavlink/start.[Hämtad 2014-05-22], 2013.

[24] “MAVLink Protocol. GitHub repository with libraries..” https://github.com/

mavlink. Accessed: 2016-01-08.

[25] K. Li and J. Wonham, “Maritime legislation: new areas for safety of life at sea,”

Maritime Policy & Management, vol. 28, no. 3, pp. 225–234, 2001.

[26] A. Harati-Mokhtari, A. Wall, P. Brooks, and J. Wang, “Automatic Identification

System (AIS): data reliability and human error implications,” Journal of naviga-

tion, vol. 60, no. 03, pp. 373–389, 2007.

[27] A. Norris, “AIS Implementation: success or failure?,” Journal of Navigation,

vol. 60, no. 01, pp. 1–10, 2007.

[28] Recommendation, “M.1371-5,” Technical characteristics for an automatic identi-

fication system using time-division multiple access in the VHF maritime mobile,

vol. ITU-R, 2014.

[29] K. Jaskólski, “Availability and integrity model of Automatic Identification System

(AIS) information,” 2014.

90 BIBLIOGRAFÍA

[30] P. R. Lei, T. H. Tsai, and W. C. Peng, “Discovering Maritime Traffic Route from

AIS network,” in 2016 18th Asia-Pacific Network Operations and Management

Symposium (APNOMS), pp. 1–6, Oct 2016.

[31] N. R. C. U. C. for Evaluating Shipboard Display of Automated Identification Sys-

tems, Shipboard Automatic Identification System Displays: Meeting the Needs of

Mariners. No. 273, Transportation Research Board, 2003.

[32] “CML Microcircuits, Product Selector Catalogue, 2016.” http://www.cmlmicro.

com/assets/CML_Product_Catalogue_September_2016.pdf. Accessed: 2016-12-

21.

[33] N. Molina, “Diseño e implementación de un prototipo hardware para un banco de

pruebas del estándar AIS,” Trabajo Fin de Grado, Universidad de Las Palmas de

Gran Canaria, Julio, 2015.

[34] G. Giuliano, “Shipboard Automatic Identification System Displays,” Transporta-

tion Research Board, Washington DC, p. 4, 2003.

[35] K.-Y. Kim, D.-H. Park, J.-B. Shim, and Y.-H. Yu, “A study of marine network

NMEA2000 for e-navigation,” Journal of the Korean Society of Marine Enginee-

ring, vol. 34, no. 1, pp. 133–140, 2010.

[36] M. Robins, D. Reid, M. Clarke, and N. Emery, “SRT Marine Technology: Cobalt

Integration Guide,” SRT Marine Technology Ltd, vol. LD3700, 2014.

[37] “BeagleBone Black System: Reference Manual.” https://cdn-shop.adafruit.

com/datasheets/BBB_SRM.pdf. Accessed: 2017-01-05.

[38] M. Richardson, Getting Started with BeagleBone: Linux-powered Electronic Pro-

jects with Python and JavaScript. Maker Media, Inc., 2013.

[39] T. Dousset, C. Renard, H. Diez, J. Sarrazin, and A. C. Lepage, “Compact patch

antenna for Automatic Identification System (AIS),” in 2012 15 International

Symposium on Antenna Technology and Applied Electromagnetics, pp. 1–5, June

2012.

BIBLIOGRAFÍA 91

[40] “Christian Gagneraud library for AIS messages decode with python. GitHub repo-

sitory with libraries..” https://github.com/ukyg9e5r6k7gubiekd6/gpsd/blob/

master/devtools/ais.py. Accessed: 2016-01-22.

[41] BOULPGC, “Tabla de Contrataciones de Investigadores con cargo a Proyectos de

Investigación aprobada el 21 de julio de 2012,” Año III, vol. 8.

[42] “Reglamento de Radiocomunicaciones. Resoluciones y Recomen-

daciones, Edición de 2012.” http://www.itu.int/en/history/

HistoryDigitalCollectionDocLibrary/regulations/1.41.48.es.303.pdf.

Accessed: 2016-12-25.

[43] L. del Estado Español, “Real Decreto Legislativo 2/2011, de 5 de septiembre, por

el que se aprueba el Texto Refundido de la Ley de Puertos del Estado y de la

Marina Mercante,” Boletín Oficial del Estado, vol. 253, p. 20, 2011.

[44] “Ley 14/2000 de 29 de diciembre. Medidas fiscales, administrativas y

del orden social..” http://www.minhafp.gob.es/Documentacion/Publico/

NormativaDoctrina/Tributaria/IRPF/LEY%2014.00.pdf. Accessed: 2016-12-

25.

[45] F. Cabrera, N. Molina, M. Tichavska, and V. Araña, “Design of a low cost prototy-

pe of Automatic Identification System (AIS) receiver,” in 2015 1st URSI Atlantic

Radio Science Conference (URSI AT-RASC), pp. 1–1, May 2015.

Parte II

Presupuesto

93

Presupuesto

P.1. Introducción

En este capítulo se desarrolla el presupuesto de este Trabajo Fin de Máster, que

permite valorar los costes que han supuestos los materiales y herramientas utilizados

durante su elaboración, además del coste del trabajo realizado. Para ello, los puntos

tratados en este capítulo en relación al cálculo del coste total que supone este trabajo

son los siguientes:

Costes de los materiales.

Amortización del inmovilizado material.

Trabajo tarifado por tiempo empleado.

Aplicación de impuestos y coste total.

P.2. Costes de materiales

Normalmente, costes de materiales de un proyecto se pueden diferenciar entre

costes de materiales fungibles, referidos a todos aquellos elementos adquiridos y que

están expuestos a un deterioro con el uso durante la elaboración del proyecto, y costes

de materiales no fungibles, que se asume que no están expuestos a deterioro durante

el periodo de ejecución del proyecto. Para este Trabajo Fin de Máster, la ausencia de

materiales no fungibles implica que únicamente se atienda al coste de los materiales

fungibles, dada la temática del mismo, y se clasifican en dos categorías:

95

96 P.2. Costes de materiales

Materiales hardware, que hacen referencia a componentes hardware que son

utilizados para la elaboración de este trabajo, sin incluir los equipos de medida

que, al ser amortizables, no se incluyen en esta categoría.

Materiales software, que hacen referencia a las licencias de los programas que

se emplean en este trabajo, asumiendo un tiempo de uso de un año, motivo por

el que no se incluye en la categoría de elementos amortizables.

Además de esta clasificación, se añaden a los costes materiales la categoría de otros

conceptos de gastos, donde se evalúan aquellos elementos adquiridos que no pueden

englobarse formalmente en ninguna de las dos categorías anteriores, aunque se imputan

igualmente en los costes materiales finales del Trabajo Fin de Máster.

P.2.1. Materiales hardware

En la tabla P.1 se presentan los costes totales, en función del número de unidades

necesarias, de los materiales hardware utilizados en este Trabajo Fin de Máster.

Tabla P.1: Costes de materiales fungibles hardware

Concepto UnidadesCoste

unitario

Coste to-

tal

Carrete de estaño para soldadura (250

g)1 21,26 e 21,26 e

Bote de pasta para soldadura 2,52 e 1 2,52 e

Kit de tubos de plástico termoretrácti-

les10,12 e 1 10,12 e

Transceptor AIS clase B Cobalt 1 250 e 250 e

Microcontrolador BeagleBone Black 1 59,33 e 59,33 e

Conector Hirose DF13-40P-1.25V(91) 10 6,23 e 60,23 e

Cable Hirose DF13 40 1,19 e 47,60 e

Cable USB macho-macho tipo A 2 2,35 e 4,70 e

Pares de cable BNC rojo y negro 1 3,20 e 6,4 e

97

Antena VHF con base magnética 1 12,30 e 12,30 e

Antena VHF portable 1 7,34 e 7,34 e

Antena GPS con base magnética 1 15,85 e 15,85 e

Kit de accesorios y repuestos para dro-

nes 3D Robotics1 1.000 e 1.000 e

Kit de dron DIY Y6 3D Robotics 1 1.300 e 1.300 e

Receptor AIS COMAR SLR-300N 1 459,71 e 459,71 e

Raspberry Pi 3 1 46,50 e 46,50 e

Carcasa protectora para Raspberry Pi 1 7,59 e 7,59 e

Cable Ethernet RJ45 (1 m) 2 1,49 e 2,98 e

Cargador ETA-U90EBE 2A 5V 1 9,90 e 9,90 e

Cargador Power-Bank 2100 mAh 5V 1 14,90 e 14,90 e

Coste total 3.341,3 e

Por tanto, el coste total de los materiales hardware fungibles empleados en este

Trabajo Fin de Máster asciende a tres mil trescientos cuarenta y uno con treinta euros.

P.2.2. Materiales software

En la tabla P.2 se presentan los costes de licencia de cada uno de los programas

utilizados durante la elaboración de este Trabajo Fin de Máster.

Tabla P.2: Costes de materiales no fungibles software

Concepto Coste de licencia

Aplicación proAIS2 0 e

Aplicación OpenCPN 0 e

Editor Python 2.7 0 e

Editor LATEX Texmaker 0 e

Editor Adobe Illustrator 2016 académico 19,66 e

Editor Keynotes para presentaciones 0 e

98 P.3. Amortización del inmovilizado material

Coste total 19,66 e

Por tanto, el coste total de los materiales software fungibles empleados en este

Trabajo Fin de Máster asciende a diecinueve con sesenta y seis euros.

P.2.3. Otros conceptos de gastos materiales

En la tabla P.3 se presentan los costes asociados a aquellos materiales que se ad-

quieren, pero no se enmarcan en la categoría de hardware ni de software.

Tabla P.3: Otros costes materiales

Concepto Coste evaluado o estimado

Material de oficina (folios, tinta de impreso-

ra)80 e

Asignación de MMSI para estación AIS 51,22 e

Coste total 131,22 e

Por tanto, el coste total de los materiales no enmarcados en las categorías hardware

o software empleados en este Trabajo Fin de Máster asciende a ciento treinta y uno

con veintidós euros.

P.3. Amortización del inmovilizado material

El inmovilizado material hace referencia a aquellos elementos que son utilizados

durante la elaboración de este Trabajo Fin de Máster, pero pueden ser reutilizados

para otros propósitos más adelante. De esta manera, los elementos que se engloban en

esta categoría son utilizados durante el periodo de tiempo estipulado para el desarrollo

del Trabajo Fin de Máster, que se conoce como tiempo de vida del producto, y con el

tiempo reducen su valor adquisitivo inicial una cierta cantidad, que es lo que se conoce

99

como valor residual. Además, se debe ponderar el tiempo de ejecución del Trabajo de

Fin de Máster, con una duración aproximada de 6 meses, sobre los valores obtenidos.

De esta manera, para conocer el valor de amortización de los elementos enmarcados

en esta categoría se les debe aplicar la ecuación P.1,

Amortización =

[Va − Vr

T

]· Tu =

[Va − k · Va

T

]· Tu =

[Va · (1− k)

T

]· Tu (P.1)

donde Va es el valor adquisitivo inicial del producto, Vr el valor residual del producto

(que se calcula considerando un porcentaje de desuso k = 0, 6 sobre el valor adquisitivo

inicial), T es el tiempo de vida del producto y Tu el tiempo de uso del mismo, siendo

este último un valor ponderado de 0,33 sobre todos los productos incluidos, debido a

que se estima una duración de 4 meses para la realización del Trabajo Fin de Máster.

En la tabla P.4 se indican aquellos materiales utilizados durante la elaboración de

este Trabajo Fin de Máster y que se enmarcan en la categoría de inmovilizado material.

Tabla P.4: Costes asociados al inmovilizado material

Concepto UnidadesValor de

adquisición

Valor re-

sidual

Vida

útilTotal

Portátil MacBook Pro

Retina 13.3” i5 512

GB

1 1.449 e 869,4 e 5 años 38,25 e

Fuente de alimenta-

ción PROMAX FAC-

662B

1 556,9 e 334,14 e 8 años 9,19 e

Estación de soldadura

JBC1 395 e 237 e 8 años 6,52 e

Antena VHF marino

Shakespeare Marine

5202

2 105,40 e 63,24 e 10 años 2,78 e

100 P.4. Trabajo tarifado por tiempo empleado

Cargador de baterías

iMAX B6 LiPro Ba-

lance Charger

1 32,84 e 19,7 e 1 año 4,33 e

Ordenador Acer i5 512

GB con sistema opera-

tivo Linux

1 865 e 519 e 5 años 22,84 e

Receptor AIS Comar

SLR 300N cedido por

MarineTraffic

1 0 e 0 e 8 años 0 e

Analizador de redes

HP 8753D1 2.943 e 1.765,8 e 10 años 38,85 e

Coste total 122,76 e

Por tanto, el coste asociado al inmovilizado material empleado en este Trabajo Fin

de Máster asciende a ciento veintidós con setenta y seis euros.

P.4. Trabajo tarifado por tiempo empleado

Para calcular el salario que debe percibir el autor de este Trabajo Fin de Máster,

se toma como referencia la Tabla de Contrataciones de Investigadores con cargo a

Proyectos de Investigación de la Universidad de Las Palmas de Gran Canaria, aprobada

el 21 de julio de 2010 y publicada posteriormente en el BOULPG [41]. Se asume que el

autor se enmarca en la clasificación de investigador en proyecto a tiempo parcial, con

una titulación de ingeniero, de modo que su salario mensual es de 1.192,99 e.

Dado que un Trabajo Fin de Máster tiene una duración límite de 300 horas, en la

tabla P.5 se muestra el sueldo total que debe ganar el autor de este trabajo en función

del número de horas dedicadas y el sueldo establecido por la institución mencionada.

101

Tabla P.5: Trabajo tarifado por tiempo empleado

CategoríaSueldo

mensual

Número de ho-

ras trabajadas

Sueldo por ho-

ra trabajada

Sueldo

final

Ingeniero 1.192,99 e 300 6,78 e 2.033,51 e

Por tanto, el salario que percibe el autor de este Trabajo Fin de Máster suma un

total de dos mil treinta y tres con cincuenta y un euros.

P.5. Aplicación de impuestos y coste total

Dado que este Trabajo Fin de Máster se realiza en una institución integrada en la

Comunidad Autónoma de Canarias, sobre los costes totales se debe aplicar el Impues-

to General Indirecto Canario (I.G.I.C.), que se establece en un 7 % sobre los costes

asociados, tal y como se indica en la tabla P.6.

Tabla P.6: Costes totales del Trabajo Fin de Máster

Concepto Coste

Costes de materiales 3.467,88 e

Amortización del inmovilizado material 122,76 e

Trabajo tarifado por tiempo empleado 2.033,51 e

Costes totales (sin I.G.I.C.) 5.624,15 e

Costes totales (con I.G.I.C.) 6.017,84 e

102 P.5. Aplicación de impuestos y coste total

El coste de este Trabajo Fin de Máster titulado Diseño de un prototipo para la

identificación de drones mediante el sistema AIS, considerando la aplicación del I.G.I.C.

sobre el coste final, asciende a un total de seis mil diecisiete con ochenta y cuatro euros.

Fdo.: D. Nicolás Molina Padrón

6 de febrero de 2017

Las Palmas de Gran Canaria

Parte III

Anexos

103

Anexo A

Procedimiento de asignación de un

identificador MMSI

La regulación determinada por la ITU en el Reglamento de Radiocomunicaciones de

1979 [42] y las autoridades competentes en materia de radiocomunicación de cada país

obligan a que cualquier equipo AIS sea provisto de un identificador MMSI. En España,

la asignación de este identificador lo lleva a cabo la Dirección General de la Marina

Mercante, tanto para estaciones terrestres como dispositivos de ayuda a la navegación,

entre los que se encuentra el sistema AIS, tal y como indican el Real Decreto Legislativo

2/2011 de 5 de septiembre [43] y la Ley 14/2000 de 29 de diciembre [44].

De esta manera, cualquier usuario en España que disponga de un transpondedor

AIS, independientemente de la clase que sea o del ámbito de la aplicación a la que se

destine, debe realizar una petición de asignación de MMSI a la Dirección General de

la Marina Mercante por medio del siguiente procedimiento administrativo:

1. A través del acceso a la web del Ministerio de Fomento, el usuario debe rellenar

un formulario con sus datos personales y/o de la institución solicitante, así como

las características técnicas del equipo AIS que desea habilitar para transmitir

(nombre de la estación, tipo de embarcación...).

2. Una vez el usuario completa el formulario, lo envía por medio de un correo elec-

trónico a la dirección indicada en la página web, donde se evalúa la petición

105

106

realizada para posteriormente asignar el MMSI que mejor corresponda al equipo

en función de su ámbito de aplicación.

3. Tras ser aceptada la solicitud, el usuario debe abonar las tasas correspondientes

que indica el procedimiento administrativo de la web. Una vez abonadas las tasas,

se envía por correo electrónico el número de MMSI que ha sido asignado y que

puede ser usado desde ese momento.

4. Después de unas semanas, la Dirección General de la Marina Mercante también

envía una carta con el impreso de solicitud y aceptación del MMSI sellado y

firmado por el administrador correspondiente.

A continuación, se muestra el documento de aceptación de la solicitud de MMSI

que se ha tenido que realizar en este Trabajo Fin de Máster. Algunos de los campos

señalados en el documento adjunto han sido omitidos por los autores de este trabajo

por razones de privacidad.

MINISTERIO

DE FOMENTO

ubdirección General de Seguridad. Contaminación e Inspección Marítima

FCO. JOSÉ CABRERA ALMEIDA

35011 LAS PALMAS G.C. (LAS PALMAS)

E RElARl1\ De F 'I \1)0

DE I FRAE TRl CI llltJ\S,

fltAN POR rE V VI\ ILNDA

OIRECCJÓ '(ihNI RAI IJJ L/\MARI AMl:R \1\11

Madrid, 16 de Noviembre de 2016

ASUNTO: ASIGNACIÓN DE MMSI

Se informa de la asignación de Número de Identificación del Servicio Móvil Marítimo a la siguiente estación:

Tipo de Estación: OTROS SERVICIOS - UNIDADES AÉREAS

Nombre de la Estación: IDETIC DRONE AIS

MMSI Asignado: 111224515

Esta asignación caduca el 30-12-2018, fecha en la que el MMSI deberá ser

desprogramado del equipo y su baja comunicada al Área de Radiocomunicaciones

Marítimas de la DGMM.

Jefe del Area de Radiocomunicaciones Marítimas

••• MADRID Rlg

- N"Doc:201611041741 FReg;

N"Exp:201611020296 Dett: 996/000

D.G.M.M IHIHIIIIIHIIHll!fflHHUIIDIUIUlllil

RUIZ DE Al.ARCO, 1

2�071 MADRID

FAX 91 )9191 ,6

Anexo B

Divulgación de resultados

Durante la realización del Trabajo Fin de Grado que precede a este Trabajo Fin de

Máster, titulado Diseño e implementación de un prototipo hardware para un banco de

pruebas del estándar AIS, se presentó una propuesta y un póster en el Congreso URSI

AT-RASC en mayo de 2015, celebrado en Maspalomas, Gran Canaria (España) [45].

Tras la presentación de esta propuesta, los autores (Francisco José Cabrera Almei-

da, Milûse Tychavska, Víctor Alexis Araña Pulido y Nicolás Molina Padrón) evaluaron

la posibilidad de publicar los resultados obtenidos en los meses posteriores al congre-

so, y en julio de 2016 presentaron el artículo Automatic Identification System modular

receiver for academic purposes en la revista AGU Publication Radio Science, que está

indexada en JCR (Journal Citation Reports) con un factor de impacto 1.273 y situada

en el segundo cuartil dentro del Área de Telecomunicación. En este artículo se seña-

lan los principales hitos alcanzados durante la elaboración del Trabajo Fin de Grado

mencionado, centrando el estudio en el diseño del receptor AIS modular, y no del trans-

misor, de forma que pudiese resultar de interés para fines académicos, principalmente

en lo que concierne al nivel físico de este estándar y en la búsqueda de obtener un re-

ceptor AIS sencillo que no diste demasiado de los modelos comerciales. A continuación,

se adjunta el artículo publicado.

109

Automatic Identification System modular receiverfor academic purposesF. Cabrera1, N. Molina1, M. Tichavska2, and V. Araña1

1IDeTIC, Departamento de Señales y Comunicaciones, Universidad de Las Palmas de Gran Canaria (ULPGC), Las Palmas,Spain, 2Exmile Solutions Limited (MarineTraffic), London, UK

Abstract The Automatic Identification System (AIS) standard is encompassed within the Global MaritimeDistress and Safety System (GMDSS), in force since 1999. The GMDSS is a set of procedures, equipment, andcommunication protocols designed with the aim of increasing the safety of sea crossings, facilitatingnavigation, and the rescue of vessels in danger. The use of this system not only is increasingly attractive tosecurity issues but also potentially creates intelligence products throughout the added-value informationthat this network can transmit from ships on real time (identification, position, course, speed, dimensions,flag, among others). Within the marine electronics market, commercial receivers implement this standardand allow users to access vessel-broadcasted information if in the range of coverage. In addition to satelliteservices, users may request actionable information from private or public AIS terrestrial networks wherereal-time feed or historical data can be accessed from its nodes. This paper describes the configuration of anAIS receiver based on a modular design. This modular design facilitates the evaluation of specific modulesand also a better understanding of the standard and the possibility of changing hardware modules toimprove the performance of the prototype. Thus, the aim of this paper is to describe the system’sspecifications, its main hardware components, and to present educational didactics on the setup and use of amodular and terrestrial AIS receiver. The latter is for academic purposes and in undergraduate studies such aselectrical engineering, telecommunications, and maritime studies.

1. Introduction

The Automatic Identification System (AIS) broadcasts high-speed, automatic, and granular information fromthe activity of vessels at sea. It is a very high frequency (VHF) radio broadcasting system that enables AIS-equipped vessels and shore-based stations to send and receive static (vessel-identifying details), dynamic(vessel position, speed, navigational status, among others), and voyage (destination port and the estimatedtime of arrival of the vessel) information.

An AIS transponder, as a shipboard device, automatically transmits vessel information allowing ships andshore stations to easily receive these details and track, identify, or exchange vessel traffic details. At the sametime, vessels fitted with AIS transponders can be tracked by AIS receivers located along the coast lines or,when out of range of terrestrial networks, throughout a growing number of satellites (and lately nanosatel-lites) fitted with AIS receivers.

The communication standard of the AIS was conceived by the International Telecommunication Unionand adopted by the International Maritime Organization. The latter through the Safety of Life at SeaConvention [Safety of Life at Sea, 1974] and its requirement for AIS transponders is to be fitted aboard inter-national voyaging ships with gross tonnage (GT) of 300 or more and all passenger ships regardless of size.Communication devices that integrate the transmission and receiving capabilities of the AIS are commerciallyavailable [Lanier, 2012; MarineTraffic web, 2016, http://shop.marinetraffic.com/ais-receivers.html]. Theseenable the access to vessel information (speed, heading, course, vessel dimensions, and other particulars)when vessels are within coverage range. However, the acquisition of AIS-receiving devices or custom distri-bution channels from AIS-receiving networks commonly implies a substantial cost, and it is not always acces-sible for nonfunded and academic purposes. Based on the above described need and objective, the presentpaper has been structured as follows.

Section 2 discusses the description of the system in accordance with the Open Systems Interconnection (OSI)model (physical, link, and network layer) and the relevant specifications that all devices must have [ITU-R Rec.M.1371-5, 2014]. Section 3 presents our modular receiver design, implemented in compliance with the AIS

CABRERA ET AL. AIS MODULAR RECEIVER ACADEMIC PURPOSES 1038

PUBLICATIONSRadio Science

RESEARCH ARTICLE10.1002/2015RS005895

Special Section:URSI AT-RASC (Atlantic RadioScience Conference)

Key Points:• Automatic Radio System foridentifying and locating vessels

• Modular receiver for use throughdevices of general purpose

• Explore AIS-related didactics inundergraduate studies

Correspondence to:F. Cabrera,[email protected]

Citation:Cabrera, F., N. Molina, M. Tichavska,and V. Araña (2016), AutomaticIdentification System modular receiverfor academic purposes, Radio Sci., 51,1038–1047, doi:10.1002/2015RS005895.

Received 1 DEC 2015Accepted 1 JUL 2016Accepted article online 5 JUL 2016Published online 18 JUL 2016

©2016. American Geophysical Union.All Rights Reserved.

specifications. For this, general purpose and commercially available devices such as an FM demodulator RX1of Radiometrix, a GMSK demodulator baseband, CMX589A CML Microcircuits integrated into a DV-MEGAplate, and an Arduino UNO R3 microcontroller (for the storage of information received) have been used.Also, a Front-End unit has been set up on a computer with open source software in order to decode theAIS frame. Section 4 presents device results of a preliminary performance test from the proposed modularreceiver and an AIS commercially available receiver. This is to verify its correct operation. Finally, insection 5, the conclusions of this work are shown.

2. System Description

The AIS is an open system that allows nonencrypted and broadcasted information to be received by anydevice that meets the system specifications. This system operates in the VHF maritime band, and it is capableof handling well over 2250 reports per minute. Each AIS device (vessel transponder and coastal or satellitereceiver) monitors the vessel speed and determines the interval when the messages are being sent out. Asthe speed of the transponder increases, the frequency of messages increases and vice versa when the velo-city decreases. AIS static data are automatically transmitted every 2 to 10 s depending on the vessel’s speedwhile underway and every 6min while anchored. On the other hand, static- and voyage-related informationis manually introduced by the vessel’s crew and transmitted every 6min regardless of the vessel’s movementspeed or status [ITU-R Rec. M.1371-5, 2014]. The principles of operation of the AIS are based on the Self TimeDivision Multiple Access (SOTDMA) protocol. This protocol is responsible for the organization of the packetand the information generated by the transponders and its order in time. These data packets contain twotypes of data: static-/voyage-related information (International Maritime Organization number, call sign,name, destination, and Estimated Time of Arrival) and dynamic details (MaritimeMobile Service Identity num-ber (MMSI), rate of turn, position coordinates, course over ground, and heading), among others. This systemcan be described throughout the OSI model. The first three layers of this model are defined in the standard,leaving the other layers for the user to make its own implementation. It should be noted that the receptionsubsystem of transponders installed in vessels and receivers located in the coast comprise the same charac-teristics described in the OSI model.

2.1. Physical Layer

The AIS transmission uses non-return-to-zero (NRZ) digital data encoded with a rate of 9.6 kbit/s using aGMSK modulation baseband and band pass subsequently modulated by FM. The frequency bands usedare two (AIS-1: 161.975MHz and AIS-2: 162.025MHz) using a 25 kHz channel [ITU-R Rep. M.2123, 2007].

2.2. Link Layer

The link-level details support the management of bit patterns, as well as the error detection and correctionthat are carried out before sending packets over the network. Therefore, it is the layer that assures the relia-bility of bitstream. This layer is divided into three sublayers: the Medium Access Control (MAC), the Data LinkService (DLS) sublayer, and the Link Management Entity (LME).2.2.1. MAC SublayerThe MAC sublayer ensures a correct data transfer. For this reason, it is necessary to include references to com-mon time between AIS receiving stations within the network. Thus, all AIS stations should be synchronizedunder a common time reference called universal time coordinated (UTC) which is given by the GlobalPosition System (GPS) of the transmitting network of vessels.2.2.2. DLS SublayerThe DLS sublayer is responsible for providing a format in AIS frames. Each AIS frame consists of 32 bytes fol-lowing the High-level Data Link Control standard, and this is organized as follows. First, the Preamble (3 bytes:0x55 0x55 0x55) is transmitted, next the Start Flag (1 byte: 0x7E) and subsequently the data field (21 bytes),the cyclic redundancy check (CRC) (2 bytes) field to control errors in AIS frames, and finally, Stop Flag (1 byte:0x7E). In addition, a 24 bit temporary buffer supplementing the frame and used for tasks bit stuffing, distancedelay, repeater delay, and jitter effects is included.2.2.3. LME SublayerThe LME sublayer implements the scheme of TDMA. Thus, each AIS receiving station has an assigned timeinterval (slot) to share the channel with other stations and the transfer of data. This implies that the receiving

Radio Science 10.1002/2015RS005895


stations are synchronized. This timing is determined by the reference time UTC (obtained in the MAC),common to all AIS receiving stations integrated into a region of coverage.

Within the AIS standard, each slot has a duration of 26.67ms. If each frame has a time duration of AIS of 60 s,the total number of slots in a frame AIS is

N ¼ 60 � Δtslot ¼ 60 � 26:67≃2250 slots (1)

In Figure 1, a TDMA scheme for both AIS channels available is observed, verifying the duration for each slot of26.67ms. The AIS standard incorporates different media TDMA access schemes, but the main one is theSOTDMA scheme [Eriksen et al., 2006].2.2.4. Network SublayerIn this layer the sending and receiving of data packets is performed. The network layer performs the task ofsending frames, commonly through a Transmission Control Protocol (TCP)/Internet Protocol networkthrough of TCP or User Datagram Protocol (UDP) ports. The AIS allows users to implement the upper layerswith the only requirement of being compatible with the network level.

3. Modular Receiver Description

Once the AIS characteristics and components have been discussed in the previous section, the modulardesign of a receiver will be described (DV-MEGA web, 2016, http://www.dvmega.auria.nl/GMSK_shield.html).The modular design of the receiver presented in this section is of interest in academic environments thatallow to evaluate each device independently. The elements that characterize this receiver are as follows: amaritime VHF antenna, a FM receiver RX1 Radiometrix, a GMSK modem DV-MEGA, and a microcontrollerArduino UNO R3. In Figure 2, the connections between each module can be observed. Furthermore, the lastblock reflects a personal computer with a Front-End Program to process the data and send the data over thenetwork. A compact receiver design is achieved by choosing the sizes of all modules equal to the size of theArduino UNO. For this reason, both the DV-MEGA board and the breakout board Radiometrix RX1 meet theserequirements. The connections between the modules are made via USB and Mini DIN-6 connectors. A GPS isonly required in AIS transponders. In this case a GPS is not required due to the exclusive frame-receivingpurposes of its use.

3.1. Radiometrix Demodulator

The Radiometrix RX1-161.975-10 chip is a FM demodulator device that enables the connection to the VHFfrequency 161.975MHz and delivers the demodulated output (baseband) with a sensitivity of �119 dBm.

Figure 1. AIS TDMA scheme.



The input impedance of Radiometrix RX1 is of 50Ω connected to a VHF antenna with Voltage Standing WaveRatio less than 1.3. This device has nine-pin input and output of encapsulation, which are the RF In, RXD, GND,Vcc, RSSI, and Enable pin. The RX1 Radiometrix chip is designed with a dual conversion superheterodynetopology FI (Radiometrix web, 2016, http://www.radiometrix.com/files/additional/tx1rx1.pdf) (Figure 3).Signals from the device input pass through the RF stage where a preamp followed by a band-pass filteringis performed. Once filtering is performed in RF, the signal passes through a mixer through another inputconnected to a crystal oscillator frequency to 161.975MHz, allowing the RF signal conversion to performthe first IF stage (FI1). Then, this signal passes through a band-pass fitter and is amplified. Finally, the inter-mediate frequency FI2 is obtained through a second mixer thereby improving the selectivity.

Once the double-conversion FI is performed, the signal passes through a frequency discriminator whichconverts frequency variations into amplitude variations linearly so that the FM modulated signal performs

Figure 3. Radiometrix RX1.

Figure 2. AIS receiver prototype block diagram.



a conversion to AM modulated signal. Since the information is located in the envelope of the AM signal, anenvelope detector enables demodulation of the modulated signal. The last stage uses a low-pass cutofffrequency of 7 kHz and is used to improve the selectivity of the demodulator filter. Finally, a receiver bufferto store data received during a certain period of time in order to adapt transmission rates to different typesof protocols is added. The output data are obtained via the RXD pin at a speed which depends on the filing ofthe buffer.

3.2. Baseband GMSK Demodulation

The DV-MEGA board is a shield for Arduino, designed to perform GMSK modulation and demodulation tasksbaseband to speed 9.6 kbit/s. This board (Figure 4) consists of a CMX589A GMSK modem with external syncstages, also with filtered transmit and receive gain and PTT controller.3.2.1. Modem GMSK CMX589AThe CMX589A chip is encapsulated 24-pin designed by the company CML Microcircuits described as a GMSKbaseband modem. This chip supports full-duplex and half-duplex communication modes and allows trans-mission rates between 4 kbit/s and 200 kbit/s. BT (Bandwidth per symbol period) has a configurable pin factorto select the values 0.3 and 0.5. This chip transmits and receives bit serial data with corresponding sync pin tobe connected to the microcontroller for data transfer. Rx input levels can be set with external componentsaround an on-chip Rx Input Amplifier.3.2.2. Clock SystemCMX589A GMSK modem employs a synchronization circuit based on a crystal 9.8304MHz. This crystal fixedclock signal 9.8304MHz to set a bit rate of 9.6 kbit/s. For this, the value N= 1024 is set through ClkDivA andClkDivB lines so that the value of the bit rate is

RB ¼ f XTAL=N ¼ 9:6 kbit=s (2)

However, since the DV-MEGA board has a crystal oscillator of 4.9608MHz, the desoldering and soldering ofthis crystal oscillator was necessary. A more detailed explanation of the process and the new oscillator isfound in IDeTIC-AIS Github Repository (2016, https://www.github.com/IDeTIC-AIS/RX-AIS).3.2.3. Rx Level Adjust SystemTwo filters are placed on pin RxOut of CMX589A chip. The first of these filters is responsible for setting the bitrate output of the device, while the second low-pass filtering performs on the data and includes, via a poten-tiometer, the gain control to the modem output.

In a first step, the passive RC filter low-pass first-order consists of the resistance R=47 kΩ and capacitorC=470 pF determines the BT factor equal to 0.5, according to the selected bit rate, and eliminates

Figure 4. DV-MEGA GMSK shield.



high-frequency noise. The second filter isan active low-pass filter based on anoperational amplifier in inverting config-uration. The gain of this filter is given bythe ratio between the resistive valuesand thus depending on the output ofthe GMSK modem can adjust the signallevel. The solution adopted is to put afixed and a variable resistance so thatwe have a gain value between 7 dBand 10 dB.3.2.4. Push to TalkThe circuits Push to Talk (PTT) are inte-grated into systems for activating anddeactivating RF subsystems transmittingand receiving in half-duplex mode. Inthis design, the activation signal is gen-erated by the Arduino microcontroller.

3.3. Arduino Microcontroller

Arduino is an open programmable hard-ware platform. It is based on a microcon-

troller and a development environment, including specific programming language Processing based, with asyntax similar to C ++. Arduino UNO R3 model integrates an ATmega328P microcontroller 32 KB of Flashmemory, 2 KB of SRAM, and 1 KB of EEPROM. It has 14-pin digital input and output and 6 analog input pinsthat connect to other devices (shield) as the DV-MEGA board. It also has a serial port where programs areloaded and performs serial communications.

After creating a setup() function, which initializes and sets the initial values, the interrupt service routine ISR()is responsible to decode AIS frames. This interrupt is enabled via clock lines DV-MEGA board. This routinereads the bits via pin RXD and identifies the start and stop flags to the store the data in the frame, as shownin Figure 5. Once stored, data are converted to NMEA format and through the routine loop() data are sent tothe Front-End Unit via the serial port.

3.4. Front-End Unit

The Front-End Unit has been implemented through the use of free and open software available thatmeets the requirements of our hardware. OpenCPN (OpenCPN web, 2016, http://www.opencpn.org) isa free software with GNU license that displays maps of any area through the use of OpenSeaMap(OpenSeaMaps web, 2016, http://www.openseamap.org) and allows an easy integration with our AIS-receiving system by using serial port connection. OpenCPN decodes the data using NMEA [ISO/IEC13239, 2002], visualizing it on the map and allowing the decode of 22 different types of messages. It alsoallows the implementation of the network layer allowing to send the NMEA sentences by using a TCP orUDP port.

4. Results

As mentioned within the structure description of the paper, this section describes results of a preliminaryperformance test from the proposed modular receiver and an AIS commercially available receiver. This isto verify its correct operation.

First, each module has been revised independently to ensure proper operation. Second, a test set has beenperformed in the laboratory to check the system operation. Finally, a proper operation has been verified witha live stream of AIS signals.

The RX1 Radiometrix was verified through a comparison of a baseband signal generated by a functiongenerator with the demodulated signal RX1 device. The GMSK demodulator was verified by mounting twoDV-MEGA. The first generates a random GMSK signal and demodulates the second one. In Figure 6, the

Figure 5. Simplified setup(), loop(), and ISR().



different signals are shown. First, D0 clock signal is generated by the module. The D1 random sequence istransmitted from Arduino. D3 and D2 are the GMSK modulated and demodulated. It is noted that a matchexists between the two signals having a propagation delay of 0.15ms between D1 and D2.

Figure 7 shows the prototype receiverfinally implemented. This receiver hasbeen tested using an AIS test systemorganized by a modular receiver equip-ment and other similar transmitter,where both devices are separated bya distance of 1m. AIS frames sent in thistest have been compared with thereceived frames. The 2250 time slotswere used to verify that all had beencorrectly received.

Once the modular receiver has been ver-ified with real AIS frames, the developedprototype had been connected to a VHFmaritime mobile band antenna locatedon the rooftop of the ULPGC Scienceand Technology Park (28.08°N/15.46°W).In Figure 8, the assembly is shown inthe laboratory, by using the digital oscil-loscope to display the received frames.Once stored, frames and changing thetime base on the oscilloscope are shownin Figure 9 as the bitrate is 9.6 kbit/s.This signal passed through the Arduinomicrocontroller that performed the tasksof NRZ inverted decoding and data

Figure 6. Random binary sequence in the DV-MEGA modem.

Figure 7. A developed hardware receiver prototype.



extraction RxVector later to make the CRC checksum. The last step has been the conversion to the NMEA 0183format and its transmission to the computer’s serial port. Table 1 shows an example of this message formatand the most relevant parameters of the manual decoding (using ITU-R Rec. M.1371-5 [2014]) where themessage ID (1) indicates the Position Report.

Figure 10 shows the graphical representation of OpenCPN through a map of the Canary Islands where thenumber of vessels collected in real time is observed. Vessel information can be obtained by clicking on theicon of each. By clicking on the coordinates that have previously been manually decoded, it is found thatthere is a vessel in the same coordinates and time sharing the same MMSI number. This verifies that manualdecoding has been performed satisfactorily. Furthermore, these results were revised again through theMarineTraffic network and data sent by the BMT-IDeTIC AIS terrestrial node.

By using the OpenCPN software, AIS messages have been received from a coverage distance of up to 100 NMand a frequency of up to 300 messages per minute. The latter is below the maximum standard (2250). To usethis software simultaneously bymultiple users, OpenCPN has been configured as a server program using UDP

Figure 8. Assembly of an AIS real test system.

Figure 9. Demodulated AIS received signal.



port 3245 in a laboratory of 10 compu-ters. Each computer can collect serverinformation, allowing to perform mea-surements such as distance and routes.

Finally, a comparative table with otherreceivers is shown in Table 2. This tablereflects the prototype developed withthe Comar SLR300N receiver (ComarSystem web, 2016, http://www.comar-systems.com/slr_300n.html) located inthe same place and used as a nodecalled BMT-IDeTIC in the MarineTrafficNetwork [Tichavska et al., 2015], Daisy-

AIS receiver (Tindie web, 2016, https://www.tindie.com/products/astuder/daisy-ais-receiver/), and RTL-SDRreceiver (RTL-SDR web, 2016, http://www.rtl-sdr.com/rtl-sdr-tutorial-cheap-ais-ship-tracking/). It should benoted that all receivers get NMEA0183 messages at a rate of 38.4 kbit/s. Test results reflect that the receiversensitivity developed has better features than others but has nevertheless been implemented in a singlechannel. The prototype as the Daisy-AIS and the RTL-SDR has not implemented the network layer, thus allow-ing an external program performing it. Finally, the cost of the developed prototype has been 125 €where themajor cost has been covered by the DV-MEGA GMSK device. This price may be of course reduced if manyunits are purchased. The Front-End Unit has not been included since a unit dedicated to the AIS is not neces-sary. In a comparison with the other receivers it is noticeable that the prototype is cheaper than the SLR300Nbut more expensive than the Daisy-AIS and RTL-SDR.

5. Conclusions

Within this paper, we propose and describe the implementation of an AIS terrestrial modular receiver, to beused for academic purposes. Also, we compare its performance with AIS general purpose receiving devices.The proposed modular design proves its use for education and student learning in areas such as electronicengineering, telecommunications, and maritime studies. The performance of the prototype also proves tobe useful for the live reception of AIS frames at a not too expensive cost.

Table 1. NMEA 0183 Frame and the Most Relevant Parameters Using aManual Decoding

NMEA 0183 frame

!AIVDM,1,1,,A,13aN2dPOilNtC1L@@lf0g@`l0H=o,0*78

Parameter Value

Message ID 1MMSI 244810418Speed over ground (SOG) 11.6 knotsLongitude �14.789895°Latitude 28.421427°Course over ground (COG) 18.9°True heading 20°

Figure 10. Data decoded and displayed on a map of the Canary Islands in the software OpenCPN.



Moreover and within this work, the process and firmware code to be used with a single hardware receiver hasalso been described and included as an open source, the latter to simultaneously visualize and map decodedAIS vessel traffic details within a network of computers and thus facilitate AIS-based research and the disse-mination of regional vessel traffic-based knowledge.

At last, results of this work motivate and support the implementation of a more accessible AIS-receiving nodetoward the potential advance of applied and theoretical research within the areas of innovative system archi-tectures for the future internet of things, transport intelligent systems, Geographical Information Systems,hardware sensors, low-power computing, vessel and route efficiency, port optimization, among others.Indeed, AIS-data access, related research, and the advance of knowledge and science may allow unprece-dented opportunities to a better understanding and the improvement of the blue territory and shipping,among others, throughout descriptive and predictive analytics applied to a more efficient, transparent,and green operations at sea and in ports. Also, it may facilitate the design, development, and implementationof computing systems and actionable intelligence services that further support maritime policy and manage-ment [Shelmerdine, 2016; Tichavska and Tovar, 2015a, 2015b].

ReferencesEriksen, T., G. Hoye, B. Narheim, and G. Jenslokken (2006), Maritime traffic monitoring using a space-based AIS receiver, Acta Astronaut., 58,

537–549.ISO/IEC 13239 (2002), Information technology—Telecommunications and information exchange between systems—High-level data link

control (HDLC) procedures, ISO.ITU-R Rec. M.1371-5 (2014), Technical characteristics for a universal shipborne Automatic Identification System using time division multiple

access in the VHF maritime mobile band, ITU-R.ITU-R Rep. M.2123 (2007), Long range detection of Automatic Identification System (AIS) messages under various tropospheric propagation

conditions, ITU-RLanier, F. (2012), Practical sailor review feature loaded high-end VHFs, ICOM.Shelmerdine, R. L. (2016), Teasing out the detail: How our understanding of Marine AIS data can better inform industries, developments, and

planning, Mar. Policy, 54, 17–25.Safety of Life at Sea (1974), , edited by International Maritime Organization, International Convention on the Safety of the Life at Sea.Tichavska, M., and B. Tovar (2015a), Port-city exhaust emission model: An application to cruise and ferry operations in Las Palmas Port,

Transp. Res. A Policy Pract., 78, 347–360.Tichavska, M., and B. Tovar (2015b), Environmental cost and eco-efficiency from vessel emissions in Las Palmas Port, Transp. Res. E, 83,

126–140.Tichavska M., F. Cabrera, B. Tovar, and V. Araña (2015), Use of the Automatic Identification System in academic research, EUROCAST 2015,

LNCS 9520, pp. 33–40.

Table 2. Comparative of Receiver Developed and Commercial Receivers (Comrad SMR300N, Daisy-AIS, and RTL-SDR)a

Receiver Prototype SLR300N Daisy-AIS RTL-SDR

Sensitivity �119 dBm �112 dBm �105 dBm �116.5 dBmNo. of channels 1 2 2 1Output format NMEA0183 NMEA0183 NMEA0183 NMEA0183BaudRate 38.4 kbit/s 38.4 kbit/s 38.4 kbit/s 38.4 kbit/sEthernet port No Yes No NoCost 125 € 304 € 76 € 20 €

aRTL-SDR sensitivity is an estimated value (IDeTIC-AIS Github Repository, 2016, https://www.github.com/IDeTIC-AIS/RX-AIS).



AcknowledgmentsWe would like to extend our acknowl-edgements to MarineTraffic and itsteam for actively contributing to everyquestion raised and for supporting theverification of our results with theMarineTraffic BMT-IDeTIC AIS terrestrialnode and also to Juan DomingoSantana Urbín (ULPGC) for hisenormous contribution during thedevelopment phase of the AIS receiverprototype. At last, the authors wouldlike to thank the reviewers for thevaluable comments and suggestionsthat have enabled the qualityimprovement of this paper. The sourcecode of the firmware, PCB layout, andtwo technical notes may be accessed forfuture academic and research projectsat https://www.github.com/IDeTIC-AIS.

Anexo C

Vistas del software proAIS2

El software proAIS2 se utiliza para configurar y monitorizar la información recibi-

da y transmitida por los módulos AIS de la compañía SRT-Marine, entre los que se

encuentra el transceptor AIS clase B Cobalt. Para ello, el usuario tiene a su disposición

cinco vistas con las que interaccionar con el módulo, y son las siguientes:

Configuración del módulo (Configuration).

Monitorización de señal GNSS (GNSS Status).

Monitorización de embarcaciones (Other Vessels).

Verificación de estado del dispositivo (Diagnostics).

Terminal de comandos recibidos y transmitidos (Serial Data).

En la figura C.1 se presenta un ejemplo de la vista de configuración del módu-

lo Cobalt. Además de los campos para indicar los puertos a los que se conecta el

dispositivo (AIS Virtual COM) y el botón de escritura de la configuración (Write

configuration), cuenta con los siguientes campos principales:

Vessel Details, que permite al usuario introducir los datos estáticos del dispo-

sitivo, como son el nombre de la embarcación, el identificador MMSI, el código

de llamada digital selectiva y el tipo de embarcación sobre la que se embarca el

121

122

módulo. Además, es posible configurar de forma gráfica la posición de la antena

de GPS en la embarcación.

Configure Baud Rate, que permite configurar la velocidad de transmisión a la

salida de los canales NMEA1 y NMEA2 del módulo.

Figura C.1: Vista de configuración en proAIS2

Por otro lado, en la figura C.2 se presenta un ejemplo de la vista de monitorización

de la señal GNSS, que dado que el módulo Cobalt utiliza habitualmente una antena de

GPS para extraer su ubicación y procesar a partir de esta información los comandos

NMEA, se puede concebir como una monitorización de la red GPS sobre el dispositivo

Cobalt. En esta vista, el usuario puede reconocer de forma gráfica los niveles de señal

de la relación portadora-ruido de la red GPS, así como conocer otros parámetros de

importancia en la cobertura GNSS como son el tiempo UTC (Universal Time Coordi-

nated), la latitud y longitud donde se ubica el dispositivo, los parámetros COG (Course

Over Ground) y SOG (Speed Over Ground) y el número de satélites utilizados para

establecer la ubicación del módulo sobre la superficie terrestre.

Tal y como aparece en la figura C.3, la vista de monitorización de embarcaciones

permite al usuario observar todas aquellas embarcaciones que disponen de un equipo

AIS y emiten sus datos en la misma zona de cobertura donde se ubica el módulo

Cobalt. De esta manera, la interfaz de esta vista muestra el nombre comercial de


Figura C.2: Vista de monitorización de señal GNSS en proAIS2

la embarcación junto a otros datos de mayor relevancia, como son la clase de AIS del

equipo, la velocidad y el rumbo de la embarcación, la ubicación en función de la latitud

y longitud, y otros parámetros relacionados con la señal AIS y el alcance.

Figura C.3: Vista de monitorización de embarcaciones en proAIS2

En la figura C.4 se muestra un ejemplo de la vista de verificación del estado del

módulo Cobalt, que permite conocer si se han realizado las conexiones con las interfaces

del módulo y si transmite y recibe correctamente los mensajes AIS. Para ello, esta vista

presenta los siguientes campos:

124

Checklist, que indica si la conexión con las antenas de VHF y GPS y la alimen-

tación del módulo se ha realizado correctamente, así como si el dispositivo tiene

un MMSI válido y acceso a la red GPS, y ha recibido mensajes de otros equipos

AIS.

Internal Data, que muestra las versiones del software y del módulo, además de

monitorizar el COE y la tensión que se le suministra al dispositivo.

Status, que no es más que una visualización gráfica del estado de los diodos

LED integrados en el módulo, por lo que su funcionalidad es la misma que la que

indican estos componentes.

Statistics, que cuentan el número de mensajes AIS recibidos y transmitidos

por los dos canales habilitados en el módulo.

Mesages, que muestra los posibles errores que se han producido durante la trans-

misión de los mensajes AIS y marcan las alarmas que el usuario haya configurado

previamente en el dispositivo para ciertos tipos de mensajes.

Figura C.4: Vista de verificación de estado en proAIS2

Por último, en la figura C.5 se muestra un ejemplo de la terminal de mensajes

integrada en este software y que permite al usuario conocer la lista de mensajes AIS

que han sido recibidos y transmitidos con el módulo Cobalt. Esta terminal, además de


monitorizar todos los mensajes AIS que han sido procesados por el módulo, permite al

usuario ejecutar dos acciones fundamentales:

Log To File, que una vez que el usuario inicie esta acción, los mensajes mos-

trados en la terminal de mensajes se almacenan en un fichero de texto hasta

que nuevamente, el usuario indique que quiere parar el almacenamiento de los

mismos.

Enter Commands, que permite al usuario introducir comandos NMEA que, en

caso de ser correctos en su formato, son enviados por el módulo. Esta acción

resulta de gran utilidad cuando se desea comprobar que el dispositivo es capaz

de enviar ciertos tipos de mensajes al resto de equipos AIS.

Figura C.5: Vista de comandos recibidos y transmitidos en proAIS2

Anexo D

Lista de códigos implementados

D.1. Generación y envío de mensajes HDT propios

del prototipo

1 #!/usr/bin/env python

2

3 # bibliotecas y ficheros importados

4 import attitude_module

5 import Adafruit_BBIO.UART as UART

6 import serial

7 import time

8

9 # datos de entrada y formato de mensaje

10 yaw = getYaw ()

11 data = "$HEHDT ," + yaw + ",T"

12

13 # inicializacion de inicio y fin de mensaje

14 end = data.find(’*’)

15 start = 0

16 if data [0] in (’$’,’!’):

17 start = 1

127

128 D.1. Generación y envío de mensajes HDT propios del prototipo

18 if -1 != end:

19 data = data[start:end]

20 else:

21 data = data[start:]

22

23 # calculo de checksum

24 sum = 0

25 for k in data:

26 sum = sum ^ ord(k)

27 sumHex = " %x" % sum

28 if len(sumHex) == 1:

29 sumHex = ’0’ + sumHex

30 checksum = sumHex.upper ()

31 message = data + "*" + str(checksum)

32

33 # envio por UART

34 UART.setup("UART1")

35 ser = serial.Serial(’/dev/ttyO1’, baudrate = 9600)

36 ser.close ()

37 ser.open()

38

39 # comprobacion y envio recurrente

40 while ser.isOpen:

41 ser.write(message)

42 ser.close ()

Código D.1: Generación y envío de mensajes HDT propios del prototipo

D. Lista de códigos implementados 129

D.2. Almacenamiento y filtrado de mensajes AIS re-

cibidos del prototipo

1 #!/usr/bin/env python

2

3 # bibliotecas y ficheros importados

4 import telnetlib

5 import time

6 import sys

7 import ais_bmtidetic

8

9 # habilitacion de direccion y puerto para conexion Telnet

10 address = ’10.13.30.35 ’

11 port = ’2000’

12 # definicion de ficheros de texto para almacenamiento

13 outfileraw = ’bmtidetic_file_raw.txt’

14 outfileparsed = ’bmtidetic_file_parsed.txt’

15 # valor de filtrado para MMSI del prototipo

16 MMSI = "B1b4Vhh00"

17

18 # se habilita una conexion Telnet con la direccion y el

19 # puerto asignados previamente

20 tn = telnetlib.Telnet(address , port)

21 # se abren los ficheros de texto para almacenamiento

22 # definidos previamente

23 fraw = open(outfileraw , ’a’)

24 fparsed = open(outfileparsed , ’a’)

25

26 # en todo momento se realiza la lectura de los datos

27 # recibidos por Telnet , y si se corresponden con el

28 # MMSI del prototipo , se almacenan en los ficheros de

29 # texto definidos previamente

130D.2. Almacenamiento y filtrado de mensajes AIS recibidos del prototipo

30 while 1:

31 data = tn.read_until("\n")

32 long = len(data)

33 if data.find(MMSI) == 14:

34 for (raw , parsed) in ais_bmtidetic.parse_ais_messages(

data , True , False , 0):

35 timedata1 = time.strftime(" %H: %M: %S")

36 timedata2 = time.strftime(" %d/ %m/ %y")

37 print "Mensaje de IDETIC DRONE AIS recibido"

38 # se escribe la trama AIS con formato NMEA del

39 # prototipo sobre el fichero

40 # ’bmtidetic_file_raw.txt’

41 fraw.write(raw)

42 # se escribe la trama AIS decodificada a partir de

43 # la funcion importada ’parse_ais_messages ’, junto

44 # con la fecha y hora del sistema , sobre el

45 # fichero ’bmtidetic_file_parsed.txt’

46 fparsed.write(parsed + ", " + timedata1 + ", " +

timedata2 + ’\n’)

47 fraw.flush ()

48 fparsed.flush ()

Código D.2: Almacenamiento y filtrado de mensajes AIS recibidos del prototipo

escuela de ingeniería de telecomunicación y electrónica · 2020. 5. 17. · escuela de...

Documents