1

Una publicación de la Facultad de Ciencias Físicas y Matemáticas

α
Cuerpo Directivo

Decano Sergio Quezada González

Σ
β
Secretaria Facultad

Directores de Escuela
Lorena Paredes Buzeta

δφ
λ
Ingeniería Civil en Computación e Informática Daniel Zamora Marín
Ingeniería Civil en Obras Civiles Iván Fernández-Dávila Gonzáles
Ingeniería en Construcción Marcos Espinoza Gamboa

ψθ
Ingeniería de Ejecución en Computación Alexis Gotschlich Neubauer

Ingeniería al día

Director

Editor
Sergio Quezada González

Cristián Martínez Moreno ϕ

Comité Editorial

Homero Latorre Astudillo

α
Luis Moraga Jaramillo
Iván Fernández-Dávila Gonzáles
José Bellido de Luna del Rosario
Mauricio Solar Fuentes
Σ
β
Mauricio Herrera Marín
Patricio Núñez Rojas
δφ
λ
Colaboradores

Sergio Hojman Guiñerman, U. de Chile

ψθ
Ernesto Cruz Zavala, U. Católica de Chile
Hernán Zabaleta García, U. Católica de Chile
Jorge Ávila Rodríguez, U. Autónoma de México
Esperanza Maldonado Rondón, U. Industrial de Santander-Colombia

ϕ
α
Diseño Gráfico: Editorial San Marino; Diseño Portada: Editorial San Marino; Dirección Postal: Facultad de
Ciencias Físicas y Matemáticas, Santa Isabel 1186, Santiago – Chile, Teléfono: 5826807, Fax: 5826909,
E-mail: editor@ucentral.cl Código Internacional: ISSN 0718-073X. Publicación Semestral. Agradecemos
Intercambio (Exchange Requested). Tiraje: 700 ejemplares. Impreso en: Editorial San Marino.

Σ
θ β
 2

αΣ
β
δφ ξ Indice
Index

λ
ψθ
Editorial 3
Editorial

Breve Introducción a la Física de Plasmas 7

ϕ
Brief Introduction to the Plasma Physics

Conectividad a Internet de Sistemas Embebidos de Bajo Costo 17

Connectivity to Internet to Low Cost Embedded Systems

α Estado del Arte Ataques de Negación de Servicio y de Negación de Servicio Distribuido

State the Art Denial of Service Attacks and of the Distributed Denial of Service Attacks
31

Σ
β Los Roles y las Metodologías en la Ingeniería de Software Orientada a Agentes
Roles and Methodologies in Agent-Oriented Software Engineering
51

δφ
Sistema de Visión Activa Basado en Lógica Difusa para Focalización 59
Active Vision System Using Fuzzy Logic Capable Of Focalization

Generación Automática de Código Java para Clases Definidas a partir de Ontologías OWL 69

λ Automatic Generation of Java Code from Written OWL Ontologies

A Solution Model for Traveler Recommendation Systems Based on Collaborative Case-Based

ψθ Reasoning and Bayesian Networks

Un Modelo de Soluciones para un Sistema de Recomendación de Viajes que utiliza Raciocinio
Basado en Casos y Redes Bayesianas
75

ϕ
Multi-agent System Design Based on Security Policies 83
Diseño de un Sistema Multiagente Basado en Políticas de Seguridad

Implementación de un Prototipo de Agente Educativo 95

α Implementation of a Prototypical Teaching Agent

Aplicación de OWL para Desarrollar un Demostrador de Oferta Turística Basado en Agentes Inteligentes 113

β
An Application of OWL for Developing a Demo of Tourist Offering Based on Intelligent Agents
Σ
θ
 3

αΣ
β
Editorial
Publishing Sergio Quezada González
Decano δφ
λ
Facultad de Ciencias Físicas y Matemáticas
Universidad Central de Chile

ψθ
En esta quinta edición he querido destacar la importancia en la decisión de ingresar a una carrera
profesional, la que a mi parecer constituye un proyecto de vida, en la cual se debe plasmar una mirada
como individuo y como profesional, ya que es en ese instante de la vida en que la persona es partícipe
de una innovación de la sociedad, en la que además debe transformarse en un ente generador de
cambios en todas las actividades en donde se desempeñe.

Pero la Universidad Central, dentro de su proyecto de desarrollo, también debe adaptarse a los cambios
de la sociedad. Un par de preguntas en este sentido son: ¿cómo y quiénes lo hacen? Y también: ¿cuál ϕ
α
es la responsabilidad que tenemos quienes trabajamos y dirigimos proyectos educativos?

Algunas instituciones siguen la opción de la publicidad para la captación de alumnos y darse a conocer.
La Universidad Central, en cambio, ha seguido el camino de la excelencia, ¿por qué esta afirmación?,

β
analicemos algunos hitos que ha cumplido nuestra Universidad Central en estos 23 años:

De ser una universidad privada tradicional, modificó sus estatutos, los que fueron aprobados por el
Σ
Ministerio de Educación el 11 de octubre 1982 y reconocidos por el Estado e inscrita según consta en el

δφ
Folio C. N° 4 del Registro de Universidades del Ministerio de Educación transformándose en una
universidad privada sin fines de lucro. ¿Qué significa ello?, significa que es la única institución privada
en Chile en la que sus utilidades se reinvierten generando una infraestructura de primer nivel, constitu-
yéndose en la universidad privada con mayor patrimonio.

Pero una universidad de excelencia no se valora solo por su infraestructura, y es por ello que nuestra
universidad, en estos últimos años, ha privilegiado los diferentes estamentos en su quehacer
académico-estudiantil, destacando grados de excelencia académica, incursionando seriamente en el λ
campo de la investigación, para lo cual anualmente destina importantes recursos; es por ello que quiero
contarles algunos avances que hemos logrado:

Es la única universidad privada en la que sus autoridades son elegidas por sus propios pares. ¿Qué ha
ψθ
significado ello?, ha significado que nuestra universidad se ha profesionalizado en todos sus ámbitos,
desde la calidad en la atención a sus alumnos, mejoramiento de planes y programas de estudio, que
son requisito de calidad de la docencia e investigación, y en la asociación con otras instituciones de
educación superior nacionales y extranjeras, con instituciones privadas, de gobierno y de otros rubros.
ϕ
Producto de lo señalado, con gran satisfacción podemos reseñar que en la sesión oficial del martes 6 de
diciembre del 2005, la Comisión Nacional de Acreditación de Pregrado CNAP resolvió la acreditación
institucional de la Universidad Central por tres años.
αΣ
θ β
 4

α Quisiera destacar la importancia de esta resolución, en el sentido que las instituciones, ya sean productivas o

Σ
β educacionales, o de otra índole, deben demostrar ante la sociedad índices de calidad, lo que para las
universidades chilenas es ser acreditadas por la CNAP. Esta acreditación no solo es beneficiosa para la
institución UCEN, sino que para nuestros alumnos que están o ingresarán al campo laboral, donde su grado de
aceptación estará fuertemente diferenciado por el hecho de haber egresado de una universidad acreditada.

δφ ξ Para quienes ingresan a nuestras aulas, también existirá un trato igualitario en comparación con el
resto de las universidades tradicionales, lo que se traducirá en la postulación a becas y préstamos
universitarios para solventar su carrera cuando no dispongan de los recursos necesarios.

λ Por nuestra parte, la Universidad Central podrá participar en los fondos de circuitos concursables, que
evidentemente serán de gran ayuda a nuestro proyecto institucional.

ψθ Concordante con el plan estratégico de la Universidad, la Facultad de Ciencias Físicas y Matemáticas

también ha desarrollado, entre otras actividades:

Un proceso de autoevaluación de las carreras de Ingeniería Civil en Computación e Informática e

ϕ Ingeniería Civil en Obras Civiles para postular a la acreditación; a la fecha, las escuelas de ICCI y
OOCC se encuentran en espera de la resolución de acreditación, se presentaron los antecedentes y la
documentación requerida, hemos recibido un primer informe aprobatorio de la CNAP, lo hemos respon-

α
dido y en fecha próxima esperamos el resultado final del proceso.

Nuestra Facultad ha generado esta revista que se edita dos veces al año, con el nombre de “Ingeniería
al día” y que muestra el quehacer de nuestros académicos de la Facultad.

Σ
β Tenemos funcionando con mucho éxito un programa de Doctorado en Ingeniería en Computación, en conjunto
con la Universidad Politécnica de Madrid, donde un alto porcentaje de los alumnos del programa son académi-
cos de la Facultad, ello nos permitirá mejorar la calidad de la docencia y desarrollar la investigación.

δφ Hemos gestionado y también ha sido aprobado por la Universidad un convenio con la City University of
New York, el que se ha traducido en intercambio de estudiantes y principalmente en nuestro proyecto
estrella “Comunidades de Aprendizaje”, donde participan aproximadamente cincuenta profesores de la

λ
Universidad. El objetivo principal de este proyecto es crear un nuevo estilo de aprendizaje que relaciona
y contextualiza contenidos, permitiendo prácticas efectivas entre estudiantes y profesores, a través de
estrategias fundadas en la relación emocional, corporal y lingüística. Esta nueva forma de aprender y

ψθ
relacionarse es un apoyo fundamental al proyecto UCEN de Rediseño Curricular, cuyos beneficiados
directos son nuestros alumnos, quienes hoy están aprendiendo bajo este nuevo concepto de competen-
cias y empleabilidad. Así aseguramos un profesional con sólidos conocimientos teórico-prácticos, con
capacidad de aprender, de liderazgo y de relacionarse con su medio.

ϕ Este año ofrecemos, además, un Magíster en Seguridad Informática y Protección de la Información con
profesores nacionales y extranjeros, lo cual constituye un esfuerzo importante para desarrollar la edu-
cación continua, única forma para mantenerse como un profesional actualizado.

α Sergio Quezada González

Decano
Facultad de Ciencias Físicas y Matemáticas

β
Universidad Central de Chile
Σ
θ
 L A B O R AT O R I O D E E N S AY O D E M AT E R I A L E S
U N I V E R S I D A D C E N T R A L D E C H I L E LT D A .

Desde 1988 se realizan estudios y ensayos en te- – Área de mecánica de suelos con especialidad en:
rreno y laboratorio, relacionados con proyectos de pavimentos y estructuras.
construcción, inspección de obras y verificación
del cumplimiento de normas. – Área de hormigón con especialidad en: obras de
edificación y pavimentos.
La infraestructura del LEMUC LTDA. permite reali-
zar y/o implementar estudios de control y diseño PROYECTOS RELEVANTES
de hormigones y morteros, ensayos destructivos y
no destructivos, estudio integral de áridos y con- Unidad de Apoyo a la docencia práctica de las Es-
glomerados, laboratorios para pruebas en terreno, cuelas de Ingeniería Civil en Obras Civiles e Inge-
inspecciones de obra, labores de muestreo, perita- niería en Construcción de la Facultad de Ciencias
jes y certificación de calidad. Físicas y Matemáticas de la Universidad Central de
Chile.
SERVICIOS DE CERTIFICACIÓN DE 3º PARTE
OFRECIDOS Control de calidad de hormigones premezclados
para las empresas Sociedad de Hormigones Pre-
La Resolución N° 420 del Ministerio de la Vivienda mix y Tecnomix.
y Urbanismo, de fecha 28 de noviembre de 1990 y
publicada en el Diario Oficial N° 33842 del 13 de DIRECTORIO
diciembre de 1990, declara al LEMUC como Insti-
tución Oficial de Control Técnico de Calidad de los Presidente Sr. Hernán Zabaleta García
Materiales y Elementos Industriales para la Cons- Vicepresidente Sr. Juan Egaña Ramos
trucción. En la actualidad, dicha habilitación com- Director Sr. Helios Corvalán Pérez
prende las siguientes áreas y especializaciones:

Lemuc@ucentral.cl • Santa Isabel 1160 – Santiago Centro, Chile

Fonos: (56-2) 5826826 ó 5826924 • Fax: (56-2) 5826912
Gerente General: Sr. Patricio Núñez R. • Gerente de Operaciones: Srta. Margarita Rebolledo B.
 7

αΣ
β
δφ
λ
ψθ
Breve Introducción a la Física de Plasmas
ϕ
Brief Introduction to the Plasma Physics
α
Denisse Pastén Σ
β
δφ
λ
ψθ
ϕ
α
β
1 Departamento de Física, Facultad de Ciencias, Universidad de Chile.

Σ
θ
 8

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β

ABSTRACT
In this article will present a brief introduction to the plasma physics and to the experimental studies in
Chile.
RESUMEN
En el presente artículo se realizará una breve introducción a la física de plasmas y su estudio experi-
mental y teórico, dando algunas nociones de lo que se hace en Chile.
INTRODUCCIÓN
El universo se encuentra constituido en un
99% por plasma, el denominado cuarto estado
de la materia. El nombre ‘plasma’ proviene del
griego πλασμα, que significa “gelatina” o “sus-
tancia moldeable”.
Es conocido que si un sólido se calienta lo sufi-
ciente, el movimiento termal de los átomos pro-
ducirá un quiebre en su estructura, lo que dará
origen a la formación de un líquido. Si este lí-
quido se calienta aún más, los átomos se vapo-
rizan produciéndose un gas. Cuando un gas se
calienta lo suficiente para que las colisiones en-
tre átomos sean capaces de arrancar electro-
nes de ellos, se está formando un plasma.
Es posible encontrar plasmas en los cuerpos
celestes, debido a las altas temperaturas que
en ellos existe, ya que de esta manera aumen-
ta la densidad de átomos ionizados en relación
a la densidad de átomos neutros en una molé-
cula. Para que exista un plasma es necesario
provocar una separación entre los electrones y
protones presentes en el núcleo. Un ejemplo
en una escala menor de temperatura de lo que
es un plasma, es el fuego y las luces de neón.
Quien comenzó con el estudio de los plasmas
fue el científico estadounidense Irving Lang-
muir, en 1920, aproximadamente. Él tenía la
necesidad de encontrar tubos de vacío que
fueran capaces de transportar corrientes, de
9
α
Σ
β
δφ
λ
ψθ
esta manera llegó a los gases ionizados, ya
que a través de ellos era posible realizar esta
operación (los plasmas son excelentes con-
ductores), entonces utilizó descargas de gas
ϕ
para llevar a cabo su cometido, dando origen
al estudio de la física de plasmas. En la actua-
lidad, es de gran importancia el desarrollo de
la fusión nuclear debido a la enorme energía
que sería posible obtener a partir de ella y so-
bre todo porque los residuos que se producen
no son radiactivos. α
β
DEFINICIÓN DE PLASMA
Σ
Básicamente, un plasma es un gas cuasi neu-
δφ
tral de partículas neutras y cargadas, en el cual
prevalece un comportamiento colectivo [3].
Se debe definir qué es la cuasi neutralidad y
qué es un comportamiento colectivo. Se enten-
derá por comportamiento colectivo a aquellos
movimientos que no dependen únicamente de λ
las condiciones locales, y como cuasi neutrali-
dad a que las densidades a orden cero de io-
nes y electrones son las mismas, es decir: ψθ
ϕ
n0i = n0e = n, (1)
donde n0i es la densidad de los iones, n0e es la
densidad de los electrones y n es la denomina-
da densidad de plasma. Además, se considera
que la densidad de carga de los iones es cons-
tante, es decir, que estos no se mueven en α
β
relación a los electrones, debido a la diferencia
Σ
θ
 10

α de masa existente entre ambas partículas (M/m (7)

Σ
β → ∞, con M masa de los iones y m masa de los
electrones). De lo anteior es posible deducir
que Reemplazando esta ecuación en (3):

δφ ξ Criterios para Identificar un Plasma

(8)

λ
debido a la cuasineutralidad,
Es necesario enunciar tres condiciones que
confirman que un gas ionizado es realmente un (9)

ψθ
plasma. Para llegar a ellas, se planteará la
ecuación de Poisson para una esfera cargada
que se introduce en este gas: El potencial en las cercanías a la esfera carga-
da es de menor orden que la energía térmica

ϕ
(2) de las partículas, por lo tanto existe una región
en la cual
Para una dimensión se tiene:

α (3)
y es posible expandir la exponencial en su se-
rie de Taylor, tomando solo el término lineal de

β
El número de partículas por unidad de volumen la expansión, la ecuación (9) muestra la si-
Σ se define como: guiente forma:

(4) (10)

δφ donde f(r) es la función de distribución y viene

dada por:
finalmente

λ
(11)
(5)

ψθ
siendo kb la constante de Boltzmann, q la car- Resolviendo esta ecuación diferencial:
ga de la partícula, m la masa de la partícula, T
la temperatura de la misma y ø(r) el potencial (12)
externo que actúa sobre ella.

ϕ Integrando sobre la velocidad n se obtiene la

densidad n:
donde D es la longitud de Debye, la cual define
el tamaño del “blindaje” que las partículas for-
man alrededor de la esfera cargada que se in-

α (6)

luego, si la partícula es un electrón se tiene la

siguiente densidad:
trodujo en el gas, ya que esta produce una po-
larización en él. Esta longitud se define por la
siguiente ecuación:

Σ
θ β

Entonces, la primera condición con la cual
(13)
debe cumplir un gas ionizado para que sea un
plasma es la siguiente: si un sistema de partí-
culas tiene una dimensión L, entonces se debe
cumplir que λD<<L, ya que de esta manera las
cargas o potenciales que sean introducidos al
plasma serán “blindados” por él, formando la
llamada esfera de Debye.
Ahora bien, el número de partículas que se en-
cuentra dentro de una esfera de Debye está
dado por la densidad de la esfera y su volu-
men:
(14)
Para que existan comportamientos colectivos
es necesario que el número de partículas pre-
sentes en la esfera de Debye sea mucho ma-
yor a uno, de lo contrario, estadísticamente no
será correcto hablar de un blindaje por parte
del plasma, de aquí se deduce la segunda con-
dición:
(15)
La tercera condición que debe cumplir un gas
ionizado tiene relación con las colisiones entre
electrones y partículas neutras (hay que recor-
dar que se considera que los iones no están en
movimiento). Los plasmas poseen una frecuen-
cia característica, denominada frecuencia de
plasma, para que el gas no sea neutro es ne-
cesario que esta frecuencia de plasma sea ma-
yor que la frecuencia de colisión entre electro-
nes y partículas neutras, es decir:
(16)
11
Cuando un gas ionizado cumple con estas tres
α
condiciones es posible llamarlo plasma.
En la Figura 1 es posible encontrar una clasifi-
cación de plasmas que se encuentran en la
Σ
β
naturaleza o se crean en los laboratorios, en
relación a su densidad y temperatura. [4]
δφ
λ
PLASMA EXPERIMENTAL
Existen dos principales formas de crear plasma
ψθ
en un laboratorio: por descargas de gas y me-
diante el confinamiento magnético, a partir de
este último es posible obtener una enorme
energía producida por la liberación de electro-
nes.
Para llevar a cabo un estudio experimental so-
bre la física de un plasma es necesario confi- ϕ
narlo a una región determinada, con el fin de
poder observar su comportamiento. Una vez
que ha sido confinado (utilizando indistinta-
mente los métodos ya mencionados), el plas-
α
ma adquiere una geometría cilíndrica, a la cual
se denomina columna de plasma, el fin que se
persigue al formarla es el de obtener energía y
es en este punto donde las complicaciones
Σ
β
aparecen, ya que es complejo mantener la co-
lumna durante un tiempo prolongado debido a
que se hacen presentes en ella una serie de δφ
λ
inestabilidades, como la compresión en secto-
res de la columna (salchicha) o cortes en ella
(quiebre), por ejemplo. Para mantener el equili-
ψθ
brio, debería cumplirse la ecuación de balance
de presión:
(17)
ϕ
sin embargo, lo que ocurre es que ∇P puede ser
mayor que J x B, con lo que el plasma se expan-
de, o puede ser menor y entonces el plasma se
contrae.
Pensando en estas características es que se
han diseñado una serie de configuraciones,
αΣ
θ β
 12

α para que el plasma que se forma sea cada externas, lo cual implica que su construc-

Σ
β vez más estable, de mayor duración y man-
tenga alta la producción de energía.

Existen diferentes dispositivos para lograr el

ción debe ser muy precisa, ya que cual-
quier error (debido a que todos los cam-
pos magnéticos son producidos de
manera externa) puede provocar un mal

δφ ξ confinamiento de un plasma creado en un la-

boratorio, dentro de ellos los más utilizados
son los siguientes:
confinamiento de la columna de plasma.
Su principal ventaja es que al trabajar
con bobinas exteriores es posible mante-

λ
ner un funcionamiento continuo, es decir,
1. Espejos Magnéticos: tipo de confinamien- es conveniente para aplicaciones comer-
to abierto, en el cual las partículas carga- ciales.

ψθ
das siguen las líneas de campo, es decir,
son confinadas a un tubo recto mediante la
aplicación de un campo externo axial que
es más intenso en los bordes que en el
4. Z-Pinch: también se basa en la compre-
sión de un gas debido a la presencia de un
campo magnético, el cual es generado por
el paso de una corriente a través de un

ϕ
centro.
2. Tokamak: su geometría es la de un toroide
grueso que contiene en su interior una co-
lumna de plasma. Fue diseñada por los
arreglo de alambres delgados que se en-
cuentran rodeando al gas. Como la corrien-
te se mueve en el eje Z y la columna de
plasma se forma en la misma dirección, es

α científicos de la Unión Soviética, a fines de

los años 60. Posee simetría axial y la co-
rriente que pasa por él se encuentra difun-
que recibe el nombre de Z-Pinch (a la com-
presión producida por el campo se le deno-
mina pinch).

β
dida a lo largo de toda la columna de plas-
Σ ma. La pregunta era cómo generar una
corriente toroidal; la respuesta fue: la ley
de Inducción de Faraday. Para llevarla a
cabo se necesitan dos bobinas: el primario,
5. Confinamiento por Láser: a este tipo de
confinamiento se le denomina inercial, en
él se comprime una pequeña cápsula de
combustible mediante un láser a densida-
des extremas. El proceso de fusión co-

δφ por donde se aplica una corriente externa,

y el secundario, que es sobre el cual se
induce la corriente, además de un núcleo
mienza en el centro y se extiende hacia los
extremos, que es donde el plasma está
más frío. Lamentablemente, el tiempo de

λ
entre ambas. En el caso del tokamak, el confinamiento es solo de unos milisegun-
primario va enrollado en el interior del mis- dos.
mo, el núcleo lo forma el aire que está en

ψθ
el agujero del toroide y el plasma es utiliza-
do como secundario. Es esta corriente to-
roidal la que mantiene confinado al plasma
al generar un campo magnético desde los
Estos dispositivos producen emisión de
rayos-X.
No existe aún un reactor de fusión que sea

ϕ
polos (poloidal), a su vez existe un campo
magnético toroidal que da estabilidad. Ade-
más, la combinación de ambos campos
evitan inestabilidades del tipo salchicha y
capaz de generar mayor energía de la que ne-
cesita para generar las reacciones, es este el
factor más importante del por qué no es renta-
ble en este momento producir energía a partir

α de quiebre.
3. Stellarator: es un dispositivo en forma to-
roidal, pero a diferencia del tokamak, el
campo poloidal es generado por bobinas
de un dispositivo de este tipo.

En la Tabla 1 se presentan algunos de los dis-

positivos que se encuentran en el mundo.
Σ
θ β

Tabla 1. Dispositivos de generación de
plasmas en el mundo
Plasma Experimental en Chile
En nuestro país existen dos laboratorios de
plasma: en la Pontificia Universidad Católica
de Chile y en la Comisión Chilena de Energía
Nuclear (CCHEN).
En el primero, se desarrollan estudios sobre
descargas capilares en cavidades pulsadas y
descargas capilares de alta corriente (realiza-
das en un Z-Pinch). Trabajan también en un
dispositivo X-Pinch, su nombre se debe a que
muestra una X al realizar una interferometría
en el momento en que se produce la emisión
de rayos-X. En este momento poseen un nuevo
generador de potencia pulsada, al que denomi-
nan LLampüdken (mariposa en mapudungun),
el cual consiste en dos generados Marx [5] que
son manejados por transmisión de líneas de
agua. Este laboratorio está principalmente fo-
calizado al estudio del comportamiento del
plasma en estos dispositivos, sin que estos
13
tengan de forma necesaria como finalidad la
α
implementación en industrias, medicina o en
otras áreas de interés. Este grupo de trabajo
está compuesto por profesores y alumnos de
pregrado, doctorado y postdoctorado. Han rea-
Σ
β
lizado una serie de tesis (en su gran mayoría
de Licenciatura), las que se han enfocado a la
holografía, estudios del comportamiento de los δφ
λ
plasmas en los diferentes dispositivos con los
que cuentan bajo distintas condiciones, diseño
de láser para mediciones, entre muchas otras.
En la Comisión Chilena de Energía Nuclear el
grupo de plasma está conformado por cinco fí-
sicos experimentales, más un físico teórico que
colabora como investigador asociado, y un es-
ψθ
tudiante en doctorado. Ellos se encuentran tra-
bajando sobre la física de plasmas en dispositi-
vos pequeños. En la comisión existen los ϕ
siguientes dispositivos para el estudio de la fí-
sica de plasmas:
1. Speed4: generador de potencia pulsada [6],
α
genera una energía de 3 kJ.
2. Speed2: generador de potencia pulsada, es
el más grande en el hemisferio Sur y genera
una energía de 187 kJ.
Σ
β
3. PF-400J: plasma foco. Produce una energía
de 400 J.
4. PF-50J: plasma foco, con una producción δφ
λ
de 50 J. Es este el plasma foco más peque-
ño en el planeta.
ψθ
La motivación de los estudios en la CCHEN es
la investigación del comportamiento de plas-
mas densos a altas energías (con los genera-
dores pulsados) y la aplicación de la emisión
ϕ
de rayos-X y neutrones que se puede obtener
de los pequeños plasma focos, ya que por su
tamaño son trasladables de un lugar a otro sin
mayores complicaciones, con lo cual sería po-
sible utilizarlos en medicina, para la toma de
radiografías, por ejemplo. Las preocupaciones
del grupo son principalmente dos: la de tener
una mayor comprensión del comportamiento de
αΣ
θ β
 14
α Facultad de Ciencias de la Universidad de Chi-
Σ
β le. Actualmente hay dos doctores que trabajan
δφ ξ
λ
ψθ
ϕ
Figura 1. Parámetros para casificar a los plasmas en la
α
naturaleza y los laboratorios.
los plasmas en fusión termonuclear con el fin
β
de llegar a obtener una valiosa fuente de ener-
Σ gía y la de llegar a realizar aplicaciones prácti-
cas de la fusión termonuclear en problemas
que no requieran que la energía que el sistema
δφ
entrega sea mayor a la invertida en él. En este
aspecto es importante destacar que al ser esta
una de las mayores motivaciones de sus traba-
jos e investigaciones, se han dedicado al dise-
λ ño de dispositivos que puedan realizar un apor-
te a diversas áreas en las que es de utilidad la
energía que de ellos se obtiene (tales como
ψθ medicina, minería, agricultura, entre otras).
Gracias al activo trabajo que este grupo reali-
za, han participado de una serie de proyectos
(Postdoctorales, Doctorales, FONDECYT, etc.).
ϕ
Además de haber recibido el galardón “Cátedra
Presidencial en Ciencias”.
PLASMA TEÓRICO EN CHILE
α Sobre el estudio teórico de esta importante
área de la física es necesario destacar que
β
existe solo un lugar en el que se realiza: en la
Σ
θ
en ella y a fines de este año se integrará uno
más. Sus estudios están focalizados a la astro-
física, la física de plasmas espaciales y el vien-
to solar (Dr. Alejandro Valdivia) y a los efectos
no lineales que ondas de gran amplitud provo-
can sobre ondas más pequeñas y la conse-
cuencia que esto produce en la estabilidad del
plasma (Dr. Luis Gombero).
CONCLUSIONES
Aunque aún no existen reactores capaces de
entregar mayor energía de la que ellos necesi-
tan para realizar una reacción, la energía nu-
clear de fusión se perfila como una excelente
alternativa energética, debido a su mayor se-
guridad (no hay peligro de explosiones, ya que
si el sistema se desestabiliza el plasma se en-
fría y se detiene la reacción) y a la menor pro-
ducción de residuos, los que son gases no
radioactivos.
Es un tema abierto la imitación del comporta-
miento de los plasmas espaciales en los labo-
ratorios que existen en el planeta.
En nuestro país, se avanza cada vez más so-
bre la aplicación de la energía obtenida en una
serie de áreas que ya fueron mencionadas; en
este aspecto han sido de real importancia los
conocimientos que se han obtenido en estos
últimos diez años de trabajo experimental. Ade-
más del gran aporte que realizan los plasmis-
tas teóricos de nuestro país a nivel mundial.
[1] Apuntes del curso Introducción al Plasma,
dictado por el Dr. Luis Gombero, primer se-
mestre 2004, Facultad de Ciencias, Univer-
sidad de Chile.
[2] Apuntes de un Seminario dictado en el cur-
so Fenomenología por el Dr. Leopoldo
Soto, primer semestre 2004, Facultad de
Ciencias, Universidad de Chile.
 15

[3] Francis F. Chen, Plasma Physics and Con- [5] Un condensador Marx es un banco de con-
α
tolled Fusion, Segunda Edición, Plenium
Press, New York (1985).
[4] Robert J. Goldston, Paul H. Rutherford, In-
troduction to Plasma Physics, publicado
densadores que se carga en paralelo y se
descarga en serie.
[6] En el Speed4 se utiliza como dieléctrico al
agua.
Σ
β
por Institute of Physics Publishing Bristol
and Philadelphia, Philadelphia, 1995.
δφ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 16

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 17

αΣ
β
δφ
λ
ψθ
Conectividad a Internet de Sistemas
ϕ
Embebidos de Bajo Costo α
Connectivity to Internet to Low Cost Embedded Systems

Rodrigo Alejandro Arriagada Núñez

Σ
β
δφ
λ
ψθ
ϕ
α
β
1 roarriagada@vtr.net; Doctorando UPM – UCENTRAL, Santiago, Chile. Junio 2005

Σ
θ
 18

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 19

ABSTRACT
α
Low Cost Embedded Systems are called appliances or electronics devices that use microcontrollers as
computing core, specially 8 and 16 bits. The modern age force at the moment to increase the capacities
of communications, bringing at applications that require access to Internet to allow to be in any place
Σ
β
and moment with the electronics devices, of way to control them and to require state of average
operation using multiplatform to unfold the information, such as a simple Browser. This article introduce
Internet connectivity on devices using 8 and 16 bit microcontrollers, and a real Internet connectivity δφ
λ
application introduced by the author to solve vehicle counting on Santiago de Chile, using the populous
ISP networks of Santiago de Chile. This application still on use today.

ψθ
RESUMEN

Como sistemas embebidos de bajo costo se conocen a las aplicaciones o dispositivos electrónicos que
usan como corazón de cómputo microcontroladores, particularmente de 8 y 16-bits. Los tiempos moder-
nos obligan a aumentar las capacidades de comunicaciones, llegando actualmente a aplicaciones que
requieren acceso a Internet para permitir estar conectado en cualquier lugar y momento con los dispo-
sitivos electrónicos, de manera de controlarlos y requerir estado de operación usando medios multipla-
taforma para desplegar la información, tales como un simple Browser. El presente artículo introduce el ϕ
mecanismo de conectividad a Internet de dispositivos basados en microcontroladores de 8 y 16 bits y
una aplicación real de conectividad a Internet presentada por el autor como una solución de conteo
vehicular en Santiago de Chile aprovechando las redes de ISP abundantes en esta ciudad. Aplicación
que hasta el día de hoy sigue operativa.
αΣ
β
δφ
INTRODUCCIÓN mitiría que la aplicación determinara cuáles
son los periodos punta y podría operar fuera
¿Por qué la necesidad de conectar un sistema de ellos. La interconectividad de todos los ser-
embebido a Internet? ¿Es realmente necesario vicios podría permitir que una aplicación deter-
tener un refrigerador o una lavadora conectada
a Internet? O también qué beneficio nos puede
reportar colocar nuestras aplicaciones embebi-
minara los mejores momentos de uso de ener-
gía de manera de aprovechar esa información.
λ
das online.

Estas interrogantes se pueden responder anali-

zando los beneficios que reportarían si estuvié-
ramos interconectados a Internet. Supongamos
que si los servicios básicos de electricidad,
agua, etc., tuvieran costos variables durante el
día, entonces la interconectividad de estos
electrodomésticos usando un sistema embebi-
do de bajo costo, de manera que el hecho de
conectarse a Internet no significara un real in-
cremento en el costo final de la aplicación, per-
El punto es el uso de la información. Si una
aplicación puede disponer de ella puede opti-
mizar los recursos notablemente, y también a
la inversa, desde el lado del humano, se puede
ψθ
ϕ
tener una interfaz hombre-máquina que nos
permita operar un dispositivo remotamente, tan
solo operando un Browser de manera de con-
trolar el sistema embebido o bien reportar da-
tos sobre él, p. ej., podríamos encender el Ja-
cuzzi antes de llegar a casa y controlar que la
temperatura fuese la óptima, o bien obtener el α
β
estado de sensores de seguridad de una casa
Σ
θ
 20

α y que esta enviara un email a nuestro teléfono ejemplo, módems inalámbricos y agregando

Σ
β celular par informarnos de una falla o intrusión
no permitida.

APLICACIONES CON CONECTIVIDAD A

sistemas embebidos que monitoreen variables
usando sistemas familiares al usuario (email y
Browsers), tales como: velocidad, consumo de
combustible, presión de neumáticos y peso de

δφ ξ INTERNET

Existen muchas aplicaciones embebidas con

carga se puede mejorar tanto la logística como
seguridad de los camiones y carga.

λ
un alto potencial de conectividad a Internet. Al- También una excelente aplicación que ya están
gunas quizás no lo necesiten, pero el hecho de viendo con buenos ojos las compañías de servi-
usar una interfaz común y familiar para un cios es el uso de Internet por medio de canales

ψθ
usuario final hacen más atractiva su utilización
y control, p. ej., un Browser o un cliente email.
Algunas potenciales aplicaciones
inalámbricos para captar datos de consumo de
medidores tanto de electricidad, agua, gas, etc.,
para evitar tener que enviar periódicamente a un
individuo a medir dichos servicios, como también

ϕ
permitir que el mismo medidor reciba órdenes de
• Hogar bloqueo ante el no pago de los servicios.
– Sistemas de seguridad.
– Electrodomésticos. Alto potencial de crecimiento

α – Medidores de servicios (electricidad,

agua, gas, etc.) Así como cada vez hay más computadores por
hogar, el número de aplicaciones interconecta-

β
• Científico das a Internet de sistemas embebidos crece
Σ – Captura de datos meteorológicos.
– Obtención de datos sísmicos en zonas
más rápido, por ejemplo, si un PC tiene impre-
sora, scanner, mouse, teclado, etc. Cada uno
remotas. de estos dispositivos tiene al menos un siste-
– Captura de datos en general. ma embebido de bajo costo. Habitualmente mi-

δφ • Médico
– Dispositivos de monitores de pacientes.
crocontroladores de 8 bits y eventualmente de
16 bits en caso de más alto rendimiento. Estos
eventualmente podrían estar online si la indus-

λ
– Ayuda a ancianos y desvalidos. tria los ofreciera con esa potencialidad, y si
bien los usuarios la necesitaran.
• Automotriz y transporte

ψθ
– Logística de flotas. Servicios esperados
– Cálculo de rutas óptimas vía GPS e in-
formación de tráfico. A pesar que Internet ofrece muchísimos servi-
– Detección de vehículos robados. cios, dos juegan un rol dominante en las apli-

ϕ
– Control de semáforos. caciones embebidas: Web y Email. Para las
aplicaciones embebidas estos dos servicios
ofrecen la funcionalidad requerida cuando es
Un buen ejemplo de aplicación de Internet em- necesario el acceso y control de datos en siste-

α bebido son las flotas de camiones. Particular-

mente su logística. Ya hay implementaciones
de localización GPS y rastreo, pero agregando
la potencialidad de Internet, a través de, por
mas embebidos.

Email ofrece un buen servicio, si los datos son

requeridos en una base regular y la transmi-
Σ
θ β

