Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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.