4.

GSS modulo AFDX

4.1 Introducción

Como ya he comentado en el apartado anterior el modulo de GSS referente a

AFDX fue desarrollado en Sevilla, y mi tarea fue desarrollar alguna de las
herramientas referentes a este modulo. Primero y para hacer el contexto del
modulo hablaremos de las herramientas realizadas por el resto de
componentes de la empresa y a continuación procederé a analizar una a una
las herramientas realizadas por mi y explicar tanto su función como la manera
de programarlas, intentare a su vez explicar los problemas que sobrevinieron
con cada una de estas herramientas. Añadiré por ultimo el código fuente de
alguna de las herramientas para ver un ejemplo de cómo programar en delphi.

Comentar que el código fuente asociado a AFDX se distribuye en dos grupos

principalmente, uno los códigos que identifican a herramientas que se agrupa
en la carpeta AFDX_Tools, y otro grupo que se refiere a las funciones que van
asociadas a distintos tipos de datos, en las que podemos encontrarnos por
ejemplo un archivo con el nombre de UDPPortConfig.pas en el que
encontramos todas las funciones asociadas al tipo UDPPortConfig.

4.2 Herramientas previas del programa

El guión de diseño de este programa nos fue dado desde la sede central
inglesa de GSS. Evidentemente las herramientas debían ser parecidas a las
usadas para los otros protocolos, y la forma de programarlas debería ser
similar a las ya realizadas para que pudiera formar parte de un “todo” que será
el programa GSS100.

86
En el proceso de diseño la herramienta que posee el control general de todo el
proceso es Stack Record Tool ya que es desde aquí donde gestionamos el
proceso de grabación de las tramas que nos van llegando, es desde aquí
también donde controlamos la posibilidad de abrir la herramienta con la que
podemos configurar los filtros y de cargar archivos guardados previamente con
posibles filtros o sistemas completos junto con pilas de mensajes que hayan
sido grabados con anterioridad. Esta herramienta es bastante simple ya que
solo se trata de gestionar un botón que aparece en la pantalla y conseguir que
al pulsarlo el equipo comience a grabar mientras que si pulsamos el botón de
stop el equipo deje de almacenar. El proceso de grabado y almacenaje se hace
basándose en las herramientas de canal que estaban hechas previamente de
los anteriores protocolos, no hay diferencia entre almacenar tramas de
ARINC429 que almacenar tramas de AFDX la diferencia es el modo de
tratarlas, que se vera a continuación.

4.2.1 Stack Control Tool

53 Herramienta Stack Control

87
Desde esta herramienta debemos también crear las instancias de los filtros ya
que es aquí donde se inicializan, posteriormente en la herramienta de filtros
explicaremos más su funcionamiento y el modo de operar de estos filtros.

4.2.2 Stack List Tool

A continuación hablaremos de la herramienta que nos permite gestionar la pila

de mensajes, el Stack List Tool donde podemos ver una lista de todas las
tramas almacenadas con detalles de las mismas. En su uso esta herramienta
también es muy sencilla ya que solo intenta servir de lista de los mensajes.

En cuanto a su realización es bastante mas compleja que la herramienta

anterior, ya que los mensajes son almacenados en una estructura llamada
árbol virtual para luego poder recorrer el árbol, este árbol se usa como una
cadena y cada nodo del árbol tiene un formato previsto, que se ha de rellenar
debidamente según cada trama que llega. Para identificar cada trama tenemos
una identidad que nos sirve para conocer tanto el destino de la trama como el
origen. El formato será el siguiente, primero veremos el End System de origen,
a su lado el Virtual Link y el puerto. A continuación vemos el destino, vemos su
End System y el puerto de destino. Podemos ver algunas identidades en la
captura de pantalla del programa siguiente.

54 Herramienta Stack List

88
En estos nodos hay un campo para el End System, para el Virtual Link y así
para todos los detalles del enlace. Con esto se crea un sistema de almacén de
datos, sabiendo todos los datos del enlace podemos rellenar este árbol y tener
una base de datos con todos los sistemas y así saber si los mensajes que nos
llegan son de sistemas esperados o simplemente sistemas nuevos. En cada
columna se hace un análisis de errores y las tramas erróneas se resaltan en un
color distinto para que se sepa que trama es la errónea.

