111
DISEÑO Y AUTOMATIZACION DEL SISTEMA CDR MAURICIO NARANJO LOURIDO JONNATHAN RAMIREZ PALOMINO UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERIA DEPARTAMENTO DE AUTOMATICA Y ELECTRONICA PROGRAMA INGENIERIA ELECTRONICA SANTIAGO DE CALI 2008

DISEÑO Y AUTOMATIZACION DEL SISTEMA CDR

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

DISEÑO Y AUTOMATIZACION DEL SISTEMA CDR

MAURICIO NARANJO LOURIDO JONNATHAN RAMIREZ PALOMINO

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERIA

DEPARTAMENTO DE AUTOMATICA Y ELECTRONICA PROGRAMA INGENIERIA ELECTRONICA

SANTIAGO DE CALI 2008

DISEÑO Y AUTOMATIZACION DEL SISTEMA CDR

MAURICIO NARANJO LOURIDO JONNATHAN RAMIREZ PALOMINO

Pasantía para optar al título de Ingeniero Electrónico

Director CARLOS HUMBERTO GARCIA

Ingeniero Electrónico

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERIA

DEPARTAMENTO DE AUTOMATICA Y ELECTRONICA PROGRAMA INGENIERIA ELECTRONICA

SANTIAGO DE CALI 2008

Nota de aceptación: Aprobado por el comité de grado en Cumplimiento con los requisitos exigidos por la Universidad Autónoma de occidente para optar al título de ingeniero electrónico.

Ing. CARLOS HUMBERTO GARCIA Director

Santiago de Cali, 10 de Diciembre 2007

AGRADECIMIENTOS

Los autores expresan sus agradecimientos a: Carlos Humberto García, Ingeniero Eléctrico y Director del Trabajo de Grado, por sus valiosas orientaciones. Jairo Antonio Chávez, Ingeniero Electrónico y Director de Departamento de Conmutación de las empresas municipales de Cali, EMCALI E.I.C.E. por su constante motivación en el desarrollo de este proyecto. William Mauricio Carabalí, Ingeniero Electrónico y técnico de teléfonos en el departamento de conmutación. Por su cooperación constante para el desarrollo de este trabajo. Fabio Marredo, Analista de Sistemas (Cipolletti - Rió Negro - Argentina). Quien estando tan lejos colaboro con sus ideas y aporto sugerencias para el desarrollo de este trabajo de grado. Walter Naranjo, Ingeniero electrónico Innovatec Ltda., por su colaboración y aporte de ideas para el desarrollo y culminación de este proyecto.

GLOSARIO

ABONADO: Persona inscrita para recibir algún tipo de servicio periódicamente o determinado número de veces. BASE DE DATOS: cualquier conjunto de datos organizados para su almacenamiento en la memoria de un ordenador o computadora, diseñado para facilitar su mantenimiento y acceso de una forma estándar. La información se organiza en campos y registros. Un campo se refiere a un tipo o atributo de información, y un registro, a toda la información sobre un individuo. CENTRAL TELEFONICA: Sistemas que concentran los bucles de un abonado, atienden las peticiones de llamadas y las dirigen a sus destinatarios. CENTRALES TANDEM: Central utilizada para conectar las distintas centrales locales de una zona que comprenda varias. Estas centrales pueden estar a su vez interconectadas entre sí. ENTORNO WEB: Es aquella aplicación que los usuarios utilizan accediendo por medio de un servidor web a través de Internet o de una intranet. PAD: es un modulo de software que convierte una secuencia de datos en su forma nativa, en paquetes típicamente reside en un nodo de la red. PVC: estos puertos son los que maneja la central para la operación y mantenimiento de X.25 SERVIDOR WEB: computadora conectada a una red que pone sus recursos a disposición del resto de los integrantes de la red. Suele utilizarse para mantener datos centralizados o para gestionar recursos compartidos. SDH: Es el estándar internacional de comunicaciones aceptado por la UIT para redes de transmisión de alta capacidad tecnologías como ATM, IP/MPLS o ADSL se apoyan en SDH para alcanzar la ansiada banda ancha. SISTEMAS DE CONMUTACIÓN: Conjunto de circuitos lógicos, forman la base de cualquier dispositivo en el que se tengan que seleccionar o combinar señales de manera controlada. TARIFICACION: proceso mediante el cual se establece un precio unitario fijado por las autoridades para los servicios públicos realizados a su cargo. TCP: Protocolo de control de transmisión. X.25: es una red de comunicaciones de datos que usa la tecnología de comunicación de paquetes para efectos de transmitir los datos.

CONTENIDO

Pág

RESUMEN 14

INTRODUCCION 15 1. DESCRIPCION DEL PROYECTO 16 1.1 PLANTEAMIENTO DEL PROBLEMA 16 1.2 ANTECEDENTES 16 1.3 OBJETIVO 17 1.3.1 Objetivos general 17 1.3.2 Objetivos específicos 17 1.4 JUSTIFICACIÓN 17 1.4.1 La empresa 17 1.4.2 La comunidad 18 1.4.3 Los autores 18 1.4.4 La universidad 18 2 MARCO TEORICO 19 2.1 CAMBIO EN LA FACTURACION POR MINUTOS 19 2.2 BREVE HISTORIA DE LA EMPRESA 20 2.3 VISIÓN 21 2.4 MISIÓN 21 2.5 SEÑALIZACION 21 2.6 TIPOS DE SEÑALIZACION 22

2.6.1 Porque usar señalización fuera de banda 22 2.7 ARQUITECTURA DE LAS REDES DE SEÑALIZACION 23 2.8 SISTEMA DE SEÑALIZACION 23 2.8.1 Concepto o siglas a tener en cuenta para SS7 23 2.9 CENTRALES TELEFONICAS 24 2.10 INTERCONEXION CENTRALES 25 2.11 TIPOS DE CENTRALES 27 2.11.1 Central EWSD 28 2.11.2 Archivo AMA 30 2.11.3Descripción del archivo AMA 30 2.11.4 Centrales AXE 33 2.12 ENTORNO WEB 37 2.12.1 Funcionalidad elemental de la web 37 2.12.2 Protocolo HTTP 37 2.12.3 URL 37 2.12.4 PHP 39 2.13 GESTOR DE BASES DE DATOS (MySQL) 42 2.13.1 Lenguajes de programación 42 2.13.2 Aplicaciones 42 2.14 SERVIDOR WEB (APACHE) 44 2.15 LENGUAJE DE PROGRAMACION DE LA APLICACIÓN (VB6.0) 45 2.15.1 Características generales 45

2.15.2 Conectividad base de datos (ADO) 46

2.15.3 Principales componentes ADO 47 2.15.4 Otros componentes ADO 48 2.15.5 Objetos connection, recordset 48 2.15.6 Conexión 48 2.15.7 Proveedor de datos 49 2.15.8 Recordset 50 3 METODOLOGIA 52 3.1 TIPO DE INVESTIGACION 52 3.2 DISEÑO DE LA INVESTIGACION 52 4 DESARROLLO DEL PROYECTO 53 4.1 IDENTIFICACION DE LAS NECESIDADES INICIALES 53 4.2 PLAN ESTRATEGICO 53 4.2.1 Decodificación y organización (DO) 54

4.2.2 Extracción de datos archivos CDR y almacenamiento de datos (EAD) 55

4.3 DESCRIPCION GENERAL DE LA APLICACIÓN 57 4.3.1 Interfaz personal administrativo 57 4.4 INTERFAZ CLIENTE 60 4.4.1 Pagina principal 60 4.4.2 Como realizar consultas 64 4.5 EJECUCION DE APLICACIÓN 67 4.6 LENGUAJE DE MODELADO UNIFICADO (UML) 68 4.6.1 Definición de actores 69

4.6.2 Usuarios del sistema 69 4.6.3 Descripción de casos de uso 69 5 CONCLUSIONES 73 BIBLIOGRAFIA 74 ANEXOS 75

LISTA DE TABLAS

Pág.

Tabla 1 Evolución de EMCALI como prestador de servicios públicos. 21 Tabla 2 características de los tipos de centrales manejadas por EMCALI 28 Tabla 3 Centrales EWSD pertenecientes a EMCALI 30 Tabla 4 Centrales AXE pertenecientes a EMCALI 35 Tabla 5 Base de datos utilizando ADO y mostrada en una WEB 47 Tabla 6 Descripción general de la aplicación 60

LISTA DE FIGURAS Pág.

Figura 1 Señalización asociada 23 Figura 2 Tipos de interconexión de centrales 26 Figura 3 Red jerárquica 26 Figura 4 Red jerárquica de EMCALI 27 Figura 5 Red planta de conmutación EWSD 29 Figura 6 Mapeo TCP/PVC 29 Figura 7 Registro AMA 31 Figura 8 Codificación binary 32 Figura 9 Descripción de una grabación AMA 33 Figura 10. Comunicación a central AXE 34 Figura 11 Correcciones a las direcciones de los puertos de la planta de conmutación AXE 34

Figura 12 Grabación de archivo CDR para centrales AXE 36 Figura 13 Parte de una dirección WEB 39 Figura 14 Ejemplo de respuesta de base de datos utilizando ADO 47 Figura 15 Componentes ADO 48 Figura 16 Conexión aplicación base de datos (1) 48 Figura 17 Conexión aplicación (2) 49 Figura 18 Acceso a la base de datos por medio de ADO 50

Figura 19 Ejemplo Recordset con algunos datos de la tabla de empleados 50

Figura 20 Inicio de sesión VB6.0 58 Figura 21 Interfaz menú de opciones 58 Figura 22 Interfaz carga de archivos EWSD 59 Figura 23 Interfaz carga de archivos AXE 59 Figura 24 Interfaz nuevo usuario 59 Figura 25 Página principal 61 Figura 26 Página acerca de 61 Figura 27 Página de registro 62 Figura 28 Consulta general 62 Figura 29 Consulta personalizada 63 Figura 30 Página enlaces 63 Figura 31 Página otros 64 Figura 32 Ingreso de registros 64 Figura 33 Autentificación valida 65 Figura 34 Consulta general 65 Figura 35 Resultado de consulta general 66 Figura 36 Consulta personalizada 66 Figura 37 Resultado consulta personalizada 67 Figura 38 Descripción de la aplicación 68 Figura 39 Definición actores 69

Figura 40 Diagrama casos de uso 69

LISTA DE ANEXOS

Pág.

Anexo 1. Manual de usuario 76

RESUMEN

El desarrollo del proyecto denominado “DISEÑO Y AUTOMATIZACION DEL SISTEMA CDR”, se llevo a cabo dentro del tiempo estimado y propuesto por la Empresa para el desarrollo de dicha aplicación, con el fin de prestar un óptimo servicio a los clientes y facilitar el proceso de respuesta ante reclamos relacionados con el consumo telefónico por parte de estos. Para la consecución del objetivo principal, el cual consiste en desarrollar una aplicación en un entorno Web, por medio de la cual se genere un reporte detallado del consumo telefónico de los abonados pertenecientes a las centrales SIEMENS EWSD Y ERICSSON AXE, a través del cual se demostrara y corroborara el consumo telefónico asociado al cliente por medio del proceso de facturación, generando confianza y satisfacción a los usuarios ante algún caso de inconformidad con el consumo registrado en su factura telefónica, además de facilitar y simplificar el proceso de respuesta empleado por EMCALI E.I.C.E.-E.S.P para resolver asuntos concernientes a desacuerdos por parte de los abonados frente a los consumos registrados, para llevar a cabo el logro de este objetivo se pretende inicialmente realizar un sistema eficiente y en la capacidad de procesar toda la información necesaria entregada por la centrales Siemens EWDS y Ericsson AXE, así generar un reporte claro y conciso de la actividad telefónica registrada por el abonado, además de contener y aprovechar todas las facilidades y ventajas que brinda un entorno Web para el desarrollo y puesta en marcha de aplicaciones orientadas al almacenamiento y consultas realizadas sobre bases de datos.

INTRODUCCIÓN

El presente trabajo de pasantía denominado “diseño y automatización del sistema CDR (call detail record – registro detallado de llamadas)” es un proyecto que tiene como objetivo principal, diseñar un software que permita al personal técnico-administrativo el monitoreo permanente de la facturación de telefonía local; además de permitir a los usuarios agilizar sus reclamos en cada C.A.L.I (centro de atención local inmediata). EMCALI E.I.C.E –E.S.P es una empresa industrial y comercial del estado, cuya finalidad específica consiste en prestar y distribuir los servicios públicos en las áreas metropolitana y rural de Santiago de Cali. Una de sus áreas denominada EMCALI telecomunicaciones, es la encargada de brindar el servicio de telefonía y demás servicios de comunicación es sus usuarios. El proyecto a presentar se desarrolló en el departamento de conmutación de la mencionada empresa. Actualmente EMCALI y el departamento encargado (departamento de conmutación) carecen de una aplicación que se encargue de agilizar y verificar el consumo telefónico de sus abonados unificada y detalladamente, pertenecientes a las centrales de conmutación SIEMENS EWSD y ERICSSON AXE, adicionalmente los usuarios presenten algunas inconformidad es con respecto al consumo telefónico, que ocasionan reclamos permanentes a través de las líneas de atención al cliente. Para desarrollar satisfactoriamente este proyecto se deberá analizar cada una de las posibles soluciones con respecto a la captura de información; para ello se deberá procesar la información (archivos CDR “AMA”, para centrales SIEMENS EWSD y archivos CDR para centrales ERICSSON AXE), para la posterior extracción de los bloques de información requeridos para el desarrollo de este proyecto. Además del diseño y funcionamiento de la aplicación, también se realizarán manuales prácticos y amigables para lograr un buen aprovechamiento de la aplicación dentro del departamento de conmutación. De esta manera un proceso de verificación del consumo telefónico del abonado de manera práctica y eficaz, ofreciendo así un mejor servicio a la comunidad y disminuyendo inconvenientes con la factura telefónica.

15

1. DESCRIPCION DEL PROYECTO

1.1 PLANTEAMIENTO DEL PROBLEMA

Debido a la nueva reglamentación planteada en la resolución 1250 del 2005 por la Comisión Reguladora de Telecomunicaciones de Colombia (CRT), que establece la forma de tarificar por minutos el consumo del servicio de telefonía local e internet, las empresas municipales de Cali “EMCALI” han tenido muchos inconvenientes con los usuarios del servicio, debido a la falta de información detallada dentro del sistema de facturación y reclamos con respecto a los minutos consumidos por el abonado. EMCALI y el departamento de conmutación actualmente no cuentan con una aplicación que se encargue de verificar detalladamente en consumo telefónico de los abonados, pertenecientes a las centrales de conmutación SIEMENS EWSD y ERICSSON AXE. Con el desarrollo de este proyecto se pretende tener una herramienta que brinde a la empresa informes permanentes de las llamadas realizadas en un periodo de tiempo, utilizando una base de datos. Estos informes presentarán información detallada de la llamada tales como:

Número de abonado A. Numero de abonado B. Fecha de la llamada. Hora de iniciación de llamada. Hora de finalización de llamada. Numero de minutos consumidos por el abonado A (quien origino la

llamada). Por medio de esta información se brindara un reporte detallado de llamadas de cada uno de los abonados de las plantas de conmutación EWSD y AXE a quienes se les presta el servicio telefónico, optimizando la prestación del servicio y obteniendo de esta manera un servicio adecuado para la comunidad caleña y circunvecinas. 1.2 ANTECEDENTES