sión no es de tiempo crítico o real. Si el dispo-
sitivo embebido es principalmente un recolec-
tor de datos, tal como una estación meteoroló-
gica, ese dispositivo podría enviar un email en
una base regular, por ejemplo cada hora, con
el último conjunto de datos acumulados.
Si es requerido un acceso remoto instantáneo
a datos o bien un control remoto de ciertas
funciones de un sistema embebido, los servi-
dores Web y los Browsers ofrecen el mejor
servicio. Si el sistema embebido corre un ser-
vidor Web, los datos y funciones pueden ser
accedidos remota e instantáneamente. El ser-
vidor Web podría no solo desplegar datos en
páginas Web refrescadas dinámicamente, sino
que también traer realimentación instantánea a
los dispositivos vía formularios html o xhtml.
Desafíos
La Internet soporta muchos diferentes protoco-
los y métodos de conexión. Uno de las prime-
ras decisiones necesarias para interconectar a
Internet sistemas embebidos es: ¿qué protoco-
los necesitan ser implementados para mi apli-
cación? Como los dispositivos embebidos a
menudo no ofrecen muchos recursos de CPU y
memoria para manejar el protocolo TCP/IP
completo, se deben analizar cuidadosamente
qué protocolos son los mínimos requeridos.
Es importantísima la decisión de qué protoco-
los o servicios mantener y de cuáles prescin-
dir, ya que mientras menores sean los requisi-
tos de protocolos o servicios TCP/IP, más
pequeño y de bajo costo será el microcontrola-
dor capaz de soportarlo, ofreciendo al usuario
final una aplicación embebida más atractiva
desde el punto de vista económico.
Bajar los costos usando gateways
Actualmente una manera popular de bajar aún
más los costos de conectividad a Internet es no
21
establecer la comunicación a Internet directa-
α
mente, sino que comunicar vía un controlador
externo o un gateway. La idea es usar un dis-
positivo embebido que use un canal de comu-
nicación de bajo costo tal como I2C o CAN
Σ
β
para comunicarse con un gateway. El gateway
ya tiene toda la inteligencia, CPU, recursos y
memoria necesaria para implementar una apli- δφ
λ
cación conectable a Internet.
Actualmente existen muchas implementaciones
ψθ
de este tipo de conexión, desde gateways ex-
ternos hasta los “gateway en un chip”, donde
toda la funcionalidad del gateway está embebi-
da en un pequeño circuito que cabe en un
socket PLCC
¿Hay estándares para Internet en sistemas
embebidos? ϕ
Uno de los más grandes problemas de la inter-
conectividad a Internet de sistemas embebidos
es justamente la falta de normativas que pue-
α
dan seguir los fabricantes para poder fijar un
estándar de facto.
Existen muchos fabricantes y ninguno genera
Σ
β
hardware y software estándar, dado que no hay
norma alguna. De hecho, una de las más gran-
des problemáticas al diseñar un sistema embe- δφ
λ
bido conectable a Internet es la casi nula posi-
bilidad de portar el diseño a otra arquitectura
de microcontrolador, si por algún problema el
ψθ
fabricante dejara de producirlo. La falta de por-
tabilidad y la obligación de tener que adaptar el
sistema para cada nuevo diseño alejan un
poco a los fabricantes dado que nadie quiere
ϕ
que su diseño caiga en obsolescencia rápida-
mente y obligue a realizar un nuevo desarrollo
de hardware y software considerando el alto
costo de las horas de ingeniería.
A la fecha de la escritura de este articulo, julio
de 2005, solo existe una pequeña idea, la
RFC#2324 “Hyper Text Coffee Pot Control Pro-
αΣ
θ β
 22

α tocol”, que menciona un posible protocolo de Más allá del medio físico, una capa de contro-

Σ
β control de cafeteras con hipertexto.

Seguridad de la interconectividad
ladores de dispositivo (device driver) debe ser
insertada para asegurar una apropiada comuni-
cación con el medio físico. Ej. Ethernet embe-
bido es lo más común.

δφ ξ Un aspecto de no menos importancia para una

aplicación de Internet embebida es la seguri-
dad, la cual de por sí es nula dado el aspecto
¿Son necesarios todos los servicios de
TCP/IP?

λ
público de Internet. Cuando interactuamos con
TCP/IP hay que considerar que por defecto no Cuando es implementado el protocolo TCP/IP
hay encriptación y la transmisión es hecha en sobre microcontroladores de medio o bajo ren-

ψθ
paquetes donde casi toda la información va en
texto plano ASCII, incluyendo contraseñas y
nombres de usuario. Cualquier cosa que sea
transmitida por Internet puede ser interceptada
dimiento, podemos simplemente eliminar algo
de funcionalidad que sin perjuicio de TCP/IP no
puede aumentar las prestaciones.

ϕ
usando un simple “sniffer” y nadie desearía
que su sistema de seguridad casero permita
que un hacker pueda violarlo e ingresar a la
propiedad sin autorización.
De todas las funciones provistas por TCP/IP, la
fragmentación de mensajes es el mejor candi-
dato a eliminar. En la capa IP, los mensajes si
son más largos que 64kbytes son fragmenta-

α Para asegurar la información de manera priva-

da, Netscape implemento SSL(Secure Socket
dos en varias piezas durante la transmisión y
reensamblados en el receptor.

β
Layer) basada en un código de encriptación de
Σ 128 bits, el cual llego a ser el estándar de fac-
to. Desafortunadamente, manejar una clave de
128 bits no es tarea fácil para un microcontro-
lador de 8 o 16 bits. Por no decir imposible.
En un microcontrolador de 8-bits con habitual-
mente un rango de direccionamiento de
64kbytes, este tipo de fragmentación puede
hacer mermar valiosos recursos de memoria,
por lo que es perfectamente prescindible; de

δφ UN POCO DE INFORMACIÓN TÉCNICA

hecho, rara vez en un sistema embebido se
enviarán paquetes de datos de más de 64kb-
ytes. A lo más 1kbyte.

λ
El protocolo TCP/IP
IPv4 vs IPv6

ψθ
El direccionamiento más usado actualmente en
Internet es todavía IPv4, el cual usa direccio-
nes de 32 bits escritas como cuatro bytes se-
parados por un punto. Tales direcciones identi-

ϕ
fican un host (nodo) en la Internet. Ej.
129.132.29.84.

Las capas de TCP/IP están localizadas al me- Como hay ciertas limitaciones al asignar hosts

α dio de la pila (stack) completa de comunicacio-

nes. Ellas aseguran la apropiada comunicación
punto-a-punto y se preocupan de enrutar y en-
usando este método, la Internet esta tratando
de expandir su direccionamiento con una ver-
sión extendida. La nueva versión, IPv6, contie-
ne 128 bits por dirección, escrita como 8 pala-

β
tregar los paquetes.
Σ
θ

bras hexadecimales separadas por un símbolo
dos puntos.
Ej. 1234:5678:9ABC:DEF0:0123:4567:89AB:CDEF
Para muchas aplicaciones de Internet Embebi-
do, una implementación de IPv4 será suficien-
te, dado que es más simple de implementar y
en un microcontrolador de 8 ó 16 bits siempre
una limitante será la cantidad de memoria RAM
y sobre todo la memoria de programa o flash.
La negociación de tres vías de TCP/IP
Para entender un poco cómo el tráfico de la
red es creado, revisemos la comunicación en-
vuelta en una conexión TCP/IP.
1. Un cliente envía un segmento con el bit
SYNC en uno y el bit ACK en cero
2. El servidor responde con bits SYNK y ACK
en uno.
3. El cliente confirma la conexión solo con el bit
ACK en uno y la conexión es establecida.
4. Los datos son intercambiados con paquetes
tan largos como sea necesario.
23
5. Cualquiera de los equipos puede terminar la
α
comunicación usando el flag FIN.
Hay que tener en cuenta que cualquier parte
de la comunicación indicada arriba pasará se-
Σ
β
guramente por muchos routers. Si el paquete
de datos es muy largo, lo más probable es que
sea fragmentado en paquetes más pequeños δφ
λ
–cada trozo viajará por diferentes routers– y el
receptor necesitará reensamblar el paquete
original de datos.
ψθ
¿De qué manera podemos enviar y recibir da-
tos reales en un sistema embebido?
Hay dos maneras básicas, dentro de todos los
servicios disponibles del protocolo TCP/IP.
Email y Web.
ϕ
Cada uno de los dos tiene sus pros y contras,
por ejemplo, al enviar emails, el equipo embe-
bido debe actuar como un cliente SMTP y
POP3. Y en ambos interactúan demons que
α
procesan los mails retardándolos desde unos
pocos minutos hasta a veces horas o días an-
tes de una entrega exitosa.
Σ
β
Como SMTP para codificar la información
que se quiere enviar ya sea como texto pla-
no ASCII o bien con un formato binario codi- δφ
λ
ficado en MIME, el que es traducido en ca-
racteres ASCII válidos. Como POP3 actúa
como un cliente que recibe mails, los cuales
ψθ
se traducen en datos válidos. Ej. Suponga-
mos que desarrollamos un equipo que envía
información de datos meteorológicos. Como
aquí el tiempo de recepción no es crítico
ϕ
dada la naturaleza de velocidad de cambios
meteorológicos, podemos enviar los datos
con un mail y esperar su recepción recibien-
do otro mail, es decir, usaríamos protocolo
SMTP y POP3.
Si queremos más funcionalidad, velocidad en
las respuestas o usar las potencialidades de
α
β
Σ
θ
 24

α los applets de java, la solución es usar un SOLUCIONES DISPONIBLES PARA INTER-

Σ
β servidor WEB embebido. Este solamente ne-
cesita manejar a modo servidor el protocolo
http, o Protocolo de Transferencia de Hyper
Texto, el cual es bien conocido, pero a modo
NET EMBEBIDA

Hay una amplia variedad de diferentes solucio-

nes comerciales en el mercado actual para co-

δφ ξ de referencia se indica que se basa en una

conexión TCP entre un cliente que corre un
Browser y un puerto asignado a http en el
nectar un dispositivo embebido a Internet.

En general las podemos diferenciar según las

λ
servidor. Cliente y servidor intercambian siguientes categorías:
mensajes en texto plano ASCII con coman-
dos tales como GET, HEAD y POST. El len- 1. TCP/IP implementado en un microcontrola-

ψθ
guaje usado para generar las páginas WEB y
las peticiones de estas es simplemente texto
plano ASCII incluido dentro de dos símbolos
<>, tal como <P>, por ejemplo. Esta solución
dor vía software.
2. TCP/IP implementado en un chip periférico
(gateway-en-un-chip).
3. TCP/IP implementado usando un gateway

ϕ
nos permitiría, por ejemplo, monitorear casi externo.
en tiempo real la misma aplicación meteoro- 4. TCP/IP implementado usando un gateway
lógica indicada con email, pero ingresaría- de alto rendimiento.
mos desde nuestro PC a este servidor WEB

α remoto indicándonos y generándonos una

página con la última información.
La principal diferencia entre las soluciones 3 y
4 es que la solución 3 se refiere a un solo

Σ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 25

dispositivo embebido y en cambio la 4 a más • La CPU no puede manejar fielmente la se-

α
de un dispositivo embebido considerando se-
guridad, rendimiento y estabilidad.

Realicemos una comparación entre los diferen-

guridad de la aplicación.

TCP/IP implementado en un chip (gateway

en un chip)
Σ
β
tes conceptos:

TCP/IP implementado en un microcontrolador

Las soluciones en esta categoría requieren im-
plementar el stack TCP/IP completamente en
Desde esta categoría siempre tendremos algún
tipo de gateway entre el microcontrolador de la δφ
λ
aplicación embebida y Internet. La principal di-
ferencia es que el gateway está localizado
dentro o fuera de la aplicación y como está

software, corriendo en el microcontrolador prin-
cipal de la aplicación embebida. En orden para
ser capaz de hacer esto, es necesario hard-
ware apropiado, una interfaz tal como un puer-
to serial para comunicarse con un MODEM o
un chip de ethernet embebido para acceso di-
recto a ethernet.
Ventajas
ψθ
implementado.
Las soluciones de esta categoría implemen-
tan el stack TCP/IP en hardware completa-
mente, sobre chips dedicados o simplemente
tratando de miniaturizar al máximo el ga-
teway usando PC miniatura (SBC o Single
Board Computer). ϕ

• Habilita un dispositivo embebido directa-

mente a Internet.
Ventajas

• Habilita un dispositivo embebido directa-

α
• No requiere hardware adicional más que un
MODEM. No es necesario gateway alguno.
• Las modificaciones de hardware necesarias
son mínimas.
mente a Internet.
• No requiere hardware adicional más que
un MODEM. No es necesario gateway al-
guno.
Σ
β
• Asume que hay muchos recursos de memo-
ria o conectividad física (Ej. Puerto serial
para el MODEM).
• Toda la conectividad a Internet está dentro
de un solo chip.
• Mínimos requerimientos al microcontrolador δφ
λ
• Solución plana de software únicamente. de memoria o CPU.
• Disponibilidad para virtualmente todos los • El chip tiene sus propios buffer de memoria.
microcontroladores existentes.

ψθ
• No usa un protocolo propietario como con
algunos gateways. Desventajas

Desventajas • Se necesita hacer modificaciones de hard-

ϕ
ware para insertar el chip con Internet em-
• Debe compartir el microcontrolador principal bebido.
de la aplicación embebida para manejar las • Puede haber algún grado de dificultad al in-
comunicaciones a Internet. tegrar un chip extra.
• Un poco ambiguo en cuanto a las capacida-
des de RAM y ROM necesarias.
• Ídem para la velocidad necesaria de la
CPU.
• No es una solución estándar, por lo que hay
que evaluar las ventajas, desventajas y dis-
ponibilidad a largo plazo en el mercado del
chip con Internet.
αΣ
θ β
 26

α TCP/IP implementado en un gateway exter- Ventajas

Σ
β no para un solo dispositivo

Los gateways de esta categoría son implemen-

tados como un dispositivo externo que interac-
• Requiere una pequeña cantidad de recursos
de la aplicación embebida.
• Es necesario una librería, habitualmente C,

δφ ξ túa por algún canal físico de comunicación con

la aplicación embebida, habitualmente un puer-
to serial.
para incorporar y comunicar la aplicación
con el gateway.
• No es necesaria ninguna modificación de la

λ
aplicación embebida.
Ventajas • Asume que hay un puerto serial disponible.
• Mínimos requerimientos de carga en la CPU.

ψθ
• Requiere una pequeña cantidad de recursos
de la aplicación embebida.
• Es necesario una librería, habitualmente C,
para incorporar y comunicar la aplicación
• Permite una puesta al mercado mínima,
dada las nulas modificaciones de hardware y
las modificaciones de software son mínimas.
• Múltiples dispositivos embebidos pueden

ϕ
con el gateway. compartir un único gateway.
• No es necesaria ninguna modificación de la
aplicación embebida. Desventajas
• Asume que hay un puerto serial disponible.

α • Mínimos requerimientos de carga en la

CPU.
• Permite una puesta al mercado mínima,
• Requiere un gateway por cada dispositivo
embebido.
• Costo medio.

β
dada las nulas modificaciones de hardware y
Σ las modificaciones de software son mínimas.
Desventajas
• En general, los gateways son muy caros
para ser usados en un solo dispositivo, es-
pecialmente en aplicaciones de bajo costo.
• Nula estandarización del protocolo entre la
aplicación y el gateway. Habitualmente cada

δφ • Requiere un gateway por cada dispositivo

embebido.
• Costo medio.
vendedor usa un protocolo propietario.
• Poca claridad respecto a la seguridad.

λ
• En general, los gateways son muy caros ¿CUÁL ES LA MEJOR SOLUCIÓN PARA
para ser usados en un solo dispositivo, es- UNA APLICACIÓN INTERNET EMBEBIDA?
pecialmente en aplicaciones de bajo costo.

ψθ
• Nula estandarización del protocolo entre la
aplicación y el gateway. Habitualmente cada
vendedor usa un protocolo propietario.
• Poca claridad respecto a la seguridad.
Desafortunadamente no se puede dar una res-
puesta genérica a esa pregunta. Esta depende
únicamente de la aplicación y sus entradas y
salidas requeridas. Simplemente se pueden

ϕ
dar algunos lineamientos o consejos.
TCP/IP implementado en un gateway exter-
no de alto rendimiento Si la aplicación es de bajo volumen de unidades
y consiste solo de dispositivos stand-alone (no

α Estos gateways deben ser lo suficientemente

poderosos para manejar múltiples dispositivos
embebidos y tomar precauciones desde el pun-
to de vista de la seguridad.
cadenas o múltiples equipos interconectados),
la solución 3 de usar un gateway por dispositivo
puede ser la mejor opción, especialmente si se
necesita una puesta al mercado rápida.
Σ
θ β
 27

Si el volumen es alto y el sistema es sensible PLCC68 el chip consiste de un microcontrola-

α
al costo, la solución 1 de implementar TCP/IP
en la misma CPU o la solución 2 de TCP/IP en
un chip serán las mejores decisiones.
dor de 16-bits con memoria Flash y RAM. El
completo stack TCP/IP es implementado en el
firmware del chip.
Σ
β
La solución 4 solo se consideraría si hay múlti-
ples dispositivos interconectados entre sí, por
ejemplo en una cocina conectamos muchos de δφ
λ
los diferentes artefactos a Internet, por ejemplo
horno, microondas, refrigerador, etc.

ψθ
EJEMPLOS DE SOLUCIONES COMERCIALES

Micronet de CMX

Micronet es un stack TCP/IP minimizado ofreci-

do por CMX, optimizado para microcontrolado-
res de 8 y 16 bits. Presenta servicios para im-
plementar un servidor WEB o correo entrante/
El chip ofrece una variada interfaz de conexión
al microcontrolador embebido de la aplicación
(serial o paralelo) y a la Internet (MODEM o ϕ
saliente. En un microcontrolador popular como
un 8051, Micronet tiene los siguientes requeri-
mientos de memoria:
ethernet).

Rabbits (Rabbit 2000 y Rabbit 3000) α

Rabbit Semiconductor tiene un amplio rango de
procesadores con ethernet, Rabbit 2000 y Rab-
bit 3000. Para complementar estos procesado-
res, ellos proveen kits de desarrollo que inclu-
Σ
β
yen una copia de su compilador Dynamic C y un
stack TCP/IP libre de royalties además de:
δφ
λ
• RCM3000 Rabbit 3000 procesador basado
en CPU Z180.
• 10Base-T Ethernet.

ψθ
Notar que el cálculo no incluye memoria reque- • 128K–512K SRAM, 256K–512K Flash.
rida para una pagina WEB y tampoco los bu- • 52 I/O digitales.
ffers de transmisión/recepción. En TCP/IP am- • Reloj de 29,4 MHz
bos buffers deben ser lo más grande que se

ϕ
pueda, dado que hay que recordar que TCP/IP
maneja paquetes de largo variable.

iChip de Connect One

El iChip es un “Chip con Internet” que actúa

como un chip periférico, integrable a un siste- α
β
ma embebido. Implementado en formato
Σ
θ
 28

α eZ80 Acclaim

Σ
β El kit de desarrollo del eZ80F91 ofrece un
completo ambiente de diseño y depuración
para aplicaciones con el eZ80Acclaim!. Inclu-

δφ ξ ye una tarjeta de desarrollo con el eZ80F91,

eZ80F91 Modulo Mini Ethernet, Smart debug
cable (RS-232), alimentador y compilador

λ
ZDS II ANSI C.

ψθ
El sensor inductivo, en rigor debiera ser re-
dondo, tal como una espira de alambre, pero
por efectos constructivos es cuadrado, dado
que hay que cortar el pavimento con herra-
mientas diamantadas. Este sensor inductivo

ϕ es recibido por un adaptador de señal que

simplemente envía un estado lógico 1 si hay
un móvil metálico sobre el sensor y 0 si no lo

α Características

• Footprint para memoria flash externa de

2Mx8.
hay.

Por lo tanto la aplicación de conteo se limita a

verificar cuando el estado es 1 y cuándo es 0

Σ
β • Conector RS-232 para interfaz serial con
UART integrada.
• Conectores ZDI y JTAG para depuracion.
• LED de alimentacion con 3.3V.
simplemente.

Para la comunicación de la aplicación desarro-

llé un servidor WEB embebido usando un pro-

δφ • Un led de prueba amarillo y un botón pul-

sador
• Fuente alimentacion externa de 5VDC
cesador derivado del famoso Z180 de Zilog. El
Z80 Acclaim, procesador embebido que posee
internamente un chip ethernet, el cual es ven-

λ
dido por la compañía Zilog como kit de desa-
IMPLEMENTACIÓN DE UNA APLICACIÓN rrollo por 99 US$ en su sitio web
REAL www.zilog.com

ψθ Para mostrar la facilidad de implementación de

dispositivos embebidos a Internet, mostraré
una demo de un sistema desarrollado para el
El kit se muestra en la siguiente fotografía e
incluye además de todo el hardware listo para
conectarse a Internet vía ethernet, un compila-

ϕ
conteo vehicular del tránsito de vehículos en el dor C y un stack TCP/IP gratuito y royalty free,
Gran Santiago, Chile. el ZTP.

El conteo de vehículos considera usar senso-

α res de tipo inductivo que se colocan en las

calles lo más lejano posible de los semáforos,
los que están ubicados en los cruces entre
calles.

Σ
θ β
 29

gar la información de conteo vehicular actual,

α
simulando los sensores inductivos con el pul-
sador mencionado.

Por simplicidad, se usó una versión demo gra-

Σ
β
tuita del stack TCP/IP Micronet, dada la facili-
dad de uso e implementación de las páginas
WEB. δφ
Se muestra a continuación la página alojada en
el servidor embebido:
λ
Fotografía kit desarrollo Zilog Z80 Acclaim con su inter-
faz de programación

El kit es conectable directamente a ethernet,

ψθ
ϕ
donde podemos conectarnos por ejemplo
usando un modem para tener conexión a Inter-
net. En la siguiente fotografía se puede apre-
ciar el kit conectado a ethernet donde usamos
un cable cruzado para no tener que usar hub y
conectar el equipo directamente a un PC con
tarjeta de red y así poder desarrollar el soft- α
β
ware necesario.
Σ
Se puede apreciar la dirección IP usada, que

δφ
corresponde a una dirección IP privada, típica-
mente usada en redes LAN. El servidor WEB
es sumamente básico. Solo indica el conteo
vehicular, que correspondería a la cantidad de
pulsaciones que se han hecho al botón. Para
mejorar el sistema de comunicación y evitar
“overflow”, lo ideal es realizar el conteo cada, λ
Fotografía kit desarrollo Zilog Z80 Acclaim conectado
con cable cruzado RJ-45
por ejemplo, 5 minutos, y cada vez que se ini-
cie un nuevo periodo de cuenta se reinicia la
variable de computo. ψθ
Dado que el kit incluye un par de pulsadores,
se desarrolló un pequeño servidor web con las
herramientas incluidas, el que permite desple-
Para procesar los datos en el servidor remo-
to que recoge la informacion TCP, se imple-
mentó el siguiente datagrama de informa-
ción:
ϕ
αΣ
θ β
 30

αΣ
β 0
#canal MSB
T. ocupación MSB
7 8
#canal LSB
T. ocupación LSB
15 16
# vehículos MSB
Terminador MSB
23 24
#vehículos LSB
Terminador LSB
31

δφ
CRC-32 CRC-32 CRC-32 CRC-32

ξ La trama contiene campos separados por bytes También el escritor e ingeniero Fred Eady.

λ con información del número del canal a contar

vehículos, la cantidad que viene en un periodo
de 5 minutos y el tiempo que ocuparon en pa-
Networking and Internetworking with Micro-
controllers
www.edtp.com

ψθ sar por los sensores todos los vehículos. Lue-

go viene un campo que termina la trama, el
cual si es 0xFFFF indica fin de trama y cual-
quier número diferente de 0xFFFF señaliza
Links de empresas dedicadas al rubro de inter-
conectividad a Internet son:

ϕ que comienza otro grupo de canales en el mis-

mo paquete.

El último grupo de 32 bits es el conocido CRC-

CMX
Micronet TCP/IP stack
www.cmx.com

α 32, que se usa para asegurar integridad de la

trama completa.
Zilog Semiconductors
Procesadores Z80 y Z80 Acclaim
www.zilog.com y www.zilog.com/products/

Σ
β REFERENCIAS Y MÁS INFORMACIÓN

Existe una agrupación llamada la “Embedded

Systems Academy” que tiene una colección
family.asp?fam=226

Rabbit Semiconductors
Procesadores de 8 bits con ethernet incluido.

δφ amplia de links referido a la interconectividad a

Internet de dispositivos embebidos. Esta está
disponible en:
www.embeddedinternetworking.com
www.rabbitsemiconductor.com

Philips Semiconductors
8-bit and 16-bit microcontroladores

λ Literatura hay poca, pero una excelente escri-

tora del mundo embebido es Jan Axelson de
www.philipsmcu.com

Phytec

ψθ Lake View Research.

Embedded Ethernet and Internet Complete:
Designing and Programming Small Devices
for Networking.
Single board computers que pueden trabajar
con el stack TCP/IP.
www.phytec.com

ϕ www.lvr.com y www.lvr.com/eec.htm

αΣ
θ β
 31

αΣ
β
δφ
λ
ψθ
Estado del Arte Ataques de Negación de Servicio
ϕ
y de Negación de Servicio Distribuido α
State the Art Denial of Service Attacks and of the Distributed
Denial of Service Attacks Σ
β
Cristián Martínez Moreno; Igor Caracci Marabolí; Julio Fuentealba
Vivallo
δφ
λ
ψθ
ϕ
1
2
Ingeniero Civil Industrial, Universidad de Chile; Doctorando UPM-UCENTRAL
Magíster© en Ingeniería Informática, Universidad de Santiago de Chile; Doctorando UPM-UCENTRAL α
β
3 Magíster en Computación, Universidad de Chile; Doctorando UPM-UCENTRAL

Σ
θ
 32

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 33

ABSTRACT α
In this article we describe the nature of denial of service attacks and of the distributed denial of service
attacks. We emphatize the importance of these types of attack, describe real cases of attacks, characte-
rize and classify these attacks and investigate strategies useful to mitigate them.
Σ
β
RESUMEN

En este artículo se describe la naturaleza de los Ataques de Negación de Servicio (DOS) y la de los
δφ
Ataques de Negación de Servicio Distribuido (DDOS). Se enfatiza la importancia de estos tipos de
ataque, se describen casos de ataques reales, se caracterizan y clasifican estos ataques y se investigan
estrategias usadas para aminorar sus efectos. λ
INTRODUCCIÓN indiscriminada, las apariciones regulares de vi- ψθ
ϕ
rus, las acciones judiciales en contra de la red
Internet se ha convertido en la última década (desde cánones por royalties a CD-ROM hasta
en un hito de la civilización, nadie puede igno- persecuciones a usuarios de programas peer-to-
rar actualmente expresiones como email , peer o P2P pasando por atentados a la privaci-
router, buscador, on-line o servidor. En sep-
tiembre de 2002 ya había más de 600 millones
de personas conectadas a Internet [WWW1]
así como 171 millones de sitios Web [WWW2].
dad de los usuarios) hacen que la realidad de
Internet diste mucho de ser idílica. Por todos
estos motivos, Internet es actualmente el medio
masivo “de moda” y su gran importancia a corto
α
La explicación fundamental a este éxito sin
precedentes es la capacidad única de unir en
un mismo medio el placer y los negocios. Por
otro lado, la disponibilidad de los servicios 24
y mediano plazo no tiene discusión.

DESARROLLO
Σ
β
horas al día, su interactividad total así como su
accesibilidad desde cualquier punto del mundo,
no hacen más que acrecentar su éxito. El im-
pacto tecnológico de Internet en nuestra socie-
Los ataques de negación de servicio (DOS)
más comunes y que han sido registrados por
organismos internacionales y grupos de inves-
tigación [Nor99] de todo el mundo como el
δφ
dad ha sido tan fuerte que ha trascendido su
propio ámbito natural (la red Internet) y es muy
extraño no observar referencias suyas casi a
CERT [WWW18] son:

1. IP Flooding (inundación de paquetes IP), λ

diario en otros medios de comunicación masiva
(televisión, prensa, radio…).

Las empresas digitales (Yahoo, Google, Ama-

2. Broadcast (radiodifusión),
3. Smurf (falsea las direcciones de origen y
destino de una petición o ping),
4. Teardrop / Boink / Bonk / Nestea (falsea
ψθ
zon…) ya tienen una relevancia y peso econó-
mico, actualmente cotizan en la bolsa y mueven
cientos de millones de dólares al igual que lo
hacen las empresas tradicionales como bancos,
los datos de posición y/o longitud de forma
que el datagrama se sobrescriba (overlap-
ping) y produzca un error de sobreescritura
del buffer (buffer-overrun) al tratar con des-
ϕ
eléctricas o petroleras. Sin embargo, estas mis-
mas características que lo hacen único e “im-
prescindible” actualmente pueden condenarlo a
plazamientos negativos),
5. ECHO-CHARGEN / Snork (ping pong infinito),
6. DOOM / QUAKE (generalización del ataque α
β
“morir de éxito”. El envío de spam o publicidad ECHO-CHARGEN),
Σ
θ
 34

