1

APLICACIÓN PARA LA GESTION DE ALARMAS DE LAS CENTRA LES TELEFONICAS DE EMCALI TELECOMUNICACIONES

DIDIER ENRIQUE MOSQUERA CUESTA ALEXANDRA CAROLINA OSPINA RICAURTE

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERIA

DEPARTAMENTO DE AUTOMATICA Y ELECTRONICA PROGRAMA DE INGENIERIA ELECTRONICA

SANTIAGO DE CALI 2006

2

APLICACIÓN PARA LA GESTION DE ALARMAS DE LAS CENTRA LES TELEFONICAS DE EMCALI TELECOMUNICACIONES

DIDIER ENRIQUE MOSQUERA CUESTA ALEXANDRA CAROLINA OSPINA RICAURTE

Pasantia para optar al titulo de Ingeniero Electrónico

Director WILMAN FRANCO ZAFRA

Ingeniero Electrónico

Coordinador del Proyecto en la Empresa LUIS FABIAN TROYANO

Ingeniero de Conmutación

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERIA

DEPARTAMENTO DE AUTOMATICA Y ELECTRONICA PROGRAMA DE INGENIERIA ELECTRONICA

SANTIAGO DE CALI 2006

3

Nota de Aceptación:

Aprobado por el Comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al titulo de Ingeniero Electrónico. Ing. OSCAR AGREDO________________ Jurado

Santiago de Cali, Diciembre de 2006

4

CONTENIDO

Pág. RESUMEN 9 INTRODUCCION 10 1. PLANTEAMIENTO DEL PROBLEMA 11 2. MARCO TEORICO 12 2.1 MySQL 12 2.2 PHP 13 2.3 APACHE 15 3. OBJETIVOS 16 3.1 OBJETIVO GENERAL 16 3.2 OBJETIVOS ESPECIFICOS 16 4. JUSTIFICACION 17 5. METODOLOGIA 18 5.1 REVISIÓN DE DOCUMENTACIÓN DE OPERACIÓN DE LAS CENTRALES TELEFÓNICAS 18 5.2 ANÁLISIS DE LOS ARCHIVOS DE ALARMAS ENTREGADOS POR LAS CENTRALES TELEFÓNICAS 18 5.3 DISEÑO E IMPLANTACIÓN DE BASE DE DATOS 19 5.4 DISEÑO E IMPLANTACIÓN DE LA APLICACIÓN WEB 19 5.5 DESARROLLO DE PRUEBAS DE LA APLICACIÓN 20 5.6 DESARROLLO DEL MANUAL DE USUARIO Y CAPACITACIÓN 20 6. DESARROLLO 21 6.1 REVISIÓN DE DOCUMENTACIÓN DE OPERACIÓN DE LAS CENTRALES TELEFÓNICAS 21 6.1.1 Centrales EWSD de Siemens 21 6.1.2 Centrales AXE de Ericsson 23 6.2 ANÁLISIS DE LOS ARCHIVOS DE ALARMAS ENTREGADOS POR LAS CENTRALES TELEFÓNICAS 26 6.2.1 Centrales EWSD 26 6.2.2 Centrales AXE 29 6.3 DISEÑO E IMPLANTACIÓN DE BASE DE DATOS 34 6.4 DISEÑO E IMPLANTACIÓN DE LA APLICACIÓN WEB 40 6.4.1 Acceso a la Aplicación 40 6.4.2 Restricciones y perfiles de usuario 40 6.4.3 Consultas 40 6.4.4 Actualización de la base de datos 43 6.4.5 Manejo de usuarios que tiene acceso a la aplicación 44 6.5 DESARROLLO DE PRUEBAS DE LA APLICACIÓN 44

5

6.6 DESARROLLO DEL MANUAL DE USUARIO Y CAPACITACIÓN 45 7. DIAGRAMA DE BLOQUE DE LA APLICACIÓN 46 8. CONCLUSIONES 47 BIBLIOGRAFIA 48 ANEXOS 49

6

LISTA DE TABLAS Pág. Tabla 1. Clases de alarmas externas 24 Tabla 2. Funciones de ALLIP 24 Tabla 3. Fallos de las centrales AXE que no han sido solucionados 35 Tabla 4. Guarda todos los fallos solucionados de las centrales AXE 37 Tabla 5. Fallos de las centrales EWSD que no han sido solucionados 38 Tabla 6. Guarda todos los fallos solucionados de las centrales EWSD 39 Tabla 7. Usuarios que están autorizados para entrar a la aplicación 39 Tabla 8. Para ALPRIO, ALSTAT y las centrales 42 Tabla 9. Verificación del buen funcionamiento de la aplicación 44

7

LISTA DE FIGURAS Pág. Figura 1. Arquitectura de la central EWSD 21 Figura 2. Conexión entre los DLU y los LTG 23 Figura 3. Diagrama del sistema de alarmas de las centrales AXE 25 Figura 4. Formato del archivo plano de la central EWSD 28 Figura 5. Archivo plano central EWSD 29 Figura 6. Formato del comando ALLIP 29 Figura 7. Formato del archivo plano de la central AXE 32 Figura 8. Archivo plano central AXE 34 Figura 9. Estadísticas de las alarmas según el fallo 41 Figura 10. Estadísticas EWSD para ALPRIO y las centrales 42 Figura 11. Estadísticas EWSD para ALSTAT y las centrales 43 Figura 12. Filtra y actualiza las bases de datos 43 Figura 13. Diagrama de bloques de la aplicación 46

8

LISTA DE ANEXOS Pág. Anexo A. Distribución de las centrales 49 Anexo B. Manual EWSD 50 Anexo C. Carta del director académico y solicitud de jurados 60 Anexo D. Carta asesor empresarial 61 Anexo E. Manual de Usuario 62

9

RESUMEN Este proyecto llamado APLICACIÓN PARA LA GESTION DE ALARMAS DE LAS CENTRALES TELEFONICAS DE EMCALI TELECOMUNICACIONES fue realizado para las Empresas Municipales de Cali EMCALI EICE ESP en la sede de la Telefónica de Colon. Esta aplicación se basa en la realización de un software que permite a los ingenieros de planta mirar con que frecuencia se están generando las alarmas y el motivo por el cual están sucediendo, además pueden usar estadísticas para analizar cual es el dispositivo o la ruta que mas fallo presenta. Los usuarios que acceden a la aplicación deben crearse primero por un administrador el cual le generar un login y un código para su ingreso, también es el encargado de dar la prioridad al usuario (administrador u operador) ya que de esto depende el excelente manejo de la información que consultan los usuarios en esta aplicación. Todas las centrales telefónicas pueden ser consultadas en esta aplicación, como son las AXE de Ericsson y las EWSD de Siemens; el usuario puede acceder a esta aplicación desde cualquier PC que este conectado al Intranet de la empresa. Para la realización de este proyecto se necesitaron 6 meses, los cuales sirvieron para la documentación de cada central (saber como funciona, cual es el archivo que generan las centrales, como se debe de interpretar este archivo); una vez entendido estos parámetros se empezaron a filtrar los datos mas importantes de cada central, los cuales fueron escogidos en conjunto con los ingenieros a cargo y nosotros.

10

INTRODUCCION Las centrales telefónicas que EMCALI tiene instaladas para la prestación del servicio en la ciudad, requieren de una administración y un soporte eficiente, que debe estar apoyado en herramientas que permitan llevar un control de los problemas que se presentan. Estas centrales generan alarmas, las cuales arrojan información, que permite saber que tipos de fallas se han presentado en el sistema, los cuales se envían a los Centros de Mando para que sean revisadas y reparadas. Sin embargo, no queda un registro histórico detallado de los problemas presentados ni se cuenta con una herramienta para el análisis estadístico de la información. En este proyecto se desarrolló una aplicación Web que permite gestionar la información de alarmas que generan las centrales telefónicas de EMCALI. El proyecto fue realizado en las EMPRESAS MUNICIPALES DE CALI EMCALI EICE ESP, en la sede de la telefónica de Colon en el área de conmutación.

11

