SIMULADOR PARA LA REPRODUCCIÓN DE ESCENARIOS Tarco.esi.uclm.es/public/pfc/alicia.garcia.pdf · D ESDE hace siglos la supremacía tecnológica ha sido un factor importante en la con-secución

SIMULADOR PARA LA REPRODUCCIÓN DE ESCENARIOS TÁCTICOS

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

INGENIERÍA

EN INFORMÁTICA

PROYECTO FIN DE CARRERA

Simulador para la Reproducción de Escenarios Tácticos

Alicia García Yébenes

Septiembre, 2013

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

Departamento de Tecnologías y Sistemas de Información

PROYECTO FIN DE CARRERA

Simulador para la Reproducción de Escenarios Tácticos

Autor: Alicia García YébenesDirector: Juan Pedro Palacios Martín-AlboTutor: Fernando Rincón Calle

Septiembre, 2013


Ciudad Real – Spain

E-mail: [email protected]

c© 2013 Alicia García Yébenes

Permission is granted to copy, distribute and/or modify this document under the terms of the GNUFree Documentation License, Version 1.3 or any later version published by the Free SoftwareFoundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copyof the license is included in the section entitled "GNU Free Documentation License".Se permite la copia, distribución y/o modificación de este documento bajo los términos de laLicencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada porla Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida enel apéndice titulado «GNU Free Documentation License».Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios sonreclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, ycuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos enmayúsculas o como nombres propios.

TRIBUNAL:

Presidente:

Secretario:

Vocal:

FECHA DE DEFENSA:

CALIFICACIÓN:

PRESIDENTE SECRETARIO VOCAL

Fdo.: Fdo.: Fdo.:

A mis padres y a mi hermana.

A Daniel.

Resumen

En la actualidad, disponer de una buena estrategia militar para realizar misiones, supone unfactor clave en el éxito o fracaso de ellas. El intercambio de mensajería táctica es, por tanto,un medio que utiliza la Armada Española en sus cometidos para compartir información entresus unidades en escenarios y situaciones concretas.

El desarrollo del presente proyecto se centra en la implementación de una herramienta ca-paz de reproducir escenarios tácticos, que se componen de mensajes con información táctica,y analizar dichos escenarios a posteriori en laboratorio sin necesidad de ningún elemento decomunicación. Esta información es proporcionada por el Procesador de redes tácticas LIN-PRO, desarrollado por la empresa TECNOBIT, que tiene capacidades de intercambio deinformación táctica en redes Link-11, Link-16 y Link-22.

XIII

Abstract

Nowadays, provide by a good military strategy for missions, involve a key factor in thesuccess or failure of those missions.The exchange of messages is, therefore, a field that usesSpanish Army in their duties to share information among their units in different situationsand scenarios.

The development of this project focuses on the implementation of a tool capable of pla-ying tactical scenarios, which consist of messages with tactical information and subsequentlyanalyzing these lab scenarios without any communication element. This information is pro-vided by the processor of tactical networks LINPRO, developed by the company TECNO-BIT, that has capabilities for information exchange networks tactical Link-11, Link-16 andLink-22.

XV

Agradecimientos

Quiero dar las gracias en primer lugar a mis padres, Manuel y Paqui, por todo el apoyo,el ánimo y la confianza que me han dado siempre. Gracias por animarme en los momentosmás difíciles y por estar a mi lado para todo, sois mi ejemplo a seguir.

Gracias a mi hermana Cristina, por su cariño y afecto, y por sacarme siempre una sonrisaesté donde esté.

Gracias a Daniel, por su paciencia y compañía, y por hacerme tan feliz.

Gracias a mi abuela Micaela, a mis tíos JJ, Mariano y Ana, y a mis primos Laura y Mariopor darme tantos ánimos siempre. También agradecer a mi otra familia, Juande y Gloria,estar tan pendientes de mi.

Gracias a todos los amigos que he hecho durante estos años, tanto en la residencia comoen la carrera, y que todavía seguimos estado juntos como el primer año. Gracias por darmetan buenos momentos y compartir juntos tantos días de estudio y, sobre todo, de diversión,que han sido muchos y siempre quedarán en mi recuerdo.

Gracias también a mis amigos y amigas de Valdepeñas, en especial a las del grupillointerno, por vuestra preocupación cada día y por vuestro apoyo constante.

Quiero agradecer a TECNOBIT haberme dado la oportunidad de realizar este proyecto, ya todos los compañeros por haberme ayudado y facilitado el trabajo.

Y por último, dar las gracias a Fernando Rincón Calle y a Juan Pedro Martín-Albo porsu confianza, tiempo y dedicación. Gracias por vuestra ayuda y supervisión del proyectodurante estos meses.


XVII

Índice general

Resumen XIII

Abstract XV

Índice general XIX

Índice de figuras XXIII

Índice de cuadros XXV

1. Introducción 1

1.1. Simulador para la reproducción de escenarios tácticos . . . . . . . . . . . . 1

1.2. Entorno de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Justificación del tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Estado del Arte 5

2.1. Sistema LINPRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Interfaces tácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1. Link-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2. Link-16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Ficheros DX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1. Especificación EBNF fichero texto Link-11 . . . . . . . . . . . . . 10

2.3.2. Especificación EBNF fichero binario Link-11 . . . . . . . . . . . . 11

2.3.3. Especificación EBNF fichero texto Link-16 . . . . . . . . . . . . . 11

2.3.4. Especificación EBNF fichero binario Link-16 . . . . . . . . . . . . 11

2.4. Interfaz SIMPLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. Objetivos 15

3.1. Extracción de la información . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2. Reconstrucción del escenario táctico . . . . . . . . . . . . . . . . . . . . . 16

XIX

3.2.1. Recepción de ficheros . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2. Depuración de información . . . . . . . . . . . . . . . . . . . . . . 16

3.2.3. Fichero de salida . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3. Reproducción y análisis del escenario . . . . . . . . . . . . . . . . . . . . 17

3.4. Objetivos secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4. Método de trabajo 19

4.1. Proceso Unificado de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1. Fase de Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.2. Fase de Elaboración . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.3. Fase de Construcción . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.4. Fase de Transición . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1. Lenguaje de programación . . . . . . . . . . . . . . . . . . . . . . 21

4.2.2. Software de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.3. Herramienta de control de versiones . . . . . . . . . . . . . . . . . 23

4.2.4. Herramienta de gestión de requisitos . . . . . . . . . . . . . . . . . 23

4.2.5. Herramienta de modelado . . . . . . . . . . . . . . . . . . . . . . 24

4.2.6. Herramientas de documentación . . . . . . . . . . . . . . . . . . . 24

5. Arquitectura 27

5.1. Fase de Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1. Iteración Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2. Fase de Elaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.1. Iteración 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.2. Iteración 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3. Fase de Construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3.1. Iteración 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3.2. Iteración 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3.3. Iteración 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.4. Fase de Transición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4.1. Iteración 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.5. Hitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6. Resultados 53

6.1. Recursos y costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.2. Calendario final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.3. Ejemplo completo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3.1. Abrir fichero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3.2. Contenido fichero original . . . . . . . . . . . . . . . . . . . . . . 57

6.3.3. Procesamiento de fichero . . . . . . . . . . . . . . . . . . . . . . . 58

6.3.4. Envío de fichero . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7. Conclusiones 63

7.1. Objetivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.2. Propuestas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Bibliografía 65

A. Documento IBM Doors 69

A.1. Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.1.1. Identificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.1.2. Descripción General del Sistema . . . . . . . . . . . . . . . . . . . 69

A.1.3. Descripción General del documento . . . . . . . . . . . . . . . . . 70

A.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.2.1. Requisitos de capacidad . . . . . . . . . . . . . . . . . . . . . . . 70

A.2.2. Requisitos de interfaces externas . . . . . . . . . . . . . . . . . . 73

B. Manual de Usuario 75

B.1. Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

B.1.1. Pantalla de Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

B.1.2. Abrir Fichero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B.1.3. Abrir Fichero Procesado . . . . . . . . . . . . . . . . . . . . . . . 76

B.1.4. Guardar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B.1.5. Procesar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.1.6. Enviar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.1.7. Parar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.1.8. Reiniciar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Índice de figuras

1.1. Simulador táctico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1. Equipo Sistema LINPRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Entorno Sistema LINPRO . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3. Equipos de comunicación con red Link-11 . . . . . . . . . . . . . . . . . . 7

2.4. Equipos de comunicación con red Link-16 . . . . . . . . . . . . . . . . . . 9

2.5. Estructura mensaje SIMPLE/TCP . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Entorno de simulación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1. Proceso Unificado de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . 20

4.2. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3. Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4. IBM Doors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.5. Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.6. Trac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1. Calendario de trabajo inicial . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3. Diagrama de casos de uso del sistema . . . . . . . . . . . . . . . . . . . . 31

5.4. DdS 1 - Seleccionar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.5. DdS 2 - Procesar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.6. DdS 3 - Enviar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.7. DdS 4 - Guardar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.8. Diagramas de secuencia 5 y 6 . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.9. Proceso Entrada de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.10. Boceto IU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.11. Mensaje SIMPLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.12. Organización información . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.13. Estructura Network Header . . . . . . . . . . . . . . . . . . . . . . . . . . 44

XXIII

5.14. Estructura Packet Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.15. Estructura Packet Data Link-11 . . . . . . . . . . . . . . . . . . . . . . . . 46

5.16. Message Data Link-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.17. Estructura Packet Data Link-16 . . . . . . . . . . . . . . . . . . . . . . . . 47

5.18. Message Data Link-16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.19. Struct Link-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.20. Struct Link-16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.21. TCP Cliente - Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.22. Boceto IU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1. Calendario de trabajo final . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2. Ejemplo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3. Ejemplo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.4. Ejemplo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.5. Ejemplo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.6. Ejemplo 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.7. Ejemplo 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.8. Ejemplo 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

B.1. Boceto IU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

B.2. Boceto IU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B.3. Boceto IU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B.4. Boceto IU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.5. Boceto IU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Índice de cuadros

5.1. Detalle CdU 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2. Detalle CdU 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3. Detalle CdU 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.4. Detalle CdU 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.5. Detalle CdU 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.6. Detalle CdU 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.7. Ejemplo fichero original . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.8. Ejemplo fichero procesado . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1. Recursos y costes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 53

XXV

Capítulo 1

Introducción

D ESDE hace siglos la supremacía tecnológica ha sido un factor importante en la con-secución de los éxitos militares y en el dominio de los escenarios de conflicto, pero

no sólo en situaciones de crisis o guerra abierta, sino también en escenarios de conflicto singuerra declarada y situaciones prebélicas.

En las últimas décadas, los avances tecnológicos han permitido el desarrollo de sistemasy aplicaciones informáticas con el fin de ser utilizados en los sectores de Defensa y Segu-ridad de las Fuerzas Armadas. Se puede referir a esta tecnología como tecnología militar,es decir, un conjunto de teorías y de técnicas que permiten el aprovechamiento práctico del

conocimiento científico aplicados al ámbito militar.

Esta evolución ha sido posible gracias al esfuerzo de muchas empresas que invierten ex-clusivamente en la investigación y desarrollo (I+D) de nuevos proyectos con el fin de atendery satisfacer las necesidades de las Fuerzas Armadas. Actualmente las Fuerzas Armadas evo-lucionan en sus cometidos realizando no sólo labores puramente bélicas, sino también deayuda humanitaria, emergencias ante catástrofes, exploración de territorios, etc.

La relación entre tecnología y defensa ha estado desde siempre fusionada. Prueba de elloes la multitud de productos existentes en el mercado que han participado en los programasnacionales e internacionales de las Fuerzas Armadas, contribuyendo a su modernizacióny desarrollo. El acceso a la información, su intercambio y la capacidad de procesarla, es latecnología que está en auge y es la que hace posible enfrentarse a los nuevos retos. [Mon]

1.1 Simulador para la reproducción de escenarios tácticosLa realización del presente Proyecto Fin de Carrera tiene como propósito desarrollar un