α 7. LAND (falsea la dirección y puerto de origen Virus y ataques DDOS - El caso MyDoom:

Σ
β para que sean las mismas que la del destino)
8. PING OF DEATH (utiliza una vez más las de-
finiciones de la longitud máxima de paquetes
de los protocolos IP/UDP/TCP/ICMP
durante la primera quincena de febrero de
2004 se marcó el inicio de una nueva tenden-
cia en los ataques de negación de servicio dis-
tribuido. Hasta la fecha, la preparación de un

δφ ξ [RFC791][RFC792] así como la capacidad de

fragmentación de los datagramas IP. Algunos
detalles técnicos a nivel de protocolo, serán
ataque DDOS quedaba sujeto a un grupo se-
lecto de hackers, ya que pese a la existencia
de herramientas más o menos sofisticadas, el

λ
analizados en el punto que trata sobre vulne- sistema continuaba siendo artesanal del tipo:
rabilidades en el protocolo TCP más adelante.
1. Lograr acceso a un ordenador vulnerable.

ψθ
Así se logra llegar a los ataques de negación Este paso lleva a la comprobación de cien-
de servicio distribuido o DDOS (Distributed tos de exploits para cada una de las posi-
Deny Of Service), que corresponden a DOS bles víctimas. Pese a existir programas se-
donde existen múltiples focos distribuidos y miautomáticos encargados de las

ϕ
sincronizados que centran su ataque en un comprobaciones, es un método de prueba y
mismo destino [Dit99][WWW3]”. En la Figura 1 error que consume mucho tiempo y no
se puede observar de forma simplificada un es- siempre garantiza resultados.
quema para un ataque DDOS: 2. Instalar un kit de DDOS. Una vez que se ha

α conseguido el acceso al computador, se de-

ben instalar/compilar (paso manual) los pro-
gramas necesarios para que el atacante
tome el control del computador y lo integre
Σ
β a su red de ataque.

Estos dos puntos son repetidos una y otra vez

por cada computador que se agregue a la red

δφ de ataque. De esta forma, en los ataques ob-

servados hasta la fecha raramente existían
más de dos o tres decenas de computadores

λ
Figura 1. Ataque típico DDOS [www.hostlibrary.com] implicados. El virus MyDoom [WWW5]

Tabla 1. Incidentes registrados en el CERT hasta la primera quincena de 20054

ψθ 1988-1989
Año
Correo
1988
539
1989
2,869

ϕ
1990-1999
Año 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999*
Correo 4,448 9,629 14,463 21,267 29,580 32,084 31,268 39,626 41,871 34,612
2000-2005

α Año
Correo
2000
56,365
2001
118,907
2002
204,841
2003
542,754
2004 1Q, 2005
717,863 128,692

β
4 Los mensajes totales del correo dirigieron (1988-1Q, 2005): 2.031.678

Σ
θ

[WWW6] original, cabe notar que han salido
varias mutaciones posteriormente que modifi-
can su comportamiento [WWW7], se propaga
a través del correo electrónico y afecta única-
mente a sistemas operativos Windows. La Ta-
bla 2 indica el detalle de los incidentes regis-
trados por el CERT, los que suman ya más de
dos millones de incidentes y que además nos
indica el grado de peligrosidad que puede al-
canzar este tipo de ataque, debido a las pro-
yecciones de proliferación que genera este
medio.
En la actualidad más del 90% de los computado-
res existentes utilizan la plataforma Microsoft
como sistema operativo [WWW8], lo que lleva po-
tencialmente a varios millones de computadores.
El comportamiento de este virus consistía en lan-
zar desde el ordenador infectado un ataque de
negación de servicio a la dirección www.sco.com
[WWW10] que finalizaba el día 12 de febrero de
2004, donde SCO es una empresa propietaria de
un sistema operativo Unix que se encuentra en
varios juicios por patentes de software contra Li-
nux, IBM y comunidades de software libre. Se
hace prácticamente imposible determinar de for-
ma exacta la cantidad de peticiones realizadas por
los computadores infectados.
Figura 2. Sofisticación del ataque con conocimiento del intruso.
35
En la Figura 2 se muestra la evolución en las
α
técnicas utilizadas en este tipo de ataques, se
aprecia que el nivel de conocimiento de los in-
trusos acerca de la víctima cada vez es menor
en la medida que son más sofisticadas dichas
Σ
β
técnicas. El éxito de este ataque fue tan rotun-
do que la dirección www.sco.com permaneció
fuera de uso durante más de una semana; la δφ
λ
desesperación de esta compañía les obligó a
ofrecer públicamente el día 30 de enero de
2004 la cantidad de 250.000 dólares
ψθ
[WWW11][WWW12] por cualquier pista que lle-
vase a la identificación del autor o autores de
este virus. De hecho, la compañía SCO ante la
imposibilidad de absorber el ataque tuvo que
dar de baja su dominio del sistema de DNS y
comprar un nuevo dominio http://
www.thescogroup.com/ hasta que pasado el
día 12 de febrero el virus dejó de lanzar el ϕ
ataque.
La compañía de sistemas antivirus Message-
labs registró hasta el 12 de abril de 2004 en las
α
empresas que utilizan sus antivirus más de 54
millones de emails infectados [WWW13]. Te-
niendo en cuenta que los emails que filtra esta
compañía no son ni siquiera un 1‰ del total
Σ
β
mundial, la envergadura que ha alcanzado este
δφ
λ
ψθ
ϕ
α
β
Σ
θ
 36
α nuevo sistema de DDOS revela que no es posi-
Σ
β ble actualmente parar este tipo de ataques. In-
dependientemente del hecho puntual del ata-
que a SCO, hay que señalar que se ha
producido un cambio tecnológico importante
δφ ξ pasando de un sistema semimanual donde
apenas decenas de ordenadores colaboraban
en un ataque DDOS bajo la orden directa de
λ
una o varias personas, a un sistema de ataque
totalmente automático con millones de compu-
tadores distribuidos por todo el mundo.
ψθ
Hasta ahora el gran problema de los virus se
centraba en los estragos o problemas que se
pudieran causar en un computador infectado
ϕ
y su capacidad de propagación. A partir de
MyDoom, el problema deja de centrarse en
un computador y pasa a afectar a terceros
(SCO en este caso y al resto de usuarios de
α Internet debido al uso de ancho de banda
que paraliza o aletarga toda la red), lo que
abre una puerta a un inquietante peligro. Por
β
otro lado, ya no son necesarios conocimien-
Σ tos específicos y tiempo para realizar ata-
ques de fuerza bruta. Cualquier persona que
simplemente modifique en el código del virus
el destino de su ataque (a su colegio, empre-
δφ sa, universidad...) puede fácilmente lanzar un
DDOS siendo prácticamente imposible de-
mostrar su culpabilidad.
λ
Otro efecto que se debe tener en cuenta en
este tipo de sistemas, es que los computado-
ψθ
res con fechas erróneas estarán creando conti-
nuamente tráfico que permanecerá aletargando
la red y consumiendo ancho de banda, lo que
llevará a una degradación de los servicios de
ϕ
Internet. El peligro del sistema híbrido que ini-
ció MyDoom no es únicamente que se pueda
conseguir el destino real de cualquier sistema
conectado a Internet, sino que además puede
α lograr un colapso de toda la red inundándola
con exceso de tráfico o atacando sus zonas
más sensibles (DNS, routers intercontinenta-
les…).
Σ
θ β
Ataques de negación de servicio distribuido: se
basan en coordinar una serie de nodos conecta-
dos a Internet de forma que dirijan su ataque
simultáneamente y desde diferentes lugares so-
bre un mismo objetivo. Pese a que los distintos
ataques DDOS se centran en aspectos distin-
tos, como colapsar un servicio simulando la co-
nexión de miles de usuarios a la vez o ralenti-
zando el tiempo de respuesta por la generación
de tráfico excesivo, su característica común es
su gran consumo de ancho de banda, por lo
cual se convierten en un inmenso peligro, ya
que los paquetes de distintas comunicaciones
comparten las mismas rutas. En la actualidad
existen tecnologías que ofrecen cada vez co-
nexiones más rápidas y con mayor ancho de
banda, y por otro lado tenemos el constante cre-
cimiento de nodos conectados a Internet, lo que
se traduce en un mayor número de nodos en
este tipo de ataques. Por supuesto, puede ocu-
rrir que de forma voluntaria y consciente varios
usuarios se coordinen en un ataque concreto,
pero la realidad muestra que los computadores
involucrados en un ataque lo realizan involunta-
riamente, debido a que si un atacante usa su
propio computador, tarde o temprano será loca-
lizado y sancionado. Por lo mismo, uno o varios
atacantes (hackers) se dedican a buscar siste-
mas vulnerables (que no han actualizado el últi-
mo parche de Windows, o con versiones anti-
guas de programas o sistemas operativos), e
instalan un programa que les permite obtener
un control remoto del computador. En una red
que posee millones de computadores conecta-
dos, la probabilidad de encontrar un sistema fá-
cil de vulnerar o que permita su uso ilegal au-
menta enormemente con el uso de conexiones
permanentes, por lo que simplemente es una
cuestión de tiempo. Una vez que el o los ata-
cantes han conseguido un número importante
de computadores bajo su control, los adminis-
tran como una estructura jerárquica que les per-
mita mantener a salvo su identificación y a la
vez mantener el control de un gran número de
nodos de forma sencilla y eficiente. ([Far96]
 37

[VM01] [MP03] [Ver03]). El atacante o atacantes todo su ancho de banda. En la Figura 3 pode-
α
controlan de forma directa una serie de nodos
llamados “masters” que a su vez dan las órde-
nes recibidas a los nodos que tienen a su cargo
o “slaves” (Figura 1 = Zombies). En la actuali-
mos observar que en el ataque de DDOS indi-
recto:

1. Se crea la infraestructura necesaria para el

Σ
β
dad algunas de las herramientas más usadas en
este tipo de ataques son [Ver03]:
DDOS (instalación de los computadores
master/ slaves).
2. Se inicia el ataque DDOS consistente en en- δφ
λ
• Tribe Flood Network / TFN [Dit99-3]. viar desde los esclavos miles de peticiones
• El proyecto TRINOO [Dit99] también conoci- “correctas” de conexión TCP al puerto 179 a
do como TRIN00. diferentes ISP. Se falsea la dirección de ori-

ψθ
• SHAFT [DDL00]. gen de la petición y el puerto, colocando la
• STACHELDRAHT [Dit99-2], basada en có- dirección IP de la víctima.
digo del TFN. 3. Se logra la obtención de cientos de miles de
• El TFN2K [BT00], revisión de la herramienta respuestas de los distintos ISP que blo-
TFN. quearán todo el ancho de banda del servi-

También se usan técnicas de ataque indirecto

o de reflexión (reflection DDOS) [Gib02]
dor WWW atacado.

Finalmente, una vez que se ha decidido el tipo ϕ

[Lar03] [MP03] [MP03-1], las que consisten en
falsificar la dirección de origen de los datagra-
mas de datos (Figura 3). La idea que se deriva
en este tipo de ataques es el uso de varios
de ataque a realizar, se lanza de forma sincro-
nizada y simultánea sobre el objetivo, el que
suele verse sobrepasado por completo durante
el desarrollo del ataque.
α
computadores con conexión “lenta” para lanzar
de forma masiva peticiones falsas a servidores
que disponen de un gran ancho de banda. De
esta forma, al sustituir la dirección origen real
DDOS en contra de los “root servers”: El 21
de octubre de 2002 [WWW20] se registró un
DDOS en Internet, y su objetivo eran los trece
Σ
β
por la del nodo que se desea atacar, se logra
que todas las respuestas sobrepasen al nodo
atacado hasta colapsarlo mediante el uso de
“root servers”, en un intento al parecer de alte-
rar el funcionamiento de toda la Internet. Du-
rante varias horas los distintos “root servers” δφ
λ
ψθ
ϕ
α
β
Figura 3. Ataques DDOS [Ver03].

Σ
θ
 38

α fueron objeto de un ataque de negación de ser- el tráfico que recibían. El ataque duró poco

Σ
β vicio distribuido (DDOS), basado en una sobre-
carga de requerimientos de tipo “ping flooding”,
que corresponde a una cantidad excesiva de
requerimientos del tipo ICMP. Como todo servi-
más de una hora. Antes de dicho período, va-
rios de los administradores de los “root ser-
vers” tomaron como contramedidas el bloquear
el tráfico excesivo que les estaba llegando, sin

δφ ξ cio, llega un límite en donde la capacidad de

respuesta ante los requerimientos se hace difi-
cultosa, e incluso imposible. La Figura 4 mues-
afectar el servicio principal que cumplen, que
es el DNS. Fue notable en esta oportunidad la
reacción de la prensa ante este ataque, debido

λ
tra mediciones realizadas a los “root servers” a que creyeron de que era un ataque que po-
durante el día del ataque, que muestran los dría terminar con el funcionamiento de la Inter-
efectos en el tiempo de respuesta de dichos net. En teoría la Internet podría seguir funcio-

ψθ
servidores: nando con solo uno de los “root servers (de
trece). Además, las consultas que se realizan a
Los hechos fueron los siguientes: El ataque iba los “root servers” son relativamente pocas, de-
dirigido a los trece “root servers”. Cinco de los bido a la misma estructura del DNS, que ade-

ϕ
“root servers” funcionaron sin problemas, sin
siquiera reportar un aumento significativo en su
tráfico; en el resto, algunos quedaron directa-
mente influenciados por el ataque, y varios de
más guarda copias de la información ya con-
sultada por un cierto tiempo, precisamente
para evitar la sobrecarga del sistema y evitar
realizar consultas a cada rato. Solamente

α ellos simplemente no pudieron manejar la so-

brecarga, otros respondieron, pero con ciertas
demoras, además de reportar un aumento en
cuando un servidor de DNS no conoce algún
TLD, se consulta a los “root servers”, lo que es
muy poco frecuente. A pesar de que el sistema

Σ
β
δφ
λ
ψθ
ϕ
α
β
Figura 4. Tiempo de respuesta “root servers”, 21 y 22 de octubre de 2002 [WWW20].

Σ
θ

de DNS es robusto frente a estas situaciones,
un ataque de mayor envergadura no solo satu-
raría al sistema de DNS, sino que también de-
gradaría la conectividad dentro de la Internet,
con todos los efectos negativos que esto po-
dría acarrear.
DDOS en contra de UltraDNS: UltraDNS es
una de las más grandes compañías proveedo-
ras de servicios de DNS, famosa por su cartera
de grandes clientes y porque acoge a varios
TLD, incluidos. INFO, y a partir de enero de
2003, a. ORG. El 21 de noviembre del 2002 los
servidores de UltraDNS fueron también objeto
de un ataque del tipo DDOS, en donde si bien el
servicio de DNS no se vio interrumpido debido a
la infraestructura propia de UltraDNS, el servicio
fue degradado y su ancho de banda consumido
por falsos requerimientos. De manera similar al
ataque a los “root servers”, las direcciones IP de
origen de este ataque fueron falsificadas. Un
peak registrado de alrededor de dos millones de
consultas por segundo conformó este ataque.
Respuestas actuales a los ataques DDOS:
En un ataque de negación de servicio podemos
identificar claramente tres componentes distin-
tos (Figura 5):
1. Sistemas origen: son los múltiples puntos
inicio de la generación masiva de datagra-
mas de datos IP.
Figura 5. Ataque DOS/DDOS [Ver03]
39
2. Sistemas intermedios: son sistemas pasi-
α
vos a través de los que circulan los paque-
tes IP hasta que estos llegan a su destino.
3. Sistema final: destino final del ataque.
Σ
β
Si el problema de la negación de servicio es
analizado con una mayor profundidad, se perci-
be que no hay recetas o soluciones mágicas δφ
λ
que permitan evitar este tipo de ataques. Sin
embargo, dentro de la bibliografía se pueden
encontrar cinco requisitos básicos que debería
ψθ
cumplir cualquier propuesta de solución [MP03-
2], las que son detalladas a continuación:
1. Uso de una solución distribuida como
defensa a un problema distribuido: solu-
ciones individuales no tienen sentido, ya
que no alcanzarán la visión global generada
por un ataque distribuido. ϕ
2. La solución propuesta no debe penalizar
el tráfico de los usuarios legales: algunas
propuestas se basan en complejos sistemas
de informes y filtros que mantienen listas y
α
cuentas de todos los paquetes recibidos.
Estos sistemas penalizan de forma general
a los usuarios, dándole lentitud al sistema.
3. La solución debe ser robusta, universal y
Σ
β
válida para amenazas externas e inter-
nas: El sistema debe ser capaz de identifi-
car nodos y usuarios legítimos, así como δφ
λ
detectar y aislar si fuera necesario los
nodos comprometidos o maliciosos.
ψθ
ϕ
α
β
Σ
θ
 40

α 4. La aplicación del sistema propuesto En la actualidad empiezan a surgir soluciones

Σ
β debe ser factible: debe de ser adoptada en
forma global en Internet, lo que implica que
debe de ser sencilla y realizable, con un
costo razonable de recursos.
agregadas o distribuidas como el ACC (Aggre-
gated-based Congestion Control ) [Mah02],
SOS (Secure Overlay Service) [KMR02] o De-
fCOM (Defensive Cooperative Overlay Mash)

δφ ξ 5. La solución debe tener una proyección

de expansión: por ser Internet un sistema
heterogéneo en donde es imposible forzar
[MP03-2], pero requieren una comunicación di-
recta con los sistemas intermedios, lo que se
traduce en que también deben estar instalados

λ
la aplicación de un nuevo protocolo, el sis- en ellos para realizar un trabajo conjunto. Ade-
tema propuesto debe permitir su aplicación más, debido al carácter global de Internet (mu-
gradual, además de ser compatible con el chos países, distintas leyes, distinto hard-

ψθ
resto de los sistemas donde aún no haya
sido implementada.
Las soluciones que existen en la actualidad se
ware…) esto no se ha conseguido. Por lo tanto
la necesidad de implantar globalmente la solu-
ción, limita su eficacia y expansión únicamente
a redes de investigación, porque como no en-

ϕ
basan en sistemas clásicos de defensa como
firewalls y sistemas de detección de Intrusos
(IDS [Nor99][Car00][Des03][Ver03]). Fabrican-
tes de equipos de comunicaciones como Cisco
trega una solución gradual y como no existen
estándares apropiados para las diferentes pro-
puestas, prácticamente ningún sistema en pro-
ducción lo implementa.

α en su documento “Defining strategies to project

against TCP SYN denial of service attacks”
[WWW14], de forma simple recomiendan accio-
El futuro de los ataques DDOS: una vez vis-
tos los ataques de negación de servicio y su

β
nes como aumentar el tamaño de la pila TCP, evolución hasta los ataques distribuidos actua-
Σ disminuir el tiempo de espera para una co-
nexión y filtrar el tráfico de salida para evitar el
les (MyDoom), se observa que hay:

uso de direcciones IP falsas [Tan03]. • Mayor frecuencia de aparición. Si en un

principio únicamente se realizaban estos

δφ Soluciones de este tipo son Multops [GP01],

Reverse Firewall [WWW15] o D-WARD [Obr01],
las que se encuentran instaladas al final de la
ataques a grandes empresas (Yahoo, Ebay,
Microsoft…) con el objetivo de ganar cierta
notoriedad, cualquier punto de conexión

λ
cadena de ataque, pero su eficacia es mínima (empresas, universidades, organismos ofi-
debido a que aunque pueden detectar y blo- ciales…) es objetivo de este tipo de ataques
quear la entrada de ataques DDOS a una red, el (SCO, Telefónica, IANA…). Los objetivos

ψθ
consumo de ancho de banda se produce de to-
das maneras, con lo que las respuestas a los
usuarios legales se ven interrumpidas. Adicio-
nalmente existe la dificultad que una gran canti-
han cambiado y en la actualidad se produ-
cen incluso casos de extorsión [Ley04] me-
diante la amenaza de un DDOS a un servi-
cio de Internet como casinos o bancos.

ϕ
dad de visitas provoquen los mismos efectos
que un DDOS, y aun así tratarse de visitas legí-
timas; es el caso de concursos y eventos desa-
rrollados en la Web o de transmisiones de TV
• Ataques cada vez más virulentos. Han
pasado de conseguir detener un servicio de
forma puntual algunos minutos u horas, a
borrar una empresa (Mydoom ante SCO)

α locales, ante eventos de interés masivo (parti-

dos de football), y las soluciones para DDOS
tendrán dificultades para distinguir una situación
legítima de una ilegítima.
durante más de una semana.
• Sofisticación de métodos usados. Han
evolucionado de sistemas semiartesanales
master/slave, donde el ataque era controla-
Σ
θ β

do remotamente, a sistemas automáticos
desarrollados por cualquier computador in-
fectado por un virus. Así a la fecha se pue-
de extrapolar que el problema lejos de des-
aparecer o minimizarse crecerá, siendo uno
de los grandes caballos de batalla para la
supervivencia de Internet.
Última vulnerabilidad en el protocolo TCP:
El 20 de abril de 2004 se hace pública por los
organismos oficiales [WWW16] [WWW17] una
última vulnerabilidad, la que permite la finaliza-
ción por parte de un tercero de una conexión
TCP legítima, lo que en la práctica es un ata-
que de negación de servicio. El protocolo TCP
[RFC793] proporciona una conexión fiable en-
tre dos puntos cualesquiera conectados a In-
ternet y utiliza el denominado protocolo three
way handshake (de tres pasos) cuyo funciona-
miento básico es el siguiente:
1. El cliente (computador que desea iniciar la
comunicación) selecciona un número alea-
torio de secuencia (x, Figura 6), a continua-
ción activa el flag (etiqueta) de SYN en el
campo de opciones y finalmente envía un
segmento TCP al computador de destino.
2. El servidor (computador con el que se quie-
re establecer una comunicación) recibe la
petición y almacena el número de secuen-
cia x, elige un número aleatorio (Figura 6)
que usará como número de secuencia y ac-
tiva las etiquetas SYN y ACK. Finalmente
envía un segmento con el número de se-
cuencia elegido y con una confirmación del
valor recibido mas uno (ACK x+1, Figura 6).
3. El cliente almacena el número de secuencia
(Figura 6), activa la etiqueta de ACK y final-
mente envía la confirmación del número re-
cibido más uno (ACK x+1, Figura 6).
En uno de los parámetros de la conexión figura
el tamaño en bytes de la ventana (window) de
la conexión. Este parámetro permite regular la
comunicación y mejorar el rendimiento entre
41
α
Σ
β
Figura 6. Establecimiento de una conexión TCP (three
way handshake) [Ver03]
δφ
λ
origen y destino, ya que en vez de enviar una
ψθ
respuesta por cada paquete recibido la envía
por cada “ventana”. Este ataque se basa en la
posibilidad de que un tercero pueda enviar un
paquete con la etiqueta reset activada de for-
ϕ
ma que la conexión se cierre inmediatamente.
Una conexión TCP queda delimitada por una 4-
tupla que contiene la dirección IP de origen, el
número de puerto origen, la dirección IP de
destino y el número de puerto destino. Para
que un tercero pueda cerrar una conexión TCP
que no le pertenece debe enviar un paquete α
β
con las direcciones IP adecuadas, los números
de puertos correctos y la etiqueta de RST (re-
set) activada [Wat04]. El número de secuencia
Σ
es un campo de 32 bits [Ric98-1] [RFC793] con
δφ
lo que la probabilidad de descubrir este núme-
ro de secuencia suponiendo una distribución
aleatoria es de 1/2^32 (0,00000000023283064
365386962890625), pero según la especifica-
λ
ción del protocolo TCP se aceptará cualquier
número de secuencia que se encuentre en el
rango de la ventana (window) definida previa-
ψθ
mente al iniciarse la conexión. Debido a esta
característica en su definición crece enorme-
mente las posibilidad de enviar un número de
secuencia que se encuentre entre los permiti-
ϕ
dos por la ventana definida, ya que en lugar
de enviarlos todos (1, 2, 3…) únicamente se
enviará uno por cada posible rango de la ven-
tana.
El decifrar las direcciones IP de origen y desti-
no no supone ningún problema ya que por un α
β
lado se conoce la dirección destino, la del ser-
Σ
θ
 42

α vicio que se quiere atacar, y la dirección origen Clasificación de los ataques DDOS: Se pue-

Σ
β a la cual queremos evitar su acceso al servicio,
además los programas sniffing de red pueden
simplificar aún más esta tarea [WWW18]. Aho-
ra en cuanto los puertos de origen y destino, la
den clasificar los ataques de negación de ser-
vicio, y por lo tanto también sus soluciones, en
dos grupos (Figura 7):

δφ ξ realidad de los estudios [WWW16][WWW17]

[Wat04] muestra que los sistemas operativos
actuales utilizan sistemas predecibles. En el
A. Ataques directos. Son aquellos en que los
datagramas o peticiones recibidas por el
blanco del ataque provienen realmente de

λ
peor de los casos se tiene un número de 16 la dirección de origen especificada. Estos
bits (2^16 = 65535) lo que da una probabilidad ataques son realizados desde computado-
de 1/65535 (0,0000152587890625). Este tipo res satélite o esclavos (slaves) donde un

ψθ
de ataque es especialmente peligroso en co-
nexiones TCP de una larga duración que per-
miten el tiempo suficiente para que el atacante
consiga enviar el datagrama de datos adecua-
atacante ha conseguido acceso ilegal, ya
sea infectando mediante un virus/troyano
(MyDoom por ejemplo) o mediante un ex-
ploit o root kit, y los usa como plataforma de

ϕ
do. Los servicios más afectados actualmente
son los del protocolo de intercambio de rutas
entre routers BGP (Border gateway protocol) y
el servicio de nombres o DNS. Paul Watson
ataque remoto.
B. Ataques indirectos. En este grupo se en-
cuentran los distintos ataques que falsifican
la dirección de origen con el objetivo de es-

α [Wat04] muestra que en con una conexión

xDSL y un tamaño de ventana de 65535 bytes
es posible conseguir un paquete de estas ca-
conder su ubicación real y minimizar las po-
sibles medidas adoptadas por el blanco del
ataque, acá también se pueden incluir los

β
racterísticas cada 5 minutos. En el caso de una
Σ conexión T1 (1.54Mbps) el tiempo se reduce a
15 segundos. Obviamente en el contexto de
ataques de servicio distribuido (DDOS) se pue-
de observar que con un número relativamente
híbridos o mixtos, que presentan direccio-
nes de origen falsificadas en mayor o menor
grado. Contrariamente a lo que las estadís-
ticas de ataques DOS/DDOS muestran,
para este tipo de ataques sí que existe una

δφ pequeño de máquinas, 10 líneas ADSL básicas

suman 1.28Mbps, se puede conseguir el efecto
casi de forma inmediata.
solución en la actualidad que permite su
desactivación de forma efectiva, rápida y
sin un costo adicional de recursos.

λ
ψθ
ϕ
α
β
Figura 7. Ataques DOS/DDOS directos e indirectos [Ver03]

Σ
θ

Egress filtering: el filtro de tráfico de salida o
“egress filtering” [Hoe00] [BK02] [Sch03]
[UVS+03] [WWW19] tiene por objetivo el con-
trol de las direcciones IP usadas en la red don-
de esté aplicado. La idea consiste en que se
conoce de antemano el rango de direcciones
IP válidas en la red, así se puede poner un
filtro que compruebe todo el tráfico de salida y
elimine todos aquellos paquetes que no perte-
nezcan al rango de IP válido. El uso de este
simple tipo de filtrado de red por parte de ISP,
universidades y grandes organizaciones conec-
tadas a Internet eliminaría todos los ataques
de negación de servicio indirectos. Desgracia-
damente la permisividad o incompetencia de
los administradores lleva a que no solo millo-
nes de conexiones particulares carezcan de
este filtrado, sino que los mismos proveedores
o ISP muchas veces no lo implementan. Si
bien el filtro de salida no puede evitar que en la
red interna o local un computador falsee su di-
rección IP, evita el uso de las redes locales (en
caso de ser comprometidas por un atacante o
virus) como trampolín de ataques DOS/DDOS
a terceros. En este sentido se recomienda leer
los RFC:
1. RFC 2827: Network Ingress Filtering: De-
feating Denial of Service Attacks which em-
ploy IP Source Address Spoofing.
2. RFC 3013: Recommended Internet Service
Provider Security Services and Procedures.
Ingress filtering: El filtrado de tráfico de entra-
da o “ingress filtering” [CB94] [WWW19]
[RFC2267] asegura que todos los datagramas
Figura 8. Clases de direcciones IP en Internet [Ver03]
43
que entran a nuestra red provienen de direccio-
α
nes IP ruteables/reales o existentes. El protoco-
lo IP [RFC791] define su direccionamiento como
un conjunto de 32 bits subdivididos en conjuntos
o clases (Figura 8). Cada una de estas clases
Σ
β
presenta un rango reservado o privado o no ru-
teable, que se destina a redes IP que no se
encuentran directamente conectadas a Internet. δφ
λ
El objetivo de estos rangos reservados es el de
permitir su reutilización en todo tipo de redes
privadas de forma que no sea necesario el uso
ψθ
de direcciones únicas para redes que no deban
estar conectadas a Internet.
En los ataques DOS/DDOS indirectos las direc-
ciones de origen se falsifican de tal forma que
no sea posible la detección de las auténticas
fuentes del ataque. Una posibilidad básica con-
siste en usar como dirección de origen falsa la ϕ
dirección de cualquier nodo conectado a Inter-
net. Aquí el computador atacado responderá a
las peticiones de conexión o de cualquier tipo a
la dirección especificada por el atacante. La
α
otra posibilidad consiste en usar como direc-
ción falsa de origen los rangos privados (usual-
mente 127.0.01) de forma que el nodo atacado
simplemente genere tráfico local hacia él mis-
Σ
β
mo. De esta forma el filtrado de entrada sim-
plemente consiste en la comprobación de que
ninguna dirección de origen en nuestro tráfico δφ
λ
de entrada hace referencia a rangos privados
no ruteables. Al igual que con el filtrado de sali-
da, esta práctica no requiere de recursos ex-
ψθ
tras para su implementación y debería de ser
de uso obligado en todos los organismos, uni-
versidades e ISP.
ϕ
α
β
Σ
θ
 44
α Como conclusión, la combinación de uso de
Σ
β prácticas de filtrado de entrada y salida (in-
gress/outgress filtering) permite reducir la posi-
bilidad de un ataque DOS/DDOS indirecto. No
obstante en el caso de ataques de negación de
δφ ξ servicio distribuido directos, donde la dirección
de origen del datagrama es la dirección real
del ordenador, este tipo de filtros no proporcio-
λ
nan ningún tipo de reducción o minimización
de su impacto. Por lo tanto el problema real de
los ataques DOS/DDOS es el uso de ataques
ψθ
directos. En este tipo de ataques donde los orí-
genes de la negación de servicio están real-
mente identificados no se puede actualmente
realizar ningún tipo de contramedida que no
ϕ
sea local. De esta forma el ataque sigue con-
sumiendo todo el ancho de banda que puede
entre los orígenes y el blanco sin que pueda
ser evitado o mitigado. Se debe indicar que lo
α referente a Egress filtering e Ingress filtering
corresponde a la definición original, lo que ha
cambiado con los conceptos de DHCP y las IP
β
dinámicas.
Σ ESTRATEGIAS PARA MITIGAR UN DDOS EN
UNA ORGANIZACIÓN
δφ Estrategias a nivel superior:
1. Planificar para el ataque: Sin una planifi-
λ
cación apropiada, un ataque sostenido de
DDOS puede encontrar a una organización
sin los recursos y procedimientos necesa-
ψθ
rios para defenderse. Es esencial que los
procedimientos de respuesta sean claros y
que existan recursos como personal y tec-
nología disponibles para enfrentar con efi-
ϕ
cacia el ataque.
2. Definir los servicios críticos: Para una
mejor protección de la organización es im-
portante identificar las partes críticas de sus
α procesos en línea. En muchos casos, las
organizaciones utilizan la misma conexión a
Internet para variados propósitos tales
como tráfico de salida, entrada, email y trá-
Σ
θ β
fico de DNS. Cuando esta conexión está
bajo ataque, debe haber una prioridad cla-
ramente identificada de los servicios que
son esenciales para la organización. Una
vez que se decida esto, otras estrategias
técnicas de mitigación llegan a ser más fáci-
les de poner en ejecución.
3. Comunicarse con la ISP: En muchos casos
cuando un ataque sostenido al ancho de
banda alcanza a los servidores no será posi-
ble detener el ataque, pues los paquetes han
consumido todo el ancho disponible en la co-
nexión a la ISP. En este caso, el tener un
buen control de los canales de comunicacio-
nes es esencial. Los ataques producidos al
ancho de banda tendrán un impacto en la
red de la ISP, además, puesto que están
más cercanos al origen del ataque, están en
una mejor posición para filtrar el tráfico. La
ISP puede tener procedimientos para ocu-
parse del ataque, por lo cual entender estos
puede reducir enormemente el tiempo toma-
do para resistirlo. Tales mecanismos de pro-
tección deberían formar parte del procedi-
miento estándar [WWW4]. En Chile, los
proveedores de ISP tienen como medida a
tomar, cerrar la conexión, con lo que se hace
que el ataque sea 100% exitoso
4. Recursos: Los recursos necesarios para
soportar un ataque deben estar disponibles
para cuando se produzca un ataque. El an-
cho de banda, los servidores y el personal
técnico deben estar listos para ser utiliza-
dos para soportar la sobrecarga, para cuan-
do se presente la urgencia.
5. Procedimientos de respuesta: Los espe-
cialistas y los procedimientos deben estar
claramente definidos para dar solución al
incidente en la organización. La ISP debe
poder proporcionar la dirección en el me-
nor tiempo posible para responder a los
ataques DDOS y los procedimientos que
se necesitan deben ser seguidos por el
personal técnico de la organización para
asegurar una defensa oportuna. Los proce-

dimientos de escalada, incluyendo los de-
talles del contacto en la ISP, deben ser do-
cumentados, y si la protección de DDOS es
parte del procedimiento estándar, los tiem-
pos de reacción deben ser especificados.
El equipo técnico debe entender su res-
ponsabilidad en la detección y responder a
un ataque, y si se presenta la necesidad,
cómo informar la respuesta a la ISP. Cuan-
do el ataque DDOS se origina de muchos
frentes, es probable que la organización no
sea la única víctima y puede ser necesario
entrar en contacto con NHTCU5. Los es-
fuerzos de solución y de investigación del
ataque pueden ser rápidos entrando en
contacto con este organismo.
6. Seguro: Es recomendable adquirir un segu-
ro para protegerse de pérdidas producidas
a la organización como resultado de un ata-
que exitoso.
Estrategias técnicas:
1. Detección de ataques: Ciertos tipos de
ataques DDOS son fáciles de detectar, pues
hacen uso de protocolos inusuales o procu-
ran enviar paquetes específicos no estánda-
res a los sistemas. Los ataques que simulan
el comportamiento de usuarios legítimos ha-
ciendo peticiones repetidas al website o en-
viando un gran volumen de email pueden
ser mucho más difíciles de detectar. Tener
el conocimiento del comportamiento y del
tráfico normal de los usuarios puede ayudar
a identificar el tráfico anómalo. En algunos
casos los ataques pueden ser indistingui-
bles (a nivel de protocolo) del tráfico legíti-
mo y es importante que los mecanismos de
detección puedan descubrir estos ataques
analizando el volumen de conexiones por el
anfitrión y no simplemente confiando en la
autenticación. La red que supervisa las he-
5 National Hi-Tech Crime Unit [WWW9]
45
rramientas usadas actualmente dentro de la
α
red debe determinar si apoyan la detección
de patrones de tráfico anómalos. Los proce-
dimientos de supervisión secundarios de-
ben estar activos para detectar los ataques
Σ
β
que no son identificados por la herramienta
primaria de detección. Estos podrían anun-
ciar la disponibilidad del website en forma δφ
λ
periódica, o un servicio proporcionado por
la ISP o por otra organización. Es importan-
te que el mecanismo para la detección ele-
ψθ
gido pueda identificar y dar los detalles del
registro del ataque, tales como la dirección
IP del origen, del protocolo usado y de la
carga.
2. Filtros de entrada: El tráfico innecesario
destinado para la red debe ser filtrado en la
entrada como un asunto rutinario. Los me-
canismos de protección que previenen inun- ϕ
dación de SYN atacan al alcanzar los servi-
dores. Los productos comerciales abiertos y
los firewalls que ofrecen esta característica
pueden proporcionar un grado limitado de
α
protección contra ataques al ancho de ban-
da. Sin embargo, si los ataques tienen éxito
en la saturación del ancho de banda dispo-
nible entre la organización y la ISP, enton-
Σ
β
ces se niega la protección ofrecida por es-
tos dispositivos, y en este caso será
necesario entrar en contacto con la ISP δφ
λ
para controlar el ataque. Además, el SYN
que protege utilizando un firewall es a me-
nudo una función intensiva del procesador,
ψθ
especialmente cuando se está bajo un ata-
que de DDOS. Es importante asegurar que
el dispositivo tenga suficiente capacidad de
procesador y de memoria para funcionar
ϕ
con eficacia bajo carga pesada. Por estas
razones, las defensas de SYN se deben
realizar lo mas alejadas de los dispositivos
como sea posible, idealmente en la co-
nexión a la ISP.
α
β
Σ
θ
 46

α 3. Filtros en la ISP: Puesto que la ISP tiene cos. Si el website de las organizaciones es

Σ
β disponible un mayor ancho de banda y está
más cercano al origen del ataque, ella está
en una mejor posición para realizar la filtra-
ción del tráfico anómalo; los criterios para
crítico, entonces la adquisición del servicio
a un proveedor que ofrezca un gran ancho
de banda debe ser considerado, otros ser-
vicios menos críticos de Internet tales

δφ ξ filtrar se basan generalmente en:

a. Las direcciones del IP del origen y desti-

como email o ftp se podrían recibir local-
mente. Al diseñar defensas de la red, es
importante identificar embotellamientos en

λ
no del tráfico la arquitectura que podría ser explotados
b. El tipo de tráfico por los atacantes, en lo posible el DNS se-
cundario y los servidores de email se de-

ψθ
Es necesario que la ISP utilice las direccio-
nes del IP origen y destino para filtrar tráfi-
co, pero se necesita conocer el origen del
ataque. Las fuentes se deben identificar
ben recibir en diversos ISP y en diversas
localizaciones físicas. Hay muchos produc-
tos demandados para poder protegerse
contra los ataques mencionados en la Ta-

ϕ
por el mecanismo de detección y comuni-
carlo a la ISP, donde se conocen las distin-
tas direcciones del IP, la ISP debe poder
filtrar individualmente, pero pueden ocurrir
bla 3, pero pocos son capaces de hacerlo y
además de proporcionar disponibilidad a
los usuarios legítimos. Puesto que la dis-
ponibilidad es el principal objetivo de la

α ocasiones donde el tráfico se identifica

como originado en otra red (o aun un país
entero). Muchos ataques de DOS usan
prevención de un DDOS, un producto cuya
principal eficacia es bloquear el tráfico no
tendrá ninguna aplicación.

β
spoofed que son paquetes que no revelan
Σ la dirección real del anfitrión que ataca. En
estos casos, la ISP tendrá que comunicar- Tabla 2. Capacidades de protección de
DDOS de distintas Tecnologías de
se con los proveedores para bloquear el
tráfico de las redes. Un acuerdo con la ISP Seguridad 6

δφ tendrá que ser capaz de negar el tráfico de

un nodo completo de la red, en compara-
ción con direcciones individuales del IP, ya

λ
que este puede negar el acceso a los
usuarios legítimos. Las empresas de ISP
puede también realizar análisis basado en

ψθ
el tipo de tráfico, lo cual permite que se
autoricen ciertos tipos de tráfico mientras
que niega otros. Donde los servicios son
críticos a la organización y se han identifi-

ϕ
cado, la ISP puede dar prioridad a estos
servicios mientras que detienes otros.
4. Segmentación: Una vez que se identifi-
quen los servicios críticos, es posible se-

α gregar estos servicios de otros menos críti-

β
6 www.hostlibrary.com/node/print/420

Σ
θ

Un producto de DDOS identificaría una porción
del tráfico como ataque potencial y por lo tanto
para sofocar el tráfico de nuevo a un nivel ma-
nejable que proporciona disponibilidad cons-
tante.
CONCLUSIONES
1. Hoy en día en que el trabajo a través de
Internet se hace cada vez más intenso y
generalizado, aparecen nuevas formas de
aplicaciones distribuidas, ofreciendo ser-
vicios y prestaciones que agregan valor y
utilidad a la red. Estas aplicaciones exi-
gen que la red funcione cada vez en me-
jor forma, garantizando la heterogenei-
dad, transparencia e integridad de los
datos, es a través de estas aplicaciones
que se abren flancos de posibles ataques,
que aprovechando las nuevas ideas po-
nen a prueba la seguridad e integridad de
estas tareas.
2. La negación de servicio distribuido DDOS
es una de las más recientes formas de
ataque a estas aplicaciones, que aprove-
chando la esencia de la Internet ofrece
servicios distribuidos cada vez de mayor
calidad y presentan, a la vez, un nuevo
frente de trabajo que por su carácter distri-
buido abre flancos difíciles de prever, bási-
camente aprovechando elementos natura-
les en la red, tales como:
• Procesamiento paralelo, distribuido.
• Desconocimiento e incomprensión de
estos sistemas.
• Configuraciones en servidores que no
cubren todas las aristas.
• La forma de pensar de los desarrollado-
res no es ni distribuida ni paralela.
• Sistemas desarrollados bajo esquemas
secuenciales de funcionamiento.
• Sistemas incipientes en la detección y
recolección de basura distribuida.
• Supuestos de funcionamiento unidirec-
47
cional y desatendiéndose de las com-
α
plejidades que la masividad trae apare-
jada.
• Escasa concordancia de criterios, para
el diseño y configuración de las redes.
Σ
β
3. Es en este contexto que aparecen los ata-
ques DDOS, los cuales aprovechándose δφ
λ
de la creciente masividad en la red, se en-
mascaran en nodos con configuraciones
deficientes, para desarrollar ataques distri-
ψθ
buidos cada vez de mayor amplitud y efi-
cacia.
4. Los ataques DDOS han llegado para que-
darse y es probable que cada vez sean
más complicados y frecuentes.
5. Puesto que las ISP están haciendo poco
esfuerzo para proteger a sus clientes con-
tra tales ataques, es responsabilidad de ϕ
las propias organizaciones el proporcio-
narse la protección adecuada.
6. Las pequeñas organizaciones deben tomar
la amenaza DDOS seriamente y reconocer
α
que no es solo para grandes organizacio-
nes.
7. Las organizaciones deberían mirar a un
producto dedicado de prevención contra
Σ
β
DDOS para proveer de ellas la capacidad
no solamente de identificar y de bloquear
ataques, sino que también permitiendo a δφ
λ
los usuarios legítimos una acceso conti-
nuado.
8. Los ataques DDOS presentan una amena-
ψθ
za latente a las organizaciones, sobre todo
cuando la disponibilidad del servicio es
una función esencial.
9. Los firewall tradicionales y la seguridad
ϕ
sensible en el ingreso pueden proporcio-
nar un cierto grado de protección contra
ataques.
10. Más y más ataques están utilizando técni-
cas de flooding para saturar el ancho de
banda de las organizaciones digitales, ne-
gando el acceso de usuarios legítimos a
sus servicios.
αΣ
θ β
 48

α 11. Es difícil defenderse contra estos ataques, UAB = Universidad Autónoma de Barcelona.

Σ
β pero una planificación cuidadosa y con
una buena comunicación con la ISP, posi-
blemente proporcione un cierto nivel de
protección contra la pérdida de procesos
RFC = Request for coments, estándares de
Internet.
NHTCU = National Hi-Tech Crime Unit.

δφ ξ vitales para las organizaciones.

12. El problema es distribuido, obliga a que
la solución sea distribuida. No es posible
BIBLIOGRAFÍA

[Ver03] Gabriel Verdejo Álvarez, “Seguridad

λ
para pequeñas organizaciones, o para en redes IP”, [WWW4], 2003.
quienes pueden actuar sobre segmentos [Wat04] Paul A. Watson, “Sleeping in the win-
de la red resolver el problema. Los ata- dow: TCP Reset attacks”, CanSecWest,

ψθ
ques DDOS son un problema de toda la 2004.
red en su conjunto y seguramente la so- [Ley04] John Leyden, “DDos attacks go
lución definitiva aparecerá recién cuando through the roof”, The register [WWW23],
el problema sea atacado en forma distri- 2004.

ϕ
buida. [UVS+03] Umer Khan, Vitaly Osipov, Mike
Sweeney, Woody Weaver, “Cisco Security
ACRÓNIMOS USADOS EN EL DOCUMENTO Specialist’s Guide to PIX Firewall”, Syn-
gress Publishing Inc., 2003.

α IP
ICMP
= Protocolo de Internet.
= Protocolo de control de mensaje de
Internet.
[Sch03] Carla Schoeder, “Egress filtering:
Fencing the bad guys”, [WWW24], 2003.
[BK02] Seymour Bosworth, Michel E. Kabay,

β
UDP = Protocolo de datagrama de usuario. “Computer Security Handbook”, John
Σ TCP
OSI
= Protocolo de control de transmisión.
= Interconexión de sistemas abiertos.
Wiley & Sons Inc., 2002.
[Mah02] R. Mahajan et al., “Controlling high
P2P = Par en par. bandwidth aggregates in the network”,
DOS = Ataque de negación de servicio. ACM Computer Communications Review,

δφ DDOS

CERT
= Ataque de negación de servicio dis-
tribuido.
= Equipo responsable de emergencias
2002.
[Hoe00] David Hoelzer, “Intrussion Detection
FAQ: Why Egress Filtering Can Benefit

λ
de computador, Carnegie Melon Uni- Your Organization”, [WWW25], 2000.
versity. [CB94] William R. Cheswick and Steven M. Be-
SCO = Empresa propietaria de un sistema llovin, “Firewalls and Internet Security:

ψθ
operativo Unix. Repelling the Wily Hacker”, Addison-Wes-
IBM = International Business Machine. ley Publishing, 1994.
DNS = Servidor de nombres de dominio. [Far96] Dan Farmer, “Security survey of key
TFN = Tribe Flood Network. Internet hosts & various semirelevant re-

ϕ
ISP = Empresa proveedora de servicios de flections”, [WWW26], 1996.
Internet. [Ric98-1] W. Richard Stevens, “TCP/IP Illustra-
TLD = Top Level Domain. ted Volume 1: The protocols”, Addison-
SYN = Etiqueta de petición de conexión. Wessley, 1998.

α ACK
NACK
RST
ADSL
= Etiqueta de reconocimiento.
= Etiqueta de no reconocimiento.
= Reset.
= Línea de abonado digital asimétrica.
[Dit99] David Dittrich, “The DOS project’s TRI-
NOO distributed denial of service attack
tool”, [WWW27], 1999.
[Dit99-2] David Dittrich, “The STACHELDRAHT
Σ
θ β

distributed denial of service attack tool”,
[WWW28], 1999.
[Dit99-3] David Dittrich, “The TRIBE FLOOD
NETWORK distributed denial of service
attack tool”, [WWW29], 1999.
[DDL00] Sven Dietrich, David Dittrich, Neil Long,
“An analysis of the SHAFT distributed de-
nial of service tool”, [WWW51], 2000.
[Nor99] Stephen Northcutt, “Network Intrusion
Detection: An analyst’s handbook”, New
raiders, 1999.
[BT00] Jason Barlow, Woody Thrower, “TFN2K
– An analysis”, [WWW30], 2000.
[Car00] Curtis A. Carver et al., “A methodolo-
gy for using intelligent agents to provide
automated intrusion response”, IEEE
Workshop IAS’00 [WWW31], 2000.
[GP01] T. M. Gil, M. Poletto, ”MULTOPS: a data-
structure for bandwidth attack detection”,
10th Usenix Security Symposium, 2001.
[Obr01] Eric O’Brien, “Netbouncer: A practical
client-legitimacy-based DDOS defense
via ingress filtering”, [WWW32], 2001.
[VM01] John Viega, Gary McGraw, “Building
Secure Software: How to Avoid Security
Problems the Right Way”, Addison-Wess-
ley, 2001.
[Gib02] Steve Gibson, “DRDoS: Distributed Re-
flection Denial of Service”, [WWW33], 2002.
[KMR02] A. D. Keromytis, V. Misra, and D. Ru-
benstein, “SOS: Secure Overlay Servi-
ces.”, SIGCOMM, 2002.
[Des03] Neil Desai, “Intrusion prevention
systems: The next step in the evolution
of IDS”, [WWW35], 2003.
[Lar03] Bob Larson, “Introduction to Network
Security”, AINAC [WWW36], 2003.
[MP03] Jelena Mirkovic, Peter Reiher,“A taxo-
nomy of DDOS attacks and defense me-
chanisms”, ACM [WWW37], 2003.
[MP03-1] Jelena Mirkovic, Peter Reiher, “Attac-
king DDOS at the source”, [WWW37], 2003.
[MP03-2] Jelena Mirkovic, Peter Reiher, “Cha-
llenges and principles of DDOS defense”,
NCA [WWW37], 2003.
49
[Tan03] Mattew Tanase, “IP Spoofing: An in-
α
troduction”, [WWW38], 2003.
BIBLIOGRAFÍA WWW
Σ
β
[RFC ] http://www.ietf.org/rfc.html;
http://www.faqs.org/rfcs/index.html;
ftp://ftp.rediris.es/pub/rfc δφ
λ
[WWW1] http://www.sitios.uach.cl/caminosfor/
CristianSalazar/SIA/AI.html
[WWW2] http://spisa.act.uji.es/SPI/TEORIA/
ψθ
Temario/tema1/
[WWW3] http://www.dcc.uchile.cl/~hsalgado/
dos/siframes.htm
[WWW4] http://tau.uab.es/~gaby
[WWW5] http://www.stanford.edu/class/ee380/
Slides/000223/sld001.htm
[WWW6] http://www.cert.org
[WWW7] http://www.net-security.org ϕ
[WWW8] http://lucas.hispalinux.es/Tutoriales/
doc-tutorial-recomendaciones-seguridad/doc-
tutorial-recomendaciones-seguridad.html
[WWW9] www.nhtcu.org
α
[WWW10] http://www.securityfocus.com
[WWW11] http://standards.ieee.org/regauth/oui/
index.shtml
[WWW12] http://whatis.techtarget.com/defini-
Σ
β
tion/0,,sid9_gci212506,00.html
[WWW13] http://whatis.techtarget.com/defini-
tion/0,,sid9_gci213780,00.html δφ
λ
[WWW14] http://www.cisco.com/warp/public/
707/4.html
[WWW15] http://www.cs3-inc.com/
ψθ
mananet.html
[WWW16] http://staff.washington.edu/dittrich/
misc/ddos/
[WWW17] http://www.koc.net/koc_kurumsal/
ϕ
destek/signatures70/attacks/Snork_Attack.htm
[WWW18] http://www.anml.iu.edu/ddos/
types.html
[WWW19] http://www.cert.org/incident_notes/
IN-99-04.html
[WWW20] http://www.nic.cl/Board/2002-1/
ataques.html
αΣ
θ β
 50

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 51

αΣ
β
δφ
λ
ψθ
Los Roles y las Metodologías en la Ingeniería de
ϕ
Software Orientada a Agentes α
Roles and Methodologies in AgentOriented Software Engineering

Mailyn Moreno Espino; Alejandro Rosete Suárez; Alfredo Simón

Σ
β
Cuevas; Renier Valdés González; Exiquio Leyva Pérez; Raisa Socorro
Llanes; Joaquín Pina Amargós; Alexander García Fernández δφ
λ
ψθ
ϕ
1 Centro de Estudio de Ingeniería de Sistemas (CEIS), Instituto Superior “José Antonio Echeverría” (CUJAE), Mariano 19390, Habana, Cuba, {my, α
β
rosete, rvaldes, asimon, exiquio, jpina, raisa, agarcíaf}@ceis.cujae.edu.cu

Σ
θ
 52

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 53

ABSTRACT
α
Software engineering has been influenced by different programming paradigms such as: structured
analysis, object orientation, etc. Object orientation has a great acceptance now due to its advantages
and the standardization that has allowed RUP as a development process and UML as a modeling
Σ
β
language. These standards face a big challenge now due to new distributed paradigms such as Web
Services and agents. Agent-orientation is a very promising paradigm for software engineering, especially
for the software that must operate in complex and distributed environments. One of the big challenges δφ
λ
for the development of this technology is the absence of one standard methodology to use. In this work
we present a comparative study of nine agent-oriented methodologies. Also, the roles of persons for
agent-oriented software engineering are analyzed. New roles of persons are proposed in order to deliver

ψθ
agent-oriented products and some recommendations for using the roles of RUP in agent process are
also presented.

RESUMEN

La ingeniería de software ha transitado por diferentes etapas marcadas por los paradigmas de progra-
mación como el estructurado y el orientado a objeto. Este último tiene gran aceptación hoy por las
facilidades que brinda y por la estandarización que ha permitido RUP como proceso de desarrollo y UML ϕ
como lenguaje de modelado. Estos estándares enfrentan grandes retos debido a los nuevos paradigmas
distribuidos como son los Servicios Web y los agentes. La orientación a agentes es un paradigma muy
prometedor para la ingeniería de software, especialmente para software que debe operar en ambientes
complejos y distribuidos. Uno de los grandes retos para el desarrollo de esta tecnología es la no
α
existencia de estándares metodológicos a emplear para su desarrollo. En este trabajo se realiza un
estudio comparativo de nueve metodologías orientadas a agentes. Además, se analizan los roles de
personas en la ingeniería de software orientada a agentes y se proponen algunos roles no presentes en
RUP que parecen necesarios con este nuevo paradigma. También se presentan algunas recomendacio-
Σ
β
nes para adaptar los roles de RUP a esta nuevo enfoque.

INTRODUCCIÓN
La ingeniería de software ha transitado por di-
ferentes etapas, marcadas por los paradigmas
de programación, por ejemplo el enfoque es-
tructurado y el enfoque orientado a objetos
(OO). Este último tiene gran aceptación por las
facilidades que brinda y por la estandarización
ganada con el lenguaje de modelado UML y el
Proceso Unificado de desarrollo (RUP) [1]. Hoy
existen grandes retos para estos estándares,
provocados por las nuevas tecnologías distri-
buidas entre los que están los Servicios Web y
los agentes. Los agentes son entidades com-
δφ
putacionales que se diferencian de los objetos
en varios aspectos entre los que se destacan
λ
ψθ
la autonomía, la proactividad y el carácter so-
cial. Los agentes encapsulan además de los
datos y los métodos, los mecanismos de acti-
vación de los métodos y su control interno. Con
esta nueva tecnología se han desarrollado apli-
caciones exitosas que han influido en su acep-
tación. Sin embargo, un reto para su desarrollo
es la no existencia de estándares metodológi- ϕ
α
cos. Las metodologías orientadas a objetos
(OO) no logran cubrir las necesidades de desa-
rrollo de estos nuevos sistemas [2], debido a
que un objeto no es autónomo, ni proactivo.

Σ
θ β
 54

α Como vía para enfrentar las limitaciones de las da con los antecedentes, lenguaje de modela-

Σ
β metodologías OO se han hecho varias pro-
puestas de metodologías orientadas a agentes:
TROPOS [3], MaSE [4, 5], MESSAGE [6, 7],
Ingenias [8], Zeus [9], Prometheus [10, 11],
do y las herramientas CASE, y la tercera parte
relacionada con lo que se modela, es decir, si
modelan el ambiente, la inteligencia y las rela-
ciones entre los agentes. Los resultados se

δφ ξ GAIA [12], MAS-CommonsKADS [13], Vowel

Engineering [14], entre otras. En este trabajo
se comparan las nueve metodologías anterior-
muestran en la Tabla 1.

En la primera parte de la tabla se presentan

λ
mente mencionadas. Además, como la orienta- las etapas del ciclo de vida que cubren. La
ción a agentes introduce nuevos conceptos y palabra “Sí” significa que sí cubre la etapa,
tareas a desarrollar que no están incluidas en “Sí-” que propone la etapa pero no la desa-

ψθ
RUP, se proponen nuevos roles del equipo de
proyecto para el desarrollo de sistemas multi-
agentes y nuevas habilidades en otros roles.
rrolla y “No” no la cubre. En la segunda par-
te de la tabla, referida al leguaje de modela-
do y antecedentes, tiene la nomenclatura
siguiente. En el Lenguaje de Modelado se

ϕ
COMPARACIÓN DE METODOLOGÍAS pone el nombre de lenguaje que utiliza. Si la
metodología no propone un lenguaje deter-
Para comparar las nueve metodologías ante- minado se pone un “0” que debe entenderse
riormente mencionadas se seleccionó un grupo como Neutral. Para el aspecto de Herra-

α de aspectos que se dividieron en tres partes: la

primera que tiene que ver con las etapas del
ciclo de vida que cubren, la segunda relaciona-
mienta Case: “Sí” si tiene y el “No” lo con-
trario a esto. En el aspecto de anteceden-
tes: “OO” se usa cuando tiene antecedentes

Σ
β Metodología
Tabla 1. Comparación de metodologías

δφ
MESSAGE/UML

Common KADS

Prometheus
Engineering
INGENIAS
TROPOS

MaSE

Vowel

ZEUS
MAS-
GAIA

λ
Aspectos
Etapas del ciclo de vida

Requisitos Sí No Sí No No No No No Sí

ψθ
Análisis Sí Sí Sí Sí Sí No Sí Sí Sí
Diseño Sí Sí Sí Sí Sí No Si Sí Sí
Implementación Sí No Sí- No No No Sí- Si- No
Prueba No No No No No No No No No

Leguajes de Modelado, Herramienta CASE y Antecedentes (Origen)

ϕ Lenguaje de
Modelado
CASE
Origen
UML/AUML
No
IR
0
No
OO*
UML+OCL UML/AUML
Sí
OO
No
OO
AUML
Sí
OO
0
No
No
UML
Sí
IC
UML
Sí
*
UML/AUML
Sí
*

α Modelado de aspectos importantes

Ambiente
Inteligencia
No
Sí
Sí
Sí
Sí
?
No
?
Sí
?
Sí
Sí
No
Sí
No
?
Sí
Sí

β
Interacción Sí Sí Sí Sí Sí Sí Sí Sí Sí

Σ
θ

en la orientación a objetos, “IR” en la inge-
niería de requisitos, “IC” en la ingeniería del
conocimiento. Se usa “*”cuando sus antece-
dentes son una mezclas de paradigmas y
“No” para cuando no tiene antecedente tan
directos de los paradigmas anteriormente
planteados. En la tercera parte de la tabla
que tiene que ver con los aspectos que mo-
dela cada metodología, se utiliza como no-
menclatura: “Sí” significa que tiene en cuen-
ta el modelado de este aspecto, “No” para
representar que no lo tiene en cuenta y “?”
cuando modela parcialmente este aspecto
pero no del todo.
Como se puede ver en la Tabla 1, solo tres
metodologías proponen cómo tratar la etapa
de requisitos: TROPOS, MaSE y Prome-
theus. Las dos últimas incluyeron esta etapa
en extensiones de ellas. La mayoría de las
metodologías cubren las etapas de análisis y
diseño, con la excepción de Vowel Enginee-
ring que no tiene definida ninguna etapa. El
resto de las etapas no son consideradas en
detalle. TROPOS sí incluye la implementa-
ción y MaSE, MAS-Common KADS y ZEUS la
proponen pero no la desarrollan [15]. MAS-
Common KADS propone pequeñas pincela-
das del proceso de implantación.
En cuanto al lenguaje de modelado algunas
utilizan UML, tal es el caso de MESSAGE,
MAS-Common KADS y ZEUS. TROPOS, Pro-
metheus y MaSE también emplean UML,
pero las dos primeras utilizan AUML para
complementar algunos de sus artefactos y la
segunda emplea una combinación con OCL
[9]. En el caso de GAIA y Vowel Engineering,
no proponen el uso de un lenguaje de mode-
lado determinado. No obstante en la mayoría
se incluyen diagramas propios. En cuanto a
la existencia de herramientas de desarrollo
asociadas debe decirse que no es un aspec-
to generalizado. MaSE incorpora la herra-
mienta “agentTool” para facilitar el desarrollo,
55
aunque no cubre todas las etapas. Prome-
α
theus también tiene herramientas pero tam-
poco cubren todo el proceso, estas son JACK
Development Environment y Prometheus De-
sign Tool. ZEUS e INGENIAS son otras que
Σ
β
tienen herramienta de desarrollo, en el pri-
mer caso se llama ZEUS y en el segundo
IDE. En MAS-Common KADS existe una he- δφ
λ
rramienta conocida como AgentEditor, mien-
tras que en TROPOS se comenta que se está
en fase de desarrollo de una herramienta que
ψθ
sustente todo el proceso. Finalmente MES-
SAGE propone una guía de recomendaciones
de herramientas útiles para MESSAGE, bási-
camente se propone hacer uso de herramien-
tas para UML como Rational Rose o la herra-
mienta metacase MetaEdit+. En cuanto a los
orígenes de la propuesta, la mayoría toma
elementos de la orientación a objetos (MES- ϕ
SAGE, MaSE e INGENIAS). En el caso de
GAIA los autores toman muchos elementos
de la metodología FUSION, aunque hacen
cambios radicales. En el caso de TROPOS
α
toma elementos de la ingeniería de requisitos
(método i*). MAS-Common KADS deviene de
la ingeniería de conocimiento (metodología
Common KADS). ZEUS y Prometheus vienen
Σ
β
de una mezcla de varios paradigmas [16].
Vowel Engineering no tiene una ascendencia
clara. δφ
λ
En cuanto al modelado es de destacar que
todas las metodologías estudiadas modelan
ψθ
la interacción entre los agentes de una forma
u otra. La inteligencia todos las modelan,
aunque hay casos en que lo asumen con una
inteligencia limitada (MESSAGE, MaSE,
ϕ
ZEUS e INGENIAS). El aspecto que no todas
modelan es el ambiente alrededor del siste-
ma, lo cual es importante ya que sin esto se
supone que los sistemas no son dinámicos y
aparentemente serán cerrados. Dentro de las
metodologías que sí modelan el ambiente es-
tán GAIA, MaSE, INGENIAS, Vowel Enginee-
ring y Prometheus.
αΣ
θ β
 56

α ROLES EN PROCESO DE DESARROLLO DE poner la importancia relativa de cada papel, y

Σ
β UN SISTEMA MULTIAGENTES

Los roles en el proceso de desarrollo de soft-

ware son importantes para la especialización y
proponer el orden de las iteraciones de desa-
rrollo según esta decisión anterior. En la etapa
de Análisis, puede adquirir la responsabilidad
de definir la estructura organizacional o la co-

δφ ξ para mejorar la eficacia en la distribución de

las tareas entre los miembro del equipo. Como
se puede ver en la sección anterior, las meto-
munidad del agente. Esta decisión está muy
estrechamente relacionada a la decisión de or-
ganización de los subsistemas (paquetes, cla-

λ
dologías orientadas a agentes tienen varias ta- se más importantes, etc.) pero también necesi-
reas que no están presentes en RUP [1, 17], ta una calificación adicional en dirección y
tal es el caso de modelar la inteligencia, mode- patrones organizacionales humanos (como se

ψθ
lar la interacción entre los agentes, entre otros.
Esto trae como consecuencia que dentro de las
etapas del proceso de desarrollo aparezcan
nuevas tareas y esto trae consigo nuevos roles
sugiere en [12]). Debe notarse que en la es-
tructura organizacional de la comunidad de
agentes influyen aspectos de diseño y también
la organización real. Esta relación entre agen-

ϕ
dentro del equipo de proyecto o nuevas habili-
dades que deben tener los roles propuesto por
RUP. Aquí se presentan algunas propuestas
para ajustar los roles de las personas para el
tes y subsistemas está muy cerca del enfoque
de TROPOS [3]. Este rol también debe encar-
garse de asignar los papeles a los agentes.

α desarrollo de sistemas multiagentes. Se optó,

siempre que fuera posible, por modificar las
responsabilidades de los roles de RUP y adqui-
Ingeniero de componentes: Este rol adquiere la
tarea de especificación de los papeles, cuando
el análisis se dirige al nivel más alto.

β
rir nuevas tareas necesarias. Cuando esto no
Σ es posible (debido a la naturaleza diferente de
las tareas en los roles de RUP y las nuevas
Ingeniero de la interacción: Este rol es nuevo,
no está en RUP. Aparece como consecuencia
necesidades) se proponen nuevos roles. Los de la complejidad de la interacción entre los
roles de RUP que se consideran que no cam- agentes. Este rol debe encargarse de definir la

δφ bian mucho no se discutirán. Se ha preferido

usar el término “papeles” en este trabajo para
llamar a lo que es llamado también “roles” en
conversación, ontologías a usar, normas a ser
respetadas, etc. La complejidad de esta tarea
se ha estudiado en [18].

λ
las metodologías de agentes, para evitar con-
fusiones. Ingeniero de conocimiento: Este rol es nuevo.
Aparece como consecuencia de la complejidad

ψθ
Analista sistema: Este rol debe extender sus
tareas para identificar los papeles preliminares
y asociarlos con los Casos del Uso. Esta tarea
incluye la identificación preliminar del grado de
del control interno en cada agente y la necesi-
dad de operar con flexibilidad. Este rol es res-
ponsable de definir las habilidades de inferencia
de cada agente e implementar el mecanismo de

ϕ
autonomía y la actitud reactiva/proactiva. Esto
implica que el diagrama de Caso del Uso pue-
da modificarse de alguna manera para identifi-
car claramente qué papel es responsable de
razonamiento acorde al nivel de reactividad/pro-
actividad definido. Debe cooperar estrechamen-
te con el Ingeniero de la Interacción para definir
las ontologías a ser usadas en el razonamiento,

α cada Caso del Uso.

Arquitecto: Este rol en la etapa de Análisis de

Requisitos puede adquirir la responsabilidad de
acorde con la comunicación.

Integrador de sistema: Este rol puede desapa-

recer, ya que la naturaleza de su tarea es me-
Σ
θ β

nos necesaria, por la flexible integración im-
puesta por la orientación a agentes. Podría
usarse si la implementación interna de los
agentes implica todavía complejos y distribui-
dos subsistemas que utilizan el paradigma
orientado a objetos u otro (debido a la mezcla
natural de paradigmas).
Ingeniero de prueba: Este rol puede asumir la
preparación de una fase de prueba más com-
pleja, incluyendo una prueba postdespliegue
(prueba tardía) que garantice que el sistema no
se va de control.
Ingeniero de prueba de integración: Este papel
puede adquirir la responsabilidad de hacer prue-
bas de la capacidad de colaboración de agentes
y la prueba de cambios organizacionales.
Ingeniero de prueba de agentes: Este rol es
nuevo. Aparece como consecuencia de la natu-
raleza más compleja de la conducta del agen-
te. Es responsable de hacer pruebas de agen-
tes por separado para probar la autonomía,
reactividad y conducta proactiva.
CONCLUSIONES
La orientación a agente es muy reciente y debe
revolucionar el desarrollo de software [2]. Esta
revolución ha generado un nuevo campo de in-
vestigación, como es la ingeniería de software
orientada a agentes. Hay una gran cantidad de
metodologías orientadas a agentes y no existe
una estandarización en este sentido ni en los
lenguajes de modelado, aunque es de destacar
que recientemente OMG ha comenzado a dar
pasos hacia una unificación [19]. Casi todas
las metodologías proponen y desarrollan las
etapas de análisis y diseño, y dejan las demás
etapas sin definir una forma clara para su de-
sarrollo. Es importante destacar que ninguna
de las metodologías estudiadas cubre la etapa
de prueba, siendo esta una etapa muy impor-
tante en el ciclo de vida de desarrollo de cual-
57
quier software y en especial de los sistemas
α
orientados a agente, debido a su complejidad,
dinamismo y carácter distribuido. Un aspecto
relevante es que varias metodologías obvian la
modelación del ambiente que rodea al sistema.
Σ
β
En este trabajo se argumenta la necesidad de
cambios en los roles de las personas dentro
del desarrollo del software con respecto a los δφ
λ
roles de RUP que incluyen la introducción de
nuevos roles (como el ingeniero de conoci-
miento y de interacción), y la modificación de
ψθ
las responsabilidades de otros (por ejemplo: el
arquitecto y el ingeniero de pruebas).
BIBLIOGRAFÍA
[1] Ivar Jacobson, G.B., James Rumbaugh, El
Proceso Unificado de Desarrollo de Soft-
ware. 2000, Madrid, Pearson Educación. ϕ
[2] F. Zambonelli, A.O., Challenges and Re-
search Directions in Agent-Oriented Soft-
ware Engineering. Autonomous Agents
and Multi-Agent Systems, 2004(9). 253-
α
283.
[3] Bresciani P., P.A., Giorgini P., Giunchiglia
F., Mylopoulos J., Tropos: An Agent-Orien-
ted Software Development Methodology.
Σ
β
Autonomous Agents and Multi-Agent Sys-
temas, 2004. 8. 203-236.
[4] Deloach, S. Multiagent Systems Enginee- δφ
λ
ring of Organization-based Multiagent
Systems. en 4th Intenacional Workshop
on Software Engineering for Large-Scale
ψθ
Multi-Agents Systems SELMAS´05. 2005.
St. Louis.
[5] S. Deloach, M.W., C. Sparkman, Multia-
gent Systems Engineering. Internacional
ϕ
Journal of Engineering and Knowledge
Engineering, 2001. 11(3). 231-258.
[6] R. Evans, B.E., P. Kearney, J. Stark, G.
Carie, F. Garijo, J. Gomez, F. Leal, P.
Chainho, P. Massonet, MESSAGE: Metho-
dology for Engineering Systems of Soft-
ware Agents. 2001, EURESCOM Partici-
pants in P907.
αΣ
θ β
 58

α [7] Caire G., C.W., Garijo F., Gomez J., Pa- [13] C. Iglesias, M.G., J. C. González, J. R. Ve-

Σ
β von J., Leal F., Chainho P., Kearney P,
Stark J., Evans R., Massonet P, Agent
Oriented Analysis using MESSAGE/UML,
en Agent-Oriented Software Engineering
lasco, Analysis and design of multiagent
systems using MAS-CommonKADS, Intelli-
gent Agents IV LNA1, 1998. 1365.
[14] MAGMA, MAGMA Research Group, Vowel

δφ ξ AOSE´01. 2001.
[8] Jorge J. Gómez Sanz, R.F. The INGENIAS
Methodology. en Fourth Iberoamerican
Engineering. 2005.
[15] K. H. Dam, M.W. Comparing Agent-Orien-
ted Methodologies. en Agent-Oriented In-

λ
Workshop on Multi-Agent Systems Ibera- formation Systems AOIS´03. 2003.
gents 2002. 2002. [16] J. Sudeikat, L.B., A. Pokahr, W. Lamers-
[9] Julián V., B.V.J., Estudio de métodos de dorf. Evaluation of agent-Oriented Soft-

ψθ
desarrollo de sistemas multiagente. Revis-
ta Iberoamericana de Inteligencia Artificial,
2003. 18. 65-80.
[10] L. Padgham, M.W. Prometheus: A Metho-
ware Methodologies - Examination of the
Gap Betweem Modeling and Platform en
International Workshop on Agent-Oriented
Software Engineering, AOSE´04. 2004.

ϕ
dology for Developing Inteligent Agents. en
Firts Internacional Joint Conference on Au-
tonomous and Multi-Agent Systems AA-
MAS. 2002. Bologna, Italy.
[17] Crain, A., Understanding RUP Roles.
Abril, 2005, Rational Software: The Ratio-
nal edge.
[18] H. V. D. Parunak, S.B., M. Fielsicher, J.

α [11] G. Cysneiros, A.Z. Refining Prometheus

Methodology with i*. en 3rd International
Workshop on Agent-Oriented Methodolo-
Odell. A preliminary taxonomy of Multi-
Agent Interaction. en Agent-Oriented
Software Engineering (AOSE IV). 2004,
Springer.

β
gies, OOPSLA 2004. 2004. Canada.
Σ [12] Zambonelli F., J.N.y.W.M., Developing
Multiagent System: The Gaia Methodolo-
[19] OMG, Request for Information on Mode-
ling Agent-based Systems. 25 de agosto
gy. ACM Transactions on Software Engi- 2004, Analysis and Design Task Force,
neering and Methodology., 2003. 12(3). Object Management Group (OMG).

δφ 317-370.

λ
ψθ
ϕ
αΣ
θ β
 59

αΣ
β
δφ
λ
ψθ
Sistema de Visión Activa Basado en Lógica Difusa ϕ
para Focalización
Active Vision System Using Fuzzy Logic Capable of Focalization α
Homero Latorre; Juan Luis Castro; José M Benítez; Miguel García Σ
β
δφ
λ
ψθ
ϕ
1
2
3
Dept. Informática, Universidad Tecnológica Metropolitana Utem – Chile, hlatorre@utem.cl
Decsai, Universidad de Granada Ugr – España, castro@decsai.ugr.es
Decsai, Universidad de Granada Ugr – España, j.m.benitez@decsai.ugr.es α
β
4 Decsai, Universidad de Granada Ugr – España, mgs@decsai.ugr.es

Σ
θ
 60

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β

ABSTRACT
We formulate a model which integrates fuzzy logic with traditional active vision, in order to develop an
active vision system based on fuzzy logic and capable of focusing on a pointlike object located in the
actual visual world.
RESUMEN
Este trabajo de investigación esta enfocado hacia la formulación de un modelo de visión que integre la lógica
difusa y la visión activa tradicional a fin de desarrollar un sistema de visión activa basado en la lógica difusa
que permita realizar fijación visual, es decir, focalización sobre un objeto puntual en el mundo visual real.
INTRODUCCIÓN
En los sistemas de visión activa, el problema
principal está en la formulación de un sistema de
control cuya planta principal sea la visión y los
cálculos de posición o ubicación relativa (error
posición) así como los cálculos de variación o de
definición de las características propias de la
imagen (iluminación, bordes, forma, característi-
cas); se realicen sobre el plano visual, usando la
relación de coordenadas imagen v/s coordena-
das del mundo visual y la retroalimentación será
dirigida hacia los actuadores (plataforma, moto-
res) que realizan el movimiento de las cámaras.
Para los sistemas de visión difusa y activa, se
propone un modelo que contenga el análisis
fuzzy dinámico de la visión y de la dinámica
fuzzy del mundo visual, en relación con el análi-
sis dinámico de los sistemas del movimiento difu-
so del sistema de control motoocular.
Se analizan los sistemas de visión activa binocu-
lares en su formulación tradicional Crisp tradicio-
nales, se analiza la lógica difusa y su aplicación
al procesamiento de imágenes en la modalidad
estática, buscando las interacciones que permi-
tan incorporar la lógica difusa a un sistema de
visión activa binocular y dinámica que sea capaz
de percibir a los objetos en el mundo visual real y
focalizar la atención sobre uno de ellos así selec-
cionado.
61
α
Σ
β
δφ
λ
UBICACIÓN DIFUSA DE UN OBJETO ψθ
ϕ
En un sistema de visión activa binocular con ca-
pacidad de movimiento de vergencia se debe de-
tectar la posición de un objeto relativo a la ubica-
ción de cada una de las cámaras (ojos), y a la
vez, este movimiento de las cámaras genera un
desplazamiento de la imagen en relación al pla-
no Imagen de cada cámara. α
β
En el modelo de visión especificado se debe con-
siderar la existencia del plano visual (ubicado en Σ
el sensor) y la referencia al plano visión que co-
rresponde al mundo real. Los sistemas de visión
activa deben usar sensores de visión (cámaras)
que tengan la cualidad de registrar sus variacio-
nes de visión y posición δφ
λ
Estos sensores de visión necesitan tener un
campo amplio de visión, que cubra todo la esce-
ψθ
na visual y a su vez una buena resolución visual,
que permita que incluya una zona central de alta
resolución (la fovea) y una zona circundante de
baja resolución en las áreas periféricas al centro.
De este modo se tiene una estructura en la cual
su área central permitirá la ubicación, discrimina-
ción y reconocimiento de objetos, rodeada de
una zona de baja resolución que contiene los
ϕ
objetos detectados y su ubicación como imagen
para ser analizados al centrar el interés por algu-
nos de ellos. αΣ
θ β
 62

α El área focal considerada para el reconocimiento

Σ
β de ubicación de objetos en el mundo visual, co-
rresponderá al área definida por la “elipse mejor
ajustada” al área del objeto en su representación
de imagen digital.

δφ ξ
λ Figura 1. Plano imagen y centro focal

Al utilizar alguna estrategia para reconocer la po-

ψθ sición de algún objeto de interés en el campo

visual y mover el área de alta resolución para
enfocar sobre ese objeto, desde la periferia al
centro visual.
Figura 3. Objeto y contorno encerrado

ϕ Al utilizar un tipo de ojo, basado en cámaras de

visión de resolución plana (x, y), se define como
Para moverse desde la periferia hacia el centro
visual, será necesario establecer decisiones so-
bre los siguientes parámetros visuales

α
centro focal, el punto de coordenadas (xo, yo) del
plano de visión (imagen), que corresponde al
campo visión X/2, Y/2.
Elegir un método para decidir cuál objeto situado
en la periferia será focalizado al siguiente movi-
miento. Utilizar un mecanismo de movimiento rá-

β El centro focal XOA, XOB, corresponde a los pun- pido de desplazamiento Gaze, para focalizar so-
Σ tos extremos A y B, que definen el trazo o línea
epirolar que define el “Plano de visión horizontal”
bre el objeto seleccionado desde el mundo visual

para calibración cero. De este modo, existen dos cambios: de posición,

δφ
de movimiento, que deben ser detectados por el
sistema para los casos elementales que son: (a)
un objeto estático y movimiento de las cámaras;
(b) para una posición fija de las cámaras y un

λ objeto en movimiento; (c) un objeto en movimien-

to más movimiento de las cámaras.

ψθ
El sistema de visión activa estará descrito por el
siguiente modelo:

Figura 2. Plano visual y ubicación objetos

ϕ Cada objeto tiene sus propias coordenadas exo-

céntricas, que reflejan su estado respecto al ob-
servador; centro del sistema de cámaras (senso-

α res) en este caso se define el área focal, o área

de alta resolución aquella que corresponde al
área cubierta por el objeto ubicado en centro fo-

β
cal, del plano de visión. Figura 4. Modelo sistema visión activa Fuzzy

Σ
θ
 63

Este sistema de visión activa debe ser capaz

α
de realizar todo el procesamiento visual de las
imágenes vistas del mundo real, antes y des-
pués de un movimiento; el problema a formular
es: Vistos varios objetos en el mundo visual
ΔPm= {Pm / Pr - Pv /}
(3)
Σ
β
real se deberá conocer la ubicación, posición y
orientación de cada uno de ellos y controlar la
ejecución de los movimientos que focalizan; fi-
El problema se puede formular desde una vi-
sión del mundo real, conocer la ubicación (po-
sición y orientación) de un objeto y moverse en δφ
λ
jen la visión sobre un objeto seleccionado se- el mundo visual para seleccionar otro objeto y
gún la percepción de este objeto en relación a conocer de él, la ubicación donde se encuentra
toda la escena visual. cada objeto en el mundo visual; y si un objeto

Rotación de los ojos

(cámaras) para ubicar un
objeto en punto de fijación
se mueve o cambia de posición, se deberá en-
contrar su nueva ubicación.

La formulación matemática será:

ψθ
→ → →
(4)
ϕ
α
Cambio de los ángulo de la base
para la translación del punto de
fijación hacia la línea focal
Donde: Prj: Vector ubicación en el mundo
visual

β
Pmj: Vector de movimiento en el plano Imagen

Figura 5. Movimientos para focalización

Pvj: Vector ubicación del objeto percibido en
los planos Imagen (x, y) y plano visual (x, y, z).
Σ
Los vectores ubicación están formados por sus
A partir de esto, se debe decidir en qué grado

δφ
componentes:
la visión está enfocada sobre el objeto pro-
puesto y cómo debería moverse la visión para P = [P (x, y, z), V (x, y, z), O (x, y, z), I (x, y, z)]
focalizar sobre otro objeto seleccionado desde posición velocidad orientación segmentación (5)

λ
el mundo real.
→ →
Donde: (6)
Este sistema, así descrito, se puede especifi-

ψθ
car por las siguientes funciones: La ecuación representa el objeto de la percep-
ción visual para controlar un proceso de ubica-
ción de los objetos en el mundo visual, según
(1) las restricciones de la visión y de segmenta-

ϕ
ción posible al separar un objeto claramente
distinguible en el mundo visual.
Pr= {Xr, Vr, Cor}
Pv: Ubicación entre el plano visual Las restricciones impuestas por la visión, la

(2)
plataforma, los objetos y el mundo visual son:

1) Los movimientos motooculares son discretos α