4.2.3 Activity Tool

La siguiente de las herramientas, sin comentar las realizadas por mi, será la
herramienta de Activity Tool que es donde podemos ver todo el trafico que
nuestro equipo ha ido escuchando en este bus, en el caso que utilicemos una
red que este conectada a la red de Internet escuchara todas las transacciones
que se hagan para entrar a alguna pagina y estas también quedaran reflejadas,
tanto aquí como en la pila de mensajes podremos ver estas tramas. En la
pantalla principal en esta herramienta veremos un árbol con todo la estructura
de End Systems, particiones, puertos, etc… y con el número de tramas y bytes
que han llegado a cada uno. Podemos guardar todo este tráfico y podemos
cargar tráfico que haya sido previamente guardado.

89
 55 Herramienta Activity

La forma de diseñar esta herramienta fue comenzar por imprimir toda la

estructura de nodos de la que hemos hablado en herramientas anteriores, de
forma que fuera visible todo el tráfico que hemos recibido. El problema ahora
es conseguir que todas las tramas que van llegando vayan siendo
contabilizadas para lo cual lo primero es buscar si los datos del mensaje ya
están en nuestra base de datos, sino esta creamos una entrada nueva, si ya
esta actualizamos el contador de mensajes recibidos y el contador de bytes.
Debemos tener una tasa de refresco muy alta para que el usuario tenga una
información veraz. A su vez el cuando seleccionamos un puerto en concreto
todos los datos de este, deben ser almacenados ya que esta herramienta sirve
como selección de la herramienta Live Monitor en la que podremos ver los
últimos datos que han llegado a este puerto, con algunos condicionantes. Por
ello deberemos tener un pequeño buffer para almacenar el último mensaje que
nos ha llegado a cada puerto para poder mostrarlo en pantalla.

90
 56 Herramienta Activity con errores

Esta herramienta también lee de la estructura de mensajes que esperamos ya

que se puede configurar el equipo para esperar mensajes de un determinado
puerto (cada vez que hablemos de puertos conlleva hablar de un End System,
Partición, Virtual Link, etc…) , de este modo tenemos que hacer una
comparación entre los mensajes que han llegado y los que esperábamos y si el
usuario quiere, mostrarlos en pantalla mediante un código de colores junto a
unas palabras clave (unexpected o missing) los que han llegado y no
esperábamos o los que no han llegado y esperamos. Todo esto lo podemos ver
en la figura anterior.

Si en alguno de estos puertos ha ocurrido algún error también lo

identificaremos mediante colores. A partir de ahora identificaremos el color de
error como rosa, y el color de error subsanado como verde.

4.2.4 Configuration Tool / Message Structure Tool

En las dos herramientas que nos quedan por comentar tenemos los útiles para
configurar la estructura de mensaje que podemos enviar o recibir, estructurar
los datos o configurar los datasets que nos van a llegar o vamos a enviar. A su
vez estas herramientas nos dan la posibilidad de configurar el sistema de
puertos que esperamos recibir y así tener perfectamente definido cada uno de
los envíos que vamos a tener.

91
 57 Herramienta Configuration

Reseñar que podemos definir la longitud de los datos y que tipo de primitivas
vamos a tener. En la sección que explica el protocolo, podemos ver el tipo de
datos que podemos tener, de todos modos en la sección baja tenemos todo
tipo de datos que podemos encontrar en las primitivas.

58 Herramienta Message Structure