1. PLANTEAMIENTO DEL PROBLEMA La presencia de daños es un elemento muy común dentro de la gestión del sistema telefónico en EMCALI, sobre todo teniendo en cuenta el tamaño de la red telefónica de la ciudad. En este proceso de gestión de fallas, EMCALI no cuenta con una herramienta que permita almacenar los datos históricos de las alarmas que generan las centrales telefónicas ni se puede obtener un análisis de los datos que dichas alarmas contienen. Obtener información detallada e histórica de las alarmas presentadas en el sistema les permite a los administradores conocer el comportamiento general y así mismo la detección de fallas comunes en las centrales telefónicas para tomar medidas correctivas o preventivas según sea el caso.

12

2. MARCO TEORICO El Marco Teórico presentado hace referencia a los elementos que se utilizaron en el desarrollo del proyecto. La profundización teórica de cada tema se presentó en el Anteproyecto de Pasantía. Se define la importancia que tiene cada uno de los temas para el desarrollo de la aplicación y el cumplimiento del objetivo del proyecto. 2.1 MySQL Uno de los elementos clave para el desarrollo del proyecto es el Gestor de Bases de Datos, el cual permite organizar e interactuar con los datos de las alarmas que generan las centrales telefónicas. Con una estructura organizada de la información, será mucho más sencillo realizar las tareas de análisis y consultas de las alarmas que se presenten. Se requiere entonces de una herramienta gestora de bases de datos que sea de código abierto, según indicaciones de EMCALI, que permita interactuar con una base de datos relacional, a través de lenguaje estructurado de consultas (SQL). Por lo anterior, se definió como Gestor de Base de Datos a MySQL, la cual es una herramienta muy popular que actualmente está siendo actualizada por desarrolladores de software libre y es ampliamente utilizada en el mundo. Entre las características disponibles en las últimas versiones se puede destacar: � Amplio subconjunto del lenguaje SQL. Algunas extens iones son incluidas

igualmente. Para el desarrollo de la aplicación, es necesario contar con que el gestor aceptará los comandos de consultar más comunes.

13

� Disponibilidad en gran cantidad de plataformas y si stemas. En el proyecto, por condicionamiento de EMCALI, se utilizaron equipos informáticos con Windows XP. MySQL es compatible con este sistema operativo.

� Transacciones y claves foráneas. MySQL permite la interacción con otros gestores de base de datos. A pesar de que el proyecto no abarca este tipo de interacción, se deja disponible en caso de que posteriormente EMCALI requiera migrar la base de datos hacia otra tecnología. � Conectividad segura. El acceso a los datos de la base de datos en MySQL está protegido con contraseñas. Con esto se establece cierto nivel de seguridad para impedir el acceso no autorizado a los datos. Adicionalmente, EMCALI solicitó la creación de usuarios en la aplicación para el acceso a la misma.

� Búsqueda e indexación de campos de texto. Esta propiedad permite que el proceso de búsqueda de información dentro de la base de datos sea relativamente rápido. Dentro del proyecto, esta función es muy importante porque la cantidad de información que generan las centrales telefónicas es bastante grande, lo que hace complejo este proceso. 2.2 PHP PHP es un lenguaje de programación usado para la creación de contenido para sitios web. PHP es el (acrónimo recursivo de "PHP: Hypertext Preprocessor", inicialmente PHP Tools, o, Personal Home Page Tools). Es un lenguaje interpretado usado para la creación de aplicaciones para servidores, o creación de contenido dinámico para sitios Web.

14

Por otro lado, el uso de PHP no genera costos para los clientes ya que su uso es libre. Como condición de implantación entregada por EMCALI, fue necesario utilizar software de este tipo. La interpretación y ejecución de PHP se da en el servidor, en el cual se encuentran almacenados los scripts. El cliente sólo recibe el resultado de la ejecución. Esta ventaja permite que las estaciones no requieran mucho uso de procesamiento al trabajar con la aplicación. Por otro lado, es posible utilizar PHP para generar archivos PDF, Flash, así como imágenes en diferentes formatos; permite la conexión a diferentes tipos de servidores de bases de datos tales como MySQL, Postgres, Oracle, ODBC, IBM DB2, Microsoft SQL Server, Firebird y SQLite. En el caso del desarrollo del proyecto, PHP interactúa sin problemas con el gestor de bases de datos MySQL. PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas operativos tales como UNIX (y de ese tipo, como Linux), Windows y Mac OS X. En el caso del proyecto, el sistema operativo utilizado es compatible con PHP (Windows XP). Ventajas de PHP � La principal ventaja se basa en ser un lenguaje mul tiplataforma. Este lenguaje puede ser utilizado bajo lenguajes de Linux, Windows, etcétera, por lo tanto su manejo no es limitado en sistemas operativos. Dentro del proyecto, esto es muy importante ya que la empresa EMCALI, maneja diversos sistemas operativos y esta aplicación debe ejecutarse en cualquier PC. � Capacidad de conexión con la mayoría de los manejad ores de base de

datos que se utilizan en la actualidad. Este lenguaje puede conectarse a los diferentes programas que manejan base de datos; esto es muy importante debido a que la aplicación no podía limitarse en ningún sistema operativo.

15

� Leer y manipular datos desde diversas fuentes, incl uyendo datos que pueden ingresar los usuarios desde formularios HTML .

PHP tampoco tienen restricciones para la manipulación de datos, estos pueden ser archivos de texto, imágenes, archivos provenientes de paginas de Internet, etcétera. En la empresa EMCALI las aplicaciones deben tener pocas restricciones ya que los sistemas operativos que se manejan pueden variar de acuerdo de a las dependencias. � Posee una muy buena documentación en su página ofic ial. Para la información del manejo de PHP hay bastante documentación ya sea en libros o en Internet; esto facilito poder resolver inquietud que se presentaron a medida que se realizo la aplicación. � Es Libre, por lo que se presenta como una alternati va de fácil acceso para

todos. Este lenguaje de programación no necesita licencia para su manejo. Una de las condiciones de EMCALI fue manejar programas que no necesitaran licencia debido a que no tenían presupuesto para adquirir sistemas operativos. 2.3 APACHE El servidor HTTP Apache es un servidor HTTP de código abierto para plataformas Unix, Windows y otras, lo cual es importante porque como se dijo anteriormente EMCALI nos exige software libres y de código abierto. Apache presenta entre otras características mensajes de error altamente configurables, bases de datos de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude en su configuración. En la actualidad (2005), Apache es el servidor HTTP más usado, siendo el servidor HTTP del 70% de los sitios Web y su manejo esta libre se licencia, un punto clave para ser utilizado en el proyecto.

16

3. OBJETIVOS 3.1 OBJETIVO GENERAL � Diseñar una aplicación que permita almacenar los eventos temporales

reportados por la central de conmutación. 3.2 OBJETIVOS ESPECÍFICOS � Conocer la documentación y el sistema de gestión de EMCALI. � Desarrollar un aplicativo que transforme un archivo plano en una base de

datos. � Diseñar una interfaz de usuario que permita realizar consultas y llevar

estadísticas. � Implementar una aplicación en ambiente Web.

17

4. JUSTIFICACIÓN En una central de conmutación se presentan ciertos eventos “fallos”, que son registrados y actualizados continuamente, después de corregidos los errores temporalmente, no existe ningún control estadístico sobre la información recibida, lo cual ocasiona que se sigan presentando fallas en los mismos puntos, repetidamente disminuyendo la calidad el servicio. Este nuevo sistema le permite saber al operario el resumen histórico de los fallos en dicha central, también determinara que solución darle y en un caso dado, tomara decisiones importantes frente a este evento.

18

5. METODOLOGÍA En la metodología de desarrollo del proyecto, se siguieron los pasos recomendados por EMCALI y los que el grupo de trabajo determinó como relevantes dentro del proceso. En el desarrollo del proyecto se atendieron las solicitudes de EMCALI referentes a sus requerimientos hacia la aplicación. Debido al límite establecido por el cronograma, el cual impedía el análisis profundo de otro tipo de metodologías, estas no fueron tomadas en cuenta formalmente. La metodología que se siguió en el desarrollo del proyecto se describe a continuación. 5.1 REVISIÓN DE DOCUMENTACIÓN DE OPERACIÓN DE LAS C ENTRALES

TELEFÓNICAS. Para establecer los parámetros de diseño de la aplicación, la cual tendrá como soporte de operación la información de alarmas entregada por las centrales telefónicas, es necesario revisar la forma como dichas centrales operan. Las centrales telefónicas que se analizan en este ítem son las AXE de Ericsson y la EWSD de Siemens. 5.2 ANÁLISIS DE LOS ARCHIVOS DE ALARMAS ENTREGADOS POR LAS