β
y los desplazamientos angulares son paso a
Σ
θ
 64

α paso y la aceleración es proporcional a la de objetos (objetos que se incorporan o salen

Σ
β suma del largo de la secuencia discreta de mo-
vimiento.

| | Wm | | ≤ Step-paso θ motor posición

del área visual pero que alcanzan a ser distin-
guibles en ubicación posición y orientación)
desde el mundo visual hacia el plano visual.

δφ ξ | | αm | | =Σ | | Wm | | velocidad angular.

2) Si la velocidad angular de movimiento es

8) Los movimientos de Saccadic (cambios
bruscos de fijación) trasladan el plano visual
desde un área visual hacia otra, sin percibir las

λ
mayor a la capacidad visual de captura de imá- áreas visuales intermedias, creando toda una
genes en movimiento, la definición de la ubica- nueva área visual obtenida desde una nueva
ción y posición del objeto será indistinguible y área del mundo visual real.

ψθ
tenderán a un valor nulo.

Si | | αm | | > Ips ⇒ Pr ->0

ϕ
3) El movimiento de la plataforma de visión
siempre cambiará el campo visual efectivo, in-
corporando o sacando objetos desde las áreas
laterales de la visión.

α (7)

Figura 6. Movimientos visuales

Σ
β 4) El sentido del movimiento tiene directa rela-
ción con la incorporación de objetos en área
visual lateral hacia el movimiento y el sacar
objetos desde el área visual lateral opuesta al
La información obtenida desde la imagen se debe
procesar e ingresar al sistema de visión para con-

δφ movimiento. trolar el sistema de movimiento motoocular.

5) La plataforma de visión cubre un área visual Una opción sería utilizar un sistema de control
específica que dependerá de la profundidad vi- difuso similar a los propuestos en la literatura y

λ sual y del ángulo de movimiento y comprende utilizados para controlar plataformas o manipu-
además los cuatro cuadrantes visuales para un ladores robóticos, pero en este caso orientado
punto de focalización especifico al control motoocular basado en el paradigma

ψθ
de control de visión utilizando retroalimenta-
(8) ción de movimientos, que proporcionen un ade-
cuado movimiento en la vecindad del punto-
6) Los movimientos de vergencia (convergen- objeto visual, con lo cual el sistema de

ϕ cia y divergencia) mantienen el área y los pun- percepción determina qué tipos de movimien-
tos de fijación y conservan la cantidad de obje- tos se deberá realizar.
tos dentro del área visual, es un movimiento
conservativo. En el modo de control tenemos que:

α 7) Los movimientos de seguimiento, Poursuite

o tracking, desplazan el área visual al punto de
δ P(Δx, Δy) = δ Pp- δ Pm Donde:
δ X = Xp - Xm = (Xo, Yo, Zo) - (Xm, Ym, Zm)

β
fijación con una suave afiliación y desafiliación δ V = Vp-Vm = (Vx, Vy, Zy) - (Vmx, Vmy, Vzm)
Σ
θ
 65