A partir del año 1982 en EMCALI, se realizó una migración de la tecnología analógica a la tecnología digital. Hoy en día todos los equipos manejados por las empresas municipales de Cali son de tecnología digital, los cuales permiten un mejor desempeño y un nivel de calidad superior en todas las actividades que se realizan en la prestación de servicios.

16

Esto no quiere decir que en la actualidad no se presenten inconvenientes y es uno de ellos el que estamos analizando y solucionando con en este trabajo.Antes del desarrollo de este proyecto, era común que los ingenieros encargados de la red de telefonía local, realizaran un trabajo bastante largo y dispendioso, como era el de conectarse con cada una de las aplicación de gestión de centrales, para descargar la información (archivos CDR) que poseen independientemente los discos duros de las centrales de conmutación, los cuales se descargan a discos magnéticos y posteriormente se utilizan en cada una de las centrales de conmutación, que al correr una aplicación muestra la información debidamente organizada. Lo anterior requiere que el ingeniero tenga conocimiento de cada uno de los parámetros manejados dentro del archivo CDR. Que es diferente para cada central además no se posee un sistema de almacenamiento de datos lo cual hace engorrosa la búsqueda del número del abonado que presento el reclamo. Estas y otras situaciones que a diario se presentan, implican muchas horas de trabajo, las cuales se optimizarían si se tuviera una aplicación unificada donde se manejaran centralizadamente los datos de CDR. 1.3 OBJETIVO

1.3.1 Objetivo general. Diseñar un software que permita al personal técnico-administrativo el monitoreo permanente de la facturación de telefonía local. Además permitir a los usuarios del sistema de telefonía local, agilizar sus reclamos en cada C.A.L.I (centro de atención local inmediata). 1.3.2 Objetivos específicos.

Conocer la infraestructura de telefonía local que posee Emcali. Crear una base de datos de los teléfonos locales que posee EMCALI

E.I.C.E para establecer un mayor control de la facturación del total de abonados.

Generar reportes de la facturación de la telefonía local de las centrales EWSD SIEMENS y AXE ERICSSON.

Agilizar el proceso de reclamos y brindar un óptimo servicio en la facturación de telefonía local a las áreas de telefonía y atención al cliente.

Diseñar una interfaz agradable y de fácil manejo para los usuarios del servicio. 1.4 JUSTIFICACIÓN 1.4.1 La empresa. EMCALI telecomunicaciones se beneficiara inmediatamente al disponer de una aplicación que interactué con una base de datos para realizar informes detallados sobre el consumo de cada uno de los abonados, permitiendo realizar consulta y verificación de una manera eficaz, lo

17

que se traduciría en un óptimo servicio al momento de presentar el usuario sus reclamos. 1.4.2 La comunidad. Los usuarios del sistema de telefonía local gozarían de un servicio de atención al público de alta calidad en todo instante, brindado por su empresa local y de esta manera EMCALI E.I.C.E. cumpliría con su función social como prestadora de servicios esenciales que contribuyan a mejorar la calidad de vida de la comunidad. 1.4.3 Los autores. Quienes de esta forma ponen en práctica los conocimientos adquiridos en el desarrollo de la carrera para la búsqueda de soluciones prácticas a problemas planteados además de ser este un medio para optar al título de ingenieros electrónicos. 1.4.4 La universidad. Quien estaría cumpliendo su función social de contribuir a tecnificar, desarrollar y mejorar la calidad de vida de la comunidad, además de realzar su buen nombre ante empresas vallecaucanas de gran importancia e influencia.

18

2. MARCO TEORICO

2.1 CAMBIO EN LA FACTURACION POR MINUTOS Este cambio es debido al poco conocimiento que el usuario de telefonía local tiene acerca de su consumo. Cabe anotar lo que dice la resolución 1250 del 2005. “es importante tener en cuenta que el cambio en la forma de calcular la tarifa, esto es, el cambio de impulsos a minutos, tuvo como propósito que los usuarios tuvieran la posibilidad de conocer sus consumos en términos reales, siempre siguiendo el criterio de costos más utilidad razonable y no que los operadores incrementarán de una forma desproporcionada sus ingresos. Con el anterior sistema de medición del consumo, por medio de impulsos, el usuario no necesariamente sabía con exactitud lo que consumía y no necesariamente el operador cobraba por el tiempo exacto de llamada, sino por medio de una medición aproximada de llamada. Sin embargo, el cambio en la forma de medir el consumo, no debió significar incrementos en las facturas, ya que el cambio que se estableció en la resolución 1250 de 2005, fue en la medición, más no en la tarifa como tal. Para aclarar la duda con respecto al cambio de impulsos a minutos, damos una pequeña aclaración al respecto. No es correcto afirmar que un impulso es igual a tres minutos, (resultado de dividir el impulso por tres). El antiguo esquema de medición se basaba en una definición anterior de la CRT donde establecía un impulso “como una unidad de tiempo bajo el método Karlsson modificado” y cuya duración era de 180 segundos. La medición por impulsos bajo el método de Karlsson modificado consistía en un reloj por central que marcaba cada 180 segundos (cada 3 minutos), una señal que se conocía como impulso. Como dicho reloj era único por central, los impulsos no se marcaban cada vez que a un usuario le contestaban el teléfono. Entonces, cuando un usuario marcaba a un número y le contestaban, era posible que pasaran 180 segundos, 60 segundos y hasta 1 segundo para que la central contara el primer impulso que se facturaba al usuario. El método Karlsson modificado agregaba un impulso adicional al iniciar la llamada, dado que en algunos casos se podía hacer una llamada, sin que el operador alcanzara a marcar un impulso. Dado lo anterior, los impulsos que aparecían en la factura al final del mes no correspondían a un tiempo de 3 minutos de conversación, y por tanto, si se

19

multiplicaba por tres los impulsos que consumía, se obtenía una cifra de consumo en minutos muy superior a lo que realmente había hablado. Si un usuario quiere comparar su consumo en impulsos con los consumos en minutos debe conocer el tiempo promedio de duración de sus llamadas tasadas en impulsos. Sin embargo, el método de tasación no está diseñado para llevar ese registro de cada una de las llamadas locales, por lo que sólo aquellos usuarios que cuentan con el servicio de facturación detallada pueden realizar directamente ese comparativo de sus consumos. No obstante, la CRT en sus cálculos encontró que la duración promedio de las llamadas en Colombia era de 140 segundos, lo que equivalía a que un impulso tasado era 1.3 minutos de conversación. Este es un factor de conversación promedio nacional, el cual varía según la red de cada operador. Esta medición fue avalada por la Asociación Nacional de Usuarios de Servicios de Comunicaciones (ASUCOM), la Asociación Colombiana de Ingenieros Eléctricos y Mecánicos (ACIEM), la Universidad Nacional – GITUN, la Especialización en Derecho de las Telecomunicaciones de la Universidad Externado de Colombia y la SSPD. De esta forma, el cambio de metodología está motivado a un cambio de medición hacia un tiempo real de consumo de minutos, que es una medición más exacta y mejor controlable por los usuarios que la medición en impulsos, ya que esta no era una unidad lo suficientemente clara.” Fuente: superintendecia de servicios públicos. 2.2 BREVE HISTORIA DE LA EMPRESA

En la historia de las empresas municipales de Cali, EMCALI, se han realizado varios cambios Institucionales dentro de los cuales están: 1931 EMPRESAS MUNICIPALES para: Acueducto, plaza de mercado, matadero, administración y recaudo impuestos de espectáculo y alcantarillado. 1961 EMPRESAS MUNICIPALES DE CALI para: Acueducto y alcantarillado municipal, empresa telefónica municipal, plazas de mercados y ferias, y el matadero municipal. 1987 EMPRESAS MUNICIPALES DE CALI para: Acueducto, alcantarillado, energía, teléfonos y conservación de aguas. 1996 EMPRESAS MUNICIPALES DE CALI: Corporación conformada por una empresa industrial y comercial del estado dueña de cuatro sociedades públicas por acciones, prestadoras de servicios de acueducto y alcantarillado, generación de energía, distribución y comercialización de energía y telecomunicaciones.

20

1999 EMPRESAS MUNICIPALES DE CALI: Multiservicios, industrial y comercial del Estado. Tabla 1. Evolución de EMCALI como prestador de servicios públicos

EVOLUCION DE EMCALI COMO PRESTADOR DE SERVICIOS PUBLICOSDOMICILIARIOS DE 1960 A 2001

ACUEDUCTO 43.400 Suscriptores a 423.600 y la Producción de 2.600 l/s a 7.500 l/s.

ENERGIA 57.888 Suscriptores a 452.000. Capacidad de Distribución Crecimiento Anual del 7.0 %.

TELECOMUNICACIONES 22.525 Suscriptores a 498.150. Crecimiento Anual del 8.6 %.

Fuente: Evolucion de EMCALI [en linea]. Santiago de Cali: EMCALI, 2007. [Consultado 08 de Noviembre de 2007]. Disponible en Internet: www.emcali.com.co 2.3 VISIÓN “Ser una empresa pública ágil, competitiva y orientada al cliente, que nos permita convertirnos y mantenernos como la mejor alternativa en el mercado Colombiano y modelo empresarial en América Latina”. 2.4 MISIÓN La Misión de EMCALI es contribuir al bienestar y desarrollo de la comunidad, especialmente con la prestación de servicios públicos esenciales y complementarios, comprometidos con el entorno y garantizando rentabilidad económica y social. 2.5 SEÑALIZACIÓN En las redes de conmutación de circuitos, las señales de control constituyen un medio mediante el cual se gestionan y por el que se establece, mantiene y finaliza las llamadas. Tanto la gestión de las llamadas como la gestión de la red necesitan que se intercambien información entre los abonados y los conmutadores, entre los conmutadores entre si y el centro de gestión de red La comunicación entre 2 usuarios se da de la siguiente manera:

21

Cuando un abonado levanta el auricular de su aparato telefónico, la central lo identifica y le envía una "invitación a marcar".

La central espera a recibir el número seleccionado, para, a su vez, escoger una ruta del usuario fuente al destino. Si la línea de abonado del usuario destino está ocupada, la central lo detecta y le envía al usuario fuente una señal ("tono de ocupado").

Si la línea del usuario destino no está ocupada, la central a la cual está conectado genera una señal para indicarle al destino la presencia de una llamada.

Al contestar la llamada el usuario destino, se suspende la generación de dichas señales.

Al concluir la conversación, las centrales deben desconectar la llamada y poner los canales a la disposición de otro usuario, a partir de ese momento.

Al concluir la llamada se debe contabilizar su costo para su facturación, para ser cobrado al usuario que la inició. En una red telefónica conmutada, la señalización transporta la inteligencia necesaria para que un abonado se comunique con cualquier otro de esa red. La señalización indica al switch que un abonado desea servicio, le proporciona los datos necesarios para identificar al abonado distante que se solicite y entonces enruta debidamente la llamada a lo largo de su trayectoria 2.6 TIPOS DE SEÑALIZACIÓN

Dentro de banda: Con este tipo de señalización, se transmiten las señales de control en la misma banda de frecuencias usadas por las señales de voz. Esta técnica es la más sencilla y además puede ser utilizada sobre cualquier línea de abonado

Fuera de banda: Es una señalización que no toma lugar sobre el mismo camino de la comunicación. Esta señalización establece un canal digital para el intercambio de información señalizada. Este canal se llama enlace de señalización y es el encargado de llevar todos los mensajes de señalización necesarios entre nodos. La velocidad de estos mensajes hoy en día es de

unos 56 a 64 SegKb

. 2.6.1 Porque usar señalización fuera de banda ?.