entorno de simulación de escenarios tácticos basados en ficheros Data Extraction. Un escena-rio táctico es un conjunto de mensajes tácticos. Estos mensajes contienen información tácticautilizada para compartir datos y para mejorar las misiones de las Fuerzas Armadas.

Los ficheros Data Extraction contienen la mensajería intercambiada por un procesador dedatos tácticos, en un período de tiempo, sobre escenarios tácticos reales. Un procesador dedatos tácticos (Data Link Processor) es un sistema de distribución de mensajes tácticos, yen este proyecto se ha utilizado el LINK PROcessor de TECNOBIT [Tec]. LINPRO tiene

1

2 1. INTRODUCCIÓN

capacidad de intercambio de información táctica en redes Link-11, Lin-16 y Link-22, trans-mitiendo la información local obtenida de los sensores de la plataforma en la que se integra(radares, etc) a las unidades de la fuerza y procesando la información táctica recibida delresto de unidades para transmitirá al Sistema de Mando y Control con el que se integra.

La herramienta permitirá la lectura y procesamiento de los ficheros Data Extraction paracompilar un escenario táctico en concreto, y que a posteriori podrá ser reproducido en elSistema LINPRO a través de la interfaz SIMPLE, donde se mostrará la simulación de losmensajes tácticos.

En el siguiente capítulo, se profundiza con detalle sobre el marco de trabajo que envuelveesta herramienta software.

Figura 1.1: Simulador táctico

1.2 Entorno de trabajoLa elaboración del proyecto se ha realizado en TECNOBIT en su sede de Valdepeñas. Esta

empresa es líder en ingeniería electrónica desde hace más de 30 años, y ofrece la tecnologíamás avanzada en sectores de Defensa, Seguridad, Espacio, Transporte y Telecomunicacio-nes.

Actualmente TECNOBIT diseña, desarrolla, suministra y mantiene productos y sistemaspara las Fuerzas Armadas Españolas y para otros ejércitos desde hace varias décadas. Lassoluciones se encuentran operativas en una amplia variedad de plataformas y sistemas dearmas y protección de fuerzas, tanto nacionales como extranjeras.

La capacidad técnica y productiva le permite proporcionar soluciones a medida de lasdemandas y necesidades de cada cliente, integrando sistemas a partir de productos de diseñopropio o ajeno, ajustando en cada caso la selección de los diferentes componentes a los

1. INTRODUCCIÓN 3

requisitos específicos del usuario.

El desarrollo de este proyecto se ha realizado íntegramente dentro de la empresa, utili-zando los equipos de laboratorio, medios y herramientas necesarios del departamento deIngeniería del Software durante los siete meses que se ha llevado a cabo.

1.3 Justificación del temaEl motivo principal de la realización de este proyecto fin de carrera, surge de la necesidad

de TECNOBIT de disponer de una herramienta que sea capaz de satisfacer unas necesidadesparticulares, en este caso, una herramienta que pueda simular y reproducir escenarios tácticosa partir de un conjunto de mensajes dados previamente.

En la actualidad, TECNOBIT no dispone de ningún sistema de simulación de escenariostácticos que pueda reproducir las trazas reales de emisión y transmisión de intercambio deinformación que se realizan entre las unidades del ejército. Cuando se produce algún erroren el intercambio de estos mensajes, se desconoce cuál ha sido la causa de fallo y qué unidadlo ha provocado. Por lo que para comprobar la incidencia ocurrida, es necesario desplazarsehasta una de esas unidades en concreto y realizar la comprobación personalmente.

Esta idea fue propuesta para desarrollar en TECNOBIT debido a la importancia de poderutilizar una herramienta que reprodujera fielmente las simulaciones de estos mensajes encualquier equipo de la propia empresa. Por lo tanto, de esta manera, no existiría la obliga-ción de desplazarse hasta la unidad del ejército que ha tenido el problema para solventarlo,suponiendo esto un gran ahorro económico, y menor pérdida de tiempo.

Es importante destacar que la realización de este proyecto fin de carrera tiene como obje-tivo la creación de una herramienta software que servirá, a partir de ahora, como un sistemade apoyo a los proyectos que se están desarrollando en TECNOBIT S.L. con el SistemaLINPRO y las redes tácticas Link.

1.4 Estructura del documentoEste documento ha sido realizado de acuerdo a la normativa de realización de proyectos fin

de carrera de la Escuela Superior de Informática de la Universidad de Castilla-La Mancha, yestá compuesto de siete capítulos que se describen de forma resumida a continuación:

Capítulo 1: Introducción. En este capítulo se realiza una breve introducción sobre eltema y el ámbito del proyecto fin de carrera elegido, el entorno de trabajo, el motivopor el cual se ha realizado y la estructura de este documento.

Capítulo 2: Estado del arte. Este capítulo recoge los temas que han sido previamenteestudiados para la elaboración del proyecto. Además se explica con detalle los recursosutilizados en el proyecto como son el Sistema LINPRO, los ficheros DX y la interfazSIMPLE.

4 1. INTRODUCCIÓN

Capítulo 3: Objetivos. En este capítulo se describe el objetivo principal del proyectoy se desglosan cada uno de los objetivos específicos que se pretenden alcanzar.

Capítulo 4: Metodología de trabajo. En este capítulo se explica la metodología dedesarrollo aplicada, y las iteraciones en las que se divide el proyecto. También seespecifican las herramientas software que componen el entorno tecnológico donde seha desarrollado.

Capítulo 5: Arquitectura. En este capítulo se explica en profundidad cómo se haaplicado cada una de las fases de la metodología escogida en este proyecto.

Capítulo 6: Resultados. En este capítulo se muestran los resultados obtenidos asícomo los inconvenientes que han ido surgiendo en la evolución del desarrollo del pro-yecto. También se muestra la evolución y estimación del coste del proyecto.

Capítulo 7: Propuestas y conclusiones. En este capítulo se analizan propuestas quepueden ser aplicables un futuro con el propósito de mejorar la herramienta. Por últimose concluye con una valoración general y una valoración personal de todo el trabajorealizado.

Anexo I: Este anexo muestra el documento generado por la herramienta IBM Doorsdonde se especifican todos los requisitos del proyecto.

Anexo II: Este anexo consta de un manual de usuario de la aplicación desarrollada.

Capítulo 2

Estado del Arte

A Lo largo de este capítulo se exponen los conocimientos que han sido estudiados parala elaboración del proyecto. Se da una visión general sobre el Sistema LINPRO, las

interfaces tácticas, los ficheros que contienen mensajes tácticos, y la interfaz SIMPLE con laque se han realizado las pruebas.

2.1 Sistema LINPROEl Sistema LINPRO es un Procesador de Datos Tácticos que tiene capacidad de inter-

cambio de información táctica en redes Link-11, Link-16 y Link-22, y está formado por unequipo procesador LINPRO y por la consola de operador LINPRO, como se puede ver en laFigura 2.1.

Figura 2.1: Equipo Sistema LINPRO

Ha sido desarrollado por TECNOBIT, y se encuentra operativo en la Armada Españolaexitosamente desde 2005, fecha en la que fue validado para diversas maniobras internacio-nales instalándose a bordo de los buques. TECNOBIT también ha conseguido implantar elSistema LINPRO en otros ejércitos a nivel internacional, como es la Armada Holandesa,debido a su alta eficiencia en el intercambio de mensajes y mejoras en las redes tácticas.

5

6 2. ESTADO DEL ARTE

El Sistema LINPRO tiene capacidades de Data Extraction generando un fichero de datospara cada interfaz táctica con la información intercambiada por el Sistema LINPRO tanto entransmisión como en recepción.

Además el Sistema LINPRO también es capaz de registrar la información intercambiadacon el Sistema de Combate. Se obtiene la información local que será transmitida a las redesLink, del Sistema de Mando y Control de la plataforma en la que se integra. De la mismaforma, toda la información recibida de las redes Link es transmitida al Sistema de Mando yControl de la plataforma desacoplando a éste de la gestión y de los procesos particulares delintercambio táctico en cada interfaz Link.

Para cada una de estas interfaces Link, el Sistema LINPRO se apoya en diferentes elemen-tos de comunicación como elementos crypto, módems, radios, etc, según se muestra en laFigura 2.2.

Figura 2.2: Entorno Sistema LINPRO

2.2 Interfaces tácticasUn enlace de datos tácticos (Tactical Data Link) utiliza un estándar de conexión de datos

con el fin de proporcionar una comunicación a través de ondas de radio o cables que sonutilizados por las Fuerzas Armadas y las naciones de la OTAN. Todos los sistemas militaresutilizan TDL estándar para transmitir y recibir datos tácticos. En la OTAN, las normas deenlace de datos tácticos son desarrolladas de acuerdo con el STANAG apropiado. [Nav]

2. ESTADO DEL ARTE 7

STANAG es la abreviatura de la OTAN para el “Standardization Agreement” (acuerdode normalización), que establece los procesos, procedimientos, términos y condiciones paralos procedimientos militares o técnicas comunes o equipos entre los países miembros de laalianza.

Cada estado de la OTAN ratifica un STANAG y lo aplica, dentro de su propio ejército.Su principal objetivo es proporcionar los procedimientos y la logística de funcionamiento yadministrativos comunes, para utilizar y apoyar a otros miembros de la Armada. STANAGtambién constituyen la base para la interoperabilidad técnica entre una amplia variedad decomunicación y de sistemas de información para operaciones de la OTAN y los aliados.

El Sistema LINPRO intercambia información con las interfaces tácticas con las que secomunica. Estas interfaces son las redes Link-11, Link-16 y Link-22, y utilizan los STANAG5511 [S5511], STANAG 5516 [S5516] y STANAG 5522 respectivamente.

2.2.1 Link-11Los enlaces de transmisión tácticos por lo general se limitan a un área determinada de

operación y son usados para el mando y el control de fuerzas específicas. Link-11 es laversión de Link-A de Información de Datos Táctico (TADIL A). El sistema Link-11 se utilizapara proporcionar alta velocidad a los equipos en el intercambio de información digital entrebuques, aeronaves e instalaciones de tierra, como se puede ver en la Figura 2.3.

Figura 2.3: Equipos de comunicación con red Link-11


Las comunicaciones de datos Link-11 pueden operar con radios de alta frecuencia (HF)o ultra alta frecuencia (UHF). En la banda de radio de HF, Link-11 proporciona coberturaomnidireccional de hasta 300 millas náuticas del lugar de transmisión. En la banda de UHF,el sistema Link-11 es capaz de cubrir aproximadamente 25 millas náuticas entre buques, y150 millas náuticas para los enlaces barco-aire.

Un sistema de comunicaciones típico Link-11 consta de los siguientes componentes: unordenador Sistema de Mando de Control (CDS), Procesador de redes tácticas (LINPRO),dispositivo criptográfico, terminal de datos Link-11 (o Modem Link-11), radios HF o UHFy acoplador de antena.

Link-11 emplea técnicas de comunicación en red para el intercambio de información di-gital entre diferentes tipos de plataformas aéreas, de tierra y marítimas. Como se ha visto, elhardware necesario para apoyar las operaciones de Link-11 consiste en un dispositivo crip-tográfico y un DTSmodem que hay que tener en el laboratorio y que resultan muy costosospara la empresa. Por ello se desarrollan otras herramientas de apoyo que puedan realizar elmismo trabajo pero de forma más económica.

Para los DTS, controlar la red correctamente requiere el cumplimiento estricto con elformato de mensaje correcto y su protocolo de red. Cada mensaje Link-11 tiene un formatoy función específica.

Formato del mensaje: Cada mensaje de datos se compone de 60 bits dispuestos enun orden establecido para la interpretación por parte de un equipo automático. Los60 bits están colocados en dos tramas de 30 bits cada uno. Seis bits por trama sonasignados a la detección y corrección de errores. Los otros restantes 24 bits por trama,están disponibles para la codificación de la información del mensaje. Por lo tanto, losmensajes definidos permiten 48 bits de información táctica.