CENTRALES TELEFÓNICAS. Como se definirá en el capítulo de desarrollo del proyecto, las centrales telefónicas ofrecen la información de alarmas utilizando archivos planos (de texto). Estos archivos contienen gran cantidad de información, por lo cual es necesario filtrarlos para obtener únicamente la información que se requiere para el análisis y control de las alarmas.

19

La selección de la información de alarmas fue determinada en conjunto con los ingenieros de conmutación de EMCALI. Como se mostrará en el capítulo de desarrollo del proyecto, para obtener en forma eficiente la información de alarmas, se requiere de cierta implementación de software. El software permite que la información relevante de las alarmas pueda ser obtenida por los usuarios en forma rápida. 5.3 DISEÑO E IMPLANTACIÓN DE BASE DE DATOS. Para organizar y tener control sobre la información de alarmas de las centrales y permitir la búsqueda en forma eficiente, se diseña e implanta una base de datos a través de un gestor de base de datos. La base de datos se diseña con base en el diagrama Entidad – Relación, en el cual se describen las características de cada elemento de información. Después de diseñada y aprobada por EMCALI, esta se implementa sobre el gestor de bases de datos que se definió en el inicio del proyecto (MySQL). 5.4 DISEÑO E IMPLANTACIÓN DE LA APLICACIÓN WEB. Por solicitud de EMCALI, la aplicación a desarrollar debe estar estructurada sobre páginas Web, de manera que sea accesible utilizando clientes Web como el Microsoft Internet Explorer. En primer lugar se definen en conjunto con EMCALI los elementos que hacen parte de la aplicación, las consultas requeridas, los procesos de captura y análisis de información. Después de contar con la validación de la información requerida para la aplicación, esta se diseña y se implementa. El grupo de trabajo desarrolló la aplicación con el lenguaje de interpretación de páginas Web recomendado por EMCALI (PHP).

20

Adicionalmente, en la implementación de la aplicación, se atendieron y siguieron las solicitudes de EMCALI referentes a la seguridad de acceso a la misma. 5.5 DESARROLLO DE PRUEBAS DE LA APLICACIÓN. Con el fin de determinar si la aplicación cumple con lo inicialmente planteado, se realiza un protocolo de pruebas que abarca todos los componentes de la aplicación. Las pruebas son realizadas tanto por los integrantes del proyecto como de los ingenieros y técnicos de EMCALI. Sin embargo, el proceso de pruebas inicia desde que se empieza a desarrollar la aplicación. Las pruebas permitieron la realimentación de EMCALI para complementar el trabajo y así cumplir con sus requerimientos. 5.6 DESARROLLO DEL MANUAL DE USUARIO Y CAPACITACIÓN . Para garantizar que la aplicación será utilizada correctamente por los usuarios, se define un manual en el cual se describe el manejo de la aplicación. El manual es entregado a EMCALI dentro del proceso de finalización y aprobación del proyecto. De igual forma, se ofrece a los ingenieros de conmutación de EMCALI la capacitación necesaria para la gestión de la aplicación y la base de datos.

21

6. DESARROLLO 6.1 REVISIÓN DE DOCUMENTACIÓN DE OPERACIÓN DE LAS C ENTRALES

TELEFÓNICAS. Para revisar el funcionamiento de las centrales telefónicas de EMCALI fue necesario solicitar los manuales de las centrales EWSD Y AXE. Estos manuales describen en detalle el funcionamiento de las centrales. 6.1.1 Centrales EWSD de Siemens. Figura 1. Arquitectura de la central EWSD

Cada bloque cumple funciones diferentes para la administración de la central, una de las funciones que se analiza en cada bloque (LTG line trunk group, DLU Digital Line Unit, SN Switching network, etc.) (Ver Anexo B) es la administración de alarmas. Ahora se explicaran los campos mas utilizados para el desarrollo de la aplicación de la Figura 1 llamada arquitectura de la central EWSD:

22

� DLU (Unidad de Línea Digital)

Un DLU puede usarse para conectar al subscriptor de línea y los PBX que acceden las líneas. El DLU puede operarse localmente, o remotamente en el nodo de la red.

El DLU también proporciona la interfaz a las diferentes redes de acceso de línea. Los DLU pueden instalarse como una parte íntegra del interruptor (local) o como una unidad de la línea remota en de un grupo de subscriptores, reduciendo la longitud de líneas de acceso y el tráfico concentrándose al nodo en los eslabones de la transmisión digitales produciendo una red de la línea con la calidad de la transmisión óptima. � LTG (Grupo de Línea Troncal) Los LTG se agrupan con la interfaz entre el ambiente digital del nodo (Ver Figura 1.) y la red cambiando digital (SN). Los LTG realizan las funciones del mando y así relevan la coordinación del procesador (PC) de trabajo rutinario. Varios tipos de LTG están disponibles para la aplicación óptima de los diferentes tipos de la línea y métodos de la señalización. El LTG esencialmente tiene la misma estructura básica y opera según los mismos principios. Ellos sólo difieren en unidades del hardware y la aplicación específica programa en el procesador de grupo (GP). La conexión entre el LTG y SN es hecho por un portador digital secundario (SDC). La proporción de la transmisión en el SDC del LTG al SN y viceversa es de 8192 kbit/s. El LTG siempre transmite y recibe la información a ambos lados del la red cambiando (SN0 y SN1). Ambos SN se encuentran en el mismo lado y reciben la misma información del usuario. El LTG sólo asigna la información de la unidad de la red cambiando al subscriptor. El otro lado de SN se designa como inactivo, transmitiendo y recibiendo la información del usuario actual inmediatamente si una falta ocurre.

23

En la Figura 2. Se muestra la interconexión entre los DLU y los LTG Figura 2. Conexión entre los DLU y los LTG

6.1.2 Centrales AXE de Ericsson.

Descripción del sistema de alarmas � Estructura de bloques del sistema de alarmas Los bloques AL y ALA (Ver Figura 3.) contienen que la alarma funciona dentro del sistema. El bloque ALIM contiene las funciones por definir, borrar, bloquear, y desbloquear de ALI. El bloque ALSA traduce las alarmas que están fuera del sistema (las alarmas externas) al mismo formato y la une a las alarmas internas del sistema. (Ver Tabla 1.)

24

Tabla 1. Clases de alarmas externas

Clases Explicación Local La alarma se recibe en AXE por el

bloque de la función EXAL2 (incluye el hardware).

Transferida La alarma es transferida internamente dentro de AXE, normalmente de un Interruptor del Subscriptor Remoto (RSS). La transmisión de las alarmas externas son recibidas por el bloque de la función EXAL0 (ningún hardware).

� La Unidad de Interfaz de Alarma (ALI) ALI contiene varios rasgos que se listan en la Tabla 2. Tabla 2. Funciones de ALI

Las funciones por dirigir una parada operacional Circuitos por enviar el estado de la alarma a un Funcionamiento del procesador central y Centro de Mantenimiento (OMC) Las interfaz para la conexión de luces que indican asistencia y Tablero de Despliegue de Alarma (ALD)

El sistema de la alarma recibe las alarmas interiores y exteriores, a través del ALI, desplegando el estado de la alarma en los tableros ALD. El ALI también transfiere el estado de la alarma al OMC a través de la interfaz SCAN. ALI se comunica con el Procesador Central (PC) emulando un término. Se conecta físicamente a un V.24 del terminal de la interfaz. Se envían órdenes del PC al ALI como las copias impresas espontáneas, y se envían órdenes del ALI al PC como los órdenes.

25

El stop operacional, o la conexión entre el PC y el programa que dirigen el circuito está rota, el ALI genera una alarma. Después de 0.5-2.5 minutos, el ALI genera una alarma de la advertencia encendiendo las luces de A2 en el ALD. Después de 8 minutos, la alarma de la advertencia se vuelve una alarma del stop operacional. La alarma del stop operacional se indica en el ALD encendiendo las luces de A1 y una alarma intermitente. La alarma intermitente se borra cuando BELL INH encienden el ALI; está en la posición superior. Las luces de A1 continúan encendidas mientras la alarma intermitente se borra. Aun cuando la conexión se restablece, las luces de A1 se encenderán si el interruptor BELL INH se encuentra apagado. Figura 3. Diagrama del sistema de alarmas de las ce ntrales AXE