92
Para programar esta herramienta comenzamos por buscar si ya hay alguna
estructura de datos realizada y vamos comprobando las compatibilidades y las
longitudes para que todo sea correcto, una vez hecho esto procedemos igual
con las que vamos creando. Para configurar el sistema global hacemos algo
parecido, tras comprobar la configuración establecida procedemos a comprobar
que todo es correcto (los valores no se salen de rango) y a permitir unos
nuevos puertos. Creo que no ha quedado suficientemente claro la forma de
almacenar los valores de los puertos, los End Systems, las particiones, etc…
Tomamos primero el End System, guardamos todos los valores que tengamos
cada uno en una estructura diferente con punteros al siguiente End System y
también un puntero a una lista de los Virtual Links que tiene asociados, estos
se almacenan igualmente y así sucesivamente. Por lo tanto cuando vamos
recorriendo toda la estructura comenzamos por el primer End System y vamos
leyendo todos los datos asociados (virtual links, particiones y puertos) y así
sucesivamente hasta que encontremos lo que necesitamos o bien lleguemos al
final de la estructura.

A partir de aquí nos centraremos en las herramientas que han sido diseñadas
por mi.

4.3 Modo de realización de las herramientas

Para la realización de cada una de las herramientas seguí un procedimiento
más o menos estándar, el cual voy a describir a continuación.

 Primero procedemos a estudiar el protocolo en cuanto a la interacción

del protocolo con esta herramienta. Debemos saber que es lo que
tendremos que analizar del protocolo, y que cualidades tiene este
protocolo para esta herramienta.
 Un ejemplo podría ser, en la herramienta de filtros, debemos buscar en
el protocolo para saber las categorías que podemos aplicar en el filtro.

93
  A continuación debemos buscar en la plataforma GSS100 las
posibilidades que nos da para cumplimentar esta herramienta, este
punto del procedimiento es una base del algoritmo que debemos crear a
continuación.
 El siguiente paso será diseñar el algoritmo mediante el cual la
herramienta pueda hacer la función que requiramos, para esto debemos
saber las funcionalidades que tenemos en GSS100 en caso que nos
falte alguna definimos nuevas funciones generales o incluso nuevos
tipos.
 Pasamos a continuación a crear el código de la herramienta.
 Por último debemos integrar la herramienta junto con el resto de la
plataforma, comprobar que el funcionamiento es el adecuado y depurar
cualquier posible error que pueda surgir.

4.4 Herramientas del programa

4.4.1 Controlador de filtros (Filter Manager Tool)

La herramienta Filter Manager ha sido diseñada para poder editar cada uno de
los filtros o disparadores (triggers) que pueden ser diseñados para lanzar una
de las siguientes acciones, podremos hacer que el dispositivo comience a
grabar, bien pare de grabar o bien solo nos lleve al próximo filtro. Para lanzar
esta herramienta debemos hacerlo desde la pantalla de la herramienta de
Stack Control y como hemos comentado antes es en esta herramienta donde
debemos inicializar cada filtro. En la captura de pantalla a continuación
podemos ver gráficamente esta herramienta, reseñar que aunque no se ve en
esta en el árbol de valores que podemos tomar para hacer el filtro veríamos
también el conjunto de señales que tuviéramos en el sistema.

94
 59 Herramienta Filter DIalog

Recorramos con detenimiento este formato (form). Lo primero que nos

encontramos, comenzando desde arriba, es el campo name lo que realizamos
en una herramienta del tipo Edit, y la controlamos desde la función
ShowTheForm; esta función es llamada desde el Stack Control al pulsar el
botón de modificar filtro y lo que hace es comprobar el numero de señales que
tenemos en el registro Watched, que son las señales que han sido utilizadas, y
comprobar cuando pulsamos el botón de OK si la cadena esta bien construida
y si los valores de siguiente filtro existe para que el programa no se quede en
un bucle infinito. Mostraremos esta función como ejemplo en el anexo, punto 1.

Siguiendo el formato de la función nos encontramos con el árbol de valores que

podemos añadir al filtro, recordemos que en este árbol tendríamos señales
también, cada uno de estos valores tienen un formato distinto de forma que el
filtro debe estar bien construido y las igualdades deben ser coherentes, y así
tenemos que la dirección MAC debe ser de caracteres hexadecimales y así
sucesivamente. De este árbol podemos tomar todos los valores que queramos,
tanto arrastrándolos (drag and drop) como haciendo doble click sobre ellos.
Cada uno de los valores que tengamos deberán formar parte de alguna