Período del mensaje: Cada mensaje contiene dos marcos de 30. La primera trama setransmite primero. Las posiciones de bits en cada trama están numeradas de 0 a 29,con el número 0 se llama el primer bit y el bit 29 el último bit de una trama. Cada bittiene dos posibles significados correspondientes a un cero binario y un uno binario.

Los mensajes con el formato estándar de Link-11, se encuentran documentados en el STA-NAG 5511. Hay ocho grupos o subconjuntos de mensaje y son los siguientes:

Información del sistema.

Vigilancia Aérea.

Vigilancia de la superficie.

Control aéreo.

Control de armas.

Gestión de la Información.


Guerra Electrónica.

Vigilancia del subsuelo.

2.2.2 Link-16El sistema de distribución de información táctica conjunta (Link-16) es un enlace de datos

tácticos que se introdujo en la flota en 1994. “Tactical Digital Link” (TADIL) es un términoutilizado por los servicios de las Fuerzas Armadas de Estados Unidos. La designación TA-DIL de Link-16 se denomina TADIL J, y el sistema de distribución de información tácticaconjunta (JTIDS) se refiere al componente de comunicaciones de Link-16.

Figura 2.4: Equipos de comunicación con red Link-16

Link-16 permite el intercambio de información táctica en tiempo real entre unidades dela Armada, los servicios conjuntos, y los miembros de la OTAN, como se puede apreciar enla Figura 2.4. Aunque algunas de las funciones son idénticas a las funciones de Link-11 yLink-4A, Link-16 también proporciona elementos de intercambio de datos “DataExchange”que los otros sistemas de enlace carecen, como son los que se enumeran a continuación:

Resistencia Jam

La flexibilidad de las operaciones de comunicación

Funciones de seguridad de transmisión y datos separados

Aumento del número de participantes

Aumento de la capacidad de datos


Características de navegación en red

Capacidades de voz segura

Link-16 transmite datos en serie utilizando mensajes compuestos por palabras de 70 bits.Durante el intervalo de tiempo de transmisión, se pueden transmitir 3, 6 o 12 palabras. Elnúmero de palabras de transmisión depende del estándar y del empaquetamiento de datosque se utiliza en la estructura. El número de palabras que compone un mensaje Link-16 esvariable, pero normalmente es 1, 2, o 3 palabras. Hay tres tipos de mensajes: formato fijo,formato variable o de texto libre.

Los mensajes de formato fijo se llaman mensajes de la serie J y se utilizan para el intercam-bio de información táctica. Los mensajes de texto libre se utilizan para las comunicacionesde voz, mientras que los mensajes en formato variable, se definen la longitud y el contenidodel usuario. Los mensajes de tipo variables no son usados por la Armada. El aumento del ta-maño de los mensajes Link-16 permite la presentación de hasta tres veces más informacióntáctica de la que estaba disponible en el sistema Link-11.

2.3 Ficheros DXLos ficheros DX contienen el conjunto de mensajes Link-11(M) y Link-16(J) que repre-

sentan el escenario táctico almacenado por el Sistema LINPRO en un determinado períodode tiempo.

Estos ficheros son los que recibirá la herramienta y serán proporcionados por el meca-nismo de extracción de datos (Data Extraction) del sistema LINPRO, que extraerá la infor-mación de las interfaces Link, y estarán compuestos por todos los mensajes, tanto recibidoscomo transmitidos de cada una de ellas.

El formato de los ficheros será independiente en cada interfaz táctica, y podrá estar entexto (.txt) si el mensaje está escrito en hexadecimal o en binario (.bin) si por el contrarioestá escrito en binario. Estos formatos se describen en los siguientes apartados:

2.3.1 Especificación EBNF fichero texto Link-11

f i c h e r o := {}b l oq ue de d a t o s := < t i t u l o > <cuerpo >i n f o := long : < l o n g i t u d > t ime : < t iempo > c ue rp o := { p a l a b r a de mensa je }p a l a b r a de mensa je := <word hexadec ima l > <word b i n a r i o >

<nombre_mensaje > <word hexadec ima l > <word b i n a r i o >word h e x a d e c i m a l := 0x 1{< d i g i t o hexadec ima l >}8word b i n a r i o := 1{0 | 1}32nombre mensa je := M_( (M <numero >[X | D_STOP ] ) | NULO)i n d i c a d o r t r a n s m i s i o n := Tx | Rx


t i t u l o := cadena c a r a c t e r e sl o n g i t u d := numerot i empo := hh :mm: s s

2.3.2 Especificación EBNF fichero binario Link-11Contiene, para cada bloque de datos transmitido o recibido, de forma secuencial y en

formato binario, la siguiente información:

número de mensajes M del bloque capturado

instante de transmisión o de recepción del bloque de datos capturado, como el númerode milisegundos transcurridos desde las 00:00 horas del día de la grabación

un 0 si el bloque se ha recibido y un 1 si se ha transmitido el bloque de datos en formatobinario

2.3.3 Especificación EBNF fichero texto Link-16

f i c h e r o := {}b l oq ue de d a t o s := < t i t u l o > <cuerpo >i n f o := long : < l o n g i t u d > t ime : < t iempo > SourceTN : < t n _ s o u r c e >c ue rp o := { p a l a b r a de mensa je }p a l a b r a de mensa je := <word hexadec ima l > <word b i n a r i o >

< nombre_pa labra >word h e x a d e c i m a l := 0x 1{< d i g i t o hexadec ima l >}18word b i n a r i o := 1{0 | 1}70nombre p a l a b r a := J < d i g i t o > . ( I | E | C) [ numero ]i n d i c a d o r de t r a n s m i s i o n := Tx | Rxt i t u l o := cadena c a r a c t e r e sl o n g i t u d := numerot n _ s o u r c e := numerot i empo := hh :mm: s s

2.3.4 Especificación EBNF fichero binario Link-16Contiene, para cada bloque de datos transmitido o recibido, de forma secuencial y en

formato binario, la siguiente información:

número de mensajes J del bloque capturado

instante de transmisión o de recepción del bloque de datos capturado, como el númerode milisegundos transcurridos desde las 00:00 horas del día de la grabación

un 0 si el bloque se ha recibido y un 1 si se ha transmitido

el bloque de datos en formato binario


2.4 Interfaz SIMPLELa interfaz SIMPLE está definida por el STANAG 5602 [S5602]. El objetivo de este acuer-

do es proporcionar especificaciones para un estándar común con el propósito de interconectarlos equipos de tierra para las pruebas de interoperabilidad.

La filosofía del estándar SIMPLE consiste en especificar la interconexión de las platafor-mas para permitir que se puedan realizar múltiples pruebas de interoperabilidad TDL. Estainterconexión se lleva a cabo mediante la vinculación de las plataformas a una red de áreaamplia (WAN), que puede ser implementada por diferentes medios físicos.

Los datos, que son transferidos como paquetes a través de la WAN, se componen de tresgrupos genéricos: mensajes TDL, datos del entorno del escenario, y pruebas de datos decontrol y gestión.

El estándar SIMPLE consta de varios elementos, y estos son: el portador de comunicacio-nes (por ejemplo, líneas telefónicas, redes WAN digitales), los métodos de encriptación (quese utilizan para proteger la información segura transmitida entre sitios), los protocolos/for-matos de datos para el proceso de transferencia de datos y otros aspectos adicionales, talescomo el tiempo de coordinación.

Los protocolos que utiliza SIMPLE son:

Protocolos WAN / LAN, incluyendo:

•User Datagram Protocol (UDP) de difusión

•UDP multicast

•Protocolo de Control de Transmisión (TCP)

Asíncrono

Sincrónico

La aplicación de los protocolos es opcional, sin embargo, con el fin de tener implemen-taciones separadas para comunicarse con éxito, ambas implementaciones deben poner enpráctica el mismo protocolo.

Los sistemas deben poner en práctica el protocolo WAN, pero pueden optar por aplicartantos protocolos adicionales como se deseen. Es posible para un sistema implementar variosprotocolos y ejecutarlos simultáneamente en canales de comunicación separados.

El Protocolo de Control de Transmisión (TCP) es el protocolo base que debe ser soportadopor todos los sitemas del STANAG 5602 y es el que se ha utilizado en este desarrollo.


En la Figura 2.5 se muestra la estructura de mensajes de datos que utiliza SIMPLE con elprotocolo de comunicación TCP. Es la que se ha usado en la realización de este proyecto yen el Capítulo 5 se explicará cómo están formados cada uno de los paquetes.

Figura 2.5: Estructura mensaje SIMPLE/TCP

Capítulo 3

Objetivos

E N este capítulo se describe el objetivo principal del proyecto y se desglosan cada unode los objetivos específicos que se pretenden alcanzar.

La realización del Presente Proyecto Fin de Carrera tiene como objetivo principal podersimular en un entorno de laboratorio, escenarios tácticos reales que se han llevado a cabo enmaniobras u operaciones donde ha participado el Sistema LINPRO, y que han sido grabadosmediante la herramienta de extracción de datos de LINPRO con la mayor fidelidad posible.Un ejemplo de la herramienta a desarrollar y del entorno donde se va a integrar se puede veren la Figura 3.1.

Los escenarios grabados en buques, donde está operativo el Sistema LINPRO, no sonreproducibles en laboratorio debido a que no es posible disponer de los elementos de comu-nicación de las interfaces Link, por lo que el simulador podrá permitir la depuración en unmomento determinado del Sistema LINPRO sin la limitación de los elementos de comuni-cación de las interfaces Link.

Figura 3.1: Entorno de simulación.

15

16 3. OBJETIVOS

El simulador para la reproducción de escenarios tácticos permitirá la extracción y filtradode información con el fin de obtener únicamente los mensajes tácticos de las interfaces Linkque representan el escenario táctico a reproducir por la herramienta. Esto se llevará a caboeliminando toda la información de control añadida al fichero y obteniendo, de esta manera,los mensajes tácticos en bruto.

Por otra parte, también tiene que ser capaz de inyectar estos mensajes procesados al Sis-tema LINPRO a través de la interfaz SIMPLE, implementada por el Sistema LINPRO ydefinida en el STANAG 5602, con el objetivo de simular un escenario táctico concreto.

Por ello, los objetivos que se pretenden alcanzar en el desarrollo de este proyecto se expli-can a continuación.

3.1 Extracción de la informaciónEl primer objetivo consiste en la extracción de la información que se quiere procesar,

almacenada en ficheros Data Extraction que se encuentran en el sistema de almacenamientoHMI (externo o interno). La información puede ser extraída del Sistema LINPRO medianteel dispositivo de almacenamiento externo USB disponible en la Consola HMI.

Los ficheros Data Extraction contienen la información táctica registrada tanto emitida co-mo recibida del Sistema LINPRO con las interfaces con las que se encuentra en contacto,como son las Interfaces Link y la Interfaz de Sistema de Mando y Control.

La herramienta utilizará únicamente los ficheros asociados a las redes Link (Link-11,Link-16) y procesará la información contenida.

3.2 Reconstrucción del escenario tácticoEl siguiente objetivo es el tratamiento de los ficheros asociados a las interfaces tácticas

Link con el fin de eliminar la información menos relevante y obtener de esta manera losmensajes tácticos en bruto.

3.2.1 Recepción de ficherosUna vez que se han obtenido los ficheros Data Extraction, se procede a seleccionar aque-

llos que se consideren significativos.

Del conjunto de mensajes transmitidos (Tx) y recibidos (Rx) del fichero, sólo se procesa-rán aquellos que han sido registrado como recibidos.

3.2.2 Depuración de informaciónEl proceso de filtrado de información eliminará de los mensajes del fichero o ficheros, los

datos de control añadidos durante su generación, quedando en cada mensaje la informacióntáctica correspondiente con su hora de generación.

3. OBJETIVOS 17

Una vez realizada la operación, se genera automáticamente un fichero de salida de caráctertemporal con la información procesada. Esta información contiene la traza de los mensajesen la misma secuencia con la que fueron recibidos, respetando la periodicidad y frecuenciade transmisión en los elementos tácticos que aparece en cada uno de ellos.