� Categoría de las alarmas La categoría de las alarmas indica la fuente que genera la alarma. AXE puede manejar 16 categorías de la alarmas. Las categorías se agrupan en el ALD o en las copias impresas de la alarma a la organización de mantenimiento apropiada. Ellos también se agrupan para examinar las categorías de la transmisión de OMC.

26

6.2 ANÁLISIS DE LOS ARCHIVOS DE ALARMAS ENTREGADOS POR LAS CENTRALES TELEFÓNICAS.

Después de conocer toda la información necesaria sobre las centrales telefónicas de EMCALI, se pasa a analizar los archivos planos que arroja cada central en conjunto con los ingenieros de conmutación de EMCALI, que son los encargados del manejo de alarmas, para saber cuales de las variables que entrega eran las más importantes.

6.2.1 Centrales EWSD. Para poder obtener una copia de las alarmas entregadas por la central es necesario conoce el comando DISP ALARM. Este comando despliega el estado de la alarma actual. El formato de entrada es el siguiente: Los parámetros de la entrada son:

OBJECT= ALARM OBJECT Este parámetro especifica el objeto de la alarma. Nota: Si un parámetro se omite, todos sus valores se tomarán en la consideración. Este parámetro permite la entrada de un solo valor, o de valores múltiples se unen con &. A continuación se muestra un la lista de los objetos que se pueden buscar utilizando este parámetro LTG LINE TRUNK GROUP DLU DIGITAL LINE UNIT SN SWITCHING NETWORK MB MESSAGE BUFFER CLOCK CENTRAL CLOCK GENERATOR SYP SYSTEM PANEL

DISP ALARM: [OBJECT=] [, ALSTAT=] [, ALPRIO];

27

CCS COMMON CHANNEL SIGNALING SIGLINK SIGNALING LINK CU CENTRAL UNITS LNL CKOUT LINE LOCKOUT MAL MAINTENANCE ALARM SAL SERVICE ALARM TGAL TRUNK GROUP ALARM TIMINSEC TIME INSECURE SYOP CALL FOR SYSTEM OPERATOR EALEXCH EXTERNAL EXCHANGE ALARM EALDLU EXTERNAL DLU ALARM RECOV RECOVERY ALARM ADMINAL ADMINISTRATION ALARM

ALSTAT= ALARM STATUS Este parámetro describe el estado y la condición de la alarma. El código del proceso es una parte de la alarma archivada a la entrada. Nota: Si un parámetro se omite, todos sus valores se tomarán en consideración. Este parámetro permite la entrada de un solo valor, o de valores múltiples unidos con &. A continuación se muestra un la lista de los objetos que se pueden buscar utilizando este parámetro NP NOT PROCESSED D DEFERRED IP IN PROCESS UR UNDER REPAIR ALPRIO= ALARM PRIORITY Este parámetro especifica la prioridad de la alarma. Nota: Si un parámetro se omite, todos sus valores se tomarán en consideración. Este parámetro permite la entrada de un solo valor, o de valores múltiples unidos con

28

&. A continuación se muestra un la lista de los objetos que se pueden buscar utilizando este parámetro MINOR MINOR ALARM MAJOR MAJOR ALARM CRITICAL CRITICAL ALARM Para el desarrollo de esta aplicación solo se utilizo el comando DISP ALARM sin ningún paramento específico, debido a que EMCALI necesitaba el control de todas las alarmas sin omitir alguna. Los campos definidos para filtrar de este comando son: OBJECT: Es el bloque dentro de la central que presenta fallas ALPRIO : corresponde al tipo de fallo o que tan grave es la alarma ALSTAT , MSGNO, ALTYPE , PABCAUSE , ALARM-ID, (Ver Anexo B) Estos parámetros describen cualquier alarma en una central EWSD de Siemens como se muestra en el formato mostrado en la Figura 4. Figura 4. Formato del archivo plano de la central E WSD

La Figura 5 es un ejemplo de un archivo plano generado por el comando DISP ALARM

29

Figura 5. Archivo plano central EWSD

6.2.2 Centrales AXE. Para conocer el archivo que generan las alarmas en esta central se utiliza un comando llamado ALLIP , el cual se ejecuta desde la conexión de emulación de terminal de la central telefónica. A continuación se muestra el formato (Ver Figura 6.) de cómo el comando muestra la función, lista y la impresión de las alarmas.

Figura 6. Formato del comando ALLIP

ALLIP:

30

A continuación se muestran los parámetros que tiene el comando, estos se utilizan para especificar la búsqueda. � Parámetros del comando

ACL=acl La clase de la alarma Según los datos de clase de alarma, listó por el orden ALCLP. Identificación 1 - 2 caracteres Todas las alarmas definidas y clasificadas

ALCAT=alcat La categoría de despliegue de alarma Según los datos de categoría de alarma, listó por el orden ALACP. Si el valor de este parámetro contiene los caracteres especiales, el valor del parámetro debe rodearse por comilla. El ejemplo: "E/S-DEV." Identificador 1 - 7 caracteres TODOS Todas las categorías de despliegue de alarma definidas

FID=fid Alarme la identidad de Forlopp Decida si la alarma la identidad de Forlopp será incluida o no será incluida en la copia impresa de lista de alarma. SÍ La información incluyó NO La información no incluyó Por defecto es NO

IO=io Input/Output ( E/S) del dispositivo Expresado como el dt-n dónde: el dt El tipo de dispositivo de E/S Identificador 1 - 5 caracteres n El número de dispositivo de E/S Número 0 – 9999

PRCA=prca La categoría de la copia impresa Número 1 - 127

31

� Función del comando ALLIP

Este comando imprime la lista de la alarma entera o una parte ella.

El comando EJECUTADO o NO EJECUTADO recibe la clasificación del dispositivo de E/S cuando la lista de la alarma se recibe un dispositivo de E/S.

La selección es hecha por el parámetro ALCAT o por el parámetro PRCA, o por ambos.

Si todos los parámetros son omitidos, una copia impresa de la lista de la alarma será recibida.

Cada alarma está impresa con la fecha y la hora cuando la alarma fue comenzada. Si la copia impresa se desea en un dispositivo de otra manera que el dispositivo de la clasificación, esto se indica con el parámetro IO (E/S). El parámetro FID se usa para decidir si la alarma de identidad Forlopp será incluida o no en la copia impresa de lista de alarma. El valor predefinido es NO. El operador puede interrumpir una copia impresa en marcha.

El orden no permanece después de que el sistema se reinicie. Se mostraran algunos ejemplos del comando mencionado anteriormente: � Ejemplo 1 ALLIP; La lista de la alarma entera está impresa en el dispositivo de E/S de clasificación, sin la alarma la identidad de Forlopp.

32

� Ejemplo 2 ALLIP:IO=AT-4,ALCAT=APZ; Una copia impresa de las alarmas existentes en la lista de la alarma con la categoría de la alarma APZ se imprimirá en el dispositivo del E/S A-4, sin la alarma la identidad de Forlopp.

� Ejemplo 3 ALLIP:IO=AT-0,ALCAT="IO-DEV"; Una copia impresa de las alarmas existentes en la lista de la alarma con la categoría de la alarma E/S-DEV se imprimirá en el dispositivo del E/S A-0, sin la alarma la identidad de Forlopp. En el desarrollo del proyecto se utilizo como el ejemplo 1, debido a que se deben listar todas las alarmas, para así manejar la información completa

� Archivo entregado por el comando Figura 7. Formato del archivo plano de la central A XE

33

En la figura 7 se muestra una copia impresa del archivo de alarmas generado por medio del comando ALLIP; este comando arroja diferentes parámetros, estos se explicaran a continuación � Parámetros del archivo entregado por el comando ALL IP Alcat . Categoría de la alarma esta categorías vienen dadas por A1, A2, A3, O1, O2. Este parámetros no dice con que prioridad debemos atender el fallo A1 es el mas grave y O2 es el menos urgente Alinfo Información de la alarma. Muestra el nombre del fallo que se presento y su ubicación Date: La fecha de iniciación de la alarma Origin : Intercambio de origen. Indica a que central pertenece la alarma. Time: Hora de iniciación de la alarma expresado hh:mm. La fecha y tiempo indica cuando la alarma fue comenzada.