Las variaciones de posición δ (x, y, z) indican la orientación de los sensores visuales (Gaze),
α
cercanía e influencia de los puntos (objetos) ve-
cinos al punto focal del objeto seleccionado; y la
variable de velocidad (Vx, Vy, Vz) se asocia a
los movimientos de Poursuite y Saccadic para
debido al movimiento Saccade, involucra un
considerable número de decisiones de control
en varios niveles del control.
Σ
β
alcanzar puntos lejanos desde el punto focal.

CUESTIONES DE CONTROL
MODELO DE CONTROL

En un sistema de visión activa binocular con δφ

λ
capacidad de movimiento de vergencia se
Una fase importante y crucial de la visión acti- debe detectar la posición de un objeto relativo
va es generar y operar el control Gaze, el cual a la ubicación de cada una de las cámaras

es la colección del control de diferentes
mecanismos para mantener la fovea, área de
alta resolución, centrada sobre un objeto espa-
cial dado. Este sistema de control Gaze produ-
ce un cambio en los métodos de cálculo com-
putacional aplicados a imágenes y visión dado
que el proceso visual y el proceso de control
están interlazados para obtener un conoci-
ψθ
(ojos) y, a la vez, este movimiento de las cáma-
ras genera un desplazamiento de la imagen en
relación al plano Imagen de cada cámara.
El modelo de control a utilizar se describe en
su estructura de bloques funcionales siguiente:

ϕ
α
Cámaras- Control Motores
miento y procesamiento integral de la visión. ojos
Sistema de Proceso Visual
control Reconocimiento
El control de parámetros Gaze [7] involucra motores
dos categorías a resolver: (1) Cambio.- involu-
cra la detección autónoma y la identificación
dinámica de los parámetros requeridos por la
tarea visual y acomodar los requerimientos
para la manipulación activa de los parámetros
Movimientos Gaze

Cálculo Vergencia
Mapa
Mental
Opto-Visual
Σ
β
δφ
Momentos Fijación
Imagen
internos del sensor. (2) Estabilización.- corres- Visual
ponde al problema de control de los paráme- Ubicación Rotación
Centro masa Pan-Tilt
tros ópticos-visual en el centro de la visión acti-

λ
va, con relación al modelo de control y sus Detección Desplazamiento
problemas derivados. disparidad Gaze H y V

En los sistemas de visión activa binoculares,
con las cámaras y sus ejes ópticos en el mis-
mo plano, el movimiento de orientación para
fijar un objeto se llama Gaze Holding, basado
ψθ
Figura 7. Sistema de Control Visual
De este modo, existen dos cambios: de posi-
ción, de movimiento, que se deben ser detecta-

en el ajuste del ángulo panorámico (Pan Azi-
mut), de modo tal que ambos sensores (cáma-
ras) miren y enfoquen sobre el mismo punto
del espacio visual.
ϕ
dos por el sistema para los casos elementales
que son: (a) un objeto estático y movimiento de
las cámaras; (b) para una posición fija de las
cámaras y un objeto en movimiento; (c) un ob-

Una segunda importancia de interés visual del

Saccade está relacionado con el control de
este movimiento. El redireccionamiento de la
jeto en movimiento más movimiento de las cá-
maras.
α
β
En los sistemas de visión activa, el problema
Σ
θ
 66

α esencial está en la formulación de un sistema

Σ
β de control cuya planta principal sea la visión y
los cálculos de posición o ubicación relativa
(error posición) así como los cálculos de varia-
ción o de definición de las características pro-

δφ ξ pias de la imagen (iluminación, bordes, forma,

características) se realicen sobre el plano vi-
sual, usando la relación de coordenadas Ima-

λ
gen v/s coordenadas del mundo visual y la re-
troalimentación será dirigida hacia los
actuadores (plataforma, motores) que realizan

ψθ
el movimiento de las cámaras.

Esto difiere del clásico problema visual para el Figura 8. Plano imagen difuso
control de un robot en lazo cerrado, puesto

ϕ
que ahora se utiliza un “Sistema de Visión en En estos dos ejes principales de enfoque tene-
Lazo Cerrado con Retroalimentación de Movi- mos las variaciones angulares de elevación
miento”. (Tilt) y de rotación (Pan). Las etiquetas lingüís-
ticas usadas son: N = Negativo; P = Positivo;

α Para los sistemas de visión activa se deberá

centrar el desarrollo en un modelo que conten-
ga el análisis dinámico de la visión y de la di-
C = Cercano; M = Medio; L = Lejano.

La función de pertenencia posible de utilizar

β
námica del mundo visual, en relación con el será considerando solo la rotación sobre el pla-
Σ análisis dinámico de los sistemas del movi-
miento motoocular.
no horizontal μ(x).

De este modo, un sistema de visión activa esta

δφ descrito por el modelo indicado en la Fig. 4,

este sistema de visión donde se realiza todo el
procesamiento visual de las imágenes vistas

λ
del mundo real, antes y después de un movi-
miento.

ψθ
ALGORITMO DIFUSO PARA VISIÓN ACTIVA
Figura 9. Membresía difusa de focalización
En el sistema de visión activa usado para reali-
zar focalización sobre un objeto, se utiliza una
El sistema de control deberá fijar o focalizar la

ϕ
caracterización difusa del punto central de con-
tacto visual entre el objeto puntual y los vecto-
res visuales de enfoque o focalización sobre
este objeto.
visión sobre el punto definido Ze, como centro
del objeto dentro de la zona de visión central,
para un objeto determinado detectado en la vi-

α
sión periférica y conocido su centro de masa
En el plano visual 2-D de la cámara de visión como punto central del área del objeto.
tendremos una representación difusa de la
forma: El primer movimiento a realizar se llamará

Σ
θ β
 67

“Amplio”, que involucra una secuencia de más cada una de ellas con movimientos de rotación
α
de tres pasos angulares de movimiento, y una
vez cercano al punto central, el movimiento
debe ser más fino, teniendo dos acciones bá-
sicas en tres pasos angulares: negativo - cen-
θi y θd para fijar la visión en el espacio visual;
Σ
β
tro - positivo; de este modo, la función de per-
tenencia debe relacionar la variable difusa
cercana al centro de visión Ze con un movi- δφ
λ
miento fino de control y cuando la zona de
movimiento esté en la periferia visual, lejos
del punto central, los movimientos deberán

ψθ
ser más amplios.

El rango de pertenencia a utilizar será: (C-ββ) ≥

(δδ - α) ≥ β , donde (C-ββ ), (δδ - α) y b son los
Figura 10. Sistema de Cámaras Binoculares
límites de los movimientos posibles de realizar
para el objeto de fijar o focalizar la visión sobre
el centro del objeto, según la función de perte-
nencia utilizada.
En este sistema cada cámara tiene su propio
plano visual de la imagen del objeto capturado, ϕ
α
luego, las reglas de control serán
Como en la función de pertenencia las varia-
bles difusas están sobrepuestas, el motor de
inferencia deberá determinar cuál será la salida
de control a utilizar.

Como la función de pertenencia es compleja,

pues existen más de dos conjuntos difusos po-
(10)
Σ
β
sibles de posición y movimiento, una regla ge-
nérica de control y decisión difusa puede ser
de la forma siguiente:
Donde: Regla cámara izquierda, RCi, deberá
partir de una Posición Pi y un valor angular de δφ
λ
movimiento Mθθi obtener un valor verdadero al
llegar a la posición Pio de la función de perte-
nencia μCi (PoI).

(9)
ψθ
ϕ
Las variables difusas de entrada son la posi-
(11)
ción P y el movimiento M y la variable de salida
será la acción de cómo moverse para cambiar
la posición más cercana al centro del objeto. Donde: Regla cámara derecha RCd, deberá

Consideremos el sistema de visión activa for-

mado por dos cámaras binoculares unidas a
partir de una Posición Pd y un valor angular de
movimiento Mθθ d obtener un valor verdadero al
llegar a la posición Pdo de la función de perte-
nencia m Cd (PoD).
α
β
una distancia d sobre una línea base común; y
Σ
θ
 68

α En ambas cámaras existen dos conjuntos difu- En el modelo del mundo difuso visual se anali-

Σ
β sos para validar la incerteza del objeto, fijar la
visión sobre el centro del objeto; esto depende
de los conjuntos difusos de posición μ A(P) y
movimiento μ B(M); luego el peso de las accio-
za la opción de describir los objetos utilizando
el centro de masa en su modalidad difusa,
como punto de fijación de los vectores visuales
de ambas cámaras y el contorno encerrado por

δφ ξ nes en cada cámara será: la elipse más posible, dado que se está solo
fijando el objeto y no describiendo su forma o
reconociendo la forma del objeto.

λ (12)
Para la ubicación del objeto en el mundo visual
dinámico se propone un modelo difuso que

ψθ
describa la presencia y desplazamiento de los
objetos en el mundo visual, el cual considera la
(13) detección del objeto usando dos cámaras del
modelo de visión binocular difusa y activa, utili-

ϕ La decisión final del movimiento de ambas cá- zando correlación difusa cruzada para obtener
maras dependerá del valor de acción/reacción la disparidad cero entre las imágenes del obje-
difusas de cada una de las cámaras: to entre ambas dos cámaras.

α Luego:
(14) REFERENCIAS

[1] H. Latorre. Prototipo de Sistema de Visión

β
Activa, Informe Interno Usach, Chile.
Σ (15)
[2] H. Latorre, J. Castro, J.M. Benites, M. Gar-
cía. Modelo de Visión Activa Difuso. Repor-
te Interno Doctorado Computación y Siste-
mas Inteligentes, Decsai Utem Ugr.

δφ De este modo, el movimiento en conjunto a

[3] J. M. Keller. Fuzzy set theory in computer
vision: A prospectus Fuzzy Sets and
Systems, 90 (1997) 177-182.

λ realizar por ambas cámaras será μ cid(R) que [4] J.C Bezdek, S. K. Pal. Fuzzy Models for
será el movimiento de la plataforma de visión Pattern Recognition, IEEE Pres, New York
obtenida como una combinación de μ ci y μ cd. 1992.

ψθ
[5] J. Keller, R. Krishnapuram. Fuzzy Set me-
CONCLUSIONES thods in computer vision, Kluwer Academic
Publishers, 1992.
Se presenta un modelo de sistema de visión [6] J. Keller, R. Krishnapuram, P. Gader, Y.

ϕ activa que utiliza teoría de Conjuntos Difusos Choi. Fuzzy rule-based models in computer
para la focalización sobre un objeto específico, vision, Kluwer Academic Publishers, 1996.
de entre todos los existentes en el mundo vi- [7] D. Marr. Vision Freeman San Francisco, 1982.
sual, se analiza una técnica difusa posible de [8] E.L. Walker. A Fuzzy Approach to Pose De-

α utilizar, el método de los cluster difusos para

realizar segmentación y separación del objeto
seleccionado desde la imagen completa del
termination in Object Recognition Procee-
dings the 1997 Conference of the North Ame-
rican Fuzzy Society, Syracuse. NY 1997.

β
mundo visual.
Σ
θ
 69

αΣ
β
δφ
λ
ψθ
Generación Automática de Código Java para Clases
ϕ
Definidas a partir de Ontologías OWL α
Automatic Generation of Java Code from Written OWL Ontologies

Edgar Casasola Murillo; Luis Quesada Quirós

Σ
β
δφ
λ
ψθ
ϕ
α
β
1 Escuela de Ciencias de la Computación e Informática, Universidad de Costa Rica, San José, Costa Rica, ecasasol@ecci.ucr.ac.cr

Σ
θ
 70

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 71

ABSTRACT
α
This document proposes a series of strategies for the automatic generation of Java code from
written OWL ontologies. The proposals are based on the evaluation of content elements identified as
candidates for automatic generation maintaining the semantic content represented in the form of
Σ
β
ontologies. Some suggestions for the implementation of tools that offer more advantages than those
currently developed are given.
δφ
λ
RESUMEN

El presente documento propone una serie de estrategias para generación automática de código

ψθ
Java a partir de ontologías escritas en OWL. Las propuestas se basan en la evaluación de elemen-
tos de contenido identificados como candidatos para generación automática manteniendo el conte-
nido semántico representado en forma de ontologías. Se dan algunas sugerencias para implementa-
ción de herramientas que ofrezca mayores ventajas que las actualmente desarrolladas.

Palabras clave: OWL, generación automática, ontologías.

ϕ
INTRODUCCIÓN

El desarrollo de sistemas multiagentes es un

tandarizar el conocimiento sobre el dominio
de trabajo que puede ser compartido entre
agentes que se comunican entre sí. Sin em- α
área activa de investigación. Por definición
un agente es un programa que percibe, ac-
túa y modifica el ambiente en el que habita
[9, 11]. El desarrollo de plataformas de
bargo, se hace necesario que los agentes
manipulen, almacenen, modifiquen y transmi-
tan conocimientos entre sí. Para lo cual se
hace necesario contar con estructuras en el
Σ
β
agentes mediante lenguajes orientados a
objetos, por ejemplo Java, hacen natural
que el desarrollo de los mismos se esté dan-
do mediante la utilización de estos lengua-
lenguaje nativo de los agentes.

Las estructuras internas de representación

de conocimiento, implementadas en el len-
δφ
jes. Una de las plataformas más utilizadas
en la actualidad es JADE ( Java Agent Deve-
lopment Framework ) [9], la cual sigue las
guaje nativo de los agentes, deben conservar
de la manera más precisa posible el conteni-
do semántico expresado en las ontologías. λ
especificaciones de FIPA ( Foundation for In-
telligent Physical Agents ) [6].

La W3C ( World Wide Web Consortium ) ha

dado un gran impulso al desarrollar OWL
( Ontology Web Language ), originalmente
pensando en el desarrollo del web semántico
[2, 7, 8]. OWL se utiliza para la representa-
ción de propiedades, clases y relaciones con
el fin de describir dominios específicos [7].
En el mundo de los agentes es necesario es-
En otras palabras, las ontologías en el caso
específico de JADE, es necesario traducirlas
a Java para que los agentes puedan hacer
uso de esta representación para todas las ta-
ψθ
reas relacionadas a la manipulación del co-
nocimiento expresado en las ontologías (ra-
zonamiento y envío de mensajes entre ϕ
α
agentes, por ejemplo).
Para hacer la traducción de ontologías del
lenguaje OWL a Java existen diversas herra-

Σ
θ β
 72

α mientas. La más utilizada es el Ontology Java. Además se muestra la forma como se

Σ
β Bean Generador (conocido también como
Bean Generator ). Dicha herramienta es una
extensión del editor de ontologías Protégé
(desarrollado en la Universidad de Stan-
ha trabajado manualmente las clases Java y
cómo esto podría replicarse de manera auto-
mática.

δφ ξ ford).

Dicha herramienta genera código para JADE,

Características de OWL traducidas por
BeanGenerator

λ
ambiente que se está utilizando en el desa- Las características de OWL que el programa
rrollo de un demostrador de agentes inteli- BeanGenerator traduce son consideradamen-
gentes. Sin embargo, BeanGenerator no es te pocas. Se puede notar la ausencia de al-

ψθ
suficiente. Esto por cuanto algunas restric-
ciones no son traducidas, y valores corres-
pondientes a enumeraciones de objetos se
pierden a la hora de obtener las clases Java
gunas características que sí permiten las on-
tologías, pero no son traducidas por
BeanGenerator, como por ejemplo herencia
múltiple (que aunque Java no la permite, se

ϕ
que BeanGenerator crea.
De esta manera, aunque se utilizó BeanGe-
nerator para hacer parte del trabajo, algunas
puede simular haciendo uso de interfaces),
restricciones de cardinalidad, entre otros.
Es aquí donde se propone una mejora a la

α labores de traducción debieron realizarse

manualmente. En este documento se propo-
nen algunas mejoras al proceso de genera-
traducción automática de algunas de las ca-
racterísticas de OWL que BeanGenerator
hace. Esto por cuanto hay veces que se hace

β
ción de código que hace el BeanGenerator.
Σ Esto con el objetivo de mejorar la calidad del
código producido, es decir, para no perder
parte de la semántica de la ontología, ni tra-
bajo en el proceso de creación de una onto-
necesario ir mucho más allá de las relaciones
is-a (es un/a). Tal es el caso de las ontolo-
gías utilizadas para el demostrador de agen-
tes inteligentes que propone el proyecto
@Lis TechNet.

δφ logía.

Así, la estructura del documento es la si-

Características de OWL traducibles a cla-
ses Java

λ
guiente. En el desarrollo se dice lo que hace
BeanGenerator y lo que no. Además, se pre- Un caso interesante lo constituyen las enu-
sentan casos específicos de traducciones meraciones, esto por cuanto al utilizar Bean-

ψθ
que se hicieron para algunas de las ontolo-
gías del proyecto de investigación que motivó
este documento. Finalmente se presentan las
conclusiones y algunas ideas de trabajo futu-
Generator se pierden. Una posible estrategia
de traducción se muestra a continuación: su-
póngase que se tiene un campo X que co-
rresponde a un listado de palabras (palabra 1,

ϕ
ro respecto a este tema. palabra2, …, palabra n), entonces una imple-
mentación automática de dicha tabla podría
DESARROLLO hacerse tal y como lo muestra la siguiente
figura.

α En esta sección se presentan las limitantes

que se han detectado en BeanGenerator que
han motivado el mejoramiento de las estrate-
gias de traducción de código OWL a clases
Σ
θ β

…
private String campoX;
private String campoXValues[] = new String[4];
// valuation values:
static public final String PALABRA1 = “Palabra 1”;
…
static public final String PALABRA2 = “Palabra 2”;
static public final String PALABRAN = “Palabra n”;
/**
* @param valuation The valuation to set.
*/
public void setCampoX(String value) {
try {
isOneOf(value, campoXValues);
} catch (OntologyException e) {
//Apply the exception
e.printStackTrace();
}
this.campoX = value;
} caso de las enumeraciones y la herencia múlti-
… ple han sido probadas en las ontologías utiliza-
Figura 1. Implementación de una enumeración en Java
En el caso anterior se debe tomar el fragmento
OWL correspondiente y hacer una lista de
constantes (que representan los posibles valo-
res). En el constructor de la clase podrá ade-
más iniciarse con algún valor por defecto. Nó-
tese que el cuidado debe tenerse con el
método set del campo que es enumerable, por
cuanto deberá verificarse que el valor corres-
ponde únicamente con los permitidos por la
enumeración.
Otras posibles mejoras la constituyen el uso de
interfaces para simular la herencia múltiple de
una clase OWL en Java. Aquí puede crearse
una interface con los métodos comunes de la
clase padre y las clases hijas implementarán la
interface (claseHija implements clasePadre1,
clasePadre2).
Además de las características anteriores, un
análisis más profundo del código OWL permiti-
73
ría ampliar el grado de representatividad de las
α
β
clases Java generadas a partir de ontologías
escritas en OWL. Este, además de útil, se con- Σ
vierte en necesario dado la aceptación que tie-
ne día a día en uso de agentes (y por tanto de
ontologías para compartir el conocimiento).
CONCLUSIONES δφ
Poder maximizar la representación en clases
Java de una clase OWL se convierte en una
λ
ψθ
necesidad. Esto porque hacerlo manualmente
requiere de bastante tiempo, y hacerlo usando
herramientas de generación automática, como
el BeanGenerator, no es cien por ciento viable
(algunas cosas se quedan por fuera).
ϕ
Las características que se han propuesto, el
α
das por los primeros prototipos del demostra-
dor de agentes inteligentes que se han venido
desarrollando. Ambas han dado buenos resul-
tados y no han provocado ningún tipo de pro-
blema. Aun así, se tiene la necesidad de am-
pliar la cantidad de características que se
pueden traducir.
Σ
β
Aunque en este documento probablemente ha-
yan quedado por fuera algunas características δφ
λ
traducibles automáticamente, una mayor inves-
tigación podría dar con más. Parte de esto se
está haciendo ya como una tesis para optar
ψθ
por la maestría académica en la Universidad
de Costa Rica.
BIBLIOGRAFÍA
ϕ
[1] @Lis TechNet Project Home Page. URL:
http://www.alis-technet.org. Febrero de
2003.
[2] Van Aart, C.J., Pels, R.F., Giovanni C. and
Bergenti F. “Creating and Using Ontologies
in Agent Communication”. Workshop on
Ontologies in Agent Systems 1st Interna-
αΣ
θ β
 74

α tional Joint Conference on Autonomous [8] Horrocks, I. et al., “OWL Web Ontology

Σ
β [3]
Agents and Multi-Agent Systems, 2002.
Van Aart, C. Ontology Java Bean Genera-
dor for JADE 3.1. URL: http://
gaper.swi.psy.uva.nl/beangenerator/con-
Language Semantics and Abstract Syntax”,
World Wide Web Consortium, W3C Wor-
king Draft 31 March 2003, http://
www.w3.org/TR/owl-semantics/

δφ ξ [4]
tent/main.php. Mayo de 2004.
Arnold, K. y Gosling K., “The Java Progra-
mming Language”, Segunda Edición, Addi-
[9] Java Agent Development Framework
(JADE). URL: http://sharon.cselt.it/projects/
jade. 2004.

λ
son-Wesley, 1998. [10] Kalyanpur, A., Jiménez Pastor, D., Battle,
[5] Bellifemine, F. “JADE – A white paper” En: S. y Padget, J., “Automatic mapping of
Exp, Vol. 3, Nº 3, septiembre de 2003. OWL ontologies into Java”, a presentarse

ψθ
[6] Foundation for Intelligent Physical Agents en The 13th International World Wide Web
(FIPA). URL: http://www.fipa.org. Marzo Conference, mayo de 2004, Nueva York,
de 2003. Estados Unidos de América.
[7] Van Harmelen, F., Bechhofer, S., et al . [11] Poggi, A., Bergenti, F. y Bellifemine, F. “An

ϕ
“OWL Web Ontology Language Referen-
ce”. URL: http://www.w3.org/TR/owl-ref/.
World Wide Web Consortium, W3C Re-
commendation, 10 de febrero, 2004.
ontology description language for FIPA
agent systems”. Reporte técnico DII-CE-
TR001-99, Universidad de Parma, Italia,
1999.

αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 75

αΣ
β
δφ
λ
ψθ
A Solution Model for Traveler Recommendation
ϕ
Systems Based on Collaborative CaseBased α
Reasoning and Bayesian Networks
Un Modelo de Soluciones para un Sistema de Recomendación de Viajes que
utiliza Raciocinio Basado en Casos y Redes Bayesianas
Σ
β
José Arturo Tejeda Gómez; Ma de los Ángeles Junco Rey; Jorge δφ
Ramírez Uresti; Zeus Andrade Zaldívar; Enrique David Espinosa
Carrillo
λ
ψθ
ϕ
1 Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Estado de México. Carretera Lago de Guadalupe km 3.5, Atizapan de Zaragoza, α
β
Estado de México, México (jtejeda, ajunco, juresti, zandrade, enrique.espinosa)@itesm.mx

Σ
θ
 76

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 77

ABSTRACT
α
The travel recommendation systems, based on case-based reasoning (CBR), have been a common tool
to provide an itinerary. In this paper, we present a Case-Based Reasoning (CBR) framework that introdu-
ces a Bayesian Network (BN) for acquiring knowledge and improving accuracy in the decision making
Σ
β
process about recommended services. In this approach, the CBR provides a learning mechanism based
on user’s preferences. The Bayesian networks allow learning within a domain model based on observed
data. The process for learning user’s preferences and the domain model generated by BN is described. δφ
RESUMEN

λ
ψθ
Los sistemas de recomendaciones de viajes que utilizan raciocinios basados en casos (CBR) son amplia-
mente usados para proporcionar itinerarios. En este trabajo presentamos una formulación de raciocinio
basado en casos (CBR) que utiliza una Red Bayesiana (BN) para adquirir conocimiento y mejorar la
exactitud del proceso de decisión que interviene en la recomendación de servicios. En este método, el

ϕ
CBR proporciona un mecanismo de aprendizaje basado en las preferencias de los usuarios. Las redes
Bayesianas permiten aprender dentro de un dominio modelo basado en datos observados. Describimos
aquí el proceso de aprendizaje de las preferencias del usuario y el modelo generado por BN.

INTRODUCTION In the real world, there are ad hoc packaged

Recommender systems usually try to extract
customer’s data for converting in knowledge re-
quired to plan a itinerary that satisfied the tas-
tes and contraints of the user, using different
solutions, which are defined for travel agents α
β
based on experience acquired by asking to the
customers. The travel itinerary proposed by the
travel agents is a significant factor to accept
Σ
the visiting to destination. Moreover, the recom-

kind of techniques and mechanisms such as
Data Mining [9] and Automated Reasoning
[4],[5]. The travel itinerary is really a multi-
constraint satisfaction problem consisting of
δφ
mendations presented by the agents, help to
the customer to make decisions when there is
no experience of the available options. But tho-
se recommendations simplify the information

λ
choosing a destination and a set of services search process by comparing destinations and
(accommodation, transport, activities). Each services, checking another customer’s opinions
element could have attributes that modify the or taking advantage of the another customer’s

required services and increasing the complexity
in the making decision process. This attributes
usually produce a group of constraints, which
are hard to manage for identifying a represen-
ψθ
history to suggest similar destinations or servi-
ces to those booked in the past.
Nowadays, the recommendations technologies

tation of what user was trying to express. The
user’s preferences and requirements have to
be satisfied when an itinerary is proposed. The
travel itinerary also is considered as a multi-
variable optimization problem consisting of
maximizing the customer’s budget, preferences
and requirements at the same time. The groups
ϕ
are based on the assumptions that users’
needs seen as preferences and constraints that
can be mapped into packages, products or ser-
vices selections by using suitable reasoning
mechanisms.

In this paper we describe a travel recommenda- α

β
of variables are the attributes elements. tion model that uses CBR framework and BN.
Σ
θ
 78

α CBR is a reasoning mechanism for modeling part of the problem description. The attributes

Σ
β and explaining human problem solving that ex-
ploit past experience and it has been used in
several travel recommendation systems [9] [4]
[3]. BN is a graphical model for probabilistic re-
of the items modify the searching process for
discriminating between the useful and useless
item instances. The items to be considered are
as follows:

δφ ξ lationships among a set of variables and also

used for the user profile construction [6]. In the
proposed model CBR are used to propose a set
– Departure City: the city where the customer
is localized.

λ
of instances that match with the users’ needs – Arrival City: the city where the customer
and preferences and BN are used to model qua- wishes to visit.
litative and quantitative relationships among the – Budget: it is the itinerary cost in euros cu-

ψθ
user characteristics and the elements that is in-
terested in. The BN also is used to create pac-
kage solutions. The network structure and pro-
babilistic values associated to variables are
rrency.
– Dates: the time-lag between available dates
to achieve the trip.
– People: the quantity of persons involved in

ϕ
modified every time that users book a service. the trip.
– Accommodation: the type of accommodatio-
A distributed case-based architecture is intro- ns available, for instance: hotel, bungalow,
duced by separating tasks for independent lodge and cabin.

α CBR agents, where a problem is solved by

combining effort of these agents. The system
performance could be improved by distributing
– Restaurants: the type of food that the user
preferred, such as: fast, traditional, chinese
and italian.

β
the tasks across of multiple agents operating in – Activities: the type of activities to carry out,
Σ parallel [10] and the outcomes resulted update
the network structure of the BN, in order to pre-
for instance: aquatic sports, aerial sport, te-
rrestrial sport, familiar, adventure, cultural
sent subsequently the travel recommendation and ecotourism.
packages.

δφ This work has been organized as follow. Sec-

tion 2 illustrates the user profile constructions,
The use of a content-based approach for ins-
tructing an user profile, in which user expres-
ses needs, preferences and constraints, allow

λ
identifying what preferences and constraints we to the system matches the user preferences
have focused. Section 3 details a CBR cycle with the items [6], [5], [3]. Certainly, the user
and the BN introduction. The creation and up- profile construction could be more complex if it

ψθ
date of the BN are also explained this section.
The collaborative CBR architecture that uses
the CBR cycle and BN for creating travel re-
commendation packages is described in Sec-
has to know all the preferences and constraints
in detail. Therefore, the user can input accurate
profile information by completing the appropria-
te form and in that way it could simplify the

ϕ
tion 4. We talk about future work in Section 5.
Finally, we present the conclusions of the paper
in Section 6.
gathering preferences process.
At this time, the user profile is a set of the
travel items mentioned above. But, it also is

α USER PROFILE CONSTRUCTION

In the user profile construction process is ne-

cessary to identify the travel items which are
necessary to count on personal characteristics
of the user, such as: genre, age. These cha-
racteristics help to classify and to rank the
possible instances for certain preferences.
Σ
θ β
 79

The classification related will be tackled in the 1. Retrieve the most similar cases for a given
α
next section.

CBR LEARNING CYCLE AND BN

problem.
2. Reuse the case(s) to attempt to solve the
problem. Each case contains his own solu-
tion seen as 2-tuple (p, s) where p is the
Σ
β
The goal of problem-solving CBR is to apply a
prior well-known solution (learned from past ex-
periences) to generate the solution to a new
problem and s is the solution to the pro-
blem.
3. Revise the proposed solution if necessary. A δφ
λ
problem [1], [10]. A travel recommended sys- case could be adapted in an attempt to sol-
tem based on CBR implements a learning cycle ve a new problem.
provided by the CBR mechanism where situa- 4. Retain the new solution as a part of a new

ψθ
tion assessment, case retrieval, and similarity case.
assessment/evaluation are involved. In addi-
tion, the similarities and differences between The Figure 1, illustrates the classic CBR lear-
new and prior cases are used to determine how ning cycle but we have added an BN to modify
the solution of the previous case can be adap- the criteria for ranking and indexing the retrie-
ted to the new situation. For example, a case-
based planning system generates a new plan
by retrieving a prior plan for a similar goal, de-
ved cases into the making decision process,
this addition will be related in the next lines.
When the CBR learning cycle begins, the BN ϕ
termining the differences between the old and
new goals, and adapting the plan to take the
new goals into account [9]. The solutions of the
prior problems are used as the starting point for
does not contain any statistical data. Once the
system starts to work, the probabilistic values
of the BN will be updated. In the next
paragraphs it will be explained the use of the
α
generating a solution to the new problem.

The classic CBR learning cycle is structured in

the following steps [1]:
BN and her structure.

The first step of the CBR learning cycle a achie-

ves a retrieving of the cases that match with the
Σ
β
δφ
λ
ψθ
ϕ
α
β
Figure 1. CBR Learning Cycle with a BN introduced. The BN modify the criteria to index and to rank the retrieved cases.

Σ
θ
 80

α user preferences. If the matching have a 100% only focus in the last statistical values of the BN,

Σ
β of accuracy, just one case is retrieved, then it is
definitely unnecessary to use a BN but when it
exists a mismatch, a set of characteristics do not
exactly match with user preferences, the proba-
because these values represent the quantity of
desires over the instance. As a consequence the
Crown Plaza hotel must be chosen. It’ that sen-
se, the third step of CBR cycle could be not

δφ ξ bilistic and statistical data in the BN helps to

rank the cases and to propose one. In addition,
the cases ranking implicitly help to index them.
necessary.

The BN used in this example is depicted in the

λ
The BN store a statistical data based on instan- Figure 2, the network structure is configured
ces selection by the users. It’ order to exemplify with travel items (Arrival City, Accommodation)
the use of this technique, we will consider a user and user personal items (Age, Genre). This

ψθ
needs a hotel in Mexico City. But he has speci-
fied the attributes for his favorite hotel. For
example, a hotel near to downtown, with one
single room available, having TV in the room,
structure could be modified or updated in order
to improve the accuracy percentage. Moreover,
some other travel items as restaurants and ac-
tivities could be set instead of Accommodation.

ϕ
etc. Then, the system provides three cases-so-
lutions (Fiesta Americana, Crowne Plaza and
Best Western) that match with 90% of accuracy
and it uses the BN to verify the percentage of
The travel recommendation packages could be
constructed by grouping all the best solutions
ranked by percentage users’ selection about

α preference about these three cases-solutions

selected and it will be able to purpose one of
them. The probabilistic values could be seen as
travel items such as accommodation, restau-
rants and activities. As a consequence, it
avoids entering again into the CBR cycle by

β
statistical values; in this situation the probabilis- using a Bayesian inference [8] but that involves
Σ tic value for the Crowne Plaza hotel (0.6) means
that 60% of the users selected this instance. We
implementing a distributed case-based reaso-
ning to improve the system performance.

δφ
λ
ψθ
ϕ
α Figure 2. The structure of the Bayesian Network for carry out the making decision process to select a case-solution instance

β
based on statistical value.

Σ
θ
 81

The BN also could be useful when the budget item with the best second option “Fiesta Ameri-
α
needs to be maximized and the system already
counts with a travel recommendation package.
It’ that sense, we propose an extra step in the
CBR cycle by introduction of the BN into the
cana” with 30% of the user’s preferences.

Then, via Bayesian inference it determines

which case-solution instances have higher pro-
Σ
β
making decision process.

The Figure 3, covers the basic CBR learning

cycle and also our particular approach. When
the system tries to exchange instances of the
travel items, it begins a iterating process.
babilities of satisfying the user preferences and
constraints. Combining and introducing BN into
the CBR learning cycle for each principal travel δφ
λ
items (Accommodation, Restaurants and Activi-
ties) possible cases are filtered based on the
past experience in the CBR cycle and statistical

ψθ
However, the BN must be present to provide satisfaction data in the BN.
the criteria to exchange the elements conside-
red expensive. The system knows what travel FUTURE WORK
item is expensive because of assigned weights
to every item’s attributes. Using the same BN, The proposed framework is being incorporated
in order to select the second best instance, it
gains time-processing to find a set of best ca-
ses that match With the given attributes of the
in the development of a travel recommendation
system into the @lis Technet Project1. In this
project a distributed case-based reasoning is ϕ
item. We will take up again the previous exam-
ple about hotel recommendation in Mexico City.
If the hotel offered “Crown Plaza” with 60% of
the users’ preferences, based on a set of given
being developed to plan a travel itinerary
across of the specific entire country. The pro-
grams made so far have showed that the fra-
mework is a viable solution to the travel recom-
α
attributes, then the system could exchange this mendation systems.
Σ
β
δφ
λ
ψθ
ϕ
1
Figure 3. CBR Learning Cycle with a BN and Iterate Step introduced.

@lis TechNet Project is funded by the European Commission aiming to reinforce the partnership between the European Union and Latin America in the α
β
field of the Information Society.

Σ
θ
 82
α Future work includes applying a test about the
Σ
β system performance by modifying the network
structure of the BN.
CONCLUSIONS
δφ ξ The BN can be adapted to manage the ma-
king decision process into the CBR learning
λ
cycle without having to modify the basic case
representation or retrieval method even the
weights manipulate in the user profile. The
ψθ
domain model expressed by the BN covers
both travel items and personal user items.
The proposed approach uses a user’s feed-
back when they booking a preferred travel
ϕ
item. Potential disadvantages include the
need to analyze the system performance
when this framework was implemented in a
distributed case-based reasoning architectu-
α re. These isiues will be investigated as the
work proceeds.
β
REFERENCES
Σ 1. Watson, I.: Applying Case-Based Reaso-
ning: Techniques for Enterprise Systems.
δφ
Morgan-Kaufmann (1997).
2. Niknafs, A.A., Shiri, M.E., Javidi, M.M.: A
case-based reasoning approach in e-
tourism: tour itinerary planning. Database
λ
and Expert Systems Applications, 2003.
Proceedings. 14th International Workshop
on 1-5 Sept. IEEE (2003) 818-822
ψθ
3. Coyle, L. and Cunningham, P.: Improving
Recommendation Ranking by Learning Per-
sonal Feature Weights, in P. Funk and P.
Gonzalez Calero (eds.), Seventh European
ϕ
αΣ
θ β
Conference on Case-Based Reasoning,
LNAI 3155, pp.560-572, Springer, 2004.
4. Ricci, F., Cavada, D., Mirzadeh, N., Venturini,
A. Case-Based Travel Recommendations.
Venturini Electronic Commerce and Tourism
Research Laboratory (2002).
5. Aamodt, A., Langseth, H. Integrating Baye-
sian Networks into Knowledge-lntensive
CBR., Papers frorn AAAI workshop, In:
Aha, D., Daniels, JJ. (eds.), AAAI Press,
Menlo Park, (1998).
6. Schiaffino, S. N., Amandi, Analía., User
profiling with Case-Based Reasoning and
Bayesian Networks. In Open Discussion
Track Proceedings - International Joint
Conference IBERAMIA-SBIA 2000 - Atibaia,
Brazil (2000) 12-21.
7. Ana, D., Chang L. W.: Cooperative Baye-
sian And Case-Based Reasoning for Sol-
ving Multiagent Planning Tasks-Technical
Report-NCARAI, Washington DC, USA -
Number AIC-96-005 - (1996).
8. Watthayu, w., Peng, Yun. A Bayesian net-
work based framework for multi-criteria de-
cision making. MCDM 2004, Whistler, B. C.
Canada (2004).
9. Arslan B., Ricci F. Case Based Session Mo-
deling and Personalization in a Travel Advi-
sory System, in Proceedings of the AH’2002
Workshop on Recommendation and Perso-
nalization in eCommerce. (2002) 60-69.
10. McGinty, L., Smyth, B., Collaborative Case-
Based Reasoring: Applications in Personali-
sed Route Planning, Proceedings of the 4tn
International Conference on Case-Based
Reasoning: Case-Based Reasoning Re-
search and Development, (2001) 362-376.
 83