3.2.3 Fichero de salidaSe obtendrá únicamente un fichero de salida compuesto por todos los mensajes proce-

sados. Este fichero tendrá un formato de salida específico que está descrito en gramáticaBNF.

3.3 Reproducción y análisis del escenarioA través de la interfaz externa SIMPLE, la herramienta software se comunica con el Sis-

tema LINPRO para inyectar la información procesada. Esta información se envía a LINPROa través de Mensajes SIMPLE, los mensajes propios que tiene la interfaz.

Este último objetivo tiene que ser capaz de inyectar al Sistema LINPRO el fichero proce-sado a través de la Interfaz SIMPLE, teniendo en cuenta los mecanismos de intercambio deinformación, el tipo de mensaje por cada interfaz, y basándose en los protocolos de comuni-cación necesarios para transferir paquetes a través de redesWAN/LAN, permitiendo enlacesde tipo: UDP broadcast, UDP multicast y TCP.

El envío del fichero al Sistema LINPRO permitirá la simulación de un ejercicio real, pu-diendo reproducir exactamente el escenario táctico con el fin de mejorar el Sistema antecualquier incidencia.

3.4 Objetivos secundariosLos objetivos secundarios que se han tenido en cuenta en el desarrollo de esta herramienta

software se describen brevemente a continuación.

Estudio y familiarización con el conjunto del sistema de intercambio de informacióntáctica.

Construcción de un sistema multiplataforma, que pueda ser portado a diferentes arqui-tecturas.

Utilización de diferentes sistemas de almacenamiento para la extracción de ficheros deinformación.

Construcción de una interfaz gráfica que permita la interacción del usuario con la apli-cación, permitiendo poder realizar operaciones básicas sobre los ficheros que se utili-zan en la herramienta.

Generación de un fichero de salida que sea posteriormente utilizado para llevar a cabola finalidad del proyecto.

Capítulo 4

Método de trabajo

E N este capítulo se explica la metodología que se ha seguido en el proyecto. En con-creto, se ha utilizado la del Proceso Unificado de Desarrollo, un método de trabajo ya

estudiado y aplicado en algunas asignaturas de la carrera. Además también se describe el en-torno tecnológico junto con las herramientas software que se han empleado en el desarrollodel proyecto.

4.1 Proceso Unificado de DesarrolloEl Proceso Unificado de Desarrollo (PUD) es una metodología de desarrollo software

que está compuesta de tres características fundamentales, está dirigido por casos de uso, esiterativo e incremental, y está centrado en la arquitectura. [Tor]

Esta metodología consta de varios ciclos en los que cada uno de ellos constituye una ver-sión del sistema. Estos ciclos se dividen en fases, y cada fase puede tener de 1 a n iteraciones.Los ciclos varían en función del proyecto que se quiere realizar.

El PUD propone seguir cada una de las fases de análisis, diseño, implementación y prue-bas, en todas sus iteraciones, por lo que se establece una serie de objetivos por cada itera-ción.

En la fase de inicio se lleva a cabo un proceso de análisis de requisitos y especifi-caciones de usuario que recogen las necesidades que tiene el cliente para obtener elproducto final tal y como quiere.

En la fase de elaboración se realiza un diseño de la arquitectura del sistema, juntocon los diagramas de caso de uso, sus especificaciones y un diseño de las interfacesque componen el sistema final. Se tienen que priorizar los casos de uso para poderestablecer cuáles van a ser los más significativas.

En la fase de construcción se procede a construir el sistema completo, implementadocada objetivo y desarrollando el sistema con la interfaz de usuario.

En la fase de transición se implanta el sistema en la empresa y se realizan las pruebasnecesarias para comprobar que el sistema trabaja correctamente y no hay fallos. Seforma al cliente con manuales de usuario para que pueda comprender el sistema.

19

20 4. MÉTODO DE TRABAJO

Figura 4.1: Proceso Unificado de Desarrollo

A continuación se describe de forma breve cómo se han llevado a cabo las iteraciones enlas cuatro fases del RUP.

4.1.1 Fase de InicioIteración Inicial

En esta iteración inicial se determinó el alcance del proyecto y se fijó el objetivo principal.Se llevó a cabo un estudio e investigación de los sistemas que iban a integrarse con la herra-mienta. También se hizo una estimación del tiempo y de los recursos que serían necesariospara el proyecto.

4.1.2 Fase de ElaboraciónIteración 1

En la primera iteración se realizó una especificación de requisitos del sistema, y además seelaboraron los primeros casos de uso de acuerdo a las funcionalidades de la herramienta.

Iteración 2

Durante la segunda iteración, se llevó a cabo una descripción más detallada del modelo decasos de uso de la Fase de Inicio. Se crearon los modelos de análisis y diseño que son los quedescriben el funcionamiento del sistema, y que finalizarán en la Fase de Construcción.

4. MÉTODO DE TRABAJO 21

4.1.3 Fase de ConstrucciónIteración 3

En esta iteración se realizó un primer boceto de la interfaz de usuario, y se añadieron lasfuncionalidades de extracción de información y reconstrucción del escenario táctico.

Iteración 4

En la cuarta iteración, se llevó a cabo la implementación de la reproducción del escena-rio táctico a través de las comunicaciones de red, con el protocolo TCP, y de los mensajesSIMPLE.

Iteración 5

Se realizaron durante esta iteración, las pruebas de la herramienta con la aplicación EVA-LINK16 con el objetivo de comprobar el correcto funcionamiento de envío del fichero.

4.1.4 Fase de TransiciónIteración 6

En la última iteración, se elaboró un manual de usuario y se realizó la documentación dela herramienta software utilizando Trac. Por último, se entregó el producto final junto contoda la documentación a TECNOBIT.

4.2 Herramientas4.2.1 Lenguaje de programación

C++ es un lenguaje de programación que fue diseñado a mediados de los años 1980 porBjarne Stroustrup. La intención de su creación fue extender el lenguaje de programación Ccon mecanismos que permitieran la manipulación de objetos.

Se puede decir que C++ es un lenguaje que abarca tres paradigmas de la programación:la programación estructurada, la programación genérica y la programación orientada a obje-tos.

Este lenguaje es el que se ha utilizado en la implementación y desarrollo de la herramientasoftware. [Eck]

4.2.2 Software de desarrolloEclipse es un entorno de desarrollo integrado de código abierto multiplataforma. [Ecl]

Se ha utilizado la versión 3.6 Helios, y los plugins para programar en lenguaje de progra-mación C++ y para utilizar Subversion.


Figura 4.2: Eclipse

Qt es un framework multiplataforma desarrollado por la empresa Trolltech con APIS paraprogramar en C++ [Blan]. En este proyecto, Qt ha estado integrado con Eclipse para el diseñode la interfaz de la aplicación. [Qt]

Figura 4.3: Qt

Se han utilizado los siguientes módulos en la implementación del proyecto:

Módulo Descripción

Qt Core Contiene los mecanismos necesarios para la comunicación

entre objetos llamados "signals & slots".

Qt GUI Ofrece clases para la integración de sistemas de ventanas,

manejo de eventos, la integración de OpenGL, gráficos 2D,

imágenes básicas, fuentes y texto.

Qt Network Qt Network proporciona un conjunto de APIs para programar

aplicaciones que utilizan TCP / IP. Las operaciones son manejados

por diferentes clases C++.

Qt Widget Este módulo proporciona los elementos necesarios para crear

interfaces de usuario.


4.2.3 Herramienta de control de versionesSubversion es un sistema de control de versiones open source basado en repositorios. Se

encuentra integrado con Eclipse y con Enterprise Architect en la realización de la implemen-tación.

4.2.4 Herramienta de gestión de requisitosIBM DOORS se utiliza esta herramienta para optimizar la comunicación, la colaboración

y la verificación de requisitos en la organización y en toda la cadena de suministros. Permitecapturar, rastrear, analizar y gestionar cambios en la información, así como demostrar laconformidad con las normas y estándares. [IBMD]

Proporciona un amplio entorno de gestión de requisitos; vincula los requisitos a los ele-mentos de diseño, los planes de prueba, los casos de prueba y otros requisitos; es escalablepara afrontar las necesidades de gestión de requisitos en constante cambio; e incluye TestTracking Toolkit para entornos de prueba manuales, de manera que los probadores puedanvincular requisitos a casos de prueba.

Esta herramienta se ha utilizado para elaborar la especificación de requisitos de softwarey sistema de la herramienta.

Figura 4.4: IBM Doors


4.2.5 Herramienta de modeladoEnterprise Architect es una herramienta que aborda el diseño y análisis UML. Propor-

ciona un entorno de modelización de carácter colaborativo y potenciado mediante UML 2.1,que abarca por completo el ciclo de vida de desarrollo de software. Permite modelar, ges-tionar información compleja, diseñar y visualizar software, o construir y desplegar diversossistemas. [EnA]

Entre sus ventajas cuenta con que es altamente eficaz; tiene una gran estabilidad, velocidady rendimiento; y proporciona trazabilidad completa desde el análisis de requerimientos y losartefactos de diseño, hasta la implementación y el despliegue.

Esta herramienta se ha utilizado para la elaboración de todos los diagramas de análisis ydiseño del sistema software.

Figura 4.5: Enterprise Architect

4.2.6 Herramientas de documentaciónLATEXes un sistema de composición de textos orientado especialmente a la creación de

artículos, documentos científicos y técnicos, tesis y libros.

Es una herramienta de código abierto y permite ser exportado desde una misma fuentea múltiples formatos. Se puede utilizar en cualquier sistema operativo, y existe también uneditor multiplataforma que también es GPL.

Se ha utilizado LATEXpara la elaboración de este documento.


Trac es una herramienta para la gestión de proyectos y el seguimiento de errores escritaen Python inspirado en CVSTrac. Su nombre original era svntrac, debido a su fuerte depen-dencia de Subversion. Es software libre y de código abierto. [Tra]

Permite enlazar información entre una base de datos de errores de software, un sistema decontrol de versiones y el contenido de un wiki. Sirve como interfaz web de un sistema decontrol de versiones como Subversion, Git, Mercurial, Bazaar o Darcs. Utiliza un sistema deplantillas web propio llamado Genshi.

Se ha utilizado Trac para documentar la herramienta software en TECNOBIT.

Figura 4.6: Trac

Capítulo 5

Arquitectura

A Lo largo de este capítulo se explicará cómo se ha aplicado la metodología escogida,centrándose en cada una de las fases e iteraciones de forma más específica.

5.1 Fase de InicioEn la Fase de Inicio se identificó el ámbito del proyecto y se definieron los objetivos de

forma más concreta. Se realizó una estimación inicial de recursos, coste y tiempo empleadosen su desarrollo. Por último se ejerció una laboriosa tarea de recopilación de información yestudio sobre el entorno de trabajo.

5.1.1 Iteración InicialAlcance del proyecto

En esta primera iteración inicial, se fijó el alcance que iba a tener el proyecto, planteán-dose la cuestión a resolver a través de unas reuniones con los responsables de Ingeniería delSoftware de TECNOBIT.

Este proyecto propuesto no cuenta con ningún sistema de referencia anterior, por lo quese ha desarrollado partiendo de cero. Por ello, se determinaron con detalle los objetivos yfuncionalidades que tenía que cumplir la herramienta software a desarrollar con el fin depoder satisfacer las necesidades de la empresa.

Para enfrentarse a la resolución de este problema, se realizó una labor de estudio y deinvestigación del entorno en el que se iba a integrar la herramienta. Este proceso de fami-liarización con el marco de trabajo se hizo posible con la documentación proporcionada porTECNOBIT sobre el Sistema LINPRO, las interfaces tácticas y la interfaz SIMPLE.

Limitaciones

La principal limitación con la que contaba el proyecto era la de la temporalidad, ya quese estimó un periodo de 6 meses para el desarrollo del mismo. Otra de las limitacionesmás importantes fue la limitación sobre la información y el acceso a la misma, debido aque algunos documentos tenían clasificación de seguridad restringida y su estudio no fueposible. Por último, las limitaciones en recursos hardware y software con los que contaba la