� Función del archivo

La copia impresa se recibe como una copia impresa de la respuesta para el comando ALLIP. Lista toda o una selección de las alarmas activas en el intercambio, dependiendo del formato de orden ALLIP. La copia impresa también puede recibirse periódicamente como una copia impresa del resultado pedida, comenzada por el orden ALLTC. El OFC del parámetro, indica el número de alarmas en que no podrían entrarse en el sistema de la alarma debido a una falta de espacio. Si el OFC del parámetro registra un valor mayor que ceros (0), entonces las lámparas de la alarma incluso pueden iluminar cuando la lista de la alarma está vacía. Si el bloque del usuario no contesta dentro de un tiempo especificado, una indicación se recibe en lugar de la información de la alarma.

34

Este es un ejemplo del archivo plano entregado por el comando ALLIP (Ver Figura 8.) Figura 8. Archivo plano central AXE

6.3 DISEÑO E IMPLANTACIÓN DE BASE DE DATOS. Para organizar y tener control sobre la información filtrada de alarmas de las centrales y permitir que la búsqueda en forma eficiente, se diseña e implanta una base de datos a través de un gestor de base de datos (MYSQL). Las bases de datos se diseñan con base en el diagrama Entidad – Relación, en el cual se describen las características de cada elemento de información. Se crearon cinco tablas par dar un orden a la información filtrada. El objetivo de cada tabla se describe a continuación. La Tabla 3, llamada AXE, corresponde a los fallos presentados en las centrales AXE, cuando se actualiza la base de datos con un nuevo archivo plano y se encuentra que hay unas alarmas dentro de la centrales AXE que ya fueron

35

solucionadas, estas son borradas de la Tabla 3 y se guardan en la Tabla 4, llamada AXE 1. El procedimiento para las centrales EWSD es el mismo, se crea una tabla llama EWSD (Ver Tabla 5.). En esta tabla se guardan la alarma que no han sido solucionadas y las alarmas que ya fueron solucionadas quedan guardadas en una tabla llamada EWSD1 (Ver Tabla 6.). Para la implementación del sistema de seguridad de acceso a la aplicación se crea una nueva tabla llamada TBUSUARIOS (Ver Tabla 7.) en esta tabla se registran todos lo usuarios que tienen acceso al manejo de alarmas. A continuación se presenta el diagrama de entidad relación de las bases de datos. � LISTADO DE PÁRAMETROS DE LAS TABLAS DE LA BASE DE D ATOS Tabla 3. Fallos de las centrales AXE que no han sid o solucionados

Nombre y tipo Función NUM int(8) Numero de alarma en la base de datos FALLO char(3) Prioridad de la alarma TIPO_FALLO char(100) Nombre de la alarma

FECHA date Fecha HORA time Hora DIP char(10) Digital path. RUTA char(18) Route designation NVD int(4) Number of devices BLO int(4) Number of blocked devices SNT char(50) Switching Network Terminal LS char(18) Link set SPID char (18) Signalling point identity SLC int(4) Subscriber Line Circuit ST char(18) Signalling Terminal REF char(18) DIP STATE char(10) State of the network port FCODE int(4) Fault code PORT char(18) Single link port or logical link port STADO char(10) Port state

36

LU char(18) Physical line unit SPG int(10) Support processor group. NODE char(8) Node within SPG. TYPE char(18) Type DETY char(10) Device type NDEV int(4) Number of connected lines per device type or

subscriber line group. NLOUT int(4) Number of lines in line lockout per device type

or subscriber line group. LVT int(4) Limit value, time in line lockout NAME char(50) Name SWS char(18) Switching stage LVB int(4) Limit value blocking ADL int(4) Allowed Disturbance Level (%). DEST char(18) Destination point NACTSL int(4) Number of active signalling links BLOCK char(10) BLOCK SWM char(18) Switching module TCASE INT(4) Test case RP int(4) RP address TWIN int(4) Twin RP address EM int(4) EM address UNIT char(20) Unit EMG char(18) Extension Module Group CAW1 char(100) Alarm slogan CAW2 char(100) Alarm details RP1 int(4) RP address RP2 int(4) RP address RP3 int(4) RP address RP4 int(4) RP address RP5 int(4) RP address RP6 int(4) RP address RP7 int(4) RP address RP8 int(4) RP address RP9 int(4) RP address VOLUME char(10) Alarm limit (0-100 followed by '%'). LIMI char(5) Volume name DEV1 char(10) External alarm receiver name DEV2 char(10) External alarm receiver name DURACION INT(6) días desde la iniciación de la alarma SOLUCION int(1) Si se soluciono continua

37

Tabla 4. Guarda todos los fallos solucionados en la s centrales AXE

Nombre y tipo Función NUM int(8) Numero de alarma en la base de datos FALLO char(3) Prioridad de la alarma TIPO_FALLO char(100)

Nombre de la alarma

FECHA date Fecha HORA time Hora DIP char(10) Digital path. RUTA char(18) Route designation NVD int(4) Number of devices BLO int(4) Number of blocked devices SNT char(50) Switching Network Terminal LS char(18) Link set SPID char (18) Signalling point identity SLC int(4) Subscriber Line Circuit ST char(18) Signalling Terminal REF char(18) DIP STATE char(10) State of the network port FCODE int(4) Fault code PORT char(18) Single link port or logical link port STADO char(10) Port state LU char(18) Physical line unit SPG int(10) Support processor group. NODE char(8) Node within SPG. TYPE char(18) DETY char(10) Device type NDEV int(4) Number of connected lines per device type or

subscriber line group. NLOUT int(4) Number of lines in line lockout per device type or

subscriber line group. LVT int(4) Limit value, time in line lockout NAME char(50) Name SWS char(18) Switching stage LVB int(4) Limit value blocking ADL int(4) Allowed Disturbance Level (%). DEST char(18) Destination point NACTSL int(4) Number of active signalling links BLOCK char(10) BLOCK SWM char(18) Switching module TCASE INT(4) Test case

38

RP int(4) RP address TWIN int(4) Twin RP address EM int(4) EM address UNIT char(20) Unit EMG char(18) Extension Module Group CAW1 char(100) Alarm slogan CAW2 char(100) Alarm details RP1 int(4) RP address RP2 int(4) RP address RP3 int(4) RP address RP4 int(4) RP address RP5 int(4) RP address RP6 int(4) RP address RP7 int(4) RP address RP8 int(4) RP address RP9 int(4) RP address VOLUME char(10) Alarm limit (0-100 followed by '%'). LIMI char(5) Volume name DEV1 char(10) External alarm receiver name DEV2 char(10) External alarm receiver name DURACION INT(6) días desde la iniciación de la alarma SOLUCION int(1) Si se soluciono continua

Tabla 5. Fallos en las centrales EWSD que no han si do solucionados

Nombre y tipo Función NUM int(8) Enumera las alarmas presentes en la central CENTRAL char(10) A que central pertenece el fallo OBJECT char(25) Que bloque de la central esta fallando ALPRIO char(10) Que tan grave es la alama ALSTAT char(10) Estado de la alarma (NP no procesada y IP en

proceso) MSGNO int(10) Numero de mensaje (Esta relacionado con la fecha y

hora) ALTYPE char(125) Tipo de alarma PABCAUSE char(125)

Probable causa por la que se presento la alarma

ALARM char(125) El informe de estado de alarma SOLUCION int(1) Indaca si la alarma fue solucionada o no

39

Tabla 6. Guarda todos los fallos solucionados en la s centrales EWSD

Nombre y tipo Función NUM int(8) Enumera las alarmas presentes en la central CENTRAL char(10) A que central pertenece el fallo OBJECT char(25) Que bloque de la central esta fallando ALPRIO char(10) Que tan grave es la alarma ALSTAT char(10) Estado de la alarma (NP no procesada y IP en

proceso) MSGNO int(10) Numero de mensaje (Esta relacionado con la fecha y

hora) ALTYPE char(125) Tipo de alarma PABCAUSE char(125)

Probable causa por la que se presento la alarma

ALARM char(125) El informe de estado de alarma SOLUCION int(1) Indica si la alarma fue solucionada o no

Tabla 7. Usuarios que están autorizados para entrar a la aplicación