95
comparación, para hacerlas debemos hacer click en alguno de los botones que
tenemos debajo de la cadena de caracteres que es el filtro y darle algún valor
coherente como ya hemos dicho antes.

Quizás la parte más importante de esta herramienta es la forma de hacer las

comparaciones. Estas deben ser extremadamente rápidas ya que cada trama
que llegue debe ser comprobada. Las comparaciones se hacen a nivel de bit
con una herramienta llamada BPF, esta herramienta es un paquete de
herramientas a las que dándole la posición dentro de la trama del campo que
queremos comparar junto con el valor a comparar y mediante estas
herramientas la función apropiada nos dirá si es mayor, menor o igual y
pasándole este dato al filtro tendremos la condición apropiada para nuestro
filtro. Este fue el mayor problema que tuvimos al desarrollar esta herramienta
para la que fue necesaria la ayuda de varios componentes de la empresa, para
buscar un paquete de herramientas lo suficientemente rápido y para hacerse
con estas herramientas buscadas. Una vez lo conseguimos, el encargo de
comprobar que las cadenas de estos filtros fueran correctos fue hecho a mi, y
mía fue la labor de programarlo y probar que su funcionamiento era el correcto.
Una vez conseguido la tarea era comprobar que la tarea programada se
cumplía al activar el filtro, lo cual tras hacer muchas pruebas para ver que la
herramienta de comparación funcionaba correctamente.

Una vez pasadas todas las pruebas la herramienta estaba preparada para ser
introducida en todo el sistema.

4.4.2 Detalles del mensaje (Message Details Tool)

En esta herramienta es donde vemos desglosados todos los campos de los

que consiste la trama. En estos campos también incluimos todas las cabeceras
que se visualizan por separado y con la posibilidad de ser eliminados. Esta
herramienta es de suma importancia ya que es aquí donde podemos estudiar la
trama y a su vez mediante su mecanismo de detección de errores, cada uno de
los campos que tenemos en esta herramienta se vera resaltado en el color de

96
error cada uno de los campos que no sean coherentes con el resto del
mensaje.

60 Herramienta Message Details

Esta herramienta esta controlada por el Stack List Tool ya que es desde ahí
donde podemos elegir el mensaje a mostrar. En cada mensaje podemos ver los
campos de cada una de las cabeceras y la estructura de mensaje, cada vez
que seleccionamos un campo de esta herramienta se destaca los bytes que
correspondan a este campo en el mensaje. La parte baja de la pantalla son los
caracteres del mensaje en hexadecimal y en código ASCII. Cuando recibimos
alguna trama con algún campo de error, se resalta, como ya hemos comentado
antes, lo que podemos ver en la siguiente figura.

97
 61 Herramienta Message Details con errores

En todas las herramientas en las que se utilizan tanto las primitivas como las
estructuras de mensaje deben ser creados unos registros para que se vuelvan
a crear referencias a estas estructuras y puedan ser tratadas debidamente. A
su vez en todas las herramientas que utilizan actualizaciones periódicas existe
una función llamada DoDisplayUpdate que es controlada por Delphi mediante
una serie de temporizadores y que se llama automáticamente cada cierto
tiempo, predefinido por el usuario, y es desde ahí donde se refresca la
herramienta. Vamos a adjuntar el código de esta función para comentarla
profundamente ya que es un buen ejemplo de una función de refresco,
encontramos el código en el anexo, punto 2.

Como podemos ver, esta función se basa en varias funciones de GSS100, esto
se debe a que un programa basado en módulos como este tiene un núcleo que
en el que se encuentran las funciones básicas como el control de canal o
control de grabación. Por otra parte con el anterior código podemos ver la
forma de programar en Delphi.

98
Una vez controlado el tema de la actualizaciones pasamos a construir el árbol,
antes de darle valores tenemos que inicializarlo y decirle el numero de nodos o
ramas que va a tener. En esta situación es fácil ya que las cabeceras serán
siempre iguales con los mismos campos, la dificultad vendrá con las
estructuras de mensajes para lo que necesitamos referenciarlas como ya
hemos comentado antes.

Cuando tengamos creado el árbol correctamente tenemos que ir dándole