27

28 5. ARQUITECTURA

empresa, fueron factores a tener en cuenta en el desarrollo del mismo debido a que se teníanque utilizar los que se proporcionaban.

Riesgos

En la realización del proyecto surgieron algunos inconvenientes que hicieron que se retra-sase un mes de la planificación prevista inicialmente.

El tema abordado en este proyecto fue novedoso, nunca se había tratado un proyecto deeste ámbito y con estas características. Se tuvo que dedicar tiempo a aprender los nuevosconceptos y a profundizar sobre el entorno de los objetivos planteados y utilización de lastecnologías.

Estimación de recursos

Se realizó una estimación de los recursos necesarios para la elaboración del proyecto.Estos recursos, tanto software como hardware, fueron proporcionados por TECNOBIT. Lalista de recursos utilizados se encuentra en el segundo apartado del Capítulo 4.

Estimación de tiempo y costo

Una vez conocido el alcance del proyecto y la definición de objetivos, se hizo una planifi-cación del tiempo que se emplearía en desarrollar la herramienta software.

Este calendario de trabajo se puede ver en la Figura 5.1 donde se prevé una duración de6 meses, desde Julio hasta Diciembre de 2012, con una dedicación de 8 horas de Lunes aViernes.

El costo del proyecto se estimó en un total de 3600 euros, 600 euros durante los 6 mesesde trabajo.

Entorno de trabajo

Durante esta fase de inicio, se realizó un estudio del entorno de trabajo que iba a estarrelacionado con el desarrollo de la herramienta. Se estudiaron los estándares de cada una delas interfaces tácticas Link-11 y Link-16, y el estándar de la interfaz SIMPLE.

Debido a que eran conocimientos nuevos, se dedicó una gran parte del tiempo en ponerseen el contexto de trabajo. También las herramientas con las que se iba a trabajar no eran lasutilizadas habitualmente, por lo que se invirtió también tiempo en el uso de ellas.

5. ARQUITECTURA 29

Figura 5.1: Calendario de trabajo inicial

5.2 Fase de ElaboraciónEn esta segunda fase se abordó la especificación de requisitos del sistema y se elaboró

un documento, utilizando IBM Doors, donde se recogían todos ellos. El documento sigue elestándar “498 Software Development and Documentation” y se encuentra en el Anexo A.

Una vez obtenidos los requisitos de la herramienta software, se definieron los casos de usomás importantes del sistema a desarrollar.

5.2.1 Iteración 1La iteración 1 tiene que ver con la descripción de los requisitos de la herramienta. Como

se ha mencionado anteriormente, se realizó un documento donde se describían cada uno deellos. Se muestra a continuación un resumen de los requisitos funcionales y no funcionalesque tendrá la aplicación software:

Requisitos funcionales

Se podrá extraer la información almacenada en ficheros Data Extraction de cualquiersistema de almacenamiento.

Los ficheros serán los asociados a las redes Link-11 y Link-16.

Se podrá extraer un número determinado de ficheros.

La aplicación debe convertir el/los fichero/s de datos en un fichero de salida determi-nado.

Se podrá visualizar por pantalla el resultado de la depuración de la información.

30 5. ARQUITECTURA

Se tendrá la opción de guardar el fichero resultante.

Se podrá enviar la información al Sistema LINPRO a partir de una dirección IP y unpuerto establecido previamente.

En cualquier momento, se podrá parar y/o reiniciar el envío de la información al Sis-tema LINPRO.

Requisitos no funcionales

La aplicación será multiplataforma, y se implementará en C++.

La interfaz será sencilla e intuitiva.

No habrá requisitos software o hardware específicos para instalar y/o ejecutar la apli-cación.

El operador de la aplicación será el encargado de realizar todas las operaciones.

5.2.2 Iteración 2En esta segunda iteración se explica la elección de la arquitectura y la estructura del mismo

a través de los casos de uso del sistema con su correspondiente descripción.

Arquitectura

Cuando se realiza el diseño de una aplicación software, hay que destacar lo importanteque es el hacer una buena elección de la arquitectura en la que se va a basar. En este proyectose ha aplicado una arquitectura modular para llegar a la resolución del objetivo principal.

Figura 5.2: Arquitectura del sistema

5. ARQUITECTURA 31

Esta descomposición modular consiste en dividir el problema principal en subproblemas,de manera que cada uno de ellos realice unas funciones específicas. En este caso, se hadividido el problema planteado en tres módulos correspondientes, cada uno de ellos, conlos subobjetivos planteados en el Capítulo 3. En la Figura 5.2 se puede ver la división enmódulos que se ha aplicado.

Se ha elegido desarrollar la aplicación a través de una colección de módulos por las ven-tajas que ofrece como son la construcción de cada módulo de forma independiente, la depu-ración de cada uno de ellos y la reducción de tiempo en su elaboración.

Diagrama de casos de uso del sistema

Figura 5.3: Diagrama de casos de uso del sistema

En la Figura 5.3 se puede ver el diagrama de casos de uso del sistema. El actor que vaa interactuar con el sistema es el operador, que podrá acceder a todas las funcionalidades.Éstas son:

Seleccionar: El operador podrá seleccionar un fichero de cualquier tipo de almacena-miento, para su posterior procesamiento.

Procesar: El operador procesará el fichero pulsando un botón en la aplicación.

Enviar: El operador enviará el fichero procesado junto con una dirección IP y unpuerto.

Guardar: Habrá una opción de guardar el fichero procesado.

Parar: Habrá una opción de parar el envío de información.

Reiniciar: Habrá una opción de reiniciar la aplicación.

32 5. ARQUITECTURA

Se explican en las siguientes páginas las funcionalidades de la herramienta a través dediagramas de secuencia

Caso de uso 1: Seleccionar

Figura 5.4: DdS 1 - Seleccionar

Caso de uso SeleccionarActor OperadorObjetivo Seleccionar un fichero del sistema de

almacenamiento. Se podrá seleccio-nar cualquier fichero asociado a lasredes Link-11 y/o Link-16.

Actor Sistema1. El actor quiere seleccionar un fi-chero y hace click en Abrir.

2. El sistema recoge el evento ymuestra la ventana necesaria para laselección del fichero.

3. El actor selecciona el fichero y ha-ce click en Aceptar.

4. El sistema muestra en una ventanade la aplicación los ficheros que hansido seleccionados, y en otra ventanael contenido de esos ficheros.

Cuadro 5.1: Detalle CdU 1

5. ARQUITECTURA 33

Caso de uso 2: Procesar

Figura 5.5: DdS 2 - Procesar

Caso de uso ProcesarActor OperadorObjetivo Procesar el fichero eliminando la in-

formación irrelevante.

Actor Sistema1. El actor hace click en Procesar 2. El sistema recoge el evento y

muestra una ventana de alerta sobresi se quiere seguir con el procesa-miento.

3. El actor hace click en Aceptar siquiere seguir con el procesamiento,o en Cancelar si por el contrario noquiere continuar.

4. El sistema recoge el evento ymuestra en una ventana de la aplica-ción el contenido del fichero proce-sado.


34 5. ARQUITECTURA

Caso de uso 3: Enviar

Figura 5.6: DdS 3 - Enviar

Caso de uso EnviarActor OperadorObjetivo Enviar uno o varios ficheros proce-

sados al Sistema LINPRO mediantesmensajes SIMPLE.

Actor Sistema1. El actor hace click en Enviar. 2. El sistema recoge el evento y

muestra el envío de los ficheros pro-cesados al Sistema LINPRO hastaque termina.


5. ARQUITECTURA 35

Caso de uso 4: Guardar

Figura 5.7: DdS 4 - Guardar

Caso de uso GuardarActor OperadorObjetivo Guardar el contenido del fichero pro-

cesado en un nuevo fichero para usar-lo posteriormente.

Actor Sistema1. El actor quiere guardar el ficheroprocesado y hace click sobre Guar-dar.

2. El sistema recoge el evento ymuestra una ventana para que el ac-tor introduzca un nombre para el fi-chero.

3. El actor introduce los datos y haceclick sobre Aceptar.

4. El sistema guarda el fichero.


36 5. ARQUITECTURA

Caso de uso 5: Parar

Caso de uso PararActor OperadorObjetivo Parar el envío de información al Sis-

tema LINPRO.

Actor Sistema1. El actor quiere parar el envío demensajes al Sistema LINPRO y haceclick en Stop.

2. El sistema recoge el evento y parade forma inmediata la comunicaciónestablecida.


Caso de uso 6: Reiniciar

Caso de uso ReiniciarActor OperadorObjetivo Reiniciar la aplicación.

Actor Sistema1. El actor quiere reiniciar la aplica-ción y hace click en Reiniciar.

2. El sistema recoge el evento y laaplicación se reinicia.


(a) DdS 5 - Parar (b) DdS 6 - Reiniciar

Figura 5.8: Diagramas de secuencia 5 y 6

5. ARQUITECTURA 37

5.3 Fase de ConstrucciónEsta fase está relacionada con la implementación de la aplicación. Se divide en tres itera-

ciones donde se desarrollan los módulos de la arquitectura del sistema. Además se diseñanlos primeros bocetos de la interfaz de usuario, hasta llegar a la versión definitiva.

Se realiza todo el trabajo de implementación de la herramienta en esta parte del proyecto.Uno de los requisitos que tiene establecidos es el de la portabilidad de la aplicación a cual-quier sistema operativo y a cualquier equipo del laboratorio. En este caso, el entorno dondese ha trabajado y se han hecho las pruebas, que se explican más adelante, ha sido sobre elsistema operativo Windows XP.

5.3.1 Iteración 3La iteración 3 se identifica con el módulo de entrada y el de procesamiento de datos.

Se realizaron las implementaciones de las funciones de selección de ficheros y filtrado deinformación.

Módulo de entrada de datosEsta sección trata sobre la extracción de los ficheros DX que utilizará la aplicación. Se

pueden extraer de cualquier dispositivo de almacenamiento de datos disponible, como puedeser de un disco duro o de una memoria USB.

Se recibirán los ficheros de datos DX en el formato propio de la interfaz táctica, ya quecada una tiene una especificación concreta de formato (Véase Capítulo 2).

Como se ha explicado, estos ficheros son los que están asociados a las redes tácticas Link-11 y Link-16. Cada fichero contiene la información táctica que ha registrado el SistemaLINPRO con cada una de estas interfaces con las que establece comunicación. El contenidode cada fichero está formado por los mensajes tácticos recibidos (RX) y emitidos (TX) juntocon toda la información y datos de control de cada uno de ellos.

Figura 5.9: Proceso Entrada de datos

38 5. ARQUITECTURA

En este módulo es necesario obtener los ficheros para continuar en el siguiente módulotrabajando con ellos. El proceso es como está descrito en la Figura 5.9.

Implementación

Para implementar esta parte, se ha utilizado la clase QFile de Qt, que proporciona unainterfaz para la lectura y escritura de archivos y recursos de texto y/o binarios. Además sehan utilizado conjuntamente las clases QTextStream y QDataStream para leer y escribir textoy visualizarlo por pantalla en la interfaz.

Módulo de procesamiento de datosEn esta sección se aborda el módulo del procesamiento de la información de los ficheros.

El propósito es obtener un fichero con los mensajes en bruto, eliminando los datos de controlque se añaden al fichero.

La herramienta contiene los dos tipos de mensajes, recibidos y transmitidos, pero solo seprocesarán aquellos que tengan el campo indicador de transmisión con valor RX, es decir,los mensajes registrados como recibidos.

Este proceso elimina la información que no es relevante conocer, salvo la hora de recep-ción y el contenido del mensaje en hexadecimal o binario. En este caso, se decidió guardarla información en hexadecimal.

La información se puede guardar en un fichero aparte con todos los datos tácticos de losmensajes, para su posterior uso. Este fichero de salida tiene la traza de los mensajes en lamisma secuencia en la que se generaron.

A continuación se muestra el ejemplo de un fichero con el contenido original, y despuésel mismo fichero con el contenido que tiene una vez procesado por la herramienta.

