CAPÍTULO II

EL PROBLEMA

2.1.- Planteamiento del Problema

En toda empresa de servicios, la más importante premisa es ofrecer la mejor

asistencia al cliente, esto se logra garantizando una disponibilidad continua, evitando

cortes innecesarios del servicio y ofreciendo una calidad superior a cualquier otro

competidor. Para alcanzar todo esto se debe desplegar una infraestructura donde se

puedan encontrar: sistemas de gestión, personal técnico y profesional calificado,

apoyo de otras empresas de servicios públicos (electricidad, agua, gas), sistemas de

comunicación, apoyo técnico, entre otros, con la finalidad de contar con una

planificación y organización acorde con la filosofía de una empresa de servicios.

A pesar de todas la previsiones que se puedan tomar en algún momento se

presentan fallas que afectan de una u otra manera a los clientes, estas fallas pueden

ser significativas o solo son avisos preventivos de que algún problema está por

producirse. Una vez que se presentan las fallas, es necesario que el personal

calificado sea notificado para que en el menor tiempo posible atiendan y den solución

al problema, logrando de esta forma que la interrupción del servio al cliente sea lo

mas corta posible. Las empresas que ofrecen servicios de comunicaciones, ya sean en

telefonía fija o celular tienen especial cuidado en mantener siempre un servicio

eficiente, de esta forma se captarán nuevos clientes y nunca perderán los clientes con

los que ya cuentan.

La red GSM de la Corporación consta de múltiples equipos y elementos, que

integran el BSS y la red de transmisión, los cuales se interrelacionan entre sí, para que

el proceso de comunicación se establezca satisfactoriamente.

24

Para el caso específico de los elementos del BSS, todos sus componentes (BTSE,

BSC y TRAU) son continuamente monitorizados por el Sistema de Gestión y

Supervisión OMC-B, en donde se registran y muestran todos los eventos que se van

presentando en la red en tiempo real; el OMC-B es continuamente vigilado por un

operador, que es el encargado de interactuar con el sistema y ejecutar las acciones

necesarias para enfrentar las circunstancias que se presentan en el BSS. El operador

posee los conocimientos necesarios y actualizados sobre la estructura de la red, los

tipos y clases de componentes que la integran, los procedimientos y acciones

necesarios para ayudar a subsanar las fallas presentadas. Si a todo esto agregamos el

gran crecimiento que ha tenido el BSS de la red GSM de la Corporación en la Región

Central en el último año y medio, así como también la posibilidad de que ocurra una

falla generalizada en donde se encuentren involucrados varios componentes de BSS,

el trabajo del operador es exigente, tornándose en ciertas ocasiones extenuante, todo

esto sin contar con el agotamiento visual que produce estar observando por varias

horas consecutivas la interface visual del OMC-B en un monitor de computadora.

Es así como surge la necesidad de desarrollar una herramienta que asista y ayude

al operador del OMC-B en todo momento, minimizando en gran medida el error

humano que puede surgir por diversos factores y condiciones, además de contribuir

en la automatización paulatina de los procesos de notificación y comunicación de

fallas del BSS de la red GSM de la Corporación.

Otra de las desventajas del OMC-B es la carencia de interfaces amigables de

donde se pueda extraer la información que éste posee, dado que allí se encuentran

registrados todos los eventos que se presentaron en la red. Si esta información es

filtrada y acondicionada adecuadamente, se pueden desarrollar dentro de una

herramienta, reportes e informes que en manos del personal adecuado, como

supervisores o gerentes de la Gerencia Líder de O&M Región Central indicarían: el

número de veces que ocurre una alarma específica, se realizaría el seguimiento de las

fallas, se podrían obtener parámetros para realizar mantenimientos preventivos,

25

estudiar fallas e incluso indicar al proveedor de los equipos fallas recurrentes, para

que sean estudiadas por el personal especializado.

Debido a lo señalado anteriormente se diseñó e implementó, bajo la plataforma

Windows un sistema que se denominó COFADI-rc (Comunicación de Fallas de

DIGITEL – Región Central) capaz de identificar, clasificar y comunicar la ocurrencia

de fallas del BSS en la red GSM de la Corporación, al personal de la Gerencia de

Mantenimiento de Campo correspondiente, con el fin de facilitar el trabajo del

operador del OMC-B, así como mantener continuamente informado al personal de las

fallas que ocurren en la red GSM de la Corporación, además de generar reportes o

informes de las alarmas que se presenten en el BSS, para se posterior estudio por

parte de los supervisores y gerentes.

2.2.- Fases de la Investigación

El desarrollo del trabajo cubrío por las siguientes fases o etapas:

Fase 1: Estudio y Documentación.

En esta primera etapa se estudió la estructura y elementos que constituyen la red

GSM, específicamente el Subsistema de Estaciones Base (BSS), ya que son

precisamente las fallas que allí ocurren las que notifica el sistema COFADI-rc. Al

mismo tiempo, se estudió la estructura, funcionamiento y datos contenidos en el

sistema de gestión OMC-B, pues de aquí se obtienen los datos que se manipulan para

que COFADI_rc funcione satisfactoriamente. Es conveniente destacar que el sistema

sólo notifica las alarmas activas en los equipos o elementos de el BSS. También se

realizó una revisión bibliográfica y posteriormente se experimentó con el lenguaje de

programación de alto nivel Visual Basic, el cual se utilizó para desarrollar e

implementar el sistema COFADI_rc; se estudiaron sus comandos, módulos, formas

de programación, objetos propios del programa, estructura de programación,

estructuras de control y toma de decisión. Para guardar la información necesaria de la

notificación de las alarmas, así como los datos para el adecuado acondicionamiento

de la información, se utilizó el gestor de base de datos ACCESS de Microsoft.

26

En el desarrollo de este proyecto se estudiaron varias posibilidades para la

obtención y el acceso a los datos contenidos en el OMC-B, éstas fueron:

• Acceso directo a la base de datos ORACLE del OMC-B: Se necesita acceso a

la base de datos mediante un usuario, conocer exactamente la estructura de la

base de datos. Ventajas: notificación de las alarmas en tiempo real,

Desventajas: No se contaba con los permisos necesarios para el acceso a la

base de datos, no se conocía su estructura, que es de un tamaño considerable.

• Acceso a los datos mediante la interface Q3: (estándar o norma Q.811 y

Q.812 del UIT-T Unión Internacional de Telecomunicaciones), se necesitaba

desarrollar una investigación sobre la estructura de esta interface, pero el

inconveniente más notorio era que no se sabía a ciencia cierta en que parte del

sistema GSM, se podía tener acceso a la misma. Esta interface sustenta la

transferencia de datos bidireccional para la gestión de los sistemas de

telecomunicaciones. Ventajas: notificación de alarmas en tiempo real.

Desventajas: se necesita invertir mucho tiempo para la comprensión de la

interface y no se sabe en que parte del sistema GSM, se podría tener acceso a

la información de ésta.

• Acceso a los datos mediante la transferencia de archivos generados por el

OMC-B: En donde se lleva el registro de los eventos que ocurren en la red. El

OMC-B genera cada quince (15) minutos un archivo en formato texto en el

cual están registradas las alarmas de la red en ese período de tiempo; el

inconveniente es que había que descifrar la estructura de los datos de este

archivo e interpretar adecuadamente estos datos. Ventajas: se puede trabajar

inmediatamente con el archivo para el desarrollo del proyecto, ya que no se

presentan problemas de acceso. Desventajas: la notificación de alarmas se

hace cada Quince (15) minutos. Pero al analizar las condiciones: tiempo de

notificación – Criticidad de alarmas, se llegó a la conclusión de que la

mayoría de las alarmas que se presentan en la red, pueden ser notificadas en el

27

peor de los casos quince (15) minutos después de haber ocurrido la alarma, sin

que se afecte considerablemente el desempeño de la red y la calidad del

servicio ofrecido a los clientes.

También se estudiaron dos procedimientos para la notificación de las alarmas;

estos fuerin: notificación mediante mensajes cortos de texto (SMS – Short Messages

Service) utilizando un teléfono celular y notificación mediante el envío de e-mail a la

cuentas del personal de operación y mantenimiento.

Para notificar las alarmas mediante el envío de SMS, se utilizó un teléfono móvil

NOKIA, conectado por el puerto serial del PC utilizando el modo de transmisión

Half Duplex. Para la notificación de alarmas por e-mail, fue necesario contar con una

cuenta en el servidor de correos de Microsoft Exchange de la Corporación. Además