Nombre y tipo Función nombre varchar(60) Nombre y apellido del usuario identificacion varchar(20) Código de la empresa Login varchar(10) Nombre para entra a la aplicación Password blob Clave para ingresar privilegio varchar(20) Privilegio (operador o administrador) fecha date Fecha de creación de usuario fallo int(1) Fallos al ingresar a la aplicación activo varchar(20) Estado del usuario (bloqueado o

desbloqueado) Para la creación de las bases de datos se utilizo PHP y SQL; primero se realizo la conexión con el gestor MySQL y luego se definieron los campos que se citaron en las Tablas 3, 4, 5, 6 y 7; fue necesario utilizar el comando CREATE TABLE de MySQL definiendo con ello el tipo y el tamaño de cada uno de los campos.

40

6.4 DISEÑO E IMPLANTACIÓN DE LA APLICACIÓN WEB. Para el diseño e implementación de la aplicación fue necesario consultar con los ingenieros que tenían a su cargo el manejo de alarmas. Se tomaron las siguientes decisiones 6.4.1 Acceso a la Aplicación. La consulta de la aplicación se debe realizar desde cualquier computador que esté sobre la red interna de EMCALI. A lo que se quiere con esto es a no tener copias de la aplicación en todos los computadores. 6.4.2 Restricciones y perfiles de usuario. En la implementación de la aplicación, se atendieron y siguieron las solicitudes de EMCALI referentes a la seguridad de acceso a la misma. Por eso fue necesario manejar dos perfiles dentro de la página llamados operador y administrador, la diferencia que tienen estos perfiles es que los operadores no pueden administrar usuarios y no tiene conocimiento sobre el manejo de la base de datos. Para dar una mayor seguridad ha nuestra pagina se utilizaron sesiones, esto impide que una persona que no se encuentre registrada en la base de datos no pueda ingresar a la aplicación. 6.4.3 Consultas. La consulta de las tablas debe ser dinámica y deben presentarse gráficos estadísticos. Se dividieron las consultas según la central para que la consultas sean más fácil a la persona que ingresa a la aplicación. � Consulta AXE En reunión con los ingenieros de conmutación se solicitaron algunos criterios que debe llevar la aplicación para que la búsqueda sea más eficiente La búsqueda debe hacerse por:

FALLO , para saber que tan grave es la alarma

41

CENTRAL , a que central pertenece este fallo RUTA, la ruta del dispositivo que se daño TIPO DE FALLO, el nombre del fallo FECHA y HORA, la fecha y hora en que se presento la alarma. Para una búsqueda mas rápida se realizó una grafica de estadísticas teniendo en cuenta el tipo de fallo y la central donde de se presenta. La elaboración de esta grafica fue posible gracias a una librería llamada jpgraph versión 1.20.5. Compatible con php4 y php5. Para utilizar esta librería solo se necesita entregar el nombre de los campos y el valor de cada uno de los de ellos. La Figura 8 muestra el dato estadístico de las alarmas según su nivel de fallo

Figura 9. Estadísticas de las alarmas según el fall o

CENTRAL A1 A2 A3 O1 O2 TOTAL

Todas 18 67 44 76 10 215

Dentro de las consultas de las centrales AXE también podemos hacer otro tipo de búsqueda para saber datos históricos; aquí se guardan los fallos que ya fueron solucionados � Consulta EWSD Al igual que las centrales AXE para estas centrales también se definieron parámetros de búsqueda en las alarmas (Ver Tabla 5.). Los criterios de búsqueda que se definieron fueron los siguientes.

42

CENTRAL , a que central pertenece (Ver Anexo A) ALPRIO , corresponde a que tan prioritaria es la alarma, la más grave es CRITICAL y la menos grave es MINOR ALSTAT , por estado de la alarma si es NP (no procesada) o IP (en proceso). O por el criterio de búsqueda donde se incluyen los demás campos de la tabla. Para las estadísticas de las centrales EWSD hay dos parámetros: el primero ALPRIO (minor, major, critical), el segundo ALSTAT (NP, IP); su grafico se divide en prioridades (Ver Figura 10.) y estados (Ver Figura11.). En la Tabla 8 muestra cuales de la alarmas cumplen con las siguientes condiciones de ALPRIO y ALSTAT.

� ESTADISTICAS EWSD Tabla 8. Para ALPRIO, ALSTAT y las centrales

CENTRAL ALPRIO TODAS MINOR MAJOR CRITICAL TOTAL

IP 72 32 46 150 ALSTAT NP 55 18 9 82

Figura 10. Estadísticas EWSD para ALPRIO y las cen trales

CENTRAL MINOR MAJOR CRITICAL TOTAL TODAS 127 50 55 232

43

Figura 11. Estadísticas EWSD para ALSTAT y las cent rales

CENTRAL IP NP TOTAL TODAS 150 82 232

La página de consulta EWSD también tiene un link llamado alarmas solucionadas que corresponde a la consulta de la Tabla 6, donde se puede buscar las alarmas que fueron solucionadas. 6.4.4 Actualización de la base de datos. En este modulo el usuario que desee actualizar la base datos debe escoger el archivo y el tipo de central desea filtrar (EWSD o AXE), el usuario presiona el botón ACEPTAR, la aplicación filtra el archivo y lo guarda el la base de datos (Ver Figura 12.). Figura 12. Filtra y actualiza las bases de datos

44

6.4.5 Manejo de usuarios que tiene acceso a la apli cación. Para el manejo de los usuarios que tiene acceso a la aplicación fue necesario crear una prioridad de administrador a cierto personal de EMCALI, quienes son los encargados de crear, borrar, bloquear y desbloquear a los usuarios que pueden entrar a esta aplicación. Para crear un usuario se necesitan los siguientes datos nombre y apellido, la identificación que para la empresa va ser el código de la empresa, un login que debe ser diferente para cada usuario esto lo define quien lo este creando, una contraseña y un privilegio que puede ser operador o administrador según las funciones en la empresa. Para borrar un usuario es necesario conoce el nombre y su identificación. Bloquear y desbloquear un usuario el administrador lo puede hacer cuando lo crea conveniente. Se pueden listar todos los usuarios que tienen acceso a esta aplicación (administrador y operador).

6.5 DESARROLLO DE PRUEBAS DE LA APLICACIÓN. Con el fin de determinar si la aplicación cumple con lo inicialmente planteado, se realiza un protocolo de pruebas que abarca todos los componentes de la aplicación. Las pruebas son realizadas tanto por los integrantes del proyecto como de los ingenieros y técnicos de EMCALI. Tabla 9. Verificación del buen funcionamiento de la aplicación

Nombre de la prueba Función OK Login y password funcionan correctamente

Diferencia entre operador y administrador

Acceso

Manejo de sesiones

Muestra todas las tablas en su totalidad

45

Los criterios de busque funcionan correctamente en todas las tablas

Diferencia entre las alarmas solucionadas y las no solucionadas

Consulta

Grafica estadística Filtra todos el archivo deseado

Actualizar Guarda correctamente en la base de datos todos el archivo filtrado

Se pueden crear usuarios Borra los usuarios creados por el administrador Bloquea y desbloquea los usuarios

Usuarios

Lista todos los usuarios que tienes acceso a la pagina

Cambiar clave Cambia la clave si el usuario lo desea

6.6 DESARROLLO DEL MANUAL DE USUARIO Y CAPACITACIÓN . Para garantizar que la aplicación será utilizada correctamente por los usuarios, se define un manual en el cual se describe el manejo de la aplicación. Este manual fue revisado y aprobado por los ingenieros de conmutación de EMCALI (Ver Anexo E.)

46

7. DIAGRAMA DE BLOQUE DE LA APLICACIÓN Con el diagrama de bloques mostrado en la Figura 13 se da a conocer las páginas a las que el administrador (línea roja) y el operador (línea azul) pueden acceder. Lo primero que se debe de hacer es entrar al portal en el cual el usuario debe validar su ingreso a la aplicación utilizando un password y un login personal, dependiendo de que privilegios tienen así mismo accederá a un numero de paginas determinadas. La diferencia que manejan estos dos usuarios es que el operador no tiene acceso a la página de usuarios, mientras que el administrador sí; dándole el privilegio de crear, borrar, listar y bloquear los usuarios. En el manual de usuario se ve detalladamente el funcionamiento de la aplicación (Ver Anexo E.) Figura 13. Diagrama de bloques de la aplicación

47