Nota: Los datos mostrados en este ejemplo son una representación de los datos en hexa-decimal y en binario que tienen los mensajes reales con los que se ha estado trabajando. Nose ha mostrado ningún mensaje real debido al carácter confidencial que tiene el proyecto.

Ejemplo fichero original

Como se puede observar en el Cuadro 5.7, el fichero está compuesto por un conjuntode mensajes de tipo Link-11. Cada mensaje tiene una cabecera en la que se muestran lossiguientes datos:

Longitud del mensaje

Hora de envío

Tipo (Recibido o Transmitido)

Número de palabras que forman el mensaje

5. ARQUITECTURA 39

Link-11 message capture data extractionlong: 6 time: 17:08:11 TxRepresentación_Hexadecimal Representación_BinariaRepresentación_Hexadecimal Representación_Binaria

Representación_Hexadecimal Representación_BinariaRepresentación_Hexadecimal Representación_Binaria


Link-11 message capture data extractionlong: 8 time: 17:08:16 RxRepresentación_Hexadecimal Representación_BinariaRepresentación_Hexadecimal Representación_Binaria








Representación_Hexadecimal Representación_BinariaRepresentación_Hexadecimal Representacion_Binaria

Cuadro 5.7: Ejemplo fichero original

40 5. ARQUITECTURA

Los mensajes necesarios son los recibidos, por lo que la herramienta solo filtrará, de ambostipos, los que tengan valor Rx junto con las palabras que forman ese mensaje.

Ejemplo fichero procesado

El fichero una vez procesado queda como se muestra en el Cuadro 5.8, cada mensajecon su hora de recepción y el contenido de datos en hexadecimal ordenados por su hora derecepción. De igual manera se podría haber elegido indicar el contenido en binario, pero seestableció de esa manera.

17:08:16Representación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_Hexadecimal

17:08:25Representación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_Hexadecimal

17:08:45Representación_HexadecimalRepresentación_HexadecimalRepresentación_HexadecimalRepresentación_Hexadecimal

Cuadro 5.8: Ejemplo fichero procesado

Especificación EBNF del fichero de salidaLa especificación del fichero de salida, en notación EBNF, es la descrita a continuación:

f i c h e r o := {}b l oq ue de d a t o s := <cuerpo >i n f o := t ime : < t iempo >c ue rp o := {}

5. ARQUITECTURA 41

p a l a b r a de mensa je := <word hexadec ima l >word h e x a d e c i m a l := 0x1{< d i g i t o hexadec ima l >}8t i empo := hh :mm: s s

Boceto de interfaz de usuario

El primer boceto que se diseñó para la interfaz de la herramienta es el el que se muestraen la siguiente figura. Es el modelo más básico y simple que se creó en esta primera fasede construcción y que contiene las principales funcionalidades. A partir de este boceto sefueron creando los sucesivos hasta llegar al diseño final.

Figura 5.10: Boceto IU

Implementación

Para esta parte, se han utilizado las clases de Qt:

QString: proporciona una cadena de caracteres Unicode.

QStringList: proporciona una lista de cadenas.

Estas clases proporcionan multitud de funcionalidades que se han utilizado para procesarlos mensajes y obtener el conjunto de mensajes finales.

La implementación de la interfaz de usuario se ha realizado totalmente con Qt, debido aque es una herramienta completa para diseñar interfaces y contiene una amplia variedad defunciones que ayudan a la programación de los módulos de esta aplicación.

42 5. ARQUITECTURA

5.3.2 Iteración 4En la cuarta iteración se afronta el último módulo de la arquitectura del sistema, enfoca-

do al envío de los mensajes por la interfaz SIMPLE. Para ello se va a describir cómo estáformado un mensaje SIMPLE, y cómo se han encapsulado en ellos los mensajes Link-11 yLink-16 y sus respectivas trazas.

Módulo de envío de datosEn este último módulo, el problema principal viene dado por la elección de una estructura

que se adaptara a los dos tipos de mensajes. Otro aspecto importante que se tuvo en cuentaes que había que respetar el orden, secuencia y tiempo de cada traza de los mensajes.

Para establecer la comunicación entre la interfaz SIMPLE y la aplicación desarrollada, sepueden utilizar distintos tipos de protocolos. La aplicación de estos protocolos es opcional,sin embargo, con el fin de realizar implementaciones separadas para comunicarse con éxitose debe poner en práctica el mismo protocolo.

Actualmente hay tres protocolos Ethernet WAN/LAN que son utilizados para las platafor-mas de aplicación del estándar SIMPLE:

UDP broadcast

UDP multicast

TCP

Tanto UDP como TCP requieren que el Protocolo de Internet (IP) se use como un proto-colo subyacente y esta forma es conocida a menudo como UDP/IP y TCP/IP.

El estándar SIMPLE para comunicaciones WAN/LAN utiliza IP como la capa de red,y UDP o TCP como la capa de transporte. Esta estructura de capas requiere que variosencabezados de protocolo precedan el Packet Header del estándar SIMPLE.

En la siguiente sección se especifica como está formado el Mensaje SIMPLE detallandolos parámetros que lo componen y los cuales han sido implementados en estructuras para elenvío de mensajes.

Estructura Mensaje SIMPLE

El protocolo SIMPLE implementa un protocolo de tres capas de nivel básico que com-prende los siguientes paquetes:

Synchronous Network Header

Packet Header

Packet Data

Checksum

5. ARQUITECTURA 43

Figura 5.11: Mensaje SIMPLE

El formato de este mensaje consiste en 3 palabras de información de la cabecera de red,seguido de 4 palabras de información de encabezado de los paquetes y seguido de N palabrasde información de datos en paquetes. Además se añade una suma de comprobación al finaldel paquete. En la Figura 5.11 se muestra la estructura del mensaje.

Network Header define las características comunes para todos los paquetes.

Packet Header puede ser diferente para cada tipo de paquete y define los parámetrosapropiados para ese tipo de paquete.

Packet Data comprende los datos que se van a transferir, por ejemplo, los datos delmensaje TDL.

La información de la interfaz SIMPLE está compuesta por un conjunto de componentesorganizados en serie y transmitidos en flujos de bits. La representación de esta informaciónemplea palabras de 16 bits, como se observa en la Figura 5.12.

Hay que tener en cuenta en la implementación que cada palabra de 16 bits va desde el bit0 hasta el 15, siendo el bit 0 el menos significativo y el bit 15 el más significativo.

44 5. ARQUITECTURA

Figura 5.12: Organización información

• Synchronous Network Header

Los datos de la cabecera de red emplean una transmisión bisíncrona para permitir quelos nodos simples detecten el inicio de cada mensaje y la longitud de cada mensaje, y paracomprobar la integridad de los datos del mensaje.

Esta transmisión bisíncrona es un protocolo de transferencia síncrona de bytes. La sin-cronización entre el transmisor y el receptor se lleva a cabo comenzando cada traza con unpatrón especial.

El patrón normalmente consiste en una secuencia de 2 o más caracteres especiales llama-dos caracteres SYN. El patrón binario del carácter SYN varía en función de la aplicación.En SIMPLE los caracteres SYN son 49H y 36H. Las trazas normalmente terminan con unasecuencia de verificación de 16 bits para permitir la detección de algún error (pero no lacorrección de errores).

Figura 5.13: Estructura Network Header

En la Figura 5.13 se muestran los parámetros que componen la cabecera de red de unmensaje SIMPLE. Estos parámetros son codificados dependiendo del tipo de mensaje que sevaya a encapsular. Como se ha mencionado antes, Synch Byte 1 y Synch Byte 2 tienen unosvalores concretos.

5. ARQUITECTURA 45

• Packet Header

El encabezado de los paquetes de datos se utiliza para administrar y enrutar todos losmensajes que son procesados por el sistema SIMPLE. El nodo originario SIMPLE lleva acabo la generación de el paquete de cabecera.

En esta parte del paquete es donde tiene que figurar qué tipo de mensaje se va a mandar,ya sea Link-11 o Link-16, y se tiene que poner como valor al parámetro Packet Type. Cadamensaje SIMPLE que se envía, contiene una cabecera como la que se detalla en la Figura5.14.

Figura 5.14: Estructura Packet Header

La última parte del mensaje SIMPLE consiste en incluir el Packet Data, que es donde va aestar toda la información táctica. Como hay diferentes tipos de mensajes para enviar, PacketData tiene su estructura específica para cada tipo de ellos. En este proyecto se han utilizadolas estructuras correspondientes a Link-11 y Link-16.

La implementación de cada tipo de paquete en la herramienta ha sido la parte de trabajoque más tiempo ha llevado, debido a que había que definir dos estructuras diferentes teniendoen cuenta todos los paquetes que forman un mensaje SIMPLE.

Cada uno de estos paquetes, había que adaptarlos y configurarlos para que realizase lafunción principal de envío de la herramienta: encapsular cada mensaje del fichero procesa-do en mensajes SIMPLE. Esta tarea resultó complicada debido a la existencia de formatosdiferentes para codificar cada mensaje:

En Link-11, los mensajes están formados por dos trazas de 24 bits divididas en 4palabras.

En Link-16, los mensajes están formados por una traza de 70 bits divididos en 5 pala-bras.

Además de estas características tan concretas, había que tener en cuenta la organizaciónde la información en cada uno de estos mensajes como se ha visto en el apartado anterior.

46 5. ARQUITECTURA

• Packet Data Link-11

Objetivo: Distribuir Link 11 mensajes transmitidos por el host de un nodo SIMPLE.

Transmisión: En la recepción por el nodo SIMPLE del host conectado, la terminal deTDL, simulación, etc.

Procesamiento especial: Ninguno.

Figura 5.15: Estructura Packet Data Link-11

Los mensajes TADIL A están formados por dos trazas de mensajes de 24 bits. Los datosdel mensaje se componen de una o más palabras estructuradas de la siguiente manera:

Figura 5.16: Message Data Link-11

• Packet Data Link-16

Objetivo: Distribuir mensajes Link-16 de formato fijo, texto libre codificado y textolibre no codificado transmitidos por el conductor de un nodo SIMPLE libre.

Transmisión: En la recepción por el Nodo SIMPLE del host conectado, la terminal deTDL, simulación, etc

Procesamiento especial: Tiene algunos requisitos especiales incluidos en el STANAG5602.

5. ARQUITECTURA 47

Figura 5.17: Estructura Packet Data Link-16

Los mensajes Link 16 utilizados han sido los de formato fijo. Los datos de mensaje secompone de una o más palabras de código cuyo formato es de la siguiente manera:

Figura 5.18: Message Data Link-16

Implementación

Una vez descritos los paquetes que forman un Mensaje SIMPLE, se explica cómo se haimplementado en este proyecto la estructura de lo mensajes que se van a enviar a través dela Interfaz SIMPLE.

Cada uno de los mensajes que han sido procesados, se encapsulan en nuevos mensajesSIMPLE Link-11 ó Link-16. La decisión de diseño fue la de crear un tipo struct que tuvieratodos los parámetros del mensaje SIMPLE y los datos tácticos propios de cada interfaz.

Este struct sería único para cada interfaz táctica, debido a que Link-11 y Link-16 tienendiferentes tipos de parámetros y palabras de mensaje.

48 5. ARQUITECTURA

La estructura de los mensajes Link-11 queda como en la siguiente Figura 5.19, formadopor los parámetros que tiene el Mensaje SIMPLE y el conjunto de palabras de cada mensajeque lo forman, comprendidos entre 1 y N.

Figura 5.19: Struct Link-11

De la misma manera, se envían los mensajes Link-16 y como se puede apreciar en laFigura 5.20, la estructura de estos mensajes es distinta a la de Link-11.

5. ARQUITECTURA 49

Figura 5.20: Struct Link-16

El proceso de envío se realiza a través de la clase QTcpSocket que proporciona un socketTCP para la comunicación entre cliente y servidor. QTcpSocket es una subclase de QAbs-

tractSocket que permite establecer una conexión TCP y transferir flujos de datos.