valores a cada uno de estos nodos. Como tenemos el mensaje solo es cuestión
de saber el protocolo y saber donde buscar la información dentro de la trama.
Los campos que son variables tenemos que buscarlos basándonos en otras
informaciones y así sabiendo los bits de datos que tiene la trama sabemos
como encasillarla debidamente. En los campos en que errores sean posibles
tenemos que chequear si estos han existido; en algunas ocasiones esta
comprobación es trivial, simplemente comprobar que el dato esta entre unos
limites dados, pero en otras ocasiones, como por ejemplo en el checksum esta
comprobación requiere una función a parte de la que adjuntamos el código en
el anexo, punto 3.

Tenemos un puntero a la zona de memoria donde esta almacenada la

cabecera IP, vamos copiando toda la cabecera en conjuntos de palabras sin
importarnos que campo se trate y una vez lo tengamos en una tabla se lo
pasamos a la función que calcula el checksum y comprobamos que sea igual,
el checksum es una suma en complemento a dos de todas las palabras que
componen la cabecera.

En cuanto al código restante solo nos queda destacar el control de cada uno de
los botones que tenemos en la forma así como los CheckBox, que son cada
uno de los campos en los que podemos cliquear y aparece un tick para ser
activado. Destacar por ultimo que junto a cada una de las primitivas que
aparecen en la estructura de mensajes, señales, aparece el valor de estas.

99
4.4.3 Visión en vivo (Live Monitor Tool)

Esta es una herramienta polivalente ya que en ella podemos ver tantos los
datos recibidos como los datos a enviar. La función principal de esta
herramienta, ya sea como receptor o como transmisor es poder ver los datos y
poder ver las estructuras de mensajes con los datos. Llegados a este punto
cabe preguntarse que nos aporta esta herramienta si ya podíamos ver los
datos en la anterior, y es que utilizando esta que estamos comentando
podemos ver la evolución de los datos en un determinado puerto, por lo que
podríamos decir que sirve para comprobar los datos en un puerto mientras que
la anterior servia para comprobar los datos de una trama.

62 Herramienta Live Monitor versión receptor

Esta herramienta se puede lanzar tanto por los cauces normales en la barra de
herramientas de GSS100 o en el transmisor cuando pulsamos para cambiar los
datos a transmitir. Si es en datos recibidos, para seleccionar el puerto debemos

100
seleccionarlo en la herramienta Activity. En el caso de recepción será el puerto
que tengamos señalado en la herramienta del transmisor. Podemos diferenciar
si estamos en datos transmitidos o datos recibidos por el radio group que
tenemos en la parte alta de la forma, o también por la identidad que se nos
muestra en el campo Edit justo encima del árbol de datos. Este árbol podemos
elegir si se muestra o no mediante un CheckBox que tenemos en la parte alta.
Vemos una captura de pantalla en el caso que tuviéramos la herramienta como
transmisor.

63 Herramienta Live Monitor versión transmisor

En la anterior captura de pantalla vemos como hemos modificado los datos, y

estos están resaltados. Por otra parte no hemos activado la opción de incluir la
estructura de mensaje así que solo vemos los datos. Comentar también que la
identidad del mensaje nos dice que el origen es el End System 175.15, el
Virtual Link es 8920 y el puerto el 7. La partición no se incluye ya que solo se
permite una partición por puerto.

Destacar la diferencia entre la opción No Updates y la opción Pause Updates.

En la primera por mas que cambiemos de puerto tanto en la herramienta

101
Activity como en el transmisor los datos que vemos no cambiaran, a no ser que
llegue un nuevo mensaje en cuyo caso los datos si se actualizan. Justo esa es
la diferencia con la segunda, ya que en el caso que Pause Updates este
activado solo se vera la ultima información que haya llegado al puerto y no se
actualizara esta, pero si podremos cambiar de puerto.

En esta herramienta también tenemos que ir actualizando, como hemos venido

explicando de modo que necesitaremos una función que sea DoDisplayUpdate,
en esta tendremos funciones distintas según la función de esta herramienta sea
transmisor o receptor y según esta elección las acciones a realizar serán
diferentes aunque parecidas, ya que en todos los casos debemos mostrar los
datos en pantalla, lo que cambiara será la posibilidad de poder cambiar estos
datos o no poder hacerlo.