αΣ
β
δφ
λ
ψθ
MultiAgent System Design Based on Security Policies
ϕ
Diseño de un Sistema Multiagente Basado en Políticas de Seguridad
α
Zeus Andrade Zaldívar; Ma de los Ángeles Junco Rey; Jorge Adolfo
Ramírez Uresti; José Arturo Tejeda Gómez; Enrique David Espinosa
Carrillo
Σ
β
δφ
λ
ψθ
ϕ
1 Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Estado de México. Atizapán de Zaragoza, México (zandrade, ajunco, juresti, α
β
jtejeda, enrique.espinosai) @itesm.mx

Σ
θ
 84

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 85

ABSTRACT
α
Security plays a major role in modern computer systems and multi-agent systems are not an exception.
Security and multi-agent systems have been related on several works but little work has been done in
relating security with agent oriented software engineering. In this paper we discuss the use of security
Σ
β
policies to guide the design process for multi-agent systems and describe extensions to the GAlA
methodology for this purpose. The proposed extensions are illustrated with the design of a file sharing
system based on the MLS security model. δφ
RESUMEN

λ
ψθ
La seguridad tiene un papel preponderante en los sistemas computacionales modernos y los sistemas
multiagentes no constituyen una excepción. La relación entre la seguridad y los sistemas multiagentes
ha sido descrita en numerosos trabajos, pero se ha puesto poca atención a la relación entre la seguri-
dad y la ingeniería de útiles relacionada con agentes. En este trabajo discutimos el uso de políticas de
seguridad que sirvan de guía al diseñar procesos para sistemas multiagentes. También describiremos
extensiones de la metodología GAIA para este propósito. Ilustraremos la extensión propuesta mediante
el diseño de un sistema de archivos compartidos basados en el modelo de seguridad MLS.
ϕ
INTRODUCTION behavior according to the security requirements
is a hard task and commonly leads to the α
Nowadays multi-agent systems provide a good
alternative for tile development of large and
complex systems. Multi-agent systems are
particularly useful, when the system aims to
introduction of vulnerabilities in the system [1],
[2], [3], [4]. Little work has been done focusing
on the incorporation of security through the
whole process of the system development.
Σ
β
recreate a real world organizational structure
and when the presence of autonomous,
intelligent, proactive, learning capable and
social entities is needed to interact in
Mouratidis in [5] proposes extensions to the
TROPOS methodology to accommodate
security. Following this approach, in this paper
we propose extensions to the GAlA
δφ
distributed systems.

The majority of modern system operate on

methodology [6], [7] to accommodate security
restrictions and we present recommendations
to guide the design process according to λ
open environments where they are susceptible
to attacks, this makes necessary to take
security as one of the more important elements
of any modern system. A lot of research has
security policies.

EXTENDING THE GAIA METHODOLOGY ψθ

related security and multi-agent systems;
however, most of it had been focused on the
final stages of the system development
process, especially when the system is already
implemented or even deployed. Identifying
security requirements based on the system
behavior instead of controlling the system
Security is established through policies and
mechanisms that ensure integrity, privacy and
availability of the resources that can be ϕ
α
provided, required or present in the system.
Security policies for multi-agent systems could
be seen as sets of rules restricting the
relationships between the system elements in

Σ
θ β
 86

α terms of privacy, integrity and availability. The case of study a hypothetical distributed file

Σ
β more important system elements are: Agents,
users and resources.

There may be a lot of different types of rules

access system based on Bell and LaPadula
multi-level security model [8] (military security
model). This security model is summarized in
the following section.

δφ ξ according to the kind of entities they restrict or

the properties they are based on. Rules can
force an entity to perform an action, make an
Multi level security

λ
action triggers another, set conditions for an This model establishes rules for two kinds of
action, control the way an action is performed, entities: objects, which are passive entities and
control the number of entities and resources, cannot perform any activities, and subjects,

ψθ
or restrict the system behavior in many other
ways. Thousands of different kinds of rules can
be defined according to the specific needs and
requirements of a system.
which are active entities performing actions
and accessing resources (objects). The model
can be represented by the following rules:

ϕ
It is not realistic to think in a design
methodology that takes all possible kinds of
rules. For this reason in this work we take
R1. Subjects have only one level.
R2. Objects have only one level.
R3. AIl subjects have a set of labels.
R4. All objects have a set of labels.

α under consideration a limited set of rule types:

1. Restrictions on the effective capabilities of

R5. For every object there is a set of
permissions for writing and reading.
R6. Reading is allowed if the subject’s level is

β
entities. Conditions that must be fulfilled to
Σ enable an entity to perform an action. These
restrictions cover any kind of action perfor-
med by an agent or user such as reading,
writing, creating or consuming resources
greater than or equal to the object’s level and
the subject’s label set is a sub-set of the
object’s label set.
R7. Writing is allowed if the subject’s level is
lesser than or equal to the object’s level and

δφ and create, suspend, resume, migrate, and

terminate an agent.
2. Restrictions over the interaction between
the subject’s label set is a sub-set of the
object’s label set.
R8. An authentication mechanism is necessary.

λ
entities. Conditions that must be fulfilled du- R9. All subjects must be authenticated before
ring the interaction of two entities. accessing the system.
3. Restrictions on the properties or attributes

ψθ
of entities. Conditions that restrain the attri-
butes of an entity and that must be always
fulfilled.
The primary objective of this model is to assure
privacy. Through the mandatory and
discretionary controls the model guaranties
that information can be accessed only by

ϕ
This set includes rules to represent and model
policies like the multi level security [8] and the
commercial model [9]. These models are
representative on computer security, so the set of
authorized entities. Authorization is contained
on the levels and labels on every entity.
DESIGNING THE SYSTEM

α rules to represent them are also representative.

To illustrate the use of security policies on the

design of multi-agent systems we use as a
The system to be consists of a shared file
system based on agents and the multi-level
security model. Although this system does not
Σ
θ β

reflect the real complexity of most modern
multi-agent systems, it has been chosen as a
case of study because its simplicity allows a
simple illustration of the design process based
on security policies.
In the following sections we present the
process of design for this system according to
the phases established by the GAIA
methodology and incorporating extensions and
guidelines to preserve the security
requirements (the security policy).
THE ANALYSIS
In this phase of the GAIA methodology, the
system specification is modeled through the
identification of the organizational structure and
the specification of preliminary roles,
environment and interaction models. The
security policy is part of the system specification
so we propose to model it on this phase.
The first stage of this phase is to establish an
organizational structure for the agents on the
system. In many cases the security policy will
define explicitly or implicitly the organizational
structure or structures that should be used. For
the case of study we identify a single
organizational structure.
Figure 1. Preliminary restrictions model
87
The GAIA methodology uses only the system
α
requirements to identify and design roles,
protocols and the environment, the first
extension we propose to this methodology is
to use a security policy to identify those
Σ
β
elements. This is done through two new
types of models, a restrictions model, which
represents the security policy, and a δφ
λ
behavior model, which models the system
behavior restricted by the security policy.
ψθ
The security policy restricts entities, so it must
be modeled before modeling entities into roles
and resources. The restrictions model must
present all the rules or restrictions of the policy
and the relationship between the rules and the
entities (active and passive) of the system. The
restriction model for the case of study is shown
on figure 1. ϕ
The restrictions model presents all entities,
resources, actions and interactions
restricted by the security policy but there
α
may be other elements present in the
system requirements which are not
restricted. The behavior model should
represent graphically all restricted and
Σ
β
unrestricted elements. On figure 2 and 3 we
present a graphical notation and a behavior
model for the case of study. δφ
λ
ψθ
ϕ
α
β
Σ
θ
 88

αΣ
β Figure 2. Graphical notation for the behavior model

δφ ξ
λ
ψθ Figure 3. Preliminary behavior model

ϕ Once we have established the restrictions and

behavior models we can use them, along with
tile system specification, to generate the
This extension does not apply to roles that are
not restricted by the security policy. The
following schema represents the role for the

α
environment, roles and interaction models. case of study.
Roles can be identified in the behavior model
as subjects, resources as objects and
interactions as double headed arrows

Σ
β connecting subjects.

An environment model, as proposed in [7], for

the case of study is presented below:
The interaction model consist of a set protocols

δφ
defined by the interactions between roles. The
interactions can be identified on the restrictions
and behavior models, these interactions must
be modeled as protocols. Restrictions over

λ
The role model, as defined on [7], presents interactions are referenced in the schema for
roles along with their description, actions, the protocols. The third proposed extension is
protocols, permissions and responsibilities. to aggregate restriction references to the

ψθ
Permissions allow the designer to express the
effective capabilities associated to the role
and the safety responsibilities allow express
conditions (invariants) that must always be
protocol schemas as defined in [7]. The
interaction model for the case of study is
shown in figure 4.

ϕ
maintained. However these two elements of
the role schema are not useful to describe
restrictions over the actions that the entity can
perform. The second proposed extension is to
The Security policy, captured with the
restrictions and behavior models define the
security requirements of the system. The
environment, role and interaction models are

α use references to tile restrictions defined on

the restriction model instead of using
permissions and safety responsibilities to
describe the effective capabilities of the role.
build parting from the restrictions and behavior
models, the protocol and role schemas include
references to the restrictions applied to the

β
element they represent.
Σ
θ

Figure 4. Preliminary interaction model
The last stage of the analysis is to establish the
organizational rules. We propose only one
recommendation for this stage, security
restrictions that are not concerned to entities,
their attributes, actions and interactions can
and should be modeled as organizational rules.
Organizational rules for the case of study are
presented below.
The GAlA methodology establishes as output of
the analysis phase the preliminary models of
environments, roles and interactions; we
propose to add tile preliminary models of
restrictions and behavior (called preliminary
because they are to be updated in the following
phase).
THE ARCHITECTURAL DESIGN
This phase is focused on the establishment of
the final structure for the system. On this phase
all preliminary models are refined until they
become final models.
The first stage of this phase is to define the
organizational structure for the system. Security
requirements (policies) diverge greatly from one
system to another so the use of organizational
patterns, as described in [7], may be restricted
to systems that adopt the same security policy.
89
αΣ
β
The organizational structure for the case of δφ
λ
study is presented underneath.
The next stage on the architectural design is to
ψθ
complete and refine the role model. The GAlA
guidelines should be used during this stage; this
means that new roles (organizational roles)
must be added following the organizational
ϕ
structure, the new roles must be evaluated to
verify that all restrictions on the security policy
are fulfilled. The fourth proposed extension is
the definition of security roles, this kind of roles
are not explicitly needed by the organizational
structure or the security policy but that are
needed to satisfy some restrictions. Security α
β
roles can be identified through the protocols for
which one or both entities (initiator and partner)
were not identified in the preliminary
Σ
interactions model, as an example, in the case
δφ
of study we defined the protocol InitSession,
which is restricted, in the preliminary
interactions model the partner for the entity user
was not identified and this identifies the need for
a security role. Also, restricted actions like
ReadFile and WriteFile imply the existence a
security role which will be in charge of verifying
λ
the fulfillment of the restrictions associated to
these actions. Below we present the role
schemas for the new roles, which along with
those defined on the preliminary role model
ψθ
ϕ
integrate the final role model.
The next stage is to refine the interactions
model. The GAIA methodology provides the
αΣ
θ β
 90

αΣ
β
δφ ξ
λ
ψθ Figure 5. Interactions model

ϕ necessary guidelines to perform this action.

New protocols may be added during this stage
The design process must iterate on this phase
until the roles, interactions, restrictions and

α
and it must be verified that they comply with all
security restrictions present on the policy. In
figure 5 we present the protocol schemas that
complete the interactions model.
behavior models become fully compliant with
the system requirements and especially with
the security policy.

Σ
β The aggregation of new roles and protocols
could introduce inconsistencies with the
security policy, thus a review and refinement of
THE DETAILED DESIGN

On this phase the main objective is to find a

match between agents and roles. Security

δφ the restrictions and behavior models is

necessary. The refinement of those models
requires to evaluate all security restrictions and
to modify them or create new restrictions to
restrictions play an important role during this
phase because in many cases they define if it
is possible for a single agent to play different
roles. For our case of study, the agent model is

λ obtain a new security policy equivalent to the

original but including all new roles and
interactions. The refined models of restrictions
presented below.

ψθ and behavior are shown in figures 6 and 7.

ϕ
α
β
Figure 6. Refinement of file restrictions model

Σ
θ
 91

Figure 7. Refinement of the behavior model
The fifth proposed extension is the inheritance of
restrictions from the roles to the agent classes.
Agent classes are designed to play one or more
roles, so an agent class should inherit
restrictions form the roles it plays. It is necessary
to verify the application all restrictions, this can
be done through a table containing all entities
(agents and objects), their restrictions and how
the restrictions will be applied. Table 1 presents
these elements for die case of study.
αΣ
β
δφ
actions and interactions are detailed. This model
λ
ψθ
can be constructed following the guidelines
provided by the GAlA methodology. For the case
of study, the services model is shown in table 2.
The detailed design is the simplest phase of
tile methodology, however, the implementation
of the systems relays completely on the output
of this phase, this implies that if any of the ϕ

The next step on the detailed design is to build a

services model, on this model all activities,
restrictions were lost during the previous
phases or in this one, the implementation of
the system will not be compliant with the
security policy.
α
Table 1. System restrictions table
Σ
β
δφ
λ
ψθ
Table 2. Services model
ϕ
αΣ
θ β
 92

α It is necessary to keep on the output of this The security add-on for Jade includes features

Σ
β phase the restrictions and behavior models
because they are useful to guide the
implementation process towards the
compliance with the security policy.
like authentication, permissions and secure
messaging between agents. Authentication
allows users to authenticate themselves with the
system, secure messaging allows the use of

δφ ξ THE DESIGNED SYSTEM

cryptography to sign or encrypt messages during
agent interactions and permissions allow or deny
users and agents to perform certain actions like

λ
The obtained design consists on the final creating, killing, pausing or terminating an agent,
models: agents, services, restrictions and sending messages to certain agents, accessing
behavior along with the system restrictions certain java classes, etc.

ψθ
table, the organizational rules and the
organizational structure.
The security policy is present in all models. In
In most of the cases, rules from the restrictions
model can be directly translated into rules from
tile Jade security add-on.

ϕ
the system restrictions table, every agent class
has a set of restrictions inherited from the roles
it plays and that must be implemented on the
system. In the same way, all protocols have a
A software tool named MASSD has been
created to allow an easy way to implement
systems designed as proposed here. The

α set of restrictions to fulfill. The organizational

rules preserve the rest of the security
restrictions not directly associated with a role
application allows the user to generate all
models here described and finally to
automatically generate Jade code to implement

β
or protocol. agents and services.
Σ IMPLEMENTING THE DESIGNS CONCLUSIONS AND FUTURE WORK

The GAlA methodology does not deal with the Security is one of the major issues to address

δφ implementation process and being the basis for

this work, the extensions proposed are limited
to the design process.
when developing a multi-agent system. The
overall system behavior must be controlled
according to the security requirements of the

λ
system. On this paper we proposed the use of
There are many different agent frameworks security policies to guide the design process of
which allow the creation and deployment of a multi-agent system and we presented a set

ψθ
multi-agent systems. A combination of GAlA
with the Jade framework [10] has been
proposed in [11] and [12]. Jade also
provides a security add-on based on rules
of guidelines, recommendations, models,
schemas and extensions to the GAlA
methodology for this effect. We also
established a relationship between the security

ϕ
[13] which is suitable for the implementation
of systems designed following the
extensions proposed.
policy, its restrictions and the elements of
multi-agent systems and the necessary
elements for modeling security restrictions
within the GAlA methodology.

α Agent classes in the GAlA agent model can be

directly mapped to Jade agent classes and its
actions, protocols and services as Jade
behaviors to be adopted by agents.
A system designed following the guidelines
proposed and using the extensions described
should be compliant with the security policy
Σ
θ β

used. This contributes to reduce vulnerabilities
in the system architecture. A real world test
case for the benefits obtained with this
methodology is part of the future work.
The presented work is focused on a
representative set of rules or restrictions that
may be present on a security policy, a
generalization of the restriction types, the
incorporation of validation mechanism to probe
the preservation of the security policy and the
study of different security models to establish
security organizational patterns are part of the
future work.
The systems designed following this work can
be easily implemented using the Jade
framework along with its security add-on. A
software tool for automatic Jade agent code
generation has been developed.
The work is being applied to generate a secure
system architecture for the @lis technet project
[14].
REFERENCES
[1] Lhuillier, N., Tomaiuolo, M., Vitaglione,
G. Security in Multiagent Systems,
JADE-S goesdistributed. exp: in search
for innovation, vol 3. no. 3. Septiembre
de 2003.
[2] Jien Tam, J., Titkov, L., Neophytou, C. Se-
curing Multi-Agent PlatformCommunica-
tion. Department of Electronic Enginee-
ring, Queen Mary, University of London.
[3] Noordende, O., Brazier, F., Tanenbaum,
A. A security framework for a mobile
agent system. Amsterdam University.
[4] Kagal, L., Finin, T., Joshi, A. Developing
Secure Agent Systems Using Delegation
Based Trust Management. University of
Maryland.
93
[5] Mouratidis, H., Giorgini, P., Manson, O.
α
Modelling secure multiagent systems. Pro-
ceedings of the AAMAS conference. 2003.
[6] Zambonelli, F., Jennings, N., Wooldridge,
M. Developing multi-agent Systems: the
Σ
β
gala methodology. ACM transactions on
software engineering and methodology.
2003. δφ
λ
[7] Wooldridge, M., Jennings, N. R., Kinny, D.
The Gala methodology for agent oriented
analysis and design. Journal of Autono-
ψθ
mous Agents and Multi-Agent Systems, 3
(3):285-312, 2000.
[8] Bell, D. E. Lapadulla, L. Computer securi-
ty model: Unified exposition and multics
interpretation. Technical report ESDTR-
75-306. 1975.
[9] Clark, D. D. Willson, D. R. A comparisson
of militar and commercial security poli- ϕ
cies. Proceedings of the IEEE sysmpo-
sium on security and privacy. 1987.
[10] Java Agent Development Framework.
http:/jade.cseit.it
α
[11] Moraltis, P., Spanoudakis, N. Combining
Gala and JADE for Multi-Agent Systems
Development. 4th International Sympo-
sium “From Agent Theory to Agent Imple-
Σ
β
mentation” (AT2AI4), in: Proceedings of
the 17th European Meeting on Cyberne-
tics and Systems Research (EMCSR δφ
λ
2004), Vienna, Austria, April 13-16, 2004.
[12] Moraitis, P., Petraki, E., Spanoudaitis, N.
Engineering JADE Agents with the Gala
ψθ
Methodology. In R. Kowalszyk, et al.
(eds), “Agent Technologies, Infrastructu-
res, Tools, and Applications for e-Servi-
ces”, LNAI 2592, Springer-Verlag, 2003,
ϕ
pp. 77-91.
[13] Java Agent Development Framework.
Jade Security Guide. 2005.
[14] @lis technet project. http: //www.alis-
technet.org.
αΣ
θ β
 94

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 95

αΣ
β
δφ
λ
ψθ
Implementación de un Prototipo de Agente Educativo
ϕ
Implementation of a Prototypical Teaching Agent
α
Vicky Pacheco; Mauro Castillo; Homero Latorre; Miguel Sanhueza Σ
β
δφ
λ
ψθ
ϕ
α
β
1 Grupo@LIS, Universidad Tecnológica Metropolitana {vicky.pacheco, mi.sanhueza}@gmail.com; {mcast, hlatorre}@utem.cl

Σ
θ
 96

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 97

ABSTRACT
α
This work, which is part of project @Lis-Tech, describes the analysis, development and implementation
of a model allowing the integration of multi-agent systems with teaching models. The model obtains
from the union of three elements: agency, e-learning platforms and users. Here we use MOODLE as e-
Σ
β
learning platform and JADE as tool for the functioning, maintenance and administration of the multi-
agent system.
δφ
λ
The user (or pupil) visits the syllabus (residing at the platform) where he finds both the theoretical
developments and a practical part, containing exercises and tests. Is in this interaction between pupil
and platform, mediated by the intervention of a human interface, where the union between the platform

ψθ
and user obtains.

Users will be able to interact in line with an agency through a user agency (representing agency) by
means of these exercises. At this agency there will reside the respective agents necessary for perfor-
ming the exercise. The interaction between the pupil, through its user agency, and the agency will result
in the user-agency union.

The results of these exercises will be directly integrated into the knowledge basis of the platform. The ϕ
respective agents of the agency, using the VIPU modulus, will perform the integration itself in an
autonomous and semi-automatical manner. It is only as a result of the creation of VIPU modulus that it
will be possible to establish the base model which will allow us to integrate the multi-agent system
(agency) with the teaching system (platform). This model has already been implemented as a prototype,
α
as described at the URL http://alis.utem.cl/alis.

RESUMEN
Σ
β
Este trabajo se enmarca dentro de las investigaciones del Proyecto @Lis-Technet y tiene por objetivo el
análisis, desarrollo e implementación de un modelo que permita integrar los sistemas multiagentes y los
sistemas educativos. El modelo se basa en lograr la unión de tres elementos que son: agencia, platafor- δφ
λ
ma e-learning y usuarios. Para este trabajo se ha elegido como plataforma e-learning a MOODLE y como
herramienta para la realización, mantenimiento y administración de sistemas multiagentes JADE.

ψθ
La idea es que el usuario (alumno) visite el curso, que se encontrará implementado en la plataforma, el
cual contará con materiales para la parte teórica, además de ejercicios y evaluaciones para la parte
práctica. Es aquí en esta interacción, entre el alumno y la plataforma mediante la interfaz humana, que
se logra la unión de ambos (usuario-plataforma).

Dichos ejercicios permitirán a los alumnos interactuar en línea con una agencia a través de un agente
usuario (agente representante). En dicha agencia se encontrarán alojados los agentes respectivos para
cada ejercicio. Esta interacción entre el alumno, a través de su agente usuario, y la agencia logra la ϕ
unión de ambos (usuario-agencia).

Los resultados de las ejercitaciones serán integrados directamente en la base de conocimiento de la

plataforma. Dicha integración de resultados será llevada a cabo de forma semiautomática y autónoma
αΣ
θ β
 98

α por los respectivos agentes de la agencia, mediante el uso del módulo VIPU. De modo que este proceso

Σ
β de integración de resultados desde la agencia a la base de conocimiento de la plataforma, permite
lograr la unión entre estos dos elementos (agencia-plataforma). Gracias a la creación del módulo VIPU
se podrá lograr establecer el modelo base que permita integrar el sistema multiagente (agencia) con el
sistema educativo (plataforma), dicho modelo fue implementado en el prototipo que se encuentra en la

δφ ξ URL: http://alis.utem.cl/alis

λ INTRODUCCIÓN

Actualmente existen muchas aplicaciones de

capaz de actuar sobre un ambiente, percibien-
do las características del propio ambiente
(Russell et al. 1995). Las características más

ψθ agentes en el área educativa, pero aún no ha

sido desarrollada una aplicación que permita a
los profesores contar con una herramienta
educativa, basada en agentes inteligentes, que
relevantes de un agente son: autonomía, reac-
tividad, proactividad y habilidad social (Wool-
dridge et al., 1995). Además, se considera que
un agente es una entidad que reside en dife-

ϕ brinde la posibilidad de que sus alumnos pue-

dan interactuar y ejercitar en un ambiente en
línea, es por este motivo que surge la idea de
rentes entornos donde interpreta datos que re-
flejan eventos y ejecuta comandos en ese en-
torno (FIPA, 1996).

α
proporcionar un modelo que permita llevar a
cabo esta tarea.
El curso que será implementado como prototi-
Las características principales de un agente
dependerán de la funcionalidad que se preten-
da conseguir, entre ellas se destacan autono-

Σ
β po en dicha plataforma será el de Agentes Inte-
ligentes dado que posee mayor afinidad con el
tema de este trabajo. La particularidad es que
el alumno podrá realizar ejercicios en línea.
mía, habilidad social, reactividad, proactividad,
cooperación (usuario-agente y agente-agente),
movilidad, veracidad, benevolencia, continui-
dad temporal. Son múltiples las combinaciones

δφ Para este trabajo se han desarrollado e imple-

mentado siete casos, que tienen por objetivo la
ejercitación de agentes. Por lo tanto, tenemos
de las características que se pueden dar en los
agentes, según dichas combinaciones, se pue-
den identificar diferentes tipos de agentes.

λ
que el alumno podrá visualizar el resultado de Nwana propone una clasificación de agentes:
sus ejercicios a través de la interfaz la platafor- (a) Colaborativos, cuando varios agentes tra-
ma MOODLE. Y si desea visualizarlos a nivel bajan juntos para resolver un problema; (b) In-

ψθ
de agentes podrá utilizar el agente “Sniffer” terfaz, el agente observa e interpreta las accio-
que proporciona la herramienta JADE. nes del usuario; (c) Móviles, son capaces de
navegar por redes e interactuar con otros equi-
Agentes pos; (d) Reactivos, actúan y responden a los
estímulos externos; (e) Deliberativos, poseen

ϕ En la actualidad la Inteligencia Artificial utiliza

el concepto de agente inteligente como una en-
tidad de software capaz de ejecutar acciones y
conocimiento del dominio y tienen capacidad
de planificación con el objeto de actuar; (f) In-
teligentes, pueden realizar operaciones en re-

α
adaptarse al entorno que se encuentra para
cumplir con sus metas. El propósito de un
agente es realizar tareas en representación de
un usuario (Nwana, 1996). Un agente debe ser
presentación de un usuario con un grado de
independencia, deben ser capaces de apren-
der; (g) Híbridos, cuando se combinan dos o
más filosofías de agentes en una sola.

Σ
θ β

Multiagentes
Se define un Sistema Multiagente (SAM)
como una asociación de agentes que trabajan
juntos para resolver problemas que van más
allá de sus capacidades individuales (Durfee
& Rosenschein, 1994). Por lo tanto en estos
sistemas los agentes trabajan juntos para re-
solver problemas, caracterizados porque cada
agente tiene información o capacidad incom-
pleta para solucionar un problema, no hay un
sistema de control global, los datos se en-
cuentran descentralizados y la computación
es asíncrona. Los agentes pueden decidir di-
námicamente qué tareas deben realizar y
quién realiza cada tarea.
Las características que hay que tener en cuen-
ta en el desarrollo de sistemas multiagentes,
casi todas ellas relacionadas con la obligación
de conseguir un todo a partir de muchos indivi-
duos y sus relaciones, son las siguientes:
(Mosquera & Santos, 2001):
Lenguaje de Comunicación entre agentes
Una de las características principales de los
agentes es su capacidad de comunicación. La
comunicación entre agentes es la llave para
poder obtener todo el potencial del paradigma
de agentes. Esta comunicación les permitirá a
los agentes compartir y enviar mensajes.
Los agentes emplean un lenguaje de comuni-
cación ACL para comunicar información y co-
nocimiento. La importancia de la comunicación
Figura 1. Funcionamiento de los Sistemas Organizados (adaptado de Genesereth y Ketchpel, 1994)
99
entre los agentes es que las sociedades de
α
agentes permiten realizar tareas que los agen-
tes individuales no pueden, así que resulta fun-
damental que los agentes puedan comunicarse
de modo que juntos logren objetivos que de
Σ
β
forma individual no podrían.
La teoría de los “Actos del habla” fue desarrolla- δφ
λ
da para ayudar en la comprensión del lenguaje
humano y estudia el lenguaje como una acción.
Esta teoría es la base teórica para la comunica-
ψθ
ción entre agentes. Los hablantes cuando reali-
zan actos del habla, estos pueden informar, pre-
guntar, sugerir, prometer, etc. Cada expresión
conlleva a un acto del habla, en donde poder
identificar el acto del habla es imprescindible
para una correcta comunicación. Por este moti-
vo es la base teórica en la comunicación entre
agente (Arroyo A., 2002). Dentro de un acto del ϕ
habla podemos encontrar 3 acciones que son:
(a) Locución: contexto del hecho físico del acto
del habla, (b) Ilocución: intención con la que se
realiza; (c) Perlocución: acto que ocurre como
α
resultado. Por ejemplo la Tabla 1 muestra las
posibles intenciones con las que se puede reali-
zar un acto del habla:
Σ
β
DEFINICIONES DE ONTOLOGÍA
En cuanto a la definición de ontología, al igual que δφ
λ
en el caso de la definición de agente, existe una
variedad de definiciones, algunas de las cuales
son: Grubber definió este término y su definición,
ψθ
actualmente es una de las más extendidas: “Una
ontología es una especificación explícita de una
conceptualización” (Grubber, 1993).
Comunicación
Coherencia y coordinación ϕ
Heterogeneidad de los agentes
Homogeneidad de los intereses
α
β
Σ
θ
 100

α Tabla 1. Ejemplo de posibles intenciones para realizar un acto del habla (Arroyo A., 2002)

Σ
β
δφ ξ
λ Según Neches, “Una ontología define los térmi- nio. Por ejemplo, ontologías sobre el tiempo, el

ψθ nos y relaciones básicos que comprenden el

vocabulario del tema de algún área, así como
también las reglas para combinar los términos
y relaciones para definir extensiones al voca-
espacio, espacio-temporales, ontologías de ca-
sualidad, de conducta, etc.

EDUCACIÓN

ϕ bulario” (Neches, 1991).

Tipos de ontologías
El Conductismo

α
Dentro de lo que son las ontologías, también
se pueden encontrar clasificaciones de estas
(Cortés U., 2004), las cuales se nombran a
La teoría conductista se desarrolla principal-
mente a partir de la primera mitad del siglo XX
y permanece vigente hasta mediados de ese
siglo, cuando surgen las teorías cognitivas. La

Σ
β continuación: (1) Terminológicas: especifican
los términos que son usados para represen-
tar conocimiento en el universo de discurso.
Suelen ser usadas para unificar vocabulario
teoría conductista, desde sus orígenes, se cen-
tra en la conducta del individuo, tratando de
predecir esta conducta. Por lo tanto su objetivo
es conseguir una conducta determinada, para

δφ en un dominio determinado. (2) De informa-

ción: especifican la estructura de almacena-
miento de bases de datos. Ofrecen un marco
lo cual analiza el modo de conseguirla.

Para las “Teorías Conductistas”, lo relevante

λ
para el almacenamiento estandarizado de in- en el aprendizaje es el cambio en la conducta
formación. observable de un sujeto, es decir, cómo este
(3) De modelado del conocimiento: especifican actúa ante una situación particular. La con-

ψθ
conceptualizaciones del conocimiento. Contie-
nen una rica estructura interna y suelen estar
ajustadas al uso particular del conocimiento
que describen. (4) Ontologías de dominio: Es-
ciencia (que no se ve) es considerada como
una “caja negra”. Como se mencionó anterior-
mente, estas teorías no están interesadas
particularmente en los procesos internos de la

ϕ
tas ontologías son específicas para un dominio
en concreto. Por ejemplo, una ontología en el
dominio de los Sistemas de Información Geo-
gráfica. (5) Ontologías de tareas: estas ontolo-
persona, dado que para estas teorías solo es
posible hacer estudios de lo observable, no
importando las actividades mentales que ocu-
rren en estos procesos. Los conductistas defi-

α
gías representan las tareas que son suscepti-
bles de realizar en un dominio en concreto. (6)
Ontologías generales: van a representar los
datos generales y no específicos de un domi-
nen el aprendizaje solo como la adquisición
de nuevas conductas o comportamientos. Por
lo tanto las personas solo son receptores pa-
sivos de información.

Σ
θ β

Cognitivismo
La psicología cognitiva es una rama de la Psi-
cología que se ocupa de los procesos a través
de los cuales el individuo obtiene conocimiento
del mundo. Según los cognitivistas, el aprendi-
zaje es un proceso mental de transformar, al-
macenar, recuperar y utilizar la información,
por lo tanto, la experiencia es un factor impor-
tante en el aprendizaje, dado que el aprendiza-
je no es solo un simple proceso de traslado de
la realidad, sino que una representación de di-
cha realidad.
Constructivismo
Uno de los más importante precursores del
constructivismo es Ausbel. El punto común de
las actuales elaboraciones constructivistas está
dado por la afirmación de que el conocimiento
no es el resultado de una mera copia de la
realidad, sino que más bien de un proceso di-
námico e interactivo a través del cual la infor-
mación externa es interpretada y reinterpretada
por la mente que va construyendo progresiva-
mente modelos explicativos cada vez más
complejos y potentes. Esto significa que el
aprendizaje constructivo supone una construc-
ción que es realizada a través de un proceso
mental que finaliza con la adquisición de un
conocimiento nuevo, entonces se puede enten-
der que los conocimientos previos que las per-
sonas poseen serán los claves para la cons-
trucción de nuevo conocimiento.
Una precisión necesaria de hacer respecto del
constructivismo y sus relaciones con la educa-
ción, consiste en aclarar la idea de que el co-
nocimiento está fuera y lo que el sujeto tiene
que hacer es incorporarlo o interiorizarlo, utili-
zando y apoyándose en sus experiencias y las
estructuras cognitivas que ya posee, es decir,
utilizar el conocimiento que ya posee. Desde la
perspectiva del constructivismo, todo conoci-
miento nuevo que el sujeto adquiere es pro-
101
ducto de un proceso constructivo, es decir, se
α
apoya en conocimientos anteriores que supo-
nen una actividad mental por parte de quien lo
adquiere.
Σ
β
Resumiendo, tenemos que el modelo construc-
tivista se centra en la persona y en las expe-
riencias previas que esta posee y con las cua- δφ
λ
les junto con la nueva información que percibe
logra crear nuevas estructuras mentales.
ψθ
ENFOQUES PEDAGÓGICOS PARA LA INS-
TRUCCIÓN: INSTRUCTIVISTA Y CONSTRUC-
TIVISTA
Dentro de la educación y el proceso de ense-
ñanza podemos destacar dos grandes enfo-
ques en cuanto al modo de instrucción a utili-
zar, es decir, cuál será la tendencia utilizada ϕ
para lograr enseñar. Gros determina dos posi-
bles enfoques en este proceso, que son: Ins-
tructivismo y Constructivismo (Gros, 1995). α
Considerando el enfoque constructivista, tene-
mos que la educación a distancia ha permitido
el poder integrar este enfoque, dado que la-
mentablemente muchas veces resulta difícil el
Σ
β
poder aplicar netamente un enfoque constructi-
vista en el desarrollo de las clases presencia-
les, especialmente cuando es demasiada la δφ
λ
cantidad de alumnos. Es por este motivo que
resulta beneficioso el utilizar este tipo de plata-
formas que permiten poder desarrollar cursos y
ψθ
utilizar diversas actividades y elementos que
sirvan para formar al alumno. Por lo tanto, el
alumno será el centro de su aprendizaje y será
el resto de los elementos los encargados de
ϕ
formarle, pero siempre considerando que será
el propio alumno quien guíe su proceso de
aprendizaje y que además contará con la
orientación proporcionada por el profesor.
A continuación en la Tabla 2 se resumen los
principios que rigen cada uno de los enfoques
mencionados.
αΣ
θ β
 102

α Tabla 2. Comparación entre el enfoque Instructivo y el Constructivo (Martel A., 2004)

Σ
β Factores

Papel del estudiante

Enfoque Constructivista

Constructor activo de
Enfoque Instructivista

Persona que escucha y absorbe

δφ ξ conocimientos. Colaborador. información (pasivo)

Siempre aprendiendo

Concepción del aprendizaje Transformación de información Acumulación de información.

en conocimiento que tenga un

λ Tipos de actividades
sentido significativo.

Centradas en el estudiante, varían Mismo ejercicio para todos los

ψθ
según el ritmo de aprendizaje y la estudiantes.
cultura del alumno y según las
opciones de este último.

Tipo de ambiente De apoyo. Jerárquico.

ϕ Medición del éxito del proceso

de enseñanza /aprendizaje

Papel del educador

Calidad de la comprensión y
construcción de conocimientos.

Colaborador, guía, compañero,

Calidad de la información
memorizada.

Único poseedor de conocimientos

α
incluso a veces hasta aprendizaje Experto, transmisor de conocimiento

El objetivo del educador Que el alumno comprenda lo Que el alumno memorice y

que se le entrega absorba información

Σ
β EDUCACIÓN A DISTANCIA Y E-LEARNING uso de las tecnologías de información y las co-

δφ
municaciones (TIC).
Desde hace bastante tiempo ha surgido una
nueva tendencia conocida como “Educación a Plataformas e-learning
Distancia”, que consiste en un método educati-

λ
vo en el que los estudiantes no necesitan asis- Una plataforma de e-learning es una aplicación
tir físicamente a ninguna aula, es decir, las cla- Web que permite gestionar e impartir cursos en
ses no son desarrolladas de modo presencial. línea. A este tipo de plataformas también se les

ψθ
En un principio este tipo de método educativo
comenzó con los cursos por correspondencia,
en donde el material de estudio era enviado a
través del correo, así como también los cursos
denomina de forma abreviada LMS. Estas pla-
taformas combinan tanto hardware como soft-
ware, para lograr ofrecer todos los servicios
necesarios para la formación de las personas.

ϕ
realizados a través de otros medios como la
televisión, etc. Analizando las diversas características que
presentan las plataformas e-learning, podemos
Actualmente existe una nueva modalidad de observar una serie de ventajas y desventajas

α educación a distancia llamada e-learning, que

corresponde a un conjunto de actividades ne-
cesarias para la creación y uso de un entorno
de formación a distancia online mediante el
que se pueden aportar a la educación de los
alumnos.

Resumiendo, se debe considerar que el alum-

Σ
θ β