se estudiaron los métodos para enviar correos mediante Visual Basic.

Fase 2: Diseño Teórico.

Es una etapa de prediseño, en donde se ponen sobre la mesa todas las

posibilidades e ideas con que se cuenta para desarrollar el proyecto. Una vez que se

dispone de los conocimientos teóricos, se procede a la formulación de bosquejos y

etapas que cumplan con cada uno de los objetivos del proyecto. Es así como se

dividió el trabajo en tres grandes fases:

• Obtención de los datos o información en donde se va a apoyar el sistema.

• Acondicionamiento, filtraje y análisis de la información, así como el

desarrollo de la base de datos en donde se guarde la información del sistema

COFADI-rc, para que se cumplan los objetivos del proyecto.

• Notificación y comunicación, mediante SMS utilizando un teléfono celular y

el envío de e-mail, de las alarmas que se presentan en la red.

Estas tres fases están divididas en sub-fases que se explicaran en el próximo

capítulo.

28

Fase 3. Implementación del Diseño.

Una vez que ya se plasmaron y adecuaron las ideas para la realización del

proyecto, comenzó en si la parte de diseño, en el cual se desarrolló paulatinamente

cada uno de los módulos o etapas de la programación en Visual Basic, desarrollando

toda una estructura lógica para que COFADI-rc cumpliera con su objetivo principal

que es la notificación y comunicación de alarmas. A medida que se creaban los

diferentes módulos se ponían a prueba, para verificar si cumplían con las tareas

encomendadas, era una especie de experimentación en base a “ensayo y error”, que

poco a poco fueron dando experiencias y conocimientos en el manejo de las

diferentes herramientas que se utilizaron en el desarrollo de COFADI-rc. Al final se

fueron integrando cada uno de los módulos, resultando exitosa la implementación del

sistema COFADI-rc.

Fase 4: Pruebas y Evaluación.

Una vez que todo estuvo integrado y funcionando, se puso al sistema de

COFADI_rc en período de prueba, para verificar su rendimiento y eficacia, al realizar

las tareas encomendadas. Surgieron algunos detalles en los códigos de programación

que se fueron afinando, pasando satisfactoriamente el período de prueba. El sistema

cumple con las tareas encomendadas y con los objetivos del proyecto, por lo que los

comentarios del sistema desarrollado fueron positivos, por lo cual se espera su pronta

utilización por parte de la Corporación.

CAPÍTULO III DESCRIPCIÓN DE PROCESOS Y

PROCEDIMIENTOS, EQUIPOS UTILIZADOS,

HERRAMIENTAS DE PROGRAMACIÓN.

Para el desarrollo de todo proyecto es necesario conocer a fondo los procesos

físicos con los que se va a trabajar, así como las tareas y actividades que se

desempeñan en cada uno de estos procesos. También es necesario conocer

detalladamente cada uno de los componentes y elementos que van a ser utilizados

para ir forjando la configuración del proyecto, de esta forma es mucho mas sencillo

idear los procedimientos que se van a llevar a cabo para desarrollar el trabajo, además

de facilitar el diagnóstico de los errores o problemas que se vayan presentando. En el

desarrollo del sistema COFADI_rc, este punto fue muy importante, pues se tenía que

cumplir con una serie de procesos para que cumpliera con los objetivos

encomendados en la notificación de las alarmas, ideando procedimientos en códigos

de programación que simularan las actividades y decisiones ejecutadas por el

operador del OMC-B, de manera de lograr la correcta notificación de las alarmas por

parte del sistema propuesto y desarrollado.

En el presente capítulo se hace una descripción del proceso físico (actividades del

operador del OMC-B) a simular y que fué estudiado punto por punto para el

desarrollo del sistema COFADI_rc. Se describen los procedimientos que se ejecutan

internamente para cumplir con los objetivos planteados y se mencionan los equipos,

30

componentes y herramientas que se utilizaron para que el sistema funcione

satisfactoriamente.

3.1.- Descripción del Proceso Físico.

Como se mencionó en el Capítulo II, la Corporación DIGITEL – TIM C.A

requería de un sistema o herramienta que notificará automáticamente las fallas que se

presentan en el BSS de la red GSM; además, debía generar reportes o resúmenes de

estas fallas diariamente. Para lograrlo se necesitó la colaboración de la Gerencia de

Mantenimiento de Campo de la Región Central y del Departamento de Performance y

Configuración.

• La Gerencia de Mantenimiento de Campo brindó los conocimientos

necesarios sobre: la composición de la red GSM, características y elementos

que la integran, experiencia adquirida sobre las diferentes alarmas,

clasificación de los subsistemas que integran la red GSM, tipos y clasificación

de alarmas.

• El Departamento de Performance y Configuración otorgó los conocimientos

sobre: el sistema de Gestión de la Corporación, es decir, el Centro de

Operación y Mantenimiento (OMC - Operation Maintenance Center),

obtención de los datos o información en donde se apoya el sistema

COFADI_rc, conocimientos sobre la configuración de los diferentes

elementos que conforman la red GSM, operación y manejo del OMC-B,

conceptos relacionados con la gestión de los elementos de la red. Este

departamento tiene bajo su cargo el Centro de Operación de la Red (NOC –

Network Operation Center); su función es velar por el funcionamiento y

operatividad de la red GSM, para esto cuenta con el sistema de gestión OMC-

B, que monitoriza en tiempo real cada una de las estaciones y elementos que

conforman el BSS. El NOC cuenta con operadores, personas encargadas y

especializadas en las acciones y procedimientos que se ejecutan en el OMC-B,

quienes se encargan de vigilar los eventos y circunstancias que se presentan

31

en la red y por consiguiente recolectadas y mostradas en la interface gráfica

del OMC-B, interactuando con el sistema y tomando decisiones y acciones

para enfrentar las fallas. Las decisiones y acciones realizadas por el operador

son los procesos físicos que COFADI_rc tiene que simular y para lo cual fue

diseñado.

3.1.1.- Procedimiento actual para la Notificación de Fallas.

Todas las actividades relacionadas con el monitoreo, supervisión y

mantenimiento, así como algunas configuraciones de la red son ejecutadas y

realizadas desde el NOC. El personal que aquí labora es el encargado del

mantenimiento de primera línea del BSS, realizando tests o pruebas remotas desde el

OMC-B al elemento donde se presenta la alarma; también se encarga de velar y hacer

el seguimiento de cada una de las fallas que se muestran en el OMC-B. Si las

acciones ejecutadas no dan resultados satisfactorios, el personal del NOC comunica al

personal de la Gerencia de Mantenimiento de Campo la falla presentada,

movilizándose estos inmediatamente al sitio para dar solución al problema. Las fallas

o alarmas que se presentan en el BSS se pueden dividir en 2 grandes grupos: fallas

de estaciones Base (de los elementos del BSS) y fallas externas (energía,

ambientales, central de incendio, luces de balizaje), debido a esto se tiene que

notificar las fallas a tres de los departamentos en la Gerencia de Mantenimiento de

Campo, los cuales son:

• Departamento de BSS: Se le notifica las fallas de los elementos del BSS que

se encuentran ubicados geográficamente en los estados Carabobo, Cojedes,

Falcón y Yaracuy.

• Departamento de Energía: Se le notifica las fallas de los Sistema de

Potencia que alimentan a los elementos del BSS de toda la Región Central;

además, están capacitados par atender fallas de los equipos de

acondicionamiento de ambiente dentro de las estaciones, centrales de

32

incendio y luces de balizaje o de señalización aérea, todo esto se puede

resumir como fallas externas de las estaciones bases.

• Departamento de Mantenimiento de Campo de la Gran Maracay: Se le

notifica las fallas de los elementos del BSS que se encuentran ubicados

geográficamente en los estados Aragua y Guarico.

Todas las estaciones bases y cada uno de sus componentes reportan al OMC-B

todo lo que le ocurre; de esta forma se tiene centralizada toda la información de cada

uno de los equipos integrantes del BSS de la red GSM. El operador del OMC-B

efectúa operaciones de supervisión, gestión, configuración, mantenimiento de primera

línea, administración de los equipos de la red GSM. Para esto en el OMC-B se cuenta

con diferentes módulos en donde se puede encontrar información precisa de cada una

de las estaciones bases o de sus componentes. Así se dispone con el módulo o reporte

“alarm monitor” (monitor de alarmas), en el cual se observan las alarmas activas en la

red; también existe el módulo o reporte “see errors log” (ver registro de errores),