Como también comentamos antes todas las herramientas que necesiten

construir un árbol con estructura de mensaje debían introducir una serie de
funciones establecidas que nos sirven para referenciar las estructuras referidas
a los puertos. Nos centraremos en explicar estas funciones a continuación. Los
códigos los encontramos en el anexo, puntos 4 y 5.

Como vemos estas funciones trabajan dentro de un conjunto, y una vez creado
el nodo superior (All Node) vamos creando sus respectivos hijos según sea
conveniente y cada función va llamando a la sucesiva. A parte de estas que
mostramos también hay una función para las primitivas, y para las
subprimitivas. El funcionamiento de este código esta bastante claro. Vamos
recorriendo los datos de cada nodo sabiendo si tiene hijos o no y en función de
la respuesta vamos creando cada uno de ellos. A la función que va creando los
hijos tenemos que pasarle una referencia del nodo superior. Vemos que hemos
creado una variable del tipo MsgStructureConfig que es el registro que hemos
estado hablando y en el podemos almacenar todos los valores y además
tenemos funciones que se usan repetidas veces en estos registros tales como
buscar hijos, o crearlos. Como vemos esta función no se destaca por su
complejidad pero me parecía bueno destacarlo para ver como se realiza el
tratamiento de las primitivas.

102
Todas estas herramientas que tienen datos en estructuras de mensajes
necesitan una función que maneje el refresco del árbol de datos. En este caso
se llama RefreshStructure y como ya hemos comentado antes encontramos el
código en el anexo 5.

Esta función es bastante extensa pese a lo cual no es compleja ya que se va

repitiendo prácticamente el mismo código para cada una de las opciones,
según sea el nodo. Como podemos ver lo que va realizando esta función es
recorrer el árbol comprobando que los datos que se muestran son los correctos
y si deben ser añadidos o borrados algunos de ellos. Como vemos por ejemplo
en el caso de DataSet comprobamos que en los datos del nodo le
correspondería alguna primitiva, si es así comprobamos si ya la tiene asociada
sino la creamos, y así sucesivamente.

Por ultimo creo que es conveniente destacar que cada vez que seleccionamos
una primitiva esta se destaca en el campo de datos. Para esto utilizamos la
función ligthselected cuyo código podemos ver en el anexo, punto 6.
Vemos que cada vez que una primitiva es seleccionada en el árbol, tiene que
ser primitiva sino nada se selecciona en la trama, comprobamos su dimensión
y resaltamos toda ella en la trama, hacemos lo mismo para las subprimitivas.
Este ejemplo de función nos sirve para ilustrar la forma de trabajar con los
editores de datos (HexEditor).

Comentar para terminar con esta herramienta que dentro del árbol con la
estructura de mensaje cada nodo debe tener unos datos coherentes respecto
al tipo de nodo que sea, de este modo vamos dando uno por uno estos datos
que posteriormente aparecerán en pantalla, tales como type, length, etc …

4.4.4 Transmisor (Transmitter Tool)

Junto con las herramientas propias de sniffer de red, con las que podemos ver
lo que esta pasando por nuestro bus y analizar las tramas, tenemos las

103
siguientes herramientas que nos permiten enviar una serie de tramas ya sea
para este u otro equipo, que nos sirve para probar equipos ante emisiones
erróneas o simplemente para saber el comportamiento del equipo ante una
transmisión normal.

Para iniciar una transmisión debemos crear una transacción nueva,

posteriormente vamos dándole los datos respectivos que queramos que tenga,
así como el destino y el origen que queremos que aparezca, estos datos de
origen serán los que tengamos en otras herramientas como Activity. Si
queremos modificar los datos a enviar lo podemos hacer mediante un acceso
directo en cada transacción al igual que si queremos añadir algún error a la
trama.

64 Herramienta Transmitter