8. CONCLUSIONES � Los parámetros a filtrar son los datos mas importantes en el manejo de esta

aplicación, pues de estos dependen la información que el usuario pueda consultar

� Es muy importante manejar un registro histórico de las alarmas, pues con esto

se puede saber con que frecuencia se presenta un fallo que altere el funcionamiento del sistema.

� Con los datos estadísticos se pueden tomar decisiones en el momento que se

presente diversas alarmas, solucionando principalmente las de mayor privilegio.

� Esta aplicación se debe acceder desde un PC que este conectado a la red de

área local, además el usuario debe poseer un login y un password el cual le permitirá ingresar a este proyecto.

� El manejo de los usuarios es muy importante debido a que el administrador es

el encargado de la creación, el bloqueo y la eliminación de las personas que pueden acceder a la aplicación, además este proyecto maneja un administrador superior que es el único que cuando se bloqueen todos los usuarios puede volver a habilitarlos.

48

BIBLIOGRAFIA Alex Application Active Library Explorer for Windows: Command Manual CO64CAS-LOCAL 7.2, 1/AXE 106 108/A67 R3A & APZ 212 20/220 R2C/13, CNG03. Version 0.8.1.0. Telefonaktiebolaget LM. Suecia: Ericsson, 2003. 1 v. Articulo sobre Ericsson: Historia, Toma forma la Ericsson moderna, Enlaces externos [en línea]. Florida (Estados Unidos): Wikipedia, la enciclopedia libre, 2001. [Consultado 15 de Agosto de 2006]. Disponible en Internet: http://es.wikipedia.org/wiki/Ericsson Articulo sobre JavaScript: Definición, Sintaxis del lenguaje, Enlaces externos [en línea]. Florida (Estados Unidos): Wikipedia, la enciclopedia libre, 2001. [Consultado 15 de Agosto de 2006]. Disponible en Internet: http://es.wikipedia.org/wiki/JavaScript EWSD, Digital Electronic Switching System: Command Manual.CML Version 12. APS-ID: KOLCBZ1V.12. P30305-V6000-Z337-1-761. Alemania: SIEMENS AG, 1998. 1 v. Historia, Evolución histórica de EMCALI Energía, Acueducto [en línea]. Santiago de Cali: Empresas Municipales de Cali, EMCALI, 2000. [Consultado 15 de Mayo de 2006]. Disponible en Internet: http://www.emcali.com.co/HistoriadeEmcali/historia.html Manual de PHP [en línea]. México: Yahoo! Inc, 2002. [Consultado 30 de Abril de 2007]. Disponible en Internet: http://www.php.net/docs.php. Manual de MySQL: Manual de usuario versión 5.0.18-win32 [en línea]. México: W3C HTML 4.0, 2002. [Consultado 30 de Abril de 2006]. Disponible en Internet: http://es.tldp.org/ManualesLuCAS/manual_PHP/manual_PHP/odbc/instalar_myodbc.htm STALLINGS, William. Comunicaciones y Redes de Computadores. 5 ed. Madrid: Prentice-Hall, 1998. 792 p. Tesis y otros trabajos de grado [en línea]. Bogota: Instituto Colombiano de Normas Técnicas y Certificación, INCONTEC, 1996. [Consultado 30 de Agosto de 2006]. Disponible en Internet: http://www.icontec.gov.co

49

ANEXOS

Anexo A. Distribución de las centrales

Nodo SIG Tipo Central Ubicación Espacio Dis. Mts 2

Uso Intercon.

Alfonso López 2

ALF2 EWSD Calle 33 Kra 7AN 30 Local

Centro 1 CEN1 AXE Kra 7 13-122 Local Centro 3 CEN3 EWSD Kra 7 13-122 Local Centro 5 CEN5 AXE-TANDEM Kra 7 13-122 General (1) Colón 2 COL2 AXE-TANDEM CLL 14 33-40 30 General Colón 3 COL3 AXE CLL 14 33-40 Local Colón 4 COL4 EWSD CLL 14 33-40 Local

Guabito 3 GUA3 AXE – TANDEM

Calle 34 8ª-165 20 General

Guabito 4 GUA4 AXE Calle 34 8ª-165 Local Guabito 5 GUA5 EWSD Calle 34 8ª-165 Local La Flora 1 LFL1 AXE Av. 3N 53N-11 6 Local Limonar 1 LIM1 AXE Kra 75 Calle 15 6 Local Limonar 2 LIM2 EWSD Kra 75 Calle 15 Local Peñón 1 PEÑ1 AXE Kra 3 Oeste 1-24 30 Local

Poblado 5 POB5 AXE Calle 62 T 28-04 30 Local Prados de Sur

1 PDS1 AXE Kra 80 Calles

2C,2B 30 Local

Salomia 1 SAL1 AXE Kra 1D 52-05 6 Local Salomia 2 SAL2 EWSD Kra 1D 52-05 Local

Marroquín 3 MAR3

EWSD Kra 27 Calle 103 30 Local

San Fdo. 2 SFD2 EWSD Kra 25 5-35 30 Local San Luis 4 SNL4 AXE Kra 1ª5 72-05 30 Local

Tequenda. 2 TEQ2 AXE Calle 6 44-110 30 Local Tequenda. 6 TEQ6 EWSD Calle 6 44-110 Local

Unión 4 Uvi4 AXE Kra 41F 46-00 30 Local Yumbo 3 YUM

3 EWSD Kra 4 5-01 15 Local

Versalles 2 VER2 EWSD Av. Estación 5AN-56

30 Local

50

Anexo B. Manual EWSD

51

52

53

54

55

56

57

58

59

60

Anexo C. Carta del director académico

Santiago de Cali, 7 de Diciembre de 2006 Ingeniero Oscar Fernando Agredo Director Programa Ingeniería Electrónica Universidad Autónoma de Occidente. Asunto: Aceptación dirección de Proyecto de grado. Con la presente me permito informarle el siguiente informe final de pasantía titulada “APLICACIÓN PARA LA GESTION DE ALARMAS DE LAS CENTRALES TELEFONICAS DE EMCALI TELECOMUNICACIONES”, del cual soy director académico de proyecto, desarrollado por los estudiantes DIDIER ENRIQUE MOSQUERA CUESTA con código 1007840 y ALEXANDRA CAROLINA OSPINA RICAURTE con código 2015357, en la Empresa: EMPRESAS MUNICIPALES DE CALI EMCALI EICE ESP, con una duración de 6 meses; cumple satisfactoriamente en contenido y forma con lo planteado inicialmente en el anteproyecto. Considerando lo anterior, ratifico que este proyecto ha sido revisado y aprobado por cumplir con los estándares de un proyecto de opción de grado. De igual manera me permito solicitar la asignación de jurados y programar la fecha para la sustentación. Atentamente, WILMAN FRANCO ZAFRA Docente Departamento de Ciencias de la Información Director Académico de la Pasantía

61

Anexo D. Carta del asesor empresarial

Santiago de Cali, 7 de Diciembre de 2006 Ingeniero Oscar Fernando Agredo Director Programa Ingeniería Electrónica Universidad Autonoma de Occidente. Asunto: Aceptación dirección de Proyecto de grado. Con la presente me permito informarle que el siguiente informe final de la pasantía titulada “APLICACIÓN PARA LA GESTION DE ALARMAS DE LAS CENTRALES TELEFONICAS DE EMCALI TELECOMUNICACIONES”, desarrollado por los estudiantes DIDIER ENRIQUE MOSQUERA CUESTA con código 1007840 y ALEXANDRA CAROLINA OSPINA RICAURTE con código 2015357, en la Empresa: EMPRESAS MUNICIPALES DE CALI EMCALI EICE ESP, con una duración de 6 meses; de la cual soy el asesor empresarial cumple satisfactoriamente en contenido inicialmente estipulado para el desarrollo del proyecto en la empresa. Cordialmente, LUIS FABIAN TROYANO Asesor empresarial

62

Anexo E. Manual de usuario

EMPRESAS MUNUCIPALES DE CALI

EMCALI E.I.C.E. E.S.P

ANALISIS DE ALARMAS EN LAS CENTRALES DE COMUNICACIO NES

Manual del usuarioManual del usuarioManual del usuarioManual del usuario

63

INDICE

Pág.

1.0. INTRODUCCION 64

2.0. ACCESO AL SISTEMA 65