aquí se pueden observar las alarmas que han ocurrido en un componente del BSS para

un tiempo específico.

Como se puede observar el proceso de notificación hasta ahora depende

totalmente del operador del OMC-B, quien vigila la interface gráfica del OMC-B y

reconoce las fallas que se van presentando, ejecutando las pruebas o tests

correspondientes. Si el elemento afectado por la falla no responde, es el operador

quien comunica, mediante una llamada telefónica, al personal del Departamento de

Mantenimiento de Campo que se encarga de atender ese tipo de alarma específica.

Queda entonces toda la responsabilidad de la notificación de alarmas y el posterior

seguimiento de la falla, en manos del operador del OMC-B.

33

Por otro lado el OMC-B no cuenta con interfaces que puedan enviar los reporte o

resúmenes de alarmas mediante ninguna vía, solo es posible que el operador los

obtenga guardando respaldos en unidades de disquetes de 3 ½.

El presente Proyecto de Grado desarrolló el sistema COFADI_rc, el cual notifica

y comunica automáticamente las fallas que se presentan en el BSS de la red GSM de

la Corporación, sin necesidad de que se interactué con el mismo, mejorando así el

tiempo de respuesta para la atención de las fallas que se presenten y proporcionando

datos de apoyo para la planificación del mantenimiento de los equipos y elementos de

la Corporación.

Este es el proceso que tiene que realizar COFADI_rc para garantizar la correcta

notificación de las alarmas. Este objetivo se logró creando procedimientos en códigos

de programación que simulan las acciones que ejecuta el operador del OMC-B. Por

ello COFADI_rc tiene que manejar los siguientes factores:

• Tipo y clasificación de las alarmas.

• Departamento encargado de atender cada tipo de alarma.

• Ubicación geográfica del elemento en donde se produjo la alarma.

• Persona de guardia por el departamento que se encarga de atender ese tipo de

alarma.

• Actualización de los datos de cada una de las estaciones de la red GSM.

• Adquisición de los datos del OMC-B.

Estos factores fueron complicando los procedimientos desarrollados para que el

sistema funcione adecuadamente de manera que cumpla con las tareas encomendadas.

Debido a esto, el desarrollo se tuvo que realizar por etapas y cada una de estas etapas

ejecuta algunos procedimientos que son descritos a continuación.

34

3.2.- Etapas y Procedimientos para el desarrollo del Sistema

COFADI_rc.

Son muchas la tareas que se tienen que ejecutar al momento de iniciar la

operación del sistema COFADI_rc, debido a esto el sistema se separa en cuatro (4)

etapas bien definidas:

• Adquisición de Datos.

• Acondicionamiento de datos y almacenaje de los mismos

• Notificación de fallas y generación de reporte diario.

• Actualización de datos.

En cada una de estas etapas se desarrollan procedimientos que van a cumplir

inequívocamente con la tarea encomendada, contribuyendo así al cumplimiento de los

objetivos que se tenían trazados para el sistema. En las próximas líneas se irá

describiendo cada una de estas tareas y se mostrará el diagrama lógico de manera de

dar una idea de lo realizado en el lenguaje de programación Visual Basic. En la

Figura 3.1, se muestra el diagrama de bloque de las etapas que se desarrollaron para

elaboración del sistema COFADI_rc.

Figura 3.1. Diagrama de bloque de las etapas del Sistema COFADI_rc

35

3.2.1.- Adquisición de Datos.

El sistema consta de dos la adquisición de datos del OMC-B, el cual es

completamente automatizado y la adquisición de datos mediante interfaces gráficas,

con las cuales interactúa la persona encargada del mantenimiento del sistema, para la

actualización de la base de datos.

Como se mencionó en el capítulo II, existen tres posibilidades para obtener los

datos del OMC-B, la alternativa seleccionada para el desarrollo del sistema

COFADI_rc, fué la transferencia de un archivo de texto generado por el OMC-B cada

15 minutos, en donde se encuentran registrados todos los eventos que se presentaron

en la red GSM en los últimos 15 minutos.

La desventaja de esta alternativa para la adquisición de datos es que la

notificación de las alarmas no se puede realizar en tiempo real, pero al analizar la

criticidad de las diferentes alarmas que se pueden presentar en el BSS, se observó que

la mayoría de éstas, no afectan en gran medida la disponibilidad y desempeño de la

red, además de considerar que este período de tiempo es bastante adecuado, para

conocer si la falla presentada es fija o intermitente o si las pruebas o tests realizados

desde el sistema de gestión y monitoreo OMC-B, solventaron la falla.

El OMC-B es un sistema desarrollado bajo una plataforma SOLARIS y el

sistema COFADI_rc se desarrolló bajo una plataforma WINDOWS, por lo que se

decidió que la mejor forma para la transferencia de archivo entre las dos plataformas

era el Protocolo para la Transferencia de Archivos (FTP – File Transfer Protocol), el

cual funciona adecuadamente a pesar de la diferencia de plataformas existentes, pues

es un protocolo ideado precisamente para la transferencia de archivos. La principal

ventaja de utilizar este protocolo es que se puede contar con los archivos de datos en

la máquina local donde se desarrolló el sistema, haciendo al sistema totalmente

independiente del OMC-B, el cual adquiriría la función de un servidor o máquina

remota a donde se accede para tomar los datos. Es conveniente acotar que fue

36

necesario crear una cuenta de acceso en la máquina remota o terminal del OMC-B, la

cual daría el acceso para realizar la transferencia de archivos. Esto trae como

consecuencia que el sistema COFADI_rc tiene que disponer de esta información de

acceso o permiso, para comunicarse con el terminal de el OMC-B y poder realizar la

transferencia de archivos. Esta información de identificación y acceso se colocó en la

base datos del sistema.

La adquisición de datos mediante las interfaces gráficas se desarrolló para

actualizar la información que corresponde a: Datos del Personal, Datos de

identificación de los BSC, Departamentos de la Gerencia de Mantenimiento de

Campo y las alarmas que atiende cada uno, Configuración del Sistema COFADI_rc y

Personal de guardia. Esta información ya está registrada en la base de datos, casi

nunca varía, su volumen es pequeño y puede ser manejado por la persona encargada

del mantenimiento del sistema. La adquisición de datos del OMC-B se desarrolló

debido a la gran cantidad de información que se maneja y se hizo automatizada de

manera de no introducir el factor “error humano” en el proceso. Los datos que se

adquieren del OMC-B son: los archivo de alarmas que genera el OMC-B y que son

leídos posteriormente por COFADI_rc y los archivos de configuración del BSS los

cuales son leídos por COFADI_rc para actualizar la información de las BTS que se

encuentran registrados en la base de datos del sistema.

Para la adquisición de datos del OMC-B fue necesario desarrollar los

procedimientos indicados en el diagrama de bloques de la Figura 3.2.

Figura 3.2. Diagrama de bloque de la etapa de adquisición de datos del OMC-B.

37

Tiempo para iniciar la transferencia de archivo del OMC-B.

El OMC-B genera automáticamente cada 15 minutos un archivo con formato de

texto en donde se registran todos los sucesos que se presentan en el BSS de la red

GSM. Este archivo se encuentra en los directorios del disco duro de cualquiera de los

terminales del OMC-B (OMT). Debido a que el archivo se genera cada 15 minutos y

la prioridad es notificar las alarmas lo mas pronto posible, fue necesario hacer saber

al sistema COFADI_rc en que momento hacer la solicitud de la transferencia del

archivo, para esto se sincronizó la hora del terminal local en donde se desarrolló

COFADI_rc con la hora del terminal remoto (OMT). Los archivos se generan en los

minutos 00, 15, 30 y 45 de cada hora del día y cada uno de ellos contiene las alarmas

de la red GSM en el periodo de tiempo indicado en la tabla 3.1. Como se puede

observar en esta tabla, el OMC-B genera e identifica inequívocamente los archivos

que genera, por lo que el sistema COFADI_rc es capaz de proporcionar el nombre del

archivo a transferir, que corresponda con el momento del día en que se realiza la

petición de transferencia.

Tabla 3.1. Condiciones que identifican los archivos a transferir.

Minutos de generación del archivo

Periodo de tiempo de las alarmas contenida en el

archivo Nombre del archivo a transferir

hh:00 horas Desde las hh:45 hasta las hh:59

Alarmas_ddmmaahh4500_ddmmaahh5959.exp

hh:15 horas Desde las hh:00 hasta las hh:14

Alarmas_ddmmaahh0000_ddmmaahh1459.exp