TCP (Transmission Control Protocol) es un protocolo de comunicación orientado a co-nexión y fiable a nivel de transporte. Está bien adaptado para la transmisión continua dedatos.

50 5. ARQUITECTURA

Figura 5.21: TCP Cliente - Servidor

Boceto interfaz de usuario

El boceto de la interfaz de usuario iba en evolución en paralelo con el desarrollo de laherramienta. Cada vez que se realizaba una funcionalidad, ésta se incluía en la interfaz pararealizar su prueba. En la figura mostrada a continuación se puede observar un diseño algo máscompleto que el primero. Aún así, el diseño mostrado en la Figura 5.22 no fue el definitivo,puesto que después se incluyeron otras funcionalidades no especificadas y que se pensaronde utilidad para la aplicación.

Figura 5.22: Boceto IU

5.3.3 Iteración 5En la última iteración de la Fase de Construcción, se llevaron a cabo las pruebas de la apli-

cación con EVALINK, una herramienta desarrollada por el ITM para validar las capacidadesdel Sistema LINPRO, y que comprueba que los mensajes se envían correctamente y que nohay pérdida de mensaje.

5. ARQUITECTURA 51

Pruebas EVALINK

Para realizar estas pruebas, de tiene que configurar EVALINK con un puerto y una direc-ción IP. Esta comunicación que se establece entre la herramienta y el software de pruebas esa través de Ethernet. Cada mensaje se envía a EVALINK y éste aparece junto con el tipo demensaje y su hora enviada.

Las pruebas se realizaron con distintos tipos de ficheros con mensajes Link-11 y Link-16.Una de las pruebas más significativas que se hicieron, fue la de enviar dos archivos con ambostipos de mensajes y comprobar que se correspondían los tiempos de envío en EVALINK conlos de ambos ficheros.

5.4 Fase de TransiciónEsta última iteración tiene que ver con la elaboración de la documentación relacionada

con la herramienta.

5.4.1 Iteración 6Manual de usuario

El manual de usuario de la herramienta se realizó en la última semana, cuando la interfazde usuario quedó en su versión definitiva. Se puede consultar este manual en el Anexo 2 deeste documento.

Este manual sirve para mostrar cómo se utiliza la aplicación software con todas sus fun-cionalidades, y se entregó junto con la herramienta.

Trac

En TECNOBIT se utilizó la herramienta Trac para documentar todo el proyecto para quepudiera estar accesible a cualquier persona de la empresa. Se elaboró una wiki con toda lainformación referente al simulador táctico, adjuntando también el manual de usuario.

5.5 HitosUna vez finalizado el proceso de desarrollo de la arquitectura pasando por cada una de las

fases del PUD, se recoge en los siguientes hitos un resumen de cada una de ellas.

HITO 1 (FASE DE INICIO) En esta fase se ha definido la problemática del proyecto,cómo se ha planificado el desarrollo en materia de tiempo y coste, y el estudio realizado parasu elaboración.

HITO 2 (FASE DE ELABORACIÓN) En esta fase se ha elegido la arquitectura dela herramienta, se han especificado sus requisitos y se han elaborado los diagramas de uso y

52 5. ARQUITECTURA

de secuencia para las funcionalidades del simulador táctico.

HITO 3 (FASE DE CONSTRUCCIÓN) En la tercera fase se ha realizado toda la im-plementación de la arquitectura y las pruebas necesarias para comprobar el funcionamiento.