Como podemos ver se trata de una tabla (grid) en la que tenemos una serie de
columnas que deben ser implementadas por todas las transacciones, para
programar esto vemos que lo mas sencillo es crear un registro para cada una
de las transacciones, que será inicializado al crear una nueva transacción en su
debido botón, e ir rellenando cada uno de los campos. Cada uno de estos
tendrá una serie de restricciones que no se pueden dejar de cumplir de modo
que al intentar cambiar estos valores antes de que estos cambios sean
definitivos se debe comprobar por ejemplo que el valor del puerto no supera el
255 y algunas otras restricciones que se pueden consultar en el protocolo.
Como podemos ver en la anterior captura de pantalla, tenemos en la columna

104
Data una serie de botones que son los que nos permiten acceder al cambio de
datos a enviar, y a su vez la columna de ErrorInyect que es la que lanza la
herramienta de inyección de errores que comentaremos mas tarde.

En cuanto a la programación lo primero que debemos hacer es crear la tabla,

que una vez creada debe crear cada uno de los campos que debemos rellenar,
a esto llamamos inicializar cada uno de estos registros. Los valores por defecto
son los mínimos, aunque dicho esto tenemos que destacar que no puede haber
dos transacciones que tengan el mismo origen exacto por lo que cada vez que
creamos una nueva transacción el puerto se incrementa en una unidad. En la
creación de cada una de las celdas que compone esta tabla debemos también
tener en cuenta cuales de estas pueden ser editadas y cuales no. Por supuesto
como hemos comentado antes en esta herramienta también tendremos una
función de DoDisplayUpdate que nos servirá para que los datos que veamos en
pantalla sean datos reales y actuales. A la hora de ir recorriendo esta tabla se
trata como si fuera un árbol, esto hay que tenerlo en cuenta a la hora de crear
los registros. Como hemos comentado los valores por defecto al crear una
transacción son los mínimos, comentamos a continuación la función que realiza
esta operación, el código de esta función lo podemos localizar en el anexo,
punto 7.

Podemos ver como primero buscamos si el End System 1.0 ha sido creado con
anterioridad sino ha sido así lo creamos en ese momento. Si ya ha sido creado
lo único que tenemos que hacer es coger ese registro y comprobar que el
virtual link también es el correcto y así hasta llegar al puerto. Por ultimo, una
vez creados todos los nodos correctamente pasamos a dar los valores en la
tabla. En otras funciones en esta misma herramienta procedemos a enviar las
tramas mediante una función del núcleo de GSS100 llamada send, que es una
función del canal. Cada vez que cambiamos alguno de los valores de cada
transacción, tenemos que cambiar la base de datos de los puertos que hemos
creado en la función que contamos arriba, y también deberemos borrar el
antiguo registro con los datos anteriores.

105
Cuando cambiamos alguna celda, como hemos dicho antes, debemos validar
los nuevos datos para que estos sean definitivos. La función en la que
realizamos estos actos es SenderTreeNewText y su código esta con el resto de
códigos en el anexo, punto 8.

Vemos como vamos recorriendo columna por columna poniendo las

restricciones, en los casos en que estas restricciones se pasen entonces se
llama a las rutinas que comentábamos antes que son las que cambian los
valores en la base de datos. La columna de la constante MAC vemos que
puede ser cambiada pero se realiza mediante una serie de rutinas de forma
que no se puede poner la que uno quiera. Poco mas queda destacar de esta
herramienta, simplemente que las tasas de transmisión están en milisegundos
ya que es 1 milisegundo la tasa mínima de transmisión que nos permite el
programa.

Las dos herramientas que nos quedan por comentar son ambas basadas en la
transmisión, pasamos a comentarlas a continuación.

4.4.5 Inyección de errores (Transaction Error Injection Tool)

Esta herramienta es muy practica a la hora de probar equipos, ya que podemos

hacer test y saber como responden estos equipos cuando reciben tramas
erróneas. En principio los equipos deben detectar estos errores y descartar las
tramas; en el analizador sin embargo podemos ver las tramas erróneas y saber
donde esta el error. Tenemos varios campos en los que añadir el error a la
trama, lo vemos en la siguiente captura de pantalla.

106
 65 Herramienta Error Injection