Este permite el transporte de más datos a mayor velocidad (56 SegKb

que es más alta comparada con la velocidad en multifrecuencia.

Permite hacer señalización durante toda la llamada y no solo al principio. Este establece señalización para elementos de red por el cual no hay

conexión directa.

22

2.7 ARQUITECTURA DE LAS REDES DE SEÑALIZACIÓN Este es el esquema cuando la arquitectura soporta la señalización aun enlace diferente al de voz y datos. Con esta arquitectura todo el tráfico de señalización es transportado por un solo enlace. Figura 1. Señalización asociada

Fuente: Redes de señalización [en línea]. Santa fe de Bogotá: Ministerio de comunicaciones, 2007. [Consultado 08 de Noviembre de 2007]. Disponible en Internet: www.mincomunicaciones.gov.co 2.8 SISTEMA DE SEÑALIZACIÓN 7 (SS7) Es una arquitectura para el desarrollo de señalización fuera de banda como soporte del establecimiento de la llamada, facturación, enrutamiento y funciones de intercambio de información de la red telefónica de swicheo pública (PSTN). Esta red identifica funciones que van a ser desarrolladas por un sistema de señalización y un protocolo para permitir su desarrollo. 2.8.1 CONCEPTOS O SIGLAS A TENER EN CUENTA PARA SS7

SSP (Signal switching point): Estos son switches telefónicos (finales de oficinas o tandems) equipados con software capaz de manejar SS7 y enlaces terminales de señalización. Generalmente estos se originan, terminan o switchean las llamadas.

STP (Signal Transfer Point ) : Estos son lo paquetes de switches de la redes SS7. ellos reciben y rutean los mensajes de señalización entrantes dirigiéndolos al destino apropiado.

SCP: Son la base de datos que entrega la información necesaria para que sea capaz de realizar el procesamiento de las llamadas avanzadas.

23

2.9 CENTRALES TELEFONICAS A medida que se fueron desarrollando los sistemas telefónicos, las antiguas conexiones manuales a cargo de operadores que trabajaban en las centrales, empezaron a resultar demasiado lentas y laboriosas. Esto fue el detonante para la construcción de una serie de dispositivos mecánicos y electrónicos que permitiesen las conexiones automáticas. En la actualidad, ya no existen prácticamente teléfonos atendidos por centrales manuales. Todos los abonados son atendidos por centrales automáticas. En este tipo de central, las funciones de los operadores humanos las realizan los equipos de conmutación. Un relé de corriente de línea de un circuito sustituyó al cuadro de conexión manual de luz de la central, y un conmutador de cruce hace las funciones de los cables. Los equipos electrónicos de la central de conmutación se encargan de traducir automáticamente el número marcado, sea por sistema de pulsos o de tonos, y de dirigir la llamada a su destino. La llamada telefónica se inicia cuando la persona levanta el teléfono y espera el tono de llamada. Esto provoca el cierre de un conmutador eléctrico. El cierre de dicho conmutador activa el flujo de una corriente eléctrica por la línea de la persona que efectúa la llamada, entre la ubicación de ésta y el edificio que alberga la central automática, que forma parte del sistema de conmutación. Se trata de una corriente continua que no cambia su sentido de flujo, aun cuando pueda hacerlo su intensidad o amplitud. La central detecta dicha corriente y devuelve un tono de llamada, una combinación concreta de dos notas para que resulte perfectamente detectable, tanto por los equipos como por las personas. Una vez escuchado el tono de llamada, la persona marca una serie de números mediante los botones del auricular o del equipo de base. Esta secuencia es exclusiva de otro abonado, la persona a quien se llama. El equipo de conmutación de la central elimina el tono de llamada de la línea tras recibir el primer número y, una vez recibido el último, determina si el número con el que se quiere contactar pertenece a la misma central o a otra diferente. En el primer caso, se aplican una serie de intervalos de corriente de llamada a la línea del receptor de la llamada. La corriente de llamada es corriente alterna de 20 Hz, que fluye en ambos sentidos 20 veces por segundo. El teléfono del usuario tiene una alarma acústica que responde a la corriente de llamada, normalmente mediante un sonido perceptible. Cuando se contesta el teléfono levantando el auricular, comienza a circular una corriente continua por su línea que es detectada por la central. Ésta deja de aplicar la corriente de llamada y establece una conexión entre la persona que llama y la llamada, que es la que permite hablar.

24

Las centrales telefónicas forman una red jerárquica. Si el código del número marcado no pertenece a la misma central, pero pertenece a otra central del mismo nivel y área geográfica, se establece una conexión directa entre ambas centrales. Sin embargo, si el número marcado pertenece a una rama distinta de la jerarquía hay que establecer una conexión entre la primera central y aquella central de conmutación de mayor nivel común a ambas y entre ésta y la segunda central. Las centrales de conmutación están diseñadas para encontrar el camino más corto disponible entre las dos centrales. Una vez que la conexión entre las dos centrales está establecida, la segunda central activa la alarma del correspondiente receptor como si se tratara de una llamada local. La tecnología de estado sólido ha permitido que estas centrales puedan procesar las llamadas en un tiempo de una millonésima de segundo, por lo que se pueden procesar simultáneamente grandes cantidades de llamadas. El circuito de entrada convierte, en primer lugar, la voz de quien llama a impulsos digitales. Estos impulsos se transmiten entonces a través de la red mediante sistemas de alta capacidad, que conectan las diferentes llamadas en base a operaciones matemáticas de conmutación computarizadas (TDM). Las instrucciones para el sistema se hallan almacenadas en la memoria de una computadora. El mantenimiento de los equipos se ha simplificado gracias a la duplicidad de los componentes. Cuando se produce algún fallo, entra automáticamente en funcionamiento una unidad de reserva para manejar las llamadas. Gracias a estas técnicas, el sistema puede efectuar llamadas rápidas, tanto locales como a larga distancia, encontrando con rapidez la mejor ruta disponible. 2.10 INTERCONEXIÓN DE CENTRALES Un buen diseño de una red de telecomunicaciones se puede establecer realizando una correcta interconexión entre centrales de una manera coherente y lógica entre sí, de modo que cualquier abonado de la red pueda comunicarse con cualquier otro abonado de la misma o de otra central sin ningún problema. Se asume que todos los abonados tienen acceso a la red por una central local próxima. Así el problema es esencialmente cómo conectar la central de manera eficiente con otras. Para esto hay tres métodos básicos de conexión en telefonía convencional: (1) punto a punto, (2) estrella, y (3) estrella doble o de alto orden. Una conexión tipo mesh es una conexión punto a punto donde cada abonado se comunica con el resto de abonados. En una conexión estrella, una central interconecta los abonados de su sector de cobertura, esto se hace cuando el trafico entre abonados es bajo. Una configuración doble estrella es la unión de varias conexiones estrellas las cuales a su vez forman una estrella mayor donde el tráfico en la doble estrella es más alto. La mayoría de las redes son combinaciones de estrella y mesh. Por ejemplo, las centrales suburbanas periféricas se pueden conectar con una central importante próxima al área

25

metropolitana central. Esta central puede servir a los abonados próximos y se puede conectar en mesh con otras centrales grandes en la ciudad. Figura 2. Tipos de Interconexión de centrales

Fuente: GONZALEZ SAINZ, Nestor. Comunicaciones y redes de datos. Bogotá: McGRAW-HILL, 1987. p. 197. Para traer orden a esta confusión, se desarrollaron las redes jerárquicas. Es decir, se desarrolló una red sistemática que reduce los grupos troncales de salida (y entradas) de una central a una cantidad razonable, permitiendo el manejo de grandes intensidades de tráfico en ciertas rutas, donde sea necesario. En la figura 2 se ve un ejemplo simplificado de una red jerárquica. Figura 3. Red jerárquica

Fuente: GONZALEZ SAINZ, Nestor. Comunicaciones y redes de datos. Bogota: McGRAW-HILL, 1987.p. 250.

EMCALI cuenta con una red jerárquica la cual está compuesta por 29 centrales de las cuales 3 de ellas son centrales tándem interconectadas entre sí por enlaces de fibra óptica. Se muestran la red jerárquica que posee en Emcali en la figura 3.

26

Figura 4. Red jerárquica de EMCALI

2.11 TIPOS DE CENTRALES DE EMCALI E.I.C.E Para prestar el servicio de telefonía, EMCALI posee 29 centrales en total distribuidas estratégicamente en toda la zona geográfica de cobertura (Santiago de Cali, Yumbo y parcelaciones). Estas centrales son de tres diferentes proveedores: 16 de estas centrales son AXE de Ericsson con 290.000 líneas en planta y 7.000 líneas en concentradores, 11 centrales EWSD de Siemens con 224.500 líneas en planta y 35.000 líneas en concentradores, 2 centrales FETEX de Fujitsu 150, 35.000 líneas en planta y 400 líneas en concentradores. En la tabla 2 se puede ver las diferentes características que poseen las centrales con que cuenta EMCALI.

27

Tabla 2. Características de los tipos de centrales manejadas por EMCALI.

NODO TIPO DE CENTRAL UBICACIÓN E1´S DISPONIBLES ESPACIO DISPONIBLE Mts2 INTERCONEXIONCentro 1 AXE Kra 7 13-122 5 LocalCentro 5 AXE-TAMDEM Kra 7 13-122 20 General (1)Centro 3 EWSD Kra 7 13-122 6 LocalColon 2 AXE-TAMDEM Cll14 33-40 20 30 General Colon 3 AXE Cll14 33-40 1 LocalColon 4 EWSD Cll14 33-40 6 Local

Guabito 3 AXE-TAMDEM Cll34 8a-165 20 20 GeneralGuabito 4 AXE Cll34 8a-165 1 LocalGuabito 5 EWSD Cll34 8a-165 6 LocalLa Flora 1 AXE Av. 3N 53N-11 4 6 LocalLimonar 1 AXE Kra 75 calle 15 4 6 LocalLimonar 2 EWSD Kra 75 calle 15 1 LocalPeñon 1 AXE Kra 3 Oeste 1-24 4 30 Local

Poblado 5 AXE Cll 62 T28-04 10 30 LocalPrados del Sur 1 AXE Kra 80 Calles 2C,2B 8 30 Local

Salomia 1 AXE Kra 1D 52-05 1 6 LocalSalomia 2 EWSD Kra 1D 52-05 10 Local

Marroquin 3 EWSD Kra 27 Calle 103 6 30 LocalSan Fernando 2 EWSD Kra 25 5-35 6 30 Local

San Luis 4 AXE Kra 1a 5 72-05 4 30 LocalTequendama 2 AXE Cll 6 44-110 4 30 LocalTequendama 6 EWSD Cll 6 44-110 10 Local

Versalles 2 EWSD Av.Estacion 5aN-56 10 30 LocalUnion 4 AXE Kra 41F 46-00 10 30 Local

Yumbo 3 EWSD Kra 4 5-01 1 15 LocalAlfonso Lopez 2 EWSD Cll 33 Kra 7aN 1 30 Local

2.11.1 Centrales EWSD. EWSD es el sistema de conmutación de mayor implantación en todo el mundo. Se han instalado más de 240 millones de puertos en 105 países. Aproximadamente una de cada cinco llamadas telefónicas realizadas hoy en día utiliza tecnología Siemens. Con la gran gama de funcionalidades. El sistema de conmutación EWSD es capaz de cubrir un espectro completo de aplicaciones, como sistemas de call center, redes inteligentes, sistemas prepago, más de 300 features para abonados análogos y más de 400 para abonados digitales, aplicaciones multimedia entre otras.El sistema de conmutación EWSD es capaz de cubrir un espectro completo de aplicaciones, como sistemas de call center, redes inteligentes, sistemas prepago, más de 300 features para abonados análogos y más de 400 para abonados digitales, aplicaciones multimedia entre otras. El sistema de conmutación EWSD realiza las tareas de tarificación y facturación, además de la señalización S7. Realiza funciones de enrutamiento basados en algoritmos estándares o definidos por el operador y soporta gran cantidad de planes de numeración para marcación nacional e internacional. Por su gran flexibilidad y adaptabilidad la EWSD puede operar en todos los niveles de la red: central local, central de transito y/o central internacional. Para establecer la comunicación de la red de gestión con las centrales diseñadas por Siemens, se puede establecer la comunicación mediante una red ethernet (protocolo TCP/IP) ó X-25 FTAM. Se puede realizar de cualquiera de las dos formas anteriores para llegar al router local. Este router local nos

28

direccionará a la central EWSD con la que se desee la comunicación mediante IP/SDH. Cuando la información llega a la central el router remoto realiza la transformación de TCP a X.25, por consiguiente los puertos TCP se convierte a PVCs (estos puertos son los que maneja la central para la operación y mantenimiento de X.25), al terminar este proceso se realiza la conexión a la central EWSD, por último se ejecuta el software propietario de la Siemens para realizar los procedimientos correspondientes a esta central. Lo anterior se puede observar en la figura 1. Figura 5. Red planta de conmutación EWSD

Para entender un poco más lo expuesto anteriormente del mapeo de puertos de TCP a PVCs el cual convierte de IP a X-25 se muestra en la figura 2. Figura 6. Mapeo TCP/PVC

Las 11 centrales EWSD que posee EMCALI son:

29

Tabla 3. Centrales EWSD pertenecientes a EMCALI

2.11.2 Archivo AMA. Las centrales Siemens EWSD tienen la funcionalidad de generar un archivo denominado “Archivo AMA” en el cual se encuentra almacenada toda la información relacionada con las llamadas realizadas por los abonados pertenecientes a dicha central, este archivo lo entrega la central en formato texto (extensión .TXT), pero su contenido se encuentra codificado de forma binaria. AMA (Contabilidad automática de mensajes) es un método de cobro por tiquetes; toda la información la cual es o puede ser relevante para la tasación es registrada en un tiquete. Los tiquetes generados son almacenados en un archivo dentro del disco EWSD, desde donde pueden ser transferidos a un centro remoto de facturación, en este centro remoto los tiquetes son usados para calcular los cobros a pagar por los usuarios. Este archivo tiene diversas funcionalidades en la empresa para efectos de tasación, tarifación y será especialmente utilizado como fuente de información para el desarrollo del proyecto. 2.11.3 Descripción del archivo AMA. El archivo AMA está compuesto por una parte de longitud fija o cabecera y una parte de longitud variable que está contenida por varios paquetes de datos.

30

Figura 7. Registro AMA

Fuente: SIEMENS. Manual de operación central EWSD. Munich: Siemens AG, 1997. 5698 p.

Parte fija o cabecera; La parte fija tiene una longitud de 12 bytes contenidos en 6 campos los cuales se describen a continuación:

Identificador de grabación: tiene una longitud de 1 byte, ocupa la primera

posición dentro de la grabación y he indica el comienzo de una llamada telefónica.

Longitud de grabación: Está formado por 2 bytes y ocupa la segunda y tercera posición dentro de la grabación. Este campo nos da a conocer el numero de bytes en el cual están contenidos toda la información de una llamada (varía de acuerdo al número que se llama).

Indicadores: Tiene una longitud de 3 bytes y está compuesto por banderas en las cuales se especifican servicios prestados por la central.

Record sequence & Sharge status: Es un campo formado por 1 byte que es utilizado para identificar facilidades del usuario y el estado normal de la llamada.

Record owner: De longitud 1 byte donde se muestra la longitud del código de área y la longitud de identificación del usuario. Longitud de 1 byte.

LAC & Directory number: En este campo van especificados el código de área de la ciudad y el número de teléfono del abonado llamante.

El campo más importante dentro de la parte fija es el identificador de grabación ya que señala el instante en que un abonado A realiza una llamada hacia un abonado B, tomando como valor el 84 en hexadecimal.

Parte variable o de paquetes; La parte variable o de paquetes de los

registros de grabaciones está compuesta por una cantidad de paquetes dentro de los cuales se describe toda la información relacionada con la llamada realizada, servicios utilizados y de más parámetros relevantes para la central.

Dentro de la aplicación a realizar se prestara interés a los paquetes 100 y 101 Descritos a continuación:

31

Paquete 100; En este paquete se encuentra toda la información relacionada con la fecha, hora y duración de la llamada. Este paquete tiene una longitud de 11 bytes y está compuesto por cuatro campos:

Package number: Identificador de paquete, por defecto para este es el número 64H, este campo tiene longitud de un byte y ocupa la primera posición dentro del paquete.

DATE/TIME: Dentro de este campo se encuentra almacenada la información acerca de la hora y la fecha de realización de la llamada. Este campo tiene una longitud de 6 bytes y ocupa desde la segunda hasta la séptima posición.

Campo utilizado para banderas. Longitud de 1 byte, posición 8. Duración: campo utilizado para indicar la duración de la llamada. Tiene una

longitud de 3 bytes y ocupa desde la novena hasta la undécima posición.

Este campo tiene una codificación especial dentro del paquete llamada: BYNARY, en esta codificación los campos se encuentran almacenados en el formato LSB_LO (Least significative Byte on the lowest address) que quiere decir que el byte menos significativo, se encuentra almacenado en la posición más baja de memoria. Ejempló: Almacenamiento de un entero binario en un campo de 3 byte. Figura 8. Codificación Bynary

Paquete 101; En este paquete se encuentra información relacionada con

el destino de la llamada realizada, este paquete tiene una longitud de 6 bytes y está compuesto por los siguientes campos:

Package number: Identificador de paquete, por defecto para este es el número 65H, este campo tiene longitud de un byte y ocupa la primera posición dentro del paquete.

No. of digits: En este campo se indica el número de dígitos marcados por el abonado llamante. Tiene una longitud de 1 byte y ocupa la segunda posición dentro del paquete.

Digits: campo en el que se encuentra almacenado el número marcado por el abonado llamante. No tiene una longitud fija y ocupa la tercera posición dentro del paquete.

32

Este campo dentro del paquete se encuentra almacenado de la forma “packed digits”, esta expresión significa que 2 dígitos están empaquetados en un solo byte.

Descripción del AMA record; Figura 9. Descripción de una Grabación AMA

2.11.4 Centrales AXE. El sistema AXE, se utiliza tradicionalmente en las redes locales, del tránsito de comunicaciones internacionales y combinado. AXE también se aplica para todos los estándares móviles importantes -análogo y digital. AXE es muy fuerte en redes inteligentes y otros usos en tiempo real de la base de datos. Los diseños recientes permiten agregar datos a la comunicación del sistema. Desde su inicio, el sistema AXE fue diseñado para permitir un cambio continuo (actualizarse). A través de los años, se han introducido los nuevos usos, una gran cantidad de funciones se han implementado, y su hardware se ha puesto al día constantemente. Los autores describen cómo los últimos avances de la tecnología de hardware se han traído al sistema, mejorando de tal modo las características tales como espacio, el consumo de energía, y el costo de la propiedad. Como siempre, la compatibilidad con diseños anteriores se ha mantenido a un grado posible, para proteger inversiones anteriores en AXE. Las centrales AXE pueden establecer comunicación con la red de gestión por X-25 FTAM o por protocolo TCP/IP, permitiendo así enlazarse con el router local 2600, pero además utilizando estas pueden utilizar XOT-X25, convirtiendo de TCP a X.25; en el cual se tiene un router 805, este router remoto hace la conexión a AXE, El protocolo XOT no sólo puede emplearse para sacar el máximo partido de la red troncal IP, sino que también puede utilizarse para conectarse a paquetes de X.25 no conectados y para facilitar la migración de X.25 a IP. El cambio escalonado de un componente cada vez (primero la red troncal y luego la aplicación) permite a la empresa afrontar el riesgo que

33

conlleva el desarrollo de un nuevo servicio y le ayuda a prolongar la vida de sus terminales gracias al interfaz de conexión a IP y evitándole la necesidad de desarrollar de nuevas aplicaciones. En la figura 3 se muestra claramente lo explicado anteriormente. Figura 10. Comunicación a central AXE

Las conexiones correspondientes que se deben desarrollar y para entender los protocolos utilizados se muestran en la figura 4, en ella podemos observar las diferentes correcciones que se le realiza a las direcciones de los puertos, además de observar recorrido de la información antes de llegar al sistema AXE. Figura 11. Correcciones a las direcciones de los puertos de la planta de conmutación AXE.

Las 15 centrales AXE que posee EMCALI son:

34

Tabla 4. AXE pertenecientes a EMCALI Nodo Tipo

Central Ubicación

Centro 1 AXE Kra 7 13-122

Centro 5 AXE-TANDEM

Kra 7 13-122

Colón 2 AXE-TANDEM

CLL 14 33-40

Colón 3 AXE CLL 14 33-40

Guabito 3 AXE – TANDEM

Calle 34 8ª-165

Guabito 4 AXE Calle 34 8ª-165

La Flora 1 AXE Av. 3N 53N-11

Limonar 1 AXE Kra 75 Calle 15

Peñón 1 AXE Kra 3 Oeste 1-24

Poblado 5 AXE Calle 62 T 28-04

Prados de Sur 1 AXE Kra 80 Calles 2C,2B

Salomia 1 AXE Kra 1D 52-05

San Luis 4 AXE Kra 1ª5 72-05

Tequendama 2 AXE Calle 6 44-110

Unión 4 AXE Kra 41F 46-00

Archivo CDR centrales AXE; Las centrales Ericsson AXE tienen la

funcionalidad de generar un archivo en el cual se almacena toda la información relacionada con las llamadas producidas por los abonados pertenecientes a estas centrales, este archivo lo entrega la central en texto plano. Pero su contenido está debidamente organizado.

35

Descripción del archivo CDR centrales AXE; El archivo CDR está compuesto por tres tipos de datos la cabecera, información y final de grabación de datos. La grabación total siempre va ser de un tamaño fijo este es de 132 caracteres y a la vez este va a ser el final de grabación.

Cabecera: es la parte que me indica la inicialización de la grabación de la llamada el cual se indica con la siguiente cadena de caracteres (00000XXXXXXX) “XXXXXXX es un consecutivo que lleva la central la cual nos indica el número de grabaciones realizadas hasta el momento”. Información: es la parte del CDR donde está contenida toda la información de la llamada realizada por el abonado en esta nos muestra información tal como:

Numero de abonado A Numero de abonado B Fecha de la llamada realizada Hora Duración Entre otras que no vienen al caso de estudio.

Final de grabación de datos: es la parte donde me indica la terminación de la grabación realizada por la central, la cual se indica por la siguiente cadena de caracteres “132” a la vez este me indica que cada 132 caracteres se obtiene por la central la información de una llamada realizada.

Descripción del CDR record centrales AXE; Figura 12. Grabación de archivo CDR para centrales AXE

36

2.12 ENTORNO WEB Es básicamente un medio de comunicación de texto, gráficos y otros objetos multimedia a través de Internet, es decir, la web es un sistema de hipertexto que utiliza Internet como su mecanismo de transporte o desde otro punto de vista, una forma gráfica de explorar Internet. El sistema CDR tendrá el funcionamiento de la interfaz de usuario por medio de la web, en la cual se mostrara los registros de cada uno de los abonados pertenecientes a las centrales de conmutación AXE y EWSD. 2.12.1 Funcionalidad elemental de la web. Se basa en tres estándares. • HTTP • URL • HTML

2.12.2 Protocolo HTTP. Internet tiene su fundamento en base a protocolos estándares, sin los cuales no podría funcionar. Si bien el protocolo subyacente es el TCP/IP, para ciertas funciones particulares son necesarios otros protocolos, como en el caso específico de la Web, donde fue necesario crear un protocolo que resolviese los problemas planteados por un sistema hipermedial, y sobre todo distribuido en diferentes puntos de la Red. Este protocolo se denominó HTTP (HyperText Transfer Protocol, o Protocolo de Transferencia de Hipertexto), y cada vez que se activa cumple con un proceso de cuatro etapas entre el browser y el servidor que consiste en lo siguiente:

Conexión: el browser busca el nombre de dominio o el número IP de la dirección indicada intentando hacer contacto con esa computadora.

Solicitud: el browser envía una petición al servidor (generalmente un documento), incluyendo información sobre el método a utilizar, la versión del protocolo y algunas otras especificaciones.

Respuesta: el servidor envía un mensaje de respuesta acerca de su petición mediante códigos de estado de tres dígitos.

Desconexión: se puede iniciar por parte del usuario o por parte del servidor una vez transferido un archivo.

2.12.3 URL. La forma en que se localizan recursos en la Web proviene del empleo de un sistema notacional, URL (Uniform Resourse Locator, o Ubicador Uniforme de Recursos) que hace posible los saltos hipertextuales. Básicamente, un URL es un puntero a un objeto de Internet. En su sintaxis nos proporciona, de forma compacta, y bastante inteligible, la información necesaria para acceder a un recurso en Internet. Dicha información contiene, como

37

mínimo, el protocolo de acceso (http para una página en la Web, ftp para transferencia de archivos, gopher para un documento hipertextual puro en el espacio Gopher, etc.), el nombre del servidor remoto, y el camino y nombre del documento. Una vez que el recurso es localizado, se transfiere una copia al usuario quien en definitiva decide qué hacer con el mismo.

Breve historia; La idea de crear una red como Internet existe desde hace más de 20 años. Los primeros conceptos acerca de la red se desarrollaron en el año 1973, realizándose las primeras pruebas de interconexión de redes en julio de 1977. Se puede considerar que Internet ya estaba en actividad en los Estados Unidos, alrededor de 1982 y a finales de la década de los 80 comienza a expandirse internacionalmente, incluyendo usuarios y redes de distintas partes del mundo.

Sin embargo, hasta alrededor del año 1993, el uso de Internet estaba, en su mayor parte, limitado a círculos técnicos, científicos y académicos. La gran mayoría de la población, incluidas personas familiarizadas con la informática y el uso de ordenadores, nunca habían oído hablar de Internet. En determinado momento se produce un punto de inflexión en el cual todos los medios de difusión comienzan a hablar de Internet, el gran público empieza a interesarse por el tema, la Red comienza a insertarse en los distintos ámbitos de la sociedad y a tener implicaciones económicas importantes. Surge World Wide Web, la telaraña mundial. El auge de Internet se debe en gran medida a la aparición de World Wide Web (WWW, W3 o simplemente Web), pero hay otros factores tecnológicos que contribuyeron a este fenómeno. El desarrollo de ordenadores cada vez más veloces, con más capacidad y a bajos precios, junto con el perfeccionamiento del software correspondiente, unido al avance de las telecomunicaciones, hace posible que en los países desarrollados se generalice el uso doméstico de Internet. La creación de W3 y su continuo desarrollo y los avances tecnológicos que la hacen posible, son dos hechos intrínsecamente relacionados, en el que cada uno tira del otro. World Wide Web fue desarrollada inicialmente en el CERN (Laboratorio Europeo de Física de Partículas) en Ginebra. Los trabajos iniciales comenzaron en 1989 y entre finales de 1990 y comienzos de 1991 aparecen el primer servidor Web y un browser (navegador) para interfaces de tipo texto. El objetivo perseguido entonces era que los físicos europeos en el ámbito de altas energías, cuyos grupos de trabajo estaban dispersos por varios países, pudiesen intercambiar conocimientos y datos de modo eficiente. El sistema se extendió rápidamente por todo el mundo abarcando a las instituciones más diversas y permitiendo el acceso a todo tipo de información.

38

Quizás uno de los principales factores que contribuyó a la rápida aceptación y al crecimiento de W3 fue la aparición, en septiembre de 1993 del primer navegador gráfico. Éste permitía visualizar documentos que combinaban texto e imágenes en un formato muy atractivo. Además del WWW, Internet ofrece otros servicios más antiguos como el correo electrónico, grupos de noticias, FTP, Telnet y Wais.

Identificación de una dirección en la web; Para acceder a una página en la Web, deberemos conocer su dirección, o URL.

Una dirección típica de una página web podría tener la siguiente estructura: Figura 13. Partes de una Dirección Web

Lenguajes de programación; Existen numerosos lenguajes de programación utilizados para el desarrollo de aplicaciones web entre los que se destacan:

PERL RUBY PYTHON CFM Coldfusion DHTML PHP ASP CGI JSP (Tecnología Java ) .NET

A continuación describiremos el lenguaje de programación PHP, el cual fue el lenguaje escogido para el desarrollo de este proyecto. 2.12.4 PHP. PHP es un lenguaje de propósito general. Es normalmente usado como un lenguaje de script embebido en HTML para su uso en la web, pero

39

puede también puede usarse como un lenguaje de script para shell o hasta como un lenguaje para escribir aplicaciones con ventanas, con PHP-GTK.

Historia de PHP; Comenzó y sigue siendo primeramente usado como un lenguaje de script del lado del servidor embebido en HTML. PHP, se conoce originalmente como Personal Home Pages, fue concebido en el otoño de 1994 por Rasmus Lerdorf. Él lo escribió como una forma de track visitantes a su CV en línea. La primera versión salió en los comienzos de 1995, y fue ahí donde Rasmus se dio cuenta que haciendo en proyecto código-abierto, las personas arreglarían sus problemas. La primera versión fue muy precaria y tenía un parser que reconocía solo unas pocas macros y brindaba algunas utilidades que se usaban comúnmente en sitios web. El parser fue reescrito a mediados de 1995 y se lo renombro a PHP/FI versión 2. El "FI" en esta versión quería decir Interprete formal. Lo que Rasmus había agregado a PHP fue de acuerdo a las necesidades crecientes del sitio web. El soporte para mSQL fue agregado. PHP/FI tuvo un crecimiento masivo, y otra gente empezó a contribuir programando regularmente. A mediados de 1997 Zeev Suraski y Andi Gutmans reescribieron el parser principal, y PHP cambio de estar en manos de Rasmus a un grupo más orientado al proyecto. Esto formo las bases para que PHP3, fuere ahora llamado PHP: Hypertext Preprocessor - un acrónimo recursivo. La última versión, de PHP4, es otra reescritura de Suraski and Gutmans y está basada en el motor Zend. PHP ahora tiene doscientos contribuyentes regularmente trabajando en varias partes del proyecto. Tiene una cantidad muy grande extensiones, módulos y soporta todos los servidores más populares nativamente, y además tiene soporte para MySql y ODBC. Las últimas estadísticas muestran que PHP es actualmente usado por más de 5.5 millones de dominios, y ha tenido un gran crecimiento durante el último año. Es lejos el módulo más popular de Apache; para dar alguna perspectiva, Apache actualmente tiene un 60% del mercado de servidores de internet, y el servidor IIS (con soporte nativo para ASP) tiene menos de la mitad de esa proporción del mercado.

Visión general; La similitud con los lenguajes más comunes de programación estructurada, como C y Perl, permiten a la mayoría de los programadores experimentados crear aplicaciones complejas con una curva de aprendizaje muy suave. También les permite involucrarse con aplicaciones de contenido dinámico sin tener que aprender todo un nuevo grupo de funciones y prácticas. Su interpretación y ejecución se da en el servidor web, en el cual se encuentra almacenado el script, y el cliente sólo recibe el resultado de la ejecución.

40

Cuando el cliente hace una petición al servidor para que le envíe una página web, generada por un script PHP, el servidor ejecuta el intérprete de PHP, el cual procesa el script solicitado que generará el contenido de manera dinámica, pudiendo modificar el contenido a enviar, y regresa el resultado al servidor, el cual se encarga de regresárselo al cliente. Además es posible utilizar PHP para generar archivos PDF, Flash, así como imágenes en diferentes formatos, entre otras cosas. Permite la conexión a diferentes tipos de servidores de bases de datos tales como MySQL, Postgres, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite; lo cual permite la creación de Aplicaciones web muy robustas.

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 o Mac OS X) y Windows, y puede interactuar con los servidores de web más populares ya que existe en versión CGI, módulo para Apache, e ISAPI.