hh:30 horas Desde las hh:15 hasta las hh:29

Alarmas_ddmmaahh1500_ddmmaahh2959.exp

hh:45 horas Desde las hh:30 hasta las hh:44

Alarmas_ddmmaahh3000_ddmmaahh4459.exp LEYENDA: * hh-hora del día en que se genera el archivo. * dd-día en que se genera el archivo.

* mm-mes en que se genera el archivo. * aa-año en que se genera el archivo.

Para lograr esto COFADI_rc observa la hora de la máquina local y activa un

contador; por cada minuto que pasa el valor del contador se incrementa una unidad; al

momento de que este valor es igual a quince (15), se activa la tarea o procedimiento

38

de solicitud de transferencia del archivo al OMC-B; COFADI_rc genera el nombre

del archivo a transferir y comienza la transferencia del archivo, luego se reinicia el

contador comenzando de nuevo el proceso descrito para los próximos quince (15)

minutos.

Es de hacer notar que todo el procedimiento para la transferencia del archivo, así

como la generación del nombre del archivo a transferir, la contabilización del tiempo

restante para la transferencia y la transferencia de los archivos, es ejecutado por

COFADI_rc luego que la persona encargada del da inicio o pone en funcionamiento

al sistema. Además si ocurre alguna falla en el suministro de electricidad o se detiene

la operación del sistema COFADI_rc, este está en capacidad de solicitar todos los

archivos desde el ultimo archivo registrado en la Base de Datos que logró transferir y

procesar del OMC-B; lo cual garantiza que es sistema COFADI_rc siempre disponga

en su base de datos de todos los eventos que se registran en el OMC-B, permitiendo

que el registro que hace de las alarmas sea permanente. Este procedimiento se resume

en los diagramas de flujos presentados en la Figura 3.3, en donde se observa cada una

de las actividades que se realizan en esta etapa, dando una idea de el código que se

programó en Visual Basic para su ejecución.

Transferencia de archivos del OMC-B

Una vez que se cumple el tiempo para que en el OMC-B se genere un nuevo

archivo de alarmas y luego de que el sistema COFADI_rc generó el nombre el

archivo, es necesario transferirlo, para ello, como se dijo, se utilizó el Protocolo FTP;

en él cual se indica en cual directorio del disco duro de la máquina remota se va a

buscar el archivo y en que directorio del disco duro de la máquina local se va a

guardar el archivo; para esto se usa comandos propios del FTP. Es necesario entonces

contar con una cuenta de acceso en la máquina remota, la cual fue creada por el

personal del Departamento de Performance y Configuración.

39

Figura 3.3. Diagrama de flujo. Inicio del tiempo para transferir los archivos del OMC-B

Es necesario identificar precisamente a la máquina remota, para esto se utiliza la

dirección IP de la misma. La información necesaria para realizar la transferencia de

archivos entre la dos máquinas, se colocó en la base de datos desarrollada para el

sistema COFADI_rc, la cual se explica más adelante. Esta información es extraída o

solicitada al momento que sea utilizada por el sistema. Los directorios origen del

40

archivo (en el terminal remoto) y destino del archivo (terminal local), se indicaron

directamente en el código de programación de Visual Basic, ya que estos directorios

son invariables.

Ahora bien, como COFADI_rc se apoya en el programa FTP que se encuentra en

Windows, para poder ejecutar este procedimiento, utilizando una instrucción

específica de Visual Basic se manda a ejecutar el programa de FTP, luego se busca

en la base de datos la información de acceso explicada anteriormente, para establecer

la conexión entre las dos máquinas. COFADI_rc envía el nombre del archivo a

transferir, se efectúa la transferencia y ya se cuenta con el archivo en la máquina

local para procesarlo adecuadamente. El diagrama de flujo de este procedimiento se

observa en la Figura 3.3 en donde se observan las actividades que se desarrollan en

esta etapa.

La información de acceso a la máquina remota se extrae de la base de datos del

sistema y se ejecuta el FTP para la transferencia del archivo, mediante los comandos

propios del protocolo. Es de hacer notar que si los datos de acceso no son correctos la

transferencia de archivos no se ejecuta y se despliega una rutina para actualizar la

información que se necesita.

En este procedimiento es importante tener cuidado con la información: Dirección

IP, Login y Password, suministrada al sistema COFADI_rc e introducida a la base de

datos por el operador, pues si ésta no es correcta, será imposible establecer la

conexión entre la máquina local y el terminal remoto del OMC-T. Esta información

no se colocó directamente en el código de programación para dar versatilidad al

sistema COFADI_rc, pues así es posible que éste se conecte a cualquiera de los

terminales del OMC-B con tan solo indicar la dirección IP del mismo. Por otro lado

y debido a que los parámetros de acceso (Login y Password) pueden ser cambiado

por el personal del Departamento de Performance y Configuración al proporcionar

mantenimiento al OMC-B, lo que haría que el sistema no funcione más, para evitar

41

este problema se creó la interface gráfica (interface hombre – máquina) para

actualizar esta información.

Figura 3.3. Diagrama de Flujo. Transferencia de archivo del OMC-B

Transferencia de archivos de la configuración de la red GSM.

La red GSM de la Corporación está en continuo crecimiento y cambio para

lograr incrementar y mejorar las zonas de cobertura, así como para satisfacer la

cantidad de tráfico que generan los usuarios, por ello es necesario ubicar e

implementar nuevas estaciones base. También en algunos casos es preciso reubicar

equipos de Estaciones Bases Transreceptoras (BTSE) en otras Estaciones Bases

Controladoras (BSC), para optimizar el funcionamiento de la red. Todo esto

42

evidencia que la red GSM de la Corporación no es estática y por el contrario es

bastante dinámica.

Las diferentes BTSE como BSC, poseen parámetros de configuración que las

identifican tanto a nivel físico como a nivel lógico. El nivel físico corresponde al

equipo tangible, lo que se puede ver y se puede tocar; el nivel lógico corresponde a

las formas de identificar al elemento físico en las bases de datos y en el sistema de

gestión OMC-B. Las BTSE se identifican a nivel lógico por el parámetro Sitio de

Administración de la Estación Base Transreceptora (BTSM – Base Transceiver

Station Site Manager), el cual es un número que identifica a una y solo una BTSE.

Además, cada BTSE esta integrada por un máximo de tres BTS o celdas, que son

identificadas a través del Cell_id (identificador de celda o BTS). Siempre el número

que identifica las BTSE y el parámetro BTSM es el mismo, pero cumplen funciones

totalmente diferentes. En la Figura 3.4 se observan los elementos que componen y los

parámetros que identifican a una BTSE, en este caso BTSE 4 y BTSM 4 el numero

que identifica a cualquier estación que integra el BSS de la red GSM.

Figura 3.4. Elementos que identifican una BTSE

43

Estos parámetros BTSE, BTSM, BTS, Cell-id de identificación y configuración,

se tabularon en una tabla en la base de datos del sistema COFADI_rc. Si se realiza

algún cambio en la configuración de los elementos del BSS, los datos allí contenidos

ya no son verdaderos ni actuales, por lo que es necesario que COFADI_rc esté en

capacidad de actualizar periódicamente esta información, para que el proceso de

notificación de alarmas sea confiable.

Es así como cada vez que se de inicio a la operación del sistema o cuando el

operador considere necesario, se efectuará un procedimiento para actualizar los datos

de identificación de las estaciones que componen la red. Para esto se transfieren

varios archivos del OMC-B que corresponde a cada uno de los BSC´s que existen en

la red; allí se encuentran los parámetros BTSE, BTS, BTSM, Cell_id, BSC, que son

usados por el OMC-B para identificar las diferentes estaciones bases. Esto garantiza

que las datos del Sistema COFADI_rc sean exactamente los mismos que usa el

OMC-B, permitiendo mantener actualizados estos datos de configuración de la red en

el sistema COFADI_rc. Estos archivos son guardados en el disco duro del terminal

local.

El procedimiento para la transferencia de los archivos de configuración del BSS

es muy parecido al realizado en el tópico anterior, Transferencia de Archivos del

OMC-B ya descrito. Se usa el FTP para transferir el archivo en donde se encuentran

los parámetros de la configuración de la red. La diferencia entre este procedimiento y

el anterior radica en que los nombres del archivos a transferir siempre son los mismos

y que el directorio origen de los datos es distinto.

3.2.2.- Acondicionamiento y Almacenaje de Datos del OMC-B.