Los seis primeros CheckBox se tratan de añadir errores a la cabecera IP, se

podrían añadir más errores pero en ese caso el analizador no procesa las
tramas que por ejemplo no cumplen algunas reglas básicas de la cabecera IP.
Como la cabecera UDP tiene menos campos también traemos menos errores.
El manejo de la inyección de errores se trata en el momento que se encapsulan
los datos, se comprueba que errores de la lista han sido activados y se actúa
en consonancia. Para ofrecer un ejemplo del código en esta herramienta
mostraremos como se procede una vez pulsamos el botón OK. Para ver el
código de esta función llamada OKBtnClick debemos dirigirnos al anexo, punto
9.

Como vemos vamos comprobando cada CheckBox si esta activado o no y si

esta activado se lo pasamos al resto del programa mediante una variable. Esta
función es bastante simple, así que añadiremos la función en la que se dan los
valores de error aunque no pertenezca totalmente a esta herramienta sino a
una de los archivos con funciones auxiliares en el anexo, punto 10.

En esta función ya disponemos del paquete que vamos a mandar y sabemos la

posición de cada uno de los campos de modo que vamos cambiando uno a uno
en función de si habíamos activado cada uno de los errores anteriormente. Al

107
inicio de la función damos los valores de las posiciones para que luego el
código pueda ser más fácil de leer.

El programa GSS100 esta en un proceso de mejora continuo añadiendo

nuevas funcionalidades entre las que esta proyectado añadir nuevos tipos de
errores, por ejemplo en las señales que se transmiten.

4.4.6 Reemisión (Replay Tool)

Esta es la ultima herramienta que vamos a comentar en profundidad. Esta se

usa para repetir una serie de envíos realizados con anterioridad, y así podemos
repetir una determinada actitud de un equipo, esta herramienta también se usa
para hacer pruebas o para sacar conclusiones sobre equipos.

66 Herramienta Replay

Como podemos ver en la captura de pantalla el funcionamiento de esta

herramienta es muy intuitivo ya que diciéndole a partir de que entrada y hasta
que entrada (del Stack List) quieres repetir su emisión, simplemente esta
comienza a reemitirse. En cuando a la tasa de emisión de la repetición
tenemos tres opciones, o bien según los hayamos recibido respetando los
tiempos de captura (recorded timestamps), o bien transmitimos a la máxima

108
velocidad posible (max network speed) o bien podemos definir una tasa para
este reenvío (custom period).

En cuanto a la programación destacar que como en otras herramientas que

hemos comentado antes, en esta también tenemos una función de
DoDisplayUpdate, para verificar los datos periódicamente. El reenvío también
tiene una función dentro del núcleo de GSS100 ya que se utiliza también para
los otros protocolos, de este modo dentro del grupo Channel tenemos una
opción de Replan, como podremos ver en el código siguiente. Para el
funcionamiento del resto de la herramienta solo decir que según la tasa se
programa el envío y se procede exactamente igual que en una transmisión
normal que ya hemos explicado en el transmisor. Destacar que la pila de
tramas de la que se lee tiene que ser salvada previamente y cargada en esta
herramienta. En el anexo, punto 11, tenemos el código con el cual se abre
estos archivos.

Primero ofrecemos la oportunidad de elegir algún tipo de archivo que sea de la

extensión cap que es en la que salvamos las pilas de mensajes. Si el archivo
es correcto se le dan los valores por defecto que son 0 para la primera trama y
la más alta para la última. En caso que el fichero no sea correcto todos tendrán
el mismo valor, 0. Nada más a destacar de esta herramienta.

4.5 Conclusiones

Para concluir destacar que a parte de estas herramientas enumeradas otros

muchos arreglos realizados a este programa corrieron por mí cuenta pero no
creo que sea necesario enumerar todas las funciones realizadas. Volver a
destacar que tanto el punto 4.3 como el 4.4 describe al completo el trabajo
realizado por mi, de modo que todas las herramientas son de mi creación al
igual que todo el código que he añadido como muestra de mis operaciones.
Espero que haya quedado claro todo el trabajo realizado durante estos meses.

109