Usos del PHP; Los principales usos del PHP son los siguientes:

Programación de páginas web dinámicas, habitualmente en combinación con el motor de base datos MySQL, aunque cuenta con soporte nativo para otros motores, incluyendo el estándar ODBC, lo que amplía en gran medida sus posibilidades de conexión.

Programación en consola, al estilo de Perl o Shell scripting. Creación de aplicaciones gráficas independientes del navegador, por medio

de la combinación de PHP y GTK (GIMP Tool Kit), lo que permite desarrollar aplicaciones de escritorio en los sistemas operativos en los que está soportado.

Ventajas de PHP;

Es un lenguaje multiplataforma. Capacidad de conexión con la mayoría de los manejadores de base de

datos que se utilizan en la actualidad. Leer y manipular datos desde diversas fuentes, incluyendo datos que

pueden ingresar los usuarios desde formularios HTML. Capacidad de expandir su potencial utilizando la enorme cantidad de

módulos (llamados ext's o extensiones). Posee una amplia documentación en su página oficial ([1]). Es libre, por lo que se presenta como una alternativa de fácil acceso para

todos. Permite las técnicas de Programación Orientada a Objetos.

41

2.13 GESTOR DE BASES DE DATOS (MySQL)

Es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones1 . MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual. Por un lado lo ofrece bajo la GNU GPL, pero, empresas que quieran incorporarlo en productos privativos pueden comprar a la empresa una licencia que les permita ese uso. Está desarrollado en su mayor parte en ANSI C. Al contrario de proyectos como el Apache, donde el software es desarrollado por una comunidad pública, y el copyright del código está en poder del autor individual, MySQL es propiedad y está patrocinado por una empresa privada, que posee el copyright de la mayor parte del código. Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado. Además de la venta de licencias privativas, la compañía ofrece soporte y servicios. 2.13.1 Lenguajes de programación. Existen varias APIs que permiten, a aplicaciones escritas en diversos lenguajes de programación, acceder a las bases de datos MySQL, incluyendo C, C++, C#, Pascal, Delphi (via dbExpress), Eiffel, Smalltalk, Java (con una implementación nativa del driver de Java), Lisp, Perl, PHP, Python, Ruby,Gambas, REALbasic (Mac), FreeBASIC, y Tcl; cada uno de estos utiliza una API específica. También existe un interfaz ODBC, llamado MyODBC que permite a cualquier lenguaje de programación que soporte ODBC comunicarse con las bases de datos MySQL. 2.13.2 Aplicaciones. MySQL es muy utilizado en aplicaciones web como MediaWiki o Drupal, en plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones.

Características (versión 5.0.22);

Un amplio subconjunto de ANSI SQL 99, y varias extensiones. Soporte a multiplataforma Procedimientos almacenados Triggers Cursors Vistas actualizables Soporte a VARCHAR

42

INFORMATION_SCHEMA Modo Strict Soporte X/Open XA de transacciones distribuidas; transacción en dos fases

como parte de esto, utilizando el motor InnoDB de Oracle Motores de almacenamiento independientes (MyISAM para lecturas

rápidas, InnoDB para transacciones e integridad referencial) Transacciones con los motores de almacenamiento InnoDB, BDB Y Cluster;

puntos de recuperación(savepoints) con InnoDB Soporte para SSL Query caching Sub-SELECTs (o SELECTs anidados) Replication with one master per slave, many slaves per master, no

automatic support for multiple masters per slave. indexing y buscando campos de texto completos usando el motor de

almacenamiento MyISAM Embedded database library Soporte completo para Unicode Conforme a las reglas ACID usando los motores InnoDB, BDB y Cluster Shared-nothing clustering through MySQL Cluster.

Características adicionales;

Usa GNU Automake, Autoconf, y Libtool para portabilidad Uso de multihilos mediante hilos del kernel. Usa tablas en disco b-tree para búsquedas rápidas con compresión de

índice Tablas hash en memoria temporales El código MySQL se prueba con Purify (un detector de memoria perdida

comercial) así como con Valgrind, una herramienta GPL Completo soporte para operadores y funciones en cláusulas select y where. Completo soporte para cláusulas group by y order by, soporte de funciones

de agrupación Seguridad: ofrece un sistema de contraseñas y privilegios seguro mediante

verificación basada en el host y el tráfico de contraseñas está cifrado al conectarse a un servidor.

Soporta gran cantidad de datos. MySQL Server tiene bases de datos de hasta 50 millones de registros.

Se permiten hasta 64 índices por tabla (32 antes de MySQL 4.1.2). Cada índice puede consistir desde 1 hasta 16 columnas o partes de columnas. El máximo ancho de límite son 1000 bytes (500 antes de MySQL 4.1.2).

Los clientes se conectan al servidor MySQL usando sockets TCP/IP en cualquier plataforma. En sistemas Windows se pueden conectar usando named pipes y en sistemas Unix usando ficheros socket Unix.

En MySQL 5.0, los clientes y servidores Windows se pueden conectar usando memoria compartida.

43

MySQL contiene su propio paquete de pruebas de rendimiento proporcionado con el código fuente de la distribución de MySQL.

2.14 SERVIDOR WEB servidor HTTP APACHE de código abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se basó inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre se debe a que Behelendorf eligió ese nombre porque quería que tuviese la connotación de algo que es firme y enérgico pero no agresivo, y la tribu Apache fue la última en rendirse al que pronto se convertiría en gobierno de EEUU, y en esos momentos la preocupación de su grupo era que llegasen las empresas y "civilizasen" el paisaje que habían creado los primeros ingenieros de internet.Además Apache consistía solamente en un conjunto de parches a aplicar al servidor de NCSA. Era, en inglés, a patchy server (un servidor "emparchado"). El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation. 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. Apache tiene amplia aceptación en la red: en el 2005, Apache es el servidor HTTP más usado, siendo el servidor HTTP del 48% de los sitios web en el mundo y decreciendo su cuota de mercado (estadísticas históricas y de uso diario proporcionadas por Netcraft ). La mayoría de las vulnerabilidades de la seguridad descubiertas y resueltas puede en la mayoría de los casos ser abusada solamente por los usuarios locales y no puede ser accionada remotamente. Sin embargo, algunas de las ediciones antedichas se pueden accionar remotamente en ciertas situaciones, o explotar por los usuarios locales malévolos en las disposiciones de recibimiento compartidas que utilizan PHP como módulo de Apache. Por lo tanto, aconsejamos fuertemente a todos los usuarios de PHP, sin importar la versión a aumentar a los 5.2.1 o 4.4.5 lanzamientos cuanto antes. Para los usuarios que aumentan a PHP 5.2 de PHP 5.0 y de PHP 5.1, una guía de la mejora está disponible aquí, detallando los cambios entre esos lanzamientos y PHP 5.2.1.

44

2.15 LENGUAJE DE PROGRAMACION DE LA APLICACIÓN (VB6.0) Visual Basic es un lenguaje de programación desarrollado por Alan Cooper para Microsoft. El lenguaje de programación es un dialecto de BASIC, con importantes añadidos. Su primera versión fue presentada en 1991 con la intención de simplificar la programación utilizando un ambiente de desarrollo completamente gráfico que facilitara la creación de interfaces gráficas y en cierta medida también la programación misma. Visual Basic fue discontinuado por Microsoft hace ya varios años. Muchos programadores estan migrando a lenguajes similares como Delphi (que actualmente tambien ha sido discontinuado por Borland). Microsoft propone abandonar el desarrollo basado en la API Win32 y pasar trabajar sobre un framework o marco comun de librerias independiente de la version del sistema operativo, .NET Framework, a traves de Visual Basic .NET (y otros lenguajes como C-Sharp (C#) de facil transicion de codigo entre ellos) que presenta serias incompatibilidades con el codigo Visual Basic existente. Visual Basic constituye un IDE (entorno de desarrollo integrado) que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código (programa donde se escribe el código fuente), un depurador (programa que corrige errores en el código fuente para que pueda ser bien compilado), un compilador (programa que traduce el código fuente a lengua máquina), y un constructor de interfaz gráfica o GUI (es una forma de programar en la que no es necesario escribir el código para la parte gráfica del programa, sino que se puede hacerlo de forma visual). 2.15.1 Características generales. Es un lenguaje de fácil aprendizaje pensado tanto para programadores principiantes como expertos, guiado por eventos, y centrado en un motor de formularios que facilita el rápido desarrollo de aplicaciones gráficas. Su sintaxis, derivada del antiguo BASIC, ha sido ampliada con el tiempo al agregarse las características típicas de los lenguajes estructurados modernos. Se ha agregado una implementación limitada de la programación orientada a objetos (los propios formularios y controles son objetos), aunque sí admite el polimorfismo mediante el uso de los Interfaces, no admite la herencia. No requiere de manejo de punteros y posee un manejo muy sencillo de cadenas de caracteres. Posee varias bibliotecas para manejo de bases de datos, pudiendo conectar con cualquier base de datos a través de ODBC (Informix, DBase, Access, MySQL, SQL Server, PostgreSQL ,etc) a través de ADO. Es utilizado principalmente para aplicaciones de gestión de empresas, debido a la rapidez con la que puede hacerse un programa que utilice una base de datos sencilla, además de la abundancia de programadores en este lenguaje. El compilador de Microsoft genera ejecutables que requieren una DLL para que funcionen, en algunos casos llamada MSVBVMxy.DLL (acrónimo de "MicroSoft

45

Visual Basic Virtual Machine x.y", siendo x.y la versión) y en otros VBRUNXXX.DLL ("Visual Basic Runtime X.XX"), que provee todas las funciones implementadas en el lenguaje. Además existen un gran número de bibliotecas (DLL) que facilitan el acceso a muchas funciones del sistema operativo y la integración con otras aplicaciones. Sin embargo esto sólo es una limitación en sistemas obsoletos, ya que las bibliotecas necesarias para ejecutar programas en Visual Basic vienen de serie en todas las versiones de Windows desde Windows 2000. 2.15.2 Conectividad base de datos (ADO). ActiveX Data Objects (ADO) es uno de los mecanismos que usan los programas de computadoras para comunicarse con las bases de datos, darles órdenes y obtener resultados de ellas. Con ADO, un programa puede leer, insertar, editar, o borrar, la información contenida en diferentes áreas de almacenamiento dentro de la base de datos llamadas tablas. Además, se puede manipular la propia base de datos para crear nuevas áreas para el almacenamiento de información (tablas), como también alterar o eliminar las ya existentes, entre otras cosas. Fue desarrollado por Microsoft y es usado en ambientes Windows por lenguajes de programación como Visual Basic, C++, Delphi entre otros, como también en la Web mediante el uso de Active Server Pages (ASP) y el lenguaje VBScript. ADO substituyó tanto a DAO (Data Access Object), como a RDO (Remote Data Object), que eran los sistemas previos que se usaban para acceder a las bases de datos y bases de datos remotas, respectivamente. Tiene la mayor parte de la funcionalidad de ambos modelos y sin embargo es más sencillo de usar y de entender y por lo tanto más fácil y menos engorroso de programar. La última versión de ADO, creada por Microsoft, se llama ADO.NET, y se usa en los entornos de programación de la plataforma .NET, de Microsoft, para manejar bases de datos tanto en Windows como en la Web mediante ASP.NET, que es la nueva versión del ASP para la plataforma .NET. En la plataforma de programación de software libre llamada Mono también existe una librería similar a ADO.NET, lo que significa que ahora, la tecnología ADO.NET se puede usar en otros sistemas operativos aparte de Windows, como Linux, Mac OS X, BSD, y Solaris. ADO.NET es mucho más poderoso que ADO pero también es muy diferente, por lo que es necesario rediseñar los programas hechos con ADO, para que funcionen en él.

46

ADO es un intermediario entre el programa y la base de datos. El programa no ve la base de datos directamente, sino que hace todo el trabajo a través de ADO. Usando ADO, el programa se comunica con la base de datos, consulta, edita, inserta, borra, registros, añade tablas, etc. ADO a su vez se comunica con la base de datos a través de un "proveedor de datos".

En la dirección contraria, la base de datos responde, comunicándose con el proveedor de datos, éste con ADO, y al final, la información llega al programa. Figura 14. Ejemplo de Respuesta de una Base de Datos Utilizando ADO.

Una vez que el programa tiene la información proveniente de la base de datos, puede hacer con ella lo que considere, como por ejemplo, puede desplegarla en una página Web.

Los usuarios solicitados son los siguientes:

Tabla 5. Base de Datos Utilizando ADO y Mostrada en una Web

2.15.3 Principales componentes de ADO.

Connection (Permite establecer una conexión con la base de datos) Recordset (Maneja un conjunto de records de la base de datos) Command (Permite enviar órdenes SQL para ser ejecutados por la base de

datos).

47

2.15.4 Otros componentes de ADO.

Record (Permite manejar un registro, típicamente pero no exclusivamente, de una fuente diferente a una base de datos. Uno de sus usos es la representación de datos que no están estructurados en forma de Tablas, como por ejemplo que tengan una estructura tipo árbol.

Field (Permite manipular un campo perteneciente a un Record o un Recordset)

Parameter (Permite configurar un parámetro para una consulta SQL. Se usa con Command)

Stream (Permite manejar flujos de datos (streams), provenientes de ficheros de texto, páginas web, etc)

Error (Indica las características de los errores que pudieran suceder al ejecutar métodos de los objetos de ADO)

Property (Contiene información perteneciente a un objeto determinado)

2.15.5 Objetos Connection, Recordset y Command. Los 3 principales componentes de ADO son Connection, Recordset y Command (la conexión, el recordset, y la orden).

Figura 15. Componentes ADO

2.15.6 Conexión. La conexión es como una autopista que permite el flujo de datos entre el programa y la base de datos. Por ella pueden viajar las órdenes que desde el programa se usan para hacer solicitudes de información a la base de datos o para realizar una operación dentro de ella como borrar registros, añadir registros, modificar tablas, etc. También, por esta autopista, pueden ir y venir los datos, desde y hacia la base de datos, entre otras cosas. Tanto el recordset como la orden usan la conexión para comunicarse con la base de datos. La conexión se comunica con la base de datos a través de un intermediario llamado "proveedor de datos".

Figura 16. Conexión Aplicación - Base de Datos (1)

48

2.15.7 Proveedor de datos. El proveedor de datos es un componente que se relaciona directamente con la base de datos. Hay un proveedor de datos por cada tipo de base de datos. Así, las bases de datos de tipo Access, SQL Server, Oracle, MySQL, tienen, cada una, un proveedor de datos específico.

La conexión ADO puede usar dos tipos de proveedores de datos, OLE DB y ODBC, siendo OLE DB el tipo de proveedor nativo. Cuando no existe un proveedor de OLE DB específico para una base de datos determinada, y en cambio existe un proveedor ODBC, la conexión ADO puede usarlo para comunicarse con la base de datos, sin embargo, no directamente, sino a través de un proveedor OLE DB especial que sirve de intermediario entre ADO y ODBC. La figura de abajo muestra, a la izquierda, un esquema de los diferentes componentes que existen entre un programa y la base de datos, y, a la derecha, muestra el camino que recorre la información, usando por un lado OLE DB, y por el otro ODBC. Nótese que al usar ODBC, la ruta es más larga porque tiene que pasarse por más componentes. Esto hace la comunicación un poco más lenta. Todo esto es transparente al usuario de ADO, quien, en líneas generales, no tiene por que enterarse ni conocer estos mecanismos.

Figura 17. Conexión Aplicación - Base de Datos (2)

ADO tiene un alto grado de abstracción, lo que significa que, al mantener una interface sencilla, oculta los detalles complejos del manejo de la base de datos. Un programa puede saltarse completamente el ADO, y acceder a la base de datos directamente de 3 maneras diferentes, a través de OLDB, ODBC, o por ODBC usando una capa intermedia de OLE DB. Al trabajar de esta manera, se tiene la ventaja de una mayor funcionalidad que no contiene ADO a cambio de una mayor complejidad en la programación. Esto es necesario algunas veces, en ciertos tipos de programas y para ciertas necesidades, pero no es lo común.

49

Figura 18. Acceso a la Base de Datos por medio de ADO

2.15.8 Recordset. El Recordset es, como su nombre lo indica, un conjunto de records. En general, sus datos tienen su origen en una base de datos, aunque también pueden generarse independientemente de ésta. Un recordset puede contener cero o más records (registros). Cada recordset tiene una colección de campos, que es común a todos los records. Podemos verlo como una matriz o tabla, en donde las filas son los records, y las columnas son los campos. Figura 19. Recordset con algunos datos de la tabla de empleados.

Un recordset puede tener varias características que el programador define a su conveniencia. Puede ser de solo lectura, o de lectura-escritura, por ejemplo. La información con que se carga el recordset puede provenir de una tabla o varias tablas, de la base de datos. El recordset, tiene capacidades de navegación entre su conjunto de registros. Puede:

Moverse al siguiente registro

50

Moverse al anterior Moverse al primero Moverse al último y otros

En un recordset, se ve y se pueden editar los datos de un solo registro en un tiempo dado, se pueden manipular los datos de los campos del "registro actual" en donde se encuentra. Además de editar registros, también se puede:

Insertar registros nuevos Borrar registros La edición, la inserción y el borrado de registros en el recordset, se

reflejarán en la Base de Datos.

51

3. METODOLOGIA

3.1 TIPO DE INVESTIGACION El tipo de investigación que se desarrolló para el cumplimiento de los objetivos propuestos fue inicialmente conocer la infraestructura de la red telefónica con que cuenta EMCALI telecomunicaciones, se evaluaron los procedimientos realizados por la empresa para el análisis de reclamos por parte de los usuarios pertenecientes a las centrales telefónica AXE ERICSSON y EWSD SIEMENS. Se paso a la etapa de estudio de cada una de las centrales con material aportado por la empresa, el cual contenía toda la información acerca de cada uno de los archivos a procesar durante nuestro proyecto, todo esto para aprovechar los recursos con que cuenta la empresa y desarrollar una aplicación eficaz y confiable. 3.2 DISEÑO DE LA INVESTIGACION Para la elaboración de la investigación se seleccionaron los archivos CDR de las centrales telefónicas AXE ERICSSON y EWSD SIEMENS, los cuales son descargados de acuerdo a la cantidad almacenada dentro del buffer de la central, donde se muestra la información de cada una de las llamadas realizadas por los usuarios del servicio de dichas centrales, esta información para la central EWSD esta codificada en binario y para centrales AXE ERICCSON la información viene en un formato de texto plano en decimal.

52

4. DESARROLLO DEL PROYECTO

4.1 IDENTIFICACIÓN DE LAS NECESIDADES INICIALES Para el buen desarrollo de software es esencial realizar una especificación completa de los requerimientos del mismo. Independientemente de lo bien diseñado o codificado que esté, un programa pobremente especificado decepcionará al usuario y hará fracasar el desarrollo. Por tal motivo EMCALI y en especial el departamento de conmutación dirigido por el ingeniero Jairo Antonio Chávez comunicaron las necesidades principales que debe tener el diseño del software para resolver sus necesidades. El sistema debe poseer las siguientes características:

El diseño del software requiere una alta calidad y confiabilidad. El software debe autentificarse ante la administración de archivos. El sistema debe ser confiable. (no existan perdida de datos) El sistema debe poseer una base de datos para administrar, almacenar el

consumo de cada uno de los usuarios. El software debe tener opción de generar reportes. El software debe ser de fácil manejo. El sistema debe ser económico.

4.2 PLAN ESTRATEGICO El desarrollo de la aplicación se dividió en tres etapas, decodificación y organización (DO), extracción de datos de archivos CDR`s y almacenamiento de datos (EAD) e integración, las cuales se desarrollaron con los requerimientos exigidos por la empresa así buscando cumplir con el objetivo del proyecto. La aplicación inicia con la etapa de decodificación y organización (DO), la cual es procesar el archivo entregado por las centrales de conmutación en este caso las plantas EWSD y AXE.las centrales EWSD por su codificación binaria (formato AMA) requiere de la etapa de decodificación, para el caso de las centrales AXE solo requieren de organización debido a que sus campos de información son explícitos, al terminar la decodificación en el caso debido se procede a la organización de los datos del archivo CDR. Buscando que los archivos CDR’s permitan identificar la información de interés, para luego pasar a la segunda etapa, que consiste en la extracción de los campos de información requeridos y almacenamiento al gestor de base de datos (MySQL), por último se llega a la etapa de integración la cual consiste en consultar la

53

información almacenada que se extrajo de los archivos CDR`s, esta se realiza gracias al servidor web APACHE y un navegador web el cual puede ser INTERNET EXPLORER o MOZILLA FIREFOX los cuales permitirán la interacción entre el usuario y las bases de datos. 4.2.1 Decodificación y organización (DO). En el proceso de decodificación básicamente fue tomar los archivos CDR`s, entregados por cada una de las centrales EWSD desde la ubicación donde están almacenados, que se encuentran codificados de forma binaria y convertir su contenido por medio del programa desarrollado en Visual Basic 6.0 a un formato hexadecimal, ya que este formato nos facilita la identificación de cada uno de los campos. La sentencia en código VB6 es la siguiente para la conversión del formato AMA al formato hexadecimal este proceso se realiza cuando el personal administrativo requiera decodificar y ordenar el archivo AMA determinado.

Esta parte del script es la encargada de realizarme la decodificación del archivo AMA y la organización del mismo la cual es almacenada dentro de un nuevo archivo llamado proc.txt. En cuanto a la organización de los archivos CDR`s de la planta AXE se toman los archivos desde la ubicación por medio de VB6, este realiza la organización de los datos, debido a que cada llamada corresponde a un numero de caracteres, en este caso 132 caracteres por cada llamada. La sentencia a continuación es la que me permite la organización de los datos de una central AXE.

54

Este script corresponde a la organización de los datos de las centrales AXE, este se ejecutara cuando el personal administrativo requiera organizar datos de las plantas de conmutación AXE. 4.2.2 Extracción de datos de archivo CDR`s y almacenamiento de datos (EAD). Una vez que la información este totalmente decodificada y organizada, esta es guardada en un archivo, se procede en VB6 a abrir y recorrer el archivo, se extrae los campos de información requeridos (abonado A, abonado B, fecha, hora, duración), los cuales son almacenados en el gestor de base de datos MySQL esta conexión entre VB6 y Mysql se genera debido a la herramienta ADO. A continuación mostraremos las sentencias en VB6 para la extracción de datos en las plantas de conmutación AXE. Sentencia para extracción de datos AXE

Sentencia para extracción de datos EWSD

55

Para la creación de la base de datos se hizo uso del gestor de base de datos MySQL que brinda muchas ventajas y opciones a la hora de trabajar con bases de datos. La base de datos es un conjunto exhaustivo no redundante de datos estructurados organizados independientemente de su utilización y su implementación en máquina accesibles en tiempo real y compatibles con usuarios concurrentes con necesidad de información diferente y no predicable en tiempo, la base de datos es diseñada de forma dinámica ya que la información es modificada de acuerdo a las necesidades del usuario, permitiendo procesos de actualización y consulta, esta base de datos se creó por medio de phpmyadmin, es una herramienta escrita en PHP con la intención de manejar la administración de MySQL a través de páginas webs, utilizando Internet. Actualmente puede crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos, ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar datos en varios formatos. No es más que una herramienta de gestión para bases de datos, para la aplicación posee el nombre de dbpasantia y cuya tabla se llama contenido la cual recibe toda la información decodificada y organizada (DO), el código correspondiente en MYSQL y PHP a estas conexiones seria: CREATE DATABASE `dbpasantia` (1) CREATE TABLE `sexo`.`contenido` ( (2) `Id` INT( 6 ) NOT NULL , AUTO_INCREMENT, `abonadoA` TEXT NOT NULL , `abonadoB` TEXT NOT NULL , `fecha` DATE NOT NULL , `hora` TIME NOT NULL , `duracion` TIME NOT NULL , `conversion` INT( 5 ) NOT NULL ) ENGINE = MYISAM PRYMARY KEY(Id)

56

El código (1) crea la base de datos en MySQL y el código (2) crea la tabla contenido, la cual contendrá la información correspondiente de los archivos CDR’s.

$link = mysql_connect('localhost', 'root', ''); $db_selected = mysql_select_db('dbpasantia', $link);

En un editor de PHP (PHPdesigner 2007) se crea la variable $link la cual almacenara la dirección de la conexión de MySQL, el servidor es localhost el usuario root y para este caso la contraseña esta en blanco, la variable $dbselect almacena la conexión y selección de la base de datos dbpasantia. INSERT INTO `dbpasantia`.`contenido` ( (3) `Id` , `abonadoA` , `abonadoB` , `fecha` , `hora` , `duracion` , `conversion` ) VALUES ( '', '1111111', '2222222’, '2007-03-22', '00:25:23', '00:00:23', '1' ); En el código (3), se muestra la forma en que los datos son ingresados a la base de datos dbpasantia y a su vez a la tabla contenido. 4.3 DESCRIPCION GENERAL DE LA APLICACIÓN Esta aplicación está orientada a personal administrativo de EMCALI y demás usuarios del servicio de telefonía cuyo número telefónico este en las centrales AXE y EWSD, brindando la facilidad de realizar reclamos para el usuario y mayor organización para el personal administrativo de la empresa. 4.3.1 Interfaz personal administrativo. El personal operativo se va encargar de la parte de administración de archivos y creación de cuentas de usuarios, contara con una interfaz grafica desarrollada VB6.0 la cual le va a brindar seguridad y facilidades de manejo.

Autentificación de operario; Esta permitirá al operario ingresar a la aplicación desarrollada en VB6.0, permitiéndole a la aplicación contar con un único nivel de seguridad (operario), la aplicación se ejecutara después de ingresado el login y el password. Al momento de la aplicación el operario se va a encontrar con la siguiente ventana.

57

Figura 20. Inicio de Sesión de la aplicación en Visual Basic 6.0

Menu de opciones; En esta encontramos dos pestañas principales, las cuales nos permitirán seleccionar las diversas acciones a desarrollar con cada archivo CDR de las plantas AXE y EWSD. Figura 21. Interfaz menú de opciones

Interfaz de carga de archivos; En esta interfaz se toman los archivos CDR entregados por las centrales desde su ubicación especifica dependiendo de cada central, también es la encargada de procesar los archivos y realizar las funciones necesarias de DO (decodificación y organización) y de EAD (extracción de datos de archivos CDR`s y almacenamiento de datos). Además es la que permite al operario de la aplicación crear nuevos usuarios para ingresar a la interfaz de usuario (permite dar un login y contraseña al usuario).

58

Figura 22. Interfaz de carga de archivos EWSD

Figura 23. Interfaz de carga de archivos AXE

Figura 24. Interfaz nuevo usuario

59

4.4 INTERFAZ CLIENTE Esta interfaz se encargara de interactuar con los clientes pertenecientes a las centrales AXE, EWSD y la información almacenada por parte de los operarios de la aplicación de VB6.0. La interfaz de cliente posee una interacción amigable y está desarrollada en PHP. La consulta del registro de llamadas se puede hacer por medio de la WEB (internet) o en PC ubicados en los C.A.L.I. Tabla 6. Descripción general de la aplicación

Campo Detalle Id Genera el número de registro en el cual es almacenado la

información del usuario, el se incrementa automáticamente. abonadoA Almacena el número telefónico del usuario que realiza la

llamada. abonadoB almacena el número telefónico al cual el usuario realiza la

llamada Fecha almacena la fecha en la cual es usuario realizo la llamada Hora almacena la hora en la cual el usuario llamo duración almacena la duración de la llamada en horas minutos y

segundos conversión Almacena la cantidad de minutos consumidos.

4.4.1 Pagina principal. Al momento de iniciar la aplicación el usuario se encontrara con los siguientes menús de opciones:

Principal Acerca de Registro Enlaces Otros

Contiene información de interés general para los usuarios.

60

Figura 25. Página Principal

Pagina acerca de; Esta posee información del proyecto desarrollado. Figura 26. Pagina Acerca de

Pagina de registro; Esta permite ingreso de los clientes con un login y un password para poder acceder a las consultas.

61

Figura 27. Pagina de Registro

Pagina consultas; Esta permite interactuar entre la información almacenada en la base de datos y el usuario. Esta se divide en dos tipos de búsqueda General. Personalizada.

A continuación se muestra Consulta General Figura 28. Consulta General

Consulta Personalizada

62

Figura 29. Consulta Personalizada.

Pagina enlaces; Permite comunicar esta página con sitios de interés general.

Figura 30. Pagina Enlaces.

Pagina otros; Contiene información del Ordenador Recomendado para que funcione en óptimas condiciones las aplicaciones desarrolladas y el sistema de protección anti cortes de energía. Esta posee dos secciones más:

S.A.I (Sistemas de Alimentación Ininterrumpida) Ordenador

63

A continuación imagen de S.A.I Figura 31. Pagina Otros.

4.4.2 Como realizar consultas. Antes de realizar cualquier tipo de consulta se debe autenticar el usuario que va a consultar, por lo tanto se debe realizar los siguientes pasos. Ir al menú Registrase y dar clic. Figura 32. Ingreso de Registro

Debe de aparecer la siguiente pagina, en la cual digita el número telefónico y la contraseña de usuario otorgada por EMCALI. Lo siguiente seria se presiona el botón Login el cual se direcciona a la siguiente página.

64

Figura 33. Autentificación valida

Y por último se hace clic en CLIC AQUI PARA INGRESAR A CONSULTAS,

Consulta General. Figura 34. Consulta General.

Ahora se digita el número telefónico a consultar y se oprime el botón enviar consulta. Ahora la consulta nos dará el siguiente resultado este reporte puede ser impreso.

65

Figura 35. Resultado de Consulta General.

Consulta Personalizada La consulta personalizada se utiliza cuando el usuario desea buscar por temporadas, en este caso por fechas. Figura 36. Consulta Personalizada

Como resultado será

66

Figura 37. Resultado de la Consulta Personalizada.

4.5 EJECUCION DE LA APLICACIÓN Los archivos CDR’s descargados a través del sistema de gestión GERTEL por medio del comando talk tiketing, son almacenados en discos magnéticos y estos son archivados según la fecha de cada uno, posteriormente son trasladados por personal administrativo a un ordenador (este procedimiento se hace manualmente), el cual tendrá la aplicación desarrollada en visual basic 6.0, estos archivos de texto que se sustraen de los discos de almacenamiento magnéticos se decodifican y organizan. Después del proceso anterior se almacena la información en la base de datos realizada en MySQL quedando así lista la información para ser consultada, en ella se almacenan todo los campos de interés para el proyecto y el usuario. Y por último la aplicación web desarrollada brinda acceso al usuario a la base de datos para únicamente poder consultar la información de interés. A continuación la aplicación web desarrollada brinda acceso al usuario a la base de datos para solamente poder leer los datos.

67

Figura 38. Descripción de la Aplicación.

4.6 LENGUAJE DE MODELADO UNIFICADO

(UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; aún cuando todavía no es un estándar oficial, está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables. Es importante resaltar que UML es un "lenguaje" para especificar y no para describir métodos o procesos. Se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado de Rational) -pero no especifica en sí mismo qué metodología o proceso usar.

68

4.6.1 Definición de actores. Figura 39. Definición de Actores

4.6.2 Usuarios del sistema. Los usuarios de este software serán:

El Usuario primario (Cliente) que será el encargado de realizar las consultas (General y Personalizada) o requerimientos de servicios e interactuara con el software de manera directa.

El Operador tendrá todos los privilegios sobre el sistema pudiendo también ingresar nueva información a la base de datos (D.B) a cerca de los clientes y modificarlos y adquirir los reportes de los usuarios que acceden al servicio. Diagramas de Caso de Uso Figura 40. Diagrama de Casos De Uso.

4.6.3 Descripción de casos de uso. Nombre: Modificar Datos de Usuario Actores: Operador Función: Permitir el mantenimiento y el flujo correcto del sistema.

69

Descripción: El Operador puede registrar datos nuevos de usuarios identificando características nuevas de este como contraseñas, y agregar más registros de datos requeridos para que todo esto quede almacenado en la base de datos. Referencias: Requiere un previo almacenamiento de los datos antes de ser modificados y compete las relaciones comerciales que se han tenido previamente con la empresa todos estos datos irán a la base de datos de la empresa que se maneja. Nombre: Generar Reporte Actores: Operador Función: Permitir el mantenimiento y el flujo correcto del sistema. Descripción: El operador debe recibir un informe detallado de la historia del usuario que solicite, número del teléfono que mantenga con la empresa actualmente para realizar un seguimiento a cada usuario. Referencias: El reporte que se genera depende de los datos establecidos previamente en la base de datos y que los demás autores “operadores” han ingresado al sistema. Nombre: Crear un Usuario Actores: Operador Función: Permitir el mantenimiento y el flujo correcto del sistema. Descripción: El Operador creara un usuario en la base de datos al presentarse la solicitud y confirmación por parte del cliente con la información detallada que se ha ingresado y los servicios que esa requiriendo Referencias: la creación de usuario se realiza a medida que los datos son ingresados por el operador pero el ingreso de los datos pertinentes del cliente solo serán guardados en la base de datos cuando se de la confirmación del servicio por parte del cliente. Nombre: Genera Login y Password Actores: Operador Función: Realizar la primera etapa de pedido al sistema y almacenar sus datos. Descripción: El sistema le entregara un login y un password tan pronto como el cliente lo solicite y hagan confirmación de la prestación del servicio estos

70

datos llegaran por el correo y el cliente podrá acceder a la página de la empresa y confirmar que se ha procesado su petición. Referencias: La etapa de Login y Password depende de que se haya aceptado el servicio por parte del usuario y que se genere un usuario en la base de datos. Nombre: Ingreso de Datos Actores: operador Función: Almacenar datos. Descripción: El operador ingresara los datos para la actualización de los registros Referencias: El ingreso de datos del usuario es la pieza fundamental para que se pueda mantener la información del servicio totalmente actualizada. Nombre: consulta a realizar Actores: cliente Función: Realizar la primera etapa de consulta al sistema y logiar sus datos. Descripción: El sistema le presenta al cliente un menú de las consultas a realizar la web, como las búsquedas generales y personalizada por medio de una GUI que presentara una ficha para que el cliente ingrese su petición. Referencias: Como se dijo anteriormente el usuario tendrá el ingreso de datos a través de una ficha que registrara su visita en una GUI. Nombre: registro Actores: cliente Función: confirmar el pedido de la consulta. Descripción: El sistema despliega por medio de una lista para ingresar los parámetros de inicio de sesión, y después de ingresado en el sistema el cliente escoge el tipo de búsqueda a realizar. Referencias: De esta etapa depende de que se le otorgue un login y un password a un usuario y que los datos se ingresen en la base de datos. Nombre: Generar Reporte

71

Actores: Cliente Función: brindar información detallada al cliente sobre su servicio. Descripción: El cliente debe recibir un informe detallado de la historia de las llamadas telefónicas que solicite. Referencias: El reporte que se genera depende de los datos establecidos previamente en la base de datos y que los demás autores han ingresado al sistema.

72

5. CONCLUSIONES

Con el desarrollo de este proyecto se contribuye, al área de telefonía dar un manejo adecuado y de fácil utilización, en el proceso de reclamos en el cual los usuarios estarán informados detalladamente de sus consumos telefónicos.

Con este proyecto, se conocieron las diferentes tecnologías (EWSD, AXE) con las que cuenta EMCALI Telecomunicaciones para brindar el servicio telefónico a Santiago de Cali, Yumbo y parcelaciones.

Con la aplicación se desarrolló una solución rápida y sencilla de almacenar información del consumo de los abonados pertenecientes a las plantas de conmutación AXE y EWSD que posee EMCALI, agilizando la forma de realizar los reclamos de telefonía, para así, poder ofrecer un excelente servicio a la comunidad. La aplicación desarrollada es una herramienta con la cual EMCALI telecomunicaciones, pretende a largo plazo disminuir las quejas por concepto de reclamos de telefonía y así mejorar el servicio al cliente prestado actualmente. Todos los objetivos planteados para el desarrollo del proyecto fueron cumplidos a cabalidad.

73

BIBLIOGRAFIA

AXE manual. Manual de operación central AXE (Ericsson), Viena: Ericsson 2000. 5132 p. Desarrollo Web: Programación en PHP. Introducción al manual II de javaScript [en línea]. Las Rozas, Madrid: Compuweb, 2006. [Consultado 8 de Agosto, 2007], Disponible en internet http://www.desarrolloweb.com/manuales/26/]. EWSD manual. Versión 12, Manual de operación central EWSD (Siemens), Múnich: Siemens AG1997. 5698 p. INSTITUTO COLOMBIANO DE NORMAS TÉCNICA Y CERTIFICACIÓN. Tesis y otros trabajos de grado, Bogota: ICONTEC. 2006. 78 p. NTC. 1486 STEVEN, Heyman Mark. Visual Basic 6.0. México: Prentice Hall. 1998. 826 p. Wikipedia: Enciclopedia Libre [en línea]. Florida: Wikipedia Foundation, 2006. [Consultado 20 de Septiembre, 2007]. Disponible en Internet http://es.wikipedia.org/wiki/PHP

74

ANEXOS

Anexo 1. Manual de Usuario

MANUAL DE USUARIO SARA

AUTOMATIZACION SISTEMA CDR

DISEÑO Y AUTOMATIZACION DEL SISTEMA CDR

EMPRESAS MUNICIPALES DE CALI EMCALI E.I.C.E-E.S.P DICIEMBRE

2007

75

Todos los derechos reservados.

No se permite la reproducción total o parcial, la traducción, anotación o duplicación de este documento de ninguna manera o por ningún medio sin permiso previo escrito del DEPARTAMENTO DE CONMUTACION DE EMCALI E.I.C.E.

EMCALI E.I.C.E. se reserva el derecho de modificar este manual debido a actualizaciones del producto u otras causas sin notificar a los usuarios anticipadamente

Departamento de Conmutación Santiago de Cali Diciembre del 2007

76

CONTENIDO Pág.

INTRODUCCION 8 1. REQUERIMIENTOS DEL SISTEMA. 9 2. INSTALACION Y CONFIGURACION. 10 3. CREACION Y CONFIGURACION DE BASES DE DATOS EN MySQL UTILIZANDO phpMyAdmin. 14 4. DESCRIPCION GENERAL DE LA APLICACIÓN. 17 4.1. INTERFAZ PERSONAL ADMINISTRATIVO. 17 4.2. AUTENTIFICACION DE OPERARIO. 17 4.2.1. MENU DE OPCIONES. 17 4.2.2. INTERFAZ DE CARGA DE ARCHIVOS. 18 4.2.3. INTERFAZ NUEVO USUARIO. 19 4.3. INTERFAZ CLIENTE. 19 4.3.1. PAGINA PRINCIPAL. 19 4.3.2. PAGINA ACERCA DE. 20 4.3.3 PAGINA REGISTRO. 21 4.3.4 PAGINA CONSULTAS. 21 4.3.5. PAGINA ENLACES. 22 4.3.6. PAGINA OTROS. 23 4.4. COMO REALIZAR CONSULTAS. 24 4.4.1 CONSULTA GENERAL. 24 4.4.2. CONSULTA PERSONALIZADA. 25 4.5. CERRAR SESION 26

77

5. HARDWARE DE PROCESOS Y SEGURIDAD ELECTRICA. 27

5.1. SISTEMA RAID 27 5.2. SEGURIDAD ELECTRICA. 29 5.2.1. CONSULTA PERSONALIZADA. 29 5.2.2 POTENCIA. 30 5.2.3 AUTONOMIA. 30 5.2.4 SAI “On-Line” 30 5.2.5. SAI “Off-Line”. 30 5.2.6. SAI DE LÍNEA INTERACTIVA o “In-Line”. 31 5.2.7. SELECCIÓN DEL SAI. 32 5.3. HARDWARE DE PROCESOS. 33 5.3.1. ORDENADOR RECOMENDADO. 33

78

LISTA DE TABLAS Pág.

Tabla 1 Requerimientos de software 9 Tabla 2 Requerimientos de hardware 9 Tabla 3 Campos de la Base de Datos. 15 Tabla 4 Campo y Tipo de Registro. 15 Tabla 5 Características de la Tarjeta Adaptec SAS

RAID 31605 29 Tabla 6 Ordenador Recomendado. 34

79

LISTA DE FIGURAS

Pág.

Figura 1. Comienzo de Instalación de XAMPP 10 Figura 2. Basic Package 11 Figura 3. Selección de Servicios. 11 Figura 4. Configuración de Archivos. 12 Figura 5. Instalación Completa 12 Figura 6. Verificación de Instalación Correcta. 13 Figura 7. Control Panel. 13 Figura 8. Interfaz phpMyAdmin. 14 Figura 9. Nueva Tabla y Cantidad de Campos. 15 Figura 10. Base de Datos Terminada. 16 Figura 11. Base de Datos Preparada para Recibir Datos. 16 Figura 12. Inicio de Sesión de la aplicación en Visual

Basic 6.0 17

Figura 13. Menú de Opciones. 18 Figura 14. Carga de Archivos AXE. 18 Figura 15. Carga de Archivos EWSD. 18 Figura 16. Nuevo Usuario. 19 Figura 17. Página Principal. 20 Figura 18. Pagina Acerca de. 20 Figura 19. Pagina Registro. 21 Figura 20. Pagina Consulta General. 21

80

Figura 21. Consulta Personalizada. 22 Figura 22. Pagina Enlaces. 22 Figura 23. Pagina Otros. 23 Figura 24. Consulta General. 24 Figura 25. Reporte – Consulta General. 24 Figura 26. Consulta Personalizada. 25 Figura 27. Reporte – Consulta Personalizada. 25 Figura 28. Cerrar Sesión – Consulta General. 26 Figura 29. Cerrar Sesión – Consulta Personalizada. 26 Figura 30. Características del Sistema S.A.I. 33

81

INTRODUCCION

Este manual permitirá aprender a utilizar todas las funcionalidades básicas del SISTEMA DE AUTOMATIZACIÓN CDR. El objetivo del manual es brindar una ayuda al usuario de la aplicación acerca de todas las funcionalidades de la aplicación, instalación y requerimientos necesarios para un buen aprovechamiento.

82

1. REQUERIMIENTOS DEL SISTEMA

Para el buen aprovechamiento del SISTEMA DE AUTOMATIZACION CDR se requiere de un equipo y un software de las siguientes características.

TABLA 1. REQUERIMIENTOS DE SOFTWARE

REQUERIMIENTO RECOMENDACIÓN SISTEMA

OPERATIVO WINDOWS 2000 - WINDOWS XP

NAVEGADOR WEB

MOZILLA FIREFOX 1.5 O SUPERIORES O INTERNET EXPLORER 5.0 O

SUPERIORES PAQUETE DE SOFWARE * XAMPP-WIN32-1.6.4

* El paquete de software incluye: MySQL 5, APACHE HTTP SERVER.

TABLA 2. REQUERIMIENTOS DE HARDWARE REQUERIMIENTO RECOMENDACIÓN CAPACIDAD DE

ALMACENAMIENTODISPONIBILIDAD DE DISCO

DURO DE 30Gb VELOCIDAD DE PROCESADOR 128 Mb O SUPERIOR MEMORIA RAM 128Mb O SUPERIOR

83

2. INSTALACION Y CONFIGURACION

Instalación del XAMPP-WIN32-1.6.4 Nota:

Este software es de libre distribución y se puede descargar de la página principal de los creadores. http://www.apachefriends.org/en/xampp-windows.html Una vez se tenga el instalador de esta aplicación se ejecuta. Y se realizan los siguientes pasos.

Pasos a seguir para la instalación de XAMPP-WIN-32-1.6.4

Figura 1. Comienzo de Instalacion de XAMPP.

Damos click en next

84

Figura 2. Basic Package

Click en next

Figura 3. Selección de Servicios. Se Activan los servicios necesarios (apache y MySQL como lo muestra el en la figura) para la aplicación y se procede a dar clic en INSTALL.

85

Figura 4. Configuración de Archivos. Se procede a esperar que la aplicación termine de configurar la instalación en el equipo.

Figura 5. Instalación Completa. Se da clic en FINISH y se procede a verificar que este instalado correctamente.

86

Figura 6. Verificación de Instalación Correcta. Para eso se dirige a Inicio Todos los Programas Apache Friends XAMPP XAMPP Control Panel.

Figura 7. Control Panel.

87

En el XAMPP Control Panel se puede observar que el servidor Apache y el servicio MySQL están Activos, en esta parte se puede parar e iniciar los servicios de estos cuando se desee. Ademas de ello trae consigo información básica del sistema en el cual se está trabajando y el directorio donde se encuentra instalado el XAMPP.

88

3. CREACION Y CONFIGURACION DE BASES DE DATOS EN MySQL UTILIZANDO phpMyAdmin.

Para la creación de la base de datos se utiliza phpMyAdmin que es de libre distribución y además viene instalado en el XAMPP. Para ingresar a la interfaz del phpMyAdmin, se utiliza un explorador web, como se comento anteriormente se pueden utilizar Mozila Firefox 1.5, Internet Explorer 5.0 o superiores a estos. En la barra de Herramientas de navegación, se digita la dirección del servidor a la cual se va a dirigir, para este caso será http://localhost/phpmyadmin.

Figura 8. Interfaz phpMyAdmin.

Después de ingresar a la interfaz, se procede a crear la base de datos, para ello se digita el nombre de la base de datos en la casilla de Crear nueva base de Datos.

Figura 9. Nueva Tabla y Cantidad de Campos.

Ahora se digita la Cantidad de Campos de va a poseer la base de Datos. Para este caso serán 7 y el nombre de la tabla contenedora de esta información. Por último se procede a dar clic en Crear.

89

Tabla 3. Campos de la Base de Datos.

Campo Detalle Id Genera el número de registro en el cual

es almacenado la información del usuario, el se incrementa

automáticamente. abonadoA Almacena el número telefónico del

usuario que realiza la llamada. abonadoB almacena el número telefónico al cual el

usuario realiza la llamada fecha almacena la fecha en la cual es usuario

realizo la llamada hora almacena la hora en la cual el usuario

llamo duración almacena la duración de la llamada en

horas minutos y segundos conversión Almacena la cantidad de minutos

consumidos.

Tabla 4. Campo y Tipo de Registro.

Se digitan los nombres de los campos y se escoge el tipo de dato a utilizar.

90

Figura 10. Base de Datos Terminada. Así se verá ya al finalizar la configuración de la base de datos, se da clic en Continuar

Figura 11. Base de Datos Preparada para Recibir Datos.

91

Por lo tanto la base de datos ya quedaría lista para recibir datos. hacer consultas desde visual Basic y de la página Web en php, respectivamente.

92

4. DESCRIPCION GENERAL DE LA APLICACIÓN.

Esta aplicación está orientada a personal administrativo de EMCALI y a demás a usuarios del servicio de telefonía cuyo número telefónico este en las centrales AXE y EWSD, brindando la facilidad de realizar reclamos para el usuario y mayor organización para el personal administrativo de la empresa.

4.1 INTERFAZ PERSONAL ADMINISTRATIVO

El personal operativo se va encargar de la parte de administración de archivos y creación de cuentas de usuarios, contara con una interfaz grafica desarrollada VB6.0 la cual le va a brindar seguridad y facilidades de manejo.

4.2. AUTENTIFICACION DE OPERARIO

Esta permitirá al operario ingresar a la aplicación desarrollada en VB6.0, permitiéndole a la aplicación contar con un único nivel de seguridad (operario), la aplicación se ejecutara después de ingresado el login y el password. Al momento de la aplicación el operario se va a encontrar con la siguiente ventana.

Figura 12. Inicio de Sesión de la aplicación en Visual Basic 6.0

4.2.1. MENU DE OPCIONES.

En esta encontramos tres pestañas principales, las cuales nos permitirán seleccionar las diversas acciones a desarrollar con cada archivo CDR de las plantas AXE y EWSD.tambien encontraremos la pestaña de crear usuario.

93

Figura 13. Menu de Opciones.

4.2.2. INTERFAZ DE CARGA DE ARCHIVOS.

En esta interfaz se toman los archivos CDR entregados por las centrales desde su ubicación especifica dependiendo de cada central, también es la encargada de procesar los archivos y realizar las funciones necesarias de DO (decodificación y organización) y de EAD (extracción de datos de archivo cdr`s y almacenamiento de datos).

Figura 14. Carga de Archivos AXE.

Figura 15. Carga de Archivos EWSD.

94

4.2.3. INTERFAZ NUEVO USUARIO.

En esta interfaz se crean los usuarios que requieran una clave de acceso al servicio de consulta.

Figura 16. Nuevo Usuario.

4.3. INTERFAZ CLIENTE

Esta interfaz se encargara de interactuar con los clientes pertenecientes a las centrales AXE, EWSD y la información almacenada por parte de los operarios de la aplicación de VB6.0. La interfaz de cliente posee una interacción amigable y está desarrollada en PHP.

4.3.1. PAGINA PRINCIPAL

Al momento de iniciar la aplicación el usuario se encontrara con los siguientes menús de opciones:

• Principal • Acerca de • Registro • Enlaces • Otros

Contiene información de interés general para los usuarios.

95

Figura 17. Página Principal.

4.3.2. PAGINA ACERCA DE

Esta posee información del proyecto desarrollado.

Figura 18. Pagina Acerca de.

4.3.3. PAGINA DE REGISTRO.

Esta permite ingreso de los clientes con un login y un password para poder acceder a las consultas.

96

Figura 19. Pagina Registro.

4.3.4. PAGINA CONSULTAS.

Esta permite interactuar entre la información almacenada en la base de datos y el usuario. Esta se divide en dos tipos de búsqueda

1. General. 2. Personalizada.

A continuación se muestra Consulta General

Figura 20. Pagina Consulta General.

97

Consulta Personalizada

Figura 21. Consulta Personalizada.

4.3.5. PAGINA ENLACES.

Permite comunicar esta página con sitios de interés general.

Figura 22. Pagina Enlaces.

98

4.3.6. PAGINA OTROS.

Contiene información del Ordenador Recomendado para que funcione en óptimas condiciones las aplicaciones desarrolladas y el sistema de protección anti cortes de energía. Esta posee dos secciones más:

1. S.A.I (Sistemas de Alimentación Ininterrumpida) 2. Ordenador

A continuación imagen de S.A.I.

Figura 23. Pagina Otros.

4.4. COMO REALIZAR CONSULTAS Antes de realizar cualquier tipo de consulta se debe autenticar el usuario que va a consultar, por lo tanto se debe realizar los siguientes pasos. Ir al menú Registrase y dar click.

99

4.4.1 CONSULTA GENERAL

Figura 24. Consulta General. Al dar click en enviar consulta nos aparecerá la siguiente pagina que genera el reporte de llamadas hechas por el usuario, este también tiene la opción de imprimir el reporte.

Figura 25. Reporte – Consulta General.

4.4.2. CONSULTA PERSONALIZADA

La consulta personalizada se utiliza cuando el usuario desea buscar por temporadas, en este caso por fechas.

100

Figura 26. Consulta Personalizada. Al dar click en enviar consulta nos aparecerá la siguiente pagina que genera el reporte de llamadas hechas por el usuario, este también tiene la opción de imprimir el reporte.

Figura 27. Reporte – Consulta Personalizada.

101

4.5. CERRAR SESIÓN Permite finalizar las consultas realizadas, esta opción esta en cada una de las páginas de búsquedas (General, Personalizada) establecidas.

Figura 28. Cerrar Sesion – Consulta General.

Figura 29. Cerrar Sesión – Consulta Personalizada.

102

Nota: Cada vez que el usuario termine de realizar la consulta, se recomienda cerrar sesión para evitar que personas indebidas violen su privacidad.

5. HARDWARE DE PROCESOS Y SEGURIDAD ELECTRICA

5.1. SISTEMA RAID En informática, el acrónimo RAID (originalmente del inglés Redundant Array of Inexpensive Disks, ‘conjunto redundante de discos baratos’, en la actualidad también de Redundant Array of Independent Disks, ‘conjunto redundante de discos independientes’) hace referencia a un sistema de almacenamiento informático que usa múltiples discos duros entre los que distribuye o replica los datos. Dependiendo de su configuración (a la que suele llamarse «nivel»), los beneficios de un RAID respecto a un único disco son uno o varios de los siguientes: mayor integridad, mejor tolerancia a fallos, más throughput (rendimiento) y más capacidad. En sus implementaciones originales, su ventaja clave era la habilidad de combinar varios dispositivos de bajo coste y tecnología más antigua en un conjunto que ofrecía mayor capacidad, fiabilidad, velocidad o una combinación de éstas que un solo dispositivo de última generación y coste más alto. Profesional hosting refuerza sus servidores de backup aplicando un RAID1: Un RAID 1 crea una copia exacta (o espejo) de un conjunto de datos en dos o más discos (array). Esto resulta útil cuando el rendimiento en lectura es más importante que la capacidad y también desde el punto de vista de la seguridad, pues un RAID 0 por ejemplo no es tolerante al fallo de uno de los discos, mientras que un RAID 1 sí, al disponer de la misma información en cada disco. Un conjunto RAID 1 es tan grande como el más pequeño de sus discos. Un RAID 1 clásico consiste en dos discos en espejo, lo que incrementa exponencialmente la fiabilidad respecto a un solo disco; es decir, la probabilidad de fallo del conjunto es igual al producto de las probabilidades de fallo de cada uno de los discos (pues para que el conjunto falle es necesario que lo hagan todos sus discos). Adicionalmente, dado que todos los datos están en dos o más discos, con hardware habitualmente independiente, el rendimiento de lectura se incrementa aproximadamente como múltiplo linear del número del

103

copias; es decir, un RAID 1 puede estar leyendo simultáneamente dos datos diferentes en dos discos diferentes, por lo que su rendimiento se duplica. Para maximizar los beneficios sobre el rendimiento del RAID 1 se recomienda el uso de controladoras de disco independientes, una para cada disco (práctica que algunos denominan splitting o duplexing). Como en el RAID 0, el tiempo medio de lectura se reduce, ya que los sectores a buscar pueden dividirse entre los discos, bajando el tiempo de búsqueda y subiendo la tasa de transferencia, con el único límite de la velocidad soportada por la controladora RAID. Sin embargo, muchas tarjetas RAID 1 IDE antiguas leen sólo de un disco de la pareja, por lo que su rendimiento es igual al de un único disco. Algunas implementaciones RAID 1 antiguas también leen de ambos discos simultáneamente y comparan los datos para detectar errores. La detección y corrección de errores en los discos duros modernos hacen esta práctica poco útil. Al escribir, el conjunto se comporta como un único disco, dado que los datos deben ser escritos en todos los discos del RAID 1. Por tanto, el rendimiento no mejora. El RAID 1 es un sistema apropiado en entornos donde la disponibilidad es crítica 24 horas al día. Aparte de los discos en espejo que crean el array en RAID 1 podemos marcar discos adicionales como reserva. Éstos se pueden definir como hot spare si queremos que estén en funcionamiento o standby hot spare, si queremos que estén en modo de espera. En el momento que alguno de los discos del espejo sufra algún fallo, uno de los discos de reserva entra a formar parte del array de discos espejo (entra instantáneamente si es un disco hot spare o tarda unos instantes si tiene que arrancar al ser un disco standby hot spare), duplicándose la información en él. Esto requiere que la aplicación de gestión del conjunto soporte la recuperación de los datos del disco en el momento de la división, procedimiento denominado recomposición (rebuilding). Éste es menos crítico que la presencia de una característica de snapshot en algunos sistemas de ficheros, en la que se reserva algún espacio para los cambios, presentando una vista estática en un punto temporal dado del sistema de ficheros. Alternativamente, un conjunto de discos puede ser almacenado de forma parecida a como se hace con las tradicionales cintas.

104

Tabla 5. Características de la Tarjeta Adaptec SAS RAID 31605

5.2. SEGURIDAD ELECTRICA

El sistema que se nombra a continuación protegerá al equipo de fluctuaciones y cortes de energía para evitar pérdidas de información. 5.2.1. ¿QUÉ ES UN SAI? Un SAI es un equipo eléctrico/electrónico encargado de alimentar y proteger cargas críticas, de tal manera que, aún faltando el suministro normal de red, es capaz de seguir alimentando a dicha carga durante un tiempo determinado.

105

Los parámetros más relevantes, que distinguen a un SAI de otro, son: 5.2.2. POTENCIA Indica la potencia máxima que ha tener la carga para que el SAI la pueda alimentar. 5.2.3. AUTONOMÍA Indica el tiempo en el que el SAI puede seguir alimentando a la carga cuando se produce un corte del suministro normal de red. Existen varios tipos de SAI, atendiendo a su estructura, elementos que lo forman, a su funcionamiento, etc. En general, se pueden dividir en los siguientes tipos: 5.2.4. SAI “On-Line” Son los SAI típicos. Se caracteriza por: Se intercalan entre el suministro de red normal y la carga que se quiere alimentar. Proporcionan una salida de corriente alterna independiente de la de la red normal, autogenerada a partir de una corriente continua. Proporcionan aislamiento entre la carga y la red normal y, por tanto, protección frente a cualquier anomalía de ésta. Esta es la tecnología que se encuentra en los SAI de uso industrial. 5.2.5. SAI “Off-Line” Estos tipos de SAI son más sencillos que los anteriores. Se utilizan en instalaciones de baja potencia y bajo coste. Se caracterizan por: No se intercalan entre el suministro de red normal y la carga a alimentar. Ésta es alimentada normalmente por la red. Tan solo cuando ésta falla la carga se alimenta de la corriente alterna generada por el SAI. Debido a que son equipos de bajo costo, a menudo no proporcionan una onda senoidal pura.

106

No protegen totalmente a la carga de las perturbaciones presentes en la red normal, puesto que no la aíslan. En el momento de la transferencia de carga, durante un fallo en el suministro de red, se produce una interrupción momentánea de la alimentación hacia la carga. Tal como se puede ver, las diferencias entre un tipo y otro son notables, hasta el punto de que es discutible admitir que los SAI Off-Line sean estrictamente SAI. 5.2.6. SAI DE LÍNEA INTERACTIVA o “In-Line” En una zona intermedia, participando de las características de los dos tipos anteriores, se encuentran los SAI de Línea Interactiva. Se caracterizan por: Se intercalan entre la red normal y la carga, por medio de un AVR o Acondicionador de Red. Pero no aíslan completamente a ésta de la red normal. En el funcionamiento normal, la carga se alimenta de la red, a través del AVR. Tan solo durante un corte de la red, la carga se alimenta de red alterna generada directamente por el SAI, a partir de una tensión continua. El AVR o acondicionador de red proporciona a la carga protección frente a fluctuaciones de tensión, tanto a la baja como al alza, dentro de unos márgenes. Está formado por un transformador y una serie de conmutadores de estado sólido (Triacs), que proporcionan una respuesta rápida a las fluctuaciones de la red, de tal manera que la carga no se ve afectada. Además van asociados a filtros y protecciones contra sobretensiones. El conjunto proporciona una protección a la carga razonable frente a perturbaciones en el suministro de red normal. Las conmutaciones cuando falla la red se realizan en el orden de los milisegundos, por lo que se puede decir que no afectan a la continuidad del suministro a la carga. Este tipo de SAI son los que se utilizan mayoritariamente para las instalaciones domésticas. En el resto de este documento, cuando se refiere a SAI, se refiere a SAI de este tipo. 5.2.7 SELECCIÓN DEL SAI.

107

Para poder seleccionar el SAI más conveniente para una instalación, basta con seguir los pasos que se indican a continuación. a) CALCULAR LA POTENCIA. En watios, de los elementos que se quieren proteger. Es importante asumir que un SAI es un sistema para emergencias, no para seguir trabajando con él cuando se pierde el suministro de energía, por lo que hay que ser muy restrictivos a la hora de elegir qué elementos debe proteger. En mi opinión, basta con la fuente del PC, el módem ADSL o similar y el monitor, si es TFT. a) Potencia real del PC. Para calcularla es conveniente utilizar alguna de las páginas Web dedicadas a ello. Hay que tener en cuenta que estas páginas ya suelen realizar un cálculo “al alza”, por lo que es importante no inflar por nuestra parte el resultado. b) Resto de elementos. Si se siguen las recomendaciones, deberán añadirse unos 50 watios más (módem + monitor TFT). Sumando los dos valores anteriores, se obtienen los watios necesarios. Este valor debe incrementarse en al menos un 15 %, pues hay que tener en cuenta el deterioro de la autonomía con los años y que no es conveniente hacer trabajar al SAI por encima del 90 % de su máxima potencia. Con ello, obtendremos la potencia mínima que ha de soportar el SAI. b) ELECCIÓN DEL SAI. Para elegir el SAI, se deben tener en cuenta los siguientes parámetros: i) Debe soportar la potencia calculada en el paso anterior. Es importante fijarse en los watios del SAI, no en los “VA”. La diferencia entre uno u otro dato será de un 30 a 50 % superior de los “VA” con respecto a la potencia en watios, según sea la eficiencia del SAI. ii) Comprobar los datos de autonomía. Normalmente, los fabricantes suelen dar el dato a plena y a media carga. Si no se dispone de alguno de ellos, una buena regla es que la autonomía a media carga es entre un 60 y un 70% superior al doble de la autonomía a plena carga. En

108

general, para los criterios expuestos, bastará con una autonomía a plena carga de 4 minutos. iii) Comparar precios, marcas y otras características (tamaño, peso, aspecto exterior, etc.) Este aspecto es bastante subjetivo, por lo que queda a expensas del interfecto. Como guía, comentar que no tiene mucho sentido invertir en un SAI más de 350 ni menos de 200 euros.

Figura 30. Caracteristicas del Sistema Sai.

5.3 HARDWARE DE PROCESOS 5.3.1. ORDENADOR RECOMENDADO Durante el desarrollo del proyecto, se llego a la conclusión que el Ordenador que se podría utilizar tendría las siguientes características.

Tabla 6. Ordenador Recomendado. ELEMENTO

CANTIDAD

CAPACIDA

REFERENCIA

HARDWARE

SOFTWARE

109

PROCESADOR

1 3GHz

AMD ATHLON 64X2 DUA

L COR

E 6000 (3.0

GHZ) SOCKET AM2

x

DISCO

DUROS

3 320GB

SATA 2

X

MOTHER

BOARD

1 MSI KN9 SLIT PLATINU

M

X

MEMORIA RAM

3 1GB

* X

UNIDAD

LECTORA DVD

1 * X

TARJETA PCI

RAID

1 8 PUERTOS

* X

TARJETA DE

VIDEO

1 256MB

* X

MONITOR

1 15" * X

110

SISTEMA S.A.I

1 20 MINUTOS

650 VA A

6 PUERTO

S

X

TECLADO

1 * X

MOUSE

1 * X

MICROSOF

T WINDOWS SERV

ER 2003

1 X

XAMPP

X

* Este requerimiento depende del comprador El costo aproximado de este ordenador es de 5’000.000 M/cte. Puesto que este ordenador debe de poseer un buen hardware de almacenamiento y procesamiento, debido a que va a realizar tareas de acumulación de datos de las centrales que posee EMCALI como lo son las AXE y EWSD.

Nota: Por favor lea cuidadosamente el manual anteriormente descrito antes de utilizar la aplicación. Los usuarios deberán asumir la responsabilidad de cualquier accidente provocado por el incumplimiento de las anteriores instrucciones.

111