Modelo de un sistema crítico para la caracterización de señales

Modelo de un sistema crítico para la
caracterización de señales aplicado a la
detección de eventos sísmicos
Mario Andrés Yandar
[email protected]
U NIVERSIDAD DEL VALLE
E SCUELA DE I NGENIERÍA DE S ISTEMAS Y C OMPUTACIÓN
C ALI - C OLOMBIA
M ARZO 10
DEL
2004
Ficha Técnica
T ÍTULO :
M ODELO
DE UN SISTEMA CRÍTICO PARA LA CARACTERIZA -
CIÓN DE SEÑALES APLICADO A LA DETECCIÓN DE EVENTOS
SÍSMICOS .
AUTOR
Mario Andrés Yandar Lobón
Código: 9613994
email: [email protected]
Director del proyecto de grado
Prof. Héctor Angulo B.
Ingeniero electricista Universidad del Valle
Especialista en Redes de Comunicaciones Universidad del Valle
Profesor de las asignaturas Sistemas Operativos,
Diseño de sistemas en tiempo real y Redes neuronales.
Universidad del Valle
Asesor
Jorge Alberto Mejía Mejía, Ph.D.
Ingeniero Civil - Universidad Nacional
Ph.D. en Geofísica
Investigador Observatorio Sismológico del SurOccidente O.S.S.O.
Universidad del Valle
Asesor
Jhon Henry Caicedo Orbes
Ingeniero de Sistemas - Universidad del Valle
Área de Instrumentación y Desarrollo O.S.S.O.
Nota de aceptación
________________________________
________________________________
Índice general
Resumen
XI
Introducción
1
1. Marco Contextual
3
1.1. Formulación del problema . . . . . . . . . . . . . . . . . . . . .
3
1.1.1. Definición del problema . . . . . . . . . . . . . . . . . .
3
1.1.2. Caracterización del problema . . . . . . . . . . . . . . .
4
1.1.3. Propuesta de solución . . . . . . . . . . . . . . . . . . .
6
1.1.4. Justificación
. . . . . . . . . . . . . . . . . . . . . . . .
8
1.1.5. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . .
9
1.1.6. Alcances y limitaciones . . . . . . . . . . . . . . . . . .
11
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . .
12
1.2.2. Objetivos estratégicos . . . . . . . . . . . . . . . . . . .
12
1.2.3. Objetivos específicos . . . . . . . . . . . . . . . . . . . .
13
I
1.3. Organización del documento . . . . . . . . . . . . . . . . . . . .
2. Marco Teórico
14
17
2.1. Visión general y estado del arte . . . . . . . . . . . . . . . . . . .
17
2.2. Sistemas de control . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.2.1. Descripción general . . . . . . . . . . . . . . . . . . . .
19
2.2.2. Componentes básicos . . . . . . . . . . . . . . . . . . . .
21
2.3. Procesamiento digital de señales . . . . . . . . . . . . . . . . . .
24
2.3.1. El efecto del ruido . . . . . . . . . . . . . . . . . . . . .
25
2.3.2. Filtrado . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.4. Redes de estaciones . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.4.1. Estaciones de registro . . . . . . . . . . . . . . . . . . .
28
2.4.2. Topologías de red . . . . . . . . . . . . . . . . . . . . . .
29
2.4.3. Procesamiento de señales sísmicas . . . . . . . . . . . . .
30
2.4.4. Otros casos de consideración . . . . . . . . . . . . . . . .
33
2.5. Sistemas en tiempo real . . . . . . . . . . . . . . . . . . . . . . .
35
2.5.1. Diseño en tiempo real . . . . . . . . . . . . . . . . . . .
35
2.5.2. Adquisición digital de datos . . . . . . . . . . . . . . . .
37
2.5.3. Estructuras de datos . . . . . . . . . . . . . . . . . . . .
38
2.5.4. Referencia a la señal de tiempo . . . . . . . . . . . . . .
39
2.5.5. Tiempo de respuesta . . . . . . . . . . . . . . . . . . . .
39
2.6. Detección y clasificación de señales . . . . . . . . . . . . . . . .
40
2.6.1. Detección STA/LTA . . . . . . . . . . . . . . . . . . . .
40
II
2.6.2. Estimación de parámetros sobre la señal. . . . . . . . . .
42
2.6.3. Mecanismos de detección . . . . . . . . . . . . . . . . .
43
2.6.4. Wavelets . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.7. Inteligencia artificial en DSP . . . . . . . . . . . . . . . . . . . .
45
2.7.1. Reconocimiento de patrones . . . . . . . . . . . . . . . .
45
2.7.2. Redes Neuronales . . . . . . . . . . . . . . . . . . . . . .
47
2.7.3. Algoritmos genéticos . . . . . . . . . . . . . . . . . . . .
49
2.7.4. Otras técnicas . . . . . . . . . . . . . . . . . . . . . . . .
50
2.8. Desarrollo de proyectos de software . . . . . . . . . . . . . . . .
51
2.8.1. Ciclo de vida de desarrollo . . . . . . . . . . . . . . . . .
52
2.8.2. Bases del desarrollo de software . . . . . . . . . . . . . .
52
2.8.3. Sistema crítico o con tolerancia a fallos . . . . . . . . . .
55
3. Desarrollo del Modelo
59
3.1. Planeación del proyecto . . . . . . . . . . . . . . . . . . . . . . .
60
3.1.1. Análisis de factibilidad . . . . . . . . . . . . . . . . . . .
60
3.1.2. Recursos y actividades . . . . . . . . . . . . . . . . . . .
61
3.1.3. Sistema de calidad . . . . . . . . . . . . . . . . . . . . .
63
3.2. Comprensión y Análisis . . . . . . . . . . . . . . . . . . . . . . .
64
3.2.1. Descripción general . . . . . . . . . . . . . . . . . . . .
64
3.2.2. Análisis de requerimientos . . . . . . . . . . . . . . . . .
65
3.3. Determinación del Ciclo de Vida . . . . . . . . . . . . . . . . . .
67
3.3.1. Entrega por etapas . . . . . . . . . . . . . . . . . . . . .
67
III
3.3.2. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . .
71
3.3.3. Gestión de riesgos . . . . . . . . . . . . . . . . . . . . .
72
3.4. Consideraciones de Diseño . . . . . . . . . . . . . . . . . . . . .
74
3.4.1. Gestión de configuraciones . . . . . . . . . . . . . . . . .
74
3.4.2. Patrones de diseño . . . . . . . . . . . . . . . . . . . . .
75
3.4.3. Diseño crítico . . . . . . . . . . . . . . . . . . . . . . . .
76
3.4.4. Excepciones de aplicación . . . . . . . . . . . . . . . . .
79
3.5. Definición Plan de Pruebas . . . . . . . . . . . . . . . . . . . . .
79
3.5.1. Sobre el diseño del producto . . . . . . . . . . . . . . . .
79
3.5.2. Sobre la funcionalidad del producto . . . . . . . . . . . .
81
3.6. Resumen del modelo . . . . . . . . . . . . . . . . . . . . . . . .
81
4. Etapas del desarrollo
83
4.1. Planeación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.1.1. Factibilidad . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.1.2. Actividades . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.1.3. Sistema de calidad . . . . . . . . . . . . . . . . . . . . .
85
4.2. Descripción del sistema actual . . . . . . . . . . . . . . . . . . .
86
4.2.1. Análisis detallado (Etapa 0) . . . . . . . . . . . . . . . .
86
4.2.2. Definición de las etapas . . . . . . . . . . . . . . . . . .
93
4.2.3. Arquitectura de la herramienta . . . . . . . . . . . . . . .
96
4.2.4. Sección crítica . . . . . . . . . . . . . . . . . . . . . . .
98
4.3. Etapa 1: Comunicaciones y control . . . . . . . . . . . . . . . . .
99
IV
4.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . .
99
4.3.2. Protocolos . . . . . . . . . . . . . . . . . . . . . . . . .
99
4.3.3. Codificación . . . . . . . . . . . . . . . . . . . . . . . .
99
4.3.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4. Etapa 2: Entrada y visualización de señales . . . . . . . . . . . . 101
4.4.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.4.2. Diseño detallado . . . . . . . . . . . . . . . . . . . . . . 101
4.4.3. Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.4.4. Codificación . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.5. Etapa 3: Núcleo - Detector de cambios . . . . . . . . . . . . . . . 102
4.5.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.5.2. Diseño detallado . . . . . . . . . . . . . . . . . . . . . . 105
4.5.3. Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.5.4. Codificación . . . . . . . . . . . . . . . . . . . . . . . . 106
4.5.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.6. Etapa 4: Clasificador de eventualidades . . . . . . . . . . . . . . 108
4.6.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.6.2. Codificación . . . . . . . . . . . . . . . . . . . . . . . . 108
4.6.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.7. Etapa 5: Sistema de alerta . . . . . . . . . . . . . . . . . . . . . . 109
4.7.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . 109
V
4.7.2. Diseño detallado . . . . . . . . . . . . . . . . . . . . . . 111
4.7.3. Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.7.4. Codificación . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.8. Etapa 6: Integración de componentes y pruebas . . . . . . . . . . 114
4.8.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.8.2. Diseño detallado . . . . . . . . . . . . . . . . . . . . . . 114
4.8.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5. Análisis de resultados
117
5.1. Estabilidad y rendimiento . . . . . . . . . . . . . . . . . . . . . . 117
5.1.1. Etapa 1 - funciones comunes . . . . . . . . . . . . . . . . 117
5.1.2. Etapa 2 - Entrada y visualización . . . . . . . . . . . . . . 118
5.1.3. Etapa 3 - Núcleo Detector . . . . . . . . . . . . . . . . . 118
5.1.4. Etapa 4 - Clasificación de eventualidades . . . . . . . . . 119
5.1.5. Etapa 5 - Servidor de Alertas . . . . . . . . . . . . . . . . 119
5.1.6. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.2. Verificación y validación . . . . . . . . . . . . . . . . . . . . . . 120
5.2.1. Primera verificación . . . . . . . . . . . . . . . . . . . . 120
5.2.2. Segunda verificación . . . . . . . . . . . . . . . . . . . . 121
6. Conclusiones
125
6.1. Sobre el Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
VI
6.2. Sobre la herramienta . . . . . . . . . . . . . . . . . . . . . . . . 126
6.3. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . 127
7. Trabajo futuro y recomendaciones
131
Bibliografía
133
A. Estructuras de control
137
A.1. Flujo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
A.1.1. Estructura DSRCP . . . . . . . . . . . . . . . . . . . . . 137
A.1.2. Estructura XMLDSRC . . . . . . . . . . . . . . . . . . . 138
A.1.3. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . 140
A.1.4. Registro de mensajes . . . . . . . . . . . . . . . . . . . . 140
A.1.5. Formato WVM . . . . . . . . . . . . . . . . . . . . . . . 141
A.2. Configuraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
A.2.1. Parámetros de configuración general . . . . . . . . . . . . 142
A.2.2. Emisión de alertas . . . . . . . . . . . . . . . . . . . . . 144
A.2.3. Manejo de errores . . . . . . . . . . . . . . . . . . . . . 146
B. Pruebas S-DCE
153
B.1. Eventos previamente detectados . . . . . . . . . . . . . . . . . . 153
B.1.1. Evento 1995 04 06 - 10:31:11 . . . . . . . . . . . . . . . 153
B.1.2. Evento 1995 08 09 - 10:30:40 . . . . . . . . . . . . . . . 155
B.1.3. Evento 1995 07 16 - 16:40:26 . . . . . . . . . . . . . . . 157
VII
B.1.4. Evento 1995 04 13 - 18:28:34 . . . . . . . . . . . . . . . 159
B.1.5. Evento 1996 09 05 - 08:22:22 . . . . . . . . . . . . . . . 161
B.1.6. Evento 1996 11 15 - 02:53:06 . . . . . . . . . . . . . . . 163
B.1.7. Evento 1998 11 07 - 03:10:46 . . . . . . . . . . . . . . . 165
B.1.8. Evento 1998 12 03 - 00:55:35 . . . . . . . . . . . . . . . 167
B.1.9. Evento 1998 11 05 - 01:03:28 . . . . . . . . . . . . . . . 168
B.1.10. Evento 1998 12 10 - 04:19:36 . . . . . . . . . . . . . . . 171
B.2. Señal continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
B.2.1. Evento 2003 12 25 - 06:59:03 . . . . . . . . . . . . . . . 173
B.2.2. Evento 2003 12 25 - 07:13:00 . . . . . . . . . . . . . . . 174
B.2.3. Evento 2003 12 25 - 07:21:12 . . . . . . . . . . . . . . . 176
B.2.4. Evento 2003 12 25 - 08:55:20 . . . . . . . . . . . . . . . 178
B.2.5. Evento 2003 12 25 - 20:34:18 . . . . . . . . . . . . . . . 179
VIII
Índice de figuras
2.1. Conversión análogo/digital . . . . . . . . . . . . . . . . . . . . .
26
2.2. Distribución de las estaciones sismológicas del OSSO. . . . . . .
31
2.3. Localización de eventos. . . . . . . . . . . . . . . . . . . . . . .
32
2.4. Adquisición digital . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.5. STA/LTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.1. Ciclo de vida de Entrega por etapas . . . . . . . . . . . . . . . . .
69
4.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.2. Modelo Conceptual . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.3. DSS - Visualización y configuración . . . . . . . . . . . . . . . .
91
4.4. DSS - Captura de señal . . . . . . . . . . . . . . . . . . . . . . .
92
4.5. DSS - Detección . . . . . . . . . . . . . . . . . . . . . . . . . .
92
4.6. DSS - Clasificación . . . . . . . . . . . . . . . . . . . . . . . . .
93
4.7. DSS - Emisión de alerta . . . . . . . . . . . . . . . . . . . . . . .
94
4.8. Arquitectura de componentes . . . . . . . . . . . . . . . . . . . .
97
4.9. DColaboración - Captura de señal . . . . . . . . . . . . . . . . . 103
IX
4.10. DColaboración - Visualización y configuración . . . . . . . . . . 104
4.11. DColaboración - Detección y Clasificación . . . . . . . . . . . . 105
4.12. DColaboración - Emisión de alerta . . . . . . . . . . . . . . . . . 111
4.13. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . 115
X
Resumen
Los sistemas de observación sismológicos han tenido la responsabilidad de alertar
con rapidez y precisión ante eventos sísmicos que ocurran en su zona de cobertura.
El proceso de detección es una de las partes más importantes de la alerta y atención
en situaciones de emergencia, ya que debe determinar con alto grado de confiabilidad cuando y donde ocurre un fenómeno natural o artificial, a partir de señales
registradas por sensores localizados en diversos lugares geográficos. Este proyecto
propone un modelo para realizar la caracterización de señales digitales, con el fin
de identificar comportamientos anormales que fuesen de interés para el sistema de
monitoreo. Finalmente se realiza la construcción de una herramienta basada en un
modelo funcional para la detección de eventos sísmicos considerando el problema
del ruido y realizando alertas para situaciones de emergencia.
Palabras claves: Ingeniería de software, tiempo real, procesamiento de señales,
inteligencia artificial, sistemas de control, sismología.
Keywords: Software engineering , real-time, signal processing, artificial intelligence, control systems, seismology.
XI
Introducción
Gran parte del compromiso social y científico de las instituciones de investigación
es ofrecer a la comunidad, información que le permita conocer mejor su medio
ambiente. Para el caso de la observación de fenómenos naturales, tal información
resulta ser más importante siempre que pueda advertir de peligros potenciales o
que permitan tomar medidas de atención y prevención en emergencias. Es imperativo para los sistemas de socorro conocer la información relevante en el menor
tiempo posible, a fin de atender las consecuencias inmediatas o futuras que pudieran presentarse, minimizando en algunas situaciones impactos sobre seres y bienes.
La observación sismológica consta, a grandes rasgos, de tres procesos: adquisición
de información sismológica, sistema de detección de eventos sísmicos y procesamiento de información básica del evento. Para efectos de investigación del fenómeno se tiene una cuarta fase denominada post-procesamiento. Por lo general, es
factible la automatización de las tres primeras fases, debido al volumen de datos,
corto tiempo de respuesta y funcionamiento permanente.
El Observatorio Sismológico del Sur Occidente -OSSO- opera desde 1987 una red
1
de estaciones sismológicas al sur occidente de Colombia, con la misión de evaluar
la información sísmica registrada. Tal observación se debe realizar ininterrumpidamente, manteniendo constante vigilancia sobre el comportamiento de la señal
registrada y el estado de los componentes de todo el sistema. Para el OSSO, así
como para otros institutos de observación no es posible tener personal capacitado
24 horas al día cumpliendo esta labor. Es por ello que se buscan mecanismos automáticos con los cuales se pueda identificar y analizar la ocurrencia de movimiento
terrestre de origen sísmico.
Las señales, vistas como registros que cambian con el tiempo, describen comportamientos de algún sistema. Estas señales pueden tener diversas fuentes y pueden
estimar o medir diferentes variables, por ejemplo registros de sonido, temperatura
o movimiento. Con la modernización de los sistemas digitales, las señales se adquieren por medio de dispositivos electrónicos y su procesamiento por sistemas de
computo, ampliándose las posibilidades para el monitoreo y la investigación del
comportamiento de la tierra. El presente proyecto propone un modelo para realizar
análisis de señales y busca desarrollar un sistema para procesar la señal sísmica e
identificar cuando segmentos de los datos registrados corresponden a movimientos
terrestres y condiciones anormales que representen mal funcionamiento del sistema.
2
Capítulo 1
Marco Contextual
1.1.
Formulación del problema
1.1.1.
Definición del problema
El monitoreo de una variable física requiere supervisión permanente de señales que
varían con el tiempo. Tal información, en sismología es generalmente impredecible, es decir, no se conoce de antemano el comportamiento que tendrá la señal en
un momento dado.
Para la observación sismológica es de especial interés reconocer comportamientos anormales de las señales sísmicas, debido a que estos cambios pueden sugerir
la ocurrencia de algún fenómeno natural. Las señales emitidas por el conjunto de
estaciones sismológicas contienen, además de la señal sísmica, otras señales añadidas como consecuencia de efectos del medio físico en el que se encuentran o
adicionadas en el proceso de transmisión/recepción.
3
Teniendo en cuenta la complejidad de las señales terrestres, durante un sismo o en
presencia de ruido u otras señales, se deben tener en consideración diversas variables para su efectiva discriminación. Actualmente no se cuenta con un mecanismo
de detección, que sea de rápida respuesta y confiable, capaz de recibir datos de los
sistemas de adquisición en desarrollo por el OSSO, de uso fácil y configurable a las
necesidades de la observación a realizar. Este sistema debería determinar la ocurrencia de eventos sísmicos en una red de estaciones sismológicas, independiente
de su distribución geográfica y ante la presencia de diferentes tipos de fenómenos
artificiales que ocasionan la ocurrencia de falsas alarmas.
1.1.2.
Caracterización del problema
Existen en el mercado, varios sistemas de detección automática que actúan correctamente en situaciones ideales, pero las señales terrestres tienen añadidas otras
señales provenientes de diversas fuentes. Generalmente los sistemas comerciales
para adquisición de datos sismológicos incluyen una herramienta que realiza la
detección, usando exclusivamente la información que provee la adquisición. Los
resultados de estas detecciones generan, muchas veces, falsas alarmas, o no registran señales que correspondan a eventos sísmicos.
Una red sismológica está conformada por un grupo de estaciones con diversas características, que puede registrar señal sísmica en una área geográfica, teniendo
limitaciones en cuanto a la precisión y alcance de los instrumentos de medición,
así como un margen de confiabilidad en la localización de eventos. El proceso de
4
localización constituye la obtención de parámetros que caracterizan un evento y el
tiempo-espacio en el cual ocurrió. Lo anterior se puede realizar siempre que sea
posible determinar cuando una señal registrada es de origen sísmico, a fin de conocer el momento en el tiempo para el cual un evento es registrado por los sensores1
(a esto se le denomina el proceso de detección), otorgando un alto margen de confianza sobre la detección de eventos reales.
La detección de un evento debe tener en cuenta varios factores que varían de acuerdo a características del medio ambiente como:
Espectro de observación del sensor. (capacidad física de registro del equipo)
Calidad de la transmisión.
Factores climáticos. (lluvia, viento)
Ruido natural. (maquinaria, personas, animales)
Calidad de la recepción.
Funcionamiento incorrecto de componentes eléctricos, mecánicos o de software.
Estos factores pueden generar tipos de señales no deseables que alteran los registros
sísmicos, ocasionando la emisión de falsas alarmas o la pérdida de información.
1 Sensor: dispositivo físico, mecánico, químico o electrónico que entrega datos sobre el comportamiento de un objeto de estudio.
5
En conclusión, no se dispone en el medio de un sistema de detección de eventos
sísmicos de dominio público, que tenga en cuenta los factores mencionados, que
tenga una independencia del proceso de adquisición de datos y principalmente que
detecte eventos sísmicos con un alto grado de confiabilidad.
1.1.3.
Propuesta de solución
Los aspectos mencionados anteriormente deben tenerse en cuenta durante el diseño
de la aplicación. El sistema propuesto deberá determinar cuales datos representan
actividad sísmica real y cuales daños sobre componentes del sistema provienen de
otras señales que no son de interés (ruido). Es necesario además poder configurar
los criterios de la detección, considerando casos como el listado de estaciones que
se desee usar, nivel de sensibilidad de la detección, entre otros.
Los puntos mencionados no son exclusivos de la red sismológica del OSSO; ellos
son válidos en redes sismológicas de similares características o incluso de otros
sistemas que operan con señales. La alternativa de solución consiste en la construcción de herramientas de software que permitan satisfacer los requisitos planteados, con el mínimo tiempo de respuesta, máxima confiabilidad, gran facilidad de
uso y siguiendo criterios de Ingeniería de software.
Como recurso de investigación se utilizarán datos de señal continua, previamente
almacenados, con los cuales se podrán realizar pruebas del software sin esperar la
ocurrencia de eventos sísmicos, con el objetivo de realizar calibración y control de
calidad del sistema. También se cuenta con varios sistemas de adquisición continua
6
de datos, los cuales pueden ser usados para probar el funcionamiento del software. El sistema a desarrollar especifica un formato de entrada de datos, compuesto
básicamente por :
Datos de la señal: Tiempo, tasa de muestreo, estación origen, frecuencia,
amplitud, entre otros.
Parámetros de configuración: Nivel de sensibilidad, grupo de estaciones,
opciones de filtrado, escogencia de alerta.
El sistema debe decidir si un segmento de señal corresponde o no a un evento y obtener sus características generales en caso afirmativo, sin incurrir en un proceso de
localización automática. La caracterización es una estimación de algunos factores
relevantes del conjunto de señales, que puede entregar información útil de manera
ágil y confiable.
Como requerimientos adicionales a los mencionados antes, el desarrollo se hará
bajo el sistema operativo Linux, que ya está siendo utilizado en el OSSO para la
adquisición de datos, debido a que es constantemente mejorado, estable, multitarea
y de dominio público. Se debe realizar el desarrollo de un sistema documentado,
que pueda ser aplicado en diversas redes sismológicas, e incluso en otros casos
con comportamiento similar (control industrial, seguridad, telecomunicaciones),
de acuerdo a las necesidades del usuario, garantizando dentro de las limitaciones,
el funcionamiento de la herramienta.
7
1.1.4.
Justificación
Con el crecimiento de las tecnologías digitales, especialmente el computador, se
han dado grandes avances en el campo de la investigación científica. El manejo
de señales análogas ha evolucionado al procesamiento digital de señales aunado al
uso del computador como herramienta principal para el análisis. Esto ha permitido la creación de diversos sistemas enfocados en áreas específicas (comunicaciones, reconocimiento de voz, imágenes). La sismología también ha transformado
sus mecanismos para el análisis de su información, con la adquisición de sistemas
digitales que les permitan almacenar y procesar señales sísmicas, permitiendo mejorar e incrementar el rango de observación del fenómeno, la calidad de los datos
y las posibilidades para la investigación en este campo.
El problema de la detección automática requiere el uso de las matemáticas, principalmente la teoría de señales, además de herramientas propias de las ciencias de
la computación tales como Ingeniería de Software, Sistemas Operativos, Diseño
en Tiempo Real, Inteligencia Artificial, Redes de Comunicaciones, entre otras, las
cuales aportarán elementos para el diseño y desarrollo del proyecto, adicionándole
características para su uso y mantenimiento.
Este proyecto propondrá un modelo teórico, base de la herramienta de software, y
factible de usarse en implementaciones de otras áreas del conocimiento con requerimientos similares. El criterio de diseño como sistema crítico otorga condiciones
para garantizar la estabilidad, confiabilidad y tiempo de respuesta del producto, a
fin de usarse en otros ambientes con requerimientos similares.
8
Para el OSSO la consecución de un sistema que cubra sus necesidades en este
campo permitirá aumentar su umbral de detección y aumentar la cantidad de eventos detectados por la red sismológica, que actualmente no se pueden discriminar.
Adicionalmente se espera reducir el número de falsas detecciones, obtener más información a partir de las señales y alertar de manera oportuna al personal del área
de sismología sobre posibles eventos, a fin de realizar una estimación más completa
sobre los datos registrados.
1.1.5.
Antecedentes
Los primeros avances en detección se dieron en el ámbito militar, a fin de explorar
las vibraciones terrestres cuando dispositivos nucleares explotaran en algún lugar
del planeta. Con varios sensores muy potentes se podía determinar el sitio de ocurrencia y la magnitud de la explosión. Luego estos sistemas se implementaron para
la vigilancia del tratado de “No proliferación de armas nucleares”. La sismología
hace uso de esta tecnología para la observación terrestre en búsqueda de eventos
sísmicos importantes, a fin de comunicar lo más rápido posible para su atención.
El OSSO cuenta, desde hace varios años, con un sistema de adquisición y detección de eventos, que funciona en plataforma DOS (modeaprh). Sin embargo, para
el caso del OSSO y la Red Sismológica del Sur Occidente, de las señales registradas como eventos por el sistema, entre el 40 y 50 % son reclasificados como
ruido (año 1999), ésto debido a mal funcionamiento de las estaciones, problemas
de transmisión por radio o recepción de la señal, además de posibles ruidos gene9
rados por elementos cercanos al sitio donde se encuentra el sensor.
Otros sistemas existentes como ViSeis, que se ejecuta bajo plataforma Microsoft
WindowsTM , realiza la adquisición y detección de manera conjunta. El principal
inconveniente detectado es que toma bloques de datos de 5 minutos, buscando de
manera independiente en cada bloque la condición de ocurrencia de evento sísmico. Además no permite el uso de señal adquirida por fuera de su sistema.
Seisan es parte de un sistema desarrollado en Noruega para procesamiento de datos
sismológicos. Este sistema tiene un módulo que realiza la adquisición y detección
también de manera conjunta. Para su funcionamiento se depende del sistema de
adquisición, Seisnet.
De acuerdo a estas experiencias y otras que se han tenido con sistemas de adquisición y detección, se ha concluido que muchos no cumplen con las características que requiere el OSSO para la observación. La mayoría de los sistemas de
adquisición, cuentan con un sistema de detección basado en STA/LTA (Short Term
Average / Large Term Average)2 , almacenando la señal en periodos específicos de
tiempo. Estos sistemas integrados son construidos para realizar detección sólo con
las señales de la adquisición, cerrando la posibilidad de usar registros de estaciones
que no estén incluidas en el mismo proceso de adquisición.
2 Algoritmo
de detección descrito en 2.6.1.
10
1.1.6.
Alcances y limitaciones
Los alcances de este proyecto están enfocados hacia la construcción de una herramienta de software, siguiendo principios de diseño de ingeniería de software con
las siguientes metas:
Modelo abierto de desarrollo.
Diseño y software aplicable a problemas similares.
Generación de documentación para el manejo y desarrollo del software.
Generación de interfaces gráficas para uso cómodo del usuario.
Uso de tecnología de bajo costo y disponibles en el OSSO.
Utilidad y aplicabilidad para el OSSO.
Interconexión con módulos anteriores y posteriores al proceso: Adquisición
y procesamiento de datos.
Algunas limitaciones de sistemas similares se han descrito anteriormente. En general, de los sistemas existentes pocos ofrecen un diseño abierto de software que
permita su revisión y afianzamiento. La mayoría de los modelos comerciales del
mercado son cerrados y tienen pocas opciones de interconectividad con sistemas de
adquisición y procesamiento diferentes a los ofrecidos por el fabricante o manejo
de algunos formatos estándar en el medio. Otros modelos más eficientes son muy
costosos, manteniendo su diseño oculto y están ligados a plataformas de software3
3 Conjunto de instrucciones escritas en algún lenguaje de programación que son ejecutadas por un
procesador.
11
y hardware4 especializado.
El sistema propuesto debe tener en cuenta para su diseño y ejecución, características derivadas del sistema operativo sobre el cual funcionará. El formato de entrada
de la información, el cual será establecido por el modelo. Especificaciones de los
sistemas de comunicación y trasmisión de datos a usar. Dado el enfoque de sistema
crítico, el diseño debe contemplar la recuperación de fallos y excepciones dentro
de algunas situaciones, a fin de garantizar el funcionamiento correcto y constante
del sistema.
1.2.
Objetivos
1.2.1. Objetivo general
Implementar un sistema detector de eventos sísmicos para redes sismológicas,
a partir de señales sísmicas, que siga principios de diseño de sistemas críticos,
otorgando confiabilidad y tolerancia a fallos, dentro de criterios establecidos.
1.2.2. Objetivos estratégicos
Diseñar un modelo teórico que permita realizar la detección de anomalías sobre
una señal y caracterización de la información obtenida, usando técnicas de Inteligencia Artificial y de Procesamiento de Señales.
4 Dispositivo electrónico que permite la ejecución de rutinas lógico matemáticas, funciones de
almacenamiento, comunicaciones, entre otros.
12
Aplicar el modelo de desarrollo de software de código abierto (OpenSource) para
la construcción de herramientas para sistemas de control industrial, siguiendo el
diseño planteado.
Promover la creación de herramientas bajo plataforma Linux, siguiendo criterios
de calidad y garantizando su modularidad, robustez y estabilidad, a fin de emplearse en medios productivos, académicos y científicos para el monitoreo de variables
naturales o artificiales.
Proponer métodos y herramientas para el monitoreo de fenómenos físicos, usando
tecnología de bajo costo, con hardware de propósito general.
1.2.3.
Objetivos específicos
Proponer un diseño teórico bajo la combinación de técnicas de programación, que
permita el análisis automático de señales digitales a partir de adquisición continua
de datos.
Elaborar una aplicación que permita reducir el número de falsas alarmas, comparando resultados con los obtenidos por otros sistemas del mismo tipo.
13
Realizar un plan de pruebas para determinar la confiabilidad de la herramienta, haciendo uso de datos anteriormente almacenados, comparándolos con análisis manuales de los operadores sismológicos.
Diseñar un actuador del sistema, que permita la emisión de alarmas sobre eventos
detectados u otras anomalías que pueda presentar el conjunto de señales (ruido excesivo, daños, entre otros).
Generar mecanismos de control para determinar posibles daños o mal funcionamiento de la red de estaciones.
Facilitar el uso de la herramienta por parte del usuario, con el uso de interfaces
gráficas para realizar la configuración del sistema a operar.
1.3. Organización del documento
El presente documento se encuentra organizado por capítulos. Este primer capítulo
plantea el problema, la justificación del mismo y los objetivos entre otros, con lo
cual se dá una idea general del trabajo. El Capítulo 2, presenta el Marco Teórico
necesario para plantear el modelo requerido. El Capítulo 3, propone el modelo de
sistema crítico, sobre el cual estará basado el diseño del sistema. El Capítulo 4,
corresponde a la etapa de implementación para el caso particular de la detección
14
de eventos sísmicos, basado en el modelo propuesto. En el Capítulo 5, se presenta
un análisis de resultados respecto a la ejecución del software construido y se dan
algunas conclusiones y recomendaciones sobre este trabajo. Finalmente, los Capítulos 6 y 7 muestran una síntesis de los logros alcanzados y aportes para futuros
desarrollos.
15
16
Capítulo 2
Marco Teórico
2.1.
Visión general y estado del arte
Entre los tópicos teóricos que contempla este proyecto se relacionan diversas áreas:
Sistemas automáticos de control: La automatización de procesos ha tenido grandes avances con los aportes de la computación y la electrónica avanzada, ya que
ha permitido incorporar a estos sistemas características que los hacen más eficientes. Con la utilización de técnicas de inteligencia artificial se han creado sistemas
adaptativos que captan las condiciones del medio y los aplican a la resolución de
problemas y toma de decisiones.
Procesamiento digital de señales: Con la aparición de equipos de cómputo de
gran capacidad de almacenamiento y procesamiento, las señales han podido ser
analizadas por métodos matemáticos y estadísticos, entre otros. Estas señales pueden ser resultado de una medición que tiene una variación respecto a otra variable
17
como el tiempo; tales mediciones han permitido utilizar la información provista
por sensores1 de distinto tipo, para realizar monitoreo y control en diversos campos de investigación y producción.
Sistemas en tiempo real: los sistemas en tiempo real tienen la función primordial
de ejecutar aplicaciones en rangos de tiempo muy limitados o en instantes precisos
de tiempo, debido a requerimientos indispensables de los problemas a tratar. A medida que los sistemas de cómputo han ido evolucionando, se dá paso a su utilización
en procesos industriales y científicos más complejos, teniendo como condiciones
indispensables de diseño una respuesta completa y correcta al problema, además
del predeterminar el tiempo máximo o preciso necesario para tenerla.
Algoritmos y métodos de detección: La detección de eventos sobre señal digital
consiste básicamente en determinar el momento sobre el tiempo en el cual ocurren
cambios o fenómenos de interés, de manera abrupta o paulatinamente en el tiempo.
La importancia de estos métodos radica en que ciertos comportamientos de la señal pueden indicar estados especiales sobre el sistema que sugieran la necesidad de
emitir una acción o respuesta de algún sistema. La idea general es que el algoritmo
sea lo suficientemente robusto como para tener un grado de confiabilidad alto (tasa
de aciertos), contemplando efectos propios del monitoreo de variables físicas como
el ruido y otros factores externos.
Ingeniería de software: Durante los últimos 20 años la manera de producir soft1 Sensor: dispositivo físico, mecánico, químico o electrónico que entrega datos sobre el comportamiento de un objeto de estudio.
18
ware ha sufrido grandes transformaciones. A medida que los sistemas de software
son más complejos se han requerido mecanismos que permitan diseñarlos más confiablemente. Para el desarrollo de software de uso exhaustivo, donde su correcto
funcionamiento determine en gran medida la operatividad de un sistema, es necesario contar con una metodología para realizar análisis, diseño e implementación
de una solución de software adecuada a las condiciones del problema.
Estas áreas de conocimiento corresponden a diversas ramas de la Ingeniería y las
ciencias exactas, que serán utilizadas de manera conceptual y práctica en el desarrollo de este proyecto. Se hace en este capítulo una breve explicación de los
apartes más significativos al producto a desarrollar.
2.2.
Sistemas de control
2.2.1.
Descripción general
La teoría de sistemas de control y tecnología de control son disciplinas académicas
aplicadas a problemas de ingeniería y ciencia. Los sistemas de control constituyen
modelos de flujo de información compuestos por entradas, salidas, procesamiento
de datos y realimentación [Kuo96].
Sistemas y teoría de control
La teoría de control está relacionada con el comportamiento dinámico de los sistemas con entradas y salidas, e interactivos con el ambiente.
19
Tecnología de control
La tecnología de control está relacionada con el control del comportamiento dinámico de sistemas técnicos complejos, por ejemplo sistemas (electro) mecánicos
y procesos químicos o biológicos. El objetivo del control es lograr un comportamiento del sistema de acuerdo a las especificaciones deseadas, la complejidad del
proceso aumenta en la medida que se tenga una descripción menos precisa del comportamiento dinámico del sistema. La tecnología de control es muy próxima a la
síntesis, usando métodos, técnicas y herramientas de diversos campos científicos,
en particular teoría de sistemas.
La teoría de control se concentra en problemas asociados con el comportamiento
dinámico de sistemas. Estos problemas son tratados como sistemas abiertos, que
significan, sistemas con entradas y salidas, que interactúan con el ambiente. Algunos problemas importantes manejados por la teoría de control son:
Modelamiento: La búsqueda de conceptos adecuados y herramientas matemáticas para describir sistemas dinámicos en interacción con el medio.
Identificación: Desarrollo de algoritmos para formular modelos dinámicos sobre
la base de la observación de señales.
Filtrado:
Estimación del comportamiento de una variable a partir de la observación de la razón señal - ruido.
Control:
Aplicar principios y algoritmos para obtener un procesador con retroalimentación que responda adecuadamente al comportamiento dinámico del sistema.
20
Motivada por los problemas de ingeniería, la teoría (o también tecnología) de control aporta conceptos como la dependencia tecnológica y aplicabilidad de restricciones principales. Ambos conceptos son utilizados de una parte por la teoría de
control, y de otra por el análisis y modelamiento matemático de problemas.
La teoría de sistemas y tecnología de control son complementarias en muchas situaciones, por ejemplo en modelamiento de procesos electro-mecánicos o químicos
y en la validación de diseños. Una infraestructura tecnológica y un conocimiento
científico son necesarios para proponer un modelo y validarlo en un alto nivel. Para
ejecutar exitosamente las tareas asociadas al modelamiento, un científico de control deberá tener conocimiento de las áreas de aplicación, así como con sistemas
modernos para procesamiento de datos.
2.2.2.
Componentes básicos
Según [Kuo96], un sistema de control se describe mediante:
Objetivos de control.
Componentes del sistema de control.
Resultados o salidas.
En términos técnicos, los objetivos se pueden identificar como entradas, o señales
actuales y a los resultados se les denomina salidas, o variables controladas. En general, el objetivo de un sistema de control es controlar las salidas en alguna forma
prescrita mediante las entradas a través de los elementos que componen tal sistema.
21
2.2.2.1.
Sistema de control en lazo abierto
(Sistemas no retroalimentados). Los sistemas de control en lazo abierto son sistemas simples, que no pueden satisfacer requerimientos de desempeño crítico. Los
elementos de un sistema de control en lazo abierto se pueden dividir en dos partes: el controlador y el proceso controlado. Una señal de entrada o comando se
aplica al controlador, cuya salida actúa como señal actuante; la señal actuante controla el proceso de tal forma que la variable controlada se desempeñe de acuerdo
con estándares preestablecidos. En los casos simples, el controlador puede ser un
amplificador, unión mecánica, filtro u otro elemento de control. En los casos mas
complejos el controlador puede ser una computadora tal como un microprocesador.
Debido a la simplicidad y economía de los sistemas de control en lazo abierto, se
les encuentra en muchas aplicaciones no críticas.
2.2.2.2.
Sistemas de control en lazo cerrado
(Sistemas de control retroalimentado). Un sistema de control en lazo abierto sería
más exacto y adaptable si tuviera una conexión o retroalimentación desde la salida
hacia la entrada del sistema. En este caso, la señal controlada debe ser retroalimentada y comparada con la entrada de referencia, enviando una señal actuante proporcional a la diferencia de la entrada y la salida a través del sistema para reevaluar
el proceso realizado. Un sistema con una o más trayectorias de retroalimentación
como el que se acaba de describir se denomina sistema en lazo cerrado.
22
2.2.2.3.
Retroalimentación
La retroalimentación se usa para reducir los errores de la entrada de referencia y
la salida del sistema. La reducción del error del sistema es uno de los efectos más
importantes que se puede realizar sobre el sistema. Para evaluar los efectos de la retroalimentación sobre un sistema de control, es esencial examinar el fenómeno en
un sentido más amplio: cuando ésta es aplicada en forma deliberada para propósitos
de control, su existencia se identifica fácilmente. Sin embargo, existen numerosas
situaciones en donde un sistema físico, que normalmente se reconocería como un
sistema inherentemente no realimentado, se puede volver uno cuando se observan
variables distintas. En general, cuando una secuencia cerrada de relaciones causaefecto existe entre las variables de un sistema, se dice que existe retroalimentación.
2.2.2.4.
Tipos de sistemas
Los sistemas de control realimentados se pueden clasificar en diversas formas, dependiendo del propósito de la clasificación. Por ejemplo, de acuerdo con el método
de análisis y diseño, los sistemas de control se clasifican en lineales y no lineales,
variantes o invariantes con el tiempo. De acuerdo con los tipos de señales usados
en el sistema, se hace referencia a sistemas en tiempo continuo y en tiempo discreto, o sistemas modulados y no modulados. A menudo, los sistemas de control se
clasifican de acuerdo a su propósito principal. Por ejemplo, un sistema de control
de posición y un sistema de velocidad controlan las variables de salida de posición
y velocidad, como sus nombres lo indican.
23
2.3. Procesamiento digital de señales
De acuerdo a la definición de [SWS99], el procesamiento digital de señales (DSP2
sigla en inglés) es distinguido de otras áreas en ciencias de la computación por el
tipo único de datos que usa: señales digitales. En muchos casos, estas señales se
originan como datos observados en el mundo real: vibraciones sismológicas, imágenes visuales, ondas de sonido, etc. DSP comprende la matemática, los algoritmos
y las técnicas usadas para manipular estas señales después de su conversión en forma digital. Este procesamiento tiene diversas aplicaciones, como: mejoramiento
de imágenes visuales, reconocimiento y generación del habla, compresión de datos
para almacenamiento y transmisión, entre otros.
La parte más importante del cualquier aplicación de DSP es entender cómo la información está contenida en las señales con las que se está trabajando, ya que pueden
existir muchas formas, ésto es especialmente cierto si la señal es artificial.
Por lo general, las señales se presentan en el mundo real como flujos continuos
de información. Para que estas señales sean procesadas en sistemas de cómputo,
se realiza un proceso denominado digitalización, donde la señal original (análoga)
se representa por un conjunto discreto de valores (digital). El proceso de conversión análogo a digital presenta una pérdida de datos, pero dependiendo del sistema
observado la señal digital podrá representar fidedígnamente la señal análoga. Esta
conversión es favorable puesto que el conjunto discreto de datos se puede procesar
2 (Digital
Signal Processing) Procesamiento digital de señales. Hace referencia al conjunto de
técnicas y métodos utilizados para el procesamiento matemático, estadístico o algorítmico que sufra
un arreglo numérico correspondiente a una señal digital.
24
con algoritmos y otras técnicas matemáticas que puedan ejecutarse sobre procesadores computarizados. El proceso de digitalización se describe en la Figura 2.1.
2.3.1.
El efecto del ruido
En observación de señales del mundo real, es común encontrar que la señal observada es una composición de varias, producto de variables externas que inciden en
el objeto de estudio, es decir, la señal observada tiene inmersa la señal que se desea
obtener, más otras señales de poco o nulo interés; a estas señales se les denominan
regularmente ruido. Hay diversos tipos de ruido, los cuales se pueden catalogar
dependiendo de los entes que lo generen (eléctricos, mecánicos, seres vivos). De
acuerdo a los elementos con los cuales se recolecte la señal, los niveles de ruido
pueden variar; también puede existir como representación de otro tipo de información que se encuentra en el ambiente, pero que no es de interés para el estudio
realizado.
2.3.2.
Filtrado
El filtrado es una operación que consiste en extraer de una señal observada, la
señal útil al observador : se pueden citar como ejemplos la extracción de una señal
inmersa en ruido o la estimación de la derivada de una señal con ruido. [SS99]
Si la operación realizada es lineal e invariante, se dirá que se hace un filtrado
lineal : el filtro será un sistema dinámico lineal.
Si el mensaje y la señal son continuos, el filtro es continuo o analógico. Si
25
Figura 2.1: Conversión análogo/digital
26
al contrario el mensaje y la señal útiles son discretas o discretizadas se dirá
que el filtro es digital. Según el método de síntesis se puede tener:
• filtro temporal; el filtro es especificado a partir de las características
temporales.
• filtro de frecuencias; las características del filtro están dadas por su
respuesta en frecuencia.
• filtrado óptimo; si la síntesis hace intervenir un criterio de optimización.
• filtrado estocástico o determinista; si el estudio del filtro hace o no intervenir señales aleatorias, su representación y su cálculo de probabilidades. Desde un punto de vista práctico se distingue el filtrado en
tiempo real del filtrado a tiempo diferido.
2.4.
Redes de estaciones
Esta sección trata sobre la composición y distribución de una estructura que denominaremos red, de acuerdo a [LEE91]. En general, una red puede ser vista como un
conjunto de nodos enlazados entre sí por medio de aristas. Para cada aplicación real
los nodos y las aristas tienen significado: una red telefónica tiene como aristas los
cables o líneas de interconexión físicas o inalámbricas; los nodos corresponderían
a los puntos donde se conectan los equipos telefónicos (celulares, fax, teléfonos).
Otro ejemplo, un poco más general, lo constituye un conjunto de estaciones actuando como nodos, un medio de transmisión o interconexión como aristas y una
señal como mensaje. Este concepto puede aplicarse a un sistema concreto como la
27
sismología.
2.4.1.
Estaciones de registro
Para un caso más particular de red, se tiene una estación de registro como un nodo
fuente de información, es decir, captura o genera información por sí mismo y la
transmite por las aristas al resto de la red.
Una estación de registro sismológico contiene básicamente uno o varios sensores,
un amplificador de señal y una unidad transmisora; alternativamente la estación
puede realizar el proceso de digitalización, almacenamiento y procesamiento de la
señal.
2.4.1.1.
Sensores
Un sensor es un dispositivo eléctrico, mecánico, físico o químico que mide una o
varias variables sobre un ambiente u objeto. El propósito de un sensor es hacer una
cuantificación de una o más variables regularmente en función del tiempo.
2.4.1.2.
Transmisión de datos
Es el proceso de envío de un conjunto de datos desde un origen a un destino utilizando un medio. Con los avances en los sistemas de comunicación se tienen diversas alternativas para realizar transmisión remota o local de información.
28
2.4.2.
Topologías de red
Una red sismológica es un sistema de observación sísmica compuesto por un grupo
de estaciones. Cada una contiene básicamente un sensor, que puede ser de movimiento, velocidad o aceleración y componentes electrónicos para realizar el registro de la señal en algún medio, más los mecanismos para transmitir la información.
Estas estaciones por lo general se localizan en sitios geográficos donde existen
bajos niveles de ruido generado por factores distintos al terrestre (carreteras, ciudades) y bajo condiciones geológicas específicas. Una red sismológica puede estar
compuesta de estaciones no telemetradas, o telemetradas utilizando diversas tipos
de tecnologías.
Estaciones telemetradas: indica si las estaciones realizan envío de los datos registrados a un punto geográfico distinto, a través de algún sistema de comunicación,
para su almacenamiento o procesamiento en una estación central donde se reuna
con la información de otras estaciones. Esta transmisión permite obtener registros
sísmicos de varias estaciones en muy corto tiempo; la información tomada en un
instante de tiempo se transmite instantáneamente, por lo cual se considera como
un sistema de funcionamiento online, es decir, a medida que se va generando la
información es enviada para su análisis. En la Figura 2.2, se indica la distribución
geográfica de estaciones sismológicas de la red del sur-occidente del OSSO.
Estaciones no telemetradas: cada estación realiza almacenamiento local de la
información tomada, algunas pueden realizar procesamiento sobre los datos. Este
caso en sismología no es comúnmente usado para localización de eventos en corto
29
tiempo, por lo tanto se considera de funcionamiento fuera de linea (offline). A pesar
que la señal está referida con el tiempo en el que se produjo, se almacena para su
posterior análisis.
Una red sismológica puede contener estaciones telemetradas y no telemetradas. Para su análisis digital, se discretiza esta información, usando un elemento de hardware denominado conversor Análogo-Digital. Este conversor aproxima una señal
análoga a digital con un nivel de resolución, definido por el número de muestras
por segundo que se toman.
La señal digital registrada debe estar referida a un momento exacto en el tiempo,
ya que es necesario para determinar, en caso de eventos sísmicos, parámetros como
el sitio geográfico, profundidad, etc. Para tener un valor de referencia común del
tiempo se utiliza un sistema de posicionamiento global (GPS por su sigla en inglés).
2.4.3.
Procesamiento de señales sísmicas
Con los datos recopilados por la red de estaciones, se realiza el análisis sismológico para extraer información sobre las señales. Un evento se denomina de manera
general la ocurrencia de movimiento sísmico. El proceso de detección de eventos
es una de las etapas del proceso de observación, en la cual se desea conocer el
momento en el tiempo donde se ha registrado un evento. A partir de este momento
se pueden identificar los parámetros epicentrales realizando el proceso de localización del evento.
30
(Fuente Catálogo digital OSSO 2002)
Figura 2.2: Distribución de las estaciones sismológicas del OSSO.
31
Detección de eventos
La detección de eventos es el procedimiento para encontrar el tiempo aproximado de inicio de un movimiento terrestre con una red sísmica. Una lista de eventos
corresponde a una tabla en orden cronológico, con los tiempos de los eventos registrados. Si un movimiento regional o telesísmico es detectado y procesado, también
podrá ser incluido en la lista. Este procesamiento se realiza por métodos visuales,
automáticos o semiautomáticos.
Localización de eventos
La localización de eventos corresponde a la identificación de los parámetros de
magnitud, profundidad y posición geográfica, junto a grado de error y calidad de
la solución, entre otros. Figura 2.3.
(Tomado de New Manual of Seismological Observatory Practice)
Figura 2.3: Localización de eventos.
Según [RC92], en el dominio sismológico un sistema automático debe cumplir 4
tareas principales:
1.
Detección de señales: precisión para identificar y rechazar trazas de ruido
32
realzando la relación Señal - Ruido (SNR)
2. Extracción de características y reconocimiento de fases: características
básicas como tiempo de arribo, amplitud, frecuencia dominante y duración
son extraídas de las señales detectadas.
3. Análisis asociativo: La idea de detectar señales y tentativamente interpretar
fases, es analizada luego con la información de todas las estaciones de la red.
Esto valida y mejora la etapa de reconocimiento de fases; la identificación
de un evento candidato se hace desde sismogramas candidatos consistentes;
fases pertenecientes a sismogramas menos claros, no son tomados en cuenta.
4. Estimación de parámetros: El evento es localizado en espacio y tiempo
(coordenadas hipocentrales: latitud, longitud, profundidad, tiempo de origen) y cuantificado utilizando escalas de valores aproximados, denominados
magnitud.
2.4.4.
Otros casos de consideración
Para extender la idea de los casos de redes de estaciones y procesamiento de señales
se pueden considerar algunos casos, sobre los cuales se realizará una aproximación
en cuanto a su funcionamiento y acoplamiento a la estructura de red presentada. El
sistema de procesamiento es visto para estos casos como un sistema especializado
para cada caso, así como el término de manejo de eventualidades, como el mecanismo accionador del sistema.
33
2.4.4.1.
Electrocardiógrafo digital
Un electrocardiógrafo simple consta de tres electrodos o sensores de diferencia
de potencial que miden pequeños niveles de voltaje en tres puntos alejados de un
organismo. La información obtenida en un lapso de tiempo es considerada señal
o electrocardiograma, la cual puede ser interpretada por expertos o procesada por
software especializado.
En términos generales el comportamiento de este sistema puede ser visto como
una serie de estaciones o electrodos, cada uno censando datos físicos, los cuales
serán procesados por un sistema central en busca de eventualidades propias de las
situaciones médicas relacionadas.
2.4.4.2.
Sistemas de seguridad física
Algunos sistemas antirrobo están basados en un mecanismo de verificación de espacio o de apertura de pasadores. Por ejemplo un sistema de seguridad física en
una empresa puede consistir en un conjunto de cámaras digitales que se activen
en horas de inactividad laboral, cada cámara tendrá un espacio visual que, en condiciones normales, no varía o varía muy poco. Para el caso del modelo de redes
de estaciones, las cámaras interconectadas a un sistema central corresponden al
conjunto de estaciones, la presencia de una eventualidad o cambio no considerado dentro del comportamiento del sistema puede considerarse, para este caso, una
alerta de seguridad, de acuerdo como se tenga establecido en el sistema de procesamiento de las señales.
34
2.4.4.3.
Control de temperatura
Para un sistema de control de temperatura basado en información obtenida de termómetros, es posible acoplar el mismo sistema descrito en los casos anteriores,
bajo el esquema de redes de estaciones (termómetros) incorporados a un sistema
centralizado que procese las señales y determine los casos donde ocurran eventualidades en el entorno del problema específico.
2.5.
Sistemas en tiempo real
2.5.1.
Diseño en tiempo real
Como requerimientos fundamentales de un sistema de tiempo real se tiene no solo su correcto funcionamiento, sinó también su principal atributo de control : el
tiempo. El sistema deberá entregar respuesta en un lapso de tiempo máximo establecido, a impulsos predeterminados o calculados.
De acuerdo a la aplicación final del sistema existen diversos tipos [JHC00]:
Por restricciones de tiempo
Sistemas de Tiempo Real Blandos:
Sistemas que a pesar de tener restricciones de tiempo real, es aceptable
que los límites de tiempo no se cumplan siempre.
Sistemas de Tiempo Real Duros:
Es indispensable el cumplimiento de las restricciones temporales impuestas, aún a costa de disminuir las funciones que el sistema es capaz
de desarrollar.
35
Por las escalas de tiempo:
Respuesta en la ejecución de las tareas del sistema frente a los eventos externos
que ocurren.
Sistemas basados en Reloj:
Existencia de una señal periódica que desencadena la ejecución de las
operaciones del sistema.
Sistemas basados en Eventos:
Las actividades son ejecutadas cuando ocurre un evento o condición
que activa el sistema.
Por la integración con el sistema físico:
Por el entorno en el cual se ejecuta el sistema:
Sistemas embebidos
Se usan para controlar hardware especializado, en este caso el software que se instala es específico para controlar un tipo particular de
hardware (firmware3 ).
Sistemas no embebidos
Estos son sistemas en donde el software no está directamente integrado
al hardware, pueden a su vez clasificarse como acoplados o débilmente acoplados según el grado de dependencia del software respecto al
hardware sobre el cual puede correr.
3 Software almacenado en memoria de solo lectura (ROM) o sobre ROM programable, generalmente utilizado para hardware programable.
36
2.5.2.
Adquisición digital de datos
Los procesos de adquisición y procesamiento de datos modernos, realizan la captura de datos por dispositivos de hardware especializados para esta tarea, operados
por firmware o equipos de cómputo de propósito general, operados por software.
El proceso de adquisición tiene restricciones en cuanto al tiempo, la precisión de
los datos y la transmisión de la información a otros módulos para el almacenamiento y procesamiento, por eso se considera un sistema de adquisición de datos
en linea un sistema de tiempo real duro, ya que se debe garantizar la recepción de
la información en lapsos de tiempo determinados, ya sea para almacenamiento o
para otros servicios.
La adquisición digital de datos, no es proceso exclusivo de la sismología. Se puede
presentar en procesos industriales automáticos, receptores de radar o telecomunicaciones. Un esquema general del flujo de la información se muestra en la Figura
2.4.
El proceso de adquisición es independiente de los procesos de recepción y transmisión de datos, sin embargo se deben conocer los tiempos de retraso ocasionados
por la transmisión remota, así como el tipo de datos que llegan a cada canal de
entrada.
La adquisición digital sobre un computador, consiste en el almacenamiento en memoria principal o secundaria de un conjunto de datos con un formato específico
durante un periodo de tiempo. Generalmente se tienen varios canales de adquisi37
Figura 2.4: Adquisición digital
ción. La adquisición digital puede tener una etapa previa dependiendo de la señal.
Si ésta es análoga, se debe realizar la conversión o discretización de ésta. Este proceso de conversión análogo-digital es realizado por hardware dedicado conocido
como conversores A/D (análogo/digital), los cuales se encuentran limitados por el
número de muestras por segundo que pueden recibir y por el nivel de resolución de
cada dato medido en bits.
2.5.3.
Estructuras de datos
La señal discretizada puede ya ser procesada en el computador. El procesamiento
es un proceso específico del análisis realizado. Los datos que han sido adquiridos
deben tener un formato claro que permita su interpretación.
El formato que encapsula la señal, será determinado por el programa. Básicamente
se debe especificar cual es la tasa de muestreo, la referencia de tiempo, la fuente de
los datos y un flujo de datos a procesar. Esta información se encuentra en algún me38
dio de almacenamiento digital y se accede bajo una estructura de almacenamiento
circular que permita la disponibilidad continua de datos. Como característica asociada a la estructura de datos se debe tener en cuenta que la permanencia de la
señal en el medio tiene un periodo de permanencia, regularmente corto, lo cual indica que otros procesos deben atender esta información antes de ser reemplazada
por nuevos datos.
2.5.4.
Referencia a la señal de tiempo
La localización de eventos sísmicos requiere una buena precisión del tiempo en que
las señales se están registrando. Para tener una referencia global de tiempo se usa
un sistema de posicionamiento global (GPS), el cual capta determinadas señales
de satélites artificiales geoestacionarios para determinar datos como la posición
geográfica y un valor de tiempo en meridiano 0 (Hora UTC). Con este sistema se
asigna el tiempo que acompaña la señal obtenida, regularmente manejada con una
precisión de décimas o centésimas de segundo.
2.5.5.
Tiempo de respuesta
Un sistema adecuado a los requerimientos de entrada y salida de datos debe considerar un tiempo de respuesta máximo, que permita atender las peticiones de recepción de datos y transferencia a otros procesos que los soliciten. Por otra parte
se debe garantizar que las operaciones de procesamiento de datos cumplan con
tiempos máximos de respuesta, admisibles por los requerimientos del sistema.
39
2.6. Detección y clasificación de señales
Un detector es un sistema que identifica la ocurrencia de cambios abruptos sobre
una señal. De manera general se busca conocer el momento en el cual la señal
presenta una cambio en su amplitud, tratando de evitar las condiciones de ruido.
Según [CHT98], los cuatro principales problemas de la detectabilidad de eventos
son:
Diferenciación entre señal débil y formas de onda con ruido puro.
Errores en la señal y modelos de ruido como resultados de disimilaridades
de onda P (tiempo de llegada del primer cambio abrupto o inicio del evento
sísmico), a través del arreglo.
Alta probabilidad de activación del detector de eventos por falsas alarmas y
ruido
Fluctuaciones del nivel de ruido o dependencia de frecuencia de relación
señal-ruido (SNR).
2.6.1.
Detección STA/LTA
Short Term Average / Large Term Average.
STA/LTA es un algoritmo de detección de cambios que se activa frente a la relación
de la amplitud de la señal en dos ventanas de tiempo. Es utilizado en sismología
porque regularmente no presenta alteraciones debido a la amplitud del ruido ajustando automáticamente la sensibilidad de las estaciones sísmicas a los actuales
40
niveles de ruido. Como resultado, provee una alta sensibilidad del sistema durante periodos de quietud sísmica y logra prevenir un número excesivo de alarmas
sísmicas, o al menos mitiga durante periodos de ruido sísmico. Los cálculos son
repetidamente ejecutados en tiempo real. Este proceso s realizado, por lo general,
independientemente de todos los canales de una estación sismológica o de una red
sísmica.
El algoritmo procesa señales sísmicas filtradas en dos ventanas de tiempo: una corta, de promedio de tiempo (STA) y otra larga con su promedio de tiempo (LTA). El
STA mide el ’instante’ de la señal sísmica e inspecciona ocurrencia de terremotos.
El LTA toma nota del actual promedio de amplitud del ruido.[SRC00]
Primero, se calcula la amplitud absoluta de cada muestra de datos. Luego se realiza para el promedio de amplitud absoluta en ambas ventanas. En un paso posterior
se calcula una razón de ambos valores (radio STA/LTA). Esta razón se compara
continuamente comparado con un valor seleccionado por el usuario: umbral de detección STA/LTA. Si el radio excede este umbral, un canal de ocurrencia de evento
será declarado. Este no necesariamente es el medio para que un grupo de canales
o red sísmica inicie un registro de señal sísmica. Todas las redes sísmicas y muchos registros sísmicos tiene un mecanismo para determinar la activación (trigger4 )
del sistema, basado en que varios canales presentan la condición de ocurrencia de
evento antes de que el instrumento o la red inicien el registro de datos. Después que
la señal gradualmente termina, se dá la condición de parada (detrigger). El usuario
puede determinar una condición de parada, la cual será menor o igual que la dada
4 Trigger
: condición de disparo o alerta sobre una señal ante la presencia de cambios abruptos.
41
para la condición de activación.
Adicionalmente a los datos adquiridos entre los tiempos de activación y de parada,
las redes sísmicas y las estaciones entregan una gran cantidad de datos antes del
trigger - datos del pre-evento (PEM). Después de que la condición de trigger termina, se toman los datos de post-evento (PET). La Figura 2.5 muestra la disposición
de estas variables sobre un segmento de señal:
Figura 2.5: STA/LTA
2.6.2.
Estimación de parámetros sobre la señal.
La estimación de parámetros en señal sísmica o extracción de características, es un
proceso de análisis preliminar de datos partiendo de un conjunto de reglas preestablecidas en el sistema, así como de un proceso de aprendizaje sobre el comportamiento de un grupo de señales. Unas cuantas técnicas en procesamiento de señales
son aplicables para estimar características tradicionales de señales sismológicas,
tales como amplitud sísmica, periodo y otros aspectos del reconocimiento de señales.
42
2.6.3.
Mecanismos de detección
De acuerdo a [FH98] y [CHT98], existen diversos métodos para determinar la ocurrencia de eventos. Algunos de ellos son:
Detector telesísmico
Enfocados hacia la detección de eventos lejanos a la zona de cobertura de la red de
estaciones. Por lo general son eventos de gran magnitud (mayores de 5 grados en
la escala de Richter).
Detector por estimación espectral
Obtienen funciones y valores de la señal en términos del espectro generalmente
calculado como una transformada.
Detector basado en filtros
Aplicación de algoritmos matemáticos y pseudo-matemáticos para la transformación de las señales en otras que representen de manera más aproximada el comportamiento real del sistema.
Detector estadístico
Se tienen de dos tipos principalmente, de comportamiento aproximado o según
alguna distribución estadística y basados en métodos Bayesianos, los cuales son
una aplicación del teorema de Bayes.
43
2.6.4.
Wavelets
Las técnicas de análisis wavelet emplean regiones de tamaño variable, para el análisis de las señales deja usar durante largo tiempo intervalos donde se necesita mucha
información que precisa poca frecuencia y pequeñas regiones donde la información
necesita altas frecuencias. El análisis wavelet es capaz de mostrar aspectos de la señal que otras técnicas no logran encontrar [SPIHT].
2.6.4.1.
Transformada Wavelet
La transformada wavelet consiste en comparar la señal con ciertas funciones wavelet, las cuales se obtienen a partir de las wavelet madre. La comparación permite
obtener unos coeficientes que son susceptibles de interpretación y posterior manipulación. En cualquier caso, un requisito básico es la posibilidad de invertir la
transformada, recuperando la señal a partir de esos coeficientes wavelet calculados.
2.6.4.2.
Transformada Wavelet Discreta (DWT)
El cálculo de la transformada wavelet para todas las posibles escalas supone una
gran cantidad de información. Escoger solo aquellas escalas y posiciones que resulten interesantes para ciertos estudios es una tarea difícil. Si se escogen aquellas
escalas y posiciones basadas en potencias de dos, los resultados serán más eficaces.
Este análisis se denomina DWT.
Para muchas señales la información más importante se encuentra en las frecuencias
bajas, mientras que en las altas frecuencias se encuentran los detalles o matices de
44
la señal. Por ejemplo, en el caso de la voz humana, si se eliminan los componentes
con altas frecuencias, la voz suena diferente pero se sigue entendiendo su mensaje. En cambio, si lo que se elimina son las componentes de bajas frecuencias, el
mensaje se vuelve irreconocible. Por eso el análisis wavelet permite descomponer
la señal en aproximaciones y detalles, a este proceso se le conoce con el nombre
de análisis.
2.7.
Inteligencia artificial en DSP
La Inteligencia Artificial (AI por su sigla en Inglés) es una de las áreas de las
ciencias de la computación encargadas del desarrollo de software o equivalente,
que presente comportamientos inteligentes. Regularmente la AI es utilizada para
resolver problemas cuyas soluciones no son obtenidas mediante el cómputo, para
lo cual utiliza métodos de búsqueda de soluciones factibles al problema, en un
conjunto de soluciones válidas. En el campo específico del Procesamiento Digital
de Señales, la información que representan las señales puede no ser fácilmente
procesada con algoritmos deterministas. Estos casos son más frecuentes si se tiene
en cuenta la naturaleza de las señales: ambientes del mundo real, donde las señales
se comportan como una combinación de múltiples fuentes de datos.
2.7.1.
Reconocimiento de patrones
El Reconocimiento de Patrones es un área de la tecnología conocida como Aprendizaje de Máquinas (Machine Learning) o Aprendizaje Automático. El único propósito de este método es clasificar un grupo de patrones conocido como conjunto
de pruebas en dos o mas clases de categorías. Esto es posible al calcular las ca45
tegorías del conjunto en prueba comparándolo con un conjunto de entrenamiento
previo (training set). Un clasificador dado mide la distancia entre varios puntos dados (compara), para saber cuales puntos son mas cercanos a la meta en un modelo
parametrizado [JK02].
También se puede definir Reconocimiento de Patrones como el acto de tomar datos
sin ningún sentido y clasificarlos de acuerdo a una acción basada en las categorías de un patrón dado o previamente analizado. Las operaciones en un sistema de
reconocimiento son las siguientes :
Sensado : toma de información de sensores5 .
Segmentación y Agrupamiento : La operación de segmentación ocurre
cuando el sistema determina que un elemento, objeto o muestra finaliza y
da comienzo a otro.
Extracción de Características : La meta del extractor es caracterizar un
objeto con medidas o cualidades cuyos “valores” tienden a ser similares.
Clasificación: El objetivo en la operación de clasificación es utilizar un “vector” con las características provistas por el extractor para asignar el objeto
(patrón) de la entrada a una categoría.
Procesamiento a Posteriori: En un clasificador raramente existe la clasificación nula, sin embargo en muchos casos es utilizada para recomendar
5 Sensor: dispositivo físico, mecánico, químico o electrónico que entrega datos sobre el comportamiento de un objeto de estudio.
46
decisiones y acciones que dependen de un costo o riesgo particular. El procesamiento a posteriori se utiliza en la descarga o resultado del clasificador
para recomendar una acción.
2.7.2.
Redes Neuronales
Emulando la estructura biológica del cerebro humano, las técnicas de redes neuronales modelan las neuronas como unidades de proceso. Cada unidad de proceso se
compone de una red de conexiones de entrada, una función de red ( de propagación), encargada de computar la entrada total combinada de todas las conexiones,
un núcleo central de proceso, encargado de aplicar la función de activación, y la
salida, por dónde se transmite el valor de activación a otras unidades.[BM01]
La función de red es típicamente el sumatorio ponderado, mientras que la función
de activación suele ser alguna función de umbral o una función sigmoidal.
Función de propagación o de red: Calcula el valor de base o entrada total a
la unidad, generalmente como simple suma ponderada de todas las entradas
recibidas, es decir, de las entradas multiplicadas por el peso o valor de las conexiones. Equivale a la combinación de las señales excitatorias e inhibitorias
de las neuronas biológicas.
Función de activación: Es quizás la característica principal o definitoria de
las neuronas, la que mejor define el comportamiento de la misma. Se usan
diferentes tipos de funciones, desde simples funciones simples de umbral a
funciones no lineales. Se encarga de calcular el nivel o estado de activación
de la neurona en función de la entrada total.
47
Conexiones ponderadas: hacen el papel de las conexiones sinápticas, el peso de la conexión equivale a la fuerza o efectividad de la sinápsis. Las existencia de conexiones determina si es posible que una unidad influya sobre
otra, el valor de los pesos y el signo de los mismos definen el tipo (excitatorio/inhibitorio) y la intensidad de la influencia.
Salida: calcula la salida de la neurona en función de la activación de la misma, aunque normalmente no se aplica más que la función identidad, y se
toma como salida el valor de activación. El valor de salida cumpliría la función de la tasa de disparo en las neuronas biológicas.
La idea detrás del proceso consiste en que las neuronas codifican criterios de operación, durante el periodo de ejecución de la red neuronal las conexiones se van
reasignando como de mayor o menor peso, según la respuesta de la red a los estímulos de nuevos datos de entrada. El resultado de todo el proceso se entrega como
la unidad de salida.
Aunque inicialmente se desarrollaron redes de una sola capa, lo más usual es disponer de tres o más capas: la primera capa actúa como almacenamiento de entrada,
conteniendo la información bruta suministrada a la red o realizando un sencillo
pre-proceso de la misma, se denomina capa de entrada; otra capa actúa como interfaz o espacio de salida, almacenando la respuesta de la red para que pueda ser
leída, llamada capa de salida; y las capas intermedias, principales encargadas de
extraer, procesar y memorizar la información, se conoce como capas ocultas.
Como parte de los procesos de implementación de la red neuronal se realiza la etapa
48
de aprendizaje, la cual le permitirá a la red establecer sus valores de operación. El
aprendizaje de una red se puede producir de tres formas:
Aprendizaje supervisado: consiste en introducir una serie de patrones de
entrada a la red y a su vez mostrar la salida que se quiere tener. La red
es capaz de ajustar los pesos de las neuronas de forma que a la presentación
posterior de esos patrones de entrada la red responde con salida memorizada.
Aprendizaje no supervisado: se presentan los patrones de entrada a la red
y ésta los clasifica en categorías según sus rasgos más sobresalientes.
Aprendizaje autosupervisado: la propia red corrige los errores en la interpretación empleando una realimentación.
El uso de las redes neuronales en procesamiento de señales aprovecha la capacidad
de aprendizaje y adaptabilidad de estas técnicas, mostrando buenos resultados en
su aplicación como filtros digitales sobre la señal y como mecanismo de aplicación
de reconocimiento de patrones. La utilización de las técnicas de redes neuronales
es conveniente cuando el comportamiento de las señales no presentan patrones o
comportamientos predecibles o ajustables a un comportamiento del entorno. Con
la utilización de técnicas supervisadas de aprendizaje, una red entrenada puede
clasificar uno o varios segmentos de señal en grupos establecidos de acuerdo a
características comunes.
2.7.3.
Algoritmos genéticos
Son basados en modelos computacionales de procesos evolucionarios fundamentales como la selección, recombinación y mutación. Son codificados como palabras
49
compuestas sobre algunos alfabetos y una población inicial producida por muestras aleatorias de estas palabras. Una vez la población ha sido producida, puede ser
evaluada usando una función objetivo con características individuales del dominio
del problema. La función objetivo es también usada como la base para la selección
y determina la eficiencia de un individuo en este ambiente. Estos procesos de selección, reproducción y evaluación son repetidos hasta un criterio de terminación
determinado. Por ejemplo, cierto número de generaciones, una desviación promedio en la eficiencia de los individuos de la población o cuando un punto particular
en el espacio de búsqueda es encontrado.
2.7.4.
Otras técnicas
KDD
KDD (Knowledge Discover on Databases) o Descubrimiento de conocimiento en
bases de datos en una área mixta de trabajo de las bases de datos, la inteligencia
artificial y la estadística. Básicamente busca extraer información oculta en bases de
datos con gran cantidad de registros; se pretende conocer comportamientos o patrones de interés que surjan de los datos. Las técnicas de KDD permiten reconocer
reglas que se presentan “de manera natural” en los datos, organizándolos como patrones o reglas. Para que estas reglas se consideren válidas es necesario contar con
gran cantidad de datos que sustenten su aprobación. Para el caso del procesamiento
de señales la aplicación del KDD es factible. Sin embargo, el procesamiento de tal
cantidad de información impediría tener un tiempo de respuesta adecuado para el
sistema, por lo cual su uso en este tipo de aplicaciones no es muy extendido en
procesamiento de señales.
50
Investigación de Operaciones
Aplicados a problemas de optimización, los modelos matemáticos de la investigación de operaciones pueden usarse en determinadas etapas del procesamiento
de señales a fin de encontrar valores óptimos y valores máximos o mínimos. Estas técnicas son usadas en diversos campos del conocimiento, donde el conjunto de
variables de búsqueda y el número de datos de entrada no son muy extensos y se encuentran claramente definidos en el contexto de cada problema. Para la resolución
de este tipo de problemas, se debe tener en cuenta las limitaciones computacionales
que pueda tener una posible implementación, debido a que algunos planteamientos
podrían no ser determinados o requerirían muchos recursos de procesamiento.
2.8.
Desarrollo de proyectos de software
La Ingeniería de Software se define como “la rama de la ingeniería que aplica los
principios de la ciencia de la computación y las matemáticas para lograr soluciones
costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de
software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos". Como cualquier proyecto de ingeniería moderna, el software se construye de acuerdo a las posibilidades técnicas y la factibilidad de los
recursos disponibles para hacerlo. Para dimensionar el desarrollo de un producto
de software es necesario realizar la planeación general del proyecto, como proyecto de Ingeniería, así como considerar su análisis y diseño dentro de los principios
de desarrollo de la Ingeniería de Software.
51
2.8.1.
Ciclo de vida de desarrollo
De acuerdo a la norma [ISO12207-1], se puede describir un ciclo de vida de desarrollo de software como “Un marco de referencia que contiene los procesos, las
actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso”.
Los procesos del ciclo de vida de desarrollo de software se muestran en la Tabla2.1,
de acuerdo a [RSP98]. Esta estructura basada en procesos, agrupa como fases generales las actividades a realizar para la construcción de software. Existen diversos
enfoques para aplicar las etapas de elaboración; el criterio de escogencia entre los
ciclos de vida para el desarrollo, lo otorga a nivel general los requerimientos del
problema, así como las características del entorno de desarrollo y utilización del
producto.
2.8.2. Bases del desarrollo de software
Tomando el esquema propuesto por [SM96], las bases del desarrollo de software
se pueden dividir en :
2.8.2.1.
Bases de gestión
Realizar gestión sobre el desarrollo de software, consiste básicamente en dimensionar el producto, en términos de funcionalidad, complejidad, recursos, actividades,
entre otros. Como etapas de la gestión se tienen los procesos de estimación, planificación y seguimiento.
52
1. Estimación: corresponde a la cuantificación que se considera sobre el proyecto.
a) Estimación del tamaño: se realiza entre otros por puntos de función
o en líneas de código. Los puntos de función son indicadores de valor (puntos) de acuerdo a los componentes del producto. Las líneas de
código son una medida estándar de la extensión del producto.
b) Estimación del esfuerzo: con base en la estimación del tamaño y con
experiencias previas similares, se puede considerar dedicación de personal / tiempo.
c) Estimación de la planificación: realizando la estimación de tamaño y
esfuerzo es posible estimar la duración y distribución del proyecto en
el tiempo.
2.
Planificación:
a) Selección y organización del personal: en referencia a los perfiles del
personal de desarrollo y de planificación.
b) Elección del modelo de ciclo de vida a utilizar: identificar el modelo
que mejor se adapte a las condiciones del proyecto y al entorno del
desarrollo.
c) Gestión de riesgos: La función de la gestión de riesgos es la de identificar, estudiar y eliminar las fuentes de riesgo antes de que empiecen a
amenazar la planificación del proyecto.
Estimación de riesgos: Identificación, análisis y priorización de
riesgos.
53
Control de riesgos: Planificación, resolución y monitorización de
riesgos.
3.
Seguimiento: verificación constante de la ejecución del proyecto. Constituye las revisiones técnicas y cumplimiento de los parámetros de calidad, así
como la demarcación de puntos cruciales para el proyecto.
4.
Medición: La medición es un proceso enfocado hacia el desarrollador. En
general busca recopilar datos sobre la planificación y envergadura del proyecto, a fin de estimar otros proyectos a futuro.
2.8.2.2.
Bases técnicas
Desde el punto de vista del desarrollo técnico del proyecto de software, se pueden
considerar:
1.
Gestión de requerimientos: corresponde a identificar los requerimientos de
los actores del proceso de desarrollo, organizándolos de acuerdo a una metodología que permita reflejar lo mejor posible las necesidades y características
del entorno de desarrollo.
2.
Diseño: Conceptos de modularidad y ocultamiento de información. Consideraciones de diseño propios del dominio de la aplicación.
3.
Construcción: Establecimiento de prioridades en el proceso de codificación.
Reglas y métodos para generación de código.
4.
Gestión de configuración: (Software Configuration Manager) Incluye métodos para evaluar cambios propuestos, continuar los cambios, manejar va54
rias versiones y guardar copias de la evolución de los artefactos del proyecto.
Los artefactos corresponden a todas los componentes utilizados en la fase de
codificación.
2.8.2.3.
Bases de control de calidad
Las bases de control de calidad permiten establecer un control sobre la funcionalidad real del producto, buscando minimizar a futuro la corrección de defectos.
1. Módulos propensos a errores: por lo general están ligados a la falta de
prueba por presiones de tiempo o a deficiencias técnicas en los estilos de
codificación.
2. Prueba: realización de pruebas del código (desarrollador) y sobre el funcionamiento del sistema. La intención de la prueba es detectar fallos sobre el
producto o sus componentes.
3. Revisiones técnicas: corresponde a a cualquier clase de revisiones utilizadas
para detectar defectos en requerimientos, diseño, código, casos de prueba.
2.8.3.
Sistema crítico o con tolerancia a fallos
Como característica fundamental de un sistema crítico se tiene el factor de supervivencia, como la habilidad de un sistema de comunicación o computación para
satisfacer requerimientos como seguridad, confiabilidad, tiempo de respuesta, respuesta a situaciones anormales y corrección de errores. La supervivencia debe ser
definida respecto al conjunto de situaciones adversas que pongan en riesgo la fiabilidad del sistema [RD97], que generalmente ocurre por:
55
Fallos en el hardware.
Imperfecciones en el software.
Ataques sobre sistemas y redes de comunicaciones perpetrados por los usuarios de modo intencional o accidental.
Interferencia electromagnética.
Un sistema crítico de software es visto entonces como un producto de software que
puede prevenir, con alcances y limitaciones, un rango de fallos sobre el software
en ejecución.
Como factores de consideración en el diseño para construcción de software de
seguridad crítica [DG94] se tiene, en primera instancia, 7 factores primordiales:
1.
Calidad y experiencia del personal.
2.
Uso del manejo de configuración
3.
Claridad, estabilidad y validación de los requerimientos del software
4.
Independencia de la verificación y validación
5.
Uso de un ciclo de vida formal para desarrollo del producto
6.
Planificación de los requerimientos y diseño del sistema, a través de los requerimientos, diseño codificación y prueba del software.
7.
Uso de análisis de riesgo y debilidades para guiar el desarrollo.
Adicionalmente 9 factores de diseño son esenciales para la seguridad:
56
1.
Referencia a la calidad
2.
Buen manejo y completa actividad de documentación
3.
Independencia del manejo de la configuración y aseguramiento de la calidad
4.
Mejoramiento continuo del proceso
5.
Medida de los resultados del proceso de desarrollo de software
6.
Disponibilidad suficiente de recursos, apropiado a la dificultad de las tareas
de desarrollo
7.
Un registro sobre el tiempo, el presupuesto, las especificaciones internas del
producto de entrega
8.
Detección y resolución del problema primario
9.
Seguimiento de defectos
57
Procesos principales
Procesos de soporte
Procesos generales
Adquisición
Documentación
Gestión
Suministro
Gestión de la configuración
Infraestructura
Aseguramiento de la calidad
Mejora
Verificación Validación
Formación - Entrenamiento
De
* Análisis
* Diseño
desarrollo * Implementación
* Prueba
* Aceptación
Explotación - Uso
Mantenimiento
Revisión conjunta
Auditoría
Resolución de problemas
Cuadro 2.1: Procesos Ciclo de Vida
58
Capítulo 3
Desarrollo del Modelo
Este capitulo contempla las fases que componen el desarrollo del modelo de sistema crítico para la caracterización de señales. El término caracterización, como
efecto de caracterizar (“Determinar los atributos peculiares de alguien o de algo, de modo que claramente se distinga de los demás”. Real Academia Española
2001). La especificación de los atributos, en este caso de atributos sobre las señales, así como la configuración e interpretación de tales señales corresponde a la
implementación detallada de este modelo.
El modelo propuesto plantea la estructura de elaboración de proyectos de software,
pero estableciendo unos principios de desarrollo alrededor de la planificación, ciclo de vida y sistema de calidad, dejando para establecer en el marco del problema
puntual el análisis y diseño detallado del sistema solución.
Por proyecto se entiende en este capítulo el potencial sistema solución, que se
59
desarrollará como producto de software en etapas posteriores al modelo.
3.1. Planeación del proyecto
Esta primera fase del modelo se contempla el reconocimiento de las necesidades
y los recursos del proyecto a desarrollar. En esta fase se pretende establecer las
características del entorno del sistema, así como la definición de ciertos criterios
generales que se usarán durante todo el desarrollo del proyecto.
3.1.1.
Análisis de factibilidad
Como proyecto de ingeniería, el proyecto a desarrollar debe establecer un grado
de confiabilidad respecto a la viabilidad operacional y económica sobre su elaboración. De acuerdo a la naturaleza del modelo de software crítico, el análisis de
factibilidad permite medir si existen las condiciones para que se pueda desarrollar
un sistema que cumpla con los requerimientos del modelo. Como criterios para
evaluar la factibilidad del proyecto se tienen:
3.1.1.1.
Factibilidad técnica
Estudia si el trabajo para el proyecto puede desarrollarse con el software y el personal existente, o en caso de necesitar nueva tecnología, cuales son las posibilidades
de desarrollarla o adquirirla. En el marco del modelo se debe establecer los criterios
y restricciones de la definición de sistema crítico para el proyecto.
60
3.1.1.2.
Factibilidad económica
Investiga si los costos se justifican con los beneficios que se obtienen, o si se ha
invertido demasiado, como para no desarrollar el sistema si se considera necesario.
También es posible evaluar, hasta que nivel funcional y con qué nivel de confiabilidad se puede desarrollar el sistema, de acuerdo a los recursos disponibles.
3.1.1.3.
Factibilidad operacional
La factibilidad operacional investiga si será utilizado el sistema, si los usuarios
usaran el sistema y si éste podrá satisfacer las necesidades reales. Realizar este
análisis parece una tarea no muy productiva, ya que se asume existe un problema o
falencia. Sin embargo, pueden no existir las condiciones para que el sistema pueda
operar en conjunto con los usuarios u otros sistemas como se espera. Si bien esta
factibilidad es difícil de detectar en las primeras etapas del proyecto, es aconsejable
realizarla.
3.1.2.
Recursos y actividades
Se debe realizar una identificación de recursos disponibles para el proyecto, según:
Tiempo : asociado a la elaboración de un cronograma, indica los plazos y
metas a alcanzar en periodos de tiempo establecidos.
Personal : tanto en disponibilidad física y motivación del recurso humano,
así como la capacidad técnica para elaborar el producto.
Información : disponibilidad de acceso a la información y procesos asociados al sistema. Incluye formatos, protocolos, estándares internos, entre otros.
61
Tecnología : disponibilidad de equipos, software y comunicaciones, de acuerdo a las posibilidades económicas del proyecto.
Economía : como valor nominal para indicar costos del proyecto. No es un
criterio de interés para el modelo.
Asesoría : Como recurso no tangible, es necesario tener acompañamiento de
personal calificado que conozca el entorno del sistema y que tenga disponibilidad para asesorar en temas relacionados.
Experiencia : experiencia del grupo de desarrollo, como mecanismo para
favorecer la gestión del riesgo y la estimación del proyecto.
Las actividades generales que describe el modelo son:
1.
2.
3.
Aplicación del Modelo.
a)
Revisión de Análisis Global
b)
Revisión de Diseño Global
Diseño de etapas
a)
Análisis detallado
b)
Identificación de etapas: diseño detallado, implementación, pruebas.
Diagnóstico y mejoras
62
3.1.3.
Sistema de calidad
El sistema de calidad se propone como mecanismo que contribuye a la gestión del
riesgo, ya que favorece en:
Asegurar que el producto entregado tiene un nivel de calidad aceptable. El
concepto de calidad será dado como “el producto funciona como dice debe
funcionar”.
Detectar los errores del proyecto cuanto antes, a fin de evitar que estos ocasionen retrasos en tiempo y sobrecostos.
El control de calidad sugerido por este modelo propone unos criterios generales,
los cuales ayudarán a guiar la calidad del software:
Proponer un modelo único de ciclo de vida de desarrollo que favorezca la
gestión de riesgos.
Establecer procedimientos de documentación de todas las etapas del desarrollo.
• Asignación de manejo de configuraciones
• Asignación de procedimientos para manejo de errores.
Aspectos técnicos de diseño: Utilidad, Portabilidad, Integridad, Extensibilidad, Reutilización, Eficiencia, Verificabilidad, Facilidad de uso, Compatibilidad, Confiabilidad (corrección y robustez), Modularidad, Legibilidad.
Utilización de patrones de diseño de software.
63
Definición y aplicación de un plan de pruebas del sistema.
A nivel de diseño, contemplar :
Estabilidad de la plataforma o sistema operativo.
Confiabilidad de las herramientas de programación.
Eficiencia y calidad en la utilización de módulos externos.
3.2.
Comprensión y Análisis
La comprensión del proceso considera el estudio e investigación de las variables,
procesos e interacciones que ocurren en el sistema. El análisis a realizar documenta las necesidades del entorno del problema puntual, enfocándose sobre los
requerimientos globales identificados para el modelo, ésto significa que algunas
características de la composición del sistema se mencionan, pero se debe obtener
el detalle según la aplicación puntual del modelo. Los siguientes puntos consideran
el esquema y contenido global propuesto.
3.2.1. Descripción general
El sistema a desarrollar procesa un flujo de datos de entrada correspondiente a un
conjunto de canales o señales independientes desde uno o varios sistemas de adquisición. Estas señales deben poseer una referencia o variable independiente (regularmente el tiempo) por la cual se realizará la sincronización de las diversas señales
si es necesario. La información recibida se presenta disponible para ser utilizada
por un proceso que se encargará de operar las señales y otro para su visualización
64
o control de parámetros. El procesamiento de la señal es un mecanismo específico del problema a tratar, se considera como una tarea general ya que se pueden
contener niveles de detalle que correspondan directamente a técnicas rigurosas de
diseño y codificación. La parte de interfaz de manejo corresponde a una primera
interfaz de interacción con los usuarios del sistema. Finalmente se encuentra el actuador del sistema como el mecanismo encargado de dar respuesta ante los criterios
establecidos para indicar la ocurrencia de eventos.
3.2.2.
Análisis de requerimientos
3.2.2.1.
Panorama general
Se tiene como propósito la creación de un modelo funcional basado en criterios de
seguridad crítica. El sistema tiene la siguiente estructura:
1.
Señales e información de entrada.
2.
Procesamiento de la señal.
3.
Actuador del sistema.
4.
Interfaz de manejo.
El modelo presenta una estructura semejante a un sistema de control considerando
una unidad de entrada, una de procesamiento o control y una respuesta o salida.
Se tiene como propósito realizar el flujo y procesamiento de la señal de entrada,
en busca de características consideradas de interés según el sistema a evaluar, para
términos de este modelo se denominará eventualidades.
65
3.2.2.2.
Funciones del sistema
Las funciones del sistema se indican en la Tabla 3.1.
Ref.#
Categoría
Función
R.1.1
Evidente
Recibir señal desde la(s) fuente(s) establecida(s).
R.1.2
Proporcionar mecanismos para suministrar las señales a otros
procesos que las requieran, de acuerdo a las prioridades de
acceso.
Oculta
R.1.3
Restablecer el sistema para la recepción de nuevas señales.
Opcional
R.2.1
Recibir flujo de datos desde la entrada de señales.
Oculta
R.2.2
Detectar eventualidades sobre señales de entrada.
Evidente
R.2.3
Transmitir resultados del procesamiento.
Oculta
R.2.4
Registrar estado / respuesta de la detección.
Oculta
R.2.5
Clasificar parámetros de señales detectadas.
Opcional
R.2.6
Establecer parámetros de operación para el actuador.
Evidente
R.2.7
Enviar solicitud de gestión hacia el actuador.
Oculta
R.2.8
Registrar estado / respuesta de la transacción con el actuador.
Oculta
R.3.1
Recibir solicitud de gestión para el actuador.
Oculta
R.3.2
Activar procedimiento(s) del actuador.
Evidente
R.3.3
Registrar estados / respuesta del actuador.
Oculta
R.4.1
Recibir flujo de datos desde la entrada de señales.
Oculta
R.4.2
Activar Interfaz para interacción con el usuario
Oculta
Cuadro 3.1: Funciones del sistema
66
3.2.2.3.
Atributos del sistema
Los atributos del modelo se consideran en la Tabla 3.2.
3.3.
Determinación del Ciclo de Vida
Como Ciclo de Vida para el desarrollo del proyecto, se realizaron evaluaciones
comparativas para determinar cual ciclo favorece al proceso de elaboración del
software, teniendo en cuenta los siguientes criterios:
Que facilite mantener procesos documentados sobre el proyecto.
Que favorezca el análisis y la gestión del riesgo.
Que permita obtener resultados parciales durante el mismo proceso de elaboración.
Que facilite la distribución de trabajo en equipo.
Que permita hacer planificación sobre actividades y tiempo.
Se darán los factores de pros y contras de un modelo de ciclo de vida, denominado
entrega por etapas, considerado éste como el ciclo de vida general a seguir por el
modelo.
3.3.1.
Entrega por etapas
Con el modelo de entrega por etapas, se siguen los pasos del modelo de cascada
pasando por la definición del proceso del software, análisis de requerimientos y
67
Atributo
Condiciones
Metáfora de Interfaz
Tolerancia a fallas
Plataforma de ejecución
Condiciones de uso
(detalles)
se utilizarán dos esquemas de interfaces:
- De visualización y manejo simple para usuarios (interfaz externa).
- De registro de transacciones o de mensajes
del sistema (interfaz interna).
(Restricciones de frontera)
Se tratará de acuerdo a la especificación del
sistema crítico - Análisis detallado.
(Restricciones de frontera)
A seleccionar según el detalle de la aplicación.
Operación
Condiciones del modelo
(detalles)
Características y consideraciones de la aplicación del modelo.
Cuadro 3.2: Atributos del sistema
68
creación del diseño global de una arquitectura para el programa completo, luego se
procede a realizar el diseño detallado, la codificación, depuración y pruebas dentro
de cada etapa. Figura 3.1.
(Tomado de [SM96])
Figura 3.1: Ciclo de vida de Entrega por etapas
Este modelo de desarrollo de software, contribuye a disminuir el riesgo total sobre el proyecto debido a que se contempla liberar versiones del producto que son
parcialmente funcionales. Entre algunos aspectos a favor :
69
Favorece la visibilidad del desarrollo ante los usuarios.
Enfrenta en las primeras etapas detalles importantes de diseño.
Detección temprana de problemas.
Ayuda a controlar la ejecución del cronograma del proyecto.
Facilita mantener la modularidad desde el diseño de las etapas.
En contraposición, tiene asociados riesgos potenciales, como el cambio de prestaciones, lo que constituye la incapacidad o dificultad de modificar su estructura de
acuerdo a cambios o adición de requerimientos, que afecten significativamente a
etapas previas. Para el caso del modelo propuesto, se subsana este ítem realizando
un análisis más detallado como parte de la aplicación del modelo. Adicionalmente
el modelo propone una arquitectura general que facilita la modularidad de componentes generales, sin comprometer el funcionamiento y especificaciones de cada
uno de estos componentes.
Cada etapa tiene una estructura interna similar al resto. Una estructura recomendada para las etapas es:
Descripción general: Explicación de qué hace o realiza la etapa.
Diseño detallado: Diagramas y conceptos del diseño de los componentes o
módulos.
Formatos y estructuras: Estructuras de entrada y salida, formatos de archivo, protocolos y configuraciones.
70
Codificación: Información general sobre la codificación: lenguajes, métodos, algoritmos.
Pruebas: Formatos de aplicación de los planes de prueba.
3.3.2.
Discusión
Aunque el ciclo de vida de entrega por etapas favorece la gestión de riesgos, es
posible considerar como parte del diseño global una planificación de las etapas
que permita la implementación temprana de los módulos base: clases y bibliotecas comunes de desarrollo, siguiendo con los mecanismos para entrada de datos y
posteriormente el núcleo, considerado como el sistema crítico en sí. Como se encuentra definido en cada etapa, se describen los procedimientos de diseño y prueba.
Si bien el ciclo de vida de entrega por etapas se ajusta bien a las condiciones y
características del modelo, es posible definir aspectos adicionales que beneficiarían
al modelo, tales como:
Realizar planificación de las etapas: identificar un orden que permita la
realización temprana de revisión y pruebas, como mecanismos de control de
calidad.
Análisis específico de requerimientos: a fin de definir con mayor detalle
cuales serán las funcionalidades y limitaciones del sistema.
Definición del sistema crítico: el componente de sistema crítico deberá tener un alcance definido. En rigor, el modelo solo contempla una parte del
sistema como crítico, debido al alto costo de desarrollo que podría tener su
71
aplicación. Sin embargo, el componente crítico deberá tener unas condiciones de supervivencia que le permitan operar una parte reducida del sistema completo. La identificación, diseño, codificación y prueba de este componente tendrá mayores exigencias de calidad y verificación, para asegurar
confiabilidad.
Aplicación de un plan de calidad sobre las etapas: Aunque los criterios
del control de calidad se encuentran sugeridos en este modelo, la utilización
de otros esquemas no contraría tales propuestas. La aplicación de un plan de
calidad solo es la confirmación de otros procesos que se encuentran ligados
a la gestión del riesgo del software.
Realizar un proceso de diagnóstico y mejoramiento: Como una última
etapa no definida completamente en tiempo y alcances, se sugiere incluirla como proceso de acompañamiento y despliegue de la herramienta en el
ambiente de operación.
3.3.3.
Gestión de riesgos
De acuerdo al desarrollo por etapas la gestión del riesgo será definida antes de cada
etapa de manera puntual y evaluada finalizando tal etapa, a fin de no acarrear nuevos indicadores de riesgo a las etapas siguientes. Con la planificación de las etapas,
se tiene que las primeras etapas tienen una mayor prioridad para el producto, por
tanto la gestión debe realizarse intensivamente. La gestión del riesgo se puede dividir en dos subprocesos a ejecutarse como parte del diseño al inicio de una etapa
(Estimación) y como parte de la implementación al finalizar la misma (Control).
72
3.3.3.1.
Estimación
Se busca establecer durante el proceso de diseño qué factores, restricciones del
medio o características del producto, pueden representar problemas que generen
sobrecostos en tiempo, recursos o personal. Estos riesgos están generalmente asociados al producto específico que se desee obtener. Sin embargo, a nivel de este
modelo se puede estimar un riesgo asociado al ciclo de vida a utilizar:
Sensibilidad a cambios en los requerimientos
Descripción: con el uso de la entrega por etapas es posible que se
presente una sensibilidad muy alta a cambios de prestaciones en las
etapas que se realicen primero. El problema es latente si el usuario
cambia drásticamente las características del desarrollo afectando detalles o estructuras de diseño sobre etapas previas, obligando a redefinir
y modificar los subproductos retrasando cronogramas, incrementando
costos, etc.
Peor caso: en el peor de los casos es necesario reconstruir desde la
primera etapa, realizando revisión sobre cada una de las siguientes. Es
posible que no se reutilice la codificación realizada.
Gestión: como medida tendiente a mitigar el impacto de este riesgo se
propone la adición de una etapa 0, en la cual se haga una identificación de requerimientos y prestaciones, que permitan obtener confianza
sobre la definición del producto a desarrollar.
Excepciones: no cualquier cambio propuesto por el usuario tendría un
impacto negativo sobre el modelo aplicado. En algunos casos, utilizar
73
la entrega por etapas es favorable, especialmente si los cambios son
dados para etapas no desarrolladas.
3.3.3.2.
Control
Como mecanismo de monitorización de riesgos se utilizará la información del formato de estimación (punto anterior), evaluando como un criterio cualitativo, cuál
fue el impacto del riesgo y cómo se está dando la respuesta. Este control se realizará durante el proceso de codificación, como tareas adicionales a la revisión y
prueba.
3.4. Consideraciones de Diseño
3.4.1.
Gestión de configuraciones
3.4.1.1.
Manejo de configuraciones
Como herramientas para la gestión de configuraciones se propone la utilización de:
Estándar de Documentación: utilización de estándares para la edición de
documentación interna y externa al producto.
Listas de correo: Como mecanismo de flujo y almacenamiento, la listas
de correo ayudan como instrumento que facilita la comunicación entre el
personal involucrado al proyecto.
Control de tareas: Identificación de roles sobre el personal de diseño y desarrollo, asignación y ordenamiento de tareas. Asignación de responsabilidades.
74
Cronogramas: Manejo de diagramas de Pert y Gant para conocer actividades, tiempos, ruta crítica.
RCS (Revision Control System): sistema de control de versiones que automatiza el almacenamiento, recuperación, acceso, identificación y mezcla de
versiones. Como herramienta específica CVS (Code Management System)
proporciona estas prestaciones.
3.4.1.2.
Control de errores
Manejo de listado de errores y uso de excepciones que permitan conocer el comportamiento del sistema y solucionar eficientemente los problemas del producto.
3.4.2.
Patrones de diseño
Los patrones de diseño de software constituyen un conjunto de principios generales
y expresiones que ayudan a desarrollar software. Un conjunto destacado de patrones es GRASP (General Responsabilty Assignment Software Patterns) [CL99], que
permite establecer algunos parámetros útiles para el diseño del producto.
3.4.2.1.
Modularidad
Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.
Para favorecer la construcción y uso del sistema se realizará un diseño e implementación modular. Se utilizarán los patrones GRASP experto, Alta cohesión y Bajo
acoplamiento [CL99]:
75
Experto: Asignar una responsabilidad al experto en información: el módulo
que cuenta con la información necesaria para cumplir la responsabilidad.
Facilidad de entender, mantener y manipular. Reutilización.
Alta cohesión: Asignar una responsabilidad para mantener alta la cohesión.
Cuan relacionadas y enfocadas están las responsabilidades de un módulo.
Bajo acoplamiento: Asignar una responsabilidad para mantener bajo el acoplamiento. Tener la mínima conexión entre los módulos.
3.4.2.2.
Escalabilidad
El sistema debe contener un núcleo central que realice las operaciones prioritarias.
También contendrá módulos de funcionamiento independiente que interactúen con
el núcleo principal y con otros módulos. Este esquema permitirá adicionar otros
módulos según se presenten nuevos requerimientos o modificar las características
de los existentes.
3.4.3. Diseño crítico
De acuerdo al modelo HRT-HOOD [BW94], un objeto HOOD tiene propiedades
estáticas (componentes internos funcionales) y dinámicas, las cuales describen los
efectos del llamado sobre objetos :
Flujo Secuencial: el control es transferido directamente a la aplicación requerida.
Flujo Paralelo: el control es transferido al objeto llamado pero independientemente de otros flujos.
76
Aunque el modelo HRT-HOOD está enfocado al diseño de sistemas en tiempo
real duro, también es posible su aplicación para sistemas críticos, por lo cual se
utilizarán algunos de los conceptos de diseño en este modelo.
3.4.3.1.
Diseño lógico de la arquitectura
El diseño lógico puede ser hecho independientemente de las restricciones impuestas por el entorno de ejecución. Hay dos aspectos que facilitan el diseño de la
arquitectura lógica de cualquier método de modelado para sistemas de tiempo real
duros: Primero, soporte con la abstracción que es requerida por los diseñadores. El
segundo aspecto involucra restricciones de arquitectura lógica, así que esto puede
ser analizado durante el diseño de la arquitectura física. En particular el diseño es
forzado para adaptarse a un modelo computacional que facilite el análisis.
1. Capa de Interfaz con el usuario: para el modelo, la interfaz con el usuario,
consiste en la visualización y posible interacción del usuario con el sistema.
En términos generales tiene una prioridad media-baja en cuanto a uso dentro
del sistema crítico, ya que su función corresponde a brindar información gráfica sobre las señales y su comportamiento, mas no es vital para el conjunto
del sistema.
2. Capa de alimentación: entrada de datos, para el caso del modelo señales e
información asociada específica de la aplicación.
3. Capa de lógica: corresponde al procesamiento de la señal, específicamente
detección, clasificación y respuesta.
77
4.
Capa de actuador: sistema de respuesta. Interpreta y ejecuta la respuesta de
la capa lógica.
5.
Capa de comunicaciones: procedimientos y protocolos de comunicaciones
entre los módulos.
6.
Capa de registro del sistema: como mecanismo de supervisión y depuramiento, se incluyen registros (Logs), indicando estados de los procesos en
ejecución, fallos, advertencias, entre otros.
3.4.3.2.
Diseño físico de la arquitectura
Toma los requerimientos no funcionales para crear un diseño funcional y generar
un análisis de organización de tareas que garantice su correcto funcionamiento.
La actividad de diseño lógico asegura que todo el diseño conforme un modelo
computacional que facilite el análisis del tiempo de ejecución. En general el diseño
de la arquitectura física concierte cuatro actividades:
1.
Localización de objetos - Localización de objetos en la arquitectura lógica para procesadores con las restricciones impuestas por los requerimientos
funcionales y no funcionales.
2.
Organización de red - programar la red de comunicaciones para la espera
de mensajes.
3.
Organización de procesadores - determinar la programación (estática o dinámica) con la cual asegurar que todas las tareas dentro de los objetos residan
en los procesadores en el momento de ejecución.
78
4. Dependencia - determinar la capacidad de detectar fallos imprevistos de
software o hardware y su tolerancia a ellos.
3.4.4.
Excepciones de aplicación
Este aparte puede verse como la personalización de los conceptos y métodos desarrollados en el modelo. Para el problema planteado, en términos generales, se
podrán utilizar las descripciones y métodos ofrecidos por el modelo. Sin embargo,
para algunos casos de aplicación, los conceptos podrían tener otras interpretaciones, adiciones o no aplicación, de acuerdo a la descripción detallada del problema
que se tenga.
La inclusión de un mecanismo de redefinición de conceptos, permite por una parte
hacer más flexible la aplicación del modelo a otro tipo de problemas; por otra parte,
diversos tipos de aplicación permitirían la retroalimentación al modelo para futuras
revisiones.
3.5.
Definición Plan de Pruebas
3.5.1.
Sobre el diseño del producto
3.5.1.1.
Definición de las etapas de desarrollo
Cada etapa es en sí misma es un desarrollo parcial del proyecto total, pero es un
sub-producto funcional. Al final de cada etapa se desarrollarán pruebas de verificación del software elaborado. La última etapa de desarrollo corresponderá a la
79
integración de los módulos elaborados anteriormente.
3.5.1.2.
Pruebas de integración
Como parte del proceso de diseño global del modelo se debe realizar la especificación de los protocolos de comunicación o paso de mensajes y los formatos internos
para los datos. Cualquier modificación estará sujeta a aprobación por el diseño detallado de cada etapa de desarrollo.
3.5.1.3.
Pruebas de sistema crítico
El componente de sistema crítico corresponde a uno o varios módulos del sistema.
Debido al nivel de estabilidad que requiere este componente es recomendable que
se haga la definición de un plan detallado adaptado a las necesidades del sistema.
3.5.1.4.
Pruebas de rendimiento
Como parte de la comprobación del producto, se realizarán pruebas de consumo de
recursos computacionales. Para facilitar este proceso se recomienda implementar
mecanismos que permitan conocer los estados internos de los módulos mediante
sistemas de registros del sistema y codificación de mensajes de error.
80
3.5.2.
Sobre la funcionalidad del producto
La definición de los casos de prueba se realizará por cada etapa. Estas pruebas de
funcionalidad consisten en verificar externamente la ejecución del producto, que
para el caso del ciclo de vida a utilizar constituye probar los sub-productos y luego
el producto final.
El esquema general de las plantillas puede ser dado como:
Caso de prueba: Nombre del caso de prueba
Objetivo de la prueba: Descripción del cometido de esta prueba
Configuración hardware y software: requerimientos y configuración del
sistema utilizado.
Formatos de entrada: Formatos o protocolos de la información de entrada.
Formatos de salida: Formatos o protocolos de la información resultante.
Procedimiento de prueba: Descripción del procedimiento utilizado por el
encargado de la prueba.
Resultados: Comentarios de ejecución de la prueba y respuesta del sistema.
3.6.
Resumen del modelo
En general el modelo presenta y contempla los siguientes conceptos:
Planeación: establecer los recursos y medios para la realización del proyecto.
Análisis de factibilidad
81
Actividades generales
Sistema de Calidad
Análisis Global: comprensión de los esquemas de funcionamiento del tipo de sistemas objetivo.
Descripción del sistema
Análisis de requerimientos
Selección del Ciclo de Vida: determinación del modelo de desarrollo del producto
de software a seguir.
Entrega por etapas
Estimación y Control del riesgo
Diseño Global: Consideraciones para el diseño de las aplicaciones y concepto de
sistema crítico.
Gestión de configuraciones
Utilización de Patrones
Diseño Crítico
Plan de pruebas: Como mecanismo de evaluación continua, se establecen procedimientos para la comprobación de la herramienta.
Sobre el diseño o pruebas de caja blanca
Sobre la funcionalidad o pruebas de caja negra
82
Capítulo 4
Etapas del desarrollo
Este capítulo documenta la aplicación del modelo presentado anteriormente, para
el caso de la detección y clasificación de eventos sísmicos sobre señales digitales.
El problema presenta las condiciones que permiten categorizarlo en el dominio del
modelo: entrada de datos, análisis o procesamiento, salida y respuestas.
El modelo descrito, constituye una base conceptual que establece métodos y definiciones para problemas del tipo de detección y clasificación de señales digitales.
Como ciclo de vida del producto software, el modelo establece los pasos para realizar el análisis y diseño global del problema, permitiendo la definición y ejecución
de las etapas descritas para construir la aplicación de software. Como soporte del
sistema crítico ofrece la recopilación de criterios y factores que guían las fases de
construcción, vinculando todo el proceso de desarrollo con el concepto de calidad
de un producto de software.
83
4.1. Planeación
4.1.1.
Factibilidad
4.1.1.1.
Técnica
De acuerdo a la revisión bibliográfica, se conoce la existencia de métodos y procedimientos que pueden ayudar al alcance de las metas del proyecto. A fin de contemplar más alternativas de solución se buscarán nuevos mecanismos que definan
los procesos de construcción de la herramienta de software.
4.1.1.2.
Económica
El OSSO proveerá los recursos humanos, equipos y telecomunicaciones para el
desarrollo del proyecto.
4.1.1.3.
Operacional
Los ítem 1.1.4 y 1.1.5 del Capítulo 1 aportan elementos que sustentan la importancia del problema y algunas alternativas de solución existentes.
4.1.2.
Actividades
Siguiendo la identificación de actividades del modelo se tiene:
Aplicación del modelo:
Revisión de Análisis global: a realizar en la descripción del sistema actual.
Revisión del Diseño global: Arquitectura general e identificación del componente crítico.
84
Diseño de etapas:
Análisis detallado: Identificado como Etapa 0.
Identificación de etapas: A partir de la etapa 1 hasta integración de componente y pruebas.
Diagnóstico y Mejoras:
Aplicación de planes de prueba del sistema.
Procesos posteriores al desarrollo para evaluar validez de los procesos.
4.1.3.
Sistema de calidad
Se consideran los siguientes elementos para uso durante el diseño y codificación:
Uso del ciclo de vida de entrega por etapas, según la descripción del modelo.
Uso de patrones de diseño GRASP y conceptos de diseño Orientado a Objetos.
Uso de un sistema para manejo de código (CVS).
Generación de archivos de registros del sistema (LOGs).
Codificación y asignación de errores y alertas sobre el sistema. Favorece en
la detección de fallos presentados durante la ejecución del sistema.
Formatos para aplicación del plan de pruebas de diseño y funcionalidad
85
4.2. Descripción del sistema actual
Para tener una correcta identificación de las variables y condiciones del sistema,
se propone la descripción formal de las características propias del sistema y sus
necesidades.
4.2.1.
Análisis detallado (Etapa 0)
Siguiendo los métodos propuestos en [CL99], se realizará el análisis detallado del
proyecto.
4.2.1.1.
Definición del problema
Como parte del proceso de observación sismológica, los casos de mayor interés
son la ocurrencia de cambios o fenómenos sobre las señales; estos casos pueden
presentarse en cualquier momento y tener diversas causas de origen. Se desea conocer cuando las señales detectadas son producidas por movimientos del subsuelo
(eventos sísmicos) y buscar un esquema de clasificación basado en las características de la señal. La definición más completa de este punto se encuentra en los ítem
1.1 y 1.2 del Capítulo 1.
4.2.1.2.
Listado detallado de requerimientos
1.
Lectura de datos de entrada en formato WVM.
2.
Lectura y conversión de datos desde archivos almacenados previamente.
3.
Mecanismo de visualización de los datos actualmente en uso.
86
4.
Mecanismo de configuración de códigos de estaciones y un coeficiente que
indique calidad de la señal (valor numérico denominado peso).
5.
Registro de funcionamiento del sistema mediante LOGs (mensajes a consola).
6.
Determinar la ocurrencia de eventos de interés y establecer un mecanismo
de clasificación.
7.
Registrar e informar la ocurrencia de eventualidades sobre las señales.
4.2.1.3.
Descripción Casos de uso
Como metáfora de uso del sistema, se pueden considerar los siguientes elementos.
Ver Figura 4.1.
Se presentan dos actores:
Usuario: puede visualizar información suministrada por el sistema de adquisición y los parámetros de configuración utilizados.
Operador: Visualiza y monitorea los estados de operación del sistema. Los
posibles errores en la entrada de datos, en la ejecución de los módulos internos, o en las salidas del sistema serán reportados al registro de mensajes del
sistema. El operador debe realizar alguna acción para restaurar la operación
completa de la herramienta.
Cinco casos de uso:
Visualización y configuración: Visualizar la señal de las estaciones sismológicas. Realizar configuración para la operación del sistema.
87
Captura de señal: Leer la señal del sistema de adquisición digital. Se utilizará el protocolo de datos nativo del sistema de adquisición. Se registran los
estados de funcionamiento de los componentes asociados.
Detección: Indica si un conjunto de señales muestran comportamientos o
presencia de eventualidades.
Clasificación: de acuerdo a la salida otorgada por la detección, la clasificación dará lugar a determinar la clase de comportamiento de la señal entrante.
Alerta: respuesta del sistema de acuerdo a la salida del caso de detección.
4.2.1.4.
Modelo Conceptual
Como una primera aproximación al diseño detallado, los objetos funcionales sobre
el sistema se indican a continuación. Se muestra en este modelo conceptual la
interrelación entre los componentes. Figura 4.2.
4.2.1.5.
Diagramas de Secuencia del Sistema
Los diagramas de secuencia muestran una generalización del paso de mensajes
entre los actores y casos de uso detectados. Estos diagramas ayudan a comprender
el funcionamiento y la interacción de componentes del sistema.
Caso de uso Visualización y configuración. Figura 4.3.
Caso de uso Captura de señal. Figura 4.4.
88
Figura 4.1: Casos de uso
89
Figura 4.2: Modelo Conceptual
90
Figura 4.3: DSS - Visualización y configuración
91
Figura 4.4: DSS - Captura de señal
Figura 4.5: DSS - Detección
92
Caso de uso Detección. Figura 4.5.
Caso de uso Clasificación. Figura 4.6.
Figura 4.6: DSS - Clasificación
Caso de uso emitir alerta. Figura 4.7.
4.2.2.
Definición de las etapas
4.2.2.1.
Listado de componentes
De acuerdo a la estructura general del modelo y con el análisis detallado del sistema
a tratar, se pueden deducir algunos componentes funcionales:
Entrada de datos
Detección de cambios
93
Figura 4.7: DSS - Emisión de alerta
94
Clasificación de eventualidades
Alerta
Adicionalmente, se requieren algunos componentes ocultos para el usuario, pero
de uso en la aplicación:
Protocolos y funciones para comunicaciones.
Protocolos y funciones para manejo de las estructuras de datos.
Sistema de registro de mensajes en consola.
4.2.2.2.
Ordenamiento
Se puede determinar el orden de construcción de los componentes, buscando reducir el riesgo potencial de la entrega por etapas: sensibilidad en cambios de requerimientos sobre etapas tempranas. Se designarán como etapas tempranas las que
ofrezcan mayor independencia de diseño y que definan protocolos y estructuras de
información necesarias en etapas posteriores. De acuerdo a estos factores, el orden
de las etapas será :
Etapa 1: Comunicaciones y registro
Corresponde a las estructuras y mecanismos de software que permiten realizar la comunicación entre los módulos internos, el registro de mensajes en
consola (LOG) y la manipulación de estructuras de datos.
Etapa 2: Entrada de datos
Define el mecanismo de entrada de datos, estableciendo comunicación con
95
la fuente que suministra los datos, convirtiéndolos en la estructura interna
adecuada.
Etapa 3: Detector de cambios
Este componente comprende la implementación del sistema que permite detectar los cambios sobre las señales de entrada.
Etapa 4: Clasificador de eventualidades
Este componente, aunado al trabajo del detector realiza la clasificación de
las señales ingresadas.
Etapa 5: Sistema de Alerta
La alerta constituye el actuador o respuesta del sistema. Puede ser vista como
un mecanismo de comunicación hacia otros sistemas o un mecanismo de
retroalimentación.
Etapa 6: Integración de componentes
El modelo sugiere la inclusión de una última etapa para la integración de
componentes y pruebas. Esto permite documentar y aplicar de manera homogénea planes de prueba.
4.2.3.
4.2.3.1.
Arquitectura de la herramienta
S-DCE : Señales - Detector y Clasificador de Eventualidades
El sistema S-DCE corresponde a la implementación del diseño modular y Orientado a Objetos. Este sistema se encargará de tomar la señal de una fuente de adquisición de datos, detectar y clasificar las señales de entrada de acuerdo a los criterios definidos internamente y emitir una alerta, según sea necesario. Paralelamente
96
provee un entorno para la visualización y configuración del detector, indicando
parámetros generales para el funcionamiento del sistema. Figura 4.8.
Figura 4.8: Arquitectura de componentes
4.2.3.2.
Componentes
GUI: Interfaz de usuario.
Sistema adquisición: fuente de señales digitales.
Alerta: Actuador o respuesta.
Detector: Mecanismo para la detección de cambios abruptos.
Clasificador: Mecanismo para la clasificador de señales.
IS-1: Interfaz del Sistema 1 para el módulo de adquisición de datos.
IS-2: Interfaz del Sistema 2 para el módulo de visualización y configuración.
97
IS-3: Interfaz del Sistema 3 para el módulo de alerta.
4.2.3.3.
Características generales
Plataforma : GNU/Linux
Lenguajes de programación : GNU/C y GNU/C++, Java, Perl.
Bibliotecas del sistema : proporcionadas por las librerías propias del sistema
operativo
• Comunicaciones por sockets.
• Manejo de memoria, cadenas, operaciones matemáticas.
• Registro de mensajes a consola (syslog).
4.2.4. Sección crítica
Las condiciones de estabilidad del sistema están dadas en gran medida por la gestión realizada en el control de calidad del producto de software. Este control se
aplica durante los planes de prueba, especialmente en los componentes críticos.
Para la aplicación puntual, los componentes críticos serán denominados núcleo, ya
que en cierta medida los otros módulos trabajan alrededor de éste. El núcleo se
define según los objetivos primarios del sistema, en este caso realizar la detección
de cambios sobre el sistema. Cualquier fallo sobre los mecanismos de entrada o
salida de datos deberán ser contemplados por el núcleo.
98
Los alcances de la sección crítica del sistema, se encuentran limitados a las condiciones de funcionamiento del sistema operativo y por ende al desempeño del
hardware de la máquina.
4.3.
Etapa 1: Comunicaciones y control
4.3.1.
Descripción
Esta etapa busca crear los métodos y funciones para :
Realizar la transmisión de datos entre los módulos, utilizando sockets (Mas
información A.1.3).
Realizar el registro de mensajes en consola, utilizando syslog (Linux system
logging utilities).
Realizar el manejo de las estructuras de datos descritas en A.1.1 y A.1.2.
4.3.2.
Protocolos
Las especificaciones de las estructuras de datos utilizadas se encuentran consignados en el Anexo A, A.1.1 y A.1.2.
4.3.3.
Codificación
La codificación de estos componentes comprenden la generación de librerías y
clases que sirvan para realizar :
99
1.
Operaciones de transmisión de información localmente o por red de datos
utilizando un modelo cliente servidor.
2.
Registro de mensajes del sistema.
3.
Funciones para el manejo de las estructuras DSRCP y XMLDSRC.
4.3.4. Pruebas
Para esta etapa se utilizarán las siguientes fichas de prueba:
Caso de prueba :
Objetivo :
Configuración :
Entradas :
Salidas :
Descripción :
Resultados :
Transmisión de datos
Realizar transmisión de datos mediante el modelo de sockets
PC i386 con sistema operativo Linux
Archivos planos y binarios.
Copia de los archivos enviados.
Se realiza la transmisión de archivos planos y binarios.
La transmisión de datos utilizando sockets se realizó con éxito.
Cuadro 4.1: Prueba: Transmisión de datos
Caso de prueba :
Objetivo :
Configuración :
Entradas :
Salidas :
Descripción :
Resultados :
Registro de mensajes
Realizar el registro de mensajes en Consola
PC i386 con sistema operativo Linux
Entrada del mensaje a registrar.
Formato de registro en Consola.
Se realiza el registro de mensajes en Consola, utilizando syslog.
Los mensajes son registrados con éxito.
Cuadro 4.2: Prueba: Registro de mensajes
100
4.4.
Etapa 2: Entrada y visualización de señales
4.4.1.
Descripción
4.4.1.1.
Enlace al sistema de adquisición
Recepción y conversión del formato de los datos del sistema de adquisición. Este
componente actúa como un servidor de datos para los otros módulos. Los datos
quedan disponibles bajo la estructura XMLDSRC.
4.4.1.2.
Cliente de interfaz gráfica
Visualiza las señales recibidas, desplegando las ondas para cada canal de datos.
También provee un mecanismo simple para configurar la información de las estaciones y su nivel de calidad mediante un parámetro denominado peso.
4.4.2.
4.4.2.1.
Diseño detallado
Enlace al sistema de adquisición
El diagrama de colaboración para este componente se indica en la Figura 4.9.
4.4.2.2.
Cliente de interfaz gráfica
El diagrama de colaboración para este componente se indica en la Figura 4.10.
4.4.3.
Protocolos
Los detalles de los protocolos y estructuras de datos se encuentran en el Anexo A,
ítem A.1.1 y A.1.4.
101
4.4.4.
4.4.4.1.
Codificación
Enlace al sistema de adquisición
El enlace al sistema de adquisición permite la conexión a una fuente de datos, correspondiente a archivos previamente almacenados. Adicionalmente estos datos se
podrán accesar mediante un servidor vía Sockets utilizando Threads (hilos) que
proveerá esta información a los otros módulos. Este módulo se encuentra implementado en /C/C++.
4.4.4.2.
Cliente de interfaz gráfica
Como herramienta para visualizar la información adquirida, se cuenta con un cliente del enlace al sistema de adquisición. Este componente permite realizar una configuración simple de los canales de datos. Este cliente se implementa en Java y la
visualización se realiza mediante Applets.
4.4.5.
Pruebas
Se propone la siguiente ficha de prueba para esta etapa:
4.5. Etapa 3: Núcleo - Detector de cambios
4.5.1.
Descripción
El detector de cambios corresponde al núcleo o sección crítica. En general este sistema es responsable de indicar donde ocurre un cambio importante sobre la señal,
102
Figura 4.9: DColaboración - Captura de señal
Caso de prueba :
Objetivo :
Configuración :
Entradas :
Salidas :
Enlace y visualización de datos
Lee y visualiza los datos del sistema de adquisición.
PC i386 con sistema operativo Linux
Archivos en formato WVM.
Señal visualizada mediante aplicación.
Descripción :
Se realiza la lectura de archivos WVM. Se provee un mecanismo para suministrar los datos a otros módulos.
Resultados :
Los datos se leyeron y visualizaron correctamente.
Cuadro 4.3: Prueba: Enlace y visualización de datos
103
Figura 4.10: DColaboración - Visualización y configuración
104
bien sea que se presente atenuado o abrupto. Una vez se determine que ha ocurrido un cambio, se procede a llamar al módulo de clasificación, el cual opera en
colaboración con este componente.
4.5.2.
Diseño detallado
El diagrama de colaboración para este componente se indica en la Figura 4.11.
Figura 4.11: DColaboración - Detección y Clasificación
105
4.5.3.
Protocolos
Los protocolos de entrada y salida de datos se encuentran definidos en el Anexo A,
ítem A.1.
4.5.4.
Codificación
Este es un cliente de datos que implementa la estructura XMLDSRC. Codifica el
algoritmo STA/LTA (descrito en el Capítulo 2, ítem 2.6.1), aplicando algunos cambios para extraer características de las señales, basado en el estudio de [MDH02].
Luego, se realiza el llamado al proceso de clasificación.
4.5.5.
Pruebas
Dado que este componente corresponde a la parte crítica del sistema, se define
y aplica un plan exhaustivo para la detección de señales. Las fichas de prueba a
utilizar son:
Caso de prueba :
Objetivo :
Configuración :
Entradas :
Salidas :
Núcleo - Rendimiento del sistema
Medir los niveles de carga y uso de recursos sobre la máquina.
PC i386 con sistema operativo Linux
Módulo de detección de cambios
Reporte sobre niveles de carga en el sistema.
Descripción :
Se revisa el consumo de recursos que presenta el sistema.
Resultados :
La máquina no presenta niveles altos de consumo de recursos, excepto para arreglos de datos muy extensos.
Cuadro 4.4: Prueba: Núcleo - Rendimiento del sistema
106
Caso de prueba :
Objetivo :
Configuración :
Entradas :
Salidas :
Núcleo - Conexiones de entrada y salida
Comprobar las funciones que realizan la entrada y salida
de datos
PC i386 con sistema operativo Linux
Módulo de detección de cambios
Reporte de funcionamiento de las conexiones.
Descripción :
Se realiza supervisión en la operación de las funciones de
entrada / salida de mensajes y datos.
Resultados :
Las conexiones de entrada y salida responden correctamente a los llamados. Cuando los módulos no se encuentran disponibles, el sistema reporta este suceso.
Cuadro 4.5: Prueba: Núcleo - Conexiones de entrada y salida
Caso de prueba :
Objetivo :
Configuración :
Entradas :
Salidas :
Núcleo - Excepciones del detector
Comprobar la respuesta del sistema en situaciones de error
o no disponibilidad de recursos.
PC i386 con sistema operativo Linux
Módulo de detección de cambios
Reporte con excepciones del sistema
Descripción :
Se realiza la comprobación de respuesta del sistema ante
entradas erróneas o fallos en el acceso a otros componentes.
Resultados :
El sistema realiza correctamente el registro ante los errores descritos.
Cuadro 4.6: Prueba: Núcleo - Excepciones del detector
107
4.6. Etapa 4: Clasificador de eventualidades
4.6.1.
Descripción
Una vez las señales han sido declaradas como eventualidad, es de utilidad saber si
corresponden a algún tipo de clasificación. Sin embargo, dada la naturaleza de las
señales y la cantidad de variantes que las afectan, puede obtenerse, para alcances
de este prototipo, una caracterización general, que resulta útil para identificar el
tipo de señal.
A nivel de diseño este componente no tiene grandes requerimientos: básicamente
el núcleo del sistema entrega cierta información ya procesada; el clasificador determinará si la eventualidad se encuentra en uno de los grupos de clasificación y retornará una respuesta al detector. Para la implementación de éste módulo, es posible
utilizar una gran variedad de técnicas desde algoritmos basados en reglas, estadísticos, técnicas de Inteligencia Artificial o de métodos numéricos. Para clasificar
eventos sísmicos existen diversos mecanismos, entre los cuales se destacan técnicas de Inteligencia Artificial 2.7, o aquellos basados en aplicación de filtros para
transformar la señal a una equivalente que favorezca un determinado procesamiento. Este módulo implementará un filtro, un algoritmo para extraer características y
aplicará un conjunto de reglas, con el fin de simplificar las operaciones.
4.6.2.
Codificación
Para el caso de aplicación, el clasificador aplica un filtro sobre la señal, extrae un
grupo de características relacionadas con la eventualidad detectada y determina
108
la clase a la que pertenece la señal basándose en algunas reglas derivadas de la
configuración local de la red de estaciones del OSSO y algunos procedimientos
simplificados de localización del evento.
Este módulo realiza la aplicación del filtro Discrete Wavelet Transform con Daubechies - 4 para extracción de características, basado en la experimentación de
[GEM98]. Para realizar la clasificación se aplican un conjunto de reglas utilizadas
por el Área de Sismología de la red del Sur Occidente del OSSO. Las características utilizadas para la clasificación son:
Tiempo y amplitud del inicio del evento (Tp y Ap).
Tiempo y amplitud máxima (Ts y As).
Tiempo finalización del evento (Tc y Ac).
4.6.3.
Pruebas
Se propone la siguiente ficha de prueba para esta etapa:
4.7.
Etapa 5: Sistema de alerta
4.7.1.
Descripción
Actuando como sistema de control, la alerta corresponde a la respuesta del sistema
frente a la ocurrencia de eventualidades, de acuerdo al módulo de detección. Este
módulo se encarga de recibir y enviar las alertas generadas por la detección y clasificación de eventualidades. La alerta puede tener múltiples variantes de acuerdo
109
Caso de prueba :
Objetivo :
Configuración :
Núcleo - Funcionamiento del detector
Comprobar si el detector funciona correctamente.
PC i386 con sistema operativo Linux
Entradas :
Módulo de detección de cambios y Módulo de conexión
de entrada de datos.
Salidas :
Ocurrencia de cambios o eventualidades sobre las señales.
Descripción :
Se comprueba el nivel de funcionamiento de la detección
de señales.
Resultados :
Se obtiene las caracterización de las señales donde ocurren
cambios de interés (presencia de eventualidades).
Cuadro 4.7: Prueba: Núcleo - Funcionamiento del detector
Caso de prueba :
Objetivo :
Configuración :
Entradas :
Salidas :
Clasificación de eventualidades
Verificar el funcionamiento de la clasificación
PC i386 con sistema operativo Linux
Caracterización de las señales
Tabla de clasificación de las señales
Descripción :
Se realiza la verificación en el correcto funcionamiento de
la clasificación de las señales.
Resultados :
Se retorna un registro con los resultados de la clasificación.
Cuadro 4.8: Prueba: Clasificación de eventualidades
110
a las necesidades o configuración del sistema. Para el caso de implementación, la
función setMedia() soporta en envío de la alerta de texto por correo electrónico.
4.7.2.
Diseño detallado
El diagrama de colaboración para este componente se indica en la Figura 4.12.
Figura 4.12: DColaboración - Emisión de alerta
4.7.3.
Protocolos
De manera general, los tipos de alerta a ser manejados por el sistema corresponden
a:
111
Alerta S-DCE: Fallos importantes sobre la funcionalidad del sistema se catalogan con este tipo de clasificación.
Alerta Técnica: Errores externos a S-DCE que indiquen imposibilidad de
funcionamiento en las operaciones.
Alerta de Eventualidad: Ocurrencia de eventos sísmicos o de otra índole y
que requieran atención, de acuerdo a lo establecido en la configuración de
este módulo.
Estas alertas poseen clasificaciones internas dinámicas, que van cambiando de
acuerdo a las condiciones y características resultantes en los módulos de detección
y clasificación.
4.7.4. Codificación
Para la implementación de este componente se generará un reporte de eventualidad.
Los servicios que realiza la alerta son:
Se provee un servidor que atiende los llamados del detector.
Se realiza el registro de un reporte de alerta.
Se ejecuta la acción de alerta de acuerdo a la configuración específica.
4.7.5. Pruebas
Se proponen la siguientes fichas de prueba para esta etapa:
112
Caso de prueba :
Objetivo :
Servidor de alertas
Verificar el funcionamiento del servicio de recepción de
alertas
Configuración :
Entradas :
Salidas :
PC i386 con sistema operativo Linux
Mensajes de alerta de prueba desde el detector
Paso del mensaje al envío de alertas.
Descripción :
El servidor debe recibir y entregar el mensaje para que sea
enviado.
Resultados :
El servidor entrega correctamente el mensaje.
Cuadro 4.9: Prueba: Servidor de alertas
Caso de prueba :
Envío del mensaje de alerta
Objetivo :
Realizar envío del mensaje de alerta.
Configuración :
PC i386 con sistema operativo Linux
Entradas :
Salidas :
Mensaje desde el servicio de recepción de alertas.
Envío del reporte de eventualidad.
Descripción :
Se debe recibir y construir el reporte de eventualidad.
Resultados :
En reporte es enviado correctamente.
Cuadro 4.10: Prueba: Envío del mensaje de alerta
113
4.8. Etapa 6: Integración de componentes y pruebas
4.8.1.
Descripción
Como etapa final del ciclo de vida de desarrollo se realiza la integración de los
módulos antes desarrollados. Adicionalmente se complementa y aplica el plan de
pruebas definido por el modelo utilizado.
4.8.2.
Diseño detallado
El Diagrama de clases, indica como se realiza la interconexión y paso de mensajes
entre los módulos y clases del sistema, Figura 4.13.
4.8.3.
Pruebas
Se describen a continuación las pruebas a realizar para esta etapa. Los resultados
de las mismas se especifican en el siguiente Capítulo, con el fin de dar más detalle
sobre los datos, valores obtenidos y valores esperados.
4.8.3.1.
Pruebas de caja blanca
Estas pruebas, se enfocan principalmente en analizar el funcionamiento de la sección crítica del sistema integrado ahora con el resto del sistema.
4.8.3.2.
Pruebas de caja negra
Contemplando el sistema en conjunto, estas pruebas consisten en ejecutar de manera continua introduciendo señales conocidas de las cuales se conocen sus carac114
Figura 4.13: Diagrama de clases
115
terísticas, contrastando los resultados o reportes entregados por el sistema con la
información conocida de las señales de entrada.
116
Capítulo 5
Análisis de resultados
5.1.
Estabilidad y rendimiento
Dado que la herramienta desarrollada, constituye un prototipo funcional de la aplicación en conjunto. Se dará en esta sección una medida teórica de la estabilidad
de la aplicación basándose en las pruebas de funcionamiento de cada componente
y en la utilización de algunos patrones que favorecen la operación planeada de la
aplicación y en los conceptos derivados del modelo propuesto.
5.1.1.
Etapa 1 - funciones comunes
Sockets : La clase PracticalSocket permite la creación y manipulación de sockets
para cliente y servidor. Se probaron de manera independiente con programas
de ejemplo.
DSRCP : funciones para el manejo de esta estructura. Básicamente se grabaron y
leyeron datos de prueba generando archivos planos y comparándolos poste117
riormente.
XMLDSRC : funciones para el manejo de esta estructura. Se realizó un proceso similar al anterior, solo que se agregó el proceso de conversión de
XMLDSRC a DSRC y viceversa.
LOG : funciones para la lectura del archivo de mensajes. Se probaron de manera
independiente los procesos de registro de mensajes en consola.
5.1.2.
5.1.2.1.
Etapa 2 - Entrada y visualización
Módulo Servidor de Adquisición
Este programa se encarga de leer un archivo WVM, genera y asigna la estructura
DSRCP y posteriormente la convierte a XMLDSRC para dejarla disponible a través del servidor de sockets. El proceso de lectura de WVM se realizó de manera
independiente, comparando las señales con las obtenidas con otros programas.
5.1.2.2.
Módulo Cliente GUI
Este cliente en Java despliega las señales en un Applet. Se recibe del servidor de
adquisición la estructura XMLDSRC, se convierte a DSRCP y se posteriormente
se dibujan las ondas. Las estructuras DSRCP y XMLDSRC previamente probadas
funcionan correctamente.
5.1.3.
Etapa 3 - Núcleo Detector
El cliente de detección está compuesto por el cliente que recibe los datos en XMLDSRC,
los cuales se convierten a DSRCP. A la señal de entrada se le aplica el filtro Wa118
velet y enseguida se llama la función de detección desde el objeto Triggers, la cual
retorna una segunda estructura DSRCP. Las funciones de Triggers se han probado
de manera independiente con antelación. Aunque se hicieron cambios sobre tales
funciones en etapas posteriores, estos no afectaron el rendimiento del componente.
5.1.4.
Etapa 4 - Clasificación de eventualidades
Este componente codifica el filtro wavelet y las funciones de clasificación. Para el
filtro se utiliza código fuente ya existente, lo que favorece la etapa de mantenimiento y brinda cierto grado de confianza en cuanto a su estabilidad. La clasificación
se realiza basándose en reglas y fue probada de manera independiente. Resultados
explícitos de este proceso se pueden ver en 5.2.
5.1.5.
Etapa 5 - Servidor de Alertas
El servidor de alertas realiza el envío del reporte generado durante la clasificación.
Este componente es relativamente simple dado que sitúa un servidor que atiende
los llamados del detector y envía por email el reporte entregado.
5.1.6.
Discusión
El factor de estabilidad del sistema se observa en esta sección como una valor cualitativo de las pruebas individuales que han tenido los componentes del sistema. Sin
embargo, es posible diseñar y aplicar otros mecanismos de comprobación que ayuden a determinar con buen grado de confiabilidad, la estabilidad y el rendimiento
funcional de la herramienta.
119
5.2. Verificación y validación
Desde el punto de vista del funcionamiento de la aplicación, se tiene :
5.2.1.
Primera verificación
5.2.1.1.
Propósito
Verificar el funcionamiento de la detección y clasificación de eventualidades sobre
archivos previamente clasificados.
5.2.1.2.
Descripción
Se comparan los tiempos de ocurrencia de eventualidades como eventos sísmicos
y ruido, presentes en un conjunto de registros previamente almacenados y catalogados por el Área de Sismología del OSSO.
5.2.1.3.
Muestra
Se utilizarán 10 archivos previamente detectados y clasificados correspondientes a
diferentes periodos de la red de estaciones del OSSO.
5.2.1.4.
Resultados
El formato de reporte S-DCE se indica en A.2.2. Algunas convenciones utilizadas:
SW Corresponde a la detección y localización realizada por el Área de Sismología.
120
LOCAL Evento local, refiere al rango de cobertura con radio de 200Km desde el
centro de la red de estaciones.
REGIONAL Evento regional, refiere al rango de cobertura con radio entre 200 y
2000 Km desde el centro de la red de estaciones.
TELESISMO Evento telesísmico o lejano, refiere al rango de cobertura con radio
mayor a 2000 Km desde el centro de la red de estaciones.
RUIDO (NOISE) Presencia de condición de ruido o señal adherida no deseada.
Ver resultados Tabla 5.1.
5.2.2.
5.2.2.1.
Segunda verificación
Propósito
Comprobar el funcionamiento de la detección y clasificación de eventualidades
sobre datos continuos sin clasificar.
5.2.2.2.
Descripción
Se ingresa el conjunto de datos y se examinan los resultados de la aplicación, a fin
de compararlos con los resultados obtenidos de manera tradicional.
5.2.2.3.
Muestra
Se utilizará 1 día de datos correspondientes a señales de la red de estaciones del
Sur Occidente del OSSO.
121
Evento
Análisis
1995 04 06 - 10:31:11 S-DCE coincide en clasificarlo como evento LOCAL, con hora de
llegada del evento Apr 6 10:31:13 1995. Detalles en B.1.1.
1995 08 09 - 10:30:40 S-DCE coincide en clasificarlo como evento REGIONAL, con hora de llegada del evento Aug 9 10:30:50 1995. Detalles en B.1.2.
1995 07 16 - 16:40:26 S-DCE coincide en clasificarlo como evento LOCAL, con hora de
llegada del evento Jul 16 16:40:30 1995. Detalles en B.1.3.
1995 04 13 - 18:28:34 S-DCE ha clasificado este evento como REGIONAL, mientras SW
lo ha hecho como LOCAL. Sin embargo, 4 de los 9 canales han
sido clasificados como LOCAL. La hora de llegada del evento Apr
13 18:28:33 1995. Detalles en B.1.4.
1996 09 05 - 08:22:22 S-DCE ha clasificado este evento como LOCAL, mientras SW lo
ha hecho como TELESISMO. De acuerdo a las reglas aplicadas,
este tipo de clasificación depende muchas veces de la presencia de
otros factores que el mód. de clasificación no contempla. La hora
de llegada del evento Sep 5 08:22:28 1996. Detalles en B.1.5.
1996 11 15 - 02:53:06 S-DCE ha clasificado este evento como regional, mientras SW lo
ha hecho como LOCAL. Sin embargo, 4 de los 9 canales han sido
clasificados como LOCAL. La hora de llegada del evento Nov 15
02:53:13 1996. Detalles en B.1.6.
1998 11 07 - 03:10:46 S-DCE ha clasificado esta señal como RUIDO, mientras SW lo ha
hecho como LOCAL. Sin embargo, en 2 canales se ha identificado
como LOCAL. La hora de llegada del evento Nov 7 03:10:52 1998.
Detalles en B.1.7.
1998 12 03 - 00:55:35 S-DCE coincide en clasificarlo como evento LOCAL, con hora de
llegada del evento Dec 3 00:55:37 1998. Detalles en B.1.8.
1998 11 05 - 01:03:28 S-DCE ha clasificado este evento como LOCAL, mientras SW lo
ha hecho como REGIONAL. Sin embargo, en 2 canales fué declarado LOCAL y en otros 2 REGIONAL. La hora de llegada del
evento Nov 5 01:03:32 1998. Detalles en B.1.9.
1998 12 10 - 04:19:36 S-DCE ha clasificado esta señal como RUIDO, mientras SW lo ha
hecho como LOCAL. Sin embargo, en 3 canales se ha identificado
como LOCAL. La hora de llegada del evento Dec 10 04:19:41
1998. Detalles en B.1.10.
Cuadro 5.1: Resultados primera verificación
122
5.2.2.4.
Resultados
El formato de reporte S-DCE se indica en A.2.2. Algunas convenciones utilizadas:
SW Corresponde a la detección y localización realizada por el Área de Sismología.
LOCAL Evento local, refiere al rango de cobertura con radio de 200Km desde el
centro de la red de estaciones.
REGIONAL Evento regional, refiere al rango de cobertura con radio entre 200 y
2000 Km desde el centro de la red de estaciones.
TELESISMO Evento telesísmico o lejano, refiere al rango de cobertura con radio
mayor a 2000 Km desde el centro de la red de estaciones.
RUIDO (NOISE) Presencia de condición de ruido o señal adherida no deseada.
Ver resultados Tabla 5.2.
123
Evento
Análisis
2003 12 25 - 06:59:03 S-DCE ha clasificado este evento como LOCAL, mientras SW lo
ha hecho como TELESISMO. De acuerdo a las reglas aplicadas,
este tipo de clasificación depende muchas veces de la presencia de
otros factores que el mód. de clasificación no contempla. La hora
de llegada del evento Dec 25 06:57:26 2003. Detalles en B.2.1.
2003 12 25 - 07:13:00 S-DCE coincide en clasificarlo como evento REGIONAL, con hora de llegada del evento Dec 25 07:11:57 2003. Detalles en B.2.2.
2003 12 25 - 07:21:12 S-DCE clasifica esta señal como como evento LOCAL, con hora de llegada del evento Dec 25 07:21:12 2003. SW no muestra
información en su localización, pero considera que efectivamente corresponde a un evento, pero es muy dificil localizarlo por los
niveles de ruido y ondas del evento anterior. Detalles en B.2.3.
2003 12 25 - 08:55:20 S-DCE coincide en clasificarlo como evento LOCAL, con hora de
llegada del evento Dec 25 08:55:31 2003. Detalles en B.2.4.
2003 12 25 - 20:34:18 S-DCE ha clasificado este evento como LOCAL, mientras SW lo
ha hecho como REGIONAL. Sin embargo, en 2 canales fué declarado REGIONAL y en 4 LOCAL. La hora de llegada del evento
Dec 25 20:34:13. Detalles en B.2.5.
Cuadro 5.2: Resultados segunda verificación
124
Capítulo 6
Conclusiones
6.1.
Sobre el Modelo
Utilización de la ingeniería de software como mecanismo de aplicación y
evaluación de la eficiencia y calidad operacional de un sistema de función
crítica, visto como la definición de criterios de operación bajo condiciones
y límites establecidos por el sistema y por las características externas del
medio externo.
En el desarrollo de productos de software las etapas de análisis de requerimientos y diseño toma gran parte del tiempo del proyecto. El modelo planteado en este proyecto pretende establecer unos parámetros de diseño generales que permitan agilizar la implementación de proyectos tipo sistemas de
control por software, cuya base común es el procesamiento de señales digitales en busca de comportamientos de interés (caracterización de señales).
La utilización de un ciclo de vida específico para el desarrollo de software,
125
basado en las condiciones del tipo de problemas a tratar, constituye uno de
los alcances notables del modelo ofrecido. El ciclo de vida contempla la noción de fases generales que constituyen un marco de situación, estableciendo
fases de solución para un subproblema concreto.
Con el constante desarrollo e innovación de las tecnologías utilizadas en las
implementaciones de software, es deseable tener un modelo no dependiente
de mecanismos, métodos y plataformas específicas, adecuándolo a necesidades y ambientes particulares. Si bien se han utilizado conceptos de paradigmas como el de desarrollo orientado a objetos o sistemas en tiempo real, el
modelo ha buscado generalizarse para que su interpretación pueda hacerse
según condiciones singulares de los problemas a tratar.
La consideración de un mecanismo para realizar la gestión del riesgo hace
parte de los principios técnicos para el desarrollo de proyectos de ingeniería.
A nivel de la Ingeniería de software y del modelo planteado, la gestión actúa
como instrumento para el control de calidad y como guía para conocer las
limitaciones y características del ciclo de vida.
6.2. Sobre la herramienta
La implementación del software, constituye una aplicación y comprobación simple
del modelo descrito. Desde el punto de vista técnico, se han utilizado conceptos
básicos como :
Modularización que favorece el depuramiento y codificación de la aplicación durante el proceso de implementación. Durante el mantenimiento del
126
software, favorece en el entendimiento y adición de características.
Uso de protocolos y estándares abiertos para comunicaciones y programación, facilitando el paso de mensajes y datos entre módulos y métodos internos y externos.
Diversos lenguajes de programación, realizando implementación de algunos
módulos en lenguajes que ofrezcan mejores condiciones que otros en ambientes particulares de uso.
Siguiendo las actividades sugeridas en el modelo, se presentan beneficios al
tener una estructura homogénea y clara reflejada en el diseño y la codificación del producto de software.
La aplicación de las pruebas durante las etapas, permiten agilizar el proceso
de depuramiento, ya que no es necesario tener toda la aplicación funcionando, sinó que se diagnostica el funcionamiento de componentes más simples
y recientemente codificados.
Utilización de estructuras de datos de varios ordenes: la estructura DSRCP
como estructura nativa del lenguaje de programación es rápida en uso. la
estructura XMLDSRC como estructura de alto nivel, basada en etiquetas
facilita el transporte entre aplicaciones de diversos lenguajes y arquitecturas.
6.3.
Conclusiones generales
Se realizó la construcción de un modelo funcional para la caracterización de
señales.
127
Establecimiento de mecanismos para el procesamiento adaptativo, basado en
el comportamiento dinámico de las señales y las características generales del
procesamiento de señales digitales.
Implementación de un sistema de control por software, dando la categorización de sistema de control por sus condiciones de operación, construcción
de alto nivel y con la flexibilidad para personalizar, propio de los sistemas de
software.
Elaboración de una herramienta para la detección de eventos, independiente
de un sistema de adquisición específico.
Utilización de la plataforma Linux y el modelo de desarrollo de código
abierto (OpenSource), para la implementación de software robusto siguiendo principios de diseño de un sistema crítico y de bajo costo de construcción
en software y hardware.
Factibilidad de aplicación del modelo y desarrollo técnico a otras tipos de
problema que requieran procesamiento de señales, específicamente detección de cambios o eventualidades sobre señales digitales.
Con la propuesta de un modelo ’portable’ en cuanto a análisis y diseño se
observa la factibilidad de enfocarlo, bajo cierto nivel de abstracción a problemas similares en estructura, puntualizando en los detalles propios del sistema.
El modelo considera aspectos de gestión de proyectos, análisis, diseño del
software, gestión de riesgos, control de calidad, entre otros.
128
Bajo la idea de cómo se concibe este modelo, se puede evaluar si es posible
aplicar el concepto general a nuevos campos o ambientes, definiendo nuevos
modelos generales que puedan ser correspondientes a tipos de problemas
específicos. Parte de la utilidad que tendría, es el poder agilizar la producción de software, sin comprometer la no realización de actividades como el
análisis y diseño, poniendo en riesgo el desarrollo del proyecto.
129
130
Capítulo 7
Trabajo futuro y
recomendaciones
Este trabajo se ha enfocado principalmente en proponer un modelo de diseño general que permita su aplicación a problemas relacionados con procesamiento de
señales, específicamente de cambios abruptos o detección de eventualidades (como el efecto de estar sujeto a cualquier evento o contingencia) sobre la señal y su
uso como sistema de control para aplicaciones de uso crítico.
El enfoque de sistema crítico para aplicaciones industriales y científicas ha estado
dirigido a implementaciones en hardware y firmware, de alto costo, que son de uso
específico, pero necesarias por su alto grado de confiabilidad. Sin embargo, algunos sistemas pueden establecer un umbral de confiabilidad en límites ajustables a
la relación costo - beneficio y prestaciones. El modelo y las implementaciones no
pretenden reemplazar sistemas de misión crítica complejos o de tiempo real duro,
131
cuyos requerimentos exigen el uso de componente de hardware para lograr la velocidad y confiabilidad necesaria.
Si bien la implementación realizada aporta elementos para satisfacer necesidades
del problema detectado en el sistema, se pueden realizar mejoras y adiciones técnicas a la solución. El modelo planteado presenta una gama de oportunidades en
cuanto a futuros desarrollos teóricos y prácticos:
A nivel práctico, con la investigación y mejoramiento de las técnicas de inteligencia artificial y los métodos de computación matemática, el procesamiento de señales digitales podrá realizar gran cantidad de tareas, y si estas
a su vez son retroalimentadas o conectadas a otros sistemas se supone una
arquitectura general compuesta por macro-componentes funcionales por sí
mismos e interoperables con otros.
A nivel teórico, ampliando y redefiniendo las conceptos, estructuras y métodos mediante la experimentación con casos de aplicación.
132
Bibliografía
[BN99]
Baseville, Michele and Nikiforov, Igor V. 1999, Detection of
Abruptes changes: Theory and application.
[JHC00]
Caicedo, Jhon Henry. 2000. Diseño e implementación de un sistema de supervisión en tiempo real para adquisición continua de
datos usando Linux. Universidad del Valle.
[BW94]
Burns, A. and Wellings, A.J. 1994. A Structured Design method
for Hard Real-time Systems. Real-time and Destributed Systems
Research Group, Department of Computer Science University of
York.
[BM01]
Blais,
Andrew
introduction
and
to
Mertz,
neural
David.
networks.
2001
.
An
http://www-
106.ibm.com/developerworks/linux/library/lneural/?dwzone=linux
[DG94]
Dennis Lawrence, J. and Gary Preckshot, G. 1994. Design Factors
for Safety-Critical Software. Lawrence Livermore National Laboratory.
133
[FH98]
Fedorenki, Yu. V. and Husebye, Eystein. 1998. Simulating Seismic
Signal Detectors.
[FB98]
Fisk, Mark and Bottone, Steven . 1998. Event characterization
using regional seismic data. Mission Research Corporation.
[GEM98]
Gendron, Paul; Ebel, Jhon and Manolakis, Dimitris. 1998. Automatic Seismic Event Detection , Characterization and Classification
: A Probabilist Approach.
[CHT98]
Hayward, Christopher T. 1998. An evaluation of the GSET-T3 prototype International Data Center Seismic Signal Detector.
[JK02]
Kitter, J. 2002. Notas del Seminario de Reconocimiento de Patrones. Universidad de Surrey.
[Kuo96]
Kuo, Benjamin C. 1996. Sistemas de control automático 7a Edición. ISBN 968-880-723-0.
[CL99]
Larman, Craig. 1999. UML y Patrones. ISBN:970-17-0261-1.
[LEE91]
Lee, W.H.K and Stewart, S.W. 1981. Principles and applications
of microearthquake networks.
[LF94]
Linville, A. Frank. 1994. Single-channel digital filter design for
seismic applications.
[SM96]
McConnell, Steve. 1996. Desarrollo y gestión de proyectos informáticos. Microsoft Press. ISBN:84-481-1229-6
134
[MDH02]
Merchant, Bion J.; Drake, Jeffrey T.; Hart, Darren; Young, Christopher J. 2002. Multiple Algorithm Signal Detection using Neural
Networks. 24th Seismic Research Review.
[PTV92]
Press, William, Teulkosky Saul, Vetterling William, Flannery
Brian. 1992. Numerical recipes in C: the art in scientific computing. 2da. Edición. Cambrigde Press ISBN:0-521-43108-5
[PGN00]
Neumann, Peter G. 2000. Practical Architectures for Survivable
Systems and Networks. Computer Science Laboratory SRI International.
[ISO12207-1] Norma ISO 12207-1.
[RSP98]
Pressman, Roger S. 1998. Ingeniería de software: un enfoque práctico. 4ta. Edición. ISBN:0-07-052182-4.
[RC92]
Roberto, Vito and Chiaruttini, Claudio. 1992. Seismic Signal Understanding: A knowlegde-Based Recognition System. IEEE Transactions on signal processing
[RD97]
R&D Programme in Safety Critical Systems. Advances in Safety
Critical Systems Results and Achievements from the DTI/EPSRC
Compiled and Edited by Mike Falla JUNE 1997
[SRC02]
Seismology Research Centre, 2002, Guria V5.05 Manual - Trigger
Algorithms.
http://www.seis.com.au/InstAndSoft/Manuals/G_V505_Manual/TriggerAlgorithm.html
135
[SRC00]
Seismology Research Centre. 2000. Earthquake Preparation, Alarm
and Response Service.
[SWS99]
Smith, Steven W. 1999. The Scientist an Engineer’s Guide to Digital Signal Processing. California Techical. Publishing. ISBN 09660176-6-8.
[SS99]
Soliman, Samir S. and Srinath, Mandyam D. 1999. Señales y Sistemas continuos y discretos. 2a edición. ISBN 84-8322-154-3.
[SPIHT]
SPIHT,
Análisis
de
señales
mediante
wavelets.
2003
http://coco.ccu.uniovi.es/immed/compresion/descripcion/spiht/wavelets/wavelets.htm
[TC98]
Torrence, Christopher and Compo, Gilbert P. 1998. A Practical
Guide to Wavelet Analysis.
136
Apéndice A
Estructuras de control
A.1.
Flujo de datos
A.1.1.
Estructura DSRCP
La estructura DSRCP (Data SouRCe Protocol ) se creó teniendo en cuenta:
Estructura residente en memoria primaria.
Permite manejo de información de diversas fuentes.
Independencia del formato nativo de los sistemas de adquisición.
count : cantidad de canales o flujos de datos.
DSRCmsg 1
DSRCmsg 2
...
DSRCmsg count
Descripción
struct dsrc_data_array
137
{
int count;
struct dsrc_data_msg **msg;
};
struct dsrc_data_msg_header
{
char network[STA_ID_LEN + 1];
char sta[STA_ID_LEN + 1];
char stream[STREAM_ID_LEN + 1];
char chan[CHAN_ID_LEN + 1];
double stime; //start time
double etime; //end time
int nsamp;
//number of samples
int samprate; //samples rate
};
struct dsrc_data_msg
{
struct dsrc_data_msg_header hdr;
int maxsamp;
int *data;
//array data
};
A.1.2. Estructura XMLDSRC
<?XML S-DCE_DSRC_1.0 ?>
138
<DS_ARRAY>
<COUNT>countvalue</COUNT>
<DS_MSG>XMLMSG-1</DS_MSG>
<DS_MSG>XMLMSG-2</DS_MSG>
. . .
<DS_MSG>XMLMSG-countvalue</DS_MSG>
</DS_ARRAY>
<DS_MSG>
<DS_HDR>XMLHDR</DS_HDR>
<MXSM>maxsampvalue</MXSM>
<DS_DATA>XMLDATA[maxsampvalue]</DS_DATA>
</DS_MSG>
<DS_HDR>
<NET>netvalue</NET>
<STA>stationvalue</STA>
<STR>streamvalue</STR>
<CHN>channelvalue</CHN>
<STM>starttimevalue</STM>
<ETM>endtimevalue</ETM>
<NSM>numsampvalue</NSM>
<SRT>sampratevalue</SRT>
</DS_HDR>
<DS_DATA>
<I>samplevalue-1</I>
. . .
139
<I>samplevalue-numsampvalue</I>
</DS_DATA>
A.1.3.
Comunicaciones
Los sockets son un mecanismo o interfaz para comunicaciones, que habilitan las
aplicaciones a operar localmente o a través de una red de datos. Ejemplos de su
aplicación son comunes en aplicaciones Unix como ftp, rlogin, telnet, etc.
A.1.3.1.
Tareas de un Servidor sockets
Paso 1: Crear un socket
Paso 2: Nombrar el socket
Paso 3: Servidor de procesos asigna una cola para escuchar
Paso 4: Servidor espera por una conexión
A.1.3.2.
Tareas de un Cliente sockets
El cliente crea un socket sin nombre, mediante un llamado a la función socket().
El cliente que usa la función connect(), establece una conexión al servidor usando
el nombre del servidor y la dirección de acceso del socket (puerto).
A.1.4.
Registro de mensajes
La siguiente estructura permite el almacenamiento de los mensajes utilizados para
el registro en consola (LOG) y la generación de reportes en el módulo de alertas.
140
typedef struct _dcelog {
char logid [128];
char logmod [512];
char logdesc [MXLINE];
char logact [MXLINE];
char logstat [MXLINE];
} dcelog;
A.1.5. Formato WVM
Especificación del formato WVM utilizado en el OSSO:
typedef struct _station_info {
char station_id[11];
/* Nombre Estacion Max 10 Chars */
UWORD channel;
/* Canal */
char unused_fields[12]; /* No usados, 12 caracteres */
} station_info;
typedef struct _time_info {
INTEGER time;
/* Segundos desde 1970 (epoch) GMT */
UWORD millitm;
/* Milisegundos */
WORD timezone;
/* ???? 0x01E0 = 480 en OSSO ? */
WORD dstflag;
/* 0x0001 en OSSO ? */
} time_info;
typedef struct _wvmheader {
WORD
magic_number;
/* Siempre 00FF */
UWORD channel_length;
/* 0200 en OSSO */
141
WORD
scan_count;
/* 0009 Numero de Canalaes */
FLOAT srate;
/* E7 9C C9 42->100.81 Hz */
UWORD channel_list[16];
/* Orden de Dig de Canales */
UWORD gain_list[16];
/* Ganancia de cada canal */
WORD
/* Todos cero en OSSO ? */
channel_stat_list[32];
station_info station_list[16];
/* Datos de las estaciones */
time_info trigger_time;
/* Hora del Evento */
time_info channel_start_time;
/* Hora inicio grabacion */
char cal_channel_start_time[10]; /* Unused 10 chars */
char unused[472];
/* No usados */
} wvmheader;
A.2.
Configuraciones
A.2.1. Parámetros de configuración general
/*
Archivo
: dceconfig.h
Proyecto
: S-DCE
Descripcion : Parametros de configuracion del sistema
*/
#ifndef __DCE_CONFIG_H
#define __DCE_CONFIG_H
/****
Variables Adquisicion
142
****/
// Numero Maximo de Canales
#define DCE_NET
"OSSO"
// Numero Maximo de Canales
#define DCE_NCHAN
16
#define WVM_BLOCK
512
#define WVM_NUMBL
64
/****
Variables Deteccion
****/
#define STA_WINDOW_S
1
#define LTA_WINDOW_S
10
#define RATIO_TRIGG
1.5
#define RATIO_DTRIG
1.3
#define SOFT_PEND
1.1
#define PEM_SEC
5
#define PET_SEC
5
/****
Variables Comunicaciones
****/
// Configuracion Servidor de Sockets/Clientes
#define DCE_ADQPORT
43210
#define DCE_ADQHOST
"localhost"
#define DCE_ALERTPORT
43211
#define DCE_ALERTHOST
"localhost"
143
// Identificacion de los modulos S-DCE
#define DCE_MODADQ
"mod_adq"
#define DCE_MODALR
"mod_alert"
#define DCE_MODCLA
"mod_classif"
#define DCE_MODGUI
"mod_gui"
#define DCE_SDETEC
"s-detect"
// Localizacion Base de errores
#define DCE_LOG_FILE "dcelog.msg"
#endif
A.2.2. Emisión de alertas
Como actuador del sistema de control, el proceso de emisión de alertas es un módulo completamente abierto a implementación del usuario. Una vez el detector
determina la ocurrencia de eventualidades envía un reporte a la emisión de alertas
el cual determinará qué hacer con éste.
En una primera versión del componente de emisión de alertas, el reporte se envía
a una dirección de correo, a través de la función setMedia(). La utilidad principal de este sub-sistema consiste en que puede ser construido en diversas etapas o
realizar diversas acciones por una sola alerta. El formato utilizado se describe a
continuación:
S-DCE v.
S-DCE y versión utilizada
144
Esta seccion hace un resumen de la detección
< <Alert Report > >
y clasificación.
TRIGGER Apply [FUNCTION].
Found in [N] Channels.
FUNCTIONS especifica la función o meca[CLASSTYPE]
generate
aprox. at [DATE TIME]
trigger,
nismo utilizado para realizar la clasificación.
N, indica el número de canales en los que se
activado el
DETECTOR .
CLASSTYPE indica
el tipo de clasificación que se presenta en la
mayoría de los canales. DATE TIME es la
menor hora de la EVENTUALIDAD detectada.
< <Channels Details > >
Esta sección presenta en detalle los datos de
detección y clasificación para cada canal.
145
[GENTYPE
detected
in
[NETWORK]-[CHAN]]
-
Declared
[OTHERCOND]
[CONDVALS].
[CLASSTYPE]
at
[DATE
TI-
ME][CLASSVALS].
GENTYPE, muestra el tipo general de la cla[GENTYPE
detected
in
sificación. NETWORK corresponde a la Red
[NETWORK] - [CHAN]]
de donde provienen los datos y CHAN el ca-
-
nal específico. OTHERCOND y CONDVALS
Declared
[OTHERCOND]
es una característica extra, junto con el va-
[CONDVALS].
[CLASSTYPE]
at
[DATE
TI-
ME][CLASSVALS].
lor asociado. CLASSTYPE indica para cada
canal el tipo de clasificación obtenido. DATE TIME la hora de la
EVENTUALIDAD
y
CLASSVALS algunos valores característicos
asociados a la clasificación.
A.2.3.
Manejo de errores
Como plataforma para el control de excepciones y errores del sistema se tiene:
A.2.3.1.
Operaciones de control
Las señales de control del sistema son:
146
OK Las operaciones se ejecutaron exitosamente.
WARNING Se ha detectado una eventualidad.
ERROR Se ha presentado un error en uno de los componentes. Sin embargo, se
puede continuar.
FATAL Error irreparable. Intervención del operador es requerida inmediatamente.
Si las señales son OK o WARNING el registro en consola es de aviso y se reporta
como
Mod_DCE [dcelog.logid] - dcelog.logdesc (dcelog.stat)
Si las señales son ERROR o FATAL el registro incluye una acción sugerida:
Mod_DCE [dcelog.logid] - dcelog.logdesc (dcelog.stat) : dcelog.logact
A.2.3.2.
Base de mensajes
La base contiene los mensajes que se reportan sobre consola cuando se presentan
señales de control que permitan evaluar el estado de funcionamiento de la aplicación. La base de mensajes tiene dos fuentes:
Mensajes generados de acuerdo al procesamiento (detección y clasificación)
que se realiza. Estos mensajes son generados OnFly (en tiempo de ejecución).
Mensajes tomados de archivos planos con estados y comportamientos previamente definidos. Para S-DCE, la base tiene los siguientes registros.
147
# DCE System Messages
#id{
#
Componente
#
Descripcion
#
Accion
#
Estado: OK, ERROR, FATAL, WARNING
#}
COM1{
COMMUNICATIONS
Connect to Adq_Server
Recv signals
OK
}
COM2{
COMMUNICATIONS
Connect to Adq_Server
Can’t connect to server. Please check this..
FATAL
}
COM3{
COMMUNICATIONS
Connect to Alert_Server
Sending Alert Msg
OK
}
148
COM4{
COMMUNICATIONS
Connect to Alert_Server
Can’t connect to server. Please check this..
ERROR
}
COM5{
COMMUNICATIONS
Error recv data
Zero data receive from server
FATAL
}
COM6{
COMMUNICATIONS
adqServer Starting
fine!
OK
}
COM7{
COMMUNICATIONS
adqServer Starting
Can’t begin socket ServerThread
FATAL
}
COM8{
149
COMMUNICATIONS
adqServer threading
Can’t create thread. Please check..
FATAL
}
ACQ1{
ACQUISITION
Reading dataInputStream
Can’t open datasource
FATAL
}
ALR1{
REPORT
Critical, report no send
report resource no available
ERROR
}
DET1{
DETECTOR
DSRC format is incorrect
Can’t read dsrc format. Please Check.
FATAL
}
DET2{
TRIGGER
150
Trigger condition match
Possible eventualitie..
WARNING
}
151
152
Apéndice B
Pruebas S-DCE
B.1.
Eventos previamente detectados
Eventos localizados por la red SW del OSSO versus S-DCE.
B.1.1. Evento 1995 04 06 - 10:31:11
ESTACION HORA EVENTO
TIPO
DURACION
HOBC E P 1 950406103111.34
480.1
L
75.
690.1
ANCC E P 2 950406103123.08
110.2 39.3 E S 2
L
109. 160.3
DIAC E P 2 950406103122.33
50.2
L
103. 50.2
HOQC E P 2 950406103122.33
80.1
L
108. 100.2
PEIC E P+1 950406103115.20
50.1
L
78.
50.3
CLMC I P C 0 950406103117.41
290.1
L
93.
260.1
AZUC E P 2 950406103117.42
160.2
L
121. 120.3
153
—————
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 9 channels.EV.LOCAL generate trigger, aprox. at Thu Apr 6 10:31:13 1995 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC .local event at Thu Apr 6 10:31:13 1995 COT
s-p(6).
EVENT detected in OSSO - ANCC - Declared HARD AmpP(1) AmpE(58).regional
event at Thu Apr 6 10:31:25 1995 COT s-p(18).
EVENT detected in OSSO - DIAC .local event at Thu Apr 6 10:31:31 1995 COT
s-p(12).
NOISE detected in OSSO - PURC .Signal pick at Thu Apr 6 10:37:00 1995 COT
Dur(1).
EVENT detected in OSSO - HOQC - Declared HARD AmpP(2) AmpE(20).regional
event at Thu Apr 6 10:31:24 1995 COT s-p(17).
EVENT detected in OSSO - PEIC - Declared HARD AmpP(3) AmpE(25).local
event at Thu Apr 6 10:31:17 1995 COT s-p(10).
EVENT detected in OSSO - CLMC - Declared HARD AmpP(8) AmpE(76).local
event at Thu Apr 6 10:31:19 1995 COT s-p(13).
EVENT detected in OSSO - AZUC - Declared HARD AmpP(1) AmpE(69).local
event at Thu Apr 6 10:31:22 1995 COT s-p(10).
EVENT detected in OSSO - SILC .local event at Thu Apr 6 10:31:38 1995 COT
s-p(4).
154
B.1.2. Evento 1995 08 09 - 10:30:40
ESTACION HORA EVENTO
TIPO
DURACION
HOBCiPd0 950809103046.58
480.5
R
307.
440.6
ANCCeP+1 950809103101.16
800.4
R
293.
600.6
DIACiPd0 950809103057.48
430.5
R
289.
540.5
PURCeP+1 950809103110.12
340.4
R
257.
240.7
PEICeP 2 950809103040.05
310.5
R
230.
240.6
SALCeP+1 950809103104.56
80.3
R
253.
80.7
CLMCeP+1 950809103055.21 1010.4
R
277.
810.5
AZUCeP-1 950809103053.21
500.3
R
309.
610.5
SILCeP-1 950809103104.40
420.3
R
373.
510.6
—————
155
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 10 channels.
EV.REGIONAL generate trigger, aprox. at Wed Aug 9 10:30:50 1995 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC - Declared HARD AmpP(11) AmpE(201). local
event at Wed Aug 9 10:30:50 1995 COT s-p(3).
EVENT detected in OSSO - ANCC - Declared HARD AmpP(5) AmpE(337). local
event at Wed Aug 9 10:31:06 1995 COT s-p(1).
EVENT detected in OSSO - DIAC - Declared HARD AmpP(8) AmpE(229). regional
event at Wed Aug 9 10:31:00 1995 COT s-p(64).
EVENT detected in OSSO - PURC . local event at Wed Aug 9 10:31:16 1995 COT
s-p(1).
EVENT detected in OSSO - HOQC - Declared HARD AmpP(9) AmpE(248). regional event at Wed Aug 9 10:31:04 1995 COT s-p(63).
EVENT detected in OSSO - PEIC - Declared HARD AmpP(23) AmpE(139). regional event at Wed Aug 9 10:30:53 1995 COT s-p(25).
EVENT detected in OSSO - SALC - Declared HARD AmpP(6) AmpE(98). regional
event at Wed Aug 9 10:31:10 1995 COT s-p(71).
EVENT detected in OSSO - CLMC - Declared HARD AmpP(10) AmpE(128). regional event at Wed Aug 9 10:31:00 1995 COT s-p(59).
EVENT detected in OSSO - AZUC . regional event at Wed Aug 9 10:31:00 1995
COT s-p(51).
EVENT detected in OSSO - SILC - Declared HARD AmpP(7) AmpE(251). regional
event at Wed Aug 9 10:31:09 1995 COT s-p(69).
156
B.1.3. Evento 1995 07 16 - 16:40:26
ESTACION HORA EVENTO
TIPO
DURACION
HOBCiPc0 950716164029.10
270.1 39.6eS 1
L
75.
610.1
HOQCeP-1 950716164029.18
110.1
L
97.
120.1
CLMCeP-1 950716164026.41
250.1
L
83.
370.1
AZUCiPd0 950716164030.55
260.2
L
84.
90.3
—————
157
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 10 channels.
EV.LOCAL generate trigger, aprox. at Sun Jul 16 16:40:30 1995 COT.
< <Channels Details > >
NOISE detected in OSSO - HOBC . Signal pick at Sun Jul 16 16:40:42 1995 COT
Dur(3).
EVENT detected in OSSO - ANCC - Declared HARD AmpP(4) AmpE(45). local
event at Sun Jul 16 16:40:33 1995 COT s-p(14).
EVENT detected in OSSO - DIAC - Declared HARD AmpP(2) AmpE(46). local
event at Sun Jul 16 16:40:35 1995 COT s-p(15).
EVENT detected in OSSO - PURC . local event at Sun Jul 16 16:46:00 1995 COT
s-p(5).
EVENT detected in OSSO - HOQC - Declared HARD AmpP(0) AmpE(16). local
event at Sun Jul 16 16:40:31 1995 COT s-p(10).
NOISE detected in OSSO - PEIC . Signal pick at Sun Jul 16 16:41:01 1995 COT
Dur(2).
NOISE detected in OSSO - SALC . Signal pick at Sun Jul 16 16:40:41 1995 COT
Dur(4).
EVENT detected in OSSO - CLMC - Declared HARD AmpP(6) AmpE(52). local
event at Sun Jul 16 16:40:30 1995 COT s-p(7).
EVENT detected in OSSO - AZUC - Declared HARD AmpP(0) AmpE(73). local
event at Sun Jul 16 16:40:33 1995 COT s-p(13).
EVENT detected in OSSO - SILC - Declared HARD AmpP(2) AmpE(10). regional
event at Sun Jul 16 16:40:44 1995 COT s-p(18).
158
B.1.4. Evento 1995 04 13 - 18:28:34
ESTACION HORA EVENTO
TIPO
DURACION
HOBCiPd0 950413182832.20 9990.1
L
217.
9990.1
ANCCiPc0 950413182838.01 9990.2
L
253.
9990.2
DIACiPc0 950413182839.86 9990.1
L
267.
9990.2
PURCeP 1 950413182852.87
20.1
L
102.
10.1
HOQCiPc0 950413182838.09 1240.1
L
213.
9990.1
PEICiPd0 950413182834.68 9990.2
L
141.
9990.3
CLMCiPc0 950413182834.56 9990.2
L
183.
9990.3
AZUCeP-1 950413182836.37 9990.1
L
264.
9990.3
SILCeP+1 950413182847.27
L
298.
520.2
500.2
—————
159
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 9 channels.
EV.REGIONAL generate trigger, aprox. at Thu Apr 13 18:28:33 1995 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC - Declared HARD AmpP(37) AmpE(492). regional event at Thu Apr 13 18:28:33 1995 COT s-p(28).
EVENT detected in OSSO - ANCC - Declared HARD AmpP(3) AmpE(805). local
event at Thu Apr 13 18:28:42 1995 COT s-p(13).
EVENT detected in OSSO - DIAC - Declared HARD AmpP(3) AmpE(667). regional
event at Thu Apr 13 18:28:42 1995 COT s-p(24).
EVENT detected in OSSO - PURC - Declared HARD AmpP(1) AmpE(10). local
event at Thu Apr 13 18:28:57 1995 COT s-p(1).
EVENT detected in OSSO - HOQC - Declared HARD AmpP(2) AmpE(396). regional event at Thu Apr 13 18:28:40 1995 COT s-p(24).
EVENT detected in OSSO - PEIC - Declared HARD AmpP(10) AmpE(690). local
event at Thu Apr 13 18:28:38 1995 COT s-p(14).
EVENT detected in OSSO - CLMC . local event at Thu Apr 13 18:28:42 1995 COT
s-p(10).
EVENT detected in OSSO - AZUC - Declared HARD AmpP(66) AmpE(867). regional event at Thu Apr 13 18:28:42 1995 COT s-p(16).
EVENT detected in OSSO - SILC - Declared HARD AmpP(64) AmpE(341). regional event at Thu Apr 13 18:28:54 1995 COT s-p(27).
160
B.1.5. Evento 1996 09 05 - 08:22:22
ESTACION
HORA EVENTO
TIPO
HOBCeP 2 960905082232.51
321.9
T
ANCCeP 2 960905082223.91
470.8
T
DIACeP 2 960905082226.77
241.3
T
PURCeP 2 960905082222.69
541.2
T
HOQCeP 2 960905082225.19
651.8
T
PEICeP 4 960905082237.12
80.9
T
SALCeP 2 960905082222.47
91.1
T
CLMCeP 2 960905082227.68
441.3
T
AZUCeP 2 960905082228.55
351.3
T
SILCeP 2 960905082223.93
661.0
T
—————
161
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 10 channels.
EV.LOCAL generate trigger, aprox. at Thu Sep 5 08:22:28 1996 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC - Declared HARD AmpP(18) AmpE(114). local
event at Thu Sep 5 08:22:37 1996 COT s-p(7).
EVENT detected in OSSO - ANCC - Declared HARD AmpP(5) AmpE(293). local
event at Thu Sep 5 08:22:28 1996 COT s-p(7).
EVENT detected in OSSO - DIAC - Declared HARD AmpP(2) AmpE(183). regional
event at Thu Sep 5 08:22:32 1996 COT s-p(27).
EVENT detected in OSSO - PURC . local event at Thu Sep 5 08:22:31 1996 COT
s-p(4).
EVENT detected in OSSO - HOQC - Declared HARD AmpP(11) AmpE(158). local
event at Thu Sep 5 08:22:32 1996 COT s-p(10).
EVENT detected in OSSO - PEIC - Declared HARD AmpP(6) AmpE(35). local
event at Thu Sep 5 08:22:51 1996 COT s-p(2).
NOISE detected in OSSO - SALC . Signal pick at Thu Sep 5 08:22:30 1996 COT
Dur(2).
EVENT detected in OSSO - CLMC . local event at Thu Sep 5 08:32:11 1996 COT
s-p(2).
EVENT detected in OSSO - AZUC - Declared HARD AmpP(1) AmpE(168). local
event at Thu Sep 5 08:22:32 1996 COT s-p(9).
EVENT detected in OSSO - SILC - Declared HARD AmpP(64) AmpE(324). local
event at Thu Sep 5 08:22:31 1996 COT s-p(4).
162
B.1.6. Evento 1996 11 15 - 02:53:06
ESTACION
HORA EVENTO
TIPO
DURACION
HOBCeP 2 961115025339.16
130.2
L
109.
140.5
DIACeP 2 961115025321.36
740.2 40.2eS 3
L
214.
650.2
PURCiPc0 961115025306.50 9990.2
L
166.
9990.2
HOQCeP+1 961115025325.90
350.2
L
106.
360.2
CLMCeP-1 961115025331.47
160.2
L
109.
230.4
AZUCeP+1 961115025328.39
310.3
L
182.
330.5 SILCiPc0 961115025311.28 9990
—————
163
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 10 channels.
EV.REGIONAL generate trigger, aprox. at Fri Nov 15 02:53:13 1996 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC - Declared HARD AmpP(3) AmpE(78). regional
event at Fri Nov 15 02:53:44 1996 COT s-p(32).
NOISE detected in OSSO - ANCC . Signal pick at Fri Nov 15 02:58:51 1996 COT
Dur(1).
EVENT detected in OSSO - DIAC - Declared HARD AmpP(5) AmpE(330). regional
event at Fri Nov 15 02:53:24 1996 COT s-p(18).
EVENT detected in OSSO - PURC - Declared HARD AmpP(112) AmpE(630). local
event at Fri Nov 15 02:53:13 1996 COT s-p(1).
EVENT detected in OSSO - HOQC - Declared HARD AmpP(2) AmpE(133). regional event at Fri Nov 15 02:53:28 1996 COT s-p(22).
NOISE detected in OSSO - PEIC . Signal pick at Fri Nov 15 02:57:09 1996 COT
Dur(1).
NOISE detected in OSSO - SALC . No signal Fri Nov 15 03:04:06 1996 COT
Dur(2).
EVENT detected in OSSO - CLMC - Declared HARD AmpP(4) AmpE(76). regional
event at Fri Nov 15 02:53:35 1996 COT s-p(29).
EVENT detected in OSSO - AZUC - Declared HARD AmpP(20) AmpE(195). regional event at Fri Nov 15 02:53:34 1996 COT s-p(21).
EVENT detected in OSSO - SILC - Declared HARD AmpP(1) AmpE(361). local
event at Fri Nov 15 02:53:14 1996 COT s-p(9).
164
B.1.7. Evento 1998 11 07 - 03:10:46
ESTACION
HORA EVENTO
ANCCeP+1 981107031046.81
TIPO DURACION
120.1 51.3eS 3 L
52.
370.1
DIACeP-1 981107031057.21
40.1
L
40.
20.1
HOQCiPd0 981107031049.93
40.1 56.8eS 3 L
42.
70.1
SALCeP 2 981107031055.94
30.1
—————
165
L
60.2
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 9 channels. NOISE
generate trigger, aprox. at Sat Nov 7 03:10:52 1998 COT.
< <Channels Details > >
NOISE detected in OSSO - HOBC . No signal Sat Nov 7 03:16:05 1998 COT
Dur(1).
EVENT detected in OSSO - ANCC . local event at Sat Nov 7 03:10:52 1998 COT
s-p(1).
NOISE detected in OSSO - DIAC . Signal pick at Sat Nov 7 03:10:58 1998 COT
Dur(3).
NOISE detected in OSSO - PURC . No signal Sat Nov 7 03:14:35 1998 COT
Dur(2).
EVENT detected in OSSO - HOQC . local event at Sat Nov 7 03:10:57 1998 COT
s-p(1).
NOISE detected in OSSO - PEIC . Signal pick at Sat Nov 7 03:13:52 1998 COT
Dur(2).
NOISE detected in OSSO - SALC . Signal pick at Sat Nov 7 03:10:57 1998 COT
Dur(2).
NOISE detected in OSSO - AZUC . No signal Sat Nov 7 03:15:59 1998 COT Dur(2).
EVENT detected in OSSO - HUIC - Declared HARD AmpP(3) AmpE(21). regional
event at Sat Nov 7 03:11:15 1998 COT s-p(22).
166
B.1.8. Evento 1998 12 03 - 00:55:35
ESTACION
HORA EVENTO
TIPO DURACION
ANCCeP 2 981203005537.33
30.0
L
24.
60.1
HOQCeP+1 981203005535.59
40.0 39.8eS 3 L
23.
70.1
SALCeP 2 981203005536.80
20.0 42.1eS 3 L
23.
120.1
—————
167
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 8 channels.
EV.LOCAL generate trigger, aprox. at Thu Dec 3 00:55:37 1998 COT.
< <Channels Details > >
NOISE detected in OSSO - HOBC . No signal Thu Dec 3 01:01:00 1998 COT
Dur(1).
EVENT detected in OSSO - ANCC - Declared HARD AmpP(3) AmpE(29). local
event at Thu Dec 3 00:55:38 1998 COT s-p(5).
EVENT detected in OSSO - DIAC . local event at Thu Dec 3 00:55:37 1998 COT
s-p(2).
EVENT detected in OSSO - HOQC . local event at Thu Dec 3 00:55:41 1998 COT
s-p(1).
EVENT detected in OSSO - PEIC . local event at Thu Dec 3 00:55:45 1998 COT
s-p(1).
EVENT detected in OSSO - SALC - Declared HARD AmpP(3) AmpE(30). local
event at Thu Dec 3 00:55:43 1998 COT s-p(1).
EVENT detected in OSSO - AZUC - Declared HARD AmpP(0) AmpE(1). local
event at Thu Dec 3 00:58:18 1998 COT s-p(8).
NOISE detected in OSSO - HUIC . Signal pick at Thu Dec 3 01:01:17 1998 COT
Dur(1).
B.1.9. Evento 1998 11 05 - 01:03:28
ESTACION
HORA EVENTO
TIPO
168
ANCCeP 2 981105010328.76
200.3
R
DIACeP 2 981105010338.40
10.2
R
HOQCeP 3 981105010333.31
30.1
R
PEICeP-1 981105010330.60
30.2
R
—————
169
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 9 channels.
EV.LOCAL generate trigger, aprox. at Thu Nov 5 01:03:32 1998 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC . local event at Thu Nov 5 01:06:23 1998 COT
s-p(2).
EVENT detected in OSSO - ANCC - Declared HARD AmpP(7) AmpE(69). regional
event at Thu Nov 5 01:03:32 1998 COT s-p(28).
EVENT detected in OSSO - DIAC - Declared HARD AmpP(2) AmpE(15). regional
event at Thu Nov 5 01:03:41 1998 COT s-p(22).
NOISE detected in OSSO - PURC . No signal Thu Nov 5 01:05:41 1998 COT
Dur(1).
EVENT detected in OSSO - HOQC - Declared HARD AmpP(0) AmpE(1). local
event at Thu Nov 5 01:08:58 1998 COT s-p(1).
EVENT detected in OSSO - PEIC . local event at Thu Nov 5 01:06:30 1998 COT
s-p(2).
NOISE detected in OSSO - SALC . Signal pick at Thu Nov 5 01:03:52 1998 COT
Dur(3).
NOISE detected in OSSO - AZUC . No signal Thu Nov 5 01:09:45 1998 COT
Dur(1).
NOISE detected in OSSO - HUIC . No signal Thu Nov 5 01:06:28 1998 COT
Dur(1).
170
B.1.10.
Evento 1998 12 10 - 04:19:36
ESTACION
HORA EVENTO
TIPO
HOQCeP 2 981210041941.38
10.0 48.1eS 3 L
30.1
SALCeP 2 981210041936.57
20.1 39.7eS 3 L
80.1
—————
171
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 8 channels. NOISE
generate trigger, aprox. at Thu Dec 10 04:19:41 1998 COT.
< <Channels Details > >
NOISE detected in OSSO - HOBC . No signal Thu Dec 10 04:20:41 1998 COT
Dur(1).
EVENT detected in OSSO - ANCC . local event at Thu Dec 10 04:24:18 1998 COT
s-p(2).
NOISE detected in OSSO - DIAC . Signal pick at Thu Dec 10 04:23:14 1998 COT
Dur(1).
EVENT detected in OSSO - HOQC - Declared HARD AmpP(0) AmpE(1). local
event at Thu Dec 10 04:19:50 1998 COT s-p(3).
NOISE detected in OSSO - PEIC . Signal pick at Wed Dec 31 19:00:05 1969 COT
Dur(-10).
EVENT detected in OSSO - SALC - Declared HARD AmpP(0) AmpE(8). local event
at Thu Dec 10 04:19:41 1998 COT s-p(1).
NOISE detected in OSSO - AZUC . No signal Thu Dec 10 04:21:36 1998 COT
Dur(7).
NOISE detected in OSSO - HUIC . No signal Thu Dec 10 04:21:20 1998 COT
Dur(1).
172
B.2.
Señal continua
Se ingresaron al sistema los archivos correspondientes a un dia de datos, divididos
en segmentos de 5 minutos.
B.2.1. Evento 2003 12 25 - 06:59:03
ESTACION
HORA EVENTO
TIPO
HOBCeP 2 031225065903.00
110.8
T
ANCCeP 4 031225065916.53
101.1
T
SEG1eP 3 031225065911.34
141.0
T
HQZCeP 4 031225065915.23
71.2
T
AZ1CeP 2 031225065906.81 2881.6
T
PEICeP 2 031225065853.12 3741.0
T
—————
173
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 8 channels.
EV.LOCAL generate trigger, aprox. at Thu Dec 25 06:57:26 2003 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC - Declared HARD AmpP(3) AmpE(30). local
event at Thu Dec 25 06:59:14 2003 COT s-p(2).
NOISE detected in OSSO - ANCC. No signal Thu Dec 25 06:57:26 2003 COT
Dur(128).
EVENT detected in OSSO - SEG1. local event at Thu Dec 25 06:59:34 2003 COT
s-p(2).
EVENT detected in OSSO - HQZC. local event at Thu Dec 25 06:59:30 2003 COT
s-p(1).
EVENT detected in OSSO - HQNC. local event at Thu Dec 25 06:59:31 2003 COT
s-p(11).
NOISE detected in OSSO - HQEC. Signal pick at Thu Dec 25 06:58:31 2003 COT
Dur(3).
EVENT detected in OSSO - AZ1C. regional event at Thu Dec 25 06:58:18 2003
COT s-p(64).
EVENT detected in OSSO - PEIC - Declared HARD AmpP(21) AmpE(109). local
event at Thu Dec 25 06:59:09 2003 COT s-p(1).
B.2.2. Evento 2003 12 25 - 07:13:00
ESTACION
HORA EVENTO
TIPO
174
HOBCeP 2 031225071300.37 1301.1
R
ANCCeP+1 031225071301.07 1060.9
R
SEG1eP 2 031225071308.31 1300.6
R
HQECeP 4 031225071304.45 2421.3
R
AZ1CeP 2 031225071307.36
620.9
R
PEICeP 2 031225071304.37
741.3
R
—————
175
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 8 channels.
EV.REGIONAL generate trigger, aprox. at Thu Dec 25 07:11:57 2003 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC. regional event at Thu Dec 25 07:12:28 2003
COT s-p(39).
NOISE detected in OSSO - ANCC. No signal Thu Dec 25 07:12:29 2003 COT
Dur(40).
EVENT detected in OSSO - SEG1. local event at Thu Dec 25 07:13:04 2003 COT
s-p(14).
EVENT detected in OSSO - HQZC. regional event at Thu Dec 25 07:12:45 2003
COT s-p(28).
EVENT detected in OSSO - HQNC. regional event at Thu Dec 25 07:12:44 2003
COT s-p(32).
NOISE detected in OSSO - HQEC. No signal Thu Dec 25 07:12:46 2003 COT
Dur(31).
EVENT detected in OSSO - AZ1C. regional event at Thu Dec 25 07:11:57 2003
COT s-p(82).
EVENT detected in OSSO - PEIC. regional event at Thu Dec 25 07:12:59 2003
COT s-p(20).
B.2.3. Evento 2003 12 25 - 07:21:12
—————
176
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 8 channels.
EV.LOCAL generate trigger, aprox. at Thu Dec 25 07:21:12 2003 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC. local event at Thu Dec 25 07:25:43 2003 COT
s-p(1).
EVENT detected in OSSO - ANCC - Declared HARD AmpP(4) AmpE(24). local
event at Thu Dec 25 07:24:13 2003 COT s-p(6).
EVENT detected in OSSO - SEG1. local event at Thu Dec 25 07:24:28 2003 COT
s-p(2).
NOISE detected in OSSO - HQZC. Signal pick at Thu Dec 25 07:23:34 2003 COT
Dur(3).
NOISE detected in OSSO - HQNC. Signal pick at Thu Dec 25 07:25:09 2003 COT
Dur(2).
NOISE detected in OSSO - HQEC. Signal pick at Thu Dec 25 07:24:16 2003 COT
Dur(4).
EVENT detected in OSSO - AZ1C. local event at Thu Dec 25 07:21:12 2003 COT
s-p(14).
EVENT detected in OSSO - PEIC. local event at Thu Dec 25 07:24:17 2003 COT
s-p(2).
177
B.2.4. Evento 2003 12 25 - 08:55:20
ESTACION
HORA EVENTO
TIPO DURACION
HOBCiPc0 031225085520.25
340.1
L
63.
ANCCiPd0 031225085526.39
30.1
L
75.
SEG1iPc0 031225085528.60
350.1
L
70.
20.1 43.6eS 3 L
69.
HQECeP 2 031225085527.64
AZ1CiPc0 031225085526.92
170.1
L
75.
PEICeP 3 031225085526.39
70.4
L
63.
—————
178
150.1
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 8 channels.
EV.LOCAL generate trigger, aprox. at Thu Dec 25 08:55:31 2003 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC - Declared HARD AmpP(2) AmpE(70). local
event at Thu Dec 25 08:55:31 2003 COT s-p(8).
EVENT detected in OSSO - ANCC. local event at Thu Dec 25 08:55:43 2003 COT
s-p(9).
NOISE detected in OSSO - SEG1. Signal pick at Thu Dec 25 08:55:38 2003 COT
Dur(3).
NOISE detected in OSSO - HQZC. Signal pick at Thu Dec 25 08:55:53 2003 COT
Dur(4).
EVENT detected in OSSO - HQNC - Declared HARD AmpP(1) AmpE(22). regional
event at Thu Dec 25 08:55:36 2003 COT s-p(17).
EVENT detected in OSSO - HQEC - Declared HARD AmpP(5) AmpE(40). local
event at Thu Dec 25 08:55:53 2003 COT s-p(1).
EVENT detected in OSSO - AZ1C - Declared HARD AmpP(1) AmpE(66). local
event at Thu Dec 25 08:55:36 2003 COT s-p(15).
EVENT detected in OSSO - PEIC - Declared HARD AmpP(2) AmpE(19). regional
event at Thu Dec 25 08:55:36 2003 COT s-p(16).
B.2.5. Evento 2003 12 25 - 20:34:18
ESTACION
HORA EVENTO
TIPO
179
HOBCeP 3 031225203418.27
190.8
R
ANCCeP 3 031225203418.20
50.3
R
SEG1eP 2 031225203425.35
480.5
R
AZ1CeP 2 031225203424.64 1240.8
R
PEICeP 3 031225203422.51
R
651.2
—————
180
S-DCE prototype v.0.1
< <Alert Report > >
TRIGGER Apply DCEClassifBasicOSSOrsw function. Found in 8 channels.
EV.LOCAL generate trigger, aprox. at Thu Dec 25 20:34:13 2003 COT.
< <Channels Details > >
EVENT detected in OSSO - HOBC. local event at Thu Dec 25 20:34:24 2003 COT
s-p(10).
EVENT detected in OSSO - ANCC. regional event at Thu Dec 25 20:34:28 2003
COT s-p(33).
EVENT detected in OSSO - SEG1. local event at Thu Dec 25 20:34:35 2003 COT
s-p(8).
NOISE detected in OSSO - HQZC. Signal pick at Thu Dec 25 20:34:13 2003 COT
Dur(2).
EVENT detected in OSSO - HQNC. local event at Thu Dec 25 20:34:28 2003 COT
s-p(9).
EVENT detected in OSSO - HQEC. regional event at Thu Dec 25 20:34:27 2003
COT s-p(23).
EVENT detected in OSSO - AZ1C - Declared HARD AmpP(1) AmpE(87). local
event at Thu Dec 25 20:34:28 2003 COT s-p(4).
EVENT detected in OSSO - PEIC. local event at Thu Dec 25 20:34:28 2003 COT
s-p(1).
181