Una vez que ya se tienen los archivos que fueron transferidos del OMC-B en el

disco duro de la máquina local, es necesario leer la información que contiene cada

uno de ellos de manera de filtrar la información de interés para la notificación de

alarmas y al mismo tiempo acondicionarlos adecuadamente para que el personal de la

44

Gerencia de Mantenimiento de Campo, entienda y cuente con la información

necesaria para la atención de las fallas. Para esto se estudió la estructura de los datos

contenidos en el archivo de texto de las alarmas.

Los archivos transferidos son del tipo texto, en donde cada línea corresponde al

registro de una alarma. Por cada registro hay treinta y tres (33) campos separados por

el caracter TAB (tabulación), este caracter es el que nos permite reconocer donde

comienza y termina cada campo para realizar la lectura del archivo. La estructura del

archivo es parecida a una tabla, donde cada línea corresponde a un registro o evento

de alarma ocurrido y cada columna corresponde a un campo (cada campo contiene

información que describe la alarma del registro).A continuación se describe la

información contenida en cada campo:

• Campo 1: Contiene información de tipo texto que indica los tipos de eventos

que pueden ser reportados como falla, este campo se denomina Event Type y

puede contener cualquiera de los siguientes valores:

1. Communication Failure

2. Quality of Service Failure

3. Processing Failure

4. Equipment Failure

5. Environmental Failure

La información contenida en este campo se rige por la recomendación X.733

de la UIT.

• Campo 2: Contiene información de tipo numérica que identifica a los posibles

eventos de Campo Event Type. (Campo no usado por COFADI_rc)

• Campo 3: Contienen información de tipo fecha que indica la fecha y hora en

la que ocurrió o apareció la falla. Este Campo se denomina Date and Time.

• Campo 4: Contiene información de tipo texto que indica el componente que

integran el BSC, BTS o TRAU donde ocurre la falla. Este campo se

denomina Type Hardware.

45

En la Figura 3.5, se muestra los diferentes componentes que integran a las

BSC, BTSE, y TRAU. La mayoría de estos componentes son tarjetas o

módulos que se insertan y extraen de gabinetes (Rack) donde se encuentran

alojados estos elementos del BSS. Cada uno de estos componentes o módulos

cumplen funciones específicas en la operación de las BSC, BTSE y TRAU de

la red GSM.

Figura. 3.5. Componentes que integran los elementos del BSS de la red GSM.

46

La Figura 3.5 muestra un diagrama de árbol con los elementos que maneja el

BSS, clasificándolos en: equipos físicos del BSS (equipos tangibles que se

pueden manipular), elementos funcionales del BSS (son instancias de los

mismo componentes de el BSC que existen a nivel software). En los equipos

físicos se observan las BSCE, BTSE y TRAUE, así como los elementos que

integran a cada uno de estos equipos.

En los elementos funcionales se observan los diferentes protocolos, interfaces,

canales de tráfico y de señalización que manejan las BSC.

• Campos 5 y 6: Contienen información de tipo numérica que identifica las

regiones y distritos en donde ocurre la falla. Estos campos se denominan

Región y Distrito respectivamente y se usan cuando a la red GSM la

supervisa más de un OMC, de esta manera se puede identificar fácilmente el

lugar de la falla. En la red de DIGITEL –TIM C.ARegión Central solo existe

un OMC por lo que estos valor siempre son cero (0) (Campos no usados por

COFADI_rc).

• Campo 7: Contiene información de tipo numérica que identifica el BSS que

atiende a el BSC en donde ocurre la falla, por cada BSC que existe en la red

existe un BSS, el número que identifica tanto al BSS como a el BSC siempre

es el mismo. Este campo se denomina BSS.

• Campo 8: Contiene información de tipo numérica que identifica el BSC que

controla al elemento donde ocurre la alarma. Este campo se denomina BSC.

• Campos 9, 10 y 11: Contienen información de tipo numérica cuyo significado

varia según el campo 4 (type hardware) y se relaciona con el diagrama de

árbol de la Figura 3.5.

Estos campo puede existir o no dependiendo del componente de el BSC,

BTSE o TRAU donde se presenta la fallas. Por ejemplo si el campo 4 indica

que la falla se presentó en el componente ACT (ubicar componente en la

Figura 3.5), el campo 9 indica el número de identificación de la BSTE donde

ocurre la falla, el campo 10 indica el número del RACK donde se ubica el

ACT y el campo 11 indica el número del ACT que esta fallando. Pero si el

47

campo 4 indica una falla en el componente LPDLM (ubicar elemento en la

Figura 3.5), el campo 9 indica el número del LPDLM donde se presenta la

falla y los campos 10 y 11 no existen.

Debido a esto en el archivo de texto que se esta leyendo no siempre se

encuentra en una misma columna el mismo tipo de información, lo que obliga

a ordenarla, de manera que cada campo contenga siempre la misma

información, esto se realizó mediante un procedimiento en el código

programado en Visual Basic.

• Campo 12: Contiene información de tipo numérica que siempre es igual a 55.

(Este campo es usado por COFADI_rc).

• Campo 13: Contiene información de tipo texto que relaciona la información

del campo 1 con el campo 4 (Este campo no es usado por COFADI_rc)

• Campo 14: Contiene información de tipo numérica de identificación de la

información registrada en el campo 13. (este campo no es usado por

COFADI_rc).

• Campo 15: Contiene información de tipo texto que da una descripción

abreviada de la alarma que presenta el elemento indicado en el campo 4. Este

campo se denomina Probable Cause

• Campo 16: Contiene información de tipo numérica que identifica la

información que se presenta en el campo 15. (Este campo no es usado por

COFADI_rc).

• Campo 17: Contiene información de tipo texto que indica la severidad de la

alarma que se presenta. Este campo se denomina Severity y puede tener los

siguientes valores

1. Critical

2. Major

3. Minor

4. Warning

5. Cleared

48

La información contenida en este campo se rige por el recomendación X.733

de la UIT.

• Campo 18: Contiene información de tipo numérica de identificación de los

valores registrados en el Campo 17. (Este campo no es usado por

COFADI_rc).

• Campo 19: Contiene información de tipo texto que indica el desarrollo o

comportamiento de la alarma si ocurre repetidas veces. Este campo se

denomina Trend Indication y puede tener los siguiente valores:

1. No change

2. More severe

3. less severe

• Campo 20: Contiene información de tipo numérica de identificación de la

información registrada en el Campo Trend Indication. (Campo no usado por

COFADI_rc)

• Campos 21, 22, 23, 24: Contienen información de tipo texto que siempre es

igual a NIL (Campo no usado por COFADI_rc).

• Campo 25: Contiene información de tipo texto que se usa cuando el objeto o

elemento del campo 4 es ENVA (alarma de entorno o alarma externa), da una

descripción detallada de la falla que ocurre en el elemento. Este campo se

denomina Associated string y la información aquí mostrada es definida por el

personal del Departamento de Performance y Configuración

• Campo 26: Contiene información de tipo texto que siempre es igual a NIL

(Campo no usado por COFADI_rc).

• Campo 27: Contiene información de tipo texto que indica el objeto en donde

ocurre la falla en el OMC-B. (Campo no usado por CODAFI-rc).

• Campo 28: Contiene información de tipo numérica de identificación de la

información registrada en el Campo 27. (Campo no usado por COFADI_rc)

• Campo 29: Contiene información de tipo texto que siempre indica

“Undetermined” (Campo no usado por COFADI_rc)

49

• Campo 30: Contiene información de tipo numérica que hace referencia de la

falla en la documentación electrónica del OMC-B, donde se da una

descripción detallada de la alarma que se presentó. Este campo se denomina

Error ID.

• Campo 31: Contiene información de tipo texto que indica la versión de los

Software que están activos o instalados en el BSC. Este campo se denomina

SW version

• Campo 32: Contiene información de tipo numérica que indica una

clasificación interna que se encuentra en cada alarma que identifica el Error

ID en la documentación electrónica del OMC-B. Este campo se denomina

Originator.

• Campo 33: Contiene información de tipo hexadecimal, que se usa como

ayuda para obtener una descripción detallada del error que se produce. Este

campo se denomina Additional Info. Para poder utilizar esta información es

necesario interpretarla de acuerdo a la alarma que se presenta, para esto se

ubica la alarma en la documentación electrónica del OMC-B mediante el

campo Error ID, en la cual se va describiendo el significado del Additional

Info, una vez interpretada se obtiene información que ayuda a solucionar el