HITO 4 (FASE DE TRANSICIÓN Por último, se elaboró un manual de usuario contoda la documentación del proyecto, y se hizo una wiki para TECNOBIT.

Capítulo 6

Resultados

E N este capítulo se evalúa el proyecto en términos de recursos, costes y tiempo empleado.Además se adjunta un ejemplo completo de uso de la herramienta.

6.1 Recursos y costesCon el proyecto terminado, se hizo una estimación final de los recursos y costes que se

han empleado en el desarrollo del proyecto. En la siguiente tabla se puede ver el resumenfinal:

Recurso Cantidad CosteRecursos humanos 1 4200 eurosOrdenador de sobremesa 1 780 eurosOtros materiales 1 50 eurosTotal 5030 euros

Cuadro 6.1: Recursos y costes del proyecto

El coste total que ha supuesto a la empresa el desarrollo de este proyecto es de 5030 euros.Se ha calculado el sueldo del programador en 600 euros cada mes que se ha trabajado allí,debido a que es lo que se ha cobrado al mes.

6.2 Calendario finalSe realizó también el calendario final, donde se muestra en la Figura 6.1 el inicio y fin del

desarrollo de la herramienta, y el cual ha comprendido desde el 2 de Julio de 2012 hasta el15 de Febrero de 2013, una duración de 7 meses.

Durante esos meses en TECNOBIT, se elaboró la herramienta, aunque en principio seestimaron 6 meses, se tuvo que ampliar un mes más de lo acordado por la falta de tiempopara realizar las pruebas.

A este inconveniente, se le sumaron otros como fueron la compaginación de estar en laempresa por la mañana, y tener clases y prácticas en la Escuela por las tardes. Y también, enEnero, la realización de los exámenes ordinarios.

53

54 6. RESULTADOS

Figura 6.1: Calendario de trabajo final

6. RESULTADOS 55

6.3 Ejemplo completoEn esta sección se muestra un ejemplo de la aplicación. La interfaz de usuario final de la

aplicación se puede ver en la Figura 6.2.

Figura 6.2: Ejemplo 1

56 6. RESULTADOS

6.3.1 Abrir ficheroPara abrir un archivo en la herramienta, hay que pulsar en Abrir Archivo, y seguidamente

nos sale una ventana para seleccionar el fichero que se quiere abrir.


6. RESULTADOS 57

6.3.2 Contenido fichero originalUna vez seleccionado el archivo, se muestra en la interfaz el contenido del mismo. Además

se añade la ruta del archivo abierto en la parte inferior de la interfaz, de modo que se puedaver qué archivos se tiene en el simulador.


58 6. RESULTADOS

6.3.3 Procesamiento de ficheroPara procesar el fichero que se ha abierto, hay que pulsar en Procesar. Se abre una ventana

para que se confirme si se quiere proceder a realizar la acción.


6. RESULTADOS 59

El contenido del fichero procesado también se muestra en una ventana de la herramienta,con el objetivo de poder consultarlo.


60 6. RESULTADOS

6.3.4 Envío de ficheroPara enviar el fichero a EVALINK, hace falta establecer los puertos y direcciones. Una

vez puestos, se pueden enviar los ficheros procesados.

En la herramienta hay que poner el mismo puerto y dirección IP que hay en EVALINK.También se puede observa la hora y tipo de mensaje que se va enviando a EVALINK entiempo real.


6. RESULTADOS 61

A su vez, en el mapa de EVALINK se van marcando los mensajes correspondientes a sutipo. Se puede ver que la hora de envío de los mensajes coincide con la hora que se muestraen la herramienta.

Cuando se han enviado todos los mensajes, se para la comunicación en la herramienta yen EVALINK.


Capítulo 7

Conclusiones

En este último capítulo, se exponen las conclusiones finales del trabajo realizado. Ademásse resumen los objetivos que se han realizado exitosamente y se proponen otros para trabajosfuturos.

7.1 Objetivos alcanzadosSe han cumplido los objetivos planteados en el anteproyecto y que se explican en el Capí-

tulo 3, salvo el de la integración y simulación de la interfaz táctica Link-22 en la herramien-ta.

No ha sido posible el desarrollo de este objetivo debido a la limitación temporal del pro-yecto, por lo que se incluye en las propuestas aportadas para realizar en un futuro.

El resultado final de este proyecto ha sido el desarrollo de una herramienta que servirá co-mo apoyo al Sistema LINPRO para poder representar el sistema real de un escenario tácticoproporcionado previamente.

Esta herramienta es capaz de procesar escenarios donde intervienen las interfaces tácticasLink-11 y Link-16, y además permite la comunicación con el Sistema LINPRO para el envíode información.

7.2 Propuestas futurasComo aportaciones que se puedan realizar e integrar en la herramienta en un futuro, se

proponen las siguientes:

Interfaz Link-22: Integración de la interfaz táctica Link-22 en la herramienta. Crea-ción del mensaje SIMPLE relacionado con Link-22 y simulación de estos mensajes.

Interfaz MNE e Interfaz N: Integración de estas interfaces que están en comunica-ción con el CDS en la herramienta, como medio para poder simular los mensajes quese transmiten con el Sistema LINPRO.

Creación de mensajes: Sería una buena opción el poder disponer de todos los pará-metros que se utilizan a la hora de crear un mensaje, y poder crearlos en la herramientadirectamente, con el objetivo de poder simular mensajes concretos para su estudio.

63

64 7. CONCLUSIONES

7.3 ConclusionesFinalmente puedo destacar, que estos meses de trabajo me han servido para tener una

primera toma de contacto con el mundo laboral y poder tener experiencia en el sector deInformática gracias a una empresa tan importante como es TECNOBIT.

He podido poner en práctica los conocimientos adquiridos durante la carrera, así comoaprender nuevas metodologías y herramientas con las que trabajar en el futuro. Además,también he podido conocer de primera mano la forma de trabajo de la empresa, he tenidoresponsabilidades y he desarrollado una herramienta que se va a poder utilizar en los labora-torios de la empresa.

Esta experiencia me ha resultado muy positiva, y también ha ayudado mucho el equipode trabajo y la empresa, que me han dado todo tipo de facilidades para poder realizar esteproyecto.

Bibliografía

[Blan] BLANCHETTE, J., SUMMERFIELD, M., C++ GUI Programming with Qt 4 2a ed.Prentice Hall, Febrero 2008.

[Eck] ECKEL, B., Thinking in C++ 2a ed., 2000.

[Ecl] ECLIPSE, http://www.eclipse.org

[EnA] ENTERPRISE ARCHITECT, http://www.sparxsystems.es

[IBMD] IBM DOORS, http://www-03.ibm.com/software/products/es/es/ratidoor

[Mon] MONTOYA, A., Tecnología y Fuerzas Armadas. 1a ed. Madrid: Ministerio de Defen-sa, Febrero 2007.

[Nav] NAVY UNITED STATES, Electronics Technician. Volume 3: Communications Systems

July 1997.

[Qt] QT, http://qt-project.org

[S5511] NATO STANDARDIZATION AGENCY (NSA), Tactical Data Exchange - Link

11/Link 11B 5a ed.

[S5516] NATO STANDARDIZATION AGENCY (NSA), Tactical Data Exchange - Link 16

3a ed.

[S5602] NATO STANDARDIZATION AGENCY (NSA), Standard Interface for Multiple Plat-

form Link Evaluation (SIMPLE) 3a ed., Julio 2007.

65

http://www.eclipse.org

http://www.sparxsystems.es

http://www-03.ibm.com/software/products/es/es/ratidoor

http://qt-project.org

66 BIBLIOGRAFÍA

[Tec] TECNOBIT, http://www.tecnobit.es

[Tor] TOROSSI, G., El Proceso Unificado de Desarrollo Software

[Tra] TRAC, http://trac.edgewall.org

http://www.tecnobit.es

http://trac.edgewall.org

ANEXOS

Anexo A

Documento IBM Doors

A.1 ObjetoEste documento constituye la especificación de requisitos software para la definición de

un entorno de simulación de escenarios tácticos, a partir de una grabación realizada por elSistema LINPRO.

Este Sistema permitirá inyectar al Sistema LINPRO, a través de la interfaz SIMPLE, lainformación táctica almacenada en ficheros Data Extraction generados por el propio Sistemade un ejercicio real, permitiendo a posteriori depurar el Sistema LINPRO ante cualquierincidencia ocurrida.

A.1.1 IdentificaciónA.1.2 Descripción General del SistemaSistema LINPRO

El Sistema LINPRO es un Procesador de Datos Tácticos que tiene capacidad de inter-cambio de información táctica en redes Link-11, Link-16 y Link-22, y capacidades de DataExtraction generando un fichero de datos para cada interfaz táctica con la información inter-cambiada por el Sistema LINPRO tanto en transmisión como en recepción.

Para cada una de las interfaces Link, el Sistema LINPRO se apoya en diferentes elementosde comunicación, como elementos crypto, modems, radios etc. según se muestra en la Figura1.1. Obtiene la información local que será transmitida a las redes Link, del Sistema de Mandoy Control de la plataforma en la que se integra. De la misma forma, toda la informaciónrecibida de las redes Link es transmitida al Sistema de Mando y Control de la plataformadesacoplando a este de la gestión y de los procesos particulares del intercambio táctico encada interfaz link.

Además, el Sistema LINPRO implementa el intercambio táctico de información a travésde redes SIMPLE, contemplando una red SIMPLE como un Data Link independiente.

Simulador para la reproducción de escenarios tácticos

La herramienta tiene el objetivo de poder reproducir en un entorno de laboratorio, esce-narios reales que se han llevado a cabo en maniobras u operaciones donde ha participado el

69

70 A. DOCUMENTO IBM DOORS

Sistema LINPRO y que han sido grabados mediante la herramienta de extracción de datosde LINPRO.

Esta herramienta permite depurar incidencias del Sistema LINPRO, reportadas por undeterminado buque, acompañando la incidencia con la grabación del escenario en el cual seregistró dicha incidencia. El simulador táctico estaría integrado en el Sistema LINPRO talcomo muestra la figura 1.2

El objetivo del software consiste en extraer la información registrada por el Sistema LIN-PRO en ficheros Data Extraction, eliminando toda la información de control añadida al fi-chero y obteniendo de esta manera los mensajes tácticos de cada una de las interfaces enbruto.

Una vez que se obtiene un mensaje táctico en bruto, se inyecta esa información al SistemaLINPRO a través de la interfaz SIMPLE implementada por el Sistema LINPRO y definidapor el STANAG 5602, con el fin de poder simular un escenario táctico concreto.

A.1.3 Descripción General del documento

La estructura del documento está desarrollada de acuerdo a la norma 498 Software Deve-lopment and Documentation.

Documentación de Referencia

STANAG 5602 - Standard Interface for Multiple Platform Link Evaluation (SIMPLE) -Edition 3.

A.2 RequisitosA.2.1 Requisitos de capacidad

Gestión de extracción de información

El primer objetivo consiste en la extracción de la información que se quiere procesar,almacenada en ficheros Data Extraction, del sistema de almacenamiento externo HMI (Hu-man Machine Interface). Este dispositivo de almacenamiento se comunica directamente conel Sistema LINPRO y permite la extracción y la inyección de información entre el propioSistema LINPRO y el HMI.

Los ficheros Data Extraction contienen la información táctica registrada tanto emitida co-mo recibida del Sistema LINPRO con las interfaces con las que se encuentra en contacto,como son las Interfaces Link y la Interfaz de Sistema de Mando y Control.

Los ficheros pueden estar en formato texto (.txt) o en formato binario (.bin).

El tipo de información que se va a extraer del sistema de almacenamiento será de ficherosasociados a las redes Link-11 y Link-16.

A. DOCUMENTO IBM DOORS 71

Extracción de ficheros

Se extraen los ficheros que contienen el conjunto de mensajes que ha intercambiado LIN-PRO con las interfaces tácticas. Se puede extraer como mínimo un fichero y como máximotres, uno por cada red Link. Un operador se encargará de realizar esta operación.

Formato ficheros

DX Mensajes Link-11

Mensajes recibidos de la interfaz táctica Link-11 en formato texto o formato binario.

DX Mensajes Link-16

Mensajes recibidos de la interfaz táctica Link-16 en formato texto o formato binario.

Reconstrucción del escenario táctico

Se tratarán los ficheros asociados a las redes Link con el fin de eliminar de cada mensajelos datos de control que se le han añadido a cada uno de ellos durante su generación, yobtener de esta manera los mensajes tácticos en bruto.

Recepción de ficheros

Una vez que se han obtenido los ficheros Data Extraction, se procede a seleccionar aque-llos que se consideren significativos.

Del conjunto de mensajes transmitidos (Tx) y recibidos (Rx) del fichero, solo se procesa-rán aquellos que tengan el campo ïndicador de transmisiónçon el valor Rx", lo que significaque el mensaje ha sido registrado como recibido.

Filtrado de información

El proceso de filtrado de información eliminará de los mensajes del fichero o ficheros, losdatos de control añadidos durante su generación, quedando en cada mensaje la informacióntáctica correspondiente con su hora de generación.

Este proceso se lleva a cabo con un control que pulsa un operador y que permite procesarel fichero.

Una vez realizada esta operación, se muestra en una ventana de la herramienta, la infor-mación procesada.

La información que contiene este fichero procesado representa la traza de los mensajes enla misma secuencia con la que fueron recibidos, de manera que se reproduzca fielmente alsistema real y pueda ser transmitido al Sistema LINPRO en el mismo orden reflejado por lasmarcas de tiempo.


Fichero de salida

Se puede guardar la información de los mensajes procesados junto con la hora en la quefue generado, en un nuevo fichero.

La acción de guardar en un nuevo fichero la lleva a cabo un operador, que podrá seleccionarel nombre que va a tener ese fichero de salida. Este fichero tendrá un formato específico. Sedescribe en gramática BNF.

Reproducción y análisis del escenario sobre el Sistema

A través de la interfaz externa SIMPLE, la herramienta se comunica con el Sistema LIN-PRO para inyectar la información procesada.

Cada una de las Interfaces Link tiene una estructura de mensajes propia, por lo que laInterfaz SIMPLE dispone de un conjunto de mecanismos específicos para poder intercambiarla información procedente de cada interfaz de datos tácticos con el Sistema LINPRO.

El formato de un Mensaje SIMPLE se estructura de la siguiente manera: Un MensajeSIMPLE contiene:

Protocolo de red

Dirección IP y puerto

Contenido del mensaje

El contenido del fichero procesado, pasará a ser enviado a la interfaz SIMPLE, mediantemensajes SIMPLE, cuando el operador pulse el botón de enviar.

Se enviarán los mensajes con las mismas marcas de tiempo con los que se han transmitido,representando así la traza de un ejercicio real, pudiendo reproducir exactamente el escenariotáctico con el fin de mejorar el Sistema LINPRO ante cualquier incidencia.

Operaciones de usuario

A continuación se detallan las operaciones que va a tener la interfaz con la que va a inter-actuar el operador.

Seleccionar

El sistema permitirá a su operador seleccionar uno o varios de los siguientes ficheros paraobtener la información deseada: - Fichero Link-11 y/o fichero Link-16.

Estará definido por un control, que será un botón que permitirá seleccionar el fichero/fi-cheros de una carpeta del sistema.

Si el operador selecciona el fichero Link-11, la información que obtendrá será: MensajesLink-11. Si el operador selecciona el fichero Link-16, la información que obtendrá será:Mensajes Link-16.

A. DOCUMENTO IBM DOORS 73

El operador podrá seleccionar varios ficheros y obtendrá los mensajes de cada uno de ellosrespectivamente.

Procesar

El operador, una vez con el/los fichero/ficheros seleccionados, utilizará la herramienta paraeliminar información de ellos.

Esta operación estará definida por un control que será un botón y pulsará el operador paraque se lleve a cabo el proceso.

Enviar

El control para enviar los mensajes generados a través de la interfaz SIMPLE al SistemaLINPRO, será un botón, que el operador pulsará. El operador seleccionará el fichero del quese quieren enviar los mensajes.

Otras operaciones

Además de las operaciones anteriormente descritas, también hay un conjunto de operacio-nes que se pueden realizar en la herramienta.

Guardar

El operador podrá guardar la información procesada en un nuevo fichero. Esta operaciónse lleva a cabo a través de un control que será un botón. Se guardará el fichero con un nombrey una extensión.

Parar

El operador puede parar la transmisión de mensajes a través de un control que será unbotón.

Reiniciar

El operador puede reiniciar la aplicación a través de un control que será un botón.

A.2.2 Requisitos de interfaces externasEl sistema está compuesto de las siguientes interfaces externas: Interfaz SIMPLE y dispo-

sitivo de almacenamiento.

Identificación de interfaces

Las interfaces externas la forman la herramienta a desarrollar "Simulador para la repro-ducción de escenarios tácticos", el Sistema LINPRO, un sistema de almacenamiento (quepuede ser cualquier dispositivo), y un operador.


Interfaz SIMPLE

La interfaz SIMPLE (Standard Interface for Multiple Platform Link Evaluation) está de-finida por el documento STANAG 5602 Ed 2, y especifica los protocolos necesarios paraestablecer enlaces tácticos basados en redes WAN / LAN entre diferentes procesadores dedatos tácticos. Los protocolos de enlace para una red WAN/LAN son UDP broadcast, UDPmulticast y TCP.

La información es transferida como paquetes a través de las redesWAN / LAN y puedeser: mensajes de enlaces tácticos, información sobre el escenario y entorno de operación, oinformación de pruebas de mantenimiento y control.

La interfaz SIMPLE puede encapsular mensajes de las redes Link-11, Link-16 y Link- 22,y es utilizada para ejercicios de interoperabilidad y pruebas.

Mediante mensajes SIMPLE, se mandará la información procesada en ficheros, desde laaplicación al Sistema LINPRO

Sistema de Almacenamiento

El sistema de almacenamiento será un dispositivo que contenga los ficheros DX que sonlos que ha generado el Sistema LINPRO con las interfaces tácticas. Este dispositivo podráser un disco duro, un pendrive, etc.

Los ficheros DX contienen el conjunto de mensajes Link-11(M), Link-16(J) y Link-22(FJ)que representan el escenario táctico almacenado por el Sistema LINPRO en un determinadoperíodo de tiempo.

Estos ficheros que recibirá la herramienta serán proporcionados por el mecanismo de ex-tracción de datos (DX) del Sistema LINPRO, que extraerá la información de las interfacesLink, y estarán compuestos por todos los mensajes, tanto recibidos como transmitidos decada una de ellos.

Operador

El operador es el encargado de interactuar con la aplicación.

Simulador para la reproducción de escenarios tácticos

El simulador para la reproducción de escenarios tácticos es la herramienta software.

Anexo B

Manual de Usuario

En este anexo se explica el manual de usuario de la herramienta.

B.1 ManualB.1.1 Pantalla de Inicio

En la Figura B.1 se muestra la pantalla de inicio de la herramienta.

Figura B.1: Boceto IU

75

76 B. MANUAL DE USUARIO

B.1.2 Abrir FicheroPara abrir un fichero se selecciona el botón de Abrir, y aparece la figura siguiente para

elegir el fichero deseado.


B.1.3 Abrir Fichero ProcesadoDe igual forma, se puede abrir un fichero procesado para su posterior envío.

B.1.4 GuardarPara guardar un fichero ya procesado, se selecciona el botón de Guardar, y aparece la

figura siguiente para guardar el fichero con el nombre que se desee.


B. MANUAL DE USUARIO 77

B.1.5 ProcesarA la hora de procesar un fichero, se selecciona el botón de Procesar, y aparece un mensaje

para indicar si se quiere continuar con el proceso.


B.1.6 EnviarPara el envío de los mensajes, hay que indicar un puerto y una dirección IP en las casillas

correspondientes, y luego seleccionar el botón Enviar.

B.1.7 PararSe puede parar el envío de mensajes seleccionando el botón de parar.

B.1.8 ReiniciarDe la misma manera se puede parar el envío de mensajes seleccionando el botón de reni-

ciar.


Este documento fue editado y tipografiado con LATEXempleando la clase arco-pfc que se puede encontrar en:

https://bitbucket.org/arco group/arco-pfc

https://bitbucket.org/arco_group/arco-pfc

Documents

SIMULADOR PARA LA REPRODUCCIÓN DE ESCENARIOS Tarco.esi.uclm.es/public/pfc/alicia.garcia.pdf · D ESDE hace siglos la supremacía tecnológica ha sido un factor importante en la con-secución