3.0. PRIVILEGIOS 67

4.0. UTILIZACION DEL SISTEMA 69

4.1. CONSULTAR 69

4.1.1. Consultar AXE 70

4.1.1.1. Alarmas AXE solucionadas 71

4.1.1.2. Estadísticas AXE 72

4.1.2 Consultar EWSD 73

4.1.2.1. Alarmas EWSD solucionadas 74

4.1.2.2. Estadísticas EWSD 75

4.2. ACTUALIZAR 76

4.3. CAMBIO DE CLAVE 77

4.4. USUARIOS 78

4.4.1. Crear 79

4.4.2. Borrar 80

4.4.3. Bloquear 81

4.4.4. Listar 82

4.5. CERRAR SESION 83

64

1.0. INTRODUCCION

Análisis de las alarmas en las centrales de comunicaciones fue realizado con el fin de optimizar los procesos realizados en dicha aplicación. A esta aplicación, se le puede acceder desde cualquier computador, teniendo den cuenta que debe estar conectado a la red interna de EMCALI (Intranet), permitiendo al usuario consultar datos de alarmas sin desplazarse de su oficina; en la aplicación los datos a consultar pueden ser cargados desde un computador central (Servidor) o desde cualquier computador. Este manual será de gran ayuda para el usuario ya que explica paso a paso el funcionamiento de cada uno de los módulos utilizados en esta aplicación.

65

2.0. ACCESO AL SISTEMA

Se accede al sistema como una página de Internet. Para ingresar, Usted debe escribir http://localhost/alarma/PORTAL.php

Figura 1.

Esta dirección ingresa al portal que es el lugar de ingreso para la aplicación. El usuario deberá ser registrado por el administrador el cual generara un login y un password; después de ingresar dichos campos se debe presionar el botón ACEPTAR para ingresar a la aplicación (Ver Figura 2.). Si el usuario digita mal su contraseña (hasta tres veces) quedara bloqueado automáticamente y deberá ponerse en contacto con el administrador para reactivar su cuenta.

66

Figura 2.

67

3.0. PRIVILEGIOS Reciben esta denominación las personas que pueden acceder al Sistema. Existen dos niveles de acceso al sistema, uno permite solo realizar consultas y el otro operar en el sistema (Ver Figura 3 y Figura 4) � Administrador: Se refiere a los responsables designados de La creación de

usuarios que pueden ingresar a esta aplicación; al igual que el operador puede consultar y actualizar (Ver Figura 3).

� Operador: Este grupo puede acceder al sistema solo para consultar y

actualizar los archivos planos que entregan las centrales. Este tipo de usuario no posee la facultad para crear nuevos usuarios. (Ver Figura 4)

Figura 3.

68

Figura 4.

69

4.0. UTILIZACIÓN DEL SISTEMA 4.1. CONSULTAR Permite realizar consultas sobre los fallos que se han presentado hasta el momento, para realizar estas consultas se debe escoger uno de los dos tipos de centrales AXE o EWSD (Ver Figura 5).

Figura 5.

70

4.1.1. CONSULTA AXE Dentro de las consultas AXE podemos buscar por: � Fallo: el usuario puede escoger el nivel de alarma (A1, A2, A3, O1, O2) � Central: son todas las centrales AXE de EMCALI � Ruta: es la ruta por donde se genero el fallo � Tipo de fallo, fecha u hora: son otros criterios de búsqueda Los criterios mencionados anteriormente se pueden ver en la Figura 6, cuadro A. Si el usuario no selecciona ningún criterio de búsqueda se listaran todas las alarmas registradas en la base de datos. Podemos ver un link que nos lleva a las estadísticas de las centrales AXE (Ver Figura 6, cuadro B). Si solo se desea ver las alarmas ya solucionadas se da clic al link de alarmas solucionadas (Ver Figura6, cuadro C)

Figura 6.

B

A

C

71

4.1.1.1. ALARMAS AXE SOLUCIONADAS Dentro de las consultas AXE podemos utilizar un solo criterio de búsqueda, con este podemos realizar búsqueda por FALLO, TIPO DE FALLO, CENTRAL, FECHA Y HORA (Ver Figura 7, cuadro A). Para retornar a la consulta de la alarmas no solucionadas se debe que dar clic en volver AXE (Ver Figura 7, cuadro B).

Figura 7.

B A

72

4.1.1.2. ESTADISCAS AXE Se pueden realizar las estadísticas de las centrales AXE, entregando un porcentaje de los tipos de fallos que se presentan en la central seleccionada (Ver Figura 8.).

Figura 8.

73

4.1.2. CONSULTA EWSD Dentro de las consultas EWSD podemos buscar por: � Fallo: el usuario puede escoger el nivel de alarma (MINOR, MAJOR,

CRITICAL) � Central: son todas las centrales EWSD de EMCALI � Estado: Dice si la alarma esta en proceso (IN) o no procesada (NP) � Tipo de fallo, fecha u hora: son otros criterios de búsqueda Los criterios mencionados anteriormente se pueden ver en la Figura 9, cuadro A. Si el usuario no selecciona ningún criterio de búsqueda se listaran todas las alarmas registradas en la base de datos. Podemos ver un link que nos lleva a las estadísticas de las centrales EWSD (Ver Figura 9, cuadro B). Si solo se desea ver las alarmas ya solucionadas se da clic al link de alarmas solucionadas (Ver Figura 9, cuadro C)

Figura 9.

A

B C

74

4.1.2.1. ALARMAS EWSD SOLUCIONADAS Dentro de las consultas EWSD podemos utilizar el criterio de búsqueda, con este podemos realizar búsqueda por CENTRAL, OBJECT, ALPRIO, ALSTST, MSGNO, ALTYPE, PABCAUSE (Ver Figura 10, cuadro A). Para retornar a la consulta de la alarmas no solucionadas tenemos que dar clic volver EWSD (Ver Figura 10, cuadro B)

Figura 10.

A

B

75

4.1.2.2. ESTADISCAS EWSD Se pueden realizar las estadísticas de las centrales EWSD, entregando un porcentaje de los tipos de fallos que se presentan en la central seleccionada (Ver Figura 11).

Figura 11.

76

4.2. ACTUALIZAR En esta pagina se realiza un filtrado de todos los archivos que arroja la central y se guardan en la base de datos; para ello se debe presionar el botón EXAMINAR, después se escoge el archivo a filtrar y por ultimo el tipo de central es AXE o EWSD. (Ver Figura 12)

Figura 12.

77

4.3. CAMBIO DE CLAVE El usuario podrá cambiar la clave dada por el administrador para sea mas fácil de recordar (Ver Figura 13)

Figura 13.

78

4.4. USUARIOS Como su nombre lo indica tiene que ver con el manejo de los usuarios que acceden a esta aplicación. Los encargados de esta página son los administradores, pues de ellos depende el buen uso de esta aplicación. Dentro de la pagina usuario un administrador puede crear, borrar, bloquear, desbloquear y listar todos los usuarios que pueden ingresar a esta aplicación (Ver Figura 14.)

Figura 14.

79

4.4.1. CREAR Para crear un usuario el administrador debe conocer el nombre completo de la persona y debe escoger un login, estos campos no pueden coincidir con ningún usuario creado anteriormente. Los campos deben ser llenados en su totalidad, si uno de estos campos esta vació no se creara el usuario. (Ver Figura 15)

Figura 15.

80

4.4.2. BORRAR Para borrar un usuario solo es necesario su nombre y su identificación. Al igual que en crear usuario todos los campos deben estar llenos (Ver Figura 16.)

Figura 16.

81

4.4.3. BLOQUEAR En esta página se puede bloquear y desbloquear usuarios que han usado indebidamente esta aplicación. (Ver Figura 17.)

Figura 17.

82

4.4.4. LISTA Muestra la lista de usuarios que puede ingresar a esta aplicación, los campos son nombre, identificación, login, fecha de creación, el privilegio y si esta bloqueado o desbloqueado. También se pueden realizar búsquedas por los campos nombrados anteriormente. (Ver Figura 18.)

Figura 18.

83

4.5 CERRAR SESION Una vez finalizado todo el trabajo y/o consulta, se debe cerrar la aplicación, para ello se debe presionar el botón CERRAR SESION; desactivando de este modo el usuario y volviendo a la pantalla inicial. (Ver Figura 19).

Figura 19.