problema, indicando las acciones a tomar, además de que es un dato muy

importante para que los diseñadores del OMC-B puedan analizar el origen del

error.

Como se puede observar en la Figura 3.6, los registros de las alarmas contenidos

en el archivo de texto transferido del OMC-B, pueden tener diferentes cantidad de

campo dependiendo del elemento del BSS donde se produzca la falla, esto dificulta el

almacenamiento de las alarmas en las tablas de la base de datos del sistema, ya que en

los gestores de base de datos (en este caso Microsoft Access) se debe cumplir al

definir una tabla que cada fila debe contener los datos de un solo registro y por cada

columna se debe registrar un campo que siempre contenga el mismo tipo de

información. Antes de guardar las alarmas en la base de datos del sistema es

50

necesario ordenar los campos de forma que siempre la información de ese campo esté

ubicado en una sola columna, para esto en el campo que no existe debido al tipo de

componente que se alarmó se coloco el valor vacío para ordenar la información de los

campos en las alarmas registradas en el archivo.

Figura 3.6. Estructura general de las alarmas registradas en el archivo leído.

Por otro lado la información contenida en los Campos 8, 9, 10, 11, son los que

nos indica exactamente en que componente de los elemento que integran el BSS se

produce la falla, pero como se describió anteriormente la información contenida en

esos campos es numérica, por lo que al momento de notificar al personal que se

encuentra de guardia la falla, estos números no les indica ninguna ubicación precisa

ni concisa. Es necesario entonces acondicionar adecuadamente los datos que se

encuentran en estos campos, para esto se creó un código programado en Visual Basic

que realiza el acondicionamiento de datos descrito en la Figura 3.7.

Como se observa en la Figura 3.7 se desarrollaron cinco (5) etapas para el

acondicionamiento de los campos señalados, en la Etapa I se lee los datos contenidos

en cada uno de los campos, en la Etapa II se busca en la tabla “Elementos de Red” de

la base de datos, que fue tabulada según los componentes del BSS que se observan el

la Figura 3.5, la información que contiene el Campo 4 relacionando los datos de estas

51

dos etapas se consigue acondicionar los Campos 9,10 y 11 como se muestra en la

Etapa III, relacionando los datos de los Campo 8 y 9 de la Etapa III con los datos

tabulados en las tablas “BTS” y “BSC” de la base de datos como se observa en la

Etapa IV se obtiene la información que se especifica en la Etapa V, en donde el

acondicionamiento de los datos es adecuado para que el personal de guardia por los

Departamentos de la Gerencia de Mantenimiento de Campo conozca exactamente en

que parte y que elementos del BSS está presente la falla.

Una vez separadas, filtradas y acondicionadas cada una de las alarmas registradas

y sus campos en el archivo leído, se procede a guardar esta información en la base de

datos, de manera de obtener esta información fácilmente al momento de ejecutar el

procedimiento de notificación de estas alarmas. La información se almacena en dos

tablas, una de las cuales contiene todas las alarmas que lee el sistema y de la cual se

genera el resumen de contabilización de las alarmas y la otra se usa para realizar el

procedimiento de notificación de alarmas al personal de guardia.

En la Figura 3.8 se observa el diagrama de flujo del procedimiento que se realiza

para acondicionar adecuadamente la información contenida en el archivo leído, con lo

cual se da una idea de el código que se programó en Visual Basic.

52

Figura 3.7. Etapas del acondicionamiento de los datos contenidos en el archivo transferido del OMC-B.

53

Figura 3.8. Diagrama de Flujo. Acondicionamiento de los datos del archivo transferido del OMC-B

Base de Datos Desarrollada.

Es necesario que el sistema COFADI_rc siempre tenga a disposición la

información que requiere para realizar cualquiera de sus procedimientos, esta

información es dinámica y además en ocasiones es bastante voluminosa por lo que no

se puede almacenar en el propio código programado en Visual Basic, por lo que se

decidió desarrollar una base da datos para el sistema, en donde se guarde o almacene

toda la información que en uno u otro momento puede utilizar COFADI_rc,

adquiriéndola al momento de necesitarla.

54

La base de datos (BD) desarrollada consiste en tablas en donde se guarda la

información dependiendo de su función y uso; así se crearon las siguientes tablas:

• Alarmas: tabla en donde se guarda cada una de las alarmas con sus respectivos

campos, una vez que el archivo transferido es leído y los datos son

acondicionados por el sistema COFADI_rc; esta tabla se borra cada vez que

se notifican las alarmas.

• Alarmas Activas: COFADI_rc solo notifica las alarmas activas, en esta tabla

se guardan las alarmas activas que van a ser notificadas. Cuando COFADI_rc

verifica que una de las alarmas allí registradas ha desaparecido (ha cesado), se

borra de esta tabla.

• Alarmas Histórico: En esta tabla se guardan todas las alarmas transferidas,

leídas y acondicionadas transferidas del OMC-B, de esta tabla se generan los

reportes diarios que contabilizan las alarmas por su tipo y lugar en donde

ocurren. Las alarmas registradas en esta tabla se van borrando luego de 7 días

de haberse registrado, mediante un procedimiento de mantenimiento

programado en Visual Basic que se le efectúa a la BD para que su tamaño no

crezca exageradamente, ya que se recomienda que el gestor de base de datos

Microsoft Access no maneje archivos cuyo tamaño sea mayor a 2 Gbytes.

• BSC: Tabla en donde se guardan los datos o parámetros de identificación de

las BSC.

• BTS: Tabla en donde se guardan los datos o parámetros de identificación de

las BTSE.

• Configuración: Tabla en donde se guarda la información que configura al

sistema COFADI_rc, por ejemplo: formas de notificación de alarmas (Por

SMS o por e-mail), puerto serial al cual se conecta el teléfono, dirección IP

del terminal OMT del OMC-B, Login y Password para el acceso al OMT,

último archivo de alarma transferido y procesado.

• Departamentos: en esta tabla se guardan la información de los departamentos

que componen la Gerencia Líder de Operación y de Mantenimiento de la

Región Central y las fallas que atiende cada uno.

55

• Elementos de red: tabla en donde se tabula la información contenida en el

diagrama de árbol de los componente que integran los elementos del BSS (ver

Figura 3.5).

• Guardias: Tabla en donde se guarda la información de la fecha y el personal

de cada departamento que se encuentra de guardia para un periodo de tiempo.

• Personal: Tabla en donde se guarda la información del personal que integra la

Gerencia Líder de Operación y de Mantenimiento de la Región Central, aquí

se guardan los datos siguientes: teléfono, nombre, correo electrónico,

departamento al que pertenece.

La información contenida en cada una de estas tablas es de vital importancia para

que el sistema COFADI_rc funcione adecuadamente al momento de realizar

cualquiera de sus procedimientos, por lo que es necesario que esta información se

actualice periódicamente.

Para hacer consultas, insertar o eliminar información en la base de datos se utilizó

el Lenguaje de Consultas Estructurado (SQL – Structured Query Language), cuyos

comandos se usaron en los códigos programados en Visual Basic para el desarrollo de

los diferentes procedimientos realizados para la notificación de las alarmas de la red

GSM.

3.2.3.- Notificación de Alarmas y Generación de Reportes

Este es el procedimiento más importante y para el que fue desarrollado el sistema

COFADI_rc; la notificación de alarmas al personal de guardia encargado de

atenderlas es el principal objetivo de este Proyecto de Grado. Esta etapa o

procedimiento no se pudo desarrollar hasta que no se culminó con las etapas de

adquisición de datos y el acondicionamiento de los mismos; ya que si esta

información no es real ni confiable, la inversión de tiempo y recursos en esta etapa no

se justificaría, debido a que la información de las alarmas que se comunicarían sería

errónea.

56

Se eligieron dos medios para notificar las alarmas al personal que se encuentra de

guardia, la primera es mediante el envío de un mensaje corto de texto (SMS) al

teléfono móvil de la persona de guardia, de esta manera se garantiza que sin importar

el lugar donde se encuentre la persona, tenga conocimiento de las alarmas que

encuentran activas en la red GSM. El otro procedimiento de notificación es mediante

el envío de un correo electrónico en donde se encuentra un documento con todas las

alarmas activas en los últimos quince (15) minutos en la red GSM; con esta forma de

notificación se garantiza que cada persona que se encuentra de guardia, cuente con un

respaldo personal de la información de las alarmas que se presentaron en la red.

El proceso de notificación ejecuta varios pasos antes de enviar al personal de

