desarrollo de un modelo de simulacion para el sistema
TRANSCRIPT
Proyecto de Grado
Presentado ante la ilustre Universidad de Los Andes como requisito final para
obtener el Tıtulo de Ingeniero de Sistemas
Desarrollo de un Modelo de Simulacion para el
Sistema Automatizado de Identificacion
Dactilar (AFIS) del Servicio Autonomo de
Identificacion, Migracion y Extranjerıa
(SAIME). Optimizacion del AFIS.
Por
Br. Yuraima del Carmen Rivas Davila
Tutor: Prof. Sebastian Medina
Asesor: Ing. Joan Viloria
Junio 2008
c©2008 Universidad de Los Andes Merida, Venezuela
Desarrollo de un Modelo de Simulacion para el Sistema
Automatizado de Identificacion Dactilar (AFIS) del Servicio
Autonomo de Identificacion, Migracion y Extranjerıa
(SAIME). Optimizacion del AFIS.
Br. Yuraima del Carmen Rivas Davila
Proyecto de Grado — Investigacion de Operaciones, 81 paginas
Resumen: El trabajo realizado presenta un modelo de simulacion del AFIS, utilizando
la metodologıa para estudios de simulacion por eventos discretos. El aspecto fundamen-
tal de la investigacion ha sido la descripcion del flujo transaccional, con el fin de obtener
las posibles configuraciones de las variables para alcanzar un desempeno lo mas cercano
al optimo que se vea reflejado en el rendimiento de sus tareas y en el mejor fluıdo de
la informacion. Para ello se desarrollo un modelo de simulacion a eventos discretos en
SimPy, el cual fue verificado y validado en contraste con el sistema real y evaluado por
los expertos en el area. Ademas de la comprension del sistema a traves de la simulacion,
se aplico el paradigma: Recocido Simulado para la determinacion de la configuracion
de clientes de trabajo dentro del AFIS que aumente la cantidad de transacciones proce-
sadas por hora. Se evaluaron algunos escenarios, cuyos resultados son de interes para
el AFIS al momento de tomar decisiones, de forma tal que de acuerdo al escenario
puedan ajustar los parametros aumentando ası el numero de transacciones procesadas
por hora.
Palabras clave: Modelo, Simulacion, Seudo-Optimizacion, Recocido Simulado, Even-
tos Discretos, AFIS, minucias, umbrales.
Este trabajo fue procesado en LATEX.
Dedico este logro en mi vida a:
A Dios y la Virgen por cuidarme e iluminarme en todo
momento.
A mi abuela Miriam que desde el cielo me cuido cada dıa
para que alcanzara esta meta.
A mi hija Astrid, con tus sonrisas y juegos alegraron la
mitad de mi carrera, gracias Dios por regalarme uno de mis
mas grandes tesoros.
A mi madre Yolanda Rivas, por ser fuente ejemplar de
constancia, de apoyo incondicional....Te quiero mucho.
A mi esposo Giovanny, por creer y confiar en mi en todo
momento, brindarme tu confianza...Lo Logre y Te Amo.
A mi hermano Freddy, espero que esta meta que he
alcanzado te impulse para que logres las tuyas, de la misma
manera...Tu sabes que no fue facil pero el que persevera
vence.
A mi tıa Carmen (Cita), gracias por nunca dejarme sola,
siempre estuviste allı para ayudarme y acompanarme
cuando mas lo necesite, de corazon Muchas Gracias!!!!!.
Indice general
Indice de Tablas VII
Indice de Figuras VIII
Agradecimientos IX
1. Introduccion 1
1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Planteamiento y Delimitacion del Problema . . . . . . . . . . . . . . . 3
1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6. Organizacion del Documento . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Marco Teorico 9
2.1. Sistemas Automatizados de Identificacion Dactilar (AFIS) . . . . . . . 9
2.2. SAIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Definicion del Servicio Autonomo de Identificacion Migracion y
Extranjerıa (SAIME) . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2. Estructura Organizacional . . . . . . . . . . . . . . . . . . . . . 13
2.3. AFIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1. Definicion de AFIS . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2. Estructura Organizacional Interna del AFIS . . . . . . . . . . . 17
iv
2.3.3. Procesos del AFIS . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4. Simulacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.1. Ventajas, desventajas y peligros de la Simulacion . . . . . . . . 21
2.4.2. Simulacion de sistemas orientados a eventos discretos . . . . . . 23
2.4.3. SimPy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5. Optimizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.1. Optimizacion a traves de Metodos Heurısticos . . . . . . . . . . 26
2.5.2. Procedimientos Metaheurısticos . . . . . . . . . . . . . . . . . . 27
2.5.3. Recocido Simulado . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.4. Algoritmo basico de Recocido Simulado . . . . . . . . . . . . . . 30
3. Desarrollo del Modelo de Simulacion del AFIS 32
3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2. Modelo Descriptivo del Flujo Transaccional en el AFIS . . . . . . . . . 33
3.3. Construccion del Modelo de Simulacion . . . . . . . . . . . . . . . . . . 41
3.3.1. Recoleccion de datos y estimacion de parametros . . . . . . . . 41
3.3.2. Implementacion del modelo en SimPy . . . . . . . . . . . . . . . 42
3.4. Verificacion y Validacion del modelo . . . . . . . . . . . . . . . . . . . . 51
3.5. Analisis de Sensibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4. Seudo-Optimizacion del Modelo de Simulacion del AFIS con la Meta-
heurıstica de Recocido Simulado 56
4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2. Busqueda de la optimizacion del modelo de simulacion del AFIS . . . . 57
5. Conclusiones y Recomendaciones 64
5.1. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Bibliografıa 67
A. Codigo de implementacion del modelo de simulacion para el AFIS 69
B. Resultados en la Maximizacion de las transacciones procesadas por
hora para el caso 60 % ATU y 40 % IDI, usando la metaheurıstica de
Recocido Simulado 77
C. Resultados en la Maximizacion de las transacciones procesadas por
hora para el caso 60 % ATU y 40 % IDI, usando la metaheurıstica de
Recocido Simulado 79
Indice de cuadros
2.1. Tipos de solicitudes de la interfase . . . . . . . . . . . . . . . . . . . . . 20
3.1. Estimacion de parametros para el modelo del AFIS . . . . . . . . . . . 44
4.1. Parametros de RS para optimizar el modelo del AFIS . . . . . . . . . . 58
vii
Indice de figuras
1.1. Enfoque Optimizacion de Modelos de Simulacion . . . . . . . . . . . . 7
2.1. Minucias en una huella . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Codificacion de huella . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Codificacion de huella . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Huella Codificada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Huella Codificada y almacenada en la bases de datos . . . . . . . . . . 12
2.6. Estructura organizacional del SAIME . . . . . . . . . . . . . . . . . . . 14
2.7. Estructura organizacional de la Direccion de Informatica . . . . . . . . 15
2.8. Arquitectura global del Proceso AFIS . . . . . . . . . . . . . . . . . . . 16
2.9. Formas de estudiar un sistema . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Flujo transaccional del AFIS . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2. Arquitectura METAMATCHER y Matcher Interface . . . . . . . . . . 39
3.3. Correos recibidos por el AFIS cada hora . . . . . . . . . . . . . . . . . 42
3.4. Aproximacion a la Distribucion Exponencial . . . . . . . . . . . . . . . 43
3.5. Resultados para la produccion por hora Caso 80 % IDI y 20 % ATU . . 54
4.1. Valor maximo en funcion del numero de iteraciones 40 % IDI y 60 % ATU 61
4.2. Valor maximo en funcion del numero de iteraciones 60 % IDI y 40 % ATU 63
viii
Agradecimientos
A la ilustre Universidad de Los Andes por ser la casa de estudio que me brindo todos
los conocimientos de mi carrera que hoy he adquirido.
Al profesor Sebastian Medina por su ayuda, apoyo, dedicacion y paciencia.
Al Ing. Joan Viloria, por abrirnos las puertas de la institucion y por la receptividad
para facilitarnos lo necesario en el logro de esta meta.
Al Ing. Saul Gutierrez e Ing. Jose Ignacio Perez, por toda la valiosa colaboracion
brindada durante el desarrollo de esta investigacion.
A todas aquellas personas que de una u otra manera contribuyeron con el objetivo
de esta investigacion.
Muchas Gracias!!!!
ix
Capıtulo 1
Introduccion
1.1. Antecedentes
El Servicio Autonomo de Identificacion, Migracion y Extranjerıa (SAIME) es un
organismo que sustituira a la Oficina Nacional de Identificacion y Extranjerıa (Onidex).
La implementacion en Venezuela de este nuevo sistema de identificacion nacional
es similar al que poseen Polonia, Noruega, Suiza, Luxemburgo, y Alemania. Segun
el Director Nacional de Control de Extranjeros de la Onidex, Jose Javier Morales
(Morales, 2006), “las ventajas de este nuevo sistema son: transparencia, seguridad,
eficiencia y servicios automatizados en su totalidad; gracias a este nuevo sistema el
tiempo de respuesta a los ciudadanos disminuira a favor de ellos en un 60 %”1.
El Sistema Automatizado de Identificacion Dactilar (AFIS, Automated FingerPrint
Identification System) juega un papel fundamental en el funcionamiento de este nuevo
sistema de identificacion de ciudadanos.
Segun el especialista en AFIS en America Latina Ing. Richard Colmenares, quien
actualmente es el Jefe de Proyecto AFIS Civil Venezuela y AFIS Policial CICPC, existe
una evolucion historica de AFISs implementados en el paıs.
En 1986 se lleva a cabo en la ONIDEX la ejecucion de un innovador sistema de
identificacion AFIS proveniente de la empresa De La Rue Printrak, el cual funciono 4
anos.
1Entrevista desde la sede de la ONIDEX 27 de noviembre de 2006
1.1 Antecedentes 2
Para el ano 1996 se implementa el segundo AFIS en Venezuela de la empresa Pintrak
INC con una duracion de 4 anos.
Finalmente, se llega al ano 2006 donde se implanta el actual AFIS de la empresa
SAGEM Defense Securite. El AFIS es un sistema compuesto por variables de diferente
naturaleza, el cual se ha implantado sin estudios previos, por lo que suponen los es-
pecialistas en este sistema que se encuentra operando por debajo de su capacidad de
produccion. (SAGEM, 2006)
Es por ello que, para la realizacion de la investigacion fue necesario realizar una
busqueda bibliografica en trabajos similares sobre las herramientas y tecnicas apropia-
das que se aplicaron en este proyecto, debido a la no inexistencia de estudios en este
tipo de sistemas.
El estudio del comportamiento de un sistema mediante la construccion de modelos
y su posterior simulacion y optimizacion, es un instrumento muy utilizado actualmente
en los estudios de sistemas complejos. De igual forma, permite profundizar en las va-
riables que afectan mas significativamente el funcionamiento del sistema, analizar sus
interacciones y evaluar su impacto.
Se han realizado trabajos de investigacion en modelado y simulacion de sistemas
complejos tales como:
C. Teran (Teran, 2003) quien realizo un trabajo en el cual, a traves de simulacion,
se evaluan los parametros de diseno de las paradas del sistema de transporte masivo de
la ciudad de Merida (Trolebus). Este trabajo condujo a que la simulacion permitiera
la identificacion de los problemas relevantes y evaluar cuantitativamente las soluciones
alternativas.
Actualmente la simulacion cuenta con entornos y herramientas computacionales
que facilitan el desarrollo de la misma. Uno de los lenguajes usados actualmente para
implantar modelos de simulacion es Python, por ser este un lenguaje interpretado, de
desarrollo mas rapido y multiplataforma.
E. Briceno (Briceno, 2007), realizo un estudio comparativo del paquete de simu-
lacion orientado a eventos discretos Simpy y, a partir del mismo, desarrollo un manual
de usuarios en castellano con ejemplos resueltos.
1.2 Planteamiento y Delimitacion del Problema 3
Adicionalmente, los modelos de simulacion se combinan con tecnicas de opti-
mizacion que permiten obtener los valores de variables mas cercanos al deseado posible
y para ası dar soporte a la toma de decisiones, usandose ampliamente las tecnicas de
optimizacion aplicadas al tipo de sistemas complejos como lo son las tecnicas heurısti-
cas.
El trabajo de J. Pacheco (Pacheco, 2007), presenta la optimizacion de la salida de
modelos de simulacion de eventos discretos con la metaheurıstica de Recocido Simulado
implementado en Simpy, el cual genero excelentes resultados.
J. Avendano (Avendano, 2007), donde se describe el desarrollo de una metodologıa
en Simpy para la optimizacion de modelos de simulacion, empleando los Metodos de
Superficie de Respuesta.
A. Bolıvar (Bolıvar, 2005), en el que se desarrollo una herramienta basada en el
analisis de Superficie de Respuesta para la optimizacion de modelos de simulacion a
eventos discretos en Arena.
En los trabajos consultados se observa que se ha hecho amplio uso de los modelos de
simulacion y procesos de optimizacion en aplicaciones especıficas y generales, mostran-
do el gran campo de aplicacion que tiene el modelado, la simulacion y la optimizacion.
El enfoque de este trabajo fue representar lo novedoso del AFIS en el desarrollo de
un modelo de simulacion y, por otro lado, se aplico la metodologıa de optimizacion
de Recocido Simulado para optimizar las variables de respuesta de dicho modelo de
simulacion.
1.2. Planteamiento y Delimitacion del Problema
El AFIS se implanta con la finalidad de brindar mayor seguridad e integridad al
ciudadano y al Estado venezolano en el control de identificacion, migracion y extran-
jerıa.
El problema que se detecta es que actualmente los procesos que se estan realizando
en el AFIS no manifiestan el rendimiento que teoricamente deberıan tener en cuanto a
rapidez en las transacciones.
El AFIS recibe las solicitudes del Centro de Datos o de las oficinas autorizadas
1.3 Justificacion 4
para tramitar un documento legal en lo que se refiere a identificacion y autenticacion
de huellas. Por tal motivo se requiere que los aplicativos del AFIS proporcionen una
respuesta rapida y eficiente ante dichas solicitudes, de forma tal que la expedicion de
documentos sea lo mas eficaz y se vea reflejado en una excelente prestacion del servicio
de identificacion.
En atencion a lo antes expuesto, la institucion SAIME hace uso del AFIS sin hacer
estudios previos, aunado de igual manera el desconocimiento de los valores de las
variables que forman parte del mismo, lo cual ha conllevado a la formacion de cuellos
de botella que disminuyen la velocidad de los procesos, incrementan los tiempos de
espera; produciendo una caıda considerable en la eficiencia (Entrevista Administrador
AFIS S. Gutierrez (Gutierrez, 2007)).
Debido a esto, se quiere estudiar cada uno de los procesos y variables que intervienen
en el sistema, con la finalidad de comprender, a traves de la simulacion, la totalidad
del sistema real, diagnosticar posibles problemas y sugerir los potenciales valores de
los parametros que mejoren los procesos, entre otros.
Es importante destacar que el problema esta limitado a conocer los procesos que
cada subsistema, dentro de los aplicativos del AFIS, realiza en el esquema entrada-
salida; esto significa, que no es posible conocer lo que cada uno realice internamente
(restricciones de la empresa facilitadora del sistema), por lo que cada uno fue visto
como subsistemas caja negra. Segun lo dicho anteriormente solo se tomaron los datos
necesarios para el analisis realizado: tiempos de espera, tiempos de atencion, numero de
clientes en cola, entre otros; para cada subsistema; cualquier informacion no relacionada
directamente con el proceso principal del AFIS no fue de interes y por lo tanto no fue
medida.
1.3. Justificacion
El desarrollo de esta investigacion a traves de un modelo de simulacion y su posterior
optimizacion, se hace con la finalidad de ayudar a entender mejor la dinamica del AFIS,
a su vez, la experimentacion con dicho modelo permite estudiar el comportamiento
del sistema ante distintos escenarios para predecir lo que podrıa ocurrir en ciertas
1.4 Objetivos 5
situaciones, contribuyendo de esta forma en la toma de decisiones.
A traves de la optimizacion de los parametros, se identifican posibles deficiencias
en la configuracion del sistema y se proponen mejoras que conlleven a un desempeno
eficiente en el AFIS. Este trabajo tambien beneficia a la seguridad nacional de la nacion
a traves de la mejora en cuanto a rapidez en la prestacion del servicio de identificacion
y autenticacion de ciudadanos.
1.4. Objetivos
1.4.1. Objetivo General
Desarrollar un modelo de simulacion a eventos discretos con SimPy para el AFIS,
con la finalidad de optimizar el rendimiento del mismo a traves de la utilizacion de la
tecnica metaheurıstica de Recocido Simulado.
1.4.2. Objetivos Especıficos
Revisar bibliografıa que facilite el aprendizaje de las herramientas Python y
SimPy.
Revisar informacion sobre la tecnica de optimizacion metaheurıstica Recocido
Simulado.
Describir y comprender el sistema automatico de identificacion dactilar y deter-
minar las variables del mismo.
Elaborar un modelo conceptual que describa los procesos que se llevan a cabo en
el AFIS.
Identificar las variables a medir y medicion de las mismas.
Aplicar tratamiento estadısticos a los datos.
Determinar la distribucion estadıstica de los datos de entrada.
Identificar el rango de tiempos de atencion en los clientes.
1.5 Metodologıa 6
Establecer el rango de valores de las variables del modelo del AFIS y parametrizar
las mismas.
Construir el modelo de simulacion usando la metodologıa de simulacion por even-
tos discretos con la herramienta Simpy identificando las relaciones entre los aplica-
tivos del AFIS.
Aplicacion de la tecnica metaheurıstica de Recocido Simulado al modelo de si-
mulacion.
Estudiar posibles comportamientos del modelo a partir de los resultados
obtenidos con la herramienta de optimizacion.
Analizar y estudiar los resultados.
Reportar los resultados obtenidos y posibles recomendaciones.
1.5. Metodologıa
Para el desarrollo de este trabajo se siguio en primer lugar la metodologıa para
estudios de simulacion tomando las ideas propuestas por H. Hoeger (Hoeger, 2005) y
Guash y otros (Guash et˜al., 2005):
Para la formulacion del problema y recoleccion de datos se realizo la observacion
directa del AFIS, se hizo uso de la experiencia de sus administradores y de la do-
cumentacion existente. El resultado final de esta etapa fue la definicion de lo que
los autores plantean en sus trabajos como Formulacion del Modelo Conceptual.
Se construyo un modelo de simulacion a eventos discretos del AFIS a partir del
modelo conceptual basado en el flujo transaccional, aplicando la herramienta
SimPy. Este modelo conceptual sirvio para construir el modelo de simulacion a
eventos discretos.
Se realizo la verificacion y validacion, a traves de pruebas en las cuales se
definieron tiempos de corridas, condiciones iniciales y numero de ejecuciones.
1.6 Organizacion del Documento 7
Con este desarrollo metodologico se logro el entendimiento del sistema real y un
modelo de simulacion verificado/validado para seguir con el proceso de investigacion.
La segunda parte en la metodologıa de trabajo consto de la aplicacion al modelo
de simulacion de la tecnica de optimizacion metaheurıstica: Recocido Simulado.
Para el caso de optimizacion de modelos de simulacion se siguio las ideas planteadas
por Carson y Anu (Carson and Anu, 1997), la cual consta de los siguientes pasos:
Se definio un conjunto inicial de los valores de parametros de entrada y una o
mas replicas de experimentos se llevaron a cabo con estos valores.
Los resultados que se obtuvieron se analizaron mediante el algoritmo de opti-
mizacion.
Se establecieron nuevos valores de los parametros y un conjunto de experimentos
se llevaron a cabo.
Los pasos 2 y 3 se repitieron hasta que el algoritmo se cerro manualmente o se
cumplio un conjunto de condiciones.
De forma grafica lo podemos apreciar en la figura 1.1
Figura 1.1: Enfoque Optimizacion de Modelos de Simulacion
1.6. Organizacion del Documento
El manuscrito del proyecto esta organizado como sigue:
El capıtulo 2 contiene la base teorica que fundamento el modelado, la simulacion y
la posterior optimizacion del modelo de simulacion con Recocido Simulado. A su vez, se
1.6 Organizacion del Documento 8
muestran caracterısticas fundamentales sobre sistemas automatizados de identificacion
dactilar en general y aspectos del organismo al cual esta adscrito el AFIS.
El capıtulo 3 describe los procesos y actividades que se llevan a cabo en el AFIS.
Seguidamente se muestra el modelo de simulacion implementado en SimPy, se discute
el comportamiento reflejado por el modelo con respecto al sistema real. Finalmente se
muestra las pruebas de verificacion y validacion realizadas al modelo desarrollado en
SimPy.
El capıtulo 4 muestra la optimizacion del modelo de simulacion del AFIS con la
tecnica de optimizacion metaheurıstica de Recocido Simulado.
El capıtulo 5 presenta las conclusiones del estudio realizado en cuanto al modelo
de simulacion y los resultados obtenidos en la optimizacion. Seguidamente se muestran
las recomendaciones surgidas del mismo.
Capıtulo 2
Marco Teorico
En el presente capıtulo se explican detalladamente los aspectos teoricos fundamen-
tales que fueron usados para el desarrollo de la investigacion planteada, en lo que se
refiere a sistemas automatizados de identificacion dactilar, simulacion, funcionamien-
to del paquete de simulacion por eventos discretos SimPy, optimizacion de modelos
de simulacion; ası como tambien lo relacionado con la tecnica metaheurıstica de opti-
mizacion Recocido Simulado.
2.1. Sistemas Automatizados de Identificacion Dac-
tilar (AFIS)
Antes de comenzar a indagar en la investigacion se hizo necesario conocer ccomo
es el funcionamiento de los sistemas automatizados de huellas dactilares, con el fin
de lograr una mayor comprension del sistema real. Los Sistemas Automatizados de
Huellas Dactilares son sistemas computarizados que permiten la identificacion rapida
y confiable de personas al contar con una base de datos que contiene los archivos
tradicionales de identificacion.
Las ventajas del sistema computarizado en relacion con el sistema tradicional de
identificacion se enumeran a continuacion:
Permite realizar varias busquedas de manera simultanea.
2.1 Sistemas Automatizados de Identificacion Dactilar (AFIS) 10
Optimiza el aprovechamiento del recurso humano.
Reduce importantes margenes de error debido a la forma de la captura y ali-
mentacion de la base de datos.
Permite la ampliacion del sistema con la posible conexion de diversas terminales.
Ahorra tiempo en las actividades de localizacion de datos.
Es importante resaltar que de todos los sistemas de identificacion biometrica, las
huellas dactilares son las unicas legalmente reconocidas como prueba fidedigna de iden-
tidad. Son unicas e irrepetibles aun en gemelos identicos, debido a que su diseno no
esta determinado estrictamente por el codigo genetico, sino por pequenas variables en
las concentraciones del factor del crecimiento y en las hormonas localizadas dentro de
los tejidos. Cabe senalar que en un mismo individuo la huella de cada uno de sus dedos
es diferente.(SOY, 2007)
En la figura 2.1 tomado de (SOY, 2007) aparecen 8 puntos caracterısticos que hay
en una huella digital, estos se repiten indistintamente para formar entre 60 y 120 (por
ejemplo 10 orquillas, 12 empalmes, 15 islotes, etc). A estos puntos tambien se llaman
minutae, o minucias, termino utilizado en la medicina forense que significa “punto
caracterıstico”.
Figura 2.1: Minucias en una huella
2.1 Sistemas Automatizados de Identificacion Dactilar (AFIS) 11
Con este conjunto de puntos, el software biometrico de huella digital genera un
modelo en dos dimensiones, que se almacena en una base de datos, con la debida
referenciacion de la persona que ha sido objeto del estudio. Para ello, la ubicacion
de cada punto caracterıstico o minucia se representa mediante una combinacion de
numeros (x.y) dentro de un plano cartesiano, los cuales sirven como base para crear un
conjunto de vectores que se obtienen al unir las minucias entre sı mediante rectas cuyo
angulo y direccion generan el trazo de un prisma de configuracion unica e irrepetible.
La codificacion en su mayorıa se realiza a menores de edad (juveniles), son huellas
pequenas que posteriormente para ser autenticadas el cotejador compara la patologıa
del nino con respecto al actual adulto. Se puede dar el caso, que este proceso se active
para adultos (no juveniles) solo en el caso que no exista dentro de la base de datos. El
proceso de codificacion consta de 4 etapas las cuales se describen a continuacion:
La huella dactilar se lee por un captor de huellas.
Figura 2.2: Codificacion de huella
La huella dactilar se codificada por el captor.
Figura 2.3: Codificacion de huella
2.2 SAIME 12
Se genera una plantilla y la imagen se comprime en formato WSQ.
Figura 2.4: Huella Codificada
El captor guarda y reconoce un conjunto de numeros (vectores) que solo podran
ser identificados como una plantilla.
Figura 2.5: Huella Codificada y almacenada en la bases de datos
Para llevar a cabo el proceso inverso o verificacion dactilar, se utilizan estos mismos
vectores, no las imagenes.
2.2. SAIME
Anteriormente se estudio el proceso de los sistemas de identificacion dactilar en
general. A partir de esta seccion se define el organismo al cual esta adscrito el AFIS y
su estructura organizacional, posteriormente se enfatiza en la arquitectura y procedi-
mientos que sigue el AFIS.
2.2 SAIME 13
2.2.1. Definicion del Servicio Autonomo de Identificacion Mi-
gracion y Extranjerıa (SAIME)
La Oficina Nacional de Identificacion y Extranjerıa (ONIDEX) es el organismo
adscrito al Ministerio del Poder Popular para las Relaciones Interiores y Justicia, el cual
posee mas de sesenta anos de actividades continuas al servicio del Paıs. La ONIDEX
pasara a ser Servicio Autonomo de Identificacion, Migracion y Extranjerıa (SAIME),
una vez resueltos los requisitos formales y jurıdicos para el cambio.
La mision del SAIME es el establecimiento de un servicio optimo de Identificacion
Nacional, a traves de la automatizacion del mismo, con alta calidad y confiabilidad
dentro del marco que establece la ley; logrando de este modo garantizar el derecho de
identidad a los ciudadanos y controlar el flujo migratorio y de extranjeros; de acuerdo
a los procedimientos de seguridad establecidos en la Constitucion de la Republica
Bolivariana de Venezuela.
Su vision es posicionarse como un organismo de marcada referencia nacional por la
excelencia del servicio que presta, que cuente con una estructura moderna, una base
de datos segura y confiable, con todos los procesos automatizados y un alto grado de
profesionalismo y eficiencia, donde los tramites de identificacion, migracion y control
de extranjeros se hagan de una manera rapida dentro del marco de la Ley, prestando
a su vez, el apoyo necesario a todas las instituciones publicas y privadas que requieran
de los servicios, contribuyendo a garantizar la seguridad del Estado venezolano.
Toda la documentacion que se expedira en el SAIME, se tratara de un documento
electronico de optima calidad, impreso en una lamina de policarbonato con un chip
incorporado que podra facilitar otros servicios. Actualmente estan siendo expedidos
pasaportes electronicos y se esta desarrollando el proyecto de cedulacion electronica.
2.2.2. Estructura Organizacional
La organizacion SAIME es una institucion que estara adscrita al Ministerio del
Poder Popular para las Relaciones Interiores y Justicia, seguidamente se encuentra la
Direccion General de la institucion, de la cual depende el area administrativa compuesta
por: Consultorıa Jurıdica, Recursos Humanos, Administracion, Secretarıa, Direccion
2.2 SAIME 14
Estrategica y Seguridad Integral. A su vez se desprenden 7 direcciones con igual nivel
jerarquico que corresponden al corazon de la mision y vision del SAIME, las cuales son:
Direccion de Identificacion, Direccion de Informatica, Direccion de Extranjerıa, Dire-
ccion de Migracion, Direccion de Dactiloscopia y el CPID (Centro de Personalizacion
e Impresion de Documentos).
En la figura 2.6 se puede observar la representacion grafica de la organizacion de
dicha institucion.
Figura 2.6: Estructura organizacional del SAIME
No es de interes para esta investigacion desglosar detalladamente cada uno de los
departamentos, por ello solo se explicara brevemente la direccion de la cual depende el
AFIS, la cual se encuentra resaltada en la figura 2.6.
Direccion de Informatica: se encarga de definir, coordinar y dirigir los procesos
informaticos y de automatizacion de la institucion de manera eficiente y segura. Ad-
ministra lo referente a la base de datos de los ciudadanos en cuanto a datos demograficos
y de huellas dactilares, ası como tambien el diseno e implementacion de las redes de co-
municacion entre la oficina nacional y sus dependencias y el sitio web para la solicitud
2.3 AFIS 15
de documentos.
A esta direccion se encuentran adscritas varias coordinaciones, tal y como se muestra
en la figura 2.7:
Figura 2.7: Estructura organizacional de la Direccion de Informatica
De igual modo, solo se detallara la coordinacion en donde el AFIS desarrolla sus
procesos.
Coordinacion del Centro de Datos y AFIS: se encarga de organizar, dirigir y super-
visar las actividades del Centro de Datos y del Sistema Automatizado de Identificacion
Dactilar (AFIS).
2.3. AFIS
2.3.1. Definicion de AFIS
En la figura 2.8 se puede observar la arquitectura global del sistema de identificacion
nacional, la cual en lıneas generales muestra la entrada y salida del AFIS.
El AFIS Civil se integra en este sistema como un bloque “motor de identifi-
cacion”que responde a solicitudes de identificacion, autenticacion, o recuperacion de
datos, por el intermedio de datos al formato ANSI/NIST 1 enviados por el protocolo
SMTP 2.
El AFIS Civil se encarga de:
Proporcionar la interfaz con el sistema del MIJ.
1Estandares internacionales de tecnologıa de huellas digitales2Protocolo simple de transferencia de correo electronico
2.3 AFIS 16
Figura 2.8: Arquitectura global del Proceso AFIS
Procesar y responder a solicitudes de identificacion y autenticacion recibidas del
sistema del MIJ o de otros sistemas a traves de esta interfaz unica.
Ademas se compone de modulos biometricos para estaciones de registro. Estos
modulos de hardware y software se encuentran integrados en las estaciones de cap-
tura instaladas para la atencion al publico. Estos modulos permiten efectuar en ellos,
ademas de las funciones normales de captura de datos, las siguientes funciones:
Captura de las diez huellas dactilares con control de calidad.
Captura de la fotografıa con control de calidad.
El AFIS proporciona una interfaz estandar para permitir el intercambio de solici-
tudes y de respuestas entre el y el sistema del MIJ u otro sistema que cumpla con esta
interfaz. El formato de todos los datos intercambiados entre los sistemas es el formato
estandar de intercambio de datos biometricos ANSI/NIST con una implementacion de
INTERPOL 3.
3Organismo encargado de la seguridad publica, terrorismo, crımenes, entre otros
2.3 AFIS 17
El servidor AFIS esta basado en un servidor de base de datos Oracle y toda la
informacion es accesible por medio de comandos SQL. Gracias a esa estructura, es
posible hacer de manera sencilla cualquier evolucion, como por ejemplo: cambios en los
procesamientos, conexion de sistemas adicionales, etc.
El DIMS es capaz registrar y almacenar hasta 44 millones de fichas con las siguientes
informaciones del solicitante:
Identificador unico alfanumerico, llamado identificador biometrico de la persona
(BIOID);
Imagenes de las diez (10) huellas en formato WSQ (diez dedos individuales);
Minucias (puntos caracterısticos) de las diez (10) huellas.
La solicitud, incluyendo los datos del solicitante y el tipo de solicitud, estara iden-
tificada por un Numero de Control (numero interno del sistema) durante el proceso.
Los registros de todas las personas estaran identificados en la base de datos del
AFIS Civil con un numero unico de identificacion.
De esta forma, se puede decir que el AFIS es el corazon de los principales procesos
en la tramitacion de documentos.
El AFIS Civil presenta una compleja estructura interna con variables de distinta
naturaleza que se encarga de responder a distintas solicitudes.
En general, el AFIS se enfrenta a multiples operaciones donde cada subsistema
posee colas de trabajo, lo que implica que se debe encontrar la mejor configuracion de
variables de tal forma que se alcance la maxima capacidad de produccion.
2.3.2. Estructura Organizacional Interna del AFIS
El AFIS cuenta con un area de administracion, area de peritos y el Centro AFIS.
Area de Administracion: encargada de garantizar el funcionamiento del AFIS y
velar por el rendimiento en cuanto a las respuestas que se dan a las solicitudes,
ya que de esto depende la rapida tramitacion de documentos a los ciudadanos.
2.3 AFIS 18
Para que esto se lleve a cabo de manera efectiva y eficiente se cuenta con la
asistencia de Administradores del AFIS ası como tambien de Operadores de Ex-
cepcion, los cuales son los encargados de las siguientes actividades y procesos:
• Revisar los clientes Windows del AFIS.
• Revisar las colas de los clientes Windows AFIS.
• Vaciado o borrado de las trazas del Meta Matcher.
• Revisar el porcentaje de uso de los tablespaces.
• Revisar las Cintas en la librerıa de Backup.
• Lanzamiento del Backup.
• Revisar el funcionamiento de los servidores.
• Generar el reporte diario de produccion del AFIS.
• Contar los Correos Enviados y Recibidos en el servidor de correo del AFIS.
• Reporte del FSV que se corre a las 12:00 de la noche
Cabe destacar que el proceso de backup solo se realiza en las horas de la noche
debido a que para la realizacion del mismo es necesario parar todos los procesos.
Area de Peritos: esta conformada por 18 especialistas en analisis de huellas dac-
tilares. Se realizan dos turnos de 6 horas donde trabajan 9 peritos. Estos se
encargan de analizar las solicitudes de tipo IDI o ATU que el AFIS no ha podido
dar respuesta debido a que no estan por encima del umbral de aceptacion.
Area del Centro AFIS: en este lugar se encuentra todo el hardware que hace
posible que el AFIS lleve a cabo sus procesos.
2.3.3. Procesos del AFIS
En la Tabla 2.1 se observa el tipo de solicitud que acepta la interfaz del AFIS:
2.3 AFIS 19
Solicitud Descripcion Posibles respuestas
Identificacion Busqueda 1/N HIT (misma(s) persona(s) encontrada(s))
Verificacion en el caso con la lista del(de los) identificador(es)
de candidatos (HIT) de esta(s) persona(s)
NO HIT (persona no existente
en la base de datos)
Error
Identificacion Busqueda 1/N HIT (misma(s) persona(s) encontrada(s))
e Insercion Verificacion en el caso con la lista del(de los) identificador(es)
de candidatos (HIT) de esta(s) persona(s)
Insercion si las huellas de la NO HIT (huellas de la persona
persona no existen ya en la no existentes en la base de datos
base de datos del
comparador
del comparador) e insercion
Error
Autenticacion Busqueda 1/1 HIT (misma persona)
NO HIT (persona diferente)
Error
Autenticacion Busqueda 1/1 HIT (misma persona)
y Verificacion en el caso NO HIT (persona diferente)
verificacion de NO HIT Error
Autenticacion Busqueda 1/1 HIT (misma persona) y actualizacion
y Verificacion en el caso NO HIT (persona diferente)
actualizacion de NO HIT Error
En caso de HIT:
Insercion de la nueva ficha
o substitucion de una ficha
en funcion de la calidad y
del tipo de la nueva ficha.
Actualizacion de la ficha
2.4 Simulacion 20
Solicitud Descripcion Posibles respuestas
virtual.
Recuperacion Recuperacion de las
imagenes
Imagenes + informacion
de imagenes de una ficha y de Error
informacion sobre la ficha
Estado Recuperacion del estado de Solicitud desconocida
de solicitud una solicitud Solicitud en curso
Solicitud ya procesada
Cuadro 2.1: Tipos de solicitudes de la interfase
Actualmente el AFIS se encuentra procesando:
1. Identificacion: proceso mediante el cual se compara las huellas de una persona
con todas las huellas existentes en la base de datos (Busqueda 1:n) permitiendo
la insercion de personas que no existen.
2. Autenticacion: mecanismo mediante el cual se compara las huellas de una
persona con las existentes en la base de datos de la misma, con el fin de verificar
que es la persona quien dice ser (Busqueda 1:1).
3. Recuperacion de imagenes: permite recuperar imagenes e informacion sobre
la ficha de una persona.
4. Estado de solicitud: facilita la informacion sobre el estado de las solicitudes
(desconocida, en proceso o ya procesada).
2.4. Simulacion
Hoy dıa para lograr el mejor funcionamiento de los sistemas en general dada la com-
plejidad de los mismos, se hace ventajoso el uso de lo que se conoce como Simulacion.
2.4 Simulacion 21
La simulacion significa imitar el comportamiento de un fenomeno o sistema fısico
con el fin de estudiarlo. Este proceso se realiza a traves del diseno de un modelo, el
cual servira para entender mejor el sistema, realizarle ciertas modificaciones y evaluar
el impacto ante las mismas.
Con respecto al sistema, modelado y simulacion, Law y Kelton (Law and Kelton,
2000) senalan:
“luego de definir el sistema de interes, se hacen experimentos con el sistema,
sı implica mucho costo, se disena un modelo y se experimenta con el para obtener un
modelo fısico o matematico; y en caso de este ultimo, emplear las tecnicas analıticas
y/o de simulacion”.
tal y como se muestra en la figura 2.9 4
Figura 2.9: Formas de estudiar un sistema
2.4.1. Ventajas, desventajas y peligros de la Simulacion
A continuacion se describe parte de las ventajas, desventajas y peligros de la simu-
lacion segun lo menciona E. Briceno (Briceno, 2007):
Ventajas.
4Tomado de Law and Kelton (2000)
2.4 Simulacion 22
1. Con el modelo de simulacion construıdo este se puede utilizar repetidamente para
analizar cambios en el diseno, polıticas y diversos escenarios de operacion con el
sistema.
2. Se identifican en un sistema complejo aquellas areas con problema (“cuellos de
botella”).
3. No es necesario interrumpir las operaciones de las companıas.
4. Permite estudiar el sistema por perıodos muy largos en un tiempo comprimido
o alternativamente un trabajo minucioso, analizarlo en tiempo expandido.
5. Se puede tener un mejor control sobre condiciones experimentales, para no ex-
perimentar con el sistema real.
Desventajas.
1. Son costosas ya que requieren gran cantidad de corridas computacionales para
encontrar soluciones, consume tiempo en su desarrollo para que el modelo sea
valido.
2. Los resultados de la simulacion son numericos; por tanto, surge el peligro de
atribuir a los numeros un grado mayor de validez y precision; en consecuencia,
las soluciones obtenidas no son optimas.
Peligros.
1. Subestimar el tiempo y costos involucrados en el proceso de modelacion.
2. Los modelos de simulacion son generalmente programas grandes, que si no se
tienen las precauciones debidas, es posible tener errores de programacion que
hagan las conclusiones sin sentido. Es por ello, que se debe evitar el entendimiento
superficial del sistema a ser modelado.
2.4 Simulacion 23
2.4.2. Simulacion de sistemas orientados a eventos discretos
El enfoque de la simulacion de sistemas orientados a eventos discretos se utiliza
para representar acciones instantaneas en tiempos no periodicos, que pueden cambiar
el estado actual del sistema en estudio.
Existen algunas alternativas para la simulacion de modelos de eventos discretos
tales como:
1. Simulacion del modelo estatico.
2. Simulacion a mano.
3. Simulacion de un lenguaje de proposito general.
4. Experimentacion mediante un entorno de simulacion.
Por este comportamiento discreto del sistema en la mayorıa de los casos se usa
la implementacion del mismo en un programa computacional mediante una lista de
sucesos futuros, un reloj que salte en el tiempo hacia el siguiente suceso, las variables
de salida que miden el comportamiento del sistema y unos acumuladores estadısticos
que tomen un registro de los valores de las variables de estado.
En virtud de lo anterior, segun E. Briceno (Briceno, 2007) p.34: “en la rama de la
simulacion de sistemas orientados a eventos discretos, existen los llamados “Lenguajes
de Proposito General”, que son los lenguajes de programacion convencionales (por
ejemplo Pascal, Fortran, C++, Python). “Lenguajes de Simulacion de Proposito Ge-
neral”, al igual que el anterior son lenguajes de programacion, con la distincion que
ya poseen modulos programados con caracterısticas especıficas para la simulacion (por
ejemplo GPSS, Simscript, Siman), que aparecieron a partir de 1960. “Paquetes de Si-
mulacion de Proposito General”, aparte de poseer modulos especıficos para simulacion
estos integran capacidades de animaciones para la simulacion e informes de resultados
(informes estandar o especıficos, tabulares o graficos, accesos a muestras individuales),
permiten definir el modelo empleando un dialogo.”
2.4 Simulacion 24
2.4.3. SimPy
Destacando el orden de ideas antes expuestas sobre las caracterısticas que presentan
los simuladores de sistemas orientados a eventos discretos, queda una interrogante en
el aire, que es ¿cual lenguaje de programacion podrıa ser usado para representar el
comportamiento de estos sistemas?, esto va a depender en gran medida de la estrategia
adoptada y de las virtudes que presente el lenguaje seleccionado.
Hoy dıa la polıtica de grupos empresariales y entes gubernamentales es dejar a un
lado el uso de software privativo y seguir la tendencia de herramientas de software
de fuente abierta. Entre los diversos entornos de software libre tenemos OMNETH,
SimPy, entre otros.
Ahora bien, para el caso de estudio que compete al proyecto, se uso el simulador
Simpy, el cual es un entorno de simulacion creado por Klaus G. Muller, definido por K.
Muller (Muller, 2005) como un paquete de simulacion por eventos discretos, orientado
a objetos, basados en procesos, escrito y llamado desde un lenguaje de programacion
de desarrollo de software libre interpretado llamado Python.
Caracterısticas generales
Segun E. Briceno (Briceno, 2007) los elementos basicos de un modelo en SimPy son
objetos de tipo proceso. Estos son retardos por tiempos fijos o aleatorios de acuerdo a
las especificaciones del modelo conceptual y colocados en cola para el uso de algunos
recursos.
Un script en SimPy contiene la declaracion de una o mas instancias de procesos y la
creacion de una serie de objetos a partir de estos. Ademas el paquete esta formado por
un conjunto de modulos escritos en Python, los cuales se mencionan a continuacion:
Simulation: modulo que tiene implementada las definiciones de las clases y meto-
dos para los objetos Process (Procesos) y Resources (Recursos), empleados en los
modelos de simulacion.
Monitor: modulo que registra los resultados generados en las variables de interes,
recopilando estadısticas basicas simples en cada uno de los recursos empleados.
2.5 Optimizacion 25
SimulationTrace: modulo que implementa las trazas para los eventos.
SimulationRT: es el modulo que permite controlar la velocidad de la simulacion
a traves de la sincronizacion de los eventos para tiempo real (Real Time).
SimulationStep: modulo para realizar la simulacion paso a paso.
SimPlot: permite realizar graficas de estadısticas durante la simulacion.
SimGui: este modulo provee las herramientas para implementar el modelo de
simulacion con interfaces graficas de usuario (GUI).
Lister: es el modulo empleado para darle un mejor formato de impresion a los
objetos Simpy empleados por el modelo.
2.5. Optimizacion
A traves del proceso de simulacion se logra comprender el funcionamiento del sis-
tema, ası como tambien observar su comportamiento ante ciertas variaciones del mismo.
Debido a las exigencias que hoy dıa se perciben en la sociedad en general, no solo basta
entender el comportamiento de los sistemas e intuir posibles diagnosticos de compor-
tamiento; sino tambien tratar de encontrar esa configuracion que permita prestar los
servicios de la forma mas eficiente posible.
Optimizar significa el proceso de tratar de encontrar la mejor solucion posible para
un determinado problema, de acuerdo a cierto criterio se puede expresar como encontrar
el valor de unas variables de decision sujetas a unas restricciones para los que una
determinada funcion objetivo alcanza su valor maximo o mınimo absoluto. Se puede
encontrar una gran cantidad de problemas de optimizacion, tanto en la industria como
en la ciencia. Desde los clasicos problemas de diseno de redes de telecomunicacion
hasta los mas actuales en ingenierıa y re-ingenierıa de software, existen una infinidad
de problemas teoricos y practicos que involucran a la optimizacion. (UN, 2007)
Algunas clases de problemas de optimizacion son relativamente faciles de resolver.
Este es el caso, por ejemplo, de los problemas lineales, en los que tanto la funcion
objetivo como las restricciones son expresiones lineales, que pueden ser resueltos con
2.5 Optimizacion 26
el conocido metodo Simplex; sin embargo, muchos otros tipos de problemas de opti-
mizacion son muy difıciles de resolver. De hecho, la mayor parte de los que se pueden
encontrar en la practica entran dentro de esta categorıa. La existencia de una gran can-
tidad y variedad de problemas difıciles que necesitan ser resueltos de forma eficiente,
impulso el desarrollo de procedimientos que encuentran buenas soluciones aunque no
sean optimas. Estos metodos, en los que la rapidez del proceso es tan importante como
la calidad de la solucion obtenida, se denominan heurısticos o aproximados.
2.5.1. Optimizacion a traves de Metodos Heurısticos
Los metodos heurısticos son procedimientos para resolver un problema de opti-
mizacion bien definido mediante una aproximacion intuitiva, en la que la estructura
del problema se utiliza de forma inteligente para obtener una buena solucion (optimo
entre las soluciones que ha explora).
En contraposicion a los metodos exactos que proporcionan una solucion optima del
problema, los metodos heurısticos se limitan a proporcionar una buena solucion del
problema no necesariamente optima. Logicamente, el tiempo invertido por un metodo
exacto para encontrar la solucion optima de un problema difıcil, es de un orden de
magnitud bastante superior al del heurıstico (pudiendo llegar a ser inaplicable).
La complejidad de los problemas que aparecen en la practica, ası como la necesidad
de obtener buenas soluciones en tiempos relativamente pequenos, han llevado a la
utilizacion de los metodos heurısticos en la mayor parte de las aplicaciones.
A principio de la decada de los 80 comenzaron a aparecer una serie de metodos
bajo el nombre de Metaheurısticos con el proposito de obtener mejores resultados que
los alcanzados por los heurısticos tradicionales . Estos procedimientos surgen de la
confluencia de distintas areas de conocimiento como las Matematicas, la Biologıa, la
Ingenierıa, etc. Especıficamente, los procedimientos Metaheurısticos son el resultado de
la fusion de los metodos de optimizacion con las tecnicas de la Inteligencia Artificial.
2.5 Optimizacion 27
2.5.2. Procedimientos Metaheurısticos
Los procedimientos Metaheurısticos son una clase de metodos aproximados que
estan disenados para resolver problemas difıciles de optimizacion combinatoria, en los
que los heurısticos clasicos no son efectivos. Los Metaheurısticos proporcionan un marco
general para crear nuevos algoritmos hıbridos combinando diferentes conceptos deriva-
dos de la inteligencia artificial, la evolucion biologica y los mecanismos estadısticos.
Ası pues, los procedimientos Metaheurısticos se situan conceptualmente “por enci-
ma” de los heurısticos en el sentido que guıan el diseno de estos.
Los tipos de Heurısticos realizan la busqueda de la solucion a traves de varios
metodos:
Constructivos: se anaden paulatinamente componentes a las soluciones para
obtener la solucion factible (ej: metodo del vecino mas cercano para el problema
del viajante).
Descomposicion: se divide el problema en problemas mas pequenos siendo la
entrada de uno la salida del siguiente. Al resolverlos se obtiene una solucion para
el problema global.
Linealizar funciones no lineales
Busqueda por entornos: parten de una solucion inicial, se mueven a soluciones
factibles del entorno de modo iterativo, almacenan la mejor solucion obtenida.
En los ultimos anos ha habido un crecimiento espectacular en el desarrollo de pro-
cedimientos Metaheurısticos para dar soluciones aproximadas a problemas de opti-
mizacion. Este hecho se ve reflejado cada vez mas, en los procesos industriales donde
se requiere de un mayor ajuste y eficiencia, lo que conlleva a la busqueda de soluciones
aproximadas al optimo de sus procesos y por lo tanto al uso de estos metodos. (UN,
2007)
Entre los procedimientos Metaheurısticos se encuentra:
2.5 Optimizacion 28
2.5.3. Recocido Simulado
Fue propuesto en 1983 por Kirkpatrick y otros, para la resolucion de un problema
de localizacion en VLSI (Very Large Scale Integration)5. Es un metodo de busqueda
estocastico que realiza una busqueda iterativa sobre soluciones puntuales, analogo al
proceso fısico de recocido, donde un solido cristalino es enfriado lentamente hasta
alcanzar el estado de mınima energıa. (DCO, 2007)
El proceso que sigue es similar al fısico que consta de calentar el solido a elevada
temperatura y luego descender la temperatura lentamente, ası las particulas se colocan
en su estado fundamental de mas baja energıa (y el mas estable).
A partir de aquı hasta el final del capıtulo, han sido tomadas las ideas de J.Pacheco
(Pacheco, 2007) con permiso de su autora.
Fısicamente las particulas de un solido se distribuyen de acuerdo a una probabili-
dad PE denominada probabilidad de Boltzmann, la cual simula los cambios energeticos
hasta alcanzar el equilibrio termico observando cada estado con energıa Ei a la tem-
peratura T , esta distribucion de probabilidad se muestra en la ecuacion 2.1
PE =1
Z(T )e−EiKBT (2.1)
donde KB es la constante de Boltzmann cuyo valor es 1.38 · 10−26 j · k−1 y solo tiene
significancia en el campo de la termodinamica. Z(T ) es un factor de normalizacion que
depende del parametro de control T . E representa el cambio energetico de las partıculas
entre dos estados vecinos. T correponde al parametro de control y es conocido como
temperatura.
El factor de normalizacion Z(T ) se define como en la ecuacion 2.2, esta sumatoria
devuelve 1 por lo tanto, el factor de Boltzmann es e−EiKBT .
PE =∑
j
e−EiKBT (2.2)
De la ecuacion 2.1 se deduce que a medida que T se decrementa la distribucion se
concentra solo en los estados de menor energıa.
5Integracion en escala muy grande de sistemas de circuitos basados en transistores, como parte delas tecnologıas de semiconductores y comunicacion.
2.5 Optimizacion 29
El algoritmo de Kirkpatrick combina los mecanismos de enfriamiento y de recocido.
Se propuso como funcion de enfriamiento la mostrada en la ecuacion 2.3
Tk = α · TK−1 = αk · T0 (2.3)
donde k toma valores dentro del rango [0, 1] y se utilizan como tasa de decrecimiento
los valores [0,8; 0,99] que empıricamente han demostrado ser velocidades lentas de
enfriamiento. La razon por la cual se deben escoger valores dentro del rango senalado
es porque si se disminuye al parametro de control T demasiado rapido, entonces no
se logra alcanzar una buena solucion (fısicamente esto indica que no se alcanza el
equilibrio termico dentro del solido); por el contrario si se disminuye muy lentamente
la solucion convergera al optimo con una alta probabilidad pero el costo computacional
es muy elevado.
El nucleo de RS es el algoritmo de Metropolis, el cual simula los cambios energeticos
y la configuracion de las partıculas en el proceso fısico de recocido bajo la distribucion
de probabilidad de Boltzmann hasta que el solido alcanza el equilibrio termico como
se muestra en la ecuacion 2.1. El criterio de Metropolis aplicado a problemas de
optimizacion es el siguiente:
1. En principio, se parte de una configuracion inicial de operacion.
2. Se genera una configuracion vecina a la inicial mediante alguna distorsion aleato-
ria.
3. Ambas configuraciones son evaluadas en una funcion objetivo que se encarga de
medir la calidad de las mismas. Si el vecino mejora la salida de la funcion objetivo
se acepta como la nueva configuracion de operacion, en caso contrario se acepta
de acuerdo a la distribucion de probabilidad de Boltzmann, la cual es controlada
por el parametro de control T .
Parametros del Algoritmo Recocido Simulado
Temperatura: la temperatura inicial es el parametro crucial en el desempeno
de RS, se encarga de controlar la aleatoriedad con respecto a los desplazamientos
2.5 Optimizacion 30
realizados que son difıcilmente aceptados a temperaturas bajas; esta se determi-
na realizando una serie de pruebas hasta alcanzar una fraccion predefinida de
movimientos aceptados. La temperatura final de enfriamiento debe tender a 0,
permitiendo que al final del recorrido solo se acepten configuraciones de puntos
que mejoren la funcion.
Longitud de la cadena: a traves de las cadenas de Markov se modela
matematicamente el RS a traves de la formulacion una secuencia de cadenas
de Markov de longitud finita que convergen al conjunto de soluciones optimas, si
el parametro de control decrece lentamente. La longitud de la cadena de Markov
define el numero de configuraciones aceptadas dentro del entorno de busqueda
(vecinos de la solucion actual), conocidos como puntos de mejora o de no mejora
para cada valor del parametro de control.
Criterio de parada: existen varios criterios de parada para el algoritmo RS,
uno de ellos es establecerlo cuando el valor del parametro de control ha alcanzado
el valor 0, el cual casi no es usado por el elevado costo computacional en el que se
incurre si el modelo no es muy complejo; otro criterio es asignar un valor umbral
para la evaluacion de la funcion objetivo, este no se considera eficaz debido a
que RS busca el optimo global de la funcion y este criterio limita de antemano
al concepto de la metaheurıstica.
Generacion de nuevos puntos para una estructura de vecindad: los
puntos son generados al azar tomando un elemento del entorno que se obtiene al
perturbar la solucion actual con un pequeno desplazamiento.
2.5.4. Algoritmo basico de Recocido Simulado
Recocido Simulado consta de los siguientes pasos:
1. Asignar la solucion inicial.
2. Estimar la temperatura inicial.
2.5 Optimizacion 31
3. Generar la nueva solucion, perturbando aleatoriamente la solucion inicial, y luego
calcular la diferencia entre la evaluacion de los puntos; o lo que es lo mismo se
calcula la diferencia energetica de las partıculas dentro del solido.
4. Establecer el numero de soluciones candidatas a ser exploradas, las cuales se
almacenan en la cadena de Markov.
5. Verificar si la solucion candidata es aceptada o no, bien sea porque siempre mejore
la solucion o a traves de la probabilidad dada por e−EiKBT , a esta regla de aceptacion
se le conoce como critero de Metropolis y es en funcion de ella que el equilibrio
es alcanzado.
6. Calcular la longitud de la cadena.
7. Ajustar el parametro de control, conocido como temperatura T .
8. Repetir el lazo comprendido entre los pasos 3 al 7 hasta que se haya alcanzado
el optimo global (entre las soluciones exploradas) o se haya cumplido el criterio
de parada para el algoritmo.
Capıtulo 3
Desarrollo del Modelo de
Simulacion del AFIS
3.1. Introduccion
El AFIS es un sistema complejo donde intervienen diversos factores, por lo cual se
hace necesario mencionarlos para comenzar a entender su funcionamiento.
El comportamiento del AFIS lo clasifica en el tipo de sistemas no terminantes,
debido a que trabaja las 24 horas del dıa los 365 dıas del ano. Para el procesamiento
de las transacciones se dedican 22 horas de trabajo, las 2 horas restantes son utilizadas
para labores de mantenimiento y la realizacion de los respaldos 1.
En este sentido, la orientacion de esta investigacion ha sido dirigida hacia el estudio
del flujo transaccional, es decir, el recorrido de las transacciones (solicitudes IDI o
ATU), por cada uno de los clientes de trabajo, sin tomar en consideracion aspectos
computacionales que puedan incidir en el mismo, costos, dinamicas internas de los
clientes y otros. Es importante mencionar que el modelo aquı desarrollado estudia el
AFIS desde la llegada de sus transacciones hasta la respuesta que el mismo da, no se
considera como es el proceso previo de como llegan las solicitudes ni su destino cuando
se da la respuesta. El estudio a nivel macro del proceso de tramitacion de documentos
en SAIME, se puede observar en la investigacion de B. Casanova (Casanova, 2008), en la
1Recomendaciones de la empresa facilitadora del software SAGEM Defense Securite
3.2 Modelo Descriptivo del Flujo Transaccional en el AFIS 33
cual se describe el proceso desde que el ciudadano solicita el tramite de un documento,
todo su tratamiento hasta el momento en que recibe la respuesta a su solicitud.
La salida de interes en el modelo de simulacion y, posteriormente, el parametro a
ser optimizado es el numero de transacciones procesadas en una hora.
Este resultado es extensible a numero de transacciones procesadas en un dıa, un mes,
un ano; ya que esta variable es uniformemente distribuida en los distintos horizontes
de tiempo.
Se hace uso para la implementacion del modelo del paquete de simulacion orientado
a eventos discretos SimPy, el cual esta dirigido a la interaccion de procesos. Basica-
mente, una interaccion de proceso es una secuencia de tiempos interrelacionados, de-
scribiendo la experiencia de una entidad a traves del sistema.
3.2. Modelo Descriptivo del Flujo Transaccional en
el AFIS
A continuacion se presenta, en la figura 3.1, la descripcion del flujo transaccional
del AFIS dividido en 4 zonas de trabajo, la cual fijo las bases para la estructura del
modelo de simulacion:
3.2 Modelo Descriptivo del Flujo Transaccional en el AFIS 34
Figura 3.1: Flujo transaccional del AFIS
3.2 Modelo Descriptivo del Flujo Transaccional en el AFIS 35
ZONA 1: para el AFIS las entradas corresponden a las Transacciones (1) que se
procesaran en el mismo. Estas transacciones pueden ser solicitudes o respuesta
que generalmente son enviadas en un correo electronico mediante un fichero NIST
que provienen del Centro de Datos o de las oficinas autorizadas.
Para todos los sitios, el intercambio de datos consiste en un solo mensaje, que
incluye el contenido del mensaje de negocios como dato adjunto. El asunto de
este mensaje incluira la siguiente informacion: [IP]-[TOT]-[TCN]-[PRY]-[HASH]
Donde:
• IP: Es la direccion IP del sitio que origina el envıo del mensaje.
• TOT: Es el Tipo de Transaccion (“Type of Transaction”).
• TCN: Es el Numero de Control de la Transaccion (´´Transaction Con-
trol Number”). Este numero tiene que ser unico para cada transaccion, no
se puede utilizar 2 veces el mismo TCN, incluso para relanzar la misma
transaccion.
• PRY: Es la Prioridad de la transaccion.
• HASH: Es el hash del mensaje adjunto, utilizando el algoritmo SHA-1.
Dentro del asunto del mensaje, cada campo de datos estara separado por el
caracter guion (-). Estos datos estan incluidos en el asunto del mensaje para fines
informativos o de verificacion, y salvo el HASH no seran usados por servicios
automaticos que reciben y procesan el mensaje.
ZONA 2: en esta etapa se reciben las transacciones y se verifica que su origen
sea una direccion autorizada.
Las transacciones llegan al servidor AFIS que es el corazon del mismo; esta basa-
do en un servidor de base de datos Oracle. Sus principales funciones son las
siguientes:
1. Manejar la base de datos AFIS: los datos temporales, tal como las solicitudes
y los datos permanentes tal como las fichas decadactilares.
3.2 Modelo Descriptivo del Flujo Transaccional en el AFIS 36
2. Manejar las operaciones del flujo de trabajo para el procesamiento de las
solicitudes a los clientes o aplicativos del flujo de trabajo para efectuar los
procesamientos requeridos.
Servidor SMTP (2): El servidor AFIS conocido como Servidor SMTP envıa las
solicitudes para ser procesadas en los aplicativos internos del AFIS. El Servidor
SMTP es el punto de entrada y salida del AFIS. Materializa la comunicacion
entre el mundo externo y el AFIS. Recibe las diversas peticiones (autenticacion,
identificacion) bajo la forma de correos electronicos que contienen un archivo
ANSI/NIST adjunto. Asimismo, responde a dichas peticiones enviando correos
electronicos que contienen un archivo ANSI/NIST adjunto.
El Servidor SMTP se comunica unicamente, y en forma directa, con un servidor
de correo electronico del MIJ especialmente designado para este fin.
Recepcion de datos: CEI Receptor (3): El (CEI - Component External In-
terface) es el punto de entrada de las imagenes y datos alfanumericos, contenidos
en registros en formato ANSI/NIST. El CEI verifica que los archivos ANSI/NIST
esten correctos, y genera una respuesta de error en caso contrario.
El CEI verifica el envıo correcto de los datos comparando el hash del archivo
enviado, presente en el e-mail de la solicitud, contra el hash del archivo recibido,
y verificando que estos sean identicos. La intencion del hash es verificar que no
hubo problemas de transmision entre las estaciones de captura y el AFIS (no es
el objetivo del hash detectar casos de substitucion de datos por un atacante). El
algoritmo hash que se utiliza es el SHA-1, con una implementacion segun Open
SSL.
El CEI solo acepta informacion proveniente de direcciones de correo electronico
y direcciones IP autorizadas, nunca acepta solicitudes NIST sin origen. Si hay
error (problema de calidad) se almacena en una carpeta llamada corruptos.
El AFIS posee cuatro clientes CEI Receptor, configurado en cuatro maquinas
distintas. Segun J. Perez (Perez, 2007) administrador del AFIS, el numero de
clientes a configurar de este tipo puede variar entre uno y cuatro, considerando
que deben estar en maquinas distintas.
3.2 Modelo Descriptivo del Flujo Transaccional en el AFIS 37
ZONA 3: en esta etapa se pueden distiguir varios subprocesos encargados de
tramitar las solicitudes que se hacen al AFIS. Si las solicitudes no presentan
error en la Zona 2 son enviadas a los aplicativos de esta zona dependiendo del
tipo de transaccion.
Control de datos: AIN (AFIS IN) (4): Este aplicativo verifica la existencia
o no-existencia del identificador biometrico de la persona (BIO ID) en la base de
datos, antes de realizar un proceso siguiente. Asimismo, decide si debe realizarse
un proceso de codificacion o no. Ademas certifica la calidad de la transaccion y
verifica si el BIOID no esta repetido y hacia donde la va a enviar.
Tratamiento de Excepciones: EXM (5): El tratamiento de excepciones per-
mite saber las causas de error en algunos de los aplicativos para luego dar con-
tinuacion a la transaccion respectiva.
El operador puede:
• Corregir el error y relanzar la transaccion.
• Suspender momentaneamente la transaccion en espera de mas informacion.
• Parar el proceso de la transaccion.
Ademas en esta estacion se puede ver y controlar el estado del sistema. Los errores
pueden venir del codificador (COD), cotejador 1/1 (MOO), cotejador 1/N (MI),
analisis dactilar (FSV) o de control de datos (AIN).
Codificador: COD (6): El COD es el sistema de procesamiento de imagenes
que se encarga de la codificacion de las huellas de adultos (no juveniles) en el
sitio central, en caso de ser necesario. El proceso de codificacion de una huella
digital consiste en identificar y almacenar los puntos caracterısticos de la misma.
Este proceso es totalmente automatico.
Todas las huellas digitales que han de ser comparadas en el Sistema de Cotejo
deben pasar por este proceso. En el AFIS, este proceso se realiza en dos puntos
diferentes, dependiendo del origen de las huellas:
3.2 Modelo Descriptivo del Flujo Transaccional en el AFIS 38
1. En el caso que el registro sea adquirido en las estaciones de captura que
utilizan el hardware y el software biometrico (modulo biometrico) propor-
cionados por SAGEM DS , y si se trata de una persona adulta (no juvenil),
la codificacion de las huellas digitales se realiza en la misma estacion.
2. Por el contrario, si el registro no es ingresado al sistema a traves de las
estaciones de captura, por ejemplo en el caso de comunicacion INTER-AFIS,
la codificacion de las imagenes dactilares se realiza en computadoras del
AFIS estipuladas para este fin, por el aplicativo COD.
Actualmente estan configurados 20 codificadores en maquinas distintas. Este
cliente puede variar entre 1 y 24 COD. (Perez, 2007)
Cotejador 1/1: MOO (7): Es la estacion automatica que realiza la funcion de
autenticacion 1:1. Utiliza las minucias almacenadas en la base AFIS, correspon-
diente a la mejor ficha de cada persona.
Este tipo de cliente varıa entre 1 y 10 MOO. Hoy dıa se tiene configurado 3 MOO.
(Perez, 2007)
Cotejador 1/N: MI (8) y MetaMatcher: MAT (9): El Metamatcher (MCH)
es el software que realiza la busqueda de identificacion (cotejo 1:N). La identi-
ficacion consiste en comparar un aspirante con una seleccion de personas reg-
istradas previamente en el sistema AFIS y los coteja con su propia base de datos.
Matcher Interface (MI): Es la interfase entre el AFIS y el Metamatcher. El Meta-
matcher esta compuesto por tres (03) maquinas:
1. Maquina CU/DU: Tiene dos (02) funciones: CU: Servidor Control Unit se
encarga de los parametros de configuracion, administracion de colas y la
administracion del sistema. DU: Servidor Data Unit esta a cargo de la base
de datos persistente almacenada en disco.
2. Maquina MU: Servidor Matching Unit a cargo de las busquedas de cotejo.
3. Maquina RU: Servidor Reserve Unit a cargo de sustituir a los otros servidores
en caso que presenten alguna falla.
3.2 Modelo Descriptivo del Flujo Transaccional en el AFIS 39
En la figura 3.2 se observa la arquitectura METAMATCHER y Matcher Inter-
face.
Figura 3.2: Arquitectura METAMATCHER y Matcher Interface
El AFIS tiene configurado diez clientes MI. Segun J. Perez (Perez, 2007) admi-
nistrador del AFIS, el numero de clientes a configurar de este tipo puede variar
entre uno y catorce.
Analisis Dactilar (10): En las estaciones de Analisis Dactilar (FSV: Fingerprint
Search Verification) se procesan los HITs (posibles fraudes en caso de procesos de
identificacion o identificacion con insercion) o NO HITs (posibles fraudes en caso
de procesos de autenticacion con actualizacion o autenticacion con verificacion)
detectados por el cotejador.
El operador, un perito dactiloscopista, puede visualizar las huellas de la nueva
ficha objeto de las busquedas, y las huellas de los candidatos detectados por el
cotejador. Las fichas mostradas corresponden a la mejor ficha de cada persona.
El operador puede visualizar tambien los correspondientes numeros biometricos
de identificacion de la persona, pero no puede ver datos alfanumericos, fotos ni
3.2 Modelo Descriptivo del Flujo Transaccional en el AFIS 40
firmas relacionados a estas huellas.
Se puede confirmar o invalidar el HIT (identificacion) o el NO HIT (autenti-
cacion).
Como se dijo anteriormente en el capıtulo 2, existen 2 turnos de trabajo para
llevar a cabo la actividad de analisis dactilar, en el que actualmente laboran 9
peritos dactiloscopista por turno. Este cliente ha variado entre 6 y 9 peritos.
ZONA 4: en esta ultima etapa se envıa la respuesta a las solicitudes de identi-
ficacion o autenticacion realizadas al AFIS.
Publicacion de los resultados: AOUT (AFIS OUT) (11): Este aplicativo
se encarga de la salida de la transaccion y actualiza los datos cuando finaliza el
procesamiento.
CEI Emisor (12): Es el punto de salida de la respuesta, contenida en registros
en formato ANSI/NIST. Envıa dicha respuesta al servidor SMTP que se encarga
de enviar la respuesta a quien hizo la solicitud (Centro de Datos u Oficinas).
Hoy dıa estan configurado 2 clientes de este tipo. Puede variar entre uno y dos
CEI Emisores.
Existen varios procesos que no entran directamente en el flujo de trabajo porque se
realizan en intervalos de tiempo distintos al de la jornada diaria, entre esos se muestran:
Purga de depuracion de la base de datos: es un suceso que se realiza todos
los dıas a la 1 a.m., puede tardar 2 horas y consume el 30 % de recurso; ocasionando
que se encole las transacciones en la entrada.
En cuanto a los respaldos se tiene:
Backup Day: se lanza despues de la jornada de trabajo a las 7 p.m. y tarda 30
min. Es un backup incremental.
Backup Week: se hace los fines de semana, es un backup total y tarda hora y
media. Se detienen los CEI Receptores y por ende se encolan allı.
Estos aspectos no fueron tomados en cuenta para el modelo de simulacion, por la
dificultad para tomar los datos correspondientes que permitieran estimar parametros,
3.3 Construccion del Modelo de Simulacion 41
ası como tambien debido a que los expertos en la administracion del AFIS afirman que
no son determinantes para evaluar el rendimiento del flujo transaccional diario.
3.3. Construccion del Modelo de Simulacion
3.3.1. Recoleccion de datos y estimacion de parametros
La recoleccion de los datos necesarios para modelar el AFIS, se realizo a traves
de la observacion directa, entrevistas, ası como tambien, los reportes de produccion y
reportes de las colas de trabajo en los clientes.
La estimacion de los parametros que conforman el modelo de la seccion 3.2, es-
pecıficamente el de la figura 3.1, se muestran a continuacion:
I. Distribucion de llegadas: para la estimacion de la llegada de las transacciones,
se procedio a utilizar los datos que corresponden a la produccion diaria por hora
desde abril-2007 hasta abril 2008, en la cual se observan las llegadas de tran-
sacciones por hora. Por razones de volumen de informacion solo se muestra el
movimiento de transacciones por hora para un dıa en la figura 3.3.
En la realizacion del analisis estadıstico sobre el comportamiento en las llegadas
de las transacciones, se hizo uso del paquete estadıstico Minitab a traves de Stat,
Reliability/Survival y Parametric Distribution Analysis, lo cual permitio conocer
la distribucion de llegadas, con el siguiente resultado:
Media de la exponencial igual a 22.5 y Anderson-Darling (adjusted)
= 0.6178
Al observar el valor del estadıstico de Anderson-Darling, corresponde a un valor
pequeno con respecto al mostrado en las otras distribuciones probadas (Weibull
A-D=0.6854; Lognormal A-D=0.7531, entre otros). Por tal motivo, se escoge la
Distibucion Exponencial para emular el comportamiento de las llegadas.
II. Las estimaciones para los parametros de la Zona 2, 3 y 4 de la figura 3.1, se
llevaron a cabo utilizando los registros del AFIS desde Abril de 2007 hasta Abril
3.3 Construccion del Modelo de Simulacion 42
Figura 3.3: Correos recibidos por el AFIS cada hora
de 2008, correspondientes a transacciones procesadas de acuerdo al tipo y colas
en cada unos de los clientes.
Los tiempos de atencion en los clientes se define a partir de la documentacion
existente y de acuerdo a la informacion facilitada por los administradores del
AFIS S.Gutierrez y J.Perez (Gutierrez, 2007; Perez, 2007), debido a que es costoso
obtener las mediciones.
En la tabla 3.1 se observa cada uno de los clientes de trabajo en cada una de las
zonas, sus tiempos de atencion y capacidades.
3.3.2. Implementacion del modelo en SimPy
Esta subseccion presenta con detalle el proceso de desarrollo e implementacion del
modelo del AFIS, el cual se realizo bajo el estilo de programacion orientado a objetos de
Python separando a cada tarea que debıa realizar cada cliente de trabajo en funciones
para mejorar el desempeno del programa. A su vez, como se menciono anteriormente,
SimPy esta orientado a la interaccion de procesos, por ello para crear la simulacion se
3.3 Construccion del Modelo de Simulacion 43
Figura 3.4: Aproximacion a la Distribucion Exponencial
implementaron clases de tipo Process.
Posteriormente, se implementaron los Metodos de Ejecucion de Procesos (PEM
Process Execution Method) donde se definen el ciclo de vida de las entidades. Se brinda
la primitiva de activate para activar un proceso; y a traves de la serie de comandos
yield (estados) se avanza el tiempo durante la ejecucion de los procesos.
Las estadısticas que se toman en el modelo son referentes a transacciones procesadas
totales y de acuerdo al tipo (IDI o ATU).
A continuacion se muestra cada uno de los subprocesos que se implementaron, para
dar lugar a la simulacion del AFIS:
I. Generacion de las transacciones: las llegadas se generaron de acuerdo a la dis-
tribucion hallada para su comportamiento. A su vez, se hallo el porcentaje de
transacciones de tipo IDI y ATU que llegan, donde se observan dos tipos esce-
narios:
a) Mayor cantidad de transacciones del tipo IDI con respecto al tipo ATU, en
un porcentaje de 80 % y 20 % respectivamente para el horizonte de tiempo
de abril 2007 hasta diciembre 2007.
b) Cantidad de transacciones del tipo IDI con respecto al tipo ATU casi equi-
tativas, en un porcentaje de 55 % y 45 % respectivamente para el horizonte
3.3 Construccion del Modelo de Simulacion 44
Zonas de trabajo Parametro Tiempo de atencion (seg) Capacidad
Zona 2 Servidor SMTP 1 -
CEI Receptor Tmin=2,5 Tmax= 3,5 4
Zona 3 Control de Datos AIN 0,1 -
Excepciones EXM 6 -
Codificador COD Tmin=25,0 Tmax= 50,0 20
Cotejador 1/1 : MOO Tmin=3,0 Tmax= 4,5 3
Cotejador 1/N : MI 1,5 10
MetaMatcher MCH Tmin=15,0 Tmax=300,0 -
Analisis Dactilar FSV Tmin=15,0 Tmax=600,0 9
Zona 4 Publicacion AOUT 0,1 -
Cei Emisor Tmin=1,0 Tmax=2,0 2
Cuadro 3.1: Estimacion de parametros para el modelo del AFIS
de tiempo de enero 2008 hasta abril 2008.
Ambos casos se usaron para la validacion del modelo. Finalmente despues de gene-
rada la llegada y definido un numero de transacciones para IDI y ATU, se asigna
la prioridad con la cual van a ser procesadas dentro del AFIS. Seguidamente se
muestra el codigo:
class GenerarTransacciones(Process): #Generacion de las transacciones
def generar(self):
global TipoTrans,pry,numerogenerado,numerogeneradoATU,numerogeneradoIDI
visitar=’L’
while True:
#####La sentencia de decision permite generar la cantidad de transacciones del tipo IDI y ATU#####
if (random.random() > 0.45):
TipoTrans=’IDI’
else:
TipoTrans=’ATU’
#####Definido la cantidad por tipo se generan las llegadas con distribucion exponencial#####
yield hold,self,r.expovariate(1.13)
#####Generada las transacciones se les asigna la prioridad#####
if (TipoTrans==’IDI’):
3.3 Construccion del Modelo de Simulacion 45
pry=9
numerogeneradoIDI+=1
else:
numerogeneradoATU+=1
if (random.random() <= 4/100):
pry=1
else:
pry=2
numerogenerado+=1
t=Servidor()
activate(t,t.smtp(TipoTrans,pry,visitar)) #Activacion del Servidor SMTP, cuando se dan las llegadas
II. Servidor SMTP: se encarga de recibir las peticiones o de enviar las respuestas.
Para ello si la transaccion viene del proceso GenerarTransacciones, en el proceso
se da el retardo y se envıa posteriormente al CEI Receptor. De lo contrario, si el
mensaje proviene del CEI Emisor, el AFIS esta dando respuesta a la peticion y
se lleva un contador de transacciones procesadas tanto del tipo IDI como ATU.
class Servidor(Process):
def smtp(self,TipoTrans, pry,visitar):
global numeroprocesadoIDI,numeroprocesadoATU
#####Si la trans. proviene de GenerarTransacciones, se da retardo y activa el CEI Receptor#####
if (visitar==’L’):
yield hold, self, tsmtp
visitar=’S’
tr=Recepcion()
activate(tr, tr.llegada(TipoTrans,pry))
#####De lo contrario ya se proceso la transaccion#####
else:
if (TipoTrans==’IDI’):
if (visitar==’E’):
print "No tuvo solucion IDI"
else:
numeroprocesadoIDI+=1 ###Contador de transacciones del tipo IDI procesadas###
else:
if (visitar==’E’):
print "No tuvo solucion ATU"
else:
numeroprocesadoATU+=1 ###Contador de transacciones del tipo ATU procesadas###
III. Recepcion de Datos Cei Receptor: se modela de la forma recurso con capacidad
variable, se pregunta si alguno esta disponible para ser procesada una transaccion,
3.3 Construccion del Modelo de Simulacion 46
de ser ası se le da el retardo por el tiempo de atencion y luego se libera. Cuando
una transaccion sale de este proceso activa Control de Datos (AIN).
class Recepcion(Process):
def llegada(self,TipoTrans, pry):
#######################################################################################################
# Se solicita uno de los CEI Receptores si estan disponibles. Son un recurso de tipo capacidad variable
#######################################################################################################
yield request, self,receptor,pry
yield hold,self,r.uniform(TminReceptor, TmaxReceptor)
yield release, self, receptor
visitar=’R’
#####La transaccion sale del CEI Receptor y se envıa a Control de Datos AIN#####
tr=ControlDatos()
activate(tr, tr.ain(TipoTrans,pry,visitar))
IV. Control de Datos AIN (AFIS IN): se encarga de certificar la calidad de la transac-
cion, por ello se evalua una probabilidad de que la transaccion venga con error,
si no es ası activa el proceso Codificacion.
class ControlDatos(Process):
def ain(self,TipoTrans, pry,visitar):
yield hold, self, tain
######La trans. viene con baja calidad, por tanto se envıa a EXM#####
if (random.random() <= ProbError[0]):
visitar=’A’
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else:
#####Si no hay error en la trans., se envia para evaluar si pasara por el COD#####
coder=Codificacion()
activate(coder,coder.estado(TipoTrans,pry,visitar))
V. Tratamiento de Excepciones (EXM): todas las transacciones que caen en error
en algunos de los clientes de la zona de trabajo No 2, pasan a esta clase de tipo
proceso, se evalua si existe solucion y se relanza al cliente de donde proviene. Al
no tener solucion se envıa a publicacion de resultados.
class Excepcion(Process): #Transacciones con error son tratadas en Excepciones
def exm(self,TipoTrans, pry,visitar):
yield hold, self, texm
if (visitar == ’A’):
3.3 Construccion del Modelo de Simulacion 47
if (random.random() <= ProbNoSol[0]): #El error viene de AIN y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
tr=ControlDatos() #Error tiene solucion, proviene de AIN, se reenvıa a ese cliente#
activate(tr, tr.ain(TipoTrans,pry,visitar))
if (visitar == ’C’):
if (random.random() <= ProbNoSol[1]): #El error viene de COD y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
visitar=’E’ #Error tiene solucion, proviene de COD, se reenvıa a ese cliente#
tr=Coder()
activate(tr, tr.cod(TipoTrans,pry,visitar))
if (visitar == ’MOO’):
if (random.random() <= ProbNoSol[2]): #El error viene de MOO y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
visitar=’E’ #Error tiene solucion, proviene de MOO, se reenvıa a ese cliente#
tr=Cotejador11()
activate(tr, tr.moo(TipoTrans,pry,visitar))
if (visitar == ’MI’):
if (random.random() <= ProbNoSol[3]): #El error viene de MI y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
visitar=’E’ #Error tiene solucion, proviene de MI, se reenvıa a ese cliente#
tr=Cotejador1n()
activate(tr, tr.mi(TipoTrans,pry,visitar))
if (visitar == ’PER’):
if (random.random() <= ProbNoSol[4]): #El error viene de PERITO y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
visitar=’E’ #Error tiene solucion, proviene de PERITO, se reenvıa a ese cliente#
tr=Peritos()
activate(tr, tr.fsv(TipoTrans,pry,visitar))
VI. Existe parte del codigo que se encarga de evaluar si las huellas ya estan codificadas
en el AFIS, ası como tambien para estudiar el tipo de transaccion para ası poder
activar el cotejador que le corresponde.
class Codificacion(Process): #Transacciones que no tienen huellas en el AFIS se codifican#
def estado(self,TipoTrans, pry,visitar):
yield hold, self, testado
if (random.random() <= ProbNoCod[0]): #No esta codificado en el AFIS, se activa el COD#
tr=Coder()
activate(tr, tr.cod(TipoTrans,pry,visitar))
3.3 Construccion del Modelo de Simulacion 48
else: #Esta codificado no pasa por el COD, se debe evaluar que TOT posee#
tr=Transaccion()
activate(tr, tr.tcn(TipoTrans,pry,visitar))
class Transaccion(Process): ###Evaluacion del tipo de transaccion TOT)###
def tcn(self,TipoTrans, pry,visitar):
yield hold, self, ttot
if (TipoTrans==’ATU’): ###Si es ATU, se activa el cotejador MOO###
tr=Cotejador11()
activate(tr, tr.moo(TipoTrans,pry,visitar))
elif(TipoTrans==’IDI’): ###Si es IDI, se activa el cotejador MI###
tr=Cotejador1n()
activate(tr, tr.mi(TipoTrans,pry,visitar))
VII. Codificador COD: este cliente se encarga de simular la codificacion de las huellas
que no estan en la base de datos del AFIS. Es definido como recurso de tipo
capacidad variable.
class Coder(Process): #Codificacion de huellas para almacenar en el AFIS
def cod(self,TipoTrans, pry,visitar):
############################################################################################
# Se solicita uno de los COD si estan disponibles. Son un recurso de tipo capacidad variable
############################################################################################
yield request, self,codificador,pry
yield hold,self,r.uniform(TminCoder, TmaxCoder)
yield release, self, codificador
visitar=’C’
if (random.random() <= ProbError[1]): #Error en la codificacion y envio a EXM
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else:
tr=Transaccion() #Codificacion y envio a evaluacion de TOT#
activate(tr, tr.tcn(TipoTrans,pry,visitar))
VIII. Cotejador 1/1 MOO: procesa las transacciones del tipo ATU segun la prioridad
que tienen asignada. De igual modo, esta definido como recurso de tipo capacidad
variable. Si la comparacion que realiza no cumple con el umbral de aceptacion
permitido activa el proceso de analisis por peritos.
class Cotejador11(Process): #Cotejo 1:1 Transaccion Tipo ATU #
def moo(self,TipoTrans, pry,visitar):
############################################################################################
# Se solicita uno de los MOO si estan disponibles. Son un recurso de tipo capacidad variable
3.3 Construccion del Modelo de Simulacion 49
############################################################################################
yield request, self,cotejamoo,pry
yield hold,self,r.uniform(TminMoo, TmaxMoo)
yield release, self, cotejamoo
visitar=’MOO’
if (random.random() <= ProbError[2]): #Error en el cotejador MOO y envio a EXM
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else:
#####Si es la persona quien dice ser#####
if (random.random() <= Probhit[0]): #Respuesta hit se envia a publicar respuesta
tr=Publicacion()
activate(tr, tr.aout(TipoTrans,pry,visitar))
#####Existe varios candidatos con esas minucias#####
else: #Posibles candidatos se envia a revision de peritos
tr=Peritos()
activate(tr, tr.fsv(TipoTrans,pry,visitar))
IX. Cotejador 1/N MI: procesamiento de las transacciones IDI, este cliente envıa al
Metamatcher quien es el encargado de realizar la comparacion, por ende es el
puente de comunicacion y esta definido como recurso de tipo capacidad variable.
class Cotejador1n(Process): #Cotejo 1:n Transaccion Tipo IDI
def mi(self,TipoTrans, pry,visitar):
############################################################################################
# Se solicita uno de los MI si estan disponibles. Son un recurso de tipo capacidad variable
############################################################################################
yield request, self,cotejami,pry
yield hold, self, tmi
yield release, self, cotejami
visitar=’MI’
#####Activacion del MetaMatcher#####
tr=Metamatcher()
activate(tr, tr.meta(TipoTrans,pry,visitar))
X. Metamatcher MCH: se activa cuando el cotejador 1/N necesita hacer la compara-
cion.
class Metamatcher(Process): #Sistema de Cotejo Metamatcher
def meta(self,TipoTrans, pry,visitar):
yield hold,self,r.uniform(TminMeta, TmaxMeta)
visitar=’META’
if (random.random() <= ProbError[3]): #Error en el cotejador MI y envio a EXM#
tr=Excepcion()
3.3 Construccion del Modelo de Simulacion 50
activate(tr, tr.exm(TipoTrans,pry,visitar))
else:
#####No existe en la base de datos las huellas#####
if (random.random() <= Probhit[1]): #Respuesta No hit se envia a publicar respuesta#
tr=Publicacion()
activate(tr, tr.aout(TipoTrans,pry,visitar))
else: #Posibles candidatos envio a revision de peritos
tr=Peritos()
activate(tr, tr.fsv(TipoTrans,pry,visitar))
XI. Analisis Dactilar FSV (Peritos): este proceso es activado cuando las huellas a sercomparadas en el cotejador 1/1 o 1/N no cumplen con el umbral de aceptacion.Este modulo emula el trabajo que realizan los dactiloscopista.
class Peritos(Process): #Estacion de Peritos
def fsv(self,TipoTrans, pry,visitar):
################################################################################################
# Se solicita uno de los PERITOS si estan disponibles. Son un recurso de tipo capacidad variable
################################################################################################
yield request, self,perito,pry
yield hold,self,r.uniform(TminPer, TmaxPer)
yield release, self, perito
visitar=’PER’
if (random.random() <= ProbError[4]): #Error en la estacion perito y envio a EXM
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else: #Publicacion de respuesta dada por peritos
tr=Publicacion()
activate(tr, tr.aout(TipoTrans,pry,visitar))
Las probabilidades de error en el procesamiento de las transacciones de algunos
clientes como AIN, COD, MI, MOO, FSV; se determino a traves de datos facili-
tados por los administradores del AFIS (Gutierrez, 2007; Perez, 2007), en el cual
se observo para cada cliente cual es el porcentaje de transacciones que de acuerdo
a la entrada caen en error y por ende enviado a EXM. De igual manera, estos
datos permitieron hallar la probabilidad de que EXM no de solucion al error que
presenta la transaccion.
La probabilidad de que hoy dıa en el AFIS no se encuentren huellas codificadas
de un ciudadano es muy baja, ya que la mayorıa de los venezolanos tienen sus
huellas en la base de datos AFIS.
3.4 Verificacion y Validacion del modelo 51
La probabilidad de Partial Hit (cliente MOO) o Hit (cliente MI), se determino de
acuerdo al umbral de aceptacion y al margen de precision establecido en la do-
cumentacion de la empresa facilitadora del software (SAGEM, 2006).
XII. Publicacion de Resultados AOUT (AFIS OUT): finalizado el procesamiento, este
proceso se encarga de enviar la respuesta al Cei Emisor mediante la activacion
de dicho proceso.
class Publicacion(Process): #Publicacion de resultados
def aout(self,TipoTrans, pry,visitar):
yield hold, self, taout
#####Activacion del CEI Emisor#####
tr=Emisor()
activate(tr, tr.ceie(TipoTrans,pry,visitar))
XIII. Cei Emisor: recibe la respuesta y activa el servidor SMTP. Es un tipo recurso de
capacidad variable.
class Emisor(Process): #Envio de la respuesta a traves de CEI Emisor
def ceie(self,TipoTrans, pry,visitar):
##############################################################################################
# Se solicita uno de los CEI Emisores si estan disponibles. Recurso de tipo capacidad variable
##############################################################################################
yield request, self,emisor,pry
yield hold,self,r.uniform(TminEmisor, TmaxEmisor)
yield release, self, emisor
visitar=’EMI’
#####Se envia la respuesta de la transaccion procesada activando el SMTP#####
tr=Servidor()
activate(tr, tr.smtp(TipoTrans,pry,visitar))
El codigo de implementacion del modelo de simulacion del AFIS completo se puede
observar en el Apendice A.
3.4. Verificacion y Validacion del modelo
Construido el modelo y estimados los parametros, se procedio a la verificacion
paulatina a medida que se fue desarrollando.
Las pruebas de verificacion usadas fueron:
3.4 Verificacion y Validacion del modelo 52
I. Diseno Modular: el modelo se estructuro en modulos que se comunican por inter-
faces bien definidas (variables de entrada y salida), mostrado en la seccion 3.3.
Esto permitio dividir el problema de verificacion en problemas mas pequenos y
se logro evaluar cada uno de los modulos que emulan los clientes de trabajo por
separado.
II. Pruebas de degeneracion: se asigno valores extremos, a pesar de que no represen-
ten casos tıpicos. Entre ellos:
Todos los clientes de trabajo con capacidad uno y tiempo de simulacion
de una hora (3600seg), lo cual muestra lo que se esperaba que la cola en el
receptor creciera debido a que existe un solo servidor y la salida disminuyera
considerablemente al ser comparada con lo que procesa actualmente el AFIS.
Los resultados de procesamiento en esta prueba fueron 478 transacciones del
tipo ATU y 360 del tipo IDI.
Entrada de 100 % transacciones del tipo IDI y entrada del 100 % transac-
ciones del tipo ATU: para las trasancciones de tipo IDI el AFIS tiene la
capacidad de procesar 3500 transacciones por hora y para las transacciones
del tipo ATU procesa 1600 transacciones por hora (SAGEM, 2006).
En tiempo de procesamiento de transacciones es menor para el caso ATU
que para el tiempo IDI. Ambos resultados se verificaron y se muestran a
continuacion:
Entrada 100\% de transacciones de tipo IDI
Numero generado f(4066)
Numero IDI generado=4066 Numero ATU generado=0
IDI procesado=3402 ATU procesado=0
Tiempo de la corrida:
real 3m6.933s
user 2m56.543s
sys 0m0.364s
Entrada 100\% de transacciones de tipo ATU
Numero generado f(4054)
Numero IDI generado=0 Numero ATU generado=4054
3.4 Verificacion y Validacion del modelo 53
IDI procesado=0 ATU procesado=1667
Tiempo de la corrida:
real 2m34.007s
user 2m29.093s
sys 0m0.320s
III. Independencia de semillas: para asegurar la independencia de semillas, se inves-
tiga que SimPy usa el generador de Python, el cual produce 53-bit de precision
y dispone de un perıodo de 2**19937-1.
Para la validacion se observo que los resultados obtenidos en la simulacion estu-
vieran proximos a los observados en el sistema real. Para ello se llevo a cabo:
Intuicion de expertos: en conjunto con los administradores del AFIS, por ser los
expertos en el sistema, se evaluo los resultados que se obtuvieron del modelo y
se constato que los resultados obtenidos por el modelo de simulacion.
Comparacion de medias: para ello se corrio el modelo en varios horizontes de
tiempo con 30 replicas cada uno, con la finalidad de comparar los datos teoricos
medidos del sistema real con el sistema modelado.
En este proceso se corrio el modelo por una hora de tiempo simulado equivalente
a 3600 seg, y se tomo las transacciones procesadas totales, ası como tambien
clasificadas segun el tipo de transaccion (IDI o ATU). De igual manera, se hicieron
las mismas corridas por un dıa de tiempo simulado correspondientes a 22 horas de
trabajo con 79200 seg. De la informacion obtenida en ambas, se tomo las medias
y se comparo con los datos disponibles de la produccion del AFIS por hora y por
dıa.
Es importante mencionar que para una buena validacion y comparacion se co-
rrieron varios casos en los cuales existen datos historicos con los que se pudo
comparar, entre ellos:
• 80 % IDI y 20 % ATU.
• 55 %IDI y 45 % ATU.
3.5 Analisis de Sensibilidad 54
Figura 3.5: Resultados para la produccion por hora Caso 80 % IDI y 20 % ATU
Se puede observar en la figura 3.5 el resultado de la produccion obtenida para
la corrida en una hora, en el caso 80 % IDI y 20 % ATU.
De los datos tomados de la produccion del mes de mayo de 2007, se tuvo una
media de 3474 transacciones por hora. Al compararse con el resultado obtenido
por el modelo de simulacion hay una diferencia de 18 transacciones que equivalen
al 0.51 % de error, lo cual permite concluir que el modelo esta representando en
buena medida el sistema real.
Sistema Real Modelo Diferencia
3474 transacciones/hora 3492 transacciones/hora 18 transacciones/hora
Para el caso de la corrida del modelo por un dıa caso 80 % IDI y 20 % ATU, se
obtuvo una media de 79474 transacciones por hora.
Sistema Real Modelo Diferencia
79222 transacciones/dıa 79474 transacciones/dıa 252 transacciones/dıa
Comparado con la media de la produccion diaria del mes de junio de 2007, se
nota una diferencia de 252 transacciones, que equivale a 0,31 % de diferencia,
por lo que el modelo de simulacion esta representando con un alto porcentaje el
modelo real.
3.5. Analisis de Sensibilidad
Con el modelo de simulacion se realizaron varios experimentos, con la finalidad de
observar si existe alguna dependencia entre los clientes, o si existıa alguna influencia
3.5 Analisis de Sensibilidad 55
significativa en la produccion de transacciones con respecto a la capacidad de algunos
de ellos.
En primer lugar, se experimento cambiando el tiempo de atencion del CEI Receptor
dejando fijos todos los demas parametros en el resto de los clientes. Se observo que
cuando se incrementaba el tiempo de atencion en el receptor y las corridas se hacıan
por un tiempo de simulacion de un mes el sistema colapsaba debido a que las colas en
ese cliente crecıan infinitamente y por ende no existıan colas en la salida por las pocas
transacciones que salıan del CEI Receptor.
Otro escenario trabajado fue la disminucion del tiempo de atencion del receptor,
lo cual ocasiono que el sistema procesara normal las transacciones pero al llegar a la
zona de salida, especifıcamente en el CEI Emisor, las colas crecıan de forma tal que
colapsaba ese cliente, y por ende, disminuıa la cantidad de transacciones procesadas
por unidad de tiempo.
Este escenario permitio concluir que entre el CEI Receptor y el CEI Emisor existe
una dependencia en cuanto a tiempos de atencion en cada uno, lo cual los hace sensibles
a cambios en los mismos. En atencion a lo expuesto anteriormente, si se disminuye el
tiempo de atencion al CEI Receptor por ende al CEI Emisor en igual magnitud y
viceversa, para que asi no colapse el sistema en horizontes de tiempo prolongados.
En segundo lugar, para el escenario que presentara el AFIS en un futuro proximo,
en el cual se procesara mas solicitudes del Tipo ATU y disminuira el Tipo IDI, debido
a que la mayorıa de los venezolanos ya tienen sus huellas dentro de la base de datos
AFIS, se corrio el modelo para el caso 55 % IDI y 45 % ATU con la disminucion de
la capacidad del codificador dejando los demas parametros fijos, con la finalidad de
observar en los resultados si habıa variabilidad en las transacciones procesadas.
Con este experimento, se observo que el procesamiento de las transacciones del tipo
ATU son mas rapidas que las IDI, ya que las transacciones del tipo IDI su demora es
debida a la entrada de la transaccion en el codificador. En vista de eso, los resultados
mostraron que la capacidad del codificador se podıa disminuir de 20 a un rango entre
15 y 18 codificadores.
Capıtulo 4
Seudo-Optimizacion del Modelo de
Simulacion del AFIS con la
Metaheurıstica de Recocido
Simulado
4.1. Introduccion
Este capıtulo muestra la optimizacion del modelo de simulacion del AFIS desa-
rrollado en el capıtulo anterior con la herramienta de optimizacion metaheurıstica de
Recocido Simulado. La metodologıa de Recocido Simulado ha sido escogida como parte
de esta investigacion por ser una tecnica probada en la optimizacion de modelos de
simulacion orientados a eventos discretos, implementado en el trabajo de J.Pacheco
(Pacheco, 2007), en el cual se mostro excelentes resultados en la optimizacion de mo-
delos de simulacion.
De igual manera, la importancia en la rapidez del proceso, como la calidad de la
solucion obtenida y la capacidad para trabajar con variables discretas o continuas en el
dominio de la solucion sin ninguna modificacion en su codificacion, han sido propiedades
determinantes en la escogencia de la herramienta de optimizacion Recocido Simulado.
4.2 Busqueda de la optimizacion del modelo de simulacion del AFIS 57
4.2. Busqueda de la optimizacion del modelo de
simulacion del AFIS
El objetivo a seudo-optimizar para el AFIS es la “Maximizacion de las
transacciones procesadas en una hora”.
Este objetivo se logra hallando los valores de 6 variables de decision, que representan
la capacidad de los clientes que se emularon en el capıtulo 3 como recurso de capacidad
variable. Se escogen estas variables para el proceso de optimizacion, ya que son las
que los administradores del AFIS pueden variar, debido a que los otros parametros
que contribuyen en el procesamiento de las transacciones son difıciles de modificar por
especificaciones de la empresa facilitadora del sofware (SAGEM, 2006).
Cada una de las variables quedan asignadas de la siguiente manera:
x --> Cei Receptor
y --> Codificador COD
z --> Cotejador 1/1 MOO
w --> Cotejador 1/N MI
t --> Analisis Dactilar FSV
s --> Cei Emisor
Dichas variables de decision, estan sujetas a las siguientes restricciones:
x --> [1,4]
y --> [1,24]
z --> [1,10]
w --> [1,14]
t --> [6,9]
s --> [1,2]
Entendido el problema y establecido lo que se querıa optimizar, seguidamente se
procedio con los requerimientos exigidos en la herramienta de Recocido Simulado para
iniciar la busqueda del optimo en modelos de simulacion a eventos discretos.
En primer lugar, se necesito determinar las condiciones iniciales en cuanto a los
parametros de la tecnica como tal, ası como tambien los valores iniciales de las
variables de decision.
4.2 Busqueda de la optimizacion del modelo de simulacion del AFIS 58
Para las variables de decision, se tomo como inicio la configuracion actual del
AFIS, con la finalidad de mostrar si dicha configuracion es la que permite el
mayor procesamiento de transacciones o lograr conocer a traves de la herramienta
si existe otra configuracion de clientes de trabajo que maximice la cantidad de
transacciones procesadas en una hora.
Estos datos son cargados por la herramienta a traves del archivo que lleva por
nombre experimentos.py mostrado en la tabla 4.1:
Parametro Valor
x 4
y 20
z 3
w 10
t 9
s 2
longCadena 50
maxIntentos 100
minIntentos 20
minRazonAceptacion 0,8
alfa 0,8
beta 1,2
maxCadenas 10
tamanoVecindad 1
Cuadro 4.1: Parametros de RS para optimizar el modelo del AFIS
La herramienta recibe el modelo de simulacion a traves de un archivo que lleva
por nombre funcion.py, el cual se ajusta de forma tal, que actue como funcion
de Python. En el archivo principal donde se encuentra la metodologıa de RS se
establece la comunicacion con este modulo.
Finalmente un archivo con nombre restricciones sin extension es donde se incluyen
4.2 Busqueda de la optimizacion del modelo de simulacion del AFIS 59
las restricciones del modelo, mencionadas anteriormente.
Para la optimizacion del modelo de simulacion del AFIS con la herramienta de
Recocido Simulado, se trabajo dos escenarios, los cuales se muestran a continuacion:
I. Maximizacion de las transacciones procesadas en una hora: Entrada 60 % transac-
ciones del tipo ATU y 40 % transacciones del tipo IDI
El escenario en el cual existe un mayor numero de llegada de transacciones del
tipo ATU con respecto al tipo IDI, en un futuro proximo se hara realidad. En vista
de esto, se considero importante al instante de la optimizacion de este escenario
por el beneficio que aporta a la toma de decisiones dentro del AFIS.
Cuando se comienza la ejecucion de la herramienta de seudo-optimizacion, las
condiciones iniciales muestra una produccion de 3710 transacciones por hora con
la configuracion actual:
f( s, t, w, x, y, z)
punto inicial: f( 2.00, 9.00, 10.00, 4.00, 20.00, 3.00) = -3710.00
La herramienta de optimizacion genera el siguiente resultado:
f( s, t, w, x, y, z)
Mejor punto encontrado: f( 2.00, 9.00, 8.00, 4.00, 23.00,10.00) = -3791.00
Ahora bien, se observa que la tecnica encuentra una configuracion en la cual se
puede llegar a producir 3791 transacciones por hora, con la siguiente configuracion
de clientes:
4 CEI Receptor
23 Codificadores
10 MOO
8 MI
4.2 Busqueda de la optimizacion del modelo de simulacion del AFIS 60
9 Peritos
2 Cei Emisor
De los cuales, la configuracion de los CEI Receptores, Peritos y Cei Emisor se
mantienen igual. La herramienta de seudo-optimizacion muestra que se debe au-
mentar para este caso la cantidad de Cotejadores 1/1 de 3 a 10, reducir la cantidad
de Cotejador 1/N de 10 a 8 y aumentar los codificadores de 20 a 23.
El aumento de cotejadores 1/1, tiene sentido por la cantidad de transacciones del
tipo ATU que estan entrando al AFIS y, como se esta disminuyendo la cantidad
de transacciones del tipo IDI recomienda que de igual manera se disminuya la
cantidad de cotejador 1/N; es decir, que se puede observar la compensacion que
hay de acuerdo a la entrada que se esta asignando.
Los codificadores no dependen del tipo de transaccion que se va ha procesar, sino
de que las huellas del ciudadano se encuentren dentro de la base de datos AFIS,
es por ello que, de acuerdo a lo que se haya dado en la corrida, posiblemente se
presentaron casos de no existencia de huellas dentro de la base de datos AFIS,
por lo que arroja como respuesta la inclusion de 3 codificadores mas.
El Tiempo de ejecucion que tomo este caso alcanzo los 4 dıas, esto se debe a la
magnitud del modelo de simulacion. Se requirio seudo-optimizar un modelo de 6
variables donde la superficie de busqueda fue bastante amplia, y conseguir la com-
binacion de parametros que maximizara la cantidad de transacciones procesadas
necesito una gran cantidad de intentos, que alcanzo los 9661 intentos.
Es importante mencionar que se observo que la herramienta de Recocido Sim-
ulado explora la mayorıa de los posibles valores de las variables de decision y
en un tiempo mucho menor que si se realizaran estas pruebas con el modelo de
simulacion probando una por una cada una de las configuraciones, se tendrıa que
invertir alrededor de 6 meses para conseguir lo que procesa cada una de las com-
binaciones y posteriormente decidir cual es la mejor configuracion (la que procese
mas transacciones).
4.2 Busqueda de la optimizacion del modelo de simulacion del AFIS 61
A continuacion se puede observar en el grafico 4.1 como se alcanzo el valor maxi-
mo de transacciones procesadas por hora en funcion del numero de iteraciones.
Figura 4.1: Valor maximo en funcion del numero de iteraciones 40 % IDI y 60 % ATU
II. Maximizacion de las transacciones procesadas en una hora: Entrada 60 % transac-
ciones del tipo IDI y 40 % transacciones del tipo ATU
Este escenario representa la entrada que recibe actualmente el AFIS. Es por
ello que se considero importante la seudo-optimizacion de este escenario con la
finalidad de conocer si la configuracion actual es apropiada o se puede ajustar
para aumentar el procesamiento de transacciones.
Al iniciar la ejecucion de la herramienta de optimizacion, el punto inicial muestra
un procesamiento 3625 transacciones por hora con la configuracion actual:
f( s, t, w, x, y, z)
punto inicial: f( 2.00, 9.00, 10.00, 4.00, 20.00, 3.00) = - 3625.00
La herramienta de optimizacion genera el siguiente resultado:
4.2 Busqueda de la optimizacion del modelo de simulacion del AFIS 62
f( s, t, w, x, y, z)
Mejor punto encontrado: f(2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00
La herramienta en su busqueda encuentra una configuracion en la cual se puede
llegar a producir 3667 transacciones por hora, con la siguiente configuracion de
clientes:
4 CEI Receptor
17 Codificadores
10 MOO
11 MI
9 Peritos
2 Cei Emisor
Se puede observar que de igual forma la configuracion de los CEI Receptores,
Peritos y CEI Emisor se mantienen igual. La herramienta de seudo-optimizacion
muestra que se debe aumentar para este caso la cantidad de Cotejadores 1/1
de 3 a 10, aumentar la cantidad de Cotejador 1/N de 10 a 11 y disminuir los
codificadores de 20 a 17.
Dicha configuracion procesa 3667 transacciones por hora, que corresponden a 42
transacciones mas que la produccion actual. Lo que se traduce en un aumento de
924 transacciones por dıa de la produccion diaria actual.
El Tiempo de ejecucion que tomo este caso alcanzo los 8 dıas con 8929 intentos
en la busqueda. Esto se debe, a que en este escenario las transacciones del tipo
IDI consumen mas recurso con respecto a las transacciones del tipo ATU; a su
vez, influye la magnitud del modelo de simulacion.
De igual forma, se observo que la herramienta de Recocido Simulado explora
en la mayorıa de los posibles valores de las variables, si esta serie de pruebas
4.2 Busqueda de la optimizacion del modelo de simulacion del AFIS 63
para este caso se hiciesen con el modelo de simulacion probando una por una las
combinaciones se tendrıa que invertir alrededor de 9 meses para conseguir lo que
procesarıa cada configuracion y posteriormente decidir cual es la mejor de ellas.
A continuacion se puede observar en el grafico 4.2 como se alcanzo el valor maxi-
mo de transacciones procesadas por hora en funcion del numero de iteraciones.
Figura 4.2: Valor maximo en funcion del numero de iteraciones 60 % IDI y 40 % ATU
Capıtulo 5
Conclusiones y Recomendaciones
El producto de este proyecto de grado es el modelo de simulacion del Sistema Au-
tomatizado de Identificacion Dactilar (AFIS), utilizando la metodologıa de simulacion
de sistemas orientados a eventos discretos y el paquete de Simulacion SimPy, bajo
lenguaje Python. Gran parte de ese producto ha sido la optimizacion del modelo de
simulacion con la metaheurıstica de Recocido Simulado.
Los resultados obtenidos en la optimizacion del modelo demuestran que, de acuerdo
al escenario en el cual el AFIS se encuentre, puede ajustarse para lograr procesar la
mayor cantidad de transacciones por hora, lo que por ende se vera reflejado en el
rendimiento del sistema y en la produccion diaria, mensual y anual.
Se analizaron 2 escenarios, uno de ellos inclinado hacia un futuro proximo y el otro
referido a la actual configuracion del AFIS. El primero de ellos, se represento definien-
do una entrada de transacciones al AFIS de 60 % transacciones del tipo ATU y 40 %
transacciones del tipo IDI, donde se obtuvo una configuracion que procesa mas transac-
ciones con respecto a la configuracion actual. Dicha configuracion consta de: 4 CEI
Receptor, 23 Codificadores, 10 MOO, 8 MI, 9 Peritos y 2 Cei Emisor; para una pro-
duccion de 3791 transacciones por hora correspondientes a 81 transacciones mas que
la produccion actual.
El segundo caso corresponde a una entrada de transacciones al AFIS de 40 %
transacciones del tipo ATU y 60 % transacciones del tipo IDI, la cual muestra una
configuracion con respecto a la actual que procesa mas transacciones, tal como sigue:
5 Conclusiones y Recomendaciones 65
4 CEI Receptor, 17 Codificadores, 10 MOO, 11 MI, 9 Peritos y 2 Cei Emisor; con
procesamiento de 3667 transacciones por hora, que corresponden a 42 transacciones
mas que la produccion actual.
Las diferencias en el procesamiento de las transacciones en sus valores absolutos,
pueden dar pie a conluir que no es de gran magnitud la mejora, de tal forma que se
pueda dar el cambio en la configuracion, sin embargo, es importante mencionar que el
mejoramiento en el rendimiento del sistema en cuanto a consumo de tiempo y recurso
si podra ser observado y quedara evidenciado en el producto que se obtenga.
Con el modelo de simulacion se logro establecer un modelo descriptivo del flujo
transaccional en el AFIS, el cual permitio la comprension de los procesos que allı se
realizan gracias al nivel de detalle alcanzado, y sento las bases para la implementacion
en SimPy.
El modelo del AFIS refleja en buena medida al sistema real. En las corridas realiza-
das para la verificacion y validacion del modelo, se pudo observar que las transacciones
procesadas por hora, diaria y mensual en el modelo difieren del sistema real en un mar-
gen lo suficientemente pequeno, permitiendo concluir que el modelo esta representando
el sistema real.
El modelo de simulacion del AFIS representa un gran beneficio para los adminis-
tradores del AFIS. Al obtener esta herramienta, el departamento AFIS podra realizar
pruebas de configuraciones y evaluar la evolucion del sistema, sin necesidad de aplicar
estos cambios directamente, es decir, el modelo permite hacer las pruebas y de acuerdo
a los resultados obtenidos, se evaluan y se decide la implementacion o no en el sistema
real.
Entre otros resultados observados dentro del modelo de simulacion, se encuentran:
Existe relacion lineal entre los tiempos de atencion de los CEI Receptores y
los CEI Emisores, debido a que deben estar proporcionados para que fluyan las
transacciones dentro del AFIS sin ningun problema, ya que al existir menor tiem-
po de atencion en un cliente con respecto al otro comienza a formarse colas muy
grandes, lo que implica un colapso en el sistema en horizontes de tiempos largos.
La cantidad de codificadores COD puede ser disminuido en funcion del numero
5.1 Recomendaciones 66
de huellas de venezolanos que esten insertadas dentro de la base de datos del
AFIS.
5.1. Recomendaciones
El modelo de simulacion del AFIS puede ampliarse agregando los tiempos que in-
vierte el AFIS al realizar los respaldos a partir de una simulacion de 24 horas diarias.
Se podrıa comenzar agregando el respaldo diario, esto implica manejo de sincroniza-
ciones en SimPy, controlando el tiempo para que cada vez que transcurran 22 horas de
trabajo consecutivas se active un proceso (el que emularıa el respaldo) y se desactiven
todos los procesos que esten trabajando por el tiempo que consume la realizacion de
un respaldo y nuevamente se volverıa a reactivar los procesos, con esto se observarıa
como crece la cola en la entrada al AFIS y como se comportarıa el AFIS al reanudarse
los procesos. Esto permitira conocer el impacto de los respaldos en el procesamiento
de las transacciones.
En la toma de decisiones para la configuracion del AFIS, es importante que se tome
en cuenta la cantidad y tipo de transacciones que procesara el AFIS. Con esto, se
lograra establecer el numero de clientes necesarios para el procesamiento de ese tipo de
transacciones, ya que no se establecerıa configuraciones de clientes que eventualmente
resultaran innecesarias en el tratamiento de transacciones. Esto se puede llevar a cabo
variando los parametros en el modelo de simulacion, estableciendo la entrada y el
tiempo de corrida.
Crear un entorno grafico para interactuar con el modelo de simulacion, compatible
con Python como Gtk. De tal forma que se introduzca la configuracion de clientes, la
cantidad de transacciones por tipo y el tiempo de simulacion que se desea. Con esto
los administradores del AFIS solo se encargarıa de establecer los valores que desean
probar y esperar que el modelo a traves de la interfaz grafica le muestre el numero de
transacciones que puede procesar el AFIS en esa unidad de tiempo.
Bibliografıa
(2007). Identificacion biometrica. Artıculo en lınea, Abril 2007. Consultado en Mayo de
2007. Disponible en http://soydondenopienso.wordpress.com/2007/04/08/que-es-la-
identificacionbiometrica- con-huellas-digitales/.
(2007). Optimizacion. Artıculo en lınea, Abril 2007. Consultado en mayo de 2007.
Disponible en http://www.tecnun.es/asignaturas/io2/Examenes//Tema.
(2007). Recocido simulado. Artıculo en lınea, Agosto 2007. Consultado en octubre de
2007. Disponible en http://dco.us.es/webdco/recocido.htm.
Avendano, J. (2007). Optimizacion de modelos de simulacion en simpy. aplicacion de
la metodologıa de superficie de respuesta. Proyecto de Grado EISULA, Universidad
de los Andes, Escuela de Ingenierıa de Sistemas.
Bolıvar, A. (2005). Desarrollo de una herramienta de optimizacion basada en analisis
de superficie de respuesta para modelos de simulacion. Proyecto de Grado EISULA,
Universidad de los Andes, Escuela de Ingenierıa de Sistemas.
Briceno, E. (2007). Estudio comparativo del paquete de simulacion orientado a eventos
discretos simpy. desarrollo de un manual de usuario con ejemplos resueltos. Proyecto
de Grado EISULA, Universidad de los Andes, Escuela de Ingenierıa de Sistemas.
Carson, Y. and Anu, M. (1997). Simulation optimization: Methods and applications.
Winter Simulation Conference.
Casanova, B. (2008). Simulacion del sistema de generacion y expedicion de pasaportes
electronicos venezolanos. Proyecto de Grado EISULA, Universidad de los Andes,
Escuela de Ingenierıa de Sistemas.
BIBLIOGRAFIA 68
Duran, J. and Sinani, F. (2002). Optimizacion del funcionamiento de una panaderıa
mediante un modelo de simulacion caso de estudio: Panaderıa de villa san antonio.
Disponible en http://www.univalle.edu/publicaciones/journal/journal10/pag3.htm.
Guash, A., Piera, M., Casanovas, J., and Figueras, J. (2005). Aplicaciones a procesos
logısticos de fabricacion y servicios. Edicions UPC, 1 edition.
Gutierrez, S. (2007). Administrador del AFIS. Entrevista. Agosto,2007.
Hoeger, H. (2005). Pasos en un estudio de simulacion. Guıas en lınea. Disponible en
http://www.ing.ula.ve/ hhoeger/curso sim.html, Consultado en Mayo de 2007.
Law, A. and Kelton, W. (2000). Simulation Modeling and Analysis. McGraw-Hill.
Muller, K. (2005). Simpy: System simulation in python, [en lınea]. Disponible en
http://simpy.sourceforge.net/simpyoverview.htm, Consultado en Junio de 2007.
Morales, J. J. (2006). Direccion nacional de con-
trol de extranjeros de la onidex. Disponible en
http://www.mci.gob.ve/entrevistas/3/11049/sistema de identificacion.html, Con-
sultado en Mayo de 2007.
Pacheco, J. (2007). Optimizacion de modelos de simulacion en simpy utilizando la
metaheurısitca de recocido simulado. Proyecto de Grado EISULA, Universidad de
los Andes, Escuela de Ingenierıa de Sistemas.
Perez, J. I. (2007). Administrador del AFIS. Entrevista. Diciembre,2007.
SAGEM (2006). Guıa de administracion afis civil. Guıa para adminitradores del AFIS,
SAGEM Defense Securite, Eragny, France.
Teran, C. (2003). Evaluacion mediante simulacion de los parametros de diseno de las
paradas del sistema de transporte masivo de la ciudad de merida (trolebus). Proyecto
de Grado EISULA, Universidad de los Andes, Escuela de Ingenierıa de Sistemas.
Univalle (2007). Sistemas biometricos. Artıculo en lınea, Junio 2007.Consultado en
Julio de 2007. Disponible en http://www.univalle.edu/noticias/journal/journal10/.
Apendice A
Codigo de implementacion del
modelo de simulacion para el AFIS
"""Sistema Automatizado de Identificacion Dactilar""" #
#-*-coding:utf-8 -*- from SimPy.Simulation import * import random
import string
salida1=open("resultados.aux","w+r")
def noRelanzar(TipoTrans,pry,visitar): #Funcion encargada de las
transacciones que no tiene solucion
visitar=’E’
tr=Publicacion()
activate(tr, tr.aout(TipoTrans,pry,visitar))
##########Componentes del modelo############
class GenerarTransacciones(Process): #Generacion de las transacciones
def generar(self):
global TipoTrans,pry,numerogenerado,numerogeneradoATU,numerogeneradoIDI
visitar=’L’
while True:
#####La sentencia de decision permite generar la cantidad de transacciones del tipo IDI y ATU#####
if (random.random() > 0.45):
TipoTrans=’IDI’
else:
TipoTrans=’ATU’
#####Definido la cantidad por tipo se generan las llegadas con distribucion exponencial#####
yield hold,self,r.expovariate(1.13)
#####Generada las transacciones se les asigna la prioridad#####
if (TipoTrans==’IDI’):
A Codigo de implementacion del modelo de simulacion para el AFIS 70
pry=9
numerogeneradoIDI+=1
else:
numerogeneradoATU+=1
if (random.random() <= 4/100):
pry=1
else:
pry=2
numerogenerado+=1
t=Servidor()
activate(t,t.smtp(TipoTrans,pry,visitar)) #Activacion del Servidor SMTP, cuando se dan las llegadas
#########Inicio del procesamiento de las transacciones#########
class Servidor(Process):
def smtp(self,TipoTrans, pry,visitar):
global numeroprocesadoIDI,numeroprocesadoATU
#####Si la trans. proviene de GenerarTransacciones, se da retardo y activa el CEI Receptor#####
if (visitar==’L’):
yield hold, self, tsmtp
visitar=’S’
tr=Recepcion()
activate(tr, tr.llegada(TipoTrans,pry))
#####De lo contrario ya se proceso la transaccion#####
else:
if (TipoTrans==’IDI’):
if (visitar==’E’):
print "No tuvo solucion IDI"
else:
numeroprocesadoIDI+=1 ###Contador de transacciones del tipo IDI procesadas###
else:
if (visitar==’E’):
print "No tuvo solucion ATU"
else:
numeroprocesadoATU+=1 ###Contador de transacciones del tipo ATU procesadas###
class Recepcion(Process):
def llegada(self,TipoTrans, pry):
#######################################################################################################
# Se solicita uno de los CEI Receptores si estan disponibles. Son un recurso de tipo capacidad variable
#######################################################################################################
yield request, self,receptor,pry
yield hold,self,r.uniform(TminReceptor, TmaxReceptor)
yield release, self, receptor
visitar=’R’
A Codigo de implementacion del modelo de simulacion para el AFIS 71
#####La transaccion sale del CEI Receptor y se envıa a Control de Datos AIN#####
tr=ControlDatos()
activate(tr, tr.ain(TipoTrans,pry,visitar))
class ControlDatos(Process):
def ain(self,TipoTrans, pry,visitar):
yield hold, self, tain
######La trans. viene con baja calidad, por tanto se envıa a EXM#####
if (random.random() <= ProbError[0]):
visitar=’A’
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else:
#####Si no hay error en la trans., se envia para evaluar si pasara por el COD#####
coder=Codificacion()
activate(coder,coder.estado(TipoTrans,pry,visitar))
class Excepcion(Process): #Transacciones con error son tratadas en Excepciones
def exm(self,TipoTrans, pry,visitar):
yield hold, self, texm
if (visitar == ’A’):
if (random.random() <= ProbNoSol[0]): #El error viene de AIN y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
tr=ControlDatos() #Error tiene solucion, proviene de AIN, se reenvıa a ese cliente#
activate(tr, tr.ain(TipoTrans,pry,visitar))
if (visitar == ’C’):
if (random.random() <= ProbNoSol[1]): #El error viene de COD y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
visitar=’E’ #Error tiene solucion, proviene de COD, se reenvıa a ese cliente#
tr=Coder()
activate(tr, tr.cod(TipoTrans,pry,visitar))
if (visitar == ’MOO’):
if (random.random() <= ProbNoSol[2]): #El error viene de MOO y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
visitar=’E’ #Error tiene solucion, proviene de MOO, se reenvıa a ese cliente#
tr=Cotejador11()
activate(tr, tr.moo(TipoTrans,pry,visitar))
if (visitar == ’MI’):
if (random.random() <= ProbNoSol[3]): #El error viene de MI y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
visitar=’E’ #Error tiene solucion, proviene de MI, se reenvıa a ese cliente#
A Codigo de implementacion del modelo de simulacion para el AFIS 72
tr=Cotejador1n()
activate(tr, tr.mi(TipoTrans,pry,visitar))
if (visitar == ’PER’):
if (random.random() <= ProbNoSol[4]): #El error viene de PERITO y no tiene solucion
noRelanzar(TipoTrans,pry,visitar)
else:
visitar=’E’ #Error tiene solucion, proviene de PERITO, se reenvıa a ese cliente#
tr=Peritos()
activate(tr, tr.fsv(TipoTrans,pry,visitar))
class Codificacion(Process): #Transacciones que no tienen huellas en el AFIS se codifican#
def estado(self,TipoTrans, pry,visitar):
yield hold, self, testado
if (random.random() <= ProbNoCod[0]): #No esta codificado en el AFIS, se activa el COD#
tr=Coder()
activate(tr, tr.cod(TipoTrans,pry,visitar))
else: #Esta codificado no pasa por el COD, se debe evaluar que TOT posee#
tr=Transaccion()
activate(tr, tr.tcn(TipoTrans,pry,visitar))
class Transaccion(Process): ###Evaluacion del tipo de transaccion TOT)###
def tcn(self,TipoTrans, pry,visitar):
yield hold, self, ttot
if (TipoTrans==’ATU’): ###Si es ATU, se activa el cotejador MOO###
tr=Cotejador11()
activate(tr, tr.moo(TipoTrans,pry,visitar))
elif(TipoTrans==’IDI’): ###Si es IDI, se activa el cotejador MI###
tr=Cotejador1n()
activate(tr, tr.mi(TipoTrans,pry,visitar))
class Coder(Process): #Codificacion de huellas para almacenar en el AFIS
def cod(self,TipoTrans, pry,visitar):
############################################################################################
# Se solicita uno de los COD si estan disponibles. Son un recurso de tipo capacidad variable
############################################################################################
yield request, self,codificador,pry
yield hold,self,r.uniform(TminCoder, TmaxCoder)
yield release, self, codificador
visitar=’C’
if (random.random() <= ProbError[1]): #Error en la codificacion y envio a EXM
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else:
tr=Transaccion() #Codificacion y envio a evaluacion de TOT#
activate(tr, tr.tcn(TipoTrans,pry,visitar))
A Codigo de implementacion del modelo de simulacion para el AFIS 73
class Cotejador11(Process): #Cotejo 1:1 Transaccion Tipo ATU #
def moo(self,TipoTrans, pry,visitar):
############################################################################################
# Se solicita uno de los MOO si estan disponibles. Son un recurso de tipo capacidad variable
############################################################################################
yield request, self,cotejamoo,pry
yield hold,self,r.uniform(TminMoo, TmaxMoo)
yield release, self, cotejamoo
visitar=’MOO’
if (random.random() <= ProbError[2]): #Error en el cotejador MOO y envio a EXM
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else:
#####Si es la persona quien dice ser#####
if (random.random() <= Probhit[0]): #Respuesta hit se envia a publicar respuesta
tr=Publicacion()
activate(tr, tr.aout(TipoTrans,pry,visitar))
#####Existe varios candidatos con esas minucias#####
else: #Posibles candidatos se envia a revision de peritos
tr=Peritos()
activate(tr, tr.fsv(TipoTrans,pry,visitar))
class Cotejador1n(Process): #Cotejo 1:n Transaccion Tipo IDI
def mi(self,TipoTrans, pry,visitar):
############################################################################################
# Se solicita uno de los MI si estan disponibles. Son un recurso de tipo capacidad variable
############################################################################################
yield request, self,cotejami,pry
yield hold, self, tmi
yield release, self, cotejami
visitar=’MI’
#####Activacion del MetaMatcher#####
tr=Metamatcher()
activate(tr, tr.meta(TipoTrans,pry,visitar))
class Metamatcher(Process): #Sistema de Cotejo Metamatcher
def meta(self,TipoTrans, pry,visitar):
yield hold,self,r.uniform(TminMeta, TmaxMeta)
visitar=’META’
if (random.random() <= ProbError[3]): #Error en el cotejador MI y envio a EXM#
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else:
#####No existe en la base de datos las huellas#####
A Codigo de implementacion del modelo de simulacion para el AFIS 74
if (random.random() <= Probhit[1]): #Respuesta No hit se envia a publicar respuesta#
tr=Publicacion()
activate(tr, tr.aout(TipoTrans,pry,visitar))
else: #Posibles candidatos envio a revision de peritos
tr=Peritos()
activate(tr, tr.fsv(TipoTrans,pry,visitar))
class Peritos(Process): #Estacion de Peritos
def fsv(self,TipoTrans, pry,visitar):
################################################################################################
# Se solicita uno de los PERITOS si estan disponibles. Son un recurso de tipo capacidad variable
################################################################################################
yield request, self,perito,pry
yield hold,self,r.uniform(TminPer, TmaxPer)
yield release, self, perito
visitar=’PER’
if (random.random() <= ProbError[4]): #Error en la estacion perito y envio a EXM
tr=Excepcion()
activate(tr, tr.exm(TipoTrans,pry,visitar))
else: #Publicacion de respuesta dada por peritos
tr=Publicacion()
activate(tr, tr.aout(TipoTrans,pry,visitar))
class Publicacion(Process): #Publicacion de resultados
def aout(self,TipoTrans, pry,visitar):
yield hold, self, taout
#####Activacion del CEI Emisor#####
tr=Emisor()
activate(tr, tr.ceie(TipoTrans,pry,visitar))
class Emisor(Process): #Envio de la respuesta a traves de CEI Emisor
def ceie(self,TipoTrans, pry,visitar):
##############################################################################################
# Se solicita uno de los CEI Emisores si estan disponibles. Recurso de tipo capacidad variable
##############################################################################################
yield request, self,emisor,pry
yield hold,self,r.uniform(TminEmisor, TmaxEmisor)
yield release, self, emisor
visitar=’EMI’
#####Se envia la respuesta de la transaccion procesada activando el SMTP#####
tr=Servidor()
activate(tr, tr.smtp(TipoTrans,pry,visitar))
###########Modelo##########################
A Codigo de implementacion del modelo de simulacion para el AFIS 75
def model():
global receptor,visitar,ProbError, codificador,cotejamoo, Probhit,
cotejami, perito, emisor,numeroprocesadoIDI,numeroprocesadoATU,
numerogenerado, tsmtp,ProbNoCod,ProbNoSol,tain,texm,testado,ttcn,tmeta,
taout,a,monisali, TipoTrans,numerogeneradoIDI,numerogeneradoATU
numerogenerado=0
numeroprocesadoIDI=0
numeroprocesadoATU=0
numerogeneradoIDI=0
numerogeneradoATU=0
receptor=Resource(capacity=4, name="CEI Receptor", qType=PriorityQ, preemptable=True)
codificador=Resource(capacity=20, name="COD", qType=PriorityQ, preemptable=True)
cotejamoo=Resource(capacity=3, name="MOO",qType=PriorityQ, preemptable=True)
cotejami=Resource(capacity=10, name="MI",qType=PriorityQ, preemptable=True)
perito=Resource(capacity=6, name="Peritos",qType=PriorityQ, preemptable=True)
emisor=Resource(capacity=2, name="CEI Emisor", qType=PriorityQ, preemptable=True)
ProbError = [5.0/100.0, 8.0/100.0, 2.0/100.0, 10.0/100.0, 8.0/100.0] #Prob. de errores en los clientes
ProbNoSol = [0.02, 0.02, 0.03, 0.02, 0.03] #Prob. de que no se solucione los errores en EXM
ProbNoCod = [0.001] #Prob. de huellas que todavia no estan en el AFIS
Probhit = [0.95, 0.95] #Prob. de partial hit(MOO) y de hit(META)
initialize()
gt=GenerarTransacciones()
activate(gt,gt.generar())
simulate(until=TiempoFuncionamiento)
##############Datos del experimento##########################
TiempoFuncionamiento=79200
TminReceptor=2.5; TmaxReceptor=3.5
TminCoder=25.0; TmaxCoder=50.0
TminMoo=3.0; TmaxMoo=4.5
TminMeta=15.0; TmaxMeta=300.0
TminPer=15.0; TmaxPer=600.0
TminEmisor=1.0; TmaxEmisor=2.0
tsmtp=1.0
tain=0.1
texm=6.0
testado=0.001
ttot=0.001
tmi=1.5
taout=0.1
Nreplicas=30
r=random.seed()
A Codigo de implementacion del modelo de simulacion para el AFIS 76
r=random.Random(r)
################Experimento###########################3
model()
transaccionesprocesadas=0
generacionpromedio=0
generaIDIpromedio=0
generaATUpromedio=0
procesaIDIpromedio=0
procesaATUpromedio=0
for replica in range(Nreplicas)
gru=model()
generacionpromedio = generacionpromedio+numerogenerado
generaIDIpromedio = generaIDIpromedio+numerogeneradoIDI
generaATUpromedio = generaATUpromedio+numerogeneradoATU
procesaIDIpromedio = procesaIDIpromedio+numeroprocesadoIDI
procesaATUpromedio = procesaATUpromedio+numeroprocesadoATU
transaccionesprocesadas = transaccionesprocesadas + (numeroprocesadoIDI+numeroprocesadoATU)
generacionpromedio = generacionpromedio/Nreplicas
generaIDIpromedio = generaIDIpromedio/Nreplicas
generaATUpromedio = generaATUpromedio/Nreplicas
procesaIDIpromedio = procesaIDIpromedio/Nreplicas
procesaATUpromedio = procesaATUpromedio/Nreplicas
transaccionesprocesadas = transaccionesprocesadas/Nreplicas
###################Analisis y Salidas############################
salida1.write("Numero generado f(%s)\t" % generacionpromedio)
salida1.write("\n")
salida1.write("Numero IDI generado: %5d" % generaIDIpromedio + " Numero ATU generado: %5d" % generaATUpromedio)
salida1.write("\n")
salida1.write("IDI procesado= %5d" % procesaIDIpromedio + " ATU procesado = %5d" % procesaATUpromedio)
salida1.write("\n")
salida1.write("Transacciones procesadas finales en promedio de 30 replicas: %5d" % (transaccionesprocesadas))
Nota: El tiempo de funcionamiento observado en el codido equivale a 1 dıa de
simulacion (22 horas de trabajo por 3600 seg equivale a 79200 seg). De forma similar,
se sustituye el tiempo de funcionamiento para una semana, un mes o incluso un ano.
Apendice B
Resultados en la Maximizacion de
las transacciones procesadas por
hora para el caso 60 % ATU y 40 %
IDI, usando la metaheurıstica de
Recocido Simulado
*** Inicio del programa ***
punto inicial: f( 2.00, 8.00, 10.00, 4.00, 20.00, 3.00)=-3710.00
temp inicial = 2250475987692.6 intentos aceptados = 125
{’s’: 1, ’t’: 8, ’w’: 8, ’y’: 22, ’x’: 4, ’z’: 4}
temp=2250475987692.6 intentos = 157
f( 1.00, 8.00,8.00,4.00,22.00, 4.00) = -2395.00
temperatura = 2250475987692.6 intentos = 207 f( 1.00, 8.00, 12.00, 3.00, 16.00, 2.00) =-2377.00 sin mejora = 1
temperatura = 1800380790154.1 intentos = 257 f( 1.00, 8.00, 11.00, 3.00, 22.00, 3.00) = -2372.00 sin mejora = 2
temperatura = 1440304632123.3 intentos = 307 f( 1.00, 9.00, 6.00, 4.00, 22.00, 4.00) = -2381.00 sin mejora = 0
:
:
:
temperatura =299139568.7 intentos = 2207 f( 2.00, 7.00, 9.00, 3.00, 15.00,10.00) = -3254.00 sin mejora = 0
temperatura = 239311654.9 intentos = 2257 f( 1.00, 8.00, 9.00, 2.00, 7.00, 9.00) =-2124.00 sin mejora = 1
temperatura = 191449323.9 intentos =2307 f( 1.00, 8.00, 12.00, 4.00, 20.00, 2.00) = -2377.00 sin mejora = 0
:
:
B Resultados en la Maximizacion de las transacciones procesadas por hora para el
caso 60 % ATU y 40 % IDI, usando la metaheurıstica de Recocido Simulado 78
:
temperatura = 77661.1 intentos = 4059 f( 2.00, 6.00, 3.00, 2.00, 7.00, 2.00) =-2117.00 sin mejora = 2
temperatura = 62128.9 intentos = 4109 f(2.00, 8.00, 9.00, 2.00, 1.00, 3.00) = -2127.00 sin mejora = 0
temperatura = 49703.1 intentos = 4159 f( 2.00, 9.00, 10.00, 2.00,11.00, 9.00) = -2153.00 sin mejora = 0
:
:
:
temperatura = 5.3 intentos = 7461 f(2.00, 9.00, 9.00, 4.00, 24.00, 9.00) = -3760.00 sin mejora = 2
temperatura = 4.2 intentos = 7561 f( 2.00, 9.00, 9.00, 4.00,24.00, 9.00) = -3749.00 sin mejora = 3
temperatura = 3.4 intentos = 7661 f( 2.00, 8.00, 10.00, 4.00, 24.00, 10.00) =-3768.00 sin mejora = 0
temperatura = 2.7 intentos = 7761 f(2.00, 8.00, 10.00, 4.00, 24.00, 10.00) = -3768.00 sin mejora = 1
temperatura = 2.2 intentos = 7861 f( 2.00, 8.00, 10.00, 4.00,24.00, 10.00) = -3768.00 sin mejora = 2
temperatura = 1.7 intentos = 7961 f( 2.00, 9.00, 9.00, 4.00, 24.00, 9.00) =-3774.00 sin mejora = 0
temperatura = 1.4 intentos = 8061 f(2.00, 9.00, 9.00, 4.00, 24.00, 9.00) = -3774.00 sin mejora = 1
temperatura = 1.1 intentos = 8161 f( 2.00, 9.00, 9.00, 4.00,24.00, 9.00) = -3774.00 sin mejora = 2
temperatura = 0.9 intentos = 8261 f( 2.00, 9.00, 9.00, 4.00, 24.00, 9.00) =-3774.00 sin mejora = 3
temperatura = 0.7 intentos = 8361 f(2.00, 9.00, 9.00, 4.00, 24.00, 9.00) = -3774.00 sin mejora = 4
temperatura = 0.6 intentos = 8461 f( 2.00, 9.00, 9.00, 4.00,24.00, 9.00) = -3774.00 sin mejora = 5
temperatura = 0.5 intentos = 8561 f( 2.00, 9.00, 9.00, 4.00, 24.00, 9.00) =-3774.00 sin mejora = 6
temperatura = 0.4 intentos = 8661 f(2.00, 9.00, 8.00, 4.00, 23.00, 10.00) = -3791.00 sin mejora = 0
temperatura = 0.3 intentos = 8761 f( 2.00, 9.00, 8.00, 4.00,23.00, 10.00) = -3791.00 sin mejora = 1
temperatura = 0.2 intentos = 8861 f( 2.00, 9.00, 8.00, 4.00, 23.00, 10.00) =-3791.00 sin mejora = 2
temperatura = 0.2 intentos = 8961 f(2.00, 9.00, 8.00, 4.00, 23.00, 10.00) = -3791.00 sin mejora = 3
temperatura = 0.1 intentos = 9061 f( 2.00, 9.00, 8.00, 4.00,23.00, 10.00) = -3791.00 sin mejora = 4
temperatura = 0.1 intentos = 9161 f( 2.00, 9.00, 8.00, 4.00, 23.00, 10.00) =-3791.00 sin mejora = 5
temperatura = 0.1 intentos = 9261 f(2.00, 9.00, 8.00, 4.00, 23.00, 10.00) = -3791.00 sin mejora = 6
temperatura = 0.1 intentos = 9361 f( 2.00, 9.00, 8.00, 4.00,23.00, 10.00) = -3791.00 sin mejora = 7
temperatura = 0.1 intentos = 9461 f( 2.00, 9.00, 8.00, 4.00, 23.00, 10.00) =-3791.00 sin mejora = 8
temperatura = 0.0 intentos = 9561 f(2.00, 9.00, 8.00, 4.00, 23.00, 10.00) = -3791.00 sin mejora = 9
temperatura = 0.0 intentos = 9661 f( 2.00, 9.00, 8.00, 4.00,23.00, 10.00) = -3791.00 sin mejora = 10
Ultimo punto encontrado: f( 2.00, 9.00, 8.00, 4.00, 23.00,10.00)= -3791.00
Mejor punto encontrado: f( 2.00, 9.00, 8.00, 4.00,23.00, 10.00) = -3791.00
real 5229m59.562s
user 5223m13.754s
sys 2m28.525s
Apendice C
Resultados en la Maximizacion de
las transacciones procesadas por
hora para el caso 60 % ATU y 40 %
IDI, usando la metaheurıstica de
Recocido Simulado
*** Inicio del programa ***
punto inicial: f( 2.00, 8.00, 10.00, 4.00, 20.00, 3.00) =-3625.00
temp inicial = 5599904409695.3 intentos aceptados = 129
{’s’: 1, ’t’: 7, ’w’: 13, ’y’: 21, ’x’: 4, ’z’: 5}
temp =5599904409695.3 intentos = 162
f( 1.00, 7.00, 13.00, 4.00,21.00, 5.00) = -2369.00
temperatura = 5599904409695.3 intentos = 212 f( 2.00, 7.00,10.00, 3.00, 22.00, 10.00) = -3156.00 sin mejora = 0
temperatura = 4479923527756.2 intentos = 262 f( 1.00, 6.00,4.00, 4.00, 18.00, 6.00) = -2372.00 sin mejora = 1
temperatura = 3583938822205.0 intentos = 312 f( 1.00, 7.00, 2.00, 3.00,15.00, 1.00) = -2340.00 sin mejora = 2
temperatura =2867151057764.0 intentos = 362 f( 1.00, 8.00, 10.00, 2.00,18.00, 1.00) = -2026.00 sin mejora = 3
temperatura =2293720846211.2 intentos = 412 f( 1.00, 6.00, 6.00, 2.00,17.00, 4.00) = -2021.00 sin mejora = 4
temperatura =1834976676968.9 intentos = 462 f( 2.00, 7.00, 8.00, 3.00,18.00, 7.00) = -3160.00 sin mejora = 0
temperatura =1467981341575.2 intentos = 512 f( 2.00, 7.00, 5.00, 3.00,12.00, 7.00) = -3154.00 sin mejora = 1
temperatura =1174385073260.1 intentos = 562 f( 1.00, 7.00, 2.00, 2.00,16.00, 3.00) = -2033.00 sin mejora = 2
:
:
:
C Resultados en la Maximizacion de las transacciones procesadas por hora para el
caso 60 % ATU y 40 % IDI, usando la metaheurıstica de Recocido Simulado 80
temperatura = 246286400515.8 intentos = 912 f( 1.00, 9.00, 10.00, 4.00, 23.00, 3.00) = -2370.00 sin mejora = 1
temperatura = 197029120412.6 intentos = 962 f( 1.00, 9.00, 11.00, 3.00, 11.00, 3.00) = -2341.00 sin mejora = 2
temperatura = 157623296330.1 intentos = 1012 f( 2.00, 8.00, 12.00, 2.00, 1.00, 9.00) = -2039.00 sin mejora = 3
temperatura = 126098637064.1 intentos = 1062 f( 1.00, 7.00, 14.00, 2.00, 10.00, 5.00) = -2019.00 sin mejora = 4
temperatura = 100878909651.3 intentos = 1112 f( 2.00, 8.00, 11.00, 1.00, 12.00, 4.00) = -1031.00 sin mejora = 5
temperatura = 80703127721.0 intentos = 1162 f( 2.00, 8.00, 13.00, 1.00, 8.00, 8.00) = -1026.00 sin mejora = 6
temperatura = 64562502176.8 intentos = 1212 f( 1.00, 8.00, 6.00, 1.00, 10.00, 7.00) = -1026.00 sin mejora = 7
temperatura = 51650001741.4 intentos = 1262 f( 1.00, 8.00, 4.00, 4.00, 14.00, 5.00) = -2375.00 sin mejora = 0
temperatura = 41320001393.2 intentos = 1312 f( 1.00, 8.00, 5.00, 1.00, 23.00, 9.00) = -1029.00 sin mejora = 1
temperatura = 33056001114.5 intentos = 1362 f( 2.00, 8.00, 2.00, 2.00, 17.00, 3.00) = -2029.00 sin mejora = 0
:
:
:
temperatura = 2839488874.5 intentos = 1912 f( 2.00, 7.00, 9.00, 3.00, 4.00, 7.00) = -3136.00 sin mejora = 1
temperatura = 2271591099.6 intentos = 1962 f( 1.00, 8.00, 12.00, 4.00, 11.00, 4.00) = -2367.00 sin mejora = 2
temperatura = 1817272879.7 intentos = 2012 f( 1.00, 9.00, 3.00, 1.00, 14.00, 10.00) = -1024.00 sin mejora = 3
temperatura = 1453818303.7 intentos = 2062 f( 2.00, 7.00, 9.00, 1.00, 12.00, 7.00) = -1023.00 sin mejora = 4
temperatura = 1163054643.0 intentos = 2112 f( 1.00, 9.00, 7.00, 2.00, 22.00, 4.00) = -2038.00 sin mejora = 0
temperatura = 930443714.4 intentos = 2162 f( 1.00, 8.00, 9.00, 2.00, 16.00, 3.00) = -2043.00 sin mejora = 0
temperatura = 744354971.5 intentos = 2212 f( 2.00, 7.00, 14.00, 1.00, 19.00, 5.00) = -1024.00 sin mejora = 1
temperatura = 595483977.2 intentos = 2262 f( 1.00, 7.00, 12.00, 2.00, 18.00, 4.00) = -2023.00 sin mejora = 0
temperatura = 476387181.8 intentos = 2312 f( 1.00, 8.00, 11.00, 1.00, 22.00, 9.00) = -1024.00 sin mejora = 1
temperatura = 381109745.4 intentos = 2362 f( 2.00, 9.00, 3.00, 2.00, 17.00, 5.00) = -2037.00 sin mejora = 0
temperatura = 304887796.3 intentos = 2412 f( 1.00, 6.00, 6.00, 4.00, 17.00, 2.00) = -2371.00 sin mejora = 0
:
:
:
temperatura = 10727285.7 intentos = 3162 f( 1.00, 6.00, 11.00, 4.00, 10.00, 8.00) = -2366.00 sin mejora = 0
temperatura = 8581828.5 intentos = 3212 f( 2.00, 7.00, 3.00, 2.00, 2.00, 1.00) = -2039.00 sin mejora = 1
temperatura = 6865462.8 intentos = 3262 f( 2.00, 8.00, 5.00, 3.00, 1.00, 6.00) = -3166.00 sin mejora = 0
temperatura = 5492370.3 intentos = 3312 f( 1.00, 7.00, 11.00, 1.00, 12.00, 10.00) = -1026.00 sin mejora = 1
temperatura = 4393896.2 intentos = 3362 f( 2.00, 6.00, 11.00, 2.00, 3.00, 8.00) = -2017.00 sin mejora = 0
temperatura = 3515117.0 intentos = 3412 f( 1.00, 6.00, 1.00, 2.00, 2.00, 1.00) = -2004.00 sin mejora = 1
temperatura = 2812093.6 intentos = 3462 f( 1.00, 8.00, 4.00, 1.00, 5.00, 2.00) = -1027.00 sin mejora = 2
temperatura = 2249674.9 intentos = 3512 f( 2.00, 8.00, 8.00, 1.00, 1.00, 7.00) = -1027.00 sin mejora = 3
temperatura = 1799739.9 intentos = 3562 f( 1.00, 8.00, 9.00, 1.00, 4.00, 6.00) = -1022.00 sin mejora = 4
temperatura = 1439791.9 intentos = 3612 f( 2.00, 6.00, 6.00, 4.00, 6.00, 3.00) = -3569.00 sin mejora = 0
temperatura = 1151833.5 intentos = 3662 f( 1.00, 7.00, 14.00, 3.00, 2.00, 9.00) = -2347.00 sin mejora = 1
temperatura = 921466.8 intentos = 3712 f( 1.00, 6.00, 14.00, 4.00, 5.00, 6.00) = -2374.00 sin mejora = 0
temperatura = 737173.5 intentos = 3762 f( 1.00, 9.00, 13.00, 1.00, 3.00, 9.00) = -1024.00 sin mejora = 1
temperatura = 589738.8 intentos = 3812 f( 1.00, 7.00, 13.00, 4.00, 2.00, 5.00) = -2369.00 sin mejora = 0
temperatura = 471791.0 intentos = 3862 f( 2.00, 9.00, 13.00, 2.00, 7.00, 3.00) = -2040.00 sin mejora = 1
temperatura = 377432.8 intentos = 3912 f( 2.00, 7.00, 12.00, 2.00, 13.00, 2.00) = -2026.00 sin mejora = 2
temperatura = 301946.2 intentos = 3962 f( 1.00, 8.00, 11.00, 3.00, 20.00, 3.00) = -2345.00 sin mejora = 0
temperatura = 241557.0 intentos = 4012 f( 1.00, 9.00, 6.00, 1.00, 21.00, 3.00) = -1021.00 sin mejora = 1
temperatura = 193245.6 intentos = 4062 f( 2.00, 8.00, 11.00, 1.00, 20.00, 8.00) = -1026.00 sin mejora = 0
:
C Resultados en la Maximizacion de las transacciones procesadas por hora para el
caso 60 % ATU y 40 % IDI, usando la metaheurıstica de Recocido Simulado 81
:
:
temperatura = 8.4 intentos = 7429 f( 2.00, 9.00, 8.00, 4.00, 21.00, 8.00) = -3651.00 sin mejora = 1
temperatura = 6.7 intentos = 7529 f( 2.00, 9.00, 10.00, 4.00, 19.00, 10.00) = -3633.00 sin mejora = 2
temperatura = 5.4 intentos = 7629 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 0
temperatura = 4.3 intentos = 7729 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 1
temperatura = 3.4 intentos = 7829 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 2
temperatura = 2.8 intentos = 7929 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 3
temperatura = 2.0 intentos = 8029 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 4
temperatura = 1.2 intentos = 8129 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 5
temperatura = 0.8 intentos = 8429 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 6
temperatura = 0.3 intentos = 8529 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 7
temperatura = 0.1 intentos = 8629 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 8
temperatura = 0.1 intentos = 8729 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 9
temperatura = 0.0 intentos = 8929 f( 2.00, 9.00, 11.00, 4.00, 17.00, 10.00) = -3667.00 sin mejora = 10
Ultimo punto encontrado: f( 2.00, 9.00, 11.00, 4.00, 17.00,10.00) = -3667.00
Mejor punto encontrado: f( 2.00, 9.00, 11.00,4.00, 17.00, 10.00) = -3667.00
real 11870m48.322s
user 11868m18.457s
sys 2m52.421s