no debe tomar conciencia de que es él el único
protagonista en su formación, es decir, todo
dependerá de su dedicación y del interés en
aprender.
Enfoque instructivo o constructivo en las
plataformas e-learning
Al igual que los enfoques que pueden tomar
las clases presenciales, se ha podido estable-
cer que los cursos a distancia desarrollados
sobre plataformas e-learning también poseen
algunos de los dos enfoques anteriormente ex-
plicados, es decir, pueden ser plataformas con
un enfoque instructivo o constructivo. El enfo-
que de la plataforma será clasificado según el
modo en que el alumno podrá acceder y nave-
gar por el material dispuesto para el curso. Por
lo tanto, se pueden observar:
Plataformas con enfoque instructivo: para
aclarar un poco más estos enfoques, debemos
considerar que algunas plataformas e-learning
siguen una tendencia instructiva en cuanto a la
disposición de los contenidos del curso, esto
debido a que se establecen ciertas pautas a
seguir para el alumno.
Plataformas con enfoque constructivo: este
tipo de plataforma permite que el alumno pue-
da acceder a cualquier contenido de cualquier
curso, sin ningún tipo de restricción, es decir,
el alumno también podrá ser evaluado, pero
dicha evaluación no implicará en que el alumno
pueda o no visitar algún contenido. En este
caso las evaluaciones sirven más que nada
para que el alumno pueda medir los conoci-
mientos que ya ha adquirido y por ende refor-
zar aquellos en los que está más débil, pero en
ningún caso implican una restricción para el
alumno.
Elementos constructivos: aquellos elementos o
actividades que permiten al alumno la búsque-
da de conocimiento, experimentación, investi-
103
gación, creación, entre otras, es decir, aquellas
α
actividades que permitan que el alumno lleve a
cabo un aprendizaje en libertad, un aprendizaje
por descubrimiento y que pueda guiar su pro-
pio proceso de aprendizaje.
Σ
β
Elementos instructivos: aquellos elementos
que permitan realizar ciertas tareas de control δφ
λ
en el aprendizaje realizado por el alumno, es
decir, evaluaciones sobre el conocimiento ad-
quirido, como por ejemplo: pruebas, tareas ca-
ψθ
lificadas, etc., entre otras. Además de activida-
des conducentes a la transmisión de
conocimiento.
La predominancia de ambos tipos de elemen-
tos dependerá del diseñador de los contenidos
y del método de aprendizaje que se proponga.
ϕ
Criterios para diseñar un curso
Se consideran cinco puntos clave al momento
de diseñar un curso, estos dependerán en cier-
α
ta medida de la plataforma e-learning a utilizar
y del criterio y objetivos educativos del profe-
sor. (1) Metodología: antes de comenzar a im-
plementar un curso, se debe considerar un as-
Σ
β
pecto fundamental, que corresponde a la meto-
dología de enseñanza que deseamos utilizar,
es decir, orientar el curso hacia un enfoque δφ
λ
más tradicional (instructivo) o enfocarlo hacia
una visión más moderna (constructivo), o tam-
bién una combinación de ambos. (2) Estructu-
ψθ
ra General de un Curso: una vez elegida la
metodología a utilizar, se debe definir cuál será
la curricula del curso, es decir, definir cuáles
serán las unidades (o capítulos), subunidades,
ϕ
temas y actividades que se desarrollarán den-
tro del curso. (3) Disposición de la Informa-
ción: una vez elegida la estructura del curso,
este debe comenzar a ser rellenado, es decir,
se debe comenzar a elaborar la información
(documentos, transparencias, enlaces, videos,
etc.) y las actividades (tareas, ejercicios, pro-
yectos, etc.) que se desarrollarán, para luego
αΣ
θ β
 104

α disponerlas dentro del curso; (4) Flexibilidad y Existe una gran diversidad de roles que pue-

Σ
β Restricción de tiempo: la restricción y flexibi-
lidad de tiempo dependerán del objetivo del
curso, es decir, si se dispondrá el curso para
que este sea desarrollado en una determinada
den adquirir los agentes, dependiendo del en-
foque que se pretenda dar a la aplicación. En-
tre alguno de los posibles roles tenemos por
ejemplo:

δφ ξ fecha y lapso o si estará dispuesto para ser

utilizado en cualquier momento. Agentes utilizados ya sea como tutores (guías)
que tienen por objetivo el guiar completamente

λ
AGENTES EDUCATIVOS: ESTADO DEL ARTE el aprendizaje del alumno. También utilizar
agentes como compañeros de aprendizaje en
La aplicación de agentes inteligentes en el donde su objetivo es el de prestar ayuda al

ψθ
área educativa es una investigación que viene
desde hace ya algunos años. El campo de la
aplicación de la Inteligencia Artificial en la edu-
cación involucra la investigación en diversos
alumno como un compañero más de clases.
Otro rol podría ser el de alumno virtual, en don-
de el alumno humano tiene como objetivo el de
enseñar y guiar a este (agente).

ϕ
dominios como son: ciencia de la computación,
ciencia cognitiva, educación, psicología e inge- Existen aplicaciones en donde el agente es uti-
niería. lizado de forma individual, pero también existe
la opción de poder utilizar en una aplicación

α Las investigaciones y proyectos que serán aquí

resumidos buscan lograr con la utilización de
las nuevas tecnologías computacionales, en
educativa a un conjunto de agentes.

MODELO PROPUESTO

β
cuanto a agentes inteligentes se refiere, dar
Σ apoyo al aprendizaje, la exploración y la cola-
boración. (Pacheco 2005, Análisis, Desarrollo e
De los proyectos e investigaciones analizadas
no se ha encontrado una aplicación basada en
Implementación de un Modelo Integrador de agentes que permita contar con una herramien-

δφ
Sistemas Multi-Agentes y Sistemas Educativos,
Informe Interno Proyecto@Lis – Utem).
Aplicaciones de agentes inteligentes en el
ta educativa, que posibilite a los alumnos po-
der interactuar y ejercitar en un ambiente en
línea. Es por este motivo que surge la idea de
proponer un modelo que permita la integración

λ
área educativa de tres elementos que son: (1) Una agencia
(sistema multiagente); (2) Una plataforma e-
A continuación se resumirán algunas de las in- learning (plataforma para el desarrollo de cur-

ψθ
vestigaciones y proyectos que fueron conside-
radas para este trabajo, investigaciones y pro-
yectos para formar una perspectiva en cuanto
a algunas aplicaciones ya existentes de agen-
sos a distancia); (3) Un usuario.
La integración de estos tres elementos permiti-
rá proporcionar una nueva modalidad para la

ϕ
tes inteligentes en el área educativa. En la Ta-
bla 3 se resumen las aplicaciones anteriores:
Analizando los proyectos e investigaciones
enseñanza utilizando sistemas multiagentes.
Analizando las diversas relaciones entre estos
3 elementos tenemos:

α aquí presentadas se ha podido observar la

existencia de variadas formas y enfoques utili-
zados para implementar esta nueva tecnología
en el área educativa.
Relación plataforma-usuario: consiste en la
unión entre la plataforma y el usuario. Esta
unión es lograda mediante la “interfaz huma-
na”, es decir, aquí el usuario utilizará sus senti-
Σ
θ β

Tabla 3. Resumen de las aplicaciones de agentes inteligentes en el área educativa
Proyecto
Sistemas de agentes para la diversidad de
aprendizajes humanos.
Agentes enseñables (Teachables Agents):
Combinando la teoría de aprendizaje y pa-
ciencia computacional.
Representación del metaconocimiento
para el diseño de escenarios de aprendi-
zaje.
Un diseño multiagente para un ambiente
“Peer-Help”.
Una metodología para la construcción de
agentes inteligentes educativos
El Systemion: un nuevo modelo de agente
para el diseño de Sistemas Tutores Inteli-
gentes (ITS).
Ontología para la meta de aprendizaje
apoyada por la teoría de la Formación de
Grupos Oportuna (OFG).
Hacia el análisis inteligente interacción del
aprendizaje colaborativo.
dos para visualizar, escuchar, interactuar, co-
municarse, etc., con la plataforma, la cual pro-
porciona información en diversos medios que
son entendibles para el usuario. Ej.: documen-
tos, imágenes, videos, etc. Dicha plataforma
será la que contendrá el curso que podrá desa-
rrollar el usuario. Por lo tanto el acceso, nave-
gación e interacción que realizará el usuario
con la plataforma a través de la interfaz huma-
na, es lo que permite lograr la unión entre es-
tos dos elementos. Cabe considerar que este
tipo de relación ya existía, dado que la interac-
ción entre un usuario y una plataforma se viene
dando desde hace bastante tiempo. La Figura
2 representa esta relación:
105
α
Características
– Agente con diversos roles para apoyar la diversidad de aprendizajes.
Σ
β
δφ
Ej.: experto amistoso, estudiante virtual, tutor, compañero de aprendi-
zaje, etc.
– Agente visto como un estudiante virtual, donde el alumno humano será
el encargado de enseñarle. “Aprendizaje enseñando”.
– El metaconocimiento es conocimiento sobre conocimiento. Utilización
del conocimiento que ya se posee para adquirir nuevo conocimiento
(constructivismo). λ
– Diseñar sistemas multiagentes para generar entornos de aprendizaje
colaborativos.
– Agentes que agregan características inteligentes a los software educa-
ψθ
tivos
– Agentes con sus propias interfaces capaces de asistir a profesores y
alumnos
ϕ
α
– Agente adaptable que permite el diseño de ITS que guían y se adecuan
mejor a las necesidades del usuario.
β
– Cambiar de un aprendizaje individualizado a un aprendizaje colaborati-
vo. Utilizando a los agentes representantes de cada alumno.
Σ
– Sistema de aprendizaje colaborativo inteligente, que permita lograr una
efectiva interacción entre los estudiantes
δφ
λ
Relación agencia-usuario: consiste en la
unión entre la agencia y el usuario. Esta unión
es lograda mediante el uso de un “agente
ψθ
usuario”, que será el que se comunique e inte-
ractúe con el o los respectivos agentes que se
encuentran en la agencia. Por lo tanto, aquí el
usuario no tiene contacto directo con la agen-
ϕ
cia, es decir, no existe una interfaz humana,
dado que es imposible para un humano comu-
nicarse directamente con un agente mediante
algún tipo de lenguaje natural. Es por este mo-
tivo que se proporciona al usuario un agente
representante (agente usuario), quien será el
que se relacione con la agencia mediante len-
guajes y protocolos de agentes. Por lo tanto el
αΣ
θ β
 106

αΣ
β
δφ ξ Figura 2. Relación plataforma-usuario

λ usuario cuando ejecute su agente usuario, de- miento de la plataforma. Este módulo integra-

ψθ berá asignarle su propio nombre, es decir, si el

nombre del usuario es Óscar, entonces deberá
asignarle a su agente usuario el mismo nombre
(Óscar), logrando de este modo ligar al agente
dor esta compuesto por aquellos códigos de
programa que permiten la interconexión desde
la agencia a la base de conocimiento de la pla-
taforma.

ϕ
usuario con el respectivo usuario al que repre-
senta. Por lo tanto, todo lo que ocurra median-
te el ciclo de vida del agente representante
será responsabilidad del usuario respectivo al
El objetivo en sí es que los usuarios desarro-
llen diversos ejercicios, que les serán dis-
puestos en la plataforma, utilizando para ello

α que representa. La interacción lograda entre la

agencia y el agente representante del usuario
es lo que permite lograr la unión entre estos
su agente usuario, que será el encargado de
interactuar con el agente de la agencia corres-
pondiente a evaluar dicho ejercicio (agencia-

β
dos elementos. Cabe considerar que este tipo usuario). Logrando, mediante esta interacción
Σ de relación también ya existía, dado que un
usuario puede utilizar un agente representante
y comunicación, obtener los resultados del
ejercicio. El agente de la agencia utilizará su
que interaccione con otros en representación base de conocimiento para analizar el ejerci-

δφ
de él. La figura 3 representa esta relación:
Relación agencia-plataforma: consiste en la
unión entre la agencia y la plataforma. Esta
cio y entregar los respectivos resultados. Es-
tos resultados serán integrados a la base de
conocimiento de la plataforma, a través del
agente de la agencia, el cual utilizará el mó-

λ unión hasta el momento no había sido imple-

mentada. Es por este motivo que se propone
un nuevo módulo llamado VIPU, que será el
dulo VIPU para llevar a cabo este proceso.
Una vez integrados los resultados a la base
de conocimiento, el alumno podrá acceder a

ψθ que permita integrar el conocimiento de los

agentes de la agencia, en la base de conoci-
la plataforma y mediante esta interfaz humana
podrá visualizar el resultado de su ejercicio.

ϕ
α
β
Figura 3. Relación agencia-usuario

Σ
θ

Figura 4. Relación agencia-plataforma
Además de poder visualizar el resultado me-
diante la plataforma, también el usuario podrá
hacer uso del agente Sniffer para ver a nivel
de agentes el intercambio de mensajes que se
genera durante la interacción entre su agente
representante y el agente correspondiente de
la agencia.
La particularidad de este nuevo módulo (VIPU)
es que permite relacionar dos tecnologías, es
decir, unir la tecnología de agentes con la tec-
nología de la educación a distancia, relación
que hasta ahora no había sido desarrollada e
implementada.
Con esta unión se logra dar un nuevo enfoque
a lo que es la educación a distancia y además
se logra contribuir con una nueva aplicación de
agentes en el área educativa. La Figura 4 re-
presenta esta nueva relación:
Este modelo resulta ser novedoso, dado que
actualmente no existen aplicaciones basadas
en agentes que hayan implementado esta idea.
Existe en la actualidad una infinidad de plata-
formas de educación a distancia que desarro-
llan e implementan diversos cursos, proporcio-
nando materiales, medios de ejercitación,
evaluaciones, etc., pero ninguna de ellas traba-
ja en conjunto con agentes. También existen
agencias en donde los agentes representantes
del usuario pueden interactuar.
107
αΣ
β
δφ
λ
La diferencia radica básicamente en que en
este nuevo modelo el alumno podrá acceder a
los materiales e información proporcionados
ψθ
por la plataforma. Pero además podrá ejercitar
en un ambiente en línea, gracias a que dispon-
drá de agentes representantes que serán los ϕ
encargados de interactuar con la agencia, que
contará con los respectivos agentes que eva-
luarán los ejercicios. Por lo tanto el alumno de-
berá desarrollar los ejercicios y posteriormente
α
utilizar a su agente representante, de modo de
lograr obtener los resultados de sus ejercicios,
que serán entregados por el correspondiente
agente evaluador de dicho ejercicio. En este
Σ
β
paso es en donde entra en juego el nuevo mó-
dulo integrador, dado que cuando se vayan ge-
nerando los resultados este módulo permitiría δφ
λ
la integración de ellos en la base de conoci-
miento de la plataforma. Logrando con todo
este proceso que el alumno visualice el resulta-
ψθ
do de su ejercitación mediante la interfaz de la
plataforma. Como se puede apreciar, este nue-
vo modelo resulta ser innovador.
ϕ
En este trabajo se desarrolló e implementó un
curso prototipo de agentes inteligentes, debido
a la directa relación con el tema de este traba-
jo. Cabe mencionar que en este trabajo no se
utilizaron ontologías para los agentes de la
agencia, dado que el objetivo que se buscaba
principalmente era lograr establecer el nuevo
módulo, es decir, lograr la integración de los
αΣ
θ β
 108

α resultados de los ejercicios en la base de co- gue al usuario, mediante la integración de es-

Σ
β nocimiento de la plataforma. Por esta razón se
utilizaron ejercicios sencillos sobre agentes y
en la agencia se dispusieron los correspon-
dientes agentes que responden a los agentes
tos a la base de conocimiento de la platafor-
ma, a través del módulo VIPU, que permitirá
que el usuario posteriormente los visualice a
través de la plataforma. La Figura 5 represen-

δφ ξ del alumno. Por lo tanto los resultados entrega-

dos por estos agentes se basan en la interac-
ción y los mensajes que se envían mutuamen-
ta la unión de todos los elementos.

Resumiendo, podemos observar de la Figura 5

λ
te, es decir, no existe una ontología respectiva que el usuario se divide en dos. Por un lado
que permita analizar el código del agente del está su interacción con la plataforma a través
usuario para ver si es correcto o no. de su interfaz humana y por otra parte está su

ψθ
La idea es que este modelo sirva de base
para la posterior implementación de otros ti-
pos de cursos, los cuales deberán proporcio-
interacción con la agencia a través de su agen-
te usuario que lo representa. Por último obser-
vamos la aparición de un nuevo elemento que
corresponde al módulo VIPU, que será el que

ϕ
nar las ontologías respectivas para el conoci-
miento que deberá poseer el agente
encargado de evaluar los ejercicios. También
se deberá proporcionar el conjunto de accio-
permita integrar el conocimiento del agente en
la base de conocimiento de la plataforma.
MODELO IMPLEMENTADO

α nes (Behaviours) que deberán tomar los agen-

tes usuarios y los agentes de la agencia, para
el logro de sus objetivos. De modo que este
La idea principal de este modelo ya se había
especificado y es la de lograr la unión de

β
genere los resultados del ejercicio y los entre- tres elementos: una plataforma e-learning,
Σ

δφ
λ
ψθ
ϕ
α
β
Figura 5. Relación agencia-plataforma-usuario

Σ
θ

una agencia y un usuario. Resumiendo, te-
nemos que la relación entre la plataforma y
el usuario ya existe. Dicha relación se logra
mediante la interfaz humana, dado que el
alumno podrá acceder, navegar e interactuar
con la plataforma utilizando para ello sus
sentidos.
Por otra parte la relación entre la agencia y el
usuario también ya existía. Esta relación se
logra mediante la representación del usuario a
través de un agente usuario, es decir, el usua-
rio va a poseer un agente que será el que lo
represente y lleve a cabo todas las acciones
necesarias en representación de él. Por lo
tanto este agente usuario será el que se co-
munique e interactúe con los agentes de la
agencia.
Por último la relación entre la agencia y la plata-
forma, era la que no existía. Es por este motivo
que se diseñó el módulo VIPU, que será el en-
cargado de integrar a la base de conocimiento de
la plataforma el conocimiento de los agentes de
la agencia.
Figura 6. Modelo Propuesto
109
La idea es la de proporcionar a los usuarios ma-
α
terial teórico y además diversos ejercicios que le
permitan ejercitar sobre ciertos temas del curso.
La particularidad es que dichos ejercicios serán
desarrollados en línea, es decir, el alumno conta-
Σ
β
rá con un agente usuario que representará a su
ejercicio. Este agente usuario interactuará con el
agente evaluador respectivo de la agencia, en
donde este último será el encargado de entregar
δφ
los resultados del ejercicio, integrándolos a la
base de conocimiento de la plataforma, utilizando
el módulo VIPU para este proceso. λ
Cualquier curso que se desee desarrollar bajo
este modelo, deberá implementar una parte teóri-
ca (material) y una parte práctica (ejercicios y
ψθ
evaluaciones) que resultan ser el centro de este
modelo (ver Figura 6).
Para este trabajo se utilizará como prototipo un
ϕ
curso de agentes inteligentes, por lo tanto dentro
de la plataforma a utilizar (MOODLE) se desarro-
llará e implementará dicho curso siguiendo como α
β
base el modelo propuesto. Este curso contará
con una parte teórica consistente de documentos Σ
δφ
λ
ψθ
ϕ
α
β
Σ
θ
 110

α y una parte práctica consistente en ejercicios y agente en tiempo real, lo cual permite interactuar

Σ
β evaluaciones.

En este trabajo no se implementaron ontologías,

dado que el objetivo a lograr era poder integrar
y ejecutar los requerimientos del proceso de las
“ontología definida por el profesor” entre todos
los agentes interactuando, lo cual representa a
todos los usuarios interactuando en el mismo

δφ ξ los resultados generados en la agencia, a la

base de conocimiento de la plataforma. Por esta
razón es que se dio prioridad al diseño del mó-
dulo que permitiera esta integración. Con los
tiempo real con los agentes que los representan
a cada uno de ellos.

Del concepto de procesos asíncronos y sin-

λ ejercicios propuestos se logró comprobar la po-

sibilidad de integrar los resultados de comunica-
ciones e interacciones de agentes directamente
crónicos de los modelos e-lerning se avanza
al paradigma de los procesos equivalentes y
equitativos, es decir, acumula las nuevas ca-

ψθ en la plataforma. Quedando como trabajo futuro

el diseñar las ontologías y agentes respectivos
para cada curso que se desee implementar. La
Figura 6 muestra el modelo.
racterísticas manteniendo las anteriores. Au-
mentando la validez y actualización del uso de
agentes inteligentes en diferentes ámbitos de
la educación.

ϕ AGRADECIMIENTOS

Este trabajo se desarrolló como parte del Proyecto

El trabajo futuro permitirá la inclusión de cual-
quier asignatura dentro de este modelo, a partir
de que el profesor, además de diseñar sus clase,

α @LIS Technet, de la Comunidad Europea (Project

Nº IST-1999-10176) y del Proyecto @LIS-UTEM
de la Universidad Tecnológica Metropolitana.
ejercicios, instrumentos de evaluación, tiempo de
preguntas y respuestas, deberá diseñar la onto-
logía, es decir, la representación sistemática del

β
conocimiento de sus asignatura representados
Σ CONCLUSIONES sobre una base de conocimiento para que los
agentes puedan interactuar con ella.
Se logro construir, implementar y poner en ope-

δφ
ración un prototipo de agente inteligente integra-
do al proceso de enseñanza, específicamente a
un curso prototipo utilizando la asignatura de
agentes inteligente, el cual está operativo es
BIBLIOGRAFÍA
AI-ED, 1999. “Artificial Intelligence in Education.
Open Learning Environments: new computa-

λ http://alis.utem.cl/alis/

Se validó la implementación y la programación

tional technologies to support learning, explo-
ration and collaboration”.
Álvarez A. Villar J., Benavides C., García I., 2001.

ψθ
del modulo VIPU, que es capaz de dialogar en “Experiencia en el desarrollo de un Sistema
lenguaje de agentes y lenguajes reconocidos por Multi-Agente”. Escuela de Ingeniería, Univer-
plataformas e-learning. sidad de León.
Arroyo A., 2002. “Lenguajes de Comunicación de

ϕ
Se validó el proceso de bautizar los agentes inte-
ligentes con la identidad del usuario que lo utili-
za, obteniendo de esta forma que mientras dure
el ciclo de vida del agente dentro del proceso,
Agentes”. Universidad Carlos III de Madrid.
Ausbel D., 1983. “Psicología Educativa. Un punto
de vista cognoscitivo”. Editorial Trillas.
Bartlett F., 1932. “Remembering”. Cambridge:

α
será responsable de todas sus acciones como si
el mismo usuario las realizara.
El sistema opera basado en plataformas multi-
Cambridge University Press.
Bellifemine F, Caire G, Trucco T., 2002. JADE
Administrador’s Guide. TILAB y U. de Parma.
Brophy S., Biswas G., Katzlberger T., Bransford

Σ
θ β

J. and Schwartz D., 1999. “Teachable agents:
Combining Insights from Learning Theory and
Computer Science”.
Calzadilla M., 2001. “Aprendizaje colaborativo y
tecnologías de la información y la comunica-
ción”. Universidad Pedagógica Experimental
Libertador, Venezuela.
Canut M., Gouarderes G., Sanchis E., 1999. “The
Systemion: a new agent model to design Inte-
lligent tutoring system”.
Carretero M., 1997. “Qué es el constructivismo?
Desarrollo cognitivo y aprendizaje”. Cons-
tructivismo y educación. Progreso México
pp. 39-71.
Córtes Ulises, 2004. “Ontologías”. Universidad
Politécnica de Cataluña.
Delgado S., 2003. “e-learning. Análisis de plata-
formas gratuitas.”. Universidad de Valencia.
Dinos J., 2004. “Arquitectura de un sistema basa-
do en agentes para la recuperación de meta-
datos RDF en base a una ontología de docu-
mentos”. Universidad de Puerto Rico.
Durfee & Rosenschein, 1994. “Distributed Pro-
blem Solving and Multi-Agent Systems:
Comparisons and Examples.” 27 de mayo
de 1994.
Eggen y Kauchak, 1999. “Estrategias docentes.
Enseñanza de contenidos curriculares y de-
sarrollo de habilidades de pensamiento”.
Editorial Fondo de Cultura Económica de
Argentina.
Garamendi J., 2004. “Agentes Inteligentes:
JADE”. Programa de Doctorado: Informática y
Modelización Matemática. Universidad Rey
Juan Carlos.
García-Serrano A., Hernández J., 2002.‘“Agentes
Inteligentes y Sistemas Multiagente”. Curso
de Doctorado en Ciencias de la Computación
e Inteligencia Artificial, Univ. Politécnica de
Madrid.
Gluz J., 2002. “Linguagens de Comunicação en-
tre Agentes: Fundamentos e Propostas de
Padronização”. Universidade Federal do Rio
Grande do Sul. Instituto de Informática.
González J., 2001. “Protocolo de Interacción Re-
quest”. Universidad de Vigo.
111
Gros, B., 1995. Nuevas tecnologías, … por el
α
dilema instruir-construir”. Substratum, vol.
II, N6.
Gruber, T., 1993. “A Trans Approach to porta-
ble ontology specifications” Knowledge Ac-
Σ
β
quisition.
Keeling H., 1999. “A methodology for building In-
telligent educational agents”.
Les J., Cumming G., Finch S., 1999. “Agents sys-
δφ
tems for diversity in human learning”.
Martel A., 2004. “La evaluación social e individual
en la era de la educación a distancia en la λ
globalización”. Revista Electrónica de Investi-
gación y Desarrollo Educativo Vol. 6, Nº 1.
Mergel B., 1998. Diseño instruc. y teoría del
aprendizaje. Comunicaciones y Tec. Educ. U.
ψθ
de Saskatchewan. Canadá.
Mosquera C & Santos A, 2001. “Análisis y estu-
dio experimental de herramientas basadas en
agentes”. Depto de Tecnología de la Informa-
ϕ
ción y las Comunicaciones, Universidad La
Coruña.
Neches, R; Fikes, R., 1991. “Enabling Tech- α
β
nology for Knowledge Sharing”. AI Magazi-
ne, 12(3).
Neisser, 1967. “Cognitive Psychology”. ‘New
Σ
York: Apleton-Century-Crofts.
δφ
Nwana H., 1996. Software Agents: An Overview.
Knowledge Engineering Review. Cambridge
Press.
Paquette G., 1999. “Meta-Knowledge representa-
tion for learning scenarios engineering”.
Pérez T., Gutiérrez J., López R., González A. &
Vadillo J., 2001. “Hipermedia, adaptación,
λ
ψθ
constructivismo e instructivismo”. Inteligencia
Artificial, Revista Iberoamericana de Inteligen-
cia Artificial. Nº 12 (2001). U. del País Vasco
UPV-EHU Depto. Lenguajes y Sistemas Infor-
ϕ
máticos.
Russell, S., Norvig, P., 1995. “Artificial Intelligen-
ce: A Modern Approach”. Ed. Prentice Hall.
Tiffin J. y Rajasingham L., 1997. “En Busca de la
α
clase virtual”. Paidós, pág. 35.
Vassilena J., Greer J., McCalla G., Zapata D.,
Deters R., Grant S., 1999. “A multi-agent de-
sign of Peer-Help environment”.
Σ
θ β
 112

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 113

αΣ
β
δφ
λ
ψθ
Aplicación de OWL para Desarrollar un Demostrador
ϕ
de Oferta Turística Basado en Agentes Inteligentes α
An Application of OWL for Developing a Demo of Tourist Offering Based on
Intelligent Agents Σ
β
Edgar E Casasola Murillo; Kryscia D Ramírez Benavides
δφ
λ
ψθ
ϕ
1 Universidad de Costa Rica, Escuela de Ciencias de la Computación e Informática, San José, Costa Rica, 1000, casasola@ecci.ucr.ac.cr α
β
2 Universidad de Costa Rica, Escuela de Ciencias de la Computación e Informática, San José, Costa Rica, 1000, kramirez@ecci.ucr.ac.cr

Σ
θ
 114

αΣ
β
δφ ξ
λ
ψθ
ϕ
αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β
 115

ABSTRACT α
This paper presents a analysis of the ontology development process towards modelling a real world
domain of knowledge. The resulting product is part of the @Lis TechNet project in which eight universi-
ties from seven countries from Europe and America participate. One of the @Lis TechNet project goals is
Σ
β
to develop a demo of the use of intelligent agents in the tourism domain. Critical aspects associated to
the modelling of the domain using the OWL language, development tools and methodologies are identi-
fied. This article is useful for those individuals and research institutions interested in the creation of δφ
λ
ontologies and multi-agent systems.

Key words: Intelligent agents, Domain modelling, Ontologies, OWL, Protégé, Multi-agent systems.

RESUMEN

Este documento presenta un análisis del proceso de desarrollo de ontologías para modelado de un
dominio de conocimiento del mundo real. El producto obtenido es parte del proyecto @Lis TechNet en el
ψθ
cual participan ocho universidades de siete países de Europa y América. Uno de los objetivos del
proyecto @Lis TechNet es desarrollar un demostrador del uso de tecnologías de agentes inteligentes en
el dominio turístico. Se identifican los aspectos críticos asociadas al modelado del dominio utilizando el ϕ
lenguaje OWL, metodologías y herramientas de desarrollo. Este artículo es de utilidad para aquellos
individuos y centros de investigación interesados en la creación de ontologías y sistemas multiagente.

Palabras clave: Agentes inteligentes, modelado de dominios, ontologías, OWL, Protégé, Sistemas
α
multiagente.
Σ
β
INTRODUCCIÓN

El desarrollo de sistemas basados en agentes

inteligentes hace necesario el modelado de do-
minios específicos mediante lenguajes para
definición de ontologías. Las ontologías sirven
como un vehículo para alcanzar un entendi-
miento entre las partes involucradas: usuarios,
desarrolladores y programas o agentes. Por
definición una ontología es una especificación
explícita y formal de una conceptualización
compartida [14]. Las ontologías definen con-
ceptos y relaciones que describen algún domi-
nio de una manera formal, legible y utilizable
por los agentes. En otras palabras, son una
conceptualización que ofrece una visión abs-
tracta y simplificada del mundo real [9]. Sin
embargo, en la actualidad, son muchos los as-
pectos involucrados en el desarrollo de ontolo-
gías para resolver problemas de aplicación en
la vida real. δφ
El desarrollo de ontologías se ve afectado por:
la complejidad del dominio que se modela, el
conocimiento del dominio, el lenguaje de repre- λ
sentación de conocimiento seleccionado, la
versatilidad de la herramienta de edición y el
uso que se va a dar a la ontología en el con-
texto de sistemas multiagente.
ψθ
El proyecto @LIS TechNet: Red de Demostra-
ción de Tecnología Avanzada para la Educa- ϕ
α
ción y las Aplicaciones Culturales en Euro-
pa y América Latina tiene como uno de sus
objetivos el desarrollar un demostrador turísti-
co haciendo uso de tecnología de agentes inte-

Σ
θ β
 116

α ligentes. Dicho demostrador pretende generar ontologías se utilizan para desarrollar una

Σ
β de manera automática itinerarios turísticos per-
sonalizados a los gustos del usuario para que
un turista europeo (España, Inglaterra o Italia)
pueda viajar a Latinoamérica (específicamente
aplicación basada en agentes inteligentes
para oferta turística. En forma particular se
pretende:

δφ ξ a Chile, Costa Rica, Cuba o México); el desa-

rrollo del demostrador es liderado por la Uni-
versidad de Costa Rica e involucra a universi-
• Identificar las características asociadas a la
metodología de desarrollo, el lenguaje de
representación y las herramientas utiliza-

λ
dades de los demás países. En este sistema el das.
turista puede solicitar este servicio a través de • Describir el producto obtenido, en cuanto a
una PC o PDA. El agente del usuario estará en la cantidad de ontologías y clases que fue

ψθ
constante monitoreo y comunicación con el tu-
rista para informarle de actividades y hechos
inesperados que puedan suceder con su itine-
rario [1].
necesario crear, la representación semánti-
ca y reutilización.
• Discutir aspectos relacionados con la evolu-
ción del modelado del dominio y su depen-

ϕ
La definición y construcción de una ontología
es una tarea compleja, ya que no existe una
metodología estándar suficientemente probada
dencia con respecto al problema de la vida
real que se quiere resolver mediante el uso
de agentes.

α y flexible. Por otra parte la escogencia del len-

guaje para modelar depende de las caracterís-
ticas y condiciones que se necesiten especifi-
No se pretende dar detalles de la implementa-
ción ni dar una metodología para la construc-
ción de ontologías, sino contar la experiencia

β
car del dominio. Aunque existe una serie de
Σ metodologías para guiar en la construcción de
ontologías, cada una fue creada paralelamente
a la solución de un problema particular o para
el modelado de un dominio específico (ver [6],
del modelado del dominio aplicando OWL al
problema que se desea resolver. Debido a que
el demostrador será de carácter académico, se
procurará aprovechar al máximo las posibilida-
des que ofrecen los estándares y las herramien-

δφ [13] y [14]). Otras ontologías solamente repre-

sentan pequeños dominios asociados a proble-
mas de juguete.
tas Open Source disponibles a través de Inter-
net tales como: el lenguaje de ontologías OWL,
y el editor de ontologías Protégé (versión 3.0).

λ En la actualidad existen muchos lenguajes

para la creación de ontologías; sin embargo,
La metodología de análisis de este documento
se basa en los principios para la construcción

ψθ
no todos permiten el mismo nivel de expresivi-
dad a la hora de definir ontologías. Uno de los
lenguajes más recientes para la elaboración de
ontologías fue OWL, disponible a partir de di-
de ontologías de Van Heijst, Schereiber y Wie-
linga [15], los cuales son:
1 Claridad y Objetividad.

ϕ
ciembre de 2003. OWL puede ser considerado 2 Completitud.
un sucesor de los lenguajes RDF/RDF-S y 3 Coherencia.
DAML+OIL del Consorcio World Wide Web 4 Máxima Extensibilidad Monótona.
(W3C). 5 Principio de Distinción Ontológica.

α El propósito de este documento es analizar el

proceso de desarrollo del dominio modelado
mediante el uso de ontologías en OWL. Las
6
7
8
9
Diversificación.
Modularidad.
Estandarización.
Minimización.
Σ
θ β

En la sección 2 se da una visión general de los
conocimientos y tecnologías necesarias para la
compresión de este documento: la metodología
de desarrollo, el lenguaje de representación y
las herramientas utilizadas. En la sección 3 se
describe el proceso de desarrollo de las ontolo-
gías, así como cuál fue el producto obtenido.
En la sección 4 se brinda un análisis de resul-
tados, discutiendo aspectos como la evolución
de las ontologías y la dependencia que existe
con respecto al problema de la vida real que
quiere resolver. Por último, en la sección 5 se
dan las conclusiones del presente documento.
MARCO TEÓRICO
En esta sección se proporciona una breve ex-
plicación de la metodología, los lenguajes y las
herramientas utilizadas en el desarrollo de las
ontologías del dominio turístico. En la sección
2.1 se describe la metodología de desarrollo.
En las secciones 2.2, 2.3 y 2.4 se da una vi-
sión general de los lenguajes para la construc-
ción de las ontologías RDF/RDF-S, DAML+OIL
y OWL. Por último, en la sección 2.5 se descri-
be la herramienta para la edición de ontologías
Protégé y los plugins que se integraron.
Metodología de Ushold y King para la Cons-
trucción de Ontologías
Los lineamientos de esta metodología son los
siguientes (ver [6], [13] y [14]):
1. Identificación del propósito y alcance. Se
especifica el contexto de aplicación y el
punto de vista del modelado.
2. Construcción de la ontología. Se divide
en tres pasos:
2.1 Captura de la ontología. Se identifican
los conceptos principales y las relaciones
de los mismos del dominio de interés.
2.2 Codificación. Se representa explícita-
mente el conocimiento adquirido en el
paso 2.1 en un lenguaje formal.
117
2.3 Integración ontologías existentes. Se
α
tendrá durante cualquier o en ambos
procesos, captura y codificación; las
preguntas: cómo, cuáles y si va a usar-
se alguna ontología previamente exis-
Σ
β
tente, reutilizando así conocimiento.
3. Evaluación. Se realiza un diseño definitivo
y se evalúa con pruebas basadas en reque- δφ
λ
rimientos y preguntas del mundo real, para
comprobar que la ontología represente el
dominio y cumpla lo requerido.
ψθ
4. Documentación. Se realiza la documenta-
ción que debe ser hecha en paralelo a los
puntos anteriores y debe ser indexada y co-
locada con las ontologías existentes para su
posible reutilización.
RDF (Resource Description Framework) y
RDF-S (RDF Schema) ϕ
RDF es una especificación propuesta por W3C
que ofrece interoperatividad entre aplicaciones
que intercambian información comprensible por
α
páginas Web (Web Semántico), para proporcio-
nar una infraestructura que soporte actividades
de metadatos y se basa en XML [9].
Σ
β
El modelo de datos básico de RDF consta de
tres tipos básicos de objetos (ver [4] y [9]):
δφ
λ
• Recursos. Un recurso es cualquier cosa
descrita por una expresión RDF. Los recur-
sos siempre son nombrados por un URI
ψθ
(Uniform Resource Identifiers), que no es
más que un identificador.
• Propiedades. Una propiedad es un aspec-
to específico, una característica, un atribu-
ϕ
to o una relación usada para describir un
recurso.
• Declaraciones. Una declaración RDF es un
recurso junto con una propiedad más el va-
lor de la propiedad para ese recurso.
El modelo formal RDF es una tripleta; cada tri-
pleta representa una declaración de una rela-
αΣ
θ β
 118