guardia la información de las alarmas presentes en la red, estos pasos son:

• Detectar en las alarmas registradas en la Tabla Alarmas de la base de datos,

las que se encuentran activas para el momento de la notificación.

• Eliminar de la Tabla Alarmas de la base de datos, las alarmas que ya han

cesado o no están presentes en la red GSM

• Clasificar las alarmas restantes en la Tabla Alarmas de acuerdo al

departamento que está encargado de atenderla.

• Verificar en la base de datos la persona que se encuentra de guardia por cada

departamento.

• Buscar en la base de datos el número de teléfono y el E-mail de la persona que

se encuentra de guardia.

• Verificar los medios de notificación que se encuentran activos en el sistema

COFADI_rc para el envío de las alarmas.

• Enviar las alarmas activas al personal de guardia mediante el medio de

comunicación activo.

Para la notificación de alarmas y la generación de reportes fue necesario

desarrollar los procedimientos indicados en el diagrama de bloques de la Figura 3.9.

57

Figura 3.9. Diagrama de bloque de la etapa de notificación de alarmas y generación de reportes.

Verificación de Alarmas que se Encuentran Activas

El sistema COFADI_rc sólo notifica las alarmas que se encuentran activas al

momento de iniciar el procedimiento de notificación, para esto se trabaja con las

alarmas registradas en la Tabla Alarmas de la base de datos del sistema.

Se realizó un procedimiento en donde el sistema separa las alarmas por tipo de

severidad (alarmas críticas, mayores, menores, cesadas y warning [“advertencia”])

para identificar cuales de las alarmas registradas se encuentran activas. Hay que

mencionar que en el OMC-B por cada alarma que se presenta en la red GSM (alarma

o registro cuya severidad es de tipo “critica, mayor o menor”) y una vez que el

problema se soluciona, aparece un evento o registro (alarmas o registro cuya

severidad es de tipo “cleared”) que indica que la alarma ya cesó o finalizó, por lo

tanto una alarma no puede volver a aparecer en el OMC-B hasta que no se registre el

evento de que la alarma ha cesado, es decir; cuya severidad es “cleared”.

Luego de la separación de las alarmas y basándose en la forma como se registran

las alarmas en el OMC-B, se estableció otro procedimiento donde por cada alarma

con severidad “crítica, mayor o menor” se busca su correspondiente registro de

alarma finalizada en las alarmas con tipo de severidad “cesadas”, de manera de saber

si la alarma todavía se encuentra activa.

58

Para esto se comparan los campos 1, 8, 9, 10 , 11 y 15 de las alarmas con

severidad “criticas o mayores o menores” con los mismos campos de las alarmas con

severidad “cesadas”, si la información contenida en estos campos son idénticas se

trata de la misma alarma, pero además se debe cumplir que la información registrada

en el campo 2 (fecha y hora) de la alarma de severidad “cesada” sea mayor que la

información registrada en el mismo campo de la alarma de severidad “critica o mayor

o menor”, si esto se cumple la alarma que se estudia no se encuentra activa, entonces

se borran estos registros de alarmas de la Tabla Alarmas con lo cual no se notifica la

alarma. Así se ejecuta el procedimiento con cada alarma registrada en la Tabla

Alarmas, al final solo quedan las alarmas activas cuya severidad sea “critica o mayor

o menor”. Las alarmas con severidad “warning” son avisos preventivos de que se

podría presentar una falla en el BSS por lo cual no se notifican, debido a esto también

se borran de la tabla alarmas.

En la Figura 3.10 se observa el diagrama de flujo del procedimiento que se

realiza para verificar las alarmas que se encuentran activas en los archivos

transferidos del OMC-B, con lo cual se da una idea de el código que se programó en

Visual Basic.

Clasificación de las Alarmas de acuerdo a la Atención de Fallas de

cada Departamento

Luego de que se obtienen las alarmas activas de la Tabla Alarmas, se procede a

clasificarlas de acuerdo a la atención de fallas de cada departamento; esta

información se obtiene de la Tabla Departamentos de la base de datos, de esta manera

se le indica al sistema cuales alarmas se notifican a los diferentes departamentos de la

Gerencia de Mantenimiento de Campo.

59

Figura 3.10. Diagrama de flujo. Verificación de las alarmas activas contenidas en los archivos transferidos del OMC-B.

Obtención de los Datos del Personal de Guardia por Departamento

Luego de tener divididas las alarmas por departamento es necesario verificar las

personas de cada departamento que se encuentra de guardia; esta información se

busca en la Tabla Guardias de la base de datos. Una vez que se conoce el personal

que se encuentra de guardia, el sistema procede a buscar la información del teléfono y

correo electrónico de cada una de estas personas, para esto consulta la Tabla Personal

de la base de datos.

Comunicación de las Alarmas Activas

Al obtener todos los datos que se necesitan para realizar una correcta notificación

comienza el procedimiento de envío de la información de las alarmas activas a las

60

personas de guardia. Se usaron dos medios para la comunicación de alarmas: el envío

de SMS y el envío de e-mails. Se verifica en la Tabla Configuración de la base de

datos cuales de los medios esta habilitado para la notificación de alarmas. Si está

habilitado el envío de SMS se desarrolla un procedimiento en donde por cada alarma

activa clasificada por departamento, se envía un SMS al personal que se encuentra de

guardia por el departamento. Si está habilitado el envío de e-mail se llena una

plantilla o formulario realizado en Excel en el cual se colocan todas las alarmas que

se encuentran activas para el departamento; esta plantilla es guardada como un

archivo y se adjunta al correo electrónico que envía el sistema a las personas que se

encuentran de guardia por departamento. En esta etapa se crean tantos archivos como

departamentos posean alarmas activas para notificar, es decir, si luego de la

clasificación de las alarmas activas todas pertenecen al departamento de BSS, solo se

crea un archivo de Excel y se envía un solo correo al personal de guardia por ese

departamento; si por el contrario, luego de la clasificación existen alarmas activas

para los tres departamentos de la Gerencia de Mantenimiento de Campo se crean tres

archivos de Excel, cada uno contiene las alarmas correspondientes y se envían tres

correos con el archivo de Excel respectivo, enviándolo al personal de guardia por el

departamento correspondiente; de esta forma solo se utilizan los recursos necesarios

para notificar las alarmas que existen.

Escalamiento de Fallas

Una vez que finaliza el procedimiento de notificación de las alarmas activas al

personal de guardia, comienza un procedimiento para el escalamiento de fallas, con

el cual se mantiene informado a los supervisores y gerentes de la Gerencia Líder de

O&M de la Región Central de las alarmas que se producen en la red GSM de manera

que puedan coordinar las actividades necesarias para solucionar el problema. Según

normativas de la Corporación es necesario que si una alarma se encuentra activa por

más de treinta (30) minutos comunicar la presencia de la misma al supervisor del

departamento encargado de atender ese tipo de falla y si ésta sigue activa por mas de

61

sesenta (60) minutos, comunicar la existencia de la falla al Gerente Líder de O&M de

la Región Central y al Gerente de Mantenimiento de Campo.

Para lograr esta tarea se creó en la base de datos la Tabla Alarmas Activas en

donde se guardan las alarmas activas luego de concluir el procedimiento de

notificación de alarmas, de esta forma se puede llevar el control del tiempo que se

encuentra activa una alarma. El procedimiento de escalamiento de fallas se describe a

continuación.

Cuando se finaliza el procedimiento de clasificación de las alarmas por tipo de

severidad y el procedimiento de obtener las alarmas que se encuentran activas en la

Tabla Alarmas, las alarmas que todavía están contenidas en la tabla pueden contener

alarmas que tengan la condición “cesada”, debido a que no se consiguió en el archivo

de texto transferido del OMC-B que se está procesando actualmente la alarma

“crítica , mayor o menor” que la originó; esto se debe a que esa alarma está registrada

en uno de los archivos de texto que originó el OMC-B anteriormente y que ya fue

procesado. Esta alarma origen se encuentra registrada en la Tabla Alarmas Activas

de la base de datos, todas las cuales tienen por lo menos 15 minutos de estar activas.

Para realizar el proceso de escalamiento es necesario comparar la información de

los campos 1, 8, 9, 10 , 11 y 15 de cada alarma con tipo de severidad “critica, mayor,

o menor” registradas en la Tabla Alarmas Activas con los mismos campos de cada

alarma con tipo de severidad “cesada” de la Tabla Alarmas. Si la información de

estos campos es idéntica y la información del campo 2 ( fecha y hora) de la alarma de

