Facultad de Ciencias de la Ingeniera Escuela de Ingeniera Civil en Informtica
APLICACIN WEB DE GESTIN DE ALARMAS Y REPORTES PARA EL SISTEMA DE CONTROL
DISTRIBUIDO DE LA CELULOSA ARAUCO PLANTA VALDIVIA.
Proyecto para optar al ttulo de Ingeniero Civil en Informtica
PATROCINANTE RODRIGO ARNOLDO SANDOVAL GARCA INGENIERO CIVIL INDUSTRIAL (E) INGENIERO EJ. ELECTRNICA PROFESOR CO-PATROCINANTE JUAN PABLO SALAZAR FERNNDEZ INGENIERO CIVIL EN INFORMTICA MAGISTER EN ADMINISTRACIN DE EMPRESAS INFORMANTE GLADYS MYRIAM MANSILLA GOMEZ INGENIERO MATEMTICO MAGSTER EN ESTADISTICA D.E.A TEORA DE LA SEAL Y LAS COMUNICACIONES
NICOLS FELIPE OPAZO SNCHEZ
VALDIVIA CHILE 2013
i
I. AGRADECIMIENTOS
Quisiera agradecer a mi pap y amigo Dios, porque gracias a l estamos en paz,
porque me ayudo a seguir caminando sin culpas ni penas, sino simplemente
cambiando las cosas que no nos agradaban. Muchas Gracias papi!
En segundo lugar quiero agradecer a mi esposa Rosmari, muchas gracias por tu
ayuda y apoyo, me has ayudado a salir adelante, Te amo.
Mis agradecimientos a mi familia que me apoyo y me dieron la posibilidad de
ingresar a la universidad y ver las cosas de forma diferente, permitindome as
acceder a ms oportunidades, en especial a mi pap, a pesar de que no deba me dio
su apoyo y nunca ha dejado de hacerlo. Los amo.
Agradecer tambin a don Juan Pablo Salazar junto con la seora Juanita, quienes me
ayudaron no solo en mi tesis, sino cuando estuve enfermo, me brindaron ayuda
econmicamente y su tiempo. Muchas gracias, sin ustedes esto no hubiera sido
posible.
Y no quisiera olvidar a mis amigos oos, sin los cuales yo no hubiera sido quien soy
ahora. En especial a Mauricio, que es como mi hermano. Los quiero mucho, muchas
gracias por su cario.
Por ltimo quisiera agradecer al rea de sistemas y accionamientos de la planta de
celulosa Arauco ubicada en Valdivia, donde me han enseado a comportarme como
un profesional y sobre las relaciones entre compaeros de trabajo. En otras palabras
mi primera experiencia laboral, muchas Gracias a todos, he aprendido mucho.
MUCHAS GRACIAS
ii
II.NDICE I.AGRADECIMIENTOS......................................................................................................................iII.NDICE.........................................................................................................................................iiIII.NDICEDETABLAS.....................................................................................................................ivIV.NDICEDEFIGURAS....................................................................................................................vV.SNTESIS....................................................................................................................................viiVI.ABSTRACT...............................................................................................................................viii1.INTRODUCCIN..........................................................................................................................11.1Objetivosgeneralesyespecficos........................................................................................21.1.1ObjetivosGenerales......................................................................................................21.1.2.ObjetivosEspecficos....................................................................................................2
2.PROBLEMA.................................................................................................................................32.1Problemticadegestindealarmas....................................................................................7
3.ANLISISYSELECCINDETECNOLOGAS................................................................................133.1Lenguajesdisponiblesdelladodelservidor......................................................................143.1.1Asp(ActiveServerPages)............................................................................................143.2.2Csp(C++ServerPages)................................................................................................143.2.3Coldfusion(Adobe).....................................................................................................143.2.4JavaEE.........................................................................................................................153.2.5Perl(CdigoAbierto)...................................................................................................153.2.6PHP..............................................................................................................................153.2.7Microsoft.Net.............................................................................................................15
3.2Lenguajesdisponiblesdelladodelcliente.........................................................................163.2.1VBScript.......................................................................................................................163.2.2AdobeFlex...................................................................................................................173.2.3JavaScript....................................................................................................................173.2.4JQuery.........................................................................................................................183.2.5MicrosoftSilverlight....................................................................................................193.2.6Html5...........................................................................................................................19
3.3LenguajesdisponiblesCliente+Servidor...........................................................................203.3.1GoogleWebToolkit....................................................................................................203.3.2Pyjamas.......................................................................................................................203.3.3Django.........................................................................................................................20
3.4BasesdeDatos...................................................................................................................213.4.1MicrosoftSQLServer..................................................................................................213.4.2Oracle..........................................................................................................................213.4.3Mysql...........................................................................................................................22
3.5Seleccin............................................................................................................................223.5.1BasedeDatos..............................................................................................................223.5.2Lenguajedeprogramacin.........................................................................................24
4.ARQUITECTURA........................................................................................................................25
iii
4.1ModeloVistaControlador.................................................................................................264.2Modelosdedatosusadosparadatawarehousing............................................................274.2.1Esquemaestrella.........................................................................................................274.2.2Esquemacopodenieve..............................................................................................28
5.DISEODELSISTEMA...............................................................................................................305.1Planificacin.......................................................................................................................305.1.1Metodologa....................................................................................................................305.1.2Estrategiadeimplementacin....................................................................................305.1.3Estrategiasdeprueba.................................................................................................31
5.2Anlisis...............................................................................................................................315.2.1Requisitos....................................................................................................................325.2.1.1RequisitosFuncionales.........................................................................................325.2.1.2Requisitosnofuncionales....................................................................................33
5.2.2CasosdeUso...............................................................................................................345.2.2.1Descripcindelosactoresdelsistema................................................................385.2.2.2Descripcindeloscasosdeusodelsistema........................................................39
5.2.3Anlisismodelodedatos............................................................................................425.3Diseo................................................................................................................................435.3.1Casosdeusoreales.....................................................................................................445.3.2DiagramasdeSecuencia.............................................................................................465.3.3DiagramadeClases.....................................................................................................475.3.4Modelodedatos.........................................................................................................495.3.5DiagramasdeActividad..............................................................................................505.3.6DiagramadeDespliegue.............................................................................................57
5.4Implementacin.................................................................................................................585.4.1Dificultadesdelaimplementacin.............................................................................585.4.2Consideracionestcnicas............................................................................................605.4.3Validacindecumplimientoderequisitos.................................................................60
6.ValidacindelSoftware...........................................................................................................617Anlisisdecostos......................................................................................................................638Documentacin.........................................................................................................................659.Conclusiones............................................................................................................................73REFERENCIAS................................................................................................................................75
iv
III. NDICE DE TABLAS
Tabla 2.1: Resumen duracin de los procesos. ................................................................ 10Tabla 3.1 (Comparacin de Bases de Datos) ................................................................... 23Tabla 5.1: Requisitos Funcionales ................................................................................... 32Tabla 5.2: Requisitos no funcionales ............................................................................... 33Tabla 5.3: Caso de Uso 1 Cargar Alarmas ....................................................................... 39Tabla 5.4: Caso de Uso 2 Generar informes mensuales................................................... 39Tabla 5.5: Caso de Uso 3 Seleccionar Alarmas ............................................................... 39Tabla 5.6: Caso de uso 4 Seleccionar Destinatarios ........................................................ 40Tabla 5.7: Caso de uso 5 Gestionar Alarmas ................................................................... 40Tabla 5.8: Caso de uso 6 Crear informe de gestiones ...................................................... 40Tabla 5.9: Caso de uso 7 crear informe de alarmas detallado .......................................... 40Tabla 5.10: Caso de uso 8 Filtrar alarmas por caractersticas seleccionadas ................... 40Tabla 5.11: Caso de uso extendido 1 - Agregar alarmas ................................................. 41Tabla 5.12: caso de uso extendido - Crear Informe ......................................................... 41Tabla 5.10: Descripcin de columnas de las alarmas. ..................................................... 42Tabla 5.11: Cargar alarmas al almacn de datos .......................................................... 44Tabla 5.11: Generar informes mensuales de alarmas ................................................... 45Tabla 5.12: Matriz de trazabilidad. .................................................................................. 60Tabla 6.1: Promedio de fallas anuales por rea de la celulosa. Fuente: Rodrigo
Sandoval, Jefe rea DCS, Celulosa Arauco, Planta Valdivia. ................................. 63Tabla 6.2: Fallas que han detenido la planta por ao. Fuente: Rodrigo Sandoval, Jefe
rea DCS, Celulosa Arauco, Planta Valdivia. ......................................................... 63Tabla 6.3: Perdidas en promedio por fallas en la planta. Fuente: Rodrigo Sandoval,
Jefe rea DCS, Celulosa Arauco, Planta Valdivia. .................................................. 64
v
IV. NDICE DE FIGURAS
Figura 2.1: Organigrama de Arauco................................................................................... 4Figura 2.2: Organigrama gerencia de finanzas de Arauco. ................................................ 5Figura 2.3: Organigrama rea informtica de Arauco. ...................................................... 6Figura 2.4: Sistema Delta V. .............................................................................................. 8Figura 2.5: Alarmas a utilizar en el sistema. ...................................................................... 8Figura 2.6: Procesos para crear informe manual de alarmas. ............................................ 9Figura 2.7: Detalle reas receptoras de informes de alarmas ........................................... 10Figura 2.8: Cadena de mando de las reas en la planta de celulosa. ................................ 11Figura 4.1: Arquitectura del sistema ................................................................................ 26Figura 4.2: Ejemplo esquema estrella. ............................................................................. 28Figura 4.3: Ejemplo de esquema Copo de nieve. ............................................................. 29Figura 5.2.1: Diagrama del proceso carga de alarmas. .................................................... 35Figura 5.2.2: Diagrama del proceso de creacin de informes. ......................................... 35Figura 5.2.3: Diagrama del proceso de configurar cuenta de correo. .............................. 35Figura 5.2.4: Diagrama del proceso de enviar por correo. ............................................... 36Figura 5.2.5: Diagrama del proceso de gestionar alarmas. .............................................. 36Figura 5.2.6: Diagrama del proceso de creacin de informes de alarmas detallado. ....... 37Figura 5.2.7: Diagrama del proceso de ingresar nuevo usuario. ...................................... 37Figura 5.2.8: Diagrama del proceso de seleccionar destinatarios de informes. ............... 37Figura 5.2.9: Diagrama del proceso de seleccionar filtros de alarma. ............................. 38Figura 5.2: Casos de uso general de la aplicacin de alarmas. ........................................ 38Figura 5.9: Generar reportes ejemplo............................................................................... 46Figura 5.10: Diagrama de secuencia del caso de uso agregar alarmas. ........................... 47Figura 5.11: Diagrama de clases de software Alarmas. ................................................... 48Figura 5.12: Modelo de datos para almacenar las alarmas. ............................................. 50Figura 5.3: Diagrama de actividad del proceso de Enviar por correo. Esta actividad
obtiene la cuenta de correo a utilizar y las claves correspondientes, luego se conecta al servidor Exchange y enva los correos generados con los informes. ...... 52
Figura 5.4: Diagrama de actividad del proceso de cargar alarmas al almacn de datos. Est actividad busca nuevas alarmas en la carpeta especificada, si encuentra, las carga al almacn de datos. ........................................................................................ 53
Figura 5.5: Diagrama de actividad del proceso Seleccionar destinatarios, solo se muestra la opcin de guardar a modo de ejemplo. La actividad mostrada en el diagrama permite agregar los destinatarios de correos a la base de datos, o modificar los existentes. ........................................................................................... 53
Figura 5.6: Diagrama de actividad del proceso que genera los informes mensuales (1 Ejemplo de todos los informes que se hacen). Este diagrama muestra la creacin
vi
de los informes, se ejecuta los procedimientos almacenados en la base de datos que filtran y entregan solamente los datos necesarios, para despus crear los informes en Excel. .................................................................................................... 54
Figura 5.7: Diagrama de actividad del proceso que gestiona alarmas. La actividad presentada muestra la forma en que se marcan como gestionadas las alarmas en el servidor, para de esta forma llevar un informe de que alarmas han sido gestionadas y cules no. ............................................................................................ 55
Figura 5.8: Diagrama de actividad del proceso que selecciona alarmas. La actividad muestra la forma en que el usuario puede modificar las alarmas a ser tomadas en cuenta en los informes mensuales, para poder crear informes de acuerdo a requerimientos especficos. ....................................................................................... 56
Figura 5.13: Diagrama de implementacin del sistema de alarmas. ................................ 57Figura 8.2: Ejemplo del Manual de usuario. .................................................................... 65Figura 8.3: Fotos manual de Administrador. ................................................................... 66Figura 8.3: Ejemplo del manual de instalacin de la aplicacin. ..................................... 67Figura 8.4: Ejemplo de la configuracin de Windows. .................................................... 68Figura 8.5: Foto del manual de instalacin de la aplicacin. ........................................... 69Figura 8.6: Ejemplo del manual de instalacin de la aplicacin. ..................................... 70Figura 8.7: Ejemplo para instalar la base de datos de la aplicacin. ................................ 71Figura 8.8: Ejemplo del manual. ...................................................................................... 72
vii
V. SNTESIS
En el presente documento se describe un problema en la Celulosa Arauco planta
Valdivia que afecta al rea de Sistemas de Control Distribuido, y se desarrolla paso a
paso una solucin informtica.
As pues se realiz una investigacin para comprender el mtodo de creacin de
reportes de mantencin en la empresa, a su vez se evalu el hardware disponible,
para de esta forma desarrollar una solucin acorde al mismo, tambin se tom en
cuenta el manejo informtico del personal.
A continuacin se presenta el estudio de tecnologas con las cuales se puede dar una
solucin al problema presentado anteriormente. Luego de esto se seleccion la mejor
opcin de acuerdo a las necesidades de la empresa.
Posteriormente se presenta el diseo planteado para la aplicacin propuesta de
generacin de reportes, se muestra claramente cada etapa, la arquitectura escogida y
tambin se muestran el anlisis y diseo de los procesos ms importantes.
Finalmente se realizaron comparaciones, en la medida de lo posible, de los informes
antiguos (generados manualmente) y los nuevos (generados de forma automtica),
validando la solucin.
viii
VI. ABSTRACT
This paper describes a problem in the Arauco pulp mill, located in Valdivia, affecting
the area of Distributed Control Systems, and developed step by step an IT solution.
Therefore research was undertaken to understand the method of building
maintenance reports on the company, in turn evaluated the available hardware, to
thereby develop a solution according to it, and also took into account staff
knowledge on computer.
Then is the study of technologies which can provide a solution to the problem
presented above. After that the best option is selected according to the needs of the
company.
Next, we present the proposed design for the report generation application, clearly
showing each stage, the chosen architecture and the analysis and design of the most
important processes.
Finally, comparisons were made, as far as possible from the old reports (manually
generated) and new (automatically generated), validating the solution.
1
1. INTRODUCCIN
En el presente documento se presentar el proyecto desarrollado para el rea de
Sistemas y Accionamientos de la planta de celulosa Arauco ubicada en Valdivia, que
permitir una creacin ms eficiente de los informes que se obtienen del sistema de
control distribuido1 que se utiliza actualmente en la planta y que es gestionado por
dicha rea.
Primeramente se realizar una breve descripcin la compaa, indicando el estado
actual del rea informtica en Arauco, posteriormente se indicaran los inconvenientes
que se presentaron y se describe el problema a resolver.
Ms adelante se expondr un anlisis a las tecnologas existentes que nos permitirn
implementar nuestro proyecto y se escoger una de ellas, tomando en cuenta los
reglamentos de la planta, los costos, los requerimientos y el tiempo que tomar
alcanzar el conocimiento adecuado en cada una de ellas para desarrollar nuestra
aplicacin.
Siguiendo a lo anterior, se describir el diseo de la aplicacin, desde la perspectiva
de la ingeniera de software, utilizando UML, para describir los procesos centrales e
importantes. Se comenzar con el anlisis, para seguir con el diseo, la
implementacin y la validacin.
Finalmente se expondrn las conclusiones de los resultados obtenidos en las
validaciones y en el uso del software.
1 Es un sistema de control aplicado a un sistema de fabricacin, proceso o cualquier tipo de sistema dinmico, en el que los elementos del tratamiento no son centrales en la localizacin, sino que se distribuyen a lo largo de todo el sistema con cada componente o sub-sistema controlado por uno o ms controladores. Todo el sistema de los controladores est conectado mediante redes de comunicacin y de monitorizacin.
2
1.1 Objetivos generales y especficos
1.1.1 Objetivos Generales.
Implementar una aplicacin web que facilite la administracin a distancia de los
reportes de alarmas de la Planta Valdivia de la empresa Celulosa Arauco y
Constitucin S.A.
1.1.2. Objetivos Especficos.
Describir la problemtica de la administracin de reportes de alarmas en la
empresa y su realidad tecnolgica.
Seleccionar las tecnologas adecuadas para el desarrollo de la aplicacin.
Disear la aplicacin.
Construir la aplicacin.
Validar la aplicacin con los usuarios finales, mediante mtricas de usabilidad y confiabilidad.
3
2. PROBLEMA
Arauco es una de las mayores empresas forestales de Amrica Latina en trminos de
superficie y rendimiento de sus plantaciones, fabricacin de celulosa kraft2 de
mercado y produccin de madera aserrada y paneles. Est organizada en cuatro reas
estratgicas de negocios: Forestal, Celulosa, Madera Aserrada y Paneles. [URL1]
En el rea de celulosa cuenta con las ms modernas plantas de Latinoamrica
[URL1].
De acuerdo al organigrama de direccin de Arauco que se muestra en la figura 2.1, la
gerencia de informtica se encuentra subordinada a la gerencia de finanzas. Figura
2.2.
2Es un tipo de papel basto y grueso de color marrn.
4
Figura 2.1: Organigrama de Arauco.
5
Figura 2.2: Organigrama gerencia de finanzas de Arauco.
Esta gerencia controla todo el proceso informtico de manera centralizada desde
Santiago.
En cada planta dispone de dos personas encargadas del rea administrativa, con
permisos para instalar aplicaciones, crear cuentas de correo, etc., pero no existe un
rea de desarrollo de software que permita solucionar los problemas con las
aplicaciones existentes o crear soluciones a los que se van presentando.
6
Los encargados de localidad pertenecen al rea de servicios de TI3, que a su vez
pertenece al rea de sub gerencia de operaciones de TI, se puede observar en la
figura 2.3 un diagrama descriptivo.
Figura 2.3: Organigrama rea informtica de Arauco.
3Recursos, procedimientos y tcnicas usadas en el procesamiento, almacenamiento y transmisin de informacin.
7
2.1 Problemtica de gestin de alarmas.
Los ingenieros que trabajan directamente en el proceso de produccin de la celulosa;
que en general son Qumicos, Electrnicos, Elctricos y Mecnicos, no tienen un
mayor dominio en el rea informtica, por lo tanto no existe mucho avance en el
desarrollo de las bases de datos. Esto se denota mayormente en que manejan mucha
informacin en planillas Excel, teniendo a personas dedicadas a trabajar con ellas. O
en el mejor de los casos existen aplicaciones de escritorio que estn conectadas a una
base de datos en Access en Red. Estas aplicaciones hay que reinstalarlas en todos los
equipos cada vez que hay un cambio en el servidor en el cual se aloja la base de
datos.
En nuestro caso en la planta ubicada en Valdivia de la empresa Celulosa Arauco y
Constitucin S.A. existe un sistema de control distribuido (DCS por sus siglas en
ingls) llamado DeltaV, que es un sistema de control aplicado, por lo general, a un
sistema de fabricacin, proceso o cualquier tipo de sistema dinmico, en el que los
elementos del tratamiento no son centrales en la localizacin (como el cerebro), sino
que se distribuyen a lo largo de todo el sistema con cada componente o sub-sistema
controlado por uno o ms controladores. Todo el sistema de los controladores est
conectado mediante redes de comunicacin y de monitorizacin (Figura 2.4). Es
importante en nuestro caso destacar que los controladores de este software
almacenan cualquier cambio que haya en los elementos del sistema. Estos cambios
pueden ser de informacin, ya sea por algn cambio en alguna variable por algn
operador, o de alarma, estos son los importantes para el sistema, ya que una gestin a
tiempo de las alarmas nos permite ahorrar un error en un sistema a futuro.
8
Figura 2.4: Sistema Delta V.
Las alarmas que van a ser tomadas en cuenta en el sistema (figura 2.5), son de
instrumentos y motores, de estos se utilizar la potencia y la corriente, ya sea baja o
alta. Estas alarmas son con las que se trabajar.
Figura 2.5: Alarmas a utilizar en el sistema.
Este sistema de alarmas emite diariamente un archivo y debido a la complejidad y
tamao de este, ya que es un archivo de texto de 300.000 lneas aproximadamente,
ste debe pasar por varios procesos antes de que pueda ser utilizado (Figura 2.6).
9
Figura 2.6: Procesos para crear informe manual de alarmas.
En el primer proceso, se debe tomar cada archivo e ingresarlo a una planilla Excel,
donde se ordenan los datos automticamente por las columnas respectivas que estn
incluidas en el archivo de texto plano. Este proceso toma aproximadamente 1 Hora.
En el segundo proceso se toma cada planilla creada en Excel y se deben almacenar
en una tabla en Access, cada da es una planilla y cada tabla es una planilla, por lo
que generalmente son 30 planillas. Este proceso toma generalmente 4 Horas.
En tercer proceso se filtran las tablas individualmente y se agregan los resultados del
filtro a una nica tabla en Access. Este proceso dura aproximadamente 1 hora y 30
minutos completo.
En el cuarto proceso se copian los datos de la tabla de Access donde se encuentran
los datos filtrados de todos los das a una planilla en Excel y se le aplican filtros para
crear informes por rea, las cuales se pueden observar en la figura 2.7. Este proceso
toma aproximadamente 15 minutos.
10
Figura 2.7: Detalle reas receptoras de informes de alarmas
Finalmente se copian los datos en planillas distintas para cada rea y luego se envan
por correo a cada rea y se espera por respuesta de gestin. Este proceso dura
aproximadamente 1 hora. En la tabla 2.1 se muestra un resumen de la duracin del
proceso.
Tabla 2.1: Resumen duracin de los procesos.
Proceso 1Proceso 2Proceso 3Proceso 4Proceso 5Proceso TotalTiempoHoras 1 4 1,5 0,25 1 7,75Debido a la cantidad de datos que deben ser procesados por cada da, no se pueden
realizar informes por tamaos mayores a 15 das, ya que el software utilizado para tal
gestin no est diseado para manejar tal cantidad de informacin. Luego de
realizado este anlisis, se debe enviar un correo a cada jefe, supervisor y encargado
de rea (ver figura 2.8), para que vea qu acciones realizar respecto de cada alarma,
enviando ste una respuesta por correo de las alarmas escogidas. Las posibles
respuestas o gestiones a realizar son 2, primero se puede notificar de una mala
configuracin de los lmites del sensor. En segundo lugar, se revisa el equipo y
soluciona el problema que gener la alarma notificando del error y la solucin.
11
Figura 2.8: Cadena de mando de las reas en la planta de celulosa.
El encargado del sistema de gestin, es el supervisor del DCS, este debe tomarse el
tiempo de revisar las alarmas que fueron gestionadas por los jefes de rea, esto se
realiza en el informe que debe crearse en la siguiente quincena.
Se desea automatizar este proceso completo, mediante un sistema web que permita la
gestin automtica por parte del supervisor de rea de sistemas y accionamientos.
Adems permitir imprimir o enviar por correo electrnico informes mensuales de
las diferentes alarmas, las cuales podrn ser escogidas.
La solucin planteada, adems de la automatizacin del proceso de generacin de
informes, producir un manejo eficaz y meticuloso de la informacin del sistema que
se plasmar en informes con mayor cantidad de alarmas, las cuales anteriormente se
perdan por errores humanos y/o falta de capacidad del software utilizado.
Finalmente se permitir mantener un registro de respuesta por parte del rea a los
informes de alarmas respectivos. Lo que los har responsables por las alarmas no
12
tomadas en cuenta, generando de esta forma un cambio desde la mantencin
reactiva4 a una predictiva5.
4Dentro de las operaciones de mantenimiento, se denomina mantenimiento correctivo, a aquel que corrige los defectos observados en los equipamientos o instalaciones, es la forma ms bsica de mantenimiento y consiste en localizar averas o defectos y corregirlos o repararlos. 5El mantenimiento predictivo que est basado en la determinacin del estado de la mquina en operacin. El concepto se basa en que las mquinas darn un tipo de aviso antes de que fallen y este mantenimiento trata de percibir los sntomas para despus tomar acciones. Se trata de realizar ensayos no destructivos, como pueden ser anlisis de aceite, anlisis de desgaste de partculas, medida de vibraciones, medicin de temperaturas, termografas, etc. El mantenimiento predictivo permite que se tomen decisiones antes de que ocurra el fallo: cambiar o reparar la mquina en una parada cercana, detectar cambios anormales en las condiciones del equipo y subsanarlos, etc.
13
3. ANLISIS Y SELECCIN DE TECNOLOGAS
En la actualidad, con el avance que se ha vivido en el desarrollo de aplicaciones web,
existen muchas posibilidades y lenguajes diferentes para disear y crear, pero para un
correcto funcionamiento del software en su conjunto, se deben escoger tecnologas
adecuadas al contexto en el cual se est trabajando. Se deben tomar en cuenta
variables como privilegios o permisos de cada usuario, el tiempo de espera de
cualquier peticin al rea de informtica (ya sea de permisos o de licencias),
hardware disponible, conexiones disponibles, cantidad de usuarios, costos, etc.
La eleccin del lenguaje de programacin que se utilizar en la interfaz grfica va a
afectar el aspecto visual del software y sus debilidades se convertirn en las
debilidades y sus fortalezas tambin sern de la aplicacin.
Por otra parte teniendo en cuenta los requerimientos de la aplicacin a desarrollar, se
debe escoger una base de datos con todas las capacidades necesarias y que permita
una limpia integracin con los actuales sistemas de la planta.
Para poder realizar esta seleccin de manera adecuada se debe tener en cuenta que
solo se utilizar en la intranet de la empresa, en la planta de Valdivia y en su mximo
uso paralelo lo utilizarn 18 personas, se trabaja con un volumen aproximado de
300.000 registros diarios y un tamao de 1 Gb mensual que debe aadirse a la base
de datos. Existe tambin le necesidad de poder realizar filtros sobre los datos, de
manera rpida, precisa y simple, por lo que se espera que sobre el sistema de base de
datos que se escoja existan mtodos para el manejo eficiente de millones de datos.
Dependiendo de la tecnologa a utilizar requeriremos un lenguaje de comunicacin
entre la interfaz y la base de datos, en este caso se debe realizar un anlisis de
14
seguridad, simplicidad, costos y permisos requeridos para su uso, para escoger la
mejor opcin.
A continuacin, se presenta un pequeo estudio sobre las tecnologas posibles para el
desarrollo de nuestra aplicacin.
3.1 Lenguajes disponibles del lado del servidor
3.1.1 Asp (Active Server Pages)
Tecnologa creada por Microsoft para pginas web generadas dinmicamente, intenta
ser solucin para un modelo de programacin rpida lo que le da ventajas tales como
utilizar elementos ActiveX y elementos del lado del servidor ya creados; Pero a su
vez muchas limitaciones como que puede ser utilizado solamente junto a Internet
Information Server. [Mur10]
3.2.2 Csp (C++ Server Pages)
Permite la programacin de aplicaciones web, a programadores de C++. Es un motor
web para desarrollar avanzadas aplicaciones web que mezcla lenguaje de marcado6 y
Scripts de C++ [Mic11].
3.2.3 Coldfusion (Adobe)
Es un servidor de aplicaciones y un lenguaje de programacin usado para desarrollar
aplicaciones de Internet, generalmente sitios web generados dinmicamente. No es
un lenguaje de bases de datos, pero interacta de manera simple con estas (Sybase,
6 Es una forma de codificar un documento que, junto con el texto, incorpora etiquetas o marcas que
contienen informacin adicional acerca de la estructura del texto o su presentacin.
15
Oracle, MySQL, SQL Server, o Access). Usando SQL estndar, las pginas y
aplicaciones web pueden fcilmente recuperar, guardar, preparar y presentar
informacin dinmicamente. [ASI09]
3.2.4 Java EE
Es una plataforma ampliamente usada para programar servidores y lenguaje Java,
esta difiere de la versin estndar de Java en que agrega varias libreras que agregan
funcionalidad para ejecutar software de Java basado en componentes modulares que
corren en servidores de aplicaciones. [Jav11]
3.2.5 Perl (Cdigo Abierto)
Perl es un lenguaje imperativo, con variables, expresiones, asignaciones, bloques de
cdigo delimitados por llaves, estructuras de control y subrutinas. Perl est
ampliamente favorecido para las aplicaciones de bases de datos. Sus facilidades de
manejo de texto son buenas para generar consultas SQL; arrays, hashes y la gestin
de memoria automtica hace fcil recoger y procesar los datos devueltos. [DBI]
3.2.6 PHP
Es un lenguaje de programacin interpretado, diseado originalmente para la
creacin de pginas web dinmicas y puede ser incrustado en cdigo HTML. Se usa
principalmente para la interpretacin del lado del servidor (server-side scripting),
destaca la capacidad de conexin con la mayora de los motores de base de datos que
se utilizan en la actualidad. [PHP]
3.2.7 Microsoft .Net
16
Es un framework7 de Microsoft que hace un nfasis en la transparencia de redes, con
independencia de plataforma de hardware y que permita un rpido desarrollo de
aplicaciones.
.NET podra considerarse una respuesta de Microsoft al creciente mercado de los
negocios en entornos Web, como competencia a la plataforma Java de Oracle
Corporation y a los diversos framework de desarrollo web basados en PHP. Su
propuesta es ofrecer una manera rpida y econmica, a la vez que segura y robusta,
de desarrollar aplicaciones o como la misma plataforma las denomina, soluciones
permitiendo una integracin ms rpida y gil entre empresas y un acceso ms
simple y universal a todo tipo de informacin desde cualquier tipo de dispositivo.
[Net11]
3.2 Lenguajes disponibles del lado del cliente
3.2.1 VBScript
Es un lenguaje interpretado por el Windows Scripting Host de Microsoft. Su sintaxis
refleja su origen como variacin del lenguaje de programacin Visual Basic, y por lo
tanto, se pueden observar categoras similares: los procedimientos, las estructuras de
control, constantes, variables, la interaccin del usuario, de manejo conjunto,
funciones de fecha y hora, manejo de errores, funciones matemticas, objetos,
expresiones regulares, la manipulacin de cadenas, y as sucesivamente. Un
"procedimiento" es la construccin principal de VBScript para separar el cdigo en
mdulos ms pequeos. VBScript distingue entre una funcin, que puede devolver
7 Es un conjunto estandarizado de conceptos, prcticas y criterios para enfocar un tipo de problemtica
particular, que sirve como referencia para enfrentar y resolver nuevos problemas de ndole similar.
17
un resultado en una sentencia de asignacin, y una subrutina, que no puede. Los
parmetros son de posicin, y se pueden pasar por valor o por referencia. Las
estructuras de control incluyen el proceso iterativo de costumbre y el bucle
condicional Do, las declaraciones If-Then-Else y Case, con algunas variantes ms
complejas, tales como Else If y estructuras de control anidadas. [Mic12]
3.2.2 Adobe Flex
Flex es un marco de trabajo gratuito de cdigo abierto y altamente productivo para
crear aplicaciones web, para ordenadores de escritorio y para dispositivos mviles.
Flex permite crear aplicaciones web y para dispositivos mviles que comparten una
base de cdigo comn, lo que reduce el tiempo y el coste de creacin de aplicaciones
y el mantenimiento a largo plazo. Flex ofrece un lenguaje moderno basado en
estndares y un modelo de programacin que admite los patrones de diseo
habituales. MXML8, un lenguaje declarativo basado en XML, se utiliza para
describir el diseo y el comportamiento de la interfaz de usuario, as como el
lenguaje de programacin ActionScript 3.09 orientado a objetos se utiliza para crear
la lgica de clientes. Flex tambin incluye una sofisticada biblioteca de componentes
con ms de 100 componentes de interfaz de usuario extensibles y de eficacia probada
tanto para aplicaciones web como para dispositivos mviles, as como un depurador
de aplicaciones de Flex. [Igf09]
3.2.3 JavaScript
8 Lenguaje que describe interfaces de usuario, crea modelos de datos y tiene acceso a los recursos del
servidor.9 Es el lenguaje de programacin de la Plataforma Adobe Flash. Originalmente desarrollado como una
forma para que los desarrolladores programen de forma ms interactiva.
18
Es un lenguaje de programacin interpretado, dialecto del estndar ECMAScript10.
Se define como orientado a objetos, basado en prototipos, imperativo, dbilmente
tipado y dinmico.
Se utiliza principalmente en su forma del lado del cliente (client-side), implementado
como parte de un navegador web permitiendo mejoras en la interfaz de usuario y
pginas web dinmicas.
Todos los navegadores modernos interpretan el cdigo JavaScript integrado en las
pginas web. Para interactuar con una pgina web se provee al lenguaje JavaScript
de una implementacin del Document Object Model (DOM).11 [JSc11]
3.2.4 JQuery
Es una biblioteca de JavaScript que permite simplificar la manera de interactuar con
los documentos HTML, manipular el rbol DOM, manejar eventos, desarrollar
animaciones y agregar interaccin con la tcnica AJAX a pginas web.
JQuery, al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en
JavaScript que de otra manera requeriran de mucho ms cdigo, es decir, con las
funciones propias de esta biblioteca se logran grandes resultados en menos tiempo y
espacio. [Jqu10] 10 Es una especificacin de lenguaje de programacin publicada por ECMA International. El
desarrollo empez en 1996 y estuvo basado en el popular lenguaje JavaScript propuesto como
estndar por Netscape Communications Corporation. Actualmente est aceptado como el estndar ISO
16262.11 Es esencialmente una interfaz de programacin de aplicaciones (API) que proporciona un conjunto
estndar de objetos para representar documentos HTML y XML, un modelo estndar sobre cmo
pueden combinarse dichos objetos, y una interfaz estndar para acceder a ellos y manipularlos.
19
3.2.5 Microsoft Silverlight
Es una estructura para aplicaciones web que agrega nuevas funciones multimedia
como la reproduccin de vdeos, grficos vectoriales, animaciones e interactividad,
en forma similar a lo que hace Adobe Flash. [Sil]
3.2.6 Html5
Es la quinta revisin importante del lenguaje bsico de la World Wide Web, HTML.
Todava se encuentra en modo experimental, lo cual indica la misma W3C; aunque
ya es usado por mltiples desarrolladores web por sus avances, mejoras y ventajas.
HTML5 establece una serie de nuevos elementos y atributos que reflejan el uso
tpico de los sitios web modernos. [HTM11]
Novedades:
Incorpora etiquetas (canvas 2D y 3D, audio, video) con codecs para mostrar los contenidos multimedia. Actualmente hay una lucha entre imponer codecs
libres (WebM + VP8) o privativos (H.264/MPEG-4 AVC).
Etiquetas para manejar grandes conjuntos de datos: Datagrid, Details, Men y Command. Permiten generar tablas dinmicas que pueden filtrar, ordenar y
ocultar contenido en cliente.
Mejoras en los formularios. Nuevos tipos de datos (email, number, url, datetime) y facilidades para validar el contenido sin JavaScript.
Visores: MathML (frmulas matemticas) y SVG (grficos vectoriales). En general se deja abierto a poder interpretar otros lenguajes XML.
20
Drag & Drop. Nueva funcionalidad para arrastrar objetos como imgenes.
3.3 Lenguajes disponibles Cliente + Servidor
3.3.1 Google Web Toolkit
Google Web Toolkit (GWT) permite crear aplicaciones AJAX en el lenguaje de
programacin Java que son compiladas posteriormente por GWT en cdigo
JavaScript ejecutable optimizado que funciona automticamente en los principales
navegadores.
Caractersticas:
Edita cdigo Java y visualiza los cambios inmediatamente sin tener que volver a compilarlo
Recorre todo el cdigo AJAX utilizable con el depurador de Java
Compila e implementa cdigo JavaScript optimizado para varios navegadores. [Goo10]
3.3.2 Pyjamas
Es una herramienta y framework para desarrollar aplicaciones Ajax en Phyton,
contiene un compilador de Python a JavaScript. Su funcin es idntica a la que
desarrolla Google Web Toolkit, la diferencia es que es de Python a JavaScript. [Pyj]
3.3.3 Django
Es un framework Web de alto nivel para desarrollar aplicaciones en Python que
promueve un rpido desarrollo, diseo limpio y pragmtico. [Dja]
21
3.4 Bases de Datos
3.4.1 Microsoft SQL Server
Es un sistema para la gestin de bases de datos producido por Microsoft basado en el
modelo relacional.
Caractersticas:
Soporte de transacciones.
Escalabilidad, estabilidad y seguridad.
Soporta procedimientos almacenados.
Permite trabajar en modo cliente-servidor, donde la informacin y datos se alojan en el servidor y los terminales o clientes de la red slo acceden a la
informacin. [IGP11]
3.4.2 Oracle
Es un sistema de gestin de base de datos objeto-relacional desarrollado por Oracle
Corporation. Se considera a Oracle como uno de los sistemas de bases de datos ms
completos, destacando:
soporte de transacciones
estabilidad
escalabilidad
concurrencia
Soporte multiplataforma.[ODB]
22
3.4.3 Mysql
Es un sistema de gestin de bases de datos relacional, multihilo y multiusuario.
Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta
licencia, pero para aquellas empresas que quieran incorporarlo en productos
privativos deben comprar a la empresa una licencia especfica que les permita este
uso.
Caractersticas:
Soporte a multiplataforma.
Procedimientos almacenados
Disparadores (triggers).
Vistas actualizables.
Soporte a VARCHAR
Soporte para SSL.
Sub-SELECTs (o SELECTs anidados).
Soporte completo para Unicode. [MyS]
3.5 Seleccin
3.5.1 Base de Datos
23
Actualmente en el rea de sistemas y accionamientos se trabaja con Delta V. Este
sistema utiliza una base de datos MS SQL Server 2005, por lo que los archivos
diarios con toda la informacin de las alarmas son backup del sistema original.
Por otro lado en la tabla 3.1 se puede ver que las diferencias de los sistemas de bases
de datos, para el desarrollo del proyecto actual, son despreciables; por lo que se
tomar la decisin en base al costo cero que tiene MS SQL en la planta, esto debido a
la existencia de licencias por parte del rea de informtica. Cabe mencionar la
interesante posibilidad de utilizar inteligencia de negocios para realizar consultas a
una gran cantidad de datos, la gran cantidad de informacin que hay en la red para su
aprendizaje, y el conocimiento previo que se tiene sobre este sistema de
administracin de bases de datos. Se destaca el convenio que existe entre Arauco y
Microsoft, lo que permite la instalacin sin permiso desde Santiago, Basta con el
permiso del jefe de informtica de la planta.
El lenguaje de consulta de Microsoft SQL Server es Transact SQL, el cual es una
extensin a SQL. Esta extensin aade programacin procedural, variables locales,
varias funciones de soporte para procesamiento de strings, procesamiento de fechas,
matemticas, etc. Por todas estas razones, se utilizar Microsoft SQL Server 2008
R2.
Tabla 3.1 (Comparacin de Bases de Datos)
Caractersticas Oracle MySQL MS SQL
Windows Si Si Si
Linux Si Si No
Max Tamao BD Ilimitado Ilimitado 524 Tb
Max Tamao Tabla 4 Gb 256 Tb 524 Tb
Licencia Propietario Propietario o GPL Propietario
Interfaz API & GUI & SQL GUI & SQL
24
SQL
Interseccin Si No Si
Excepcin Si No Si
Merge Joins Si No Si
Expresiones de tabla comn Si No Si
Tipos de variables booleanas No Si Si
3.5.2 Lenguaje de programacin
Para la seleccin del lenguaje de programacin, los factores ms importantes a tomar
en cuenta son [REQ11]:
La plataforma de destino: Este factor es el ms importante, debido a que es donde se ejecutar la solucin implementada. Para el caso de nuestra
aplicacin web, esta debe verse igual en todos los navegadores, sin importar
el sistema operativo en el cual se despliegue.
La elasticidad del lenguaje: Es la facilidad con que se le agregan nuevas caractersticas al programa existente, qu capacidades vienen incluidas en el
lenguaje, etc.
El tiempo de produccin: Es el tiempo que va a tomar al desarrollador en implementar la solucin y que est funcione como debe. Por lo tanto se debe
programar eficientemente y tomar en cuenta factores como los lenguajes que
conoce el desarrollador, el tiempo que le tomar aprenderlo. etc.
El rendimiento: El rendimiento que se obtiene de una aplicacin depende en gran medida del sistema en el cual se implementa, por lo tanto se debe tomar
en cuenta el Hardware del servidor donde ser implementado.
25
El soporte de la comunidad: Un lenguaje de programacin es ms fcil de aprender y toma menos tiempo solucionar problemas que se pueden presentar
si tiene una comunidad grande que pueda brindar ayuda, y lo ms importante,
que esta comunidad pueda crear libreras adicionales que ayuden a crecer en
funcionalidades al lenguaje.
En nuestro caso particular tenemos que:
Plataforma de destino: Microsoft Windows 7 Enterprise, con Microsoft Internet Explorer 9, esto debido a que todos los equipos de la planta tienen la
misma plataforma como estndar, sin posibilidad de utilizar otra.
Tiempo disponible: Se disponen de 6 meses para disear, desarrollar e implementar una solucin.
Rendimiento: El servidor a utilizar es un Dell PowerEdge R710, sus caractersticas son:
o 2 Procesadores Intel Xeon de 2.4 GHz, de 4 ncleos cada uno. 8 Ncleos virtuales.
o 4 Gb de memoria RAM o Windows Server 2008 64 Bits o 4 Tarjetas de Red o 6 Discos SCSI de 146 Gb cada uno, utilizando RAID 10. Con un
disco Virtual de 408.37 Gb.
En base a los factores anteriormente descritos, se decidi utilizar Microsoft .Net, ya
que es de fcil aprendizaje y rpida creacin de interfaces grficas, lo que nos deja
ms tiempo para trabajar en el funcionamiento del sitio. Disponemos tambin de una
gran comunidad de apoyo, adems de libreras tiles para nuestras necesidades.
Finalmente es de fcil interaccin con JavaScript, lo que nos permitir aadir
funcionalidad extra a nuestra aplicacin.
26
$548,7(&785$
En el presente capitulo, se presentar la arquitectura definida para la implementacin
de nuestra solucin.
4.1 Modelo Vista-Controlador
Como se puede observar en la figura 4.1 se utilizar el patrn de diseo Modelo
Vista Controlador.
Figura 4.1: Arquitectura del sistema
La segmentacin que este esquema de diseo define, nos permitir dividir el sistema
en tres unidades claras, trabajando en cada una por separado.
Las tres unidades son [SOM05]:
Modelo: Esta es la representacin especfica de la informacin con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y
su controlador facilitando las presentaciones visuales complejas. El sistema
tambin puede operar con ms datos no relativos a la presentacin, haciendo
uso integrado de otras lgicas de negocio y de datos afines con el sistema
modelado.
Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
27
Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.
La vista va a ser implementada con ASP.Net, este lenguaje nos permite crear la
estructura de la pgina sin problemas. En otras palabras se utilizar para disear la
interfaz grfica.
El modelo va a ser creado utilizando T-SQL que es lenguaje SQL extendido utilizado
por Microsoft SQL Server 2008 R2.
El controlador va ser implementado manejando VB.Net para las funciones de la
pgina que acceden al servidor y JavaScript para interactuar con el usuario.
El ciclo del modelo MVC (Modelo Vista Controlador) es:
EL usuario interacta con la vista. EL controlador recibe la solicitud a travs de la vista. El controlador accede al modelo y solicita la informacin necesaria. El modelo entrega los datos solicitados al controlador. El controlador entrega los datos solicitados a la vista para que los despliegue
al usuario.
La vista espera nuevas instrucciones del usuario.
4.2 Modelos de datos usados para data warehousing 4.2.1 Esquema estrella
Es un modelo de datos que tiene una tabla de hechos que contiene los datos para el
anlisis, rodeada de las tablas de dimensiones. Este aspecto, de tabla de hechos (o
central) ms grande rodeada de radios o tablas ms pequeas es lo que asemeja a una
estrella, dndole nombre a este tipo de construcciones (Figura 4.2).
Las tablas de dimensiones tendrn siempre una clave primaria simple, mientras que
en la tabla de hechos, la clave principal estar compuesta por las claves principales
de las tablas dimensionales.
28
Figura 4.2: Ejemplo esquema estrella.
4.2.2 Esquema copo de nieve
Es una estructura algo ms compleja que el esquema en estrella. Se da cuando alguna
de las dimensiones se implementa con ms de una tabla de datos. La finalidad
es normalizar las tablas y as reducir el espacio de almacenamiento al eliminar la
redundancia de datos; pero tiene la contrapartida de generar peores rendimientos al
tener que crear ms tablas de dimensiones y ms relaciones entre las tablas (Figura
4.3).
29
Figura 4.3: Ejemplo de esquema Copo de nieve.
30
5. DISEO DEL SISTEMA
En el presente captulo se detallarn los pasos realizados para el desarrollo del
software. Las etapas de planificacin, anlisis, diseo, implementacin y verificacin
se realizaron para cada incremento de la aplicacin debido a la metodologa utilizada
para el desarrollo, pero se describir de manera secuencial para una mejor
comprensin.
5.1 Planificacin
Se detallarn los procesos realizados al comienzo del desarrollo de la aplicacin. El
ciclo de vida escogido, las motivaciones y los diferentes planteamientos presentados
durante el avance.
5.1.1 Metodologa
Para crear la aplicacin deseada, se utiliz un modelo iterativo e incremental, esto
debido a que al final de cada incremento se entrega un producto completamente
operacional y con una constante retroalimentacin del cliente. De esta forma es el
mismo cliente el que incluye o desecha elementos al final de cada incremento a fin
de que el software se adapte mejor a sus necesidades reales. El proceso se repite
hasta que se elabore el producto completo.
Para el ciclo de vida se utiliz el desarrollo incremental, de esta forma se genera
software operativo de forma rpida y en etapas tempranas, con correccin de errores
de manera cmoda y expedita por iteracin. Esto adems del hecho de que cada
iteracin no se superpone con otras y todos los requisitos de la aplicacin han sido
definidos al comienzo del proyecto.
5.1.2 Estrategia de implementacin
En el proceso de implementacin, hay que tener en cuenta los siguientes factores:
Se est realizando en la planta una transicin del software de control de alarmas Delta V de la versin 7.1 (con archivos de salida en texto plano) a las
31
10.1 (con archivos de salida en SQL Server). Esto va a implicar un cambio
completo de la forma de adjuntar cada archivo a nuestro almacn de datos.
Es importante el desarrollo de la aplicacin web dentro de la planta para tener reuniones peridicas con el cliente, sin quitarle mucho tiempo. De esta forma
se recibe retroalimentacin diaria, lo que da como resultado la aplicacin
deseada por el cliente.
En cuanto al funcionamiento de nuestra aplicacin:
El producto ser aceptado y se dar por finalizado cuando cumpla los requisitos acordados por ambas partes, cliente y desarrollador.
Debido a la naturaleza del proyecto, se podrn agregar funcionalidades a medida que el cliente lo vaya requiriendo. Estas funcionalidades debern
ser agregadas en posteriores desarrollos.
5.1.3 Estrategias de prueba
O considerar:
Se realizarn pruebas de cada iteracin, verificando su funcionamiento antes de proseguir con la siguiente.
Se compararn resultados obtenidos del software, con resultados existentes si es que los hubieran.
Finalmente:
Se realizar una prueba final donde se demuestre el funcionamiento correcto de la aplicacin, cumpliendo a cabalidad todos los puntos pactados con el
cliente.
5.2 Anlisis
En esta etapa del documento se describirn los requerimientos del software y los
casos de uso centrales de la aplicacin.
32
5.2.1 Requisitos
A continuacin de detallarn los requerimientos de la aplicacin, tanto funcionales
como no funcionales.
5.2.1.1 Requisitos Funcionales
Los requisitos funcionales del sistema se muestran en la tabla 4.1.
Tabla 5.1: Requisitos Funcionales
RF-1 Agregar Alarmas
Descripcin El sistema deber cargar archivos que contienen informacin sobre las
Alarmas generadas en la planta, y desplegar los ltimos archivos
aadidos
Comentarios Los archivos son generados por SQL Server 2005, en formato MDF
RF-2 Generar Informes de alarmas
Descripcin El sistema deber generar informes de las alarmas seleccionadas cuya
frecuencia sea mayor a 1000 por da y enviarlo por correo a quien se
indique.
Comentarios Estos informes deben entregarse en formato xlsx, mensualmente, con
cada da indicando la cantidad de alarmas.
RF-3 Escoger las alarmas que se tomarn en cuenta en el informe
Descripcin El sistema debe dar la posibilidad de escoger las alarmas a ser tomadas
en cuenta en los informes mensuales
RF-4 Gestionar Alarmas
Descripcin El sistema debe poder marcar si una alarma del informe ha sido
gestionada o no, por la respectiva rea
33
RF-5 Crear informe de gestiones
Descripcin El sistema debe crear un informe mensual sobre las alarmas
gestionadas versus la no gestionadas
RF-6 Seleccionar direcciones de correo
Descripcin El sistema debe permitir escribir las direcciones a las cuales enviara
los informes de gestin mensuales, modificarlas o eliminarlas.
RF-7 Crear informe de alarmas detallado
Descripcin El sistema deber permitir crear informe de Alarmas diarios, con todas
las alarmas por rea
RF-8 Filtrar Alarmas por caractersticas seleccionadas
Descripcin El sistema deber permitir crear informes con filtros sobre las alarmas
seleccionadas por el usuario, por la cantidad de tiempo deseado por el
usuario.
Comentarios Estos filtros debern ser lo ms dinmico posible, permitiendo escoger
entre todos los datos posibles y en cortos periodos de tiempo
5.2.1.2 Requisitos no funcionales
Los requisitos no funcionales se ilustran en la tabla 5.2.
Tabla 5.2: Requisitos no funcionales
RNF-1 Aplicacin Web
Descripcin El sistema deber poder ejecutarse en cualquier navegador Web, desde
cualquier lugar de la planta
RNF-2 Recursos libre en Cliente
34
Descripcin El sistema debe ocupar lo menos posible el PC del cliente, todo debe
efectuarse en el servidor.
RNF-3 Usar productos Microsoft
Descripcin El sistema debe ser desarrollado utilizando productos Microsoft donde
sea posible debido a compatibilidad con rea tcnica informtica de la
planta.
5.2.2 Casos de Uso
En la figura 5.1, se presenta un diagrama del proceso de gestin de alarmas y se
puede ver como interacta cada actor con el sistema y la relacin que existe entre los
procesos.
En el software desarrollado existen 2 procesos importantes, estos se analizarn con
ms detalle.
35
Figura 5.2.1: Diagrama del proceso carga de alarmas.12
Figura 5.2.2: Diagrama del proceso de creacin de informes.
Figura 5.2.3: Diagrama del proceso de configurar cuenta de correo.
12 Elaboracin propia utilizando el software biz agi.
36
Figura 5.2.4: Diagrama del proceso de enviar por correo.
Figura 5.2.5: Diagrama del proceso de gestionar alarmas.
37
Figura 5.2.6: Diagrama del proceso de creacin de informes de alarmas detallado.
Figura 5.2.7: Diagrama del proceso de ingresar nuevo usuario.
Figura 5.2.8: Diagrama del proceso de seleccionar destinatarios de informes.
38
Figura 5.2.9: Diagrama del proceso de seleccionar filtros de alarma.
De los diagramas de procesos mostrados en las figuras anteriores, se desprende el
diagrama de casos de uso mostrado en la Figura 5.2.
Figura 5.2: Casos de uso general de la aplicacin de alarmas.13
5.2.2.1 Descripcin de los actores del sistema
13Elaboracin propia utilizando Enterprise Architect.
39
Admin: El administrador o administradores debern poseer conocimientos
avanzados sobre el sistema de control distribuido Delta V, sobre los informes a crear
y de las fechas que se utilizarn para crearlos. Adems de poseer conocimientos
sobre los diferentes filtros aplicables al sistema y los diferentes informes que se
pueden crear.
5.2.2.2 Descripcin de los casos de uso del sistema
Se describen a continuacin los casos de uso del sistema.
Tabla 5.3: Caso de Uso 1 Cargar Alarmas
Caso de Uso 1
Caso de Uso: Carga de alarmas al almacn de datos
Actores: Administrador
Tipo: Primario Descripcin: Este caso de uso comienza cuando se desea generar el informe mensual. El
administrador copia las alarmas del mes en el servidor y las carga en el almacn de datos.
Tabla 5.4: Caso de Uso 2 Generar informes mensuales.
Caso de Uso 2
Caso de uso: Generar Informes Mensuales
Actores: Administrador
Tipo: Primario Descripcin: Este caso de uso comienza cuando se desea generar los informes de alarmas
mensuales y enviarlos por correo. El administrador selecciona el mes y realiza los informes.
Tabla 5.5: Caso de Uso 3 Seleccionar Alarmas
Caso de Uso 3
Caso de uso: Seleccionar Alarmas
Actores: Administrador
Tipo: Primario Descripcin: Comienza cuando el Administrador desea seleccionar que alarmas se tomaran
en cuenta al generar el informe.
40
Tabla 5.6: Caso de uso 4 Seleccionar Destinatarios
Caso de Uso 4
Caso de uso: Seleccionar destinatarios
Actores: Administrador
Tipo: Primario Descripcin: Comienza cuando el administrador desea seleccionar los destinatarios de los
distintos informes.
Tabla 5.7: Caso de uso 5 Gestionar Alarmas
Caso de Uso 5
Caso de uso: Gestionar Alarmas
Actores: Administrador
Tipo: Primario Descripcin: Comienza cuando el administrador desea marcar las alarmas que fueron
gestionadas por las distintas reas
Tabla 5.8: Caso de uso 6 Crear informe de gestiones
Caso de Uso 6
Caso de uso: Crear Informe de gestiones
Actores: Administrador
Tipo: Primario Descripcin: Comienza cuando el administrador desea obtener un informe de las alarmas que
fueron gestionadas y las que no.
Tabla 5.9: Caso de uso 7 crear informe de alarmas detallado
Caso de Uso 7
Caso de uso: Crear informe de alarmas detallado
Actores: Administrador
Tipo: Primario Descripcin: Comienza cuando el administrador desea obtener un informe con todas las
alarmas de 1 da sobre un rea en particular.
Tabla 5.10: Caso de uso 8 Filtrar alarmas por caractersticas seleccionadas
Caso de Uso 8
Caso de uso: Filtrar alarmas por caractersticas seleccionadas
41
Actores: Administrador
Tipo: Primario Descripcin: Comienza cuando el administrador desea obtener un informe con un filtro en
particular.
Tabla 5.11: Caso de uso extendido 1 - Agregar alarmas
Caso de Uso extendido 1
Caso de Uso: Carga de alarmas al almacn de datos
Actores: Administrador
Propsito: Almacenar alarmas en el almacn de datos Ref. Cruzada: [RF1]
Precondiciones: El sistema debe estar activo Las alarmas deben estar copiadas en el servidor
Resumen: El administrador carga las alarmas al sistema.
Curso Normal de Eventos
Acciones Actor: Respuesta Sistema:
1. Comienza cuando el Administrador desea generar un reporte mensual con las alarmas mayores a 1000
2. El sistema despliega la opcin de cargar alarmas nuevas al sistema.
3. El administrador presiona el botn 4. Empieza el proceso de cargar nuevas alarmas al almacn de datos.
5. El Administrador recibe confirmacin de 100% de las alarmas disponibles cargadas
Curso Alternativo 4. El sistema no encuentra alarmas nuevas disponibles e informa la situacin.
Tabla 5.12: Caso de uso extendido - Crear Informe
Caso de Uso extendido 2
Caso de Uso: Generar informes mensuales
Actores: Administrador
Propsito: Generar informe mensual que ser enviado por correo
Ref. Cruzada: [RF1]; [CU1]; [CU3]; [CU4]14
Precondiciones: El sistema debe estar activo
Las alarmas del mes seleccionado deben estar ingresadas en el almacn de datos
14 CU: caso de uso.
42
Las alarmas a ser tomadas en cuenta en el informe deben estar seleccionadas
Los destinatarios de los correos deben estar seleccionados.
Resumen: EL administrador crea los informes a ser enviados por correo mensualmente.
Curso Normal de Eventos Acciones Actor: Respuesta Sistema:
1. Comienza cuando el Administrador desea generar un reporte mensual con las alarmas mayores a 1000
2. El sistema despliega la opcin de seleccionar el mes para el cual se desea generar el informe.
3. El administrador selecciona mes y presiona el botn
4. Empieza el proceso de generar el informe de las alarmas seleccionadas.
5. El Administrador recibe confirmacin de la creacin de los informes, y del envo por correo.
Curso Alternativo 3. El administrador no selecciona un mes. 4. El sistema notifica que debe seleccionar un
mes para crear el informe.
5.2.3 Anlisis modelo de datos
La aplicacin a desarrollar debe almacenar aproximadamente 300.000 alarmas por
da. Estas alarmas de obtienen de una tabla guardada en una base de datos Microsoft
SQL Server 2005, estos datos no tienen ningn orden, es simplemente una plantilla
con 17 Columnas, las cuales se encuentran detalladas en la tabla 5.10.
Tabla 5.10: Descripcin de columnas de las alarmas.
Columnas Descripcin Formato Tipo de Datos
Date_Time Fecha y hora YYYY-MM-DD HH:MM:SS.MMM
datetime
FracSec Fraccin de segundo que duro la alarma
Entero 4 Dgitos smallint
Event_Type Tipo de evento que genero la alarma
String con 7 opciones posibles
nvarchar(32)
Event_SubType Vaco Columna en Blanco nvarchar(32)
Category Causa de la Alarma String con 7 Opciones posibles
nvarchar(64)
Area rea donde se gener la Alarma
String con 25 opciones posibles
nvarchar(32)
Node Controlador que genero la alarma
String nvarchar(64)
43
Unit Lugar especfico del rea
String nvarchar(255)
Module Modulo que genero la alarma
String nvarchar(255)
Module_Description
Descripcin del Modulo
String nvarchar(255)
Attribute Alarma Generada String nvarchar(255)
State Estado del mdulo que genero la alarma
String con 34 opciones disponibles
nvarchar(64)
Event_Level Gravedad de la alarma String con 9 Opciones disponibles
nvarchar(64)
Desc1 Descripcin detallada de la alarma
String nvarchar(255)
Desc2 Simple descripcin de la alarma
String nvarchar(255)
IsArchived Est archivada la alarma
Entero 1 Digito, generalmente 0
smallint
Ord Nmero de orden Entero de 7 dgitos int
Se deben generan informes que cuenten la cantidad de alarmas que se generan en 1
da, tomando en cuenta las siguientes columnas:
Event Type Area Node Module Attribute
Se tiene que por un lado estn las columnas con atributos descriptivos y por otro las
alarmas que deben ser medidas numricamente.
Por esta razn se utilizar un esquema estrella para el modelo de datos, donde las
columnas presentadas son las dimensiones y las alarmas que debemos contar son
nuestros hechos.
44
En la presente seccin se presentarn los casos de uso reales de los procesos ms
significativos de nuestra aplicacin, el diagrama de implementacin, los diagramas
de secuencia, diagrama de clases, diagramas de actividad y el diseo del modelo de
datos.
5.3.1 Casos de uso reales
A continuacin se describen casos de uso de cargar alarmas al almacn de datos y
generar informes mensuales de alarmas. Estos casos son generalmente usados en
forma secuencial, donde al cargar las alarmas del mes completo se procede a crear el
informe de las alarmas mensuales.
La tabla 5.11 describe el caso de uso Cargar alarmas al almacn de datos
Tabla 5.11: Cargar alarmas al almacn de datos
Caso de uso cargar alarmas al almacn de datos Actores: Administrador Propsito: Almacenar alarmas en el almacn de datos Tipo: Primario Resumen: El administrador carga alarmas al sistema
Interfaz 1: Cargar Alarmas
Curso Normal de eventos Accin Actores: Accin Sistema: 1. Este caso de uso comienza cuando el administrador desea agregar alarmas nuevas al sistema y presiona agregar alarmas.
1. El sistema despliega confirmacin del proceso finalizado correctamente.
'LVHxR
45
Por peticin de la empresa donde se desarroll la solucin, no se puede conectar el
servidor de la aplicacin de generacin de alarmas con el servidor del sistema de
control distribuido. Por lo que las alarmas no van a ser obtenidas automticamente,
sino que van a ser copiadas en DVD y luego se grabarn en el servidor de Alarmas
para crear los informes.
La tabla 5.12 describe el caso de uso Generar informes mensuales de alarmas
Tabla 5.11: Generar informes mensuales de alarmas
Caso de uso Generar informes mensuales de alarmas Actores: Administrador Propsito: Generar informes mensuales con alarmas
mayores a 1000Tipo: Primario Resumen: El Administrador genera un informe con las
alarmas mensuales que sobrepasaron las 1000 diarias.
Interfaz 1: Crear informes
Curso Normal de eventos Accin Actores: Accin Sistema: 1. El administrador selecciona el mes del informe.
2. El administrador selecciona si desea enviar y/o descargar los informes.
3. El administrador presiona el botn que comienza el proceso para crear el informe.
3. El sistema comienza a crear los informes.
Curso alternativo de eventos 3. El administrador olvido seleccionar el mes del informe y presiona el botn.
3. El sistema despliega mensaje para que el administrador seleccione el mes.
46
5.3.2 Diagramas de Secuencia
La figura 5.9 y 5.10 muestran los diagramas de secuencia de los casos de uso
presentados anteriormente.
Figura 5.9: Generar reportes ejemplo.
Figura 5.10: Diagrama de secuencia del caso de uso agregar alarmas.
48
La figura 5.11 presenta el diagrama de clases de nuestra aplicacin. Se utilizaron las
clases ms importantes del software desarrollado para la facilidad de la comprensin.
Figura 5.11: Diagrama de clases de software Alarmas.
Todas las clases se comunican entre ellas desde el equipo del cliente a travs de la
clase Page, que nos permite manejo de variables entre cliente y servidor, despliegue
de interfaz en el equipo del cliente, Etc.
5.3.3 Diagrama de Clases
49
La clase ArchivoExcel genera un informe entre 2 fechas especificadas sobre un
rea a eleccin, esto se puede ver claramente por las variables que contiene y sus
mtodos.
La clase AgregarAlarmas se conecta a la base de datos para que esta realice todo el
trabajo relacionado con la carga de los archivos diarios de alarmas, por esta razn
solo contiene una variable de conexin a la base de datos y mtodos que llaman a los
procedimientos almacenados que permiten realizar la carga de alarmas.
Por otro lado la clase Administrador es la central vista desde el lado del usuario,
porque est clase permite la interaccin de este con el sistema. En esta clase se
ubican los mtodos que llaman a otras clases y las propiedades que almacenan sus
elecciones.
Por ltimo la clase GenerarReportes, que permite la creacin de los informes de
alarmas.
5.3.4 Modelo de datos
Para el manejo de tal cantidad de alarmas mensuales, se realiz un estudio sobre los
datos a almacenar y cmo estos estaban relacionados. Se lleg a la conclusin que lo
nico que relacionaba a los datos eran las alarmas en s, esto quiere decir que una
tabla central, donde se almacenen las alarmas, a la que los atributos estn conectados
es perfecta para nuestra aplicacin. Por lo tanto se desarroll un modelo estrella, con
una tabla de hechos central donde simplemente se mantienen las alarmas y tablas de
dimensiones, que se relacionan con la de hechos.
El modelo final se muestra en la Figura 5.12.
Todos los datos en un almacn, deben ser cargados mediante funciones llamadas
ETL (Extract, transform and load), esta funcin debe extraer los datos de alguna
50
fuente, transformarlos para que puedan ser ingresados en el almacn y luego
cargarlos.
Figura 5.12: Modelo de datos para almacenar las alarmas.
Se puede observar en la Figura 5.12 la forma de estrella, en este caso tiene 14 puntas
o dimensiones.
5.3.5 Diagramas de Actividad
Desde las figuras 5.3 a la 5.8 se presentarn los diagramas de actividad de los casos
de uso del sistema.
51
52
Figura 5.3: Diagrama de actividad del proceso de Enviar por correo. Esta actividad obtiene la cuenta de correo a utilizar y las claves correspondientes, luego se conecta
al servidor Exchange y enva los correos generados con los informes.
53
Figura 5.4: Diagrama de actividad del proceso de cargar alarmas al almacn de datos. Est actividad busca nuevas alarmas en la carpeta especificada, si encuentra, las
carga al almacn de datos.
Figura 5.5: Diagrama de actividad del proceso Seleccionar destinatarios, solo se muestra la opcin de guardar a modo de ejemplo. La actividad mostrada en el
diagrama permite agregar los destinatarios de correos a la base de datos, o modificar los existentes.
54
Figura 5.6: Diagrama de actividad del proceso que genera los informes mensuales (1 Ejemplo de todos los informes que se hacen). Este diagrama muestra la creacin de
los informes, se ejecuta los procedimientos almacenados en la base de datos que filtran y entregan solamente los datos necesarios, para despus crear los informes en
Excel.
55
Figura 5.7: Diagrama de actividad del proceso que gestiona alarmas. La actividad presentada muestra la forma en que se marcan como gestionadas las alarmas en el
servidor, para de esta forma llevar un informe de que alarmas han sido gestionadas y cules no.
56
Figura 5.8: Diagrama de actividad del proceso que selecciona alarmas. La actividad muestra la forma en que el usuario puede modificar las alarmas a ser tomadas en
cuenta en los informes mensuales, para poder crear informes de acuerdo a requerimientos especficos.
57
5.3.6 Diagrama de Despliegue
El diagrama de implementacin o de despliegue nos va a permitir identificar el
hardware utilizado y las relaciones entre sus componentes. En la Figura 5.13 se
puede observar el esquema utilizado.
En el mismo servidor van a estar ubicadas la aplicacin y la base de datos, estas dos
van a interactuar con el equipo del cliente.
En el esquema se puede ver claramente la vista que se despliega en el PC del cliente,
el controlador que se ejecuta en el servidor de aplicaciones y la base de datos. Se
puede prestar atencin a su vez a la interaccin de los diferentes componentes de la
aplicacin y las libreras externas.
Figura 5.13: Diagrama de implementacin del sistema de alarmas.
58
5.4 Implementacin
En el presente capitulo se expondr la implementacin de la aplicacin.
5.4.1 Dificultades de la implementacin
Una de las principales dificultades encontradas al desarrollar la solucin,
corresponde al cambio de versin del Delta V (Programa de gestin del sistema de
control distribuido) de la versin 7.1 a la Versin 10.3, lo que modificaba el archivo
de salida con el cual se trabajara.
Este archivo ya no sera de texto plano con 300.000 lneas aproximadamente, sino
que paso a ser una base de datos de SQL Server 2005 de respaldo, con 300.000 filas
aproximadamente sin ningn tipo de relacin.
Se realiz un estudio sobre el formato del archivo nuevo de salida y de la mejor
forma de trabajar dicho archivo. Debido en gran parte a este problema se decidi
finalmente utilizar SQL Server 2008.
Segundo problema presentado para la implementacin, fue la peticin del envo de
correos automticos del sistema de alarmas al momento de crear los informes.
Se realiz un estudio de la Red de planta, del proxy existente y los puertos
bloqueados, se hicieron pruebas con distintos clientes de correo y libreras externas
necesarias para utilizarlos. De esta forma se concluy que se creara una cuenta de
correo especial para el sistema de alarmas, que no tendra problemas de puertos para
el envo de correos dentro y fuera de planta. Se utilizara una librera externa de
Microsoft Outlook que al integrarla con VB.Net nos permitira el envo de correos
sin problemas.
59
Tercer problema fue el requisito de que los informes deban ser entregados en
formato Excel 2010, para crear archivos Excel en versiones mayores al 2007, VB.Net
no posee libreras, por lo que se debi utilizar una externa.
Cuarto, el cambio de servidores que se efectu durante el desarrollo, esto se debi a
que el rea de sistemas y accionamientos no contaba con un servidor para las alarmas
que se pudiera utilizar durante el desarrollo, por lo que se utiliz el mismo PC de
desarrollo como servidor durante el primer tercio, se cambi este por un servidor de
prueba durante el segundo tercio y finalmente por el servidor final en la fase final de
desarrollo.
Estos cambios implicaron la reinstalacin de las bases de datos, adems de la
reconfiguracin de las mismas y algunos cambios en el cdigo del programa. Cabe
destacar a su vez que cada cambio fue para mejor, ya que al cargar un archivo con
300.000 alarmas, este tomaba 8 minutos en el primer servidor, 6 en el segundo y 4 en
el tercero.
Por ltimo, toda la carga de los procesos deba ser llevada por el servidor, esto
significaba que una gran cantidad de cdigo deba ser programado en T-SQL,
adems de realizar algunas configuraciones, que de no ser porque se trabaja en una
red interna de planta supondra, problemas de seguridad. Esto se not mayormente
cuando el servidor deba buscar los archivos en el disco duro y adjuntarlos, extraer la
informacin, transformarla y cargarla a su almacn de datos, porque para acceder al
disco duro hubo que permitir el acceso a comandos de Windows desde un
procedimiento almacenado. Esto poda producir riesgos de seguridad en caso de
inyeccin de cdigo SQL a travs de la pgina web.
Debido a lo anterior hubo que realizar un estudio sobre seguridad web y en
especfico sobre inyecciones SQL. En base a este artculo [MEM01] se decidi
utilizar en su mayora procedimientos almacenados cuando fuera posible para validar
entradas. No se ejecutara nunca T-SQL directamente desde VB.Net, solo se
llamaban a los procedimientos o funciones con los parmetros ingresados.
60
5.4.2 Consideraciones tcnicas
Se trabaj con la versin de SQL Server 2008 R2. .Net (ASP.Net y VB.Net) utilizados corresponden a la Versin 4.0 Se utiliz Visual Studio 2010. El sistema operativo utilizado es Windows XP Profesional SP3 de 32 Bits en
el Cliente.
El sistema operativo utilizado es Windows Server 2008 R2 64 Bits en el servidor.
5.4.3 Validacin de cumplimiento de requisitos
A continuacin se muestra una matriz de trazabilidad en la tabla 5.12. De esta
manera se puede llevar un registro verificable de los requisitos solicitados y los
requisitos cumplidos a travs de los casos de uso de la aplicacin.
Tabla 5.12: Matriz de trazabilidad.
61
6. VALIDACIN DEL SOFTWARE
En el proceso de validacin del software hay que considerar que los informes se
realizaban antiguamente con los archivos de texto plano. Estos archivos se utilizaron
hasta Octubre de 2011, de Noviembre en adelante se comenz a utilizar la bases de
datos de Microsoft SQL Server.
Por lo anterior, no se dispona de un mtodo para obtener informes con los archivos
nuevos, por lo que se cre una tcnica provisoria basada en el mtodo anterior
utilizando Access, que obtena los informes. Este era exactamente igual al anterior,
con la diferencia que el mtodo nuevo tomaba un poco ms de tiempo al tener que
adjuntar la base de datos nueva entregada por el sistema.
Este mtodo se fue mejorando y adecuando a la interfaz grfica creada y a la
automatizacin del proceso completo, ya que al principio era manual en todos sus
pasos.
Al finalizar la aplicacin se cre un mtodo automtico que puede procesar mayor
informacin, de manera minuciosa y sin errores humanos de por medio. Por lo que el
nuevo informe presenta una mayor cantidad de alarmas que el generado
anteriormente y de manera eficaz.
La validacin del software se realiz junto con Don Jose Campos, supervisor del rea
de DCS, encargado de crear los informes manualmente.
Se revis cada funcin de la aplicacin para verificar el correcto cumplimiento del
requisito asociado y que este respetaba los formatos predefinidos de la planta si
corresponda.
En una primera etapa se encontr que el formato del informe deba cambiar, por lo
que se modific la planilla con las alarmas a una deseada por el supervisor del rea,
se cre un informe mensual que indicaba alarmas por da y por rea; Este informe
mantena los estndares requeridos de planta para los documentos.
62
Se corrigi un problema con el envo de correos automtico, que se gener durante la
marcha blanca. Esto se debi a que la librera externa utilizada para enviar correos no
era compatible con la seguridad de la red de la planta, por lo que hubo que crear una
nueva.
Debido a la generacin automtica de informes, y el posterior envo de estos tambin
de forma autnoma, al entregar los informes de manera exitosa se cumple lo
acordado en el proyecto, quedando satisfecho el supervisor del rea.
63
7 ANLISIS DE COSTOS
Se efectu un anlisis de ahorro de costos que se producen al utilizar la aplicacin.
Como se puede observar en la tabla 6.1, existen 5 reas de produccin en la planta,
de las cuales 3 son las ms importantes en trminos monetarios: Licor (produccin de
electricidad que se vende al sistema interconectado central), fibra y maquina (ambas
afectan la produccin de celulosa).
Tabla 6.1: Promedio de fallas anuales por rea de la celulosa. Fuente: Rodrigo Sandoval, Jefe rea DCS, Celulosa Arauco, Planta Valdivia.
reas Promedio fallas anuales
Fallas por equipos
Fallas Operativas
Totales Alarmas
Licor 30 15 15 5Efluentes y
Aguas 12 6 6 1
Caustificacin y horno de cal
50 20 30 15Fibra 60 24 36 25
Maquina 240 192 48 4Se puede observar que de las alarmas en general, estn divididas en 2 reas grandes:
fallas por equipos y fallas operativas. Dentro de las fallas operativas encontramos las
fallas que son advertidas por las alarmas y pueden ser evitadas si se gestionan
correctamente.
En la tabla 6.2 se puede observar la cantidad de veces que la planta se ha detenido
por ao y la cantidad de horas que ha dejado de producir en total en el ao por las
fallas.
Tabla 6.2: Fallas que han detenido la planta por ao. Fuente: Rodrigo Sandoval, Jefe rea DCS, Celulosa Arauco, Planta Valdivia.
64
Si tenemos en cuenta los datos anteriores, obtenemos lo desplegado en la tabla 6.3.
Tabla 6.3: Perdidas en promedio por fallas en la planta. Fuente: Rodrigo Sandoval, Jefe rea DCS, Celulosa Arauco, Planta Valdivia.
Anualmente por mala gestin de las alarmas, se pierden $89.473.291 en promedio.
PERIODO
MESES
JUNIO
AGOSTO
OCTUBRE
ENERO
MARZO
MARZO
MAYO
AGOSTO
ABRIL
JULIO
AGOSTO
OCTUBRE
NOVIEM
BRE
DICIEMBRE
NFALLAS 1 1 1 1 1 1 1 1 1 1 1 1 1 1TOTALHORAS
PERDIDAS
2005 2006 2007 2008 2009
32 32 24 24 24
ConceptoPromedioanual
porhora Unidad TiempoUtilidaddeventaporMW[US]