α ción entre las cosas denotadas por los nodos RDF en sí mismo no puede construir ontolo-

Σ
β que se unen, y consta de tres partes [9]:

• Sujeto (también llamado recurso).

• Predicado (también llamado propiedad).
gías, necesita de RDF-S para poder ser un len-
guaje para ontologías. Ya que, RDF solo repre-
senta las instancias, mientras que el RDF-S
representa la estructura de las instancias defi-

δφ ξ • Objeto (otro sujeto o valor de la propiedad).

La colección de tripletas conforma el modelo

niendo clases y propiedades.

DAML+OIL (DARPA Agent Markup Language

λ
de datos gráfico (grafo), esto puede ser ilustra- + Ontology Inference Layer)
do por un diagrama con nodos y arcos dirigidos
en los que cada tripleta se representa como un DAML+OIL es un lenguaje de marcado semán-

ψθ
link nodo-arco-nodo (ver Figura 1). Los nodos
de un gráfico RDF son sus sujetos y sus obje-
tos, y la dirección del arco es el predicado y
siempre apunta hacia el objeto [9].
tico para los recursos Web. Está construido ba-
sado en estándares de W3C como RDF y el
RDF-S, y extiende estos lenguajes modelando
primitivas más poderosas. Recuérdese que el

ϕ
lenguaje RDF está escrito en XML, usando
XML Namespaces, y URIs.

DAML+OIL toma lo mejor de los lenguajes DAML

α y OIL, e intenta combinarlos en un lenguaje que

proporciona una manera de buscar información
en la Web y, en un futuro, “entienda” la informa-

β
ción que se encuentra en la Web [3].
Σ OWL (Web Ontology Language)

OWL es hasta ahora la representación de co-

δφ nocimiento más expresiva, dado que agrega

más vocabulario para describir propiedades y
clases, relaciones entre las clases, axiomas de

λ Figura 1. Representación de una tripleta RDF. Adaptado clases, restricciones de cardinalidad, igualdad
de [4]. y desigualdad, combinaciones booleanas de
clases, características y restricciones de pro-

ψθ RDF cuenta también con el RDF-S, para ex- piedades, y clases enumeradas (ver [5] y [10]).
presar relaciones entre los niveles de las cla-
ses abstractas que describen relaciones entre Este lenguaje es el último estándar en los lengua-
los niveles de las instancias aceptables. El jes para construir ontologías, desarrollado por

ϕ RDF-S es como una especie de diccionario y W3C. Tiene fundamentos matemáticos formales
define los términos que se utilizarán en una basados en las Lógicas Descriptivas1, eso permite
declaración RDF y le otorgará significados es- usar un razonador (por ejemplo RACER2) para
pecíficos [2]. comprobar la ontología según se construya.

α 1
2
La rama lógica dentro de la familia de los marcos (frames) son subconjuntos de la lógica de primer orden computacionalmente tratables.
Razonador (clasificador) basado en lógicas descriptivas. Motor de inferencia semántico para desarrollar ontologías y proveedor de la lógica modal KM

β
con calificadas modalidades y axiomas.

Σ
θ
 119

Los elementos básicos del lenguaje OWL gía de clases y propiedades, y las instan-
α
son [10]:

• Clases (conceptos)
• Propiedades (atributos o relaciones)
cias de esas clases y propiedades.
• OWL DL. Es un lenguaje que se extiende
de OWL Lite, pero permitiendo la elabora-
ción de ontologías con más detalle semánti-
Σ
β
• Individuos (instancias)

En la Figura 2 se muestra un ejemplo utilizan-

do los elementos básicos de OWL. Se mues-
tran los conceptos Persona, País y Mascota;
las propiedades (en este caso son relaciones)
co. Diseñado para proveer máxima expresi-
vidad, manteniendo completitud y
computabilidad, con un conjunto de caracte- δφ
λ
rísticas deseables para que los sistemas ra-
zonen.
• OWL Full. Es un lenguaje que se extiende

casadoCon, viveEnPaís y tieneMascota; y dife-
rentes individuos asociados a cada concepto
representado.
ψθ
de OWL DL. Diseñado para dar libertad sin-
táctica de RDF/RDF-S sin garantías compu-
tacionales. Esto ocasiona que es improba-
ble que cualquier software para
razonamiento pueda dar un razonamiento
completo para cada rasgo de OWL Full.

Las funcionalidades que brinda OWL son: ϕ

•
•
•
Listas delimitadas.
Restricciones de cardinalidad.
Expresiones de clase.
α
•
•
•
•
Tipos de datos.
Clases definidas.
Enumeraciones.
Equivalencia.
Σ
β
Figura 2. Ejemplo de los elementos básicos de OWL.
•
•
•
Extensibilidad.
Semántica formal.
Herencia. δφ
λ
• Inferencia.
OWL proporciona tres lenguajes expresivos, di- • Restricciones locales.
señados para el uso de comunidades específi- • Restricciones calificadas.

cas de implementadores y usuarios. A conti-
nuación se describen en forma breve estos
lenguajes [10]:
ψθ
• Reification3.
El demostrador exige representar el dominio lo
más real que se pueda, que existan restriccio-

• OWL Lite. Es un lenguaje simple, pero es
más expresivo que el RDF/RDF-S. Diseña-
do para proveer a los usuarios un conjunto
funcional y fácil uso, ofreciendo un razona-
miento eficiente. Permite definir una ontolo-
ϕ
nes, relaciones entre los conceptos y que se
pueda tener un buen razonamiento de la repre-
sentación del dominio. Por lo tanto, RDF/RDF-S
ofrece los mínimos requerimientos para el desa-
rrollo de una ontología y poco razonamiento.

α
β
3 Transformación de algo abstracto en concreto.

Σ
θ
 120

α DAML+OIL une RDF/RDF-S con una capa de Editor de Ontologías: Protégé

Σ
β inferencias para ontologías, brindado una se-
mántica precisa para la descripción de significa-
dos de los términos y un buen razonamiento.
Las ontologías pueden ser modeladas con la
ayuda de editores de ontologías. Existe gran va-
riedad de editores, sin embargo, el seleccionado

δφ ξ Por su parte, OWL no agrega más funcionali-

dades a DAML+OIL, sino toma los elementos
que este lenguaje proporciona para adecuarlos
por el proyecto @Lis TechNet es el desarrollado
por la Universidad de Stanford: Protégé.

λ
y mejorarlos. Esto lo logra agregando más ele- Protégé, aparte de ser Open Source, está ba-
mentos a las distintas funcionalidades para en- sado en JAVA y es extensible. Este editor
riquecer la representación semántica e inferen- permite crear ontologías en varios lenguajes,

ψθ
cia, desaparecen algunos elementos cuyo
significado era opaco para agentes que utilizan
el RDF/RDF-S, elimina ciertos elementos y
cambia el nombre de otros manteniendo su
entre ellos RDF/RDF-S, DAML+OIL y OWL;
pero no solo define la estructura de una onto-
logía, sino también permite definir y adminis-
trar instancias. También es un marco de tra-

ϕ
función. Por estos motivos este fue el lenguaje
escogido para el desarrollo de las ontologías,
específicamente OWL DL porque da máxima
expresividad, manteniendo completitud, razo-
bajo de bases de conocimiento, está
integrado con un GUI y diferentes plugins
para agregarle más funcionalidad. En la Figu-
ra 3 se muestra la pantalla de edición de Pro-

α namiento y computabilidad. tégé [11].

Σ
β
δφ
λ
ψθ
ϕ
α
β
Figura 3. Editor de ontologías Protégé, versión 3.0.

Σ
θ
 121

A continuación se cita los plugins para OWL Los plugins que ofrecen las herramientas de vi-
α
que se utilizaron para el desarrollo de las onto-
logías:

• OWLViz. Plugin para el despliegue gráfico

sualización permiten dar una perspectiva visual
de la ontología, más compresible para un ser
humano, permitiendo asimilar mejor las relacio-
nes entre conceptos. En la Figura 4 se muestra
Σ
β
de las jerarquías de las clases, permitiendo
explotar a formatos de imágenes.
• ezOWL. Plugin para el despliegue gráfico
el despliegue gráfico del plugin OWLViz.

Al tener una visión general sobre la metodolo- δφ

λ
de las jerarquías de las clases, muestra las gía de construcción, la descripción de los len-
propiedades y restricciones de cada clase. guajes y las herramientas utilizadas para la
• BeanGenerator. Plugin para producir cla- construcción de las ontologías; se planteará en

ψθ
ses JAVA a partir de la ontología, para que la siguiente sección la descripción del producto
JADE puede utilizar y entender la ontología obtenido.

ϕ
αΣ
β
δφ
λ
ψθ
ϕ
α
β
Figura 4. Jerarquía de clases de la ontología Itinerary, utilizando el plugin OWLViz.

Σ
θ
 122

α DESCRIPCIÓN DEL MODELADO Y DESA- cual está desarrollada en JAVA y es lo que en-

Σ
β RROLLO DE LAS ONTOLOGÍAS

El desarrollo de las ontologías necesarias para

el demostrador del dominio de oferta turística
tienden los agentes.

Lo primero a realizar fue adquirir un conocimien-

to en el dominio, las fuentes de información y

δφ ξ del proyecto @LIS TechNet le correspondió al

equipo de trabajo de la Universidad de Costa
Rica. Todo el diseño giró en torno al demostra-
conocimiento utilizadas fueron: expertos en el
área, sitios Web y guías turísticas. Seguidamen-
te se estudiaron una serie de lenguajes para la

λ
dor y el enfoque del dominio turístico, el cual construcción de ontologías y se analizaron las
fue complejo. características de la aplicación que se desarro-
llaría, para elegir el lenguaje que permitiera el

ψθ
La importancia de las ontologías en el proyec-
to, es que proporcionan una forma de repre-
sentar y compartir el conocimiento utilizando
un vocabulario común y permiten usar un for-
nivel de expresividad que se desea para el de-
mostrador. Con el lenguaje elegido, se procedió
a realizar una lista de las ontologías necesarias
para representar el dominio, y se comenzó a

ϕ
mato de intercambio de conocimiento. Aparte,
en el proyecto, se utilizan para definir el esque-
ma de bases de conocimientos necesario para
guardar las instancias de los conceptos que se
modelar siguiendo la metodología de Ushold y
King, y utilizando la herramienta Protégé para la
construcción de las ontologías. Al terminar esta
etapa, las ontologías fueron utilizadas para los

α modelan; y cada clase de las ontologías es tra-

ducida de OWL a clases JAVA, debido a que
los agentes están sobre la plataforma JADE, la
propósitos mencionados en el párrafo anterior.
En la Figura 5 se muestra un diagrama del pro-
ceso de desarrollo realizado.

Σ
β
δφ
λ
ψθ
ϕ
α
β
Figura 5. Diagrama de iteración del modelado y desarrollo de las ontologías.

Σ
θ

Como el objetivo del proyecto es desarrollar un
planeador de itinerarios a gusto de las preferen-
cias de los turistas, en los cuáles se va a planifi-
car el hospedaje, las actividades a realizar y el
transporte; el problema a resolver se llegó a re-
presentar en seis ontologías principales:
• Itinerario (Itinerary). Describe y modela la
información necesaria del itinerario que se
le hace al turista, se incluyen las acciones
planeadas y las restricciones y preferencias
del usuario.
• Proveedor (Provider). Describe y modela
la información relacionada con los provee-
dores de los servicios que se planifican en
el demostrador.
• Reservaciones (Reservations). Describe y
modela la información relacionada con las
reservaciones de los servicios que se plani-
fican en el demostrador.
• Hospedaje (Accommodation). Describe y
modela el servicio de hospedaje.
• Actividades (Activities). Describe y mode-
la el servicio de ofrecer la realización de
actividades turísticas.
• Transporte (Transport). Describe y modela
el servicio de transporte.
De estas ontologías se encontraron conceptos
importantes a representar que produjeron otras
cinco ontologías:
• Aeropuerto (Airport). Describe y modela la
información sobre aeropuertos.
• Lugares geográficos (GeographicPlaces).
Describe y modela los lugares geográficos
(continente, país) y la división política de
cada país destino del demostrador involu-
crado en el proyecto.
• Contingencias (Contingencies). Describe
y modela el plan de contingencia asociado a
cualquier problema que pase en el plan de
viaje de algún turista.
• Precio (Price). Describe y modela el con-
cepto de precio.
123
• Dirección (Address). Describe y modela el
α
concepto de dirección.
Como uno de los beneficios de las ontolo-
gías es ser reutilizables, antes de empezar
Σ
β
la construcción de las ontologías se busca-
ron en la Web ontologías que tuvieran que
ver con el dominio en cuestión. De las onto- δφ
λ
logías halladas se reutilizó aproximadamen-
te un 75%, pero cuatro de ellas se empeza-
ron desde cero porque no se encontró
ψθ
ninguna ontología al respecto, lo cual a nivel
general la reutilización ayudó en un 50% en
el desarrollo.
Con ese 50% se comenzó la implementación
y documentación de las ontologías. La mayo-
ría de las ontologías enumeradas fueron
reutilizadas, adaptándolas y traduciéndolas a ϕ
OWL (algunas de ellas estaban en RDF/RDF-
S o DAML+OIL) para el propósito de este
proyecto. α
Las ontologías obtenidas de este proyecto, a
su vez, pueden ser reutilizadas en un 100% en
otras aplicaciones, donde se ofrezca caracte-
rísticas similares a las de este proyecto. Las
Σ
β
más generales como Provider, Airport, Geogra-
phicPlaces, Price y Address pueden ser utiliza-
das un 100% por cualquier aplicación que ne- δφ
λ
cesite representar esos conceptos.
A todas las ontologías, tanto las desarrolladas
ψθ
como las adaptadas, se les incluyeron una je-
rarquía de clases propuesta por JADE (plata-
forma del proyecto) para facilitar la traducción
de OWL a JAVA. Las clases auxiliares de esta
ϕ
jerarquía son [8]:
• Concepto. Expresan nociones o entidades
que existen, es decir, que pueden de cierta
forma materializarse.
– Acción del agente. Corresponde a las
preguntas o consultas que un agente
puede recibir.
αΣ
θ β
 124

α – AID. Corresponde al ID del agente. ANÁLISIS DEL PROCESO DE DESARROLLO

Σ
β • Predicado. Definen estados y relaciones
que se pueden dar entre los conceptos. Los
predicados solo tienen dos posibles valores:
verdadero o falso.
En la Tabla 1, de la sección anterior, se puede
observar que se construyeron un total de 11
ontologías. Aunque en un principio solo se pen-

δφ ξ En la Tabla 1 se observa un resumen de las

ontologías desarrolladas para el demostrador
só en construir tres de ellas: itinerario, activida-
des y transporte, ya que se usaría la ontología
de hospedaje hecha para otro proyecto de

λ
de oferta turística, donde se muestra el número @LIS.
de versión, el número de clases y propiedades
de la ontología, y si para su construcción se Durante el desarrollo de las tres ontologías fue

ψθ
reutilizó conocimiento de otras ontologías y
qué porcentaje fue reutilizado.
El problema más importante que se presentó al
necesario definir otras ontologías que refleja-
ran conceptos que eran importantes a repre-
sentar, por ejemplo: una reservación de algún
servicio, los precios de los servicios y la canti-

ϕ
modelar el dominio fue el poco conocimiento
acerca de él y la escasa ayuda de expertos, lo
cual provocó una gran tiempo conociendo el
dominio a representar y, muchas veces, malas
dad de dinero disponible para el viaje, las di-
recciones, entre otros.
Para la representación de estos conceptos se

α representaciones del mismo. Por lo que se

aconseja, antes de modelar, conocer bien lo
que se representará y buscar ayuda de exper-
utilizaron ontologías ya modeladas, que se
adaptaron a las necesidades del problema a
resolver y fueron traducidas a OWL; por ejem-

β
tos en el tema.
Σ En la sección siguiente se planteará un análisis
del producto obtenido, discutiendo la evolu-
ción, la importancia y la dependencia al proble-
plo: la ontología que representa cantidades de
dinero, se le añadieron propiedades para pasar
el valor de cualquier tipo de moneda a la mo-
neda euro (ya que será el tipo de moneda utili-
zado), y se quitó una clase que para los fines

δφ ma en cuestión del modelado del dominio. del proyecto no tenía sentido. En cuanto a las

λ
Tabla 1. Resumen de ontologías del demostrador de oferta turística

Ontología Nº versión Nº clases Nº propiedades Se reutilizó Porcentaje de

otra ontología reutilización

ψθ Itinerary
Provider
Reservations
1.4
1.2
1.2
27

9
5
47
15
14
No
Sí
Sí
0
75
50

ϕ
Accommodation 1.2 10 22 Sí 75
Activities 1.4 81 63 No 0
Transport 1.2 7 24 Sí 50
Airport 1.1 5 12 Sí 90

α
GeographicPlaces 1.2 8 26 No 0
Contingencies 1.1 6 10 No 0
Price 1.0 5 11 Sí 90
Address 1.2 6 12 Sí 90

Σ
θ β

ontologías desarrolladas sin reutilizar ninguna
otra ontología, realmente no fueron difíciles de
modelar, a excepción de la ontología de activi-
dades, como se puede apreciar en la Tabla 1
es la más grande.
Inicialmente se detectaron 55 actividades turís-
ticas a representar, aparte de las otras clases
que conformaban la ontología de actividades.
Estas actividades se redujeron a 40, ya que
era necesario disminuir la cantidad de clases a
representar; el criterio de selección fue dejar
todas aquellas actividades de importancia tu-
rística que fueran culturales, recreativas y eco-
lógicas. Esta disminución se dio porque la defi-
nición de cada una de las clases, y el paso de
las ontologías a tablas del esquema de bases
de datos y a clases JAVA, provocaba una gran
cantidad de trabajo que no era necesario, ya
que se está implementando un demostrador de
la tecnología de agentes inteligentes y no una
aplicación de uso comercial.
Tomando en cuenta todas las ontologías desa-
rrolladas por el equipo de trabajo de Costa
Rica, se había generado un total de 185 cla-
ses, y al eliminar las 15 clases que representa-
ban actividades quedaron 170 clases. Esto
ahorró tiempo y esfuerzo valioso, que se utilizó
en otras tareas del proyecto; además, disminu-
Figura 6. Jerarquía de clases de la ontología original de Accommodation, utilizando el plugin OWLViz.
125
yó la cantidad de código a utilizar y la entrada
α
de datos a la base de datos.
Algo que se aprendió con el desarrollo de las
ontologías, es que el modelado del dominio de-
Σ
β
pende casi un cien por ciento del problema que
se quiere resolver; aunque se puedan reutilizar
algunas ontologías, estas deben ser adaptadas δφ
λ
al propósito de la aplicación a realizar. Para
ilustrar esto, al principio de esta sección se
mencionó que se usaría la ontología de hospe-
ψθ
daje hecha para otro proyecto de @LIS, la cual
tuvo que ser revisada y modificada, ya que no
era apta para el proyecto en cuestión. La Figu-
ra 6 muestra la ontología original, y la Figura 7
muestra la adaptación de esta para cumplir los
fines del proyecto.
La ontología original no tenía una clase que de- ϕ
finiera el concepto de diferentes tipos de hospe-
daje que existen, solo definía lo que era un sitio
y un lugar de hospedaje, sus facilidades y el
concepto de cama, por lo cual se le agregó este
α
concepto que se necesitaba, y así seguir con el
estándar utilizado en las otras dos ontologías
que representan los otros servicios que serán
planeados (actividades y transporte).
Σ
β
A continuación se realizará el análisis del pro-
ducto obtenido basándose en los principios δφ
λ
ψθ
ϕ
α
β
Σ
θ
 126

αΣ
β
δφ ξ
λ
ψθ Figura 7. Jerarquía de clases de la ontología adaptada de Accommodation, utilizando el plugin OWLViz.

ϕ para construir ontologías, mencionados en la

introducción:
6. Diversificación. La diversificación fue algo
que no está de todo desarrollado, dado que

α 1. Claridad y Objetividad. Cada uno de los

conceptos de las ontologías fueron descri-
la herencia múltiple se evitó por motivos
que la plataforma JADE está basada en
JAVA, y este lenguaje de programación no

β
tos de una manera clara y en lenguaje natu- soporta la herencia múltiple.
Σ ral, siempre pensando en el objetivo que te-
nía cada uno en relación al uso del mismo
7. Modularidad. El acoplamiento entre las cla-
ses es muy bajo, ya que se representaron
en el demostrador. conceptos que son disjuntos, este principio

δφ
2. Completitud. Cada ontología cuenta con
los conceptos, propiedades e instancias ne-
cesarias para describir lo que se desea re-
presentar en el demostrador.
se cumple al cumplir el de distinción ontoló-
gica.
8. Estandarización. El estándar utilizado
fue: en los nombres de clases (conceptos)

λ 3. Coherencia. Con la ayuda de RACER se

comprobó la consistencia de las inferencias
que se obtiene a partir de las ontologías.
se usa mayúscula en la primera letra de
cada palabra, en los nombres de propie-
dades se usa la primera palabra toda en

ψθ 4. Máxima Extensibilidad Monótona. Las je-

rarquías que se encuentran en las ontolo-
gías son a lo máximo de dos niveles, y se
realizaron generalizaciones para agrupar de
minúscula y las siguientes palabras la pri-
mera letra en mayúscula, en las enumera-
ciones se usa todo en mayúscula, y los
individuos (instancias) depende de los da-

ϕ lo específico a lo más general y evitar así la

inconsistencia de las clases en alguna jerar-
quía.
5. Principio de Distinción Ontológica. Cada
tos que se llenen.
9. Minimización. Las clases están agrupadas
y representadas en jerarquías de dos nive-
les (máximo), se usaron generalizaciones

α una de las clases de las ontologías están

definiendo conceptos que son disjuntos,
pero eso no indica que estas clases pueden
para agrupar de lo específico a lo más ge-
neral, y con este proceso se fueron pasan-
do las propiedades y restricciones que com-

β
tener instancias que compartan. partían a la clase padre.
Σ
θ

Para finalizar, en la siguiente sección se expo-
nen las conclusiones obtenidas de la experien-
cia del modelado del dominio y la realización
de este documento.
CONCLUSIONES
En este artículo se detalla el proceso de desa-
rrollo del modelado del dominio de oferta tu-
rística, para desarrollar un demostrador basa-
do en agentes inteligentes, los cuales son: la
metodología de desarrollo, el lenguaje de re-
presentación, las herramientas utilizadas, la
cantidad de ontologías y clases que se crea-
ron para representar el dominio, la reutiliza-
ción de otras ontologías, y la dependencia con
respecto al problema de la vida real que se
quiere resolver.
Las primeras etapas del desarrollo de onto-
logías requirieron de un gran esfuerzo, debi-
do a que representar el conocimiento de al-
gún dominio es complejo. La experiencia
deja claro que no es cosa de unos minutos,
es más, se necesita conocer bien el dominio
a modelar y contar con expertos antes de
representarlo.
Hasta el momento, el desarrollo de las onto-
logías para el demostrador se basa en una
conceptualización del dominio, por lo que
hace falta representar los procesos que se
llevan a cabo en el mismo. Este aspecto está
pendiente de representar mediante el uso de
predicados (por ejemplo: hacerItinerario
(Constraints)) y acciones (por ejemplo:
planear(Itinerario)) [8].
Al mismo tiempo, como producto de la partici-
pación en este proyecto, se está realizando el
trabajo de tesis: Evaluación de esquemas de
modelado de dominios específicos mediante el
uso de ontologías, para optar por el grado de
Magíster Scientiae en Computación e Informá-
tica.
127
AGRADECIMIENTOS
α
Este artículo es producto del trabajo realizado
como parte del proyecto @Lis TechNet donde
participan las siguientes universidades y cen-
Σ
β
tros de investigación [1]:
• Universitat Politècnica de Catalunya (Es- δφ
λ
paña).
• University of Bath (Inglaterra).
• Università degli Studi di Parma (Italia).
ψθ
• Instituto Superior Politécnico José Antonio
Echeverría (Cuba).
• Universidad de Costa Rica (Costa Rica).
• Universidad Tecnológica Metropolitana
(Chile).
• Instituto Politécnico Nacional (México).
• Instituto Tecnológico y de Estudios Superio-
res de Monterrey (México). ϕ
REFERENCIAS
[1] Proyecto @LIS Technology Net”. Comisión
α
Europea, Oficina de Cooperación Euro-
peAid, Proyecto @LIS. 2003. URL: http://
europa.eu.int/comm/europeaid/projects/
alis/index_en.htm
Σ
β
[2] Brickley, D. & Guha, R.V., Editores. “Re-
source Description Framework (RDF)
Schema Specification 1.0”. W3C, 27 marzo δφ
λ
2000. URL: http://www.w3.org/TR/2000/
CR-rdf-schema-20000327/
[3] Connolly, D.; Van Harmelen, F.; Horrocks, I.;
ψθ
McGuinness, D. L.; Patel-Schneider, P. F. &
Stein, L. A., Editores. “DAML+OIL (march
2001) Reference Description”. W3C Note, 18
Diciembre 2001. URL: http://www.w3.org/TR/
ϕ
2001/NOTE-daml+oil-20011218/
[4] Daconta, M.C., Obrst, L.J. & Smith, K.T.
“The Semantic Web: A Guide to the Future
of XML, Web Services, and Knowledge
Management”. 1ª ed., Editorial Wiley. In-
dianápolis, Indiana, 2003.
[5] Dean, M. & Schreiber, G., Editores. “OWL
Web Ontology Language Reference”. W3C
αΣ
θ β
 128

α Recommendation, 10 febrero 2004. URL: brero 2004. URL: http://www.w3.org/TR/

Σ
β http://www.w3.org/TR/2004/REC-owl-ref-
20040210/
[6] Fernández López, M. & Gómez Pérez, A.
“Overview and Analysis of Methodologies
2004/REC-owl-features-20040210/
[11] Protégé Community. “Proyecto Protégé”. 4 fe-
brero 2005. URL: http://protege.stanford.edu
[12] Studer, S.; Benjamins, R. & Fensel, D..

δφ ξ for Building Ontologies”. Knowledge Engi-

neering Review (KER). Vol. 17, Nº 2, pp.
129-156. 2002.
“Knowledge Engineering: Principles and
Methods”. Data and Knowledge Enginee-
ring, 25, pp. 161-197. 1998.

λ
[7] Honrubia López, F. J.. “Introducción a las [13] Uschold, M. & Gruninger, M.. “Ontologies:
Ontologías”. Escuela Universitaria Politéc- Principles, Methods and Applications”.
nica de Albacete. 2000. Knowledge Engineering Review, Vol. 11,

ψθ
[8] JADE Community. “JADE: Java Agent
DEvelopment Framework”. 26 julio 2004.
URL: http://sharon.cselt.it/projects/jade
[9] Klyne, G. & Carroll, J. J., Editores. “Re-
Nº 2, pp. 93-155. Junio 1996. URL: http://
www.aiai.ed.ac.uk/project/pub/documents/
1996/96-ker-intro-ontologies.ps
[14] Uschold, M. & King, M.. “Towards a Metho-

ϕ
source Description Framework (RDF):
Concepts and Abstract Syntax”. W3C Re-
commendation, 10 febrero 2004. URL:
http://www.w3.org/TR/2004/REC-rdf-con-
dology for Building Ontologies”. Workshop
on Basic Ontological Issues in Knowledge
Sharing. 1995.
[15] Van Heijst, G., Schereiber, A.T. & Wielinga,

α cepts-20040210/
[10] McGuinness, D. L. & Van Harmelen, F.,
Editores. “OWL Web Ontology Language
B.J. “Using Explicit Ontologies in KBS De-
velopment”. International Journal of Hu-
man and Computer Studies, Vol. 46, Issue

β
Overview”. W3C Recommendation, 10 fe- 2-3, pp. 183-292. Febrero/marzo 1997.
Σ

δφ
λ
ψθ
ϕ
αΣ
θ β

NORMAS DE PUBLICACIÓN
A los autores
Los autores interesados en publicar artículos o
papers en la revista “Ingeniería al día” deben
enviar sus trabajos ajustados a las Normas de
Publicación que se detallan más abajo. Los
temas deben enmarcarse dentro de las áreas
de las Ciencias de la Ingeniería en su acepción
más amplia. El trabajo presentado no debe te-
ner “Derechos de Autor” otorgados a terceros y
su contenido será de responsabilidad exclusiva
de los autores. El Editor se reserva el derecho
a realizar modificaciones de edición, para una
mejor presentación del trabajo. Se podrán pre-
sentar trabajos en idioma inglés y en idioma
español.
Recepción de colaboraciones: Deberán en-
viarse grabadas en CD, utilizando procesador
de textos, formateado para impresora láser, ad-
juntando tres copias impresas del original. En-
viar a la Facultad de Ciencias Físicas y Mate-
máticas de la Universidad Central de Chile,
Santa Isabel 1186, Santiago – Chile. Para efec-
tos de comunicación, remitir las consultas al
siguiente e-mail: editor@ucentral.cl
Las figuras, fotografías y tablas más su le-
yenda explicativa se recibirán con un número
correlativo indicando su posición dentro del
texto en una hoja individual con impresión lá-
ser u otro tipo de impresión de nitidez seme-
jante.
Los artículos no podrán tener una extensión
mayor a 7 páginas y deberán respetar el si-
guiente formato: Papel tamaño carta, 21,59 x
27,94 cm; Márgenes superior 2 cm, inferior 2
cm, izquierdo 2,54 cm y derecho 2 cm; Título
del artículo, centrado en negritas, con letras
mayúsculas tipo Time New Roman 14 pt; Títu-
los del texto, centrados en negritas, con letra
Time New Roman 12 pt con un número máximo
129
de 10 palabras clave; Nombre de los autores a
α
continuación del título del trabajo indicando:
nombre, apellidos y un supraíndice numérico
para su individualización; antes de un párrafo
dos líneas en blanco; Subtítulos, al margen en
Σ
β
negritas, con letra Time New Roman 12 pt;
Cuerpo del texto con letra Time New Roman
12 pt; después de un párrafo una línea en blan- δφ
λ
co; el interlineado general del texto debe ser
de 1.5 líneas.
ψθ
Características de las publicaciones
El Comité Editorial será el encargado de auto-
rizar la publicación de los trabajos. Los origina-
les de los artículos recepcionados no serán de-
vueltos. Las modificaciones se indicarán con
notas explicativas, las que serán devueltas al
autor con los comentarios correspondientes. El ϕ
Editor comunicará al autor principal la publica-
ción o no de su trabajo. El Comité Editorial po-
drá considerar trabajos presentados en congre-
sos y reuniones científicas nacionales e
α
internacionales.
El título principal deberá ir en inglés y en es-
pañol, indicar claramente la materia del artícu-
Σ
β
lo, ser breve, pero preciso en la idea que re-
presente.
δφ
λ
El texto comienza con un abstract en inglés y
un resumen en español de no más de 250
(doscientos cincuenta) palabras, donde debe
ψθ
precisarse brevemente: Objetivos, Metodolo-
gía, Resultados y Conclusiones.
La introducción deberá orientar al lector res-
ϕ
pecto al problema presentado e incluye nor-
malmente: naturaleza del problema, antece-
dentes o trabajos previos, propósito o
significancia del artículo, no debiendo tener
una extensión mayor a una página.
El cuerpo del artículo o paper contendrá la pri-
mera divulgación de los resultados del trabajo
αΣ
θ β
 130

α del o de los autores, escrito de tal modo que los tre paréntesis cuadrado y se listarán según el

Σ
β lectores (en el presente o futuro) puedan com-
prender plenamente y utilizar lo que se divulga.
Por lo tanto, debe presentarse información sufi-
ciente a fin de que los posibles usuarios pue-
orden de aparición, como en el siguiente
ejemplo:

Para: 1) Revistas [1] J.A Rich, G.A. Farral; “Va-

δφ ξ dan: (a) evaluar las observaciones, (b) repetir

los experimentos, y (c) evaluar los procesos in-
telectuales (¿justifican los datos las conclusio-
cuum arc recovery phenomena” Proc. IEEE,
Vol. 52, pp.1293, November 1964.

λ
nes del autor?). La redacción de los trabajos 2) Libros [1] J.D. Kraus; “Antenas”, New York;
será de carácter objetivo. El autor cuidará que McGraw Hill, 1950.
la forma se ajuste a las normas de presenta-

ψθ
ción, corrección en el lenguaje y uso de termino-
logías aceptadas por la comunidad científica.
Las conclusiones deberán claramente explici-
Para la individualización de los autores se
especificará como pie de página para indicar
la lista de personas o instituciones que cola-
boraron, profesión, institución, dirección pos-

ϕ
tar lo que se demuestra en el trabajo, su rele- tal y dirección electrónica de cada uno de
vancia, ventajas, limitaciones y aplicación de ellos. Estas llamadas deberán utilizar números
los resultados. arábigos.

α Los agradecimientos no deberán extenderse

más allá de tres líneas.
Periodicidad: La revista “Ingeniería al día”
se editará semestralmente y de acuerdo a los
recursos disponibles podrá publicarse una edi-

β
Las referencias se indicarán con número en- ción especial.
Σ

δφ
λ
ψθ
ϕ
αΣ
θ β

INFORMATION FOR CONTRIBUTORS
Manuscripts intended for publication in the
magazine “Ingeniería al día” should comply
with the following norms: The topic of the work
must relate to the Sciences of Engineering,
construed in a wide sense. The paper must not
have its copyrights transferred to third party. Its
contents are in the authors’ entire
responsibility. If necessary, the editor reserves
the right to carry out minor modifications of the
text, in order to achieve a better presentation of
the work. Papers may be written in English or
in Spanish.
Manuscripts must be submitted recorded in a
CD, written using a text processor and
formatted for a Laser printer. Three written
copies of the text, including tables and figures,
must accompany the CD. The manuscript must
be sent to the Facultad de Ciencias Físicas y
Matemáticas de la Universidad Central de
Chile, Santa Isabel 1186, Santiago CHILE.
Further communications or enquires can be
addressed to editor@ucentral.cl
Figures, photographs and tables, including
their respective captions, should be
numbered consecutively. Each must be
submitted in a separate page. Figures and
tables must be presented using a Laser
printer, or another medium of similar
resolution. Their respective position in the
text should be indicated.
Papers may not be longer than 7 pages and
must comply with the following format: Paper
size should be A4 (or letter-sized 21,59 x 27,94
cm). Top and bottom margins should be 2 cm,
left margin 2,54 cm and right margin, 2 cm. The
title of the article should be centred in bold
letters, 14-pt Times New Roman, leaving two
blank spaces before the initial paragraph.
Subtitles should be left-justified and written in
bold 12-pt Times New Roman. The body of the
131
text must be typed, using 12-pt normal Times
α
New Roman and leaving a blank line at the end
of each paragraph. The interlinear spacing
should be set at 1.5 spaces.
Σ
β
Publication characteristics
The Editorial Committee will be in charge of δφ
λ
approving the publication of each paper.
Contributions accepted for publication will not
be returned. Editing or rejections will be
ψθ
notified promptly. The Editorial Committee may
consider for publication papers presented in
national and international conferences and
scientific meetings.
The main title of the article should be in both
English and Spanish. It must state clearly the
issue of the work. The title should be brief, but ϕ
its meaning must be stated clearly and
precisely.
The manuscript begins with an abstract of no
α
more than 250 (two hundred and fifty) words. It
must briefly state the objectives, methods,
results and conclusions of the work.
Σ
β
The introduction must help the reader to
understand the problem presented, and
normally includes information about the nature δφ
λ
of the problem, its antecedents or reference to
previous work and the purpose and meaning of
the paper. Its length must not exceed one
ψθ
page.
The body of the paper must contain the first
disclosure of the result of the authors’ work,
ϕ
stated in such a way that its readers (present
or future) can fully understand and use these
results. Therefore, it must present enough
information in order to permit a potential user to
(a) evaluate the observations, (b) repeat the
experiments and (c) evaluate the intellectual
processes (do the data presented justify the
authors’ conclusions?). The style must be
αΣ
θ β
 132

α objective and impersonal. The author must Magazines: [1] J.A. Rich, G.A. Farra: “Vacuum

Σ
β heed that the article complies with the
standards of publication, language and specific
terms usually accepted by the respective
scientific community.
arc recovery phenomena”. Proc. IEEE, Vol. 52,
pp. 1293, November 1964.

Books: [1] J.D. Kraus, “Antenas”, New York; Mc

δφ ξ Conclusions must be clearly presented, and

must declare what is demonstrated by the work
Graw Hill, 1950.

A footnote following the name of the authors

λ
presented, as well as its possible relevance. It shall state name of the persons or institutions
must also state the advantages, limitations and which collaborated in the work, as well as the
applications of its results. professions and institutions of the authors, and

ψθ
their mail addresses. These footnotes must be
Acknowledgements should not be longer than written in Arabic numbers.
three lines.
Periodicity: The magazine “Ingeniería al día”

ϕ
References will be written with numbers in will be published biannually. According to
parenthesis, and shall be listed at the end of available resources, special editions may be
the paper as follows: published.

αΣ
β
δφ
λ
ψθ
ϕ
αΣ
θ β