la Tabla Alarmas es mayor que la información contenida en el mismo campo de la

Tabla Alarmas Activas, se trata de la misma alarma, con lo cual se borra cada alarma

de cada una de las tablas.

Si a las alarmas de la Tabla Alarmas Activas no se les consigue el registro en

donde la severidad es “cesada” en la Tabla Alarmas, significa que estas alarmas

62

todavía siguen activas, por lo que es necesario saber cuanto tiempo llevan activas

para notificar al supervisor o gerente correspondiente. Para esto se compara la

información contenida en el Campo 2 (fecha y hora) de cada alarma con la hora del

PC donde esta funcionando el sistema COFADI_rc, si la diferencia entre estos datos

es mayor a treinta (30) minutos se le notifican estas alarmas a los supervisores de

cada departamento. Los medios de comunicación de las alarmas del Procedimiento de

Escalamiento son los mismos utilizados para el Proceso Notificación de Alarmas

Activas para el personal de guardia (SMS y E-mail), así como el proceso que se

realiza para enviar las alarmas por estos medios. Pero si la diferencia entre estos datos

es mayor a sesenta (60) minutos, se le notifica las alarmas a los Gerentes. Los

medios de comunicación de las alarmas para esta etapa del Proceso de Escalamiento

son los mismos utilizados para la notificación de las alarma a los supervisores con

una pequeña diferencia en el proceso, pues a los gerentes se les notifican todas las

alarmas registradas en la Tabla Alarmas Activas cuya aparición sea mayor a sesenta

(60) minutos. (No existe la clasificación o división de las alarmas de acuerdo a la

atención de cada departamento).

Generación de Reportes

Por último la generación de reportes consiste en enviar a los supervisores y

gerentes un resumen en donde se contabiliza la cantidad de veces que se presenta

cada tipo de alarma en la red GSM para el día anterior, de esta forma se puede vigilar

el estado de los elementos de que componen el BSS, así como planificar y organizar

mantenimientos preventivos y correctivos, basándose en la información que aportan

estos reportes. Para esto se usa la Tabla Alarmas Histórico de la base de datos en

donde se van registrando todas las alarmas que son leídas y acondicionadas por el

sistema COFADI_rc, a partir de los archivos que son transferidos del OMC-B.

El sistema solo contabiliza las alarmas que tienen tipo de severidad “critica,

mayor, menor y warning”. Para eso se utilizó un comando del SQL que cuenta la

cantidad de veces que existen en la Tabla Histórico los registros de la alarma en

63

donde se cumpla que la información de los Campos 1, 8, 9, 10, 11, 15, 17, 25, 30 y 32

sean iguales entre los diferentes registros existentes y donde la información de

Campo 2 (fecha y hora) sea igual al día anterior de la fecha que tiene el PC al

momento de generar el reporte, esto garantiza que se esté contabilizando siempre una

misma alarma por instrucción. La información obtenida mediante estas consultas se

van colocando en una plantilla o formato realizada en Excel, al finalizar el proceso de

consulta a la base de datos se guarda el documento y se adjunta al Correo Electrónico

que fue el medio elegido para comunicar este reporte a los supervisores de

departamentos y a los gerentes es el E-mail, debido a lo extensa y voluminosa que

puede ser la información que se extrae de la base de datos del sistema. Con este

proceso finaliza el procedimiento de notificación de alarmas y generación de reportes.

3.3.- Equipo Utilizado

Para el desarrollo de todo proyecto es necesario hacer un estudio de los equipos

que se van a utilizar, de esta manera se pueden escoger los que mejor se adapten a los

requerimientos y funciones del trabajo que se realiza. La herramienta o sistema

COFADI_rc esta integrada por los tres (3) equipos que se muestran en la Figura 3.11,

los cuales son:

• El PC: Es la computadora personal en el cual se realizó todo el trabajo de

programación en Visual Basic para el desarrollo del proyecto y donde se

encuentra instalado el Sistema COFADI_rc. Las principales características de

la máquina utilizada a nivel de hardware son:

o Procesador PENTIUM III.

o Disco Duro de 20 Gbytes.

o 128 Mbytes de memoria RAM.

Se recomienda que la aplicación opere en una PC con estas características o

superiores, de manera de que el rendimiento del sistema COFADI_rc no se vea

afectado.

64

Figura 3.11. Equipos utilizados para el desarrollo del sistema COFADI_rc

• Teléfono Móvil NOKIA 5110: Para el envío de los SMS de notificación de

alarmas se necesitó un teléfono que hiciera las funciones de un MODEM

GSM, el equipo elegido fue el NOKIA 5110, debido a su facilidad para

conectarlo con el puerto serial del PC a través de una interface normalizada y

propia de NOKIA (interface FBUS).

• Cable de conexión o Interface FBUS: es el medio por el cual se conectan y

comunican los teléfonos NOKIA que están diseñados bajo tecnología GSM

con la PC, para intercambiar información. La interface se rige por la norma

RS-232 (V.24-V.28) la UIT, la cual es un estándar de comunicación que

permite adaptar los niveles de tensión de los “1” y “0” binarios, para que dos

equipos se entiendan y comuniquen. En la Figura 3.12 se muestra el diagrama

del circuito electrónico de la interface FBUS, con el cual se construyó el cable

para que se interconecte la PC y el teléfono. En la Figura 3.13 se muestra la

interface FBUS elaborada para el envío de SMS a través de la PC.

65

Figura 3.12. Diagrama de circuito de la interface FBUS para el teléfono NOKIA 5110.

66

Figura 3.13. Interface elaborada para la conexión dela PC con el teléfono móvil.

El sistema COFADI_rc también utiliza indirectamente los siguientes equipos:

terminales del OMC-B (OMT) de donde se adquieren los archivos de alarmas a

transferir, la red de computadoras de la Corporación, el servidor de correos

electrónicos de la Corporación, sin los cuales no seria posible la operación del

sistema COFADI_rc.

3.4.- Herramientas de Programación

La herramienta de programación utilizada para el proyecto desarrollado fue

Visual Basic, la cual es un lenguaje de programación de alto nivel, en donde su

codificación está orientada a eventos producidos sobre objetos. Un evento es una

acción reconocida por un formulario o un control. Las aplicaciones controladas por

eventos ejecutan código Basic como respuesta. Cada formulario y control de Visual

Basic tiene un conjunto de eventos predefinidos. Una vez que se produce uno de estos

eventos, Visual Basic llama al código asociado a éste.

67

Una de las bondades más importantes de Microsoft Visual Basic, es la capacidad

de interacción que posee, debido a que a través de él pueden crearse aplicaciones de

otros programas tales como Excel, Access, entre otros, a través de los cuales es

posible desarrollar programas de mayor complejidad con una gran flexibilidad.

Esta es la razón que motivó a la selección de este software para llevar a cabo el

desarrollo del Sistema COFADI_rc, pues permite la ejecución del código programado

si se produce un evento, manejar bases de datos, utilizar librería para ejecutar algún

proceso específico, lo cual se puede realizar mediante una interface amigable al

usuario, lo que hace que su manipulación sea sencilla. Además, es posible crear

formularios amigables con los cuales puede interactuar el usuario para utilizar la

aplicación creada.

En el desarrollo del proyecto se utilizó una librería para Visual Basic que se

obtuvo mediante investigaciones realizadas en Internet llamada Mobile FBUS, la

cual es un objeto que responde a eventos ya programado, tiene sus propias

instrucciones y desarrolla métodos como cualquier otro objeto de Visual Basic. Esta

librería se encarga de la interpretación de protocolo FBUS de los teléfonos NOKIA

para que se puedan comunicar con los PC y viceversa; con la utilización de esta

librería, se ahorró el trabajo de desarrollar un módulo o procedimiento que realizara

esta labor de interpretación de protocolo FBUS de NOKIA. También se utilizaron en

el desarrollo del proyecto las siguientes herramientas: FTP, SQL, Microsoft Access,

Microsoft Excel, Microsoft Exchange (servidor de correo).

La herramienta o sistema desarrollado puede ser utilizada bajo los sistema

operativos Windows NT y Windows 2000, funcionando perfectamente en los dos

casos. También se hicieron prueba bajo el sistema operativo Windows ME pero solo

de la interface gráfica desarrollada para los usuarios del sistema, la cual también

funcionó perfectamente. Se menciona este aspecto debido a que es necesario que el

68

sistema funcione correctamente con cualquier Sistema Operativo con el que trabajen

las PC.