LMAN: Máquina Abstracta del Cálculo NTCC para Programación ...
152
LMAN: M´ aquina Abstracta del C´ alculo NTCC para Programaci´ on Concurrente de Robots LEGO MARIA DEL PILAR MU ˜ NOZ RINCON ANDRES RENE HURTADO RODRIGUEZ PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA INGENIERIA DE SISTEMAS Y COMPUTACION SANTIAGO DE CALI 2003
Transcript of LMAN: Máquina Abstracta del Cálculo NTCC para Programación ...
LMAN: Maquina Abstracta del CalculoNTCC para Programacion Concurrente de
Robots LEGO
MARIA DEL PILAR MUNOZ RINCON
ANDRES RENE HURTADO RODRIGUEZ
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
INGENIERIA DE SISTEMAS Y COMPUTACION
SANTIAGO DE CALI
2003
LMAN: Maquina Abstracta del CalculoNTCC para Programacion Concurrente de
Robots LEGO
MARIA DEL PILAR MUNOZ RINCON
ANDRES RENE HURTADO RODRIGUEZ
Tesis de grado para optar el tıtulo de
Ingeniero de Sistemas y Computacion
Director
CAMILO RUEDA CALDERON
Profesor titular, Universidad Javeriana-Cali
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
INGENIERIA DE SISTEMAS Y COMPUTACION
SANTIAGO DE CALI
2003
Santiago de Cali, Enero 19 del 2004
Ingeniero
ANDRES JARAMILLO BOTERO
Decano Academico de la Facultad de Ingenierıa
Pontificia Universidad Javeriana
Ciudad
Certifico que el presente proyecto de grado, titulado “LMAN: Maquina Abstracta del
Calculo NTCC para Programacion Concurrente de Robots LEGO” realizado por MA-
RIA DEL PILAR MUNOZ RINCON y ANDRES RENE HURTADO RODRIGUEZ,
estudiantes de Ingenierıa de Sistemas y Computacion, se encuentra terminado y puede
ser presentado para sustentacion.
Atentamente,
Ing. CAMILO RUEDA CALDERON
Director del Proyecto
Santiago de Cali, Enero 19 del 2004
Ingeniero
ANDRES JARAMILLO BOTERO
Decano Academico de la Facultad de Ingenierıa
Pontificia Universidad Javeriana
Ciudad
Por medio de esta, presentamos a usted el proyecto de grado titulado “LMAN: Maquina
Abstracta del Calculo NTCC para Programacion Concurrente de Robots LEGO” para
optar el tıtulo de Ingeniero de Sistemas y Computacion.
Esperamos que este proyecto reuna todos los requisitos academicos y cumpla el proposi-
to para el cual fue creado, y sirva de apoyo para futuros proyectos en la Universidad
Javeriana relacionados con la materia.
Atentamente,
MARIA DEL PILAR MUNOZ RINCON ANDRES RENE HURTADO RODRIGUEZ
ARTICULO 23 de la Resolucion No 13 del 6 de Julio de 1946
del Reglamento de la Pontificia Universidad Javeriana.
“La Universidad no se hace responsable por los conceptos emitidos
por sus alumnos en sus trabajos de Tesis. Solo velara porque no se
publique nada contrario al dogma y a la moral Catolica y porque las
Tesis no contengan ataques o polemicas puramente personales;
antes bien, se vea en ellas el anhelo de buscar la Verdad y la Justicia”
Nota de Aceptacion:
Aprobado por el comite de Trabajo de Grado en
cumplimiento de los requisitos exigidos por la
Pontificia Universidad Javeriana para optar el
tıtulo de Ingeniero de Sistemas y Computacion.
ANDRES JARAMILLO BOTERO
Decano Academico de la Facultad de Ingenierıa
CAMILO RUEDA CALDERON CAMILO RUEDA CALDERONDirector de la Carrera de Ingenierıa Director de Tesis
de Sistemas y Computacion
PERSONA1 PERSONA2Jurado Jurado
Maria del Pilar Munoz Rincon
A Dios por iluminar mis pasos cada dıa. A mis padres Benjamın y Edilma y a mis
hermanos Carlos Octavio y Maritza por darme acompanamiento constante, apoyo,
animo y guıa en la realizacion de mis suenos.
Andres Rene Hurtado Rodrıguez
A Dios por apoyarme y ser el pilar en mi caminar. A mi padre Rene y a mi madre
Alba Felisa, a mis hermanas Maritza, Alba Lucia y Carmen Beatriz, no serıa nada sin
ustedes
Ficha del Proyecto
Titulo LMAN: Maquina Abstracta del Calculo NTCCpara Programacion Concurrente de Robots LEGOMindStorm.
Facultad INGENIERIA - Ingenierıa de Sistemas y Computacion
Estudiantes MARIA DEL PILAR MUNOZ RINCONANDRES RENE HURTADO RODRIGUEZ
Director CAMILO RUEDA CALDERONGrupo de investigacion AVISPA (Ambientes Visuales de Programacion Aplicativa)Palabras clave Calculo de Procesos, Maquina Abstracta, Maquina Virtual,
Robots LEGO, Concurrencia, Restricciones, LMAN.Resumen del proyecto El actual proyecto de grado describe LMAN, maquina
abstracta del calculo NTCC para programacion concurrentede robots LEGO. LMAN incluye tanto la especificacion dela maquina abstracta, como la implementacion de la maquinavirtual, que actua como el ejecutor notacional del calculoNTCC. El modelo formal presentado en forma de maquinaabstracta, provee la especificacion de la maquina virtual.La maquina virtual esta compuesta de un conjunto deinstrucciones, registros y de un modelo de memoria; queactuando junto con un protocolo de comunicaciones,permiten controlar y ejecutar de manera eficiente y entiempo real programas escritos en NTCC sobre losrobots LEGO MindStorm.
Cuadro 1: Ficha del proyecto
i
Agradecimientos
A Camilo Rueda, director de la carrera de Ingenierıa de Sistemas y Computacion
de la Universidad Javeriana – Cali, y director del proyecto, por sus ideas, apoyo
y asesorıa incondicional en la consecucion del presente proyecto de grado.
A Frank Valencia, post–doctoral researcher en el Departamento de Tecnologıa de
Informacion en la Universidad de Uppsala – Sweden, y asesor del proyecto por
sus aportes y colaboracion en el desarrollo del presente proyecto de grado.
A Antal Buss, profesor de la carrera de Ingenierıa de Sistemas y Computacion de
la Universidad Javeriana – Cali, por todas sus ideas y retroalimentacion en las
etapas iniciales del proyecto.
A Catherine Garcıa, profesora de la carrera de Ingenierıa de Sistemas y Compu-
tacion de la Universidad Javeriana – Cali, por su ayuda y sus aportes en el acople
del modulo del Sistema de Restricciones con el presente proyecto.
A Marıa Constanza Pabon, profesora de la carrera de Ingenierıa de Sistemas y
Computacion de la Universidad Javeriana – Cali, por su colaboracion y apoyo en la
consecucion del modulo del compilador asociado al presente proyecto. Igualmente
agradecemos a todos los estudiantes que estuvieron participando en el proyecto,
en especial a Federico Rocha y Johana Chala.
Al grupo AVISPA.
A Dios, por ser nuestra guıa.
A nuestras familias, por su apoyo incondicional, por su acompanamiento y por
darnos animo en todos los momentos, en especial en los mas difıciles.
A Lady Janeth y a Jorge Alonso por ser pacientes, comprensivos y por su apoyo.
ii
A todas aquellas personas que de una otra manera colaboraron para la consecucion
del presente proyecto de grado.
iii
Indice general
Indice de cuadros VIII
Indice de figuras X
Indice de Anexos XII
1. ANTECEDENTES 1
1.1. CONCURRENCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. CALCULOS DE PROCESOS . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1. CCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2. Default-TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. MAQUINAS ABSTRACTAS Y MAQUINAS VIRTUALES . . . . . . . 10
1.3.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2. Maquina Abstracta y Virtual de TyCO . . . . . . . . . . . . . . 11
1.3.3. Maquina Abstracta de PiCO . . . . . . . . . . . . . . . . . . . . 20
1.4. OBJETIVOS Y CONTRIBUCIONES DE ESTE TRABAJO DE TESIS 28
2. CALCULO NTCC 31
2.1. Descripcion General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2. Sintaxis de NTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
iv
2.3. Semantica de NTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1. Sistema de Restricciones Aritmetico-Modular . . . . . . . . . . 34
2.3.2. Semantica Operacional . . . . . . . . . . . . . . . . . . . . . . . 34
2.4. Definiciones Recursivas . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.1. Codificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5. Celdas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6. Aplicaciones y Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6.1. Controladores RCX: Ejemplo de Zig-Zag . . . . . . . . . . . . . 40
2.6.2. Sistemas Multiagentes: Presa y Predador . . . . . . . . . . . . . 41
2.6.3. Aplicaciones Musicales: Control de Improvisacion . . . . . . . . 41
3. LMAN: MAQUINA ABSTRACTA 43
3.1. Analisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1. Entorno de Programacion NTCC . . . . . . . . . . . . . . . . . 43
3.1.2. Evaluacion de Alternativas de Implementacion para la Maquina
Abstracta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.3. Evaluacion de Alternativas de la plataforma de implementacion
para la Maquina Virtual . . . . . . . . . . . . . . . . . . . . . . 46
3.2. Maquina Abstracta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.1. Especificacion formal . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2. Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.3. Estado inicial y Final . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.4. Semantica Operacional: Reglas de Reduccion . . . . . . . . . . . 54
3.2.5. Diagrama de Transicion . . . . . . . . . . . . . . . . . . . . . . 58
v
4. LMAN: MAQUINA VIRTUAL 61
4.1. Arquitectura General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.1. Memoria de Programa . . . . . . . . . . . . . . . . . . . . . . . 64
4.1.2. Interfaz STORE . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1.3. Interfaz LEGOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.1.4. ControlLMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2. Funcionamiento de LMAN . . . . . . . . . . . . . . . . . . . . . . . . . 83
5. COMPILADOR NTCC–LMAN 87
5.1. Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.1. Conjunto de Caracteres . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.2. Reglas de Produccion . . . . . . . . . . . . . . . . . . . . . . . 89
5.2. Semantica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3. Generacion de Codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6. Ejemplos y Pruebas 94
6.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.1.1. Programa Zig-Zag . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.1.2. Programa de Evasion de Obstaculos . . . . . . . . . . . . . . . . 100
6.1.3. Aplicaciones Musicales . . . . . . . . . . . . . . . . . . . . . . . 103
6.2. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2.1. Etapa de pruebas de LMAN . . . . . . . . . . . . . . . . . . . . 107
6.2.2. Comparacion entre LMAN , ESTEREL y La Maquina estandar
de LEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7. CONCLUSIONES Y TRABAJO FUTURO 113
vi
ANEXOS 116
ANEXOS 125
Bibliografıa 127
vii
Indice de cuadros
1. Ficha del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
1.1. Sintaxis de CCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Semantica de CCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Sintaxis de TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Semantica de TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Registros de la maquina virtual de TyCO . . . . . . . . . . . . . . . . . 19
1.6. Conjunto de Registros de MAPiCO . . . . . . . . . . . . . . . . . . . . 28
2.1. Sintaxis de NTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2. Semantica de NTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1. Evaluacion de Alternativas de Implementacion para la Maquina Abstracta 45
3.2. Evaluacion de alternativas de la plataforma de implementacion para la
Maquina Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3. Sintaxis de LMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1. Formato de Instrucciones de LMAN . . . . . . . . . . . . . . . . . . . . 65
4.2. Alternativas de programacion de RCX . . . . . . . . . . . . . . . . . . 79
4.3. Alternativas de programacion de RCX . . . . . . . . . . . . . . . . . . 80
viii
5.1. Palabras reservadas en el Compilador NTCC-LMAN . . . . . . . . . . 89
5.2. Operadores sobre restricciones . . . . . . . . . . . . . . . . . . . . . . . 91
6.1. Desempeno del programa Zig-Zag . . . . . . . . . . . . . . . . . . . . . 108
6.2. Desempeno del programa Evasion de Obstaculos . . . . . . . . . . . . . 109
6.3. Desempeno del programa Canon en Do mayor . . . . . . . . . . . . . . 110
6.4. comparacion de LMAN, ESTEREL y Maquina estandar de LEGOS . . 112
ix
Indice de figuras
1.1. Modelo de un entorno CCP . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Ejemplo de un ambiente TCC . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Categorıas basicas del lenguaje de programacion TyCO . . . . . . . . . 12
1.4. Nuevas Categorıas del lenguaje de programacion TyCO . . . . . . . . . 12
1.5. Gramatica del lenguaje de programacion TyCO . . . . . . . . . . . . . 13
1.6. Reglas de Reduccion de la maquina abstracta de TyCO . . . . . . . . . 16
1.7. Areas de Memoria de la maquina virtual de TyCO . . . . . . . . . . . . 17
1.8. Flujo de datos del sistema TyCO . . . . . . . . . . . . . . . . . . . . . 20
1.9. Reglas de Reduccion de la maquina abstracta MAPiCO, parte I . . . . 25
1.10. Reglas de Reduccion de la maquina abstracta MAPiCO, parte II . . . . 26
1.11. Diseno de MAPiCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1. Flujo del entrono de programacion NTCC . . . . . . . . . . . . . . . . 44
3.2. Diagrama de Transicion LMAN . . . . . . . . . . . . . . . . . . . . . 59
4.1. Bloques Funcionales de LMAN . . . . . . . . . . . . . . . . . . . . . . 62
4.2. Conjunto de Instrucciones de LMAN . . . . . . . . . . . . . . . . . . . 66
4.3. Especificacion de Fuentes Src1 y Src2 . . . . . . . . . . . . . . . . . . . 67
4.4. Sintaxis para la especificacion de Formulas de Primer Orden en LMAN 68
x
4.5. Instrucciones para construccion de restricciones en LMAN . . . . . . . 69
4.6. Arbol binario infijo que representa una restriccion en LMAN . . . . . . 70
4.7. Ambiente LEGO en LMAN . . . . . . . . . . . . . . . . . . . . . . . . 71
4.8. Protocolo del lado de la estacion de trabajo en LMAN . . . . . . . . . 76
4.9. Protocolo del lado del RCX en LMAN . . . . . . . . . . . . . . . . . . 77
4.10. RCX LEGO brick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.11. Algunos ejemplos de modelos LEGO . . . . . . . . . . . . . . . . . . . 80
4.12. Gestion del controlLMAN . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.13. Requerimientos Hardware del Sistema LMAN . . . . . . . . . . . . . . 84
4.14. Requerimientos Software del Sistema LMAN . . . . . . . . . . . . . . . 84
4.15. Funcionamiento del Sistema LMAN . . . . . . . . . . . . . . . . . . . . 86
4.16. Comportamiento reactivo del Sistema LMAN . . . . . . . . . . . . . . 86
6.1. Ejecucion del programa Evasion de obstaculos . . . . . . . . . . . . . . 109
xi
Indice de Anexos
Anexo A. Traduccion de procesos NTCC a codigo de bytes de LMAN . . . . 116
Anexo B. Librerıas para la construccion de Programas en LMAN . . . . . . 125
xii
Resumen
NTCC (Non-deterministic Temporal Concurrent Constraint Calculus) [Val03] es una
extension de TCC[SJG94] para modelar dos nociones primordiales: No-determinismo
y Asincronıa en Sistemas Discretos-Temporales-Reactivos. Estas dos nociones, junto
con su naturaleza simple, expresiva, formal y su propiedad de combinar una vista ope-
racional, algebraica y declarativa de los procesos, hacen de NTCC un calculo de gran
aplicabilidad sobre sistemas multiagentes, dispositivos roboticos y aplicaciones musica-
les. Con esta motivacion en mente, surge la idea de implementar NTCC mediante una
Maquina Abstracta, modelando en particular uno de los posibles aplicativos propuestos
para NTCC: Programacion de controladores RCX en robots LEGO MindStorm.
De esta manera, el presente trabajo de grado tiene como objetivos, tanto la especi-
ficacion de la maquina abstracta de NTCC, como su implementacion mediante una
maquina virtual. La maquina abstracta actua como el componente que da formalidad
a la maquina virtual, siendo la maquina virtual propiamente el ejecutor notacional del
calculo NTCC. La especificacion de la maquina abstracta incluye las reglas de reduccion,
la definicion de estados inicial – final y las transiciones posibles. La maquina virtual
por su parte, se compone de un conjunto de instrucciones, de registros y de un modelo
de memoria que, actuando junto con un Sistema de Restricciones y un Protocolo de
Comunicaciones, permiten controlar y ejecutar de manera eficiente y en tiempo real
programas escritos en NTCC sobre los Robots LEGO MindStorm.
xiii
Introduccion
Los Calculos Computacionales constituyen la base teorica formal de los lenguajes de
programacion. Sobre esta base es posible demostrar formalmente propiedades como co-
rrectitud y completitud en las construcciones hechas en el lenguaje. Los calculos se
caracterizan basicamente por una sintaxis para describir formulas bien formadas y una
semantica que define las reglas de reduccion. Existen diversos calculos para modelar
diferentes ambientes computacionales; NTCC [Val03] es un calculo para programa-
cion de sistemas reactivos, heredero de los modelos CC[SRP91], TCC[SJG94] y CCS
Calculi[Mil99]. Este trabajo busca implementar una maquina abstracta para NTCC y
analizar su desempeno programando sistemas reactivos como los dispositivos roboticos
LEGO.
La Maquina Abstracta (LMAN) que se describe en el presente documento, incluye tam-
bien la implementacion de una Maquina Virtual que es realmente el ejecutor notacional
de NTCC. La maquina abstracta es el componente formal que define las reglas de re-
duccion y las transiciones posibles en las que se fundamenta la maquina virtual en su
ejecucion. La maquina virtual se compone de un conjunto de instrucciones, de registros
y de un modelo de memoria que, fundamentados en la definicion formal de la maquina
abstracta, permiten ejecutar eficientemente y en tiempo real construcciones de NTCC.
Esta maquina virtual ha sido construıda en bloques funcionales brindando modularidad
a la implementacion. Consta de una interfaz con los robots LEGO MindStorm (inter-
faz LEGOS) que permite modelar la interaccion constante con el ambiente propia de
un sistema reactivo, una interfaz con un Sistema de Restricciones (interfaz STORE)
(imprescindible en una implementacion de programacion CC[SRP91]) de dominios fi-
nitos, de una memoria de programa y, finalmente, de un control o cerebro operacional
(controLMAN). A diferencia de otras implementaciones de maquinas virtuales [Lop99],
[AB98] LMAN incluye no solo la nocion de planeacion de procesos, sino tambien la
xiv
nocion de planeacion de maquinas en el tiempo.
Respecto al desempeno de LMAN, los resultados obtenidos en las pruebas demuestran
eficiencia en la ejecucion. Ha sido probada ejecutando construcciones NTCC[Val03] ta-
les como evasion de obstaculos y movimiento en zigzag. Cabe notar que los programas se
ejecutan en tiempo real, pese a que conllevan la resolucion de restricciones aritmeticas
de dominio finito. En cuanto a la interfaz de programacion que el actual proyecto provee
al usuario, el proposito es construır alrededor de LMAN un ambiente de programacion
aplicativa, que incluye un Lenguaje VISUAL VIN [FQ04] para programacion iconica en
alto nivel y un compilador NTCC–LMAN [RCP03] que toma las entradas en NTCC y
genera “Codigo de Bytes” para LMAN. El presente trabajo incluye el diseno e integra-
cion del compilador NTCC–LMAN, su implementacion se describe en [RCP03] por F.
Rocha, J.Chala y M. Pabon; este componente posibilita la programacion en alto nivel,
ya que los programas son escritos en NTCC, compilados y posteriormente ejecutados
por LMAN sobre el robot LEGO.
Este documento ha sido dividido en 7 capıtulos:
Capıtulo 1, presenta los antecedentes involucrados en el desarrollo del proyecto,
tales como la teorıa CCP, el calculo TCC, las definiciones de maquina abstracta y
virtual, y las maquinas para calculos de procesos que fueron referencia del actual
trabajo: TyCO y MAPiCO.
Capıtulo 2, esta dedicado al calculo NTCC, enfatizando la sintaxis, la semantica y
los aplicativos relacionados.
Capıtulo 3, trata la maquina abstracta definida para LMAN: analisis, especifica-
cion formal, reglas de reduccion, estados y transiciones.
Capıtulo 4, describe la implementacion de la maquina virtual, presentando la divi-
sion en bloques funcionales: interfaz con el Sistema de Restricciones, interfaz con
el dispositivo LEGO, el modelo de memoria y el Control. Se describe adicional-
mente el funcionamiento de la aplicacion y todos los elementos utilizados en la
implementacion.
Capıtulo 5, presenta el diseno del compilador NTCC–LMAN: sintaxis, semantica
y generacion de codigo. Tambien se trata su integracion con el actual trabajo de
grado.
xv
Capıtulo 6, se describen los ejemplos y pruebas realizadas ejecutando construccio-
nes NTCC sobre LMAN. Se muestran comparaciones entre LMAN, el lenguaje
ESTEREL[MR] y la maquina virtual estandar de LEGO.
Capıtulo 7, muestra las conclusiones del presente trabajo, enfatizando las activi-
dades a futuro y las recomendaciones a partir de este trabajo base.
En la actualidad, no se ha reportado previamente en la literatura ninguna implementa-
cion de un calculo temporal, concurrente, por restricciones validado sobre robots LEGO.
En nuestro conocimiento, el actual trabajo de tesis constituye la primera implementa-
cion de este tipo. No obstante, es importante mencionar los desarrollos JCC [SRP03]
y ESTEREL[MR] que estan en la misma lınea formal de este trabajo y que han sido
probados en programacion de robots LEGO.
xvi
1 ANTECEDENTES
A lo largo de este capıtulo encontrara los principales aspectos metodologicos utilizados
en el desarrollo del actual trabajo de tesis; se trataran las nociones generales sobre
conceptos como concurrencia, calculos de procesos y maquinas abstractas y virtuales;
esto con el proposito de establecer una base conceptual clara que permita comprender
el presente trabajo. Al final del capıtulo se recopilan los objetivos y las contribuciones
del desarrollo que aquı se reporta.
1.1. CONCURRENCIA
La definicion de concurrencia esta asociada con sistemas de multiples agentes, tambien
llamados procesos, que interactuan entre si en un mismo ambiente y al mismo tiempo.
Esta definicion cubre una gran variedad de modelos de la vida real, como lo son las
aplicaciones sobre Internet, la programacion de dispositivos roboticos, la computacion
movil y los sistemas reactivos, entre otros.
Observando esta variedad de aplicaciones que tiene la computacion concurrente, se ha-
ce necesario tener herramientas para analizar y razonar en torno a la misma. Estas
herramientas deben ser confiables y precisas, por lo cual es necesario que tengan una
base matematica y logica, como la que existe ya para el modelo secuencial de progra-
macion a traves del lambda calculo. El problema es que modelos como el anterior no son
adecuados para la concurrencia debido a algunas propiedades inherentes a esta, tales
como:
No-determinismo, representa la escogencia aleatoria de una opcion entre multi-
ples.
Computacion Reactiva, mediante la cual se modelan sistemas de agentes que no
1
presentan un estado final debido a que responden a estımulos del ambiente en
cualquier momento.
Movilidad, referencia procesos que pueden cambiar sus enlaces y configuracion de
comunicacion.
Teniendo la necesidad de crear modelos precisos y confiables para procesos concurrentes
y dado el gran campo de aplicaciones que tienen, es necesario construır modelos que
traten comportamientos especıficos y que posean al menos algunas de las caracterısticas
mencionadas anteriormente. Un modelo de esta naturaleza debe tener las siguientes
propiedades:
Debe ser simple, es decir que su base deben ser principios basicos.
Debe ser expresivo, permitir modelar diferentes situaciones.
Debe ser formal, fundamentado en bases matematicas y logicas.
Debe aportar tecnicas para poder razonar sobre los procesos.
Una vez completado el modelo puntual podran surgir extensiones a este para incluir
mas propiedades dentro del dominio de problemas particular que se considera, como
es el caso de los problemas que involucran numeros reales y aquellos que manejan la
nocion de tiempo(TCC), como se tratara a continuacion.
1.2. CALCULOS DE PROCESOS
La necesidad de obtener herramientas precisas y confiables que permitan demostrar pro-
piedades como correctitud y completitud, da origen a los calculos computacionales. Los
calculos llegan a constituirse en la base teorica formal de los lenguajes de programacion.
Los componentes basicos de un calculo computacional son:
Sintaxis, descripcion de formulas bien formadas en el calculo.
Semantica, definicion de las reglas de reduccion y la forma como se interpretan
cada una de las formulas.
2
Existe diversidad de calculos para modelar diferentes ambientes computacionales como
los calculos π, CCP , TyCO , PiCO , ρ(calculo del lenguaje OZ), entre otros. No
obstante, el enfoque de este trabajo de tesis son los calculos de procesos. A continuacion
se trataran los calculos de procesos pertinentes a este trabajo de tesis: CCP y Default-
TCC
1.2.1. CCP
El calculo concurrente de programacion por restricciones (CCP)[VS91] es uno de los mas
conocidos formalismos para concurrencia. La nocion basica de CCP considera multi-
ples agentes (procesos) ejecutandose al mismo tiempo y comunicandose por medio de
variables compartidas que se encuentran en un almacen comun o Store.
En el Store la nocion del valor de una variable se toma como un conocimiento parcial
sobre esta (ej: x se encuentra entre 10 y 20); conocimiento que se acumula dentro
del almacen por medio de una restriccion, que es una representacion de un conjunto
de posibles valuaciones (ej: 10 ≤ x ≤ 20). El sistema de restricciones asociado a un
ambiente CCP, es quien se encarga de la interaccion de los procesos con el Store.
Intuitivamente puede considerarse que el Store almacena o acumula las restricciones;
en el modelo, sin embargo, el Store representa la conjuncion logica de las mismas; por
lo tanto, este sera monotonico; lo cual quiere decir, que la informacion que se agregue
debe ser coherente con la que ya se tiene.
Los procesos se comunican adicionando (operacion tell) al Store (en el sentido des-
crito arriba) y consultando (ask) informacion sobre las variables. Cuando en el Store
no se tiene suficiente informacion para decidir si una restriccion es verdadera o falsa,
se suspende la ejecucion del proceso hasta tener suficiente informacion para dar una
respuesta; esta es la forma en que los procesos se sincronizan en el calculo.
Ejemplo 1.2.1. Considere el siguiente comportamiento; se tienen dos agentes, (A) es el
encargado de reportar la temperatura en un edificio y (B) sera el encargado de activar la
alarma de incendios, ejecutado un proceso Q si la temperatura es mayor que 75 grados
centıgrados. Estos dos agentes se comunican por medio de una variable en comun (t).
Suponga que A comenta que la temperatura es mayor de 25 grados centıgrados (tell t >
25), despues B pregunta si la temperatura es mayor que 75 (ask t > 75). Como en este
3
momento la informacion brindada por A no es suficiente para tomar una decision, B
queda suspendido. Dos horas mas tarde, digamos, A reporta que la temperatura es igual
a 80 grados (tell t = 80); en ese momento B puede obtener mas informacion sobre el
valor temperatura y activa la alarma contra incendios. La figura 1.1 presenta el modelo
del problema.
Figura 1.1: Modelo de un entorno CCP
CCP posee varias extensiones: movilidad, comportamiento estocastico y una de las mas
significativas para el presente trabajo, la nocion del tiempo.
A continuacion se definen el sistema de restricciones utilizado por CCP y algunas ex-
tensiones.
1.2.1.1. Sistema de Restricciones
Se utilizara la definicion de sistemas de restricciones encontrada en la tesis doctoral de
Frank Valencia[Val03]:
Definicion 1.2.1.1 Un sistema de restricciones se define como una tupla (Σ,4), en
donde Σ representa un conjunto de constantes, funciones y sımbolos de predicado, y 4es una logica de primer orden consistente que opera sobre Σ.
Siendo (Σ,4) el sistema de restricciones, se definira Γ como su lenguaje de primer orden;
el cual consiste en una tupla (Σ, V, S), donde V es un conjunto de variables {x, y, ..., z},y S es un conjunto de operadores logicos como ¬, ∧, ∨, ⇒, ∃, ∀, true, false los cuales
hacen referencia a: la negacion, la conjuncion, la disyuncion, la implicacion, los cuanti-
4
ficadores universales y existenciales, y los sımbolos de verdadero y falso. El sistema de
restricciones esta compuesto por restricciones, denotadas por c, d, ..., que son formulas
de primer orden sobre Γ. Se dira que c deduce a d bajo 4, escrito c ⇒4 d si y solo si
c⇒ d es verdadero de acuerdo a la relacion logica 4. Por comodidad se escribira c⇒ d
en vez de c ⇒4 d. Se dira c ≈ d si y solo si c ⇒ d y d ⇒ c son verdaderos bajo 4.
Algunos ejemplos de sistemas de restricciones son Herbrand y Getzen [VSG96].
1.2.1.2. Calculo CCP
La sintaxis de CCP esta dada por el cuadro 1.1:
Agentes A, B, ... := true no haga nada| tell(σ) tell σ
| ask(σ)→ A ask σ| (vX)A EscondaX|A||B Ejecucion en paralelo| p(X) Definicion de llamada
Definiciones D := ∈| p(X) :: A Definicion de agente|D.D
Programas P, Q := D.A
Cuadro 1.1: Sintaxis de CCP
Donde:
σ denota una o mas restricciones primitivas. X, Y... hace referencia a las variables del
calculo. A denota un agente o proceso. D denota una secuencia de declaraciones de
procesos y P, Q... es la definicion de un programa.
Los procesos se describen de la siguiente manera: El proceso true es equivalente a
vacıo; representa inactividad o el proceso que no hace nada. El proceso tell se encarga
de adicionar la restriccion σ al Store. El proceso ask pregunta al Store si la restriccion σ
se deduce de la informacion allı consignada; si puede deducirse, se ejecuta A, si deduce
la negacion de σ, se descarta A y si no puede deducir nada, el proceso queda suspendido
hasta que se tenga suficiente informacion para tomar una decision. EL proceso (vX)A
sirve para ocultar o crear una variable local al proceso A con el objetivo de que esta
solo sea visible para aquel. A||B denota la ejecucion en paralelo, lo cual dice que A
5
y B se ejecutaran independientemente, pero se pueden comunicar y complementar de
acuerdo a las acciones de cada uno. El proceso p(X) es la definicion de llamada a un
proceso.
1.2.1.3. Reglas Semanticas de CCP
La descripcion de las reglas semanticas expuestas aquı, estan de acuerdo a la semantica
operacional, que interpreta un proceso como un conjunto de pasos computacionales.
Se define la relacion →(τ,τ ′) como la transicion del Store τ al τ ′.
Las reglas semanticas se ilustran en el cuadro 1.2:
TELL tell(σ)→(τ,τtσ) trueASK (ask(σ)→A)→(τ,τ)A si τ ` σ
PARA→(τ,τ)A
′
A||B→(τ,τ)A′||B ,
B→(τ,τ)B′
A||B→(τ,τ)A||B′
HIDEA→(τ,τ)A
′
(vX)A→(τ,τ)A′ si X es fresca
Cuadro 1.2: Semantica de CCP
La regla TELL especifica la accion de anadir la restriccion σ al Store mientras que el
proceso original reduce a true.
La regla del ASK modela el caso en que el Store puede deducir σ del Store τ , ejecu-
tandose el proceso A.
PAR especifica que la reduccion puede ocurrir en cualquiera de los dos procesos, mas
no en ambos en el mismo paso computacional.
HIDE implica el concepto de localidad de la variable X para el proceso A, lo que
quiere decir que solo este proceso (y sus subprocesos) tendra acceso a ella.
1.2.2. Default-TCC
El modelo de programacion concurrente por restricciones CCP ha demostrado ser muy
efectivo y de gran ayuda para modelar propiedades de concurrencia en problemas reales;
sin embargo, muchos de los problemas reales incluyen la nocion de tiempo, que CCP
no modela.
6
Para dar solucion a esta falencia, se ha propuesto la extension al calculo CCP denomi-
nada TCC – Temporal Concurrent Constraint Programming –. A partir de TCC sur-
gieron posteriormente otras extensiones y variantes, tales como Default-TCC y NTCC
–Non-deterministic Temporal Concurrent Constraint Programming – bases para el ac-
tual trabajo de tesis.
TCC implementa la nocion de tiempo discreto para poder modelar sistemas reactivos.
Basado en la programacion sincronica (Berrey & Gonthier(1992), Halbwachs et al. 1991,
Harel(1987)) TCC plantea agrupar todos los modelos temporales que se han trabajado
anteriormente, basandose en la nocion de tiempo multiforme y preemption (proceso
interruptible), que implica que cualquier senal puede ”servir como unidad de tiempo”.
Un sistema reactivo se define por su continua interaccion con su ambiente de ejecucion.
Un claro ejemplo se puede ver en los dispositivos roboticos, que interactuan constan-
temente con su ambiente, para reaccionar, por ejemplo, cuando se presiona un sensor
o se detecta un cambio en la percepcion de la luz. Los sistemas de tiempo multiforme
permiten modelar eventos condicionales de tiempo (time-outs) y retardos (unit-delays),
entre otros. Un ejemplo de esto son ciertas acciones de tipo time-out que puede presen-
tar un dispositivo robotico: si en una determinada cantidad de tiempo no ha recibido
senal alguna, ejecuta una accion o proceso determinado.
Con base en los sistemas reactivos y la nocion de tiempo multiforme, TCC divide el
tiempo en unidades discretas. En una unidad de tiempo TCC se captura el estado del
ambiente, despues se procesa esa entrada y, cuando se termina de procesar, se emite una
salida al ambiente. Es posible que queden algunos procesos residuales que se ejecutaran
en la siguiente unidad de tiempo. Es importante observar que en TCC el Store se vacıa
cada vez que una unidad de tiempo inicia.
Ejemplo 1.2.2. Suponga un proceso P que se ejecuta en todas la unidades; P interactua
con el ambiente evaluando si la variable del ambiente x se encuentra en “1”. Cada vez
que esto sucede, el ambiente debera de ejecutar un proceso Q, de lo contrario, no se
ejecuta nada. La figura 1.2 ilustra la ejecucion del proceso.
1.2.2.1. Propiedad por Defecto (Default)
Debido a que el modelo de programacion por restricciones CCP maneja la nocion de un
Store monotonico, lo cual implica que la informacion nueva debe de ser coherente con
7
Figura 1.2: Ejemplo de un ambiente TCC
la informacion actual, surgen problemas para expresar tanto la ausencia de informacion
como la informacion negativa. La ausencia de informacion hace referencia a aquella
informacion que no existe en el Store sobre la restriccion que se pregunta, y la infor-
macion negativa referencia aquella informacion que no es coherente con la informacion
que ya contiene el Store.
Debido al problema mencionado anteriormente, se ha propuesto modelar la propiedad
Default, que representa un valor por defecto para una variable en caso de que el Store
no tenga informacion sobre esta. Esta propiedad no es obligatoria, es decir no todas las
variables deben de tener un default.
1.2.2.2. Sintaxis de Default-TCC
Al ser TCC una extension de CCP, su sintaxis es similar. Se adicionan algunos cons-
tructores nuevos para manejar propiedades del tiempo y se perciben cambios de forma
al escribir los procesos.
La sintaxis de TCC esta dada por el cuadro 1.3:
A, B, .. = tell(σ) tell σ| if σ then A ask σ| if σ elseA ask negativo σ|A, B Composicion paralela|hence A Ejecucion de Aa partir de ahora|new X in A Encapsulamiento
Cuadro 1.3: Sintaxis de TCC
Donde: A, B, .. Denota un agente o proceso, X, Y, ... hace referencia a las variables del
8
calculo. σ representa una o mas restricciones primitivas.
Las descripcion de los procesos es la siguiente: La accion de tell(σ) consiste en anadir
la restriccion σ al Store. El proceso if σ then A verifica si se puede deducir del Store
la restriccion σ; si esto es posible, se ejecuta el proceso A (note que este proceso tiene
cierta similitud con ask(σ → A) en CCP). El tercer proceso if σ elseA es el opuesto del
anterior: si no se puede deducir σ del Store, entonces se ejecuta A, aclaracion: el que
no se pueda deducir σ no implica que se cumpla ¬σ).“Estos dos procesos cumplen con
la propiedad de supuesto por defecto del calculo CC, ya que sirven para asegurar un
supuesto”. A, B es el proceso de composicion paralela, el cual representa dos procesos A
y B que se ejecutan independientemente sobre el mismo Store. hence A es el operador
del manejo del tiempo en TCC; significa que se impondran las restricciones del proceso
A en cada instante a partir de la ejecucion del hence. new X in A es el proceso que
construye la relacion de encapsulamiento en TCC, que significa que solo el proceso A
puede ver a X.
1.2.2.3. Semantica de Default-TCC
La descripcion de las reglas semanticas expuestas aquı es tomada de [VSG96].
Se define Γ, ∆, .. como multiconjuntos de programas,“que se entienden como procesos”
, σ(Γ) como el conjunto de todos los tell que hay en Γ y la relacion →b, como una
transicion binaria indexada por los supuestos finales b que seran usados para evaluar
las acciones con default.
La semantica de los procesos esta dada por el cuadro 1.4:
TELL σ(Γ)`aΓ`(tell(a),∆)
ASK1 ς(Γ)`a((Γ,if a then B),∆)→b((Γ,B),∆)
ASK2 ς(Γ)6`a((Γ,if a else B),∆)→b((Γ,B),∆)
PAR ((Γ, (A, B)), ∆)→b ((Γ, A,B), ∆)HENCE ((Γ, hence A), ∆)→b (Γ, (A, hence A, ∆))
NEW ((Γ, new X in A), ∆)→b ((Γ, A[Y/X]), ∆) para Y no libre en A y Γ
OBS∃b∈D (Γ,φ)→∗
b (Γ′,∆) 6→b σ(Γ′)=b
Γ;new−→Y in δ
Cuadro 1.4: Semantica de TCC
9
La regla TELL se modela de manera similar que en CCP, especificando la accion de
anadicionar la restriccion σ al Store. ASK1 representa el caso en que se puede deducir a
del Store, por lo tanto se ejecuta el proceso B.La segunda regla ASK2, describe el caso
en que no hay suficiente informacion para deducir a, por lo que se ejecuta el proceso
B.PAR presenta la ejecucion de dos procesos en paralelo, bajo la condicion que se reduce
uno de los dos en cada paso computacional o transicion interna.HENCE describe la
ejecucion del proceso A y la posterior ejecucion de HENCE para el siguiente instante.
Este proceso hace una analogıa con la replicacion, del calculo π, para este calculo.La
regla NEW implica el concepto de encapsulamiento para la variable X en el proceso
A, este proceso remplaza al HIDE de CCP.
La ultima regla OBS se utiliza para definir una transicion observable. Una transicion
observable indica las acciones visibles de un proceso para los espectadores externos a
este; ademas de representar en este calculo el paso de la unidad actual de tiempo a la
siguiente. OBS se activa cuando el Store actual a alcanzado un estado de quietud impli-
cando que no se pueda deducir conocimiento nuevo y que ninguna de las reglas anterior-
mente expuestas pueda realizar alguna reduccion; de esta manera se finaliza la unidad
actual de tiempo, dando las instrucciones que debe ejecutar el ambiente(∃−→Y
σ(Γ)) y
presentado los procesos que se deben ejecutar en el siguiente instante. Es importante
mencionar que esta regla es la unica transicion observable de TCC .
1.3. MAQUINAS ABSTRACTAS Y MAQUINAS
VIRTUALES
1.3.1. Definiciones
Una Maquina Abstracta [Com00] puede definirse como un procedimiento para
ejecutar un conjunto de instrucciones en algun lenguaje formal, tomando una entrada
de datos y generando una salida. Algunas maquinas abstractas no pretenden ser im-
plementadas en Hardware. Ejemplo: Maquina de Estados Finitos, Maquina de Turing,
entre otras. Algunas maquinas abstractas implementan calculos como PICT para π,
MA TyCO para TyCO y MAPiCO para PiCO.
Una Maquina Virtual [Com00] es un procesador no implementado en Hardware,
pero que actua como el ejecutor notacional de un Lenguaje de Programacion particular.
10
Se compone de un conjunto de instrucciones, registros y un modelo de memoria. Es un
Software de emulacion para un ambiente fısico de computacion o Hardware. Ejemplo:
Maquina Virtual de Java y la Maquina Virtual de TyCO.
1.3.2. Maquina Abstracta y Virtual de TyCO
TyCO (Typed Concurrent Objects) [Lop99], es un calculo de procesos que implementa
los conceptos presentes en los Lenguajes Orientados-Objetos combinado con la Pro-
gramacion Concurrente, todo en un ambiente de paso de mensajes y objetos que se
comunican asincronicamente. Este calculo se origina en el CCS (Calculus of Communi-
cating Processes)[Mil89] y toma del calculo π las caracterısticas acerca de la definicion
de objetos, mensajes asıncronos y definiciones de plantillas, que se constituyen como
las entidades fundamentales de TyCO. Este calculo formalmente describe la interaccion
concurrente de objetos por medio de una comunicacion asıncrona. La comunicacion
sıncrona es implementada incorporando en los mensajes un nombre extra para cubrir el
resultado de la comunicacion. Las plantillas se usan para modelar clases y un comporta-
miento tıpico unbounded. Un sistema de tipos asigna tipos monomorficos a las variables
y tipos polimorficos a las plantillas.
A diferencia de otras implementaciones, la maquina virtual de TyCO descrita en [Lop99],
involucra la definicion de un lenguaje basado en el calculo TyCO y provee una semanti-
ca estatica, en la forma de un sistema de inferencia de tipos y una semantica dinamica,
en forma de una maquina abstracta. Este marco formal es el que define la base para el
diseno de la maquina virtual y el compilador del lenguaje asociado.
La maquina virtual ejecuta programas TyCO traducidos en un formato de ”codigo de
bytes”. Cuenta con una arquitectura compacta e independiente, y su desempeno resulta
favorable al comparase con otras implementaciones de su tipo. La maquina ha sido
afinada para TyCO, pero puede ser usada para implementar otro calculo incluyendo los
cambios necesarios o extensiones a su semantica. Es implementada como un emulador de
”codigo de bytes”, definiendo un monton (heap) para las estructuras de datos dinamicas,
una cola de ejecucion (run–queue) para planificacion del ”codigo de bytes, un arreglo
para las variables locales y una pila de operandos para la evaluacion de expresiones.
El lenguaje de programacion TyCO se define como un lenguaje tipado low–level
kernel, con una sintaxis y semantica muy cercanas al calculo mismo; solamente incluye
11
unos pocos constructores derivados y tipos de datos. El sistema de inferencia de
tipos es el encargado de asegurar correctitud de tipos en los programas, en los nombres
y adicionalmente garantiza que no existiran errores de protocolo en tiempo de ejecucion.
1.3.2.1. Lenguaje de programacion TyCO
El lenguaje de programacion TyCO utiliza una sintaxis muy cercana al calculo mismo.
Toma como base la sintaxis del calculo TyCO y define las categorıas basicas para el
lenguaje de programacion subyacente que se observan en la figura 1.3.
Figura 1.3: Categorıas basicas del lenguaje de programacion TyCO
La novedad en el lenguaje TyCO es la introduccion de dos nuevas categorıas sintacticas:
instrucciones e hilos(threads), (Ver figura 1.4). Las instrucciones estan muy relacionadas
con los procesos TyCO y son elementos del conjunto Instr, nombrado como I. Los hilos
son elementos del conjunto Thread de colas de instrucciones, nombrado como T.
Figura 1.4: Nuevas Categorıas del lenguaje de programacion TyCO
La sintaxis del calculo fuente del lenguaje TyCO utiliza los hilos como la categorıa
principal, su gramatica se describe en la figura 1.5.
12
Figura 1.5: Gramatica del lenguaje de programacion TyCO
Para ilustrar el calculo TyCO se presenta un ejemplo tomado de [Lop99], que da solucion
al problema de la Criba de Eratostenes, tal como se describe a continuacion.
Se define una secuencia de procesos plantillas los cuales generan un flujo de numeros
naturales y chequean cuales de ellos son primos. Todos los numeros primos encontrados
se adicionan a la cadena de cribas que crece dinamicamente; de modo que se adiciona
una criba por cada numero primo encontrado. Esta cadena de cribas, filtra los naturales
mientras ellos son generados en Nats. El codigo que resuelve este problema en TyCO
sigue a continuacion.
def Nats = (n m sieve)
sieve![n] ; if n < m then Nats[n+1 m sieve]
and Sieve = (self prime nextsieve)
self ? (n done)
(if n % prime != 0 then nextsieve![n done]
else done![])
| Sieve[self prime nextsieve]
and Sink = (self)
13
self ? (n done)
io!put[n] |
new newsieve Sink[newsieve] |
Sieve[self n newsieve] |
done![]
in io!put[2] | new sieve Nats[2 1000 sieve] | Sink[sieve]
Del ejemplo anterior se observa que Nats es quien genera el flujo de naturales entre n y
m, donde cada natural es enviado a la primera criba en la cadena de cribas (sieve) para
su chequeo. La generacion de un natural por Nats es sincronizada con senales generadas
cuando se realizan actualizaciones en la cadena. Sieve es una plantilla definida para las
cribas en la cadena.
El procedimiento, toma el natural n y lo pasa de criba en criba en la cadena chequean-
do que este no pueda dividirse por ninguna. Si sucede lo ultimo, el natural se olvida
y la criba envıa una senal a Nats para proceder a generar un nuevo numero natural.
Sink(llave) es quien senaliza el final de la cadena; de modo que, un natural que logra lle-
gar hasta el final se toma como un primo y se imprime. El proceso finaliza, extendiendo
la cadena al adicionar una nueva criba cuyo primo es n, situando sink luego del nuevo
primo para demarcar y enviando una senal a Nats para generar un nuevo numero. En
el anterior bloque de codigo, se llama a Nats para un flujo de naturales entre 2 y 1000.
1.3.2.2. Maquina Abstracta de TyCO
La semantica dinamica del lenguaje de programacion TyCO se define en forma de una
maquina abstracta. De esta manera, la maquina abstracta es quien confiere el compo-
nente de formalidad al flujo de implementacion que incluye el lenguaje, el compilador
y la maquina virtual. A continuacion se mencionan cada uno de los aspectos mas im-
portantes en la definicion de la maquina abstracta de TyCO.
1.3.2.2.1. Categorıas Sintacticas .
La definicion de la maquina abstracta incluye las siguientes categorıas sintacticas:
14
Ambiente de un hilo, representado como un mapeo de variables a valores:
VBind = Var 7→ Val. Se denota B.
Plantillas, son representadas como un mapeo de variables a pares de variables
y abstracciones: TBind = Tvar 7→ VBind x Abs. Se denotan K.
Mensajes, llevan una etiqueta y una secuencia de valores. Se mantienen en las
colas de: QComm = QueueLabel x Name*. Se nombran como ms.
Objetos, contienen una tabla de metodos y ligaduras de variables libres. Se
mantienen en las colas de: QMeth = Queue(VBind x Meth). Se nombran como
Ms.
Canales, son elementos del conjunto QBind = Name 7→ (QComm⋃
QMeth)
de colas de mensajes u objetos. Se nombran como Q.
Cola de ejecucion, es un elemento del conjunto RunQueue = Queue(VBind x
Thread) donde los hilos y sus ambientes se mantienen esperando por ejecucion.
Se nombra como R.
Estado–de–Maquina, denotado por S, es una tupla en el conjunto
State = TBind x VBind x QBind x Thread x RunQueue.
1.3.2.2.2. Estados Inicial y Final .
Para la maquina abstracta de TyCO se definen los estados inicial y final como sigue:
Estado Inicial: Dado un hilo T, la maquina abstracta inicia la computacion con
una cola de ejecucion vacıa, sin variables ni plantillas de ambientes y sin colas en
los canales. El estado inicial es representado por:
∅, ∅, ∅, T, •
Estado Final: La maquina se detiene cuando ninguna regla puede ser aplicada;
es decir, cuando se alcanza el estado final de la forma:
, , , •, •
15
1.3.2.2.3. Reglas de reduccion .
Las reglas de reduccion descritas en la figura 1.6, realizan transformaciones de estados en
estados. Cada una de estas reglas requiere ciertas condiciones para que las reducciones
sean exitosas; de lo contrario, la maquina llega a un estado de bloqueo.
Figura 1.6: Reglas de Reduccion de la maquina abstracta de TyCO
1.3.2.2.4. Propiedades de la maquina abstracta .
La maquina abstracta de TyCO presenta las siguientes propiedades[Lop99]:
1. La maquina abstracta es sana, es decir, que cada transicion puede ser vista como
una reduccion o una congruencia entre las reglas y el calculo.
2. En cualquier momento de computacion, las colas asociadas con nombres estan
vacias o tienen solamente comunicaciones o tienen clausuras de metodos (method-
closures).
16
3. Para programas correctos la maquina no presenta bloqueos. Esta propiedad esta li-
gada a la caracterıstica del sistema de tipos que garantiza que no existiran errores
de protocolo en tiempo de ejecucion.
4. La maquina abstracta es justa, es decir que, dado un hilo, este siempre se ejecuta
un tiempo despues de que llega a la cola de ejecucion.
1.3.2.3. Maquina Virtual de TyCO
La especificacion formal presentada anteriormente como maquina abstracta, define la
implementacion de la maquina virtual de TyCO. El diseno e implementacion fue inspira-
da en STG-Machine[Jon92, JNO97], la Maquina Virtual de Java[LY97] y WAM[War83];
no obstante, el modelo computacional es tomado de la especificacion formal de la maqui-
na abstracta. A continuacion se describe los componentes asociados a la implementacion
de la maquina virtual de TyCO.
1.3.2.3.1. Arquitectura de Memoria .
Para la maquina virtual de TyCO se definen cinco areas de memoria. Ver figura 1.7
Figura 1.7: Areas de Memoria de la maquina virtual de TyCO
1. Area de Programa: mantiene las instrucciones en codigo de bytes a ser ejecuta-
das. El codigo de bytes se compone de bloques de instruccion y tablas de metodos
(secuencias de punteros a los bloques de codigo).
2. Monton: es un espacio de direcciones planas donde las estructuras de datos
dinamicas como objetos, mensajes y canales son localizados. El bloque constructor
17
basico del monton es la palabra(machine word); y la unidad de alocacion basica
es el marco(frame) y consiste de uno o mas palabras contiguas con un descriptor
para la recoleccion de basura.
La maquina manipula tres clases basicas de procesos en tiempo de ejecucion:
mensajes, objetos e instancias. Los mensajes y objetos se localizan en canales
compartidos, y son vistos externamente como marcos. Los marcos de mensaje
esperan por una etiqueta y una lista de argumentos. Los marcos de objetos es-
peran por un puntero al codigo donde se encuentra la tabla de metodos, mas las
ligaduras de las variables libres asociadas a los metodos. Un marco de instancia
espera por una referencia al codigo que ubica las plantillas, ligaduras y argumen-
tos de una instancia. Los canales finalmente son marcos especiales utilizados en
la comunicacion entre colas e implementan la nocion de nombres en el calculo.
3. Cola de Ejecucion: espera vm threads o bloques de instrucciones contiguas aso-
ciados a un hilo, listos para ejecucion y sus respectivos ambientes. Esta cola crece
en la misma direccion del monton. Cada vm thread consiste de una estructura de
datos con una referencia al codigo del programa, una referencia a un marco con
los parametros y una referencia a un marco en el monton con las variables libres.
Cada vez que una reduccion ocurre, un nuevo vm thread es creado y colocado,
junto con su ambiente, en la cola de ejecucion donde espera ser planificado para
ejecucion.
4. Arreglo de variables locales: Ya que cada vm thread crea nuevas variables loca-
les; cada vez que una variable local es creada, la siguiente posicion disponible en
el arreglo de variables locales es asignada y ligada al canal que ya ha sido definido.
Cada que un vm thread termina, las ligaduras locales se descartan y se sobrees-
criben las asignaciones cada vez que el siguiente vm thread pase a ejecucion.
5. Pila de Operandos: la maquina virtual admite directamente tipos de datos de-
finidos en TyCO; es decir, que existen instrucciones que implementan operacio-
nes booleanas sobre booleanos, operaciones aritmeticas sobre enteros y flotantes
y operaciones relacionales sobre enteros, flotantes y cadenas. Para las cadenas
tambien existen instrucciones para computar su tamano y para concatenar. La
implementacion actual admite listas. Todas estas operaciones se realizan en el
area de memoria denominada pila de operandos. Cuando las expresiones son sim-
ples como constantes o variables que no requieren evaluacion, son directamente
18
copiadas al monton para procesar; de lo contrario, las expresiones que requieren
de evaluacion pasan del monton a la pila para evaluacion y de nuevo a una nueva
ubicacion en el monton para ejecucion.
1.3.2.3.2. Registros .
La maquina virtual utiliza registros globales para controlar el flujo del programa y
manipular la maquina y las estructuras de datos asociadas. El conjunto de registros se
muestra en el cuadro 1.5.
Registros Descripcion
PC (Program Counter) apunta a la siguiente instruccion a ser ejecutada.HP (Heap Pointer) apunta a la siguiente posicion disponible en el
monton.SQ (Start Queue) apunta al inicio de la cola de ejecucion.EQ (End Queue) apunta al final de la cola de ejecucion.OS (Operand Stack) apunta al ultima posicion utilizada de la pila.LV (Local Variable Array) apunta a la base del arreglo de variables.CC (Current Channel) apunta al canal actualmente usado en la reduccion.CF (Current Frame) espera por marcos temporales hasta que ellos sean
encolados o usados en una reduccion.OF (Other Frame) se utiliza cuando se esta ejecutando una reduccion.FV (Free Variable bindings) espera por variables libres.PM (Parameter bindings) espera por parametros.
Cuadro 1.5: Registros de la maquina virtual de TyCO
1.3.2.3.3. Conjunto de Instrucciones .
La maquina virtual de TyCO utiliza un tamano minimizado en el formato de ins-
trucciones para fines de eficiencia. Las instrucciones son identificadas por un codigo
de operacion unico apuntado por el registro del PC y han sido implementadas como
funciones tipo C, sin parametros.
1.3.2.3.4. Flujo de Datos TyCO .
19
Finalmente, es importante mencionar que la implementacion de TyCO incluye un com-
pilador de codigo fuente a codigo ensamblador, un ensamblador de codigo de bytes y
un emulador de codigo de bytes. El emulador es basicamente la implementacion de la
maquina abstracta. El codigo ha sido escrito en lenguaje C buscando eficiencia. La
figura 3.1 ilustra el flujo de datos en el sistema TyCO.
Figura 1.8: Flujo de datos del sistema TyCO
1.3.3. Maquina Abstracta de PiCO
El diseno e implementacion de la maquina abstracta para el calculo PiCO[ADQV98],
MAPiCO[AB98], no realiza la diferenciacion entre maquina abstracta y maquina vir-
tual, tal como se presento en la seccion anterior para TyCO. Sin embargo, esta di-
ferenciacion esta implıcita, ya que, para MAPiCO se define la maquina abstracta en
forma de reglas de reduccion y, adicionalmente, se implementa el emulador subyacente.
Para MAPiCO, igualmente, se define un flujo de datos que incluye el lenguaje visual
CORDIAL, un compilador de PiCO a MAPiCO y el emulador denominado MAPiCO.
A continuacion se describen los componentes mas importantes de la implementacion de
MAPiCO.
1.3.3.1. Especificacion Formal
PiCO[ADQV98] es un calculo que integra objetos concurrentes y restricciones como
elementos basicos. El modelo de objetos se extiende adicionando la nocion de un sistema
20
de restricciones, ademas de la nocion de delegacion de mensajes, confiriendo una manera
natural de expresar comportamientos de comunicacion usando sincronizacion en el paso
de mensajes. Uno de las aplicaciones de este calculo es la representacion musical, de
manera que es posible utilizar PiCO para modelar objetos musicales como armonıas,
patrones, secuencias de acordes y melodıas, entre otros.
Como ilustracion del calculo PiCO se muestra la codificacion de factorial [AB98]. Pri-
mero se muestra la definicion recursiva y luego su codificacion en PiCO.
fact(x, r) ::= r = 1 si x = 1|r = fac(x− 1) ∗ x si x > 0
fact(3, r)
.(v x y)(v fac)((∗fac . [input : (n, r)(?(n = 0).!(r = 1)
. |?(n > 0).(v y a)((!y = n− 1)
. |(fac/ input[y, a]))
. |!(r = a ∗ n)))])
. |!(x = 3).fac/ input[x, y])
MAPiCO es la maquina abstracta que implementa el calculo PiCO. En MAPiCO se
definen todos los componentes que confieren formalidad a la implementacion, de modo
que se logre un nivel de correspondencia entre el calculo y la maquina.
1.3.3.1.1. Estructuras de Datos .
Las estructuras de datos usadas por MAPiCO en la especificacion formal se describen
en la siguiente tabla:
RunQ: cola de ejecucion.
Obj: cola de objetos suspendidos.
MsgQ: cola de mensajes suspendidos.
AskQ: cola de procesos ask suspendidos.
S: Store.
Memoria de Ligaduras: memoria dinamica que almacena las pilas de procesos
y el arbol sintactico con las restricciones.
21
Memoria del Programa: memoria estatica que almacena las instrucciones a
ejecutar.
Registros internos: se definen cinco registros internos para la maquina.
1.3.3.1.2. Estados Inicial y Final .
Cada vez que se ejecuta un hilo, el proceso asociado cambia de estado; los estados de
un proceso se definen, de acuerdo a su actividad actual, en: ejecucion, listo, suspendido
o finalizado. Un estado en MAPiCO se representa como:
�Hilo, HBind, HAux, ObjQ, MsgQ, AskQ, RunQ, Store�
donde Hilo, HBind y HAux representan el proceso que esta siendo ejecutado. La
memoria de programa no se referencia en la definicion de estado ya que esta es estatica;
por lo tanto, no se modifica en tiempo de ejecucion.
Los estados inicial y final se definen a continuacion (• es utilizado para indicar que la
cola esta vacia y :: indica concatenacion de colas).
Estado Inicial: la maquina comienza en un estado donde las colas de objetos,
de mensajes, de ask y de ejecucion, estan vacias y no hay ligaduras; ademas, el
Store esta inicialmente vacıo.
� ~P ~P , ∅, ∅, •, •, •, •, ∅ �
Estado Final: a este estado solo se llega cuando no hay nada mas que planificar
en la cola de ejecucion. La maquina reconoce que los procesos que han quedado
suspendidos en Oq, Msq y Aq estan suspendidos y que no pueden ser reducidos.
� nil, B, H, Oq, Msq, Aq, •, S�
1.3.3.1.3. Reglas de reduccion .
En la semantica operacional de MAPICO las reglas de reduccion son transiciones de
estados a estados. Las reglas de reduccion se muestran en las figuras 1.9 y 1.10.
22
En MAPiCO cada regla toma el primer proceso de la cola de ejecucion RunQ y ejecuta
una paso de reduccion en el proceso. La regla SCHED remueve el proceso actual
en ejecucion, permitiendo que el siguiente pueda reducirse. NEW-REF es la regla
que define la creacion de nuevas variables; de modo que, el proceso (vx)−→P crea un
nuevo enlace de x a L, donde L es el nuevo nombre generado por el sistema. La regla
PARALLEL crea un nuevo proceso Q, lo situa al final de la cola RunQ, y sigue con
la ejecucion del proceso P. TELL define la forma en que se comenta al Store; asi, para
reducir un proceso tell(!φ.−→P ), la restriccion φ(L) es comentada al Store y los procesos
suspendidos en las colas Aq y Msq pasan a ejecucion para intentar ser reducidos, se
continua con la ejecucion de−→P . Para ASK se definen tres casos: ASK1 donde si el
store deduce φ(L), la maquina continua ejecutando (−→P ); ASK2 donde si el store logra
deducir ¬φ(L), la maquina elimina el proceso actual; y finalmente ASK3 caso en el
cual el Store no pude deducir φ(L), ni tampoco ¬φ(L), luego, se suspende el proceso y
se envia a la cola Aq.
En cuanto a las reducciones relacionadas con mensajes; MSgEnQ es la regla que define
la reduccion de un paso de mensaje a un objeto que no se encuentra en la cola Oq, caso
en el cual se suspende el mensaje en la cola Msq. La regla MsgComm define que si
el proceso es un mensaje I / li : [K].−→P a un objeto en la cola Oq y la etiqueta del
mensaje li concuerda con una en el conjunto de metodos del objeto, este ultimo se
elimina y el cuerpo del metodo−→Pi , con el nuevo enlace para K se envıan a la cola
RunQ para ejecucion. MsgDel define la reduccion en caso que el objeto (I ′, J ′) . [l1 :
(x1−→P1, . . . , lm : (xn)
−→Pm] exista en la cola Oq, no exista una etiqueta li para comunicarse
con I / li : [K].−→P , pero si posea una direccion de delegacion; entonces, el receptor
del mensaje se cambia por la direccion de delegacion. De igual manera si el objeto
anterior existe en Oq, noy ha una etiqueta li para comunicarse, y no tiene una direccion
de delegacion, el mensaje se suspende en la cola Msq como se describe en la regla
MsgWODel.
Para objetos se tienen las siguientes reglas; ObjEnQ que define la situacion en la cual no
hay ningun mensaje para comunicarse con el objeto (I, J). [l1 : (x1)−→P1, . . . , lm : (xn)
−→Pm]
en la cola Msq para comunicarse, por lo tanto el objeto es pasado a la cola de objetos Oq
para posterior reduccion. ObjComm presenta el caso en que el mensaje I/ li : [K].−→P
espera comunicarse con el objeto (I, J). [l1 : (x1)−→P1, . . . , lm : (xn)
−→Pm], y existe una
etique li; luego el mensaje es eliminado de la cola Msq, y la continuacion del mensaje−→P puesto para ejecucion, seguido por el cuerpo del metodo con el nuevo enlace para
23
K. ObjDel describe la misma situacion anterior, con delegacion, pero sin etiqueta li;
luego el mensaje es pasado al final de la cola RunQ,pero cambiando el objeto receptor
pr la direccion de delegacion y el objeto es pasado a la cola Oq. Por ultimo, para el
mismo caso, pero sin delegacion, ni etiqueta, el objeto se pasa a la cola Oq, como se
muestra en ObjWoDel.
1.3.3.2. Diseno de MAPiCO
MAPiCO esta compuesta por dos areas de memoria, cuatro colas para los diferentes
estados de ejecucion de un proceso, y un sistema de restricciones que provee, tanto el
almacenamiento de restricciones, como las operaciones ask y tell [AB98]. La entrada
de la maquina es codigo de bytes y se asume que es correcta, por lo que no se realizan
chequeos. La implementacion fue realizada en lenguaje Java. El diseno se muestra en
la figura 1.11.
Los elementos basicos en el calculo PiCO son: objetos, mensajes, restricciones, variables
y nombres, los cuales se modelados uno a uno en la maquina. Existen cuatro colas de
procesos: una cola para los objetos que aun no han establecido comunicacion o son
replicados, otra para los mensajes y en tercer lugar una cola de ask que han quedado
suspendidos. Debido a la naturaleza de PiCO como calculo de procesos concurrente
y por restricciones, la implementacion de MAPiCO esta asociada a un Sistema de
Restrticciones que mantiene un Store monotonico donde se almacena la informacion,
y al que se accede via operaciones ask para hacer preguntas y tell para adicionar
informacion.
El programa se ubica en una memoria estatica o Memoria de Programa donde se
almacenan todas las instrucciones en codigo de bytes para ser ejecutadas.
Por ultimo, existe un area de memoria dinamica o Memoria de Traduccion utilizada
para mantener las ligaduras de variables y nombres. En esta area de memoria tam-
bien son almacenados los parametros usados por los metodos y el arbol sintactico que
representa una restriccion.
1.3.3.2.1. Registros .
En MAPiCO se definen cinco registros de uso especıfico que guardan informacion de la
24
Figura 1.9: Reglas de Reduccion de la maquina abstracta MAPiCO, parte I
25
Figura 1.10: Reglas de Reduccion de la maquina abstracta MAPiCO, parte II
memoria y de los procesos, los cuales se muestran en el cuadro 1.6.
1.3.3.2.2. Formato de Instrucciones .
Las instrucciones estan representadas por un codigo de operacion y de 0 a 3 atributos.
Las instrucciones pueden ser clasificadas en tres grupos: para manipular procesos, para
definicion de objetos y para la construccion de predicados de primer orden. Los atributos
utilizados en el formato de instrucciones se describen a continuacion:
Opcode: codigo de operacion de la instruccion, 8 bits
Dir: direccion valida en la memoria de programa, 32 bits
Ind: indice dentro de alguna de las listas de variables o nombres, 16 bits
Num: numero constante entero. Para objetos especifıca el numero de metodos.
Para metodos y mensajes especifıca su nombre o referencia, 16 bits.
26
Figura 1.11: Diseno de MAPiCO
Fun: codigo de la funcion, 8 bits para el sistema de restricciones actual.
Pred: codigo del predicado del atomos, 8 bits
Ari: aridad de la funcion o del atomo, 8 bits
Con: codigo del conector, and(0), or (1), 8 bits
Cuan: codigo del cuantificador o negacions, ∃ (1) ∀ (2) not (0) 8 bits
1.3.3.2.3. Sistema de Restricciones .
En PiCO las restricciones se definen como predicados de primer orden(∅)[AB98] bajo
una sintaxis de terminos, atomos y sentencias. Ası en MAPiCO, estos predicados son
modelados por instrucciones que permiten construir el arbol sintactico que describe la
27
Registros Descripcion
PCA (Puntero a Codigo Actual) apunta a la instruccion en ejecucion.PVA (Puntero a Variables Actual) apunta al PV del proceso en ejecucion.PNA (Puntero a Nombres Actual) apunta al PN del proceso en ejecucion.PAA (Puntero Auxiliar Actual) apunta al PA delproceso en ejecucion.PAUX (Puntero Auxiliar) usado en la manipulacion y ejecucion
de procesos.
Cuadro 1.6: Conjunto de Registros de MAPiCO
restriccion. Esta particularidad permite que el sistema de restricciones se adicione pa-
rametricamente a la maquina; es decir, que dado un sistema de restricciones que exprese
sus restricciones en terminos de predicados de primer orden, este puede adicionarse a
MAPiCO sin mayores modificaciones.
El sistema de restricciones que utiliza la actual implementacion de MAPiCO define
restricciones de dominio finito; este sistema se describe en [CG01]. Se fundamenta en
el modelo de Bjorn Carlson [Car95] y fue implementado en lenguaje C.
1.4. OBJETIVOS Y CONTRIBUCIONES DE ES-
TE TRABAJO DE TESIS
El presente trabajo de tesis utiliza el calculo de procesos NTCC – Non-deterministic
Temporal Concurrent Constraint Calculus – [Val03] para definir e implementar su
maquina abstracta y virtual; la maquina se prueba en aplicaciones asociadas a NTCC:
Programacion concurrente de controladores RCX en robots LEGO.
NTCC es una extension de TCC [SJG94], que adiciona las nociones de No-determinismo
y Asincronıa actuando sobre sistemas Discretos-Temporales-Reactivos. NTCC permite
modelar: retardos unitarios o unit-delays, para forzar la ejecucion de un proceso en
el siguiente instante de tiempo; time-outs, que esperan durante el instante actual a
que una pieza de informacion este presente y, de lo contrario, activan un proceso para
ejecutar en el siguiente instante; preemption y tiempo multiforme, que permiten que los
procesos sean “regulados” por otros procesos, dando la posibilidad de definir multiples
formas de tiempo en vez de tener un unico reloj global. Finalmente, modelan sincronıa
28
al igual que TCC. La asincronıa es modelada como operaciones de retardos finitos
pero no limitados o unbounded-finite-delays y el no-determinismo por operaciones de
eventualidad limitada o bounded-eventuality.
La perspectiva reactiva de este calculo, hace que NTCC sea de gran aplicabilidad en
programacion de diversos dominios de concurrencia tales como: Shared Variables Com-
munication Systems, donde agentes interactuan escribiendo y leyendo informacion de
una locacion central o Store; Reactive Systems, donde se mantiene una interaccion conti-
nua con el ambiente; Timed Systems, en los que agentes se restringen por requerimientos
temporales y, finalmente, Syncronous y Asyncronous Systems. La aplicabilidad sobre
estos sistemas permite ilustrar la expresividad de NTCC, y para el caso del actual tra-
bajo de tesis permite ilustrar la aplicabilidad de NTCC para programar sistemas reac-
tivos como los dispositivos roboticos LEGO. En la actualidad existen algunos lenguajes
que permiten programar estos dispositivos siguiendo esta lınea, tales como LUSTRE y
ESTEREL [MR]; lenguajes sıncronos para robots LEGO y JCC[SRP03] que permite
integrar Timed Default Concurrent Constraint Programming con Java.
Este trabajo de tesis describe el diseno e implementacion de la maquina abstracta y la
maquina virtual de NTCC (LMAN). Adicionalmente, se describe el diseno y acople del
compilador NTCC-LMAN, que permite escribir programas NTCC en alto nivel para la
maquina. Los objetivos de este trabajo se describen a continuacion:
Construir la maquina abstracta del calculo NTCC, manteniendo una equivalencia
entre la maquina y el calculo.
Disenar e Implementar la maquina virtual del calculo NTCC, asegurando eficien-
cia y ejecucion en tiempo real sobre Robots LEGO MindStorm.
Acoplar un Sistema de Restricciones de dominios finitos y asegurar ortogonalidad
en su adicion a la maquina.
Disenar y Acoplar un Compilador NTCC-LMAN que permita crear programas en
alto nivel para LMAN.
LMAN toma principalmente como referencia las maquinas para calculos de procesos
TyCO[Lop99] y MAPiCO[AB98] descritas en brevedad en las secciones anteriores. La
semantica utilizada es realmente cercana a la defincion del calculo mismo, demostran-
do ası su expresividad. La especificacion de una maquina asbtracta para el calculo le
29
confiere una base formal a la implementacion de la maquina virtual, idea tomada de la
maquina de TyCO[Lop99]; adicionalmente, facilita las pruebas formales de correspon-
dencia entre el calculo y la actual implementacion. La maquina virtual es implementada
como un emulador de codigo de bytes que se compone de cuatro bloques funcionales: me-
moria de programa, Interfaz LEGO, Interfaz STORE, y el ControlLMAN. A diferencia
de otras implementaciones de otras maquinas para calculos de procesos[AB98, Lop99]
LMAN maneja no solo la nocion de planificacion de procesos, sino tambien de planfi-
cacion de maquinas en el tiempo.
Un sistema de restricciones de dominio finito[CG01] ha sido adicionado a LMAN. La
definicion de restricciones como formulas de primer orden en LMAN, idea adoptada de la
implementacion de MAPiCO[AB98], asegura que el sistema de restricciones se adiciona
de forma parametrica a la actual implementacion, de modo que para extensiones futuras
cualquier sistema de restricciones que exprese sus restricciones como formulas de primer
orden puede ser adicionado. Respecto a la ejecucion, LMAN resulta completa y eficiente
ya que aunque se ejecuta desde una estacion de trabajo y requiere de un protocolo
de comunicaciones con el robot LEGO, se observa que los programas NTCC corren
eficientemente y en tiempo real. Adicionalmente, su implementacion posibilita modelar
problemas que involucran hasta dos agentes roboticos; con algunas adiciones es posible
modelar sistemas multiagentes.
LMAN ha sido desarrollada para servir como ambiente de pruebas y para la ensenanza
introductoria de lenguajes de programacion concurrente y por restricciones. Para ello. ha
sido disenado e implementado el compilador NTCC-LMAN y un lenguaje Visual[FQ04],
haciendo que la interfaz con el usuario resulte amigable. En la actualidad, no conocemos
de otra implementacion de un calculo de procesos, temporal, concurrente por restric-
ciones validado sobre robots LEGO. Consideramos que la maquina que aquı se reporta
es la primera implementacion de esta naturaleza. En particular, LMAN constituye una
implementacion completa y eficiente del calculo NTCC; esta modela de manera cercana
las reglas de reduccion del calculo, facilitando las pruebas formales de correctitud en la
actual implementacion.
30
2 CALCULO NTCC
En este capıtulo se describe el calculo NTCC [Val03], base del presente trabajo de tesis.
Se describe en brevedad la sintaxis, semantica operacional y ejemplos de aplicaciones
NTCC.
2.1. Descripcion General
La extension TCC agrega la nocion de tiempo a CCP. Existen, sin embargo, otras
caracterısticas que se hace necesario modelar; dos de ellas son la asincronıa y el no-
determinismo. Procesos como: “el sistema debe entregar un mensaje pero no hay un
limite de tiempo preciso sobre cuando debe hacerlo”, “el sistema debe ejecutar la tarea
c en alguna de las siguientes t unidades de tiempo” o la posibilidad de escoger entre
multiples opciones correctas para ejecutar una tarea (Ejemplo: la decision que toma un
dispositivo robotico en el momento de moverse al ejecutar zig-zag), no son expresables
en TCC.
Con los ejemplos anteriores es posible concluir lo siguiente: “la asincronıa da libertad a
los procesos de responder a una velocidad relativamente indeterminada. Solo asegura que
los procesos se ejecutan en algun momento, mas no asegura cuando. El no-determinismo
es importante para modelar respuestas y comportamientos correctos e impredecibles de
los procesos. ”[Val03].
Estas propiedades tambien facilitan la tarea de describir procesos computacionales, sin
necesidad de sobre-especificarlos.
Debido a las necesidades de modelar y utilizar los beneficios de las propiedades anterior-
mente expresadas, surge el calculo NTCC (Non-Deterministic Temporal Concu-
rrent Constraint Programming ), que es una extension ortogonal del calculo TCC,
31
al que se adicionan las propiedades de no-determinismo y asincronıa . En NTCC es
posible modelar con facilidad: retardos unitarios, para forzar la ejecucion de un proceso
en el siguiente instante de tiempo; time-outs, que esperan durante el instante actual
a que una pieza de informacion este presente y, de lo contrario, activan un proceso
para ejecutar en el siguiente instante; preemption y tiempo multiforme, que permiten
que los procesos sean “regulados”por otros procesos, dando la posibilidad de definir
multiples formas y senales de tiempo en vez de tener un unico reloj global. Finalmente,
modela tambien sincronıa al igual que TCC. La asincronıa en NTCC es representada
por operaciones de retardos finitos pero no limitados o unbounded-finite-delays y el no-
determinismo por operaciones de eventualidad limitada o bounded-eventuality, que se
tratan en los procesos ∗P y σ when ci doPi respectivamente.
NTCC es de gran aplicabilidad en la programacion de dispositivos roboticos, sincroni-
zacion de procesos musicales y sistemas multiagentes; aplicaciones en que se presentan
ciclos en los que se recibe una entrada del ambiente, se procesa y luego se regresa
de nuevo al ambiente la correspondiente salida, comportamiento propio de sistemas
reactivos. NTCC sigue el mismo comportamiento de TCC, en cuanto al manejo de la
unidad de tiempo; es decir, el lapso entre el retorno de una respuesta al ambiente y
la recepcion de la entrada del mismo, define una unidad de tiempo. A partir de esta
concepcion reactiva-temporal es que se definen nuevos procesos y propiedades en estos
calculos temporales.
2.2. Sintaxis de NTCC
La sintaxis de NTCC difiere en forma respecto a la de TCC, pero los conceptos glo-
bales son similares; ademas de incluir nuevos operadores para las propiedades de no-
determinismo y asincronıa. La sintaxis de NTCC esta dada en el cuadro 2.1.
c, d, ... denotan las restricciones. P, Q, A, ... representan los procesos del calculo. x, y, ..
se utilizan para hacer referencia a las variables de los procesos.
El proceso skip es utilizado para representar inactividad.
El proceso tell c adiciona la restriccion c al Store en el intervalo de tiempo actual;
operacion que puede causar inconsistencias en el Store, si c no es coherente con la
informacion actual.
32
P, Q, ... = skip Nohaga nada|tell(c) tell c
|∑
i∈I when (ci) doPi Seleccione un Pi, si ci, i ∈ I|P ||Q Ejecucion en paralelo
|Local x in P Localidad|next P Ejecute P en la siguiente unidad de tiempo
|unless (c) do next P A menos que deduzca c ejecute next P|!P Replicacion| ? P Retardo infinito pero no limitado de P
Cuadro 2.1: Sintaxis de NTCC
El proceso∑
i∈I when (ci) doPi, llamado seleccion multiple con guarda (guarded-choice),
donde I es un conjunto de ındices, tiene como tarea escoger no-deterministicamente
algun Pj, j ∈ I, para el cual cj pueda deducirse de la informacion contenida en el Store.
Si se logra deducir cj, se ejecuta Pj y los demas procesos Pi, i ∈ I− j seran eliminados.
Si el Store deduce la negacion de todas las guardas cj ( ¬cj,∀j∈I), se eliminan todos los
Pj; y finalmente, si no hay suficiente informacion para deducir cj, entonces se suspende
el proceso∑
. Este proceso modela el no-determinismo en el calculo.
El proceso local x in P modela el encapsulamiento, mediante la definicion de una varia-
ble local x utilizada unicamente por P ; la informacion acerca de x no puede ser vista
por ningun proceso, excepto P .
El proceso next P ejecuta P en la siguiente unidad de tiempo; es decir que espera una
unidad para ejecutar P . Este proceso junto con !P es la unica forma que un proceso
perdure en el tiempo.
La composicion P ||Q, denota la ejecucion paralela de P y Q. Su comunicacion se hace
solo a traves de la informacion en el Store.
La primitiva unless (c) do next P , tambien conocida como el ask negativo, ejecuta P
en la siguiente unidad de tiempo, a menos de que, c pueda deducirse en la unidad de
tiempo y Store actuales. Esta primitiva permite modelar “time-outs”, ya que espera
que en la unidad actual se presente la informacion c; de lo contrario, se activa P en la
siguiente unidad.
!P modela el proceso de replicacion, que consiste en crear una copia de p de manera no
limitada en la unidad actual y en cada unidad de tiempo futura. Esta es la forma de
33
modelar un comportamiento infinito en este calculo.
Finalmente, ?P activa P en algun instante de tiempo, ya sea el actual o alguno futuro,
permitiendo modelar asincronıa de procesos.
2.3. Semantica de NTCC
2.3.1. Sistema de Restricciones Aritmetico-Modular
El sistema de restricciones que usa el calculo NTCC, llamado Sistema de Restriccio-
nes Aritmetico-Modular, se apoya en la definicion del sistema de restricciones pre-
sentada en el capitulo anterior (ver definicion 1.2.1.1), modificando algunos aspectos,
que se describen a continuacion.
Definicion 2.3.1 Sea n > 0, Se define A[n] como un sistema de restricciones tal que:
Σ esta dado por 0, 1, 2....n− 1, succ, pred, +, x, =, <.
4 es el conjunto de sentencias validas de la aritmetica modulo n.
Se entendera por A[n] un sistema de restricciones sobre los naturales, modulo n; es
decir, que el rango de los posibles valores es 0..n − 1. Se utilizara v para referenciar
cualquier posible valor; los operadores aritmeticos tambien estaran sujetos al modulo
n. Este sistema se asumira como sistema de restricciones por defecto para el calculo
NTCC, de aquı en adelante.
NTCC tiene parametrizado su sistema de restricciones por lo cual no tiene que limitarse
a utilizar uno solo. Pueden utilizarse otros sistemas de restricciones, tales como: Inter-
valos racionales, tipos enumerados, sistemas de restricciones Kahn y Getzen[VSG96],
entre otros.
2.3.2. Semantica Operacional
La semantica operacional de NTCC [Val03] esta dada en terminos de las relaciones de
reduccion → y ⇒.
34
Las transiciones de un proceso a otro modelan el transcurso de una computacion: definen
paso a paso la ejecucion de un ”programa”en el calculo.
Se define una transicion interna (no observable) de la forma < P, d >→< P ′, d′ >,
que se lee ”P con Store d reduce, en un paso interno, a P ′con Store d′ ”, donde P ′ es
una evolucion interna de P .
Una transicion externa (observable) de la forma P →(c,d) R, se lee ”P , con entrada
c del ambiente, reduce en una unidad de tiempo a R, con salida d al ambiente”, donde
R es una evolucion observable de P .
La reglas de la semantica operacional se exponen en el cuadro 2.2:
TELL<tell(c),d>→<skip,d∧c>
SUM<
∑i∈I when ci do Pi,d>→<Pj ,d>
if d |= cj, j ∈ I
PAR <P,c>→<P ′,d><P ||Q,c>→<P ′||Q,d>
UNL<unless c next P,d>→<skip,d>
if d |= c
LOC <P,c∧∃xd>→<P ′,c′><(local x,c) P,d>→<(local x,c′) P ′,d∧∃xc′>
STAR<?P,d>→<nextnP,d>
if n ≥ 0
REP<!P,d>→<P ||next !P,d>
STRγ1→γ2
γ′1→γ′2if γ1 ≡ γ′1 y γ2 ≡ γ′2
OBS <P,c>→∗<Q,d> 6→P=⇒(c,d)R
if R ≡ F (Q)
Cuadro 2.2: Semantica de NTCC
En el cuadro 2.2, la notacion de las reglas PQ
se lee, cuando P se cumple, entonces Q se
cumple”.
La regla TELL adiciona c al Store d, quedando un nuevo Store d ∧ c y el proceso
reducido a skip.
35
SUM escoge, no-deterministicamente, una guarda cj que pueda deducir el Store y
ejecuta entonces el proceso Pj. Si se deduce lo contrario de cada una de las guardas
ci ( ¬ci,∀i∈I), no se ejecuta ningun proceso Pi. Si no hay suficiente informacion para
deducir algun ci, se suspende el proceso∑
i∈I when ci doPi.
La regla PAR especifica que en una transicion interna solo se reducira uno de los dos
procesos.
UNL modela la ejecucion de P siempre y cuando la condicion c no sea deducida por el
Store. Esto se presenta de dos formas: la primera ocurre al deducirse ¬c y la segunda es
cuando el Store una vez alcanzado el estado de quietud no tiene suficiente informacion
para deducir si c se cumple.
LOC representa la propiedad de encapsulamiento creando una variable x a la que solo
puede aceder el proceso P ; esto se modela ocultando a P la informacion de alguna x
que se encuentre en el Store global mediante la cuantificacion existencial de esta (∃x d).
A su vez P oculta al Store global la informacion de la variable x mediante un Store
local c, el cual contendra toda la informacion sobre la x local.
La regla STAR activa, no-deterministicamente, el proceso P , sea en la unidad de tiempo
actual o en una futura; se modela ası la espera de tiempo limitada, mas no definida.
REP especifica la ejecucion de P en todos las unidades de tiempo, modelando el com-
portamiento infinito de un proceso.
La regla STR dice que procesos estructuralmente congruentes tienen reducciones que
producen procesos congruentes.
Las anteriores reglas se agrupan bajo el nombre de transiciones internas.
La regla OBS dice que una transicion observable de P , etiquetada por < c, d >, se
obtiene al realizar una secuencia interna de transiciones desde la configuracion inicial
< P, c > a la configuracion final < Q, d >, en la que ya no es posible hacer mas
evoluciones internas. El proceso residual R a ser ejecutado en la siguiente unidad de
tiempo, es equivalente a (F (Q)) ( Futuro de Q) . Futuro de Q se obtienen eliminando
de Q las sumatorias que no dispararon actividad en el intervalo actual, junto con la
informacion local almacenada en Q y eliminado el Store actual, dejando solo los procesos
next y unless[Val03].
36
Es importante mencionar como NTCC, al igual que TCC, introduce la programacion
reactiva-temporal [Val03]. El ambiente estimula a un proceso Pi dandole una entrada
ci. El proceso P reacciona en una cantidad de tiempo finita al ambiente dandole una
salida c′i y evolucionando al proceso Pi+1. Cada respuesta a estos estımulos definen una
unidad de tiempo. Los observadores externos al proceso no observan las transiciones
internas, solamente las entradas y salidas definidas.
2.4. Definiciones Recursivas
Resulta conveniente especificar determinados comportamientos mediante la recursion.
Por este motivo, se describira la forma de codificarla en NTCC. NTCC define la recur-
sion de la siguiente forma [Val03].
q(x) =def Pq
Donde q es el nombre de un proceso y Pq su cuerpo, que puede tener como maximo una
ocurrencia de q, y antepuesta al operador next; lo anterior es para forzar que se tenga
una respuesta de q(x) en cada unidad de tiempo, pues no se quiere que Pq haga infinitos
llamados recursivos a q en la misma unidad de tiempo. Para tratar los llamados q(t),
se considera a t como una variable con un valor v (el Store puede deducir que t = v),
obteniendose Pq[v/x], donde la operacion [v/x] denota el remplazo de toda ocurrencia
de x por v.
En NTCC se debe evitar que las variables que ocurren libres en Pq sean capturadas por
el alcance de las variables locales. Se hace necesario entonces utilizar el alcance estatico,
con la siguiente notacion:
q(x)[y1, ....., yn] =def Pq
Donde y1, ....., yn son las variables que pueden ocurrir libres en P .
Se expondra el siguiente ejemplo para aclarar la diferencia entre alcance estatico y
dinamico [Val03].
Ejemplo 2.4 Sea q(x) =def tell(y = 1)||next(localy)(q(x)||when y do P )
37
Si se considera alcance dinamico, en el momento que se ejecute el llamado recursivo
((localy)(q(x)||when y do P )) se asumira que el proceso tell(y = 1) hace referencia a la
variable local y, lo cual no es cierto porque tell(y = 1) utiliza una variable global. Si se
desea obtener la independencia de variables entre el proceso tell(y = 1) y el when y do P ,
es necesario utilizar alcance estatico, mencionando las variables que pueden ocurrir
libres en q(x).
2.4.1. Codificacion
A continuacion se presenta la codificacion para modelar recursion en NTCC.
Un proceso q(t) que representa el primer llamado recursivo, se define de la siguiente
forma:
(local q qarg)(pq(x) =def Pqq || q(t))
donde:
El proceso recursivo pq(x) =def Pqq es:
!(when call(q) do (local x)(x← qarg || Pq))
siendo:
- call q(t) la abreviacion de x = 1.
- x← t la abreviacion de Σv when t = v do !tell(x = v)
q(t): tell(call(q)) || tell(qarg = t)
q y qarg dos variables no libres en Pq
Se utilizan las variables locales q y qarg, para abolir posibles interferencias entre los
llamados recursivos externos.
38
2.5. Celdas
Las celdas proveen herramientas para el analisis y especificacion de estructuras de datos
persistentes y variables, por lo cual es importante modelarlas en el calculo NTCC.
Para el modelamiento de las celdas se debe asumir que el sistema de restricciones cuenta
con un predicado que pueda expresar el estado de cambio de una variable; este predicado
sera change.
Definicion 2.5.“ Se define una celda x : (v) como una estructura x cuyo valor actual
es v y que puede mantenerse o cambiar en el futuro” [Val03]. Una celda x : (v) tiene la
forma:
x : (z) =def tell(x = z) ||unless change(x) next x : (z)
La anterior definicion representa una celda x, cuyo valor actual es z y, a menos que se
decida cambiar este valor, (tell chage(x) = 1) x, tomara el mismo valor z en el proximo
instante.
Ademas de la definicion de la celda existe otro operador utilizado. Se trata del operador
exchg[x, y], llamado operador de intercambio ( exchage). Se utiliza para asignar nuevos
valores sobre las celdas. Sea exchg[x, y], v el valor actual de x y y otra celda y g(v) la
funcion que calcula el siguiente valor de x. Se tiene:
exchg[x, y] = Σv when x = v do ( tell(change(x)) || tell(change(y))
||next(x : (g(v)) || y : (v)))
El uso del operador exchg[x, y] podra ser apreciado en la siguiente seccion de Aplica-
ciones y Ejemplos.
2.6. Aplicaciones y Ejemplos
Se ha mencionado anteriormente que por las propiedades reactivas-temporales, el no-
determinismo y la asincronıa que modela NTCC, existe un gran numero de aplicaciones
en las que se pueden demostrar la expresividad de este calculo, tales como: la progra-
macion de dispositivos roboticos, la sincronizacion de procesos musicales y los sistemas
39
multiagentes. En esta seccion se mostraran algunos ejemplos, enfatizando la aplicacion
principal de este trabajo de tesis: Programacion Concurrente de controladores RCX en
dispositivos LEGO. Los ejemplos expuestos aquı son tomados de [Val03].
2.6.1. Controladores RCX: Ejemplo de Zig-Zag
“Un RCX es un dispositivo programable fabricado por LEGO, con el cual se pueden
crear diferentes clases de robots autonomos [LP99]. La tarea de zig-zag [Fre99] consiste
en que el robot-RCX se mueva aleatoriamente de izquierda a derecha con las siguientes
condiciones: 1. el robot no puede ir hacia adelante si su ultima accion fue ir adelante.
2. no puede girar a la derecha si su penultima accion fue ir a la derecha, 3. la segunda
condicion aplicada a la izquierda”[Val03].
La solucion que se plantea evita la sobre-especificacion, planteando solo los aspectos que
conciernen a la descripcion de la solucion. Se usaran dos celdas a1 y a2 para tener una
referencia de los dos ultimos movimientos que ha hecho el RCX. Ademas, se definiran
las constantes f, r, l ∈ D − 0 para denotar los predicados f=adelante(forward),
r=derecha(right), l=izquierda (left). La solucion es la siguiente:
goF =def exchf [a1, a2] || tell(forward)goR =def exchr[a1, a2] || tell(right)goL =def exchl[a1, a2] || tell(left)
Zigzag =def !(when (a1 6= f) doGoF+ when (a2 6= r) doGoR+ when (a2 6= l) doGoL)
GoZigzag =def a1 : (0) || a2 : (0) ||Zigzag
Inicialmente las celdas a1 y a2 contendran valores diferentes de f , r y l, lo cual hace
que se escoja no-deterministicamente la direccion de arranque; despues el RCX se di-
rigira por las condiciones 1, 2 y 3, grabando en a1 y a2 los movimientos anteriores. A
continuacion se da un ejemplo de la funcion exch[a1, a2]:
exchf [a1, a2] =def
∑v∈f,r,l,0 when a1 = v do
( tell(change(a1)) || tell(change(a2)) ||next( a1 : (f) || a2 : (v)))
Las demas operaciones exch[a1, a2] (exchr[a1, a2] y exchl[a1, a2]) son similares a la de-
finicion anterior.
40
2.6.2. Sistemas Multiagentes: Presa y Predador
“El juego Presa y Predador [MBD86] es muy famoso debido a que sus multiples analisis
desde diferentes puntos de vista [HS96], permiten representar entornos multi-agentes
[SV00]. Este ejemplo puede ser modelado con multiples robots-RCX.”
El juego consiste en que los predadores y la presa se mueven en un tablero toroidal; si
llegan al final de este, salen por el otro lado del mismo. La presa y el predador se pueden
mover horizontal o verticalmente, en cualquier direccion. Los predadores tendran cierta
ventaja sobre su presa, ya que corren dos casillas del tablero mientras que la presa solo
puede correr una.
El objetivo del predador es capturar a la presa; esto ocurre cuando la presa se mueve
a una posicion entre las tres casillas que el predador puede atacar: la casilla donde se
encuentra actualmente el predador, la anterior a donde se encontraba o la casilla de la
mitad.
El juego comienza con la presa ubicada al frente de los predadores y estos posicionados
en la misma fila. El comportamiento que debe adoptar la presa para poder escapar
es ejecutar un zigzag no predecible sobre el mundo, mientras que la estrategia de los
predadores es cooperar entre ellos para capturar a la presa. De tal manera que, cuando
un predador se encuentre frente a la presa, se declarara como lıder del ataque y los
otros predadores seran sus cooperadores en la captura de la presa. Como consecuencia,
la posicion de lıder se alterna dependiendo de quien este mas cerca de la presa.
2.6.3. Aplicaciones Musicales: Control de Improvisacion
Un ejemplo de las aplicaciones musicales que tiene el calculo NTCC es el control de
improvisacion. Este consiste en tener un conjunto de musicos m, que tocaran un numero
fijo de notas (en este caso se tomara 3). Cada musico puede escoger que notas tocar,
pero se le establece un tiempo que puede utilizar entre las notas del bloque. Ejemplo:
sea la partitura del musico 1 [5,6,2], esto quiere decir que entre la primera y la segunda
nota tiene un espacio de 5 silencios para improvisar, entre la segunda y tercera 6 y
despues de la tercera 2. Cuando el musico termine su interpretacion de las tres notas
correspondientes, debe esperar a la senal del conductor que le dice que todos los musicos
ya han terminado de tocar su bloque y el puede volver a empezar. El tiempo entre los
41
bloques consecutivos de cada musico no esta determinado, pero hay la restriccion de
que no debe demorarse mas que la suma de todos los tiempos de las partituras de los
otros musicos.
Los dos anteriores ejemplos se profundizan en [Val03], PHD Tesis de Frank d. Valencia.
42
3 LMAN: MAQUINAABSTRACTA
Este capıtulo describe el Analisis y la Especificacion formal de la Maquina Abstracta
LMAN . Se presenta la evaluacion de alternativas sobre la implementacion, seguida de
la especificacion de la maquina abstracta: notacion, sintaxis de los procesos, las reglas de
reduccion que describen su funcionamiento y constituyen su nucleo, los estados inicial
y final, finalizando con un diagrama de transiciones que resume su funcionamiento.
3.1. Analisis
A continuacion se muestran las consideraciones que se tomaron en la etapa del analisis
de este trabajo de tesis, las cuales fueron determinantes para las siguientes etapas de
diseno e implementacion.
3.1.1. Entorno de Programacion NTCC
LMAN , hace parte de un flujo de implementacion que tiene como objetivo proveer
un entorno de programacion aplicativa. Este entorno de programacion NTCC [Val03]
se divide en 5 bloques funcionales(ver figura 3.1). El bloque superior VIN se encuentra
en desarrollo como proyecto de grado independiente al presente[FQ04] y su objetivo
es elevar el nivel de programacion en el calculo, programando en un lenguaje iconico.
El siguiente modulo es el COMPILADOR NTCC-LMAN que ademas de que actua
como un componente integrador entre el lenguaje visual y LMAN, permite programar
NTCC en alto nivel; su diseno se trata en el capıtulo 5. Los ultimos tres bloques hacen
referencia a LMAN y la base que la soporta; estos bloques funcionales se tratan en el
43
siguiente capıtulo que describe la maquina virtual. El H8/300L es el microprocesador
del RCX brick y legOS es el sistema operativo que LMAN utiliza como interfaz con
este microprocesador. La integracion del lenguaje visual, el compilador y LMAN se hace
posible, dado que los tres utilizan el calculo NTCC base; de esta manera, el lenguaje
visual genera codigo NTCC, que el compilador entiende como entrada para la generacion
de codigo de bytes LMAN.
Figura 3.1: Flujo del entrono de programacion NTCC
3.1.2. Evaluacion de Alternativas de Implementacion para laMaquina Abstracta
En el desarrollo de LMAN, maquina que implementa el calculo NTCC [Val03] para
programacion de dispositivos roboticos LEGO se presentaron varias alternativas para
su implementacion. Por esta razon, se hizo conveniente establecer una analisis de al-
ternativas que permitiera decidir de manera objetiva, cual era la opcion optima. Los
criterios que se consideraron pertinentes para evaluar cada alternativa se describen a
continuacion:
Eficiencia en Tiempo de Ejecucion: Trata el factor del tiempo en la ejecucion
de un programa sobre la implementacion de la maquina.
Manejo Sistema de Restricciones: Trata la integracion e interaccion entre la
maquina y el sistema de restricciones.
Eficiencia en el Manejo de Memoria: Trata el manejo de memoria eficiente
sobre la implementacion de la maquina.
44
El modo de calificacion de cada indicador, fue dado cuantitativamente en modo ascen-
dente, siendo 1 la opcion mas desfavorable y 10 la mas conveniente.
El cuadro 3.1, muestra la evaluacion de alternativas, posteriormente se sustenta la
puntuacion asignada para cada una de las opciones en los criterios evaluados.
Criterios/Indicadores Traductor Maquina Virtual
Eficiencia Tiempo de Ejecucion 10 8Manejo de Sistema de Restricciones 8 10
Eficiencia Manejo de Memoria 6 8Total 21 25
Cuadro 3.1: Evaluacion de Alternativas de Implementacion para la Maquina Abstracta
Las alternativas propuestas y su analisis de criterios sigue a continuacion. Los argumen-
tos dados toman como referencia otras implementaciones similares a las alternativas en
analisis.[LY97][Leg00].
Descripcion:
• Traductor : Un traductor [AB98] como su nombre lo indica, se encarga de
traducir un programa durante la etapa de compilacion, de un lenguaje de
alto nivel a uno equivalente en un lenguaje que pueda ejecutar el computador
o el dispositivo robotico.
• Maquina Virtual : La maquina virtual [Com00] es un procesador no imple-
mentado en Hardware, que actua como el ejecutor notacional de un lenguaje
de programacion particular.
Eficiencia en Tiempo de Ejecucion:
• Traductor : Debido a que la traduccion se realiza en tiempo de compilacion,
el programa sera ejecutado directamente por el dispositivo robotico; luego el
tiempo en ejecucion serıa optimo. Valoracion: 10.
• Maquina Virtual : La maquina virtual interpreta el programa en tiempo de
ejecucion, luego comparando con un traductor su desempeno no serıa el
mejor. Valoracion: 8.
Manejo Sistema de Restricciones:
45
• Traductor : Debido a que el traductor actua en tiempo de compilacion, su
integracion con el modulo del sistema de restricciones se harıa extensa; ya
que serıa necesario unir ambos bloques de codigo para asegurar un funcio-
namiento en conjunto. Valoracion: 8.
• Maquina Virtual : La implementacion de una maquina virtual confiere modu-
laridad, lo cual combinado con su caracterıstica de interpretacion del progra-
ma en tiempo de ejecucion; posibilita la adicion del sistema de restricciones
como un modulo funcional, definiendo solamente una interfaz que le permita
interactuar con el control de la maquina. Valoracion: 10.
Eficiencia en el Manejo de Memoria:
• Traductor : Un traductor combinarıa en tiempo de ejecucion el bloque de
control que implementa la semantica operacional del calculo, con el codigo
del programa a ejecutar. Esto generarıa que los programas traducidos fuesen
de mayor tamano en memoria y que posiblemente requirieran de mayores
recursos mientras se realiza la traduccion. Valoracion: 6.
• Maquina Virtual : La maquina virtual interpreta los programas en tiempo de
ejecucion; por lo cual se separa el control de las construcciones hechas en el
calculo. Esto permitirıa un manejo mas eficiente de memoria, ya que solo se
consumirıan los recursos de ejecucion. Valoracion: 8.
Como conclusion de las valoraciones dadas, la alternativa que se escoge para imple-
mentacion es una maquina virtual . Una maquina virtual confiere modularidad a la
implementacion, eficiencia en el manejo de memoria, adminte la integracion de una
manera transparente del sistema de restricciones y el fundamento sobre la base formal
de una maquina abstracta.
3.1.3. Evaluacion de Alternativas de la plataforma de imple-mentacion para la Maquina Virtual
Para implementar una maquina virtual sobre un dispositivo robotico LEGO, existen
varias alternativas de plataformas de programacion; por este motivo se hace conveniente
establecer un analisis para decidir objetivamente cual es la alternativa optima. Los
criterios que se consideraron pertinentes para evaluar cada alternativa son los siguientes:
46
Eficiencia: Evalua el tiempo de ejecucion, la gestion de memoria y el manejo del
microprocesador.
Escalabilidad y Mantenimiento: Evalua las ventajas de la plataforma: faci-
lidad de instalacion, lenguajes admitidos, transparencia en las actualizaciones,
manejo de perifericos del robot.
Restricciones Legales: Evalua el tipo de restricciones que existen en la adqui-
sicion y utilizacion de la plataforma.
Compatibilidad: Evalua la portabilidad y el nivel de acceso por el usuario final
a la plataforma.
El modo de calificacion de cada indicador, fue dado cuantitativamente en modo ascen-
dente, siendo 1 la opcion mas desfavorable y 10 la mas conveniente.
El cuadro 3.2, muestra la evaluacion de alternativas, posteriormente se sustenta la
puntuacion asignada para cada una de las opciones en los criterios evaluados.
Criterios/Indicadores LEJOS BrickOS Maquina NQC(java) (legOS) Estandar de
(c++ y c) LEGO
Eficiencia 5 8 10 9Escalabilidad y Mantenimiento 10 10 1 6
Restricciones Legales 10 10 10 10Compatibilidad 7 8 7 8
Total 32 36 28 33
Cuadro 3.2: Evaluacion de alternativas de la plataforma de implementacion para laMaquina Virtual
Las alternativas propuestas y su analisis de criterios sigue a continuacion. Los argu-
mentos dados toman como referencia la documentacion y pruebas realizadas sobre las
alternativas en analisis.[LY97][Leg00].
Descripcion:
• LEJOS : Implementacion de la maquina virtual de JAVA para los robots
LEGO. Permite el manejo de todos los perifericos del RCX, el control total de
47
los 32Kb de RAM y la programacion orientada a objetos en JAVA. El driver
de la torre LEGO USB se encuentra bajo desarrollo (para Linux solamente).
Funciona sobre Linux y Windows. [SR00].
• BrickOS : Sistema operativo de codigo abierto para robots LEGO, antes lla-
mado legOS. Permite programar en lenguajes C y C++ el RCX brick, admite
el manejo de todos los perifericos del RCX ,el control total de los 32Kb de
RAM y la programacion orientada a objetos. El driver de la torre LEGO
USB se encuentra bajo desarrollo (para Linux solamente); el driver de la
torre serial ha sido desarrollado y probado en Linux. Funciona sobre Linux,
Windows y MacOS. [MLNP00].
• Maquina estandar de LEGO : El RCX tiene un firmware original en forma de
maquina virtual para su control. Permite el manejo de todos los perifericos y
la programacion se realıza por medio de una interfase visual basica llamada
RIS (Robotic Invention System) SDK que funciona solo en Windows y Mac.
Esta maquina admite un numero de variables globales de 32 y locales de 16,
un numero maximo de programas en memoria de 5, cada uno con maximo
10 tareas y 8 subrutinas. Tiene soporte USB y serial. [Leg00].
• NQC(Not Quite C): Es un compilador de codigo de bytes nativo,que utiliza
la maquina estandar de LEGO en su funcionamiento. Toma los programas
escritos con una sintaxis basica muy similar al lenguaje C, de ahı su nombre; y
los traduce al codigo de bytes que entiende la maquina virtual estandar. Tiene
limitaciones en el manejo de variables (32),no se pueden definir estructuras
de datos,las subrutinas no pueden retornar valores y no admiten parametros.
Funciona en Windows, Linux y MacOS.[Bau00].
Eficiencia:
• LEJOS : La maquina virtual de JAVA es interpretada y maneja objetos, ra-
zones que pueden generar mas consumo de memoria y extender el tiempo de
ejecucion de los programas sobre el robot LEGO, tal como se ha observa-
do en otras implementaciones de maquinas virtuales en JAVA ejecutandose
sobre estaciones de trabajo [AB98]. Valoracion: 5.
• BrickOS : Se ha demostrado que la programacion C y C++ resulta eficiente,
adicionalmente admite una programacion estructurada y orientada a objetos
que confiere modularidad a las implementaciones. Lo anterior, en conjunto
48
con las habilidades de BrickOS para el control del hardware de robot, per-
miten lograr una buena combinacion en eficiencia. Valoracion: 8.
• Maquina estandar de LEGO : la programacion directamente en el codigo de
bytes asegura un buen desempeno, ya que se estarıa tratando directamente
con las instrucciones nativas del microprocesador del RCX. Valoracion: 10.
• NQC : Aunque la sintaxis de NQC es basica, su propiedad de compilar al
codigo de bytes la hace eficiente en tiempo de ejecucion. No obstante el
manejo de memoria no resulta tan eficiente, debido a las limitaciones del
lenguaje. Valoracion: 9.
Escalabilidad y Mantenimiento:
• LEJOS : La implementacion de una maquina virtual confiere modularidad,
como se ha mencionado antes; esto hace de LeJOS un sistema administrable.
La programacion en lenguaje JAVA posibilita realizar construcciones com-
pletas y complejas. La programacion de los perifericos del RCX se realiza
mediante librerıas, ademas de que es posible utilizar las librerıas estandar.
Las actualizaciones son transparentes, ya que solo se requiere actualizar a
una nueva version de la maquina virtual, de modo que los programas siguen
ejecutandose sin modificaciones de fondo. Valoracion: 10.
• BrickOS : Es un sistema operativo que continuamente esta actualizandose
en versiones. El uso del lenguaje C como herramienta de programacion, le
confiere eficiencia a las construcciones en cuanto al control del hardware del
robot y la programacion convencional.Aunque la instalacion es un poco dis-
pendiosa, existen muchas ayudas para completarla. Es una de las plataformas
mas robustas y mas usadas para programacion de robots LEGO. Valoracion:
10.
• Maquina estandar de LEGO : Las actualizaciones son realizadas eventual-
mente y entregadas directamente por LEGO Group. Para programar utili-
zando esta maquina virtual se requiere un largo estudio de su arquitectura,
las instrucciones y de la generacion del codigo de bytes. Valoracion: 1.
• NQC : Al actuar como una interfaz de alto nivel con la maquina virtual
de LEGO, la programacion resulta mucho mas manejable que el lenguaje
ensamblador de la maquina virtual. Sin embargo, las construcciones hechas
49
en NQC, conllevan las limitaciones de su sintaxis; lo cual se convertirıa en
un factor limitante para la implementacion. Valoracion: 4.
Restricciones Legales:
• Tanto LEJOS como BrickOS y NQC se han trabajado como proyectos
GNU/Linux. El firmware estandar de LEGO es propiedad de Lego Group,
sin embargo su uso no esta limitado. Valoracion: 10.
Compatibilidad:
• LEJOS : Es multiplataforma (Linux, Windows, MacOS entre otros). Su ins-
talacion puede resultar compleja. Valoracion: 7.
• BrickOS : Es multiplataforma (Linux, Windows, entre otros) y adicional-
mente es compatible con otras soluciones para programacion de RCX como
se describe los cuadros 4.2 y 4.3. Su instalacion puede resultar compleja.
Valoracion: 8.
• Maquina estandar de LEGO : Es multiplataforma. Valoracion: 7.
• NQC : Es multiplataforma (Linux, Windows, Mac, entre otros), su instalacion
es relativamente sencilla. Valoracion: 8.
Teniendo en cuenta el total para las valoraciones asignadas a las diferentes alternati-
vas de implementacion; la alternativa seleccionada para implementacion de la maquina
virtual es el Sistema operativo BrickOS(legOS) y el lenguaje de programa-
cion C . Esta plataforma es realmente estable, funciona como proyecto alrededor de
una comunidad GNU por lo cual facilita la busqueda de informacion y ayuda en las
tareas de configuracion, acople y desarrollo; es multiplataforma de modo que confiere
portabilidad a la solucion de la maquina virtual y permite controlar eficientemente el
hardware de los robots. El uso del lenguaje de programacion C confiere eficiencia a
la implementacion, admite programacion estructurada y cuenta con la funcionalidad
necesaria para realizar la implementacion de la maquina virtual.
3.2. Maquina Abstracta
A continuacion se define la maquina abstracta del calculo NTCC [Val03] para progra-
macion concurrente de robots LEGO. Se presenta la especificacion formal, la sintaxis, la
50
definicion de estados inicial y final, las reglas de reduccion y el diagrama de transiciones
que muestra el funcionamiento de la maquina abstracta.
3.2.1. Especificacion formal
La Maquina Abstracta LMAN se define formalmente como sigue a continuacion:
3.2.1.1. Procesos
Un proceso en LMAN esta conformado por una tupla < P,B > donde P es un proceso
y B es una funcion que contiene todas las variables que puede alcanzar el proceso, siendo
B el ambiente, o asociacion de localidades a variables: B : LOC− > V AR.
3.2.1.2. Store
El Store(S) se define como una conjuncion de todas las restricciones iniciales mas las
adicionadas al Store en el instante actual.
S : c1 ∧ c2 ∧ c2 ∧ ................. ∧ cn
3.2.1.3. Colas de ejecucion
Las colas representan procesos concurrentes de la forma:
P1||P2||P3||.......||Pn
Se define una cola C como una concatenacion de procesos de la forma < P,B >:
C : < P1, B1 > || < P2, B2 > || < P3, B3 > ||.......|| < Pn, Bn >
La representacion de una cola vacıa es ∅.
La notacion C ::< P, B > representa una cola cuyo primer elemento es < P, B > y
cuyo residuo de elementos es la cola C.
51
3.2.1.4. Estructura de LMAN
La estructura de la maquina esta dada por:
<<< P,B >, CL, CA, CU >, CC, S >
Donde:
P : es el proceso en ejecucion.
B: es el conjunto de variables asociadas al proceso P.
CL: Es la cola de procesos listos a ejecutar.
CA: Es la cola de procesos ask suspendidos por falta de informacion en el Store.
CU : Es la cola de procesos unless.
CC: Es la cola de construccion, donde se almacenan los procesos residuales del
instante actual, que seran ejecutados en el siguiente o siguientes instantes de
tiempo.
S: Es el Store comun, donde se almacenan las restricciones asociadas al instante
en ejecucion.
La tupla mas a la izquierda (< P ; B >) define un proceso en la maquina; la siguiente
estructura (<< P ; B >; Cl; CA; CU >) define la maquina que se esta ejecutando en
el instante actual y la tupla mas a la derecha (<<< P ; B >; Cl; CA; CU >; CC; S >)
define la estructura utilizada para construir la maquina en el siguiente instante. El Store
se trata como una estructura global a la definicion de la maquina.
En LMAN se maneja la nocion de “planeacion de maquinas”. Esta nocion implica
que se construye una sola maquina por instante de tiempo; es decir que al final de cada
instante se destruye tanto la maquina actual como el Store. La maquina para el proximo
instante se construye a partir de la cola CC, donde se encuentran todos los procesos
residuales de la actual unidad de tiempo.
52
3.2.2. Sintaxis
Los procesos que implementa la maquina son esencialmente los expresados en la sintaxis
de NTCC. La unica diferencia esta realmente en el proceso de ejecucion eventual (∗P ),
que se delimita por eficiencia en la implementacion en un rango dado. La maquina
considera solamente procesos primitivos del calculo (la excepcion es nextn P ), pero no
las construcciones derivadas que se mencionan en [Val03](pagina 31). El cuadro 3.3
muestra la sintaxis de los procesos validos en LMAN .
P, Q, ... = skip Inactividad|tell(c) tell c
|∑
i∈I when (ci) doPi Seleccione un Pi, si ci, i ∈ I|P ||Q Ejecucion en paralelo
|Local x in P Localidad|next P Ejecute P en la siguiente unidad de tiempo|nextn P Ejecute P en la n−−esimaunidad de tiempo
|unless (c) next P A menos que deduzca c, ejecute next P|!P Replicacion
| ? [i, j]P Retardo infinito pero no limitado de P
Cuadro 3.3: Sintaxis de LMAN
Donde: c, d, ... denotan las restricciones. P, Q,A, ... representan los procesos del calculo.
x, y, .. se utilizan para hacer referencia a las variables de los procesos.
El proceso nextn P representa una abreviacion del proceso (next(next(...(nextP )...))),
con n ocurrencias de next.
El proceso ?[i, j]P modela eventualidad limitada en un intervalo entre i y j, donde j
es mayor que i, de modo que, P se ejecuta en una unidad de tiempo eventual en este
intervalo.
La equivalencia los anteriores dos procesos con los procesos primitivos se encuentra en
[Val03].
3.2.3. Estado inicial y Final
El estado inicial de la maquina esta dado por la siguiente configuracion:
53
<<< skip, B >, CL, ∅, ∅ >, ∅, S >
Donde:
S es el Store inicial, B contiene todas las variables globales de la maquina y
CL contiene todos los procesos a ejecutar. Las variables globales son visibles y
modificables por todos los procesos de la maquina actual.
El calculo NTCC modela sistemas reactivos, los cuales pueden permanecer inac-
tivos por grandes periodos de tiempo y luego pueden volver a activarse. Ası si-
guiendo esta nocion, no se define un estado final para la maquina. Solo detiene su
computacion a menos que exista un fallo funcional o un bloqueo por inconsisten-
cias en el Store.
3.2.4. Semantica Operacional: Reglas de Reduccion
Las reglas de reduccion de la maquina estan basadas en la semantica operacional del
calculo NTCC; apoyandose en la siguiente definicion de ESTADO y la relacion →:
ESTADO : P x B x CL x CAx CU x CC x S
→:⊆ ESTADO x ESTADO
La regla SCHED se encarga de la planeacion de los procesos que se encuentran en la
maquina. Se divide en tres casos. El primer caso es cuando un proceso llega a su final
(skip), por lo cual se continua con el siguiente en la cola CL. El segundo caso es cuando
la cola CL se encuentra vacıa; entonces se procede a ejecutar los procesos de la cola CU .
La tercera regla determina el paso a la siguiente unidad de tiempo y la construccion de
una nueva maquina; esto sucede solo si las colas CL y CU se encuentran vacıas; lo que
quiere decir, que no hay procesos que se puedan reducir. Adicionalmente, se destruye
el Store anterior(S) y se crea el nuevo Store(S ′) el cual contiene solamente el estado
inicial del ambiente.
SCHED1 :
<<< skip, B >,CL ::< P, B′ >,CA, CU >, CC, S >→<<< P,B′ >,CL,CA,CU >,CC, S >
54
SCHED2 :
<<< skip, B >, ∅, CA,CU ::< P, B′ >>, CC, S >→<<< P,B′ >, ∅, CA,CU >,CC, S >
SCHED3 :
<<< skip, B >, ∅, CA, ∅ >,CC, S >→<<< skip, B′ >,CC, ∅, ∅ >, ∅, S′ >
La regla TELL necesita del sistema de restricciones para agregar la restriccion c al
Store, en la unidad de tiempo actual.
TELL :
<<< tell(c), B >,CL,CA, CU >, CC, S >→<<< skip, B >,CL, CA,CU > CC, S ∧ c >
La regla ASK presenta los siguientes cuatro casos. El primer caso (ASK1), es para
la informacion positiva; esto quiere decir, que el ask da una respuesta afirmativa de
acuerdo con la restriccion c. El segundo caso (ASK2,1), sucede cuando el Store deduce
lo contrario de uno de los ask de la sumatoria que le ha sido preguntado (¬c ), entonces
elimina ese proceso particular de la sumatoria. El tercer caso (ASK2,2) es cuando
no hay mas procesos ask en la sumatoria, entonces se elimina el proceso∑
de la
cola CL. Y finalmente, el cuarto caso (ASK3), se presenta cuando el Store no puede
deducir ninguna de las opciones anteriores por ausencia de informacion, por lo tanto,
se suspende el procesos∑
en la cola CA.
ASK1 :
S |= cj ∧ j ∈ K
<<<∑
k∈K ask ck do Pk, B >,CL,CA, CU >, CC, S >→<<< Pj , B >,CL,CA, CU >, CC, S >
ASK2,1 :
S|=¬cj∧j∈K
<<<∑
k∈K ask ck do Pk,B>,CL,CA,CU>,CC,S>→<<<∑
k∈K−{j} ask ck do Pk,B>,CL,CA,CU>,CC,S>
ASK2,2 :
K = ∅<<<
∑j∈K ask ck do Pk, B >,CL,CA, CU >, CC, S >→<<< skip, B >,CL, CA,CU >,CC, S >
55
ASK3 :
K 6=∅∧¬∃j∈k.(S|=cj∨S|=¬cj)
<<<∑
k∈K ask ck do Pk,B>,CL,CA,CU>,CC,S>→<<<skip,B>,CL,<∑
k∈K ask ck do Pk,B>::CA,CU>,CC,S>
La regla UNLESS presenta tres casos. El primer caso es cuando hay todavıa procesos
en la cola CL, por lo cual se pospone la ejecucion del proceso unless adicionandolo a
la cola CU . El segundo activa el unless solo si, CL se encuentra vacıa y la guarda no se
deduce. Finalmente, el tercer caso considera la no activacion del proceso unless debido
a que se cumple la guarda(c).
UNLESS1 :
CL6={}<<<unless c do next P,B>,CL,CA,CU>,CC,S>→<<<skip,B>,CL,CA,<unless c do next P,B>::CU>,CC,S>
UNLESS2 :
S 2 c
<<< unless c do next P >, B, ∅, CA,CU >,CC, S >→<<< next P,B >, ∅, CA,CU >,CC, S >
UNLESS3 :
S |= c
<<< unless c do next P,B >, ∅, CA,CU >,CC, S >→<<< skip, B >, ∅, CA,CU >,CC, S >
La regla LOC permite crear variables locales al proceso P , de modo que la nueva
variable solamente pueda ser vista por P ; para esto se selecciona una nueva etiqueta L
del universo de posibles etiquetas Uloc que haya sido utilizada en el rango de localidades
(ran(B)).
LOC :
L ∈ Uloc − ran(B)<<< local x in P, B >,CL,CA,CU >, CC, S >→<<< P,B + (L←|x) >,CL,CA,CU >, CC, S >
La regla NEXT1 ejecuta el proceso en el siguiente instante de tiempo, por lo cual se
adiciona a la cola CC.
NEXT1 :
<<< next P,B >,CL,CA, CU >, CC, S >→<<< skip, B >,CL, CA,CU >,< P, B >:: CC,S >
56
La segunda regla de NEXT2 sirve para manejar la abreviacion de nextn, que se denota
(next(next......(nextP ))), n veces.
NEXT2 :
n > 1<<< nextn P,B >, CL,CA, CU >, CC, S >→<<< skip, B >,CL, CA,CU >,< nextn−1 P,B >:: CC,S >
La regla PAR ejecuta Q y adiciona P a la cola CL para su futura ejecucion.
PAR :
<<< (P |Q), B >,CL,CA, CU >, CC, S >→<<< Q,B >, < P,B >:: CL,CA, CU >, CC, S >
La regla REP ejecuta el proceso P y crea una “copia” que es adicionada a la cola CC
para ejecucion en los siguientes instantes.
REP :
<<<!P,B >, CL,CA, CU >, CC, S >→<<< P,B >, CL,CA, CU >, <!P,B >:: CC,S >
Por ultimo la regla STAR permite modelar una espera aleatoria finita de un evento,
escogiendo una unidad de tiempo entre i y j para activar P .
STAR :
n ∈ i..j
<<< ?[i, j]P,B >, CL,CA, CU >, CC, S >→<<< skip, B >,CL, CA,CU >,< nextnP,B >:: CC,S >
Las siguientes propiedades pretenden expresar la relacion entre la definicion formal de
la maquina abstracta y el calculo NTCC:
3.2.4.1. Conjetura 1: Correctitud de Transiciones No Observables
Sea P un proceso NTCC y d un Store. Entonces en NTCC
< P, d >→∗< Q, d′ >
si y solo si
<< skip, ∅, << P, var(P ) >, ∅, ∅ >, ∅, d >→∗<< skip,B,<< Q,B′ >>, CA, CU >,CC, d′ >
57
3.2.4.2. Conjetura 2: Correctitud de Transiciones Observables
Sean R y P procesos de NTCC. Entonces:
P ⇒(c,d) R
si y solo si
<< skip, ∅, << P, var(P ) >, ∅, ∅ >, ∅, c >⇒(c,d)<< skip,B, ∅, CA, ∅ >,<< R, B′ >>, d′ >
Donde:
V ar(p) es la asociacion de localidades con las variables libres de P
⇒(c,d) representa en la maquina, la transicion por medio de multiples reducciones
entre el inicio de una unidad de tiempo con Store c y el final de la misma con
Store d.
Es importante mencionar que la regla expresada en la Conjetura 2, es quien define
el input-output behavior de la maquina con respecto a NTCC y el ambiente. El
proceso que comienza en la unidad de tiempo actual P se representa como el unico
proceso que contiene la cola de listos (CL), tal como se define en la regla SCHED1;
despues de presentar multiples transiciones no observables (Conjetura 1) llega a la
regla SCHED3, dando como resultado un Store final d, que contiene las instrucciones
para a ejecutar por el ambiente y el proceso residual R en la cola de construccion CC
para ejecucion en instantes posteriores. De esta manera, todos los instantes en la maqui-
na pueden ser modelados siguiendo el anterior comportamiento; lo cual resulta similar
al comportamiento que presenta NTCC en su definicion de input-output behavior
[Val03].
3.2.5. Diagrama de Transicion
En la figura 3.2, se muestra el diagrama de transicion de la maquina abstracta, el cual
se construye con base en las reglas de reduccion descritas anteriormente.
El comportamiento del diagrama de transicion es el siguiente:
1. Cuando el proceso en ejecucion llega a skip, se pasa el siguiente proceso de la cola
CL para ejecucion(regla SCHED1).
58
Figura 3.2: Diagrama de Transicion LMAN
2. Si se encuentra un proceso next P o nextn P en ejecucion se pasa a la cola
CC(regla NEXT1 y NEXT2).
3. Si el proceso en ejecucion es replicacion (!), se deja P y se pasa !P a CC(regla
REP ).
4. Cuando el proceso en ejecucion es when y no se puede resolver por falta de
informacion en el Store, se encola en CA(regla ASK3).
5. Cuando el proceso en ejecucion es un unless y la cola CL no esta vacıa, el proceso
se encola en CU(regla UNL1).
6. Si el proceso en ejecucion es un tell, los procesos suspendidos en CA se adicionan
a la cola CL(regla TELL).
7. Si la cola CL se encuentra vacıa, se pasan a ejecucion los procesos en CU(regla
SCHED2).
8. Cuando CL y CU se encuentren vacıas, se crea una nueva maquina y se transfiere
el contenido de CC a CL en la nueva maquina(regla SCHED3).
59
Se observa que el ciclo de transiciones esta determinado por las tres reglas SCHED,
que definen la forma en que se mueven los procesos en las colas: primero deben eje-
cutarse todos los procesos en la cola CL(SCHED1), luego los procesos en la cola
CU(SCHED2) y por ultimo cuando las dos colas anteriores se encuentran vacıas, se
construye a partir de los procesos residuales en CC(SCHED3), la nueva maquina para
el siguiente instante de tiempo.
60
4 LMAN: MAQUINA VIRTUAL
En este capıtulo se describe la arquitectura e implementacion de la maquina virtual de
NTCC para programacion concurrente de robots LEGO. El objetivo principal es disenar
una maquina eficiente, modular y que provea la funcionalidad basica para programacion
concurrente, particularmente sobre robots LEGO. El modelo formal presentado en el
capıtulo anterior provee la especificacion para la maquina virtual.
Es importante notar, que en LMAN se modela ademas de la programacion concurrente,
la programacion temporal (al definir instantes de tiempo para ejecucion), y la pro-
gramacion por restricciones con el uso de un Sistema de Restricciones para gestionar
el almacenamiento de la informacion. Todos estos componentes han sido integrados en
LMAN, de modo que es posible aplicarlos para programar dispositivos roboticos LEGO.
A continuacion se presentan los aspectos de diseno e implementacion de la maquina
virtual.
4.1. Arquitectura General
La maquina virtual de LMAN consta de cuatro bloques funcionales: memoria de
programa, interfaz LEGO, interfaz STORE y controlLMAN , interactuando
tal como se muestra en la figura 4.1.
La memoria de programa guarda las instrucciones del programa en codigo de bytes
y es estatica, es decir, que no es modificable en tiempo de ejecucion. La interfaz
STORE es el modulo que permite interactuar con el Sistema de Restricciones asociado
a LMAN. Este bloque funcional crea el Store donde se almacenan las restricciones
durante el instante actual y luego lo destruye al final del mismo. La interfaz LEGO
es el bloque encargado de manejar el ambiente externo.
61
Figura 4.1: Bloques Funcionales de LMAN
ControlLMAN, actua como el cerebro ejecutor de la maquina virtual. Este bloque
es el encargado de planear maquinas y procesos, de ejecutar el programa almacenado
en la memoria de programa, de comunicarse con la Interfaz STORE por medio de
operaciones ask y tell, de comunicarse con la Interfaz LEGO para sensar el ambiente
y ejecutar instrucciones sobre el robot y, finalmente, es el encargado de construir el
siguiente instante, asegurando siempre continuidad en la ejecucion, a menos de que
exista un bloqueo en el Store.
Como se ha mencionado anteriormente, LMAN a diferencia de otras implementaciones
de maquinas para calculos de procesos [AB98, Lop99], introduce la nocion de Planeacion
de Maquinas. Esta nocion hace referencia a que solo debe existir una y solo una maquina
activa por instante de tiempo; esto se representa en la figura 4.1 como una lınea punteada
rodeando la maquina activa en el instante actual. De esta manera, aunque se define
una cola de maquinas al interior del control, siempre existira una y solo una maquina
activa por instante de tiempo. La Planeacion de Procesos en LMAN hace referencia al
62
manejo de colas y registros que permiten ejecutar cada una de las instrucciones LMAN
equivalentes a un proceso en NTCC.
Para cada maquina en LMAN se definen tres registros y tres colas de procesos: PCN
es el registro contador de programa, PAN es el registro utilizado para construir arboles
sintacticos de restricciones y PAUX es el registro auxiliar. Respecto a las colas, CL
almacena los procesos listos para ejecucion, CA almacena los procesos ask suspendidos
y CU almacenan los procesos unless que se ejecutan solo al final de cada instante. La
cola CC se define externamente a la maquina activa, ya que almacena los procesos
residuales del instante actual, que pasaran a ejecucion en los siguientes instantes de
tiempo.
LMAN ha sido disenada en bloques funcionales de modo que se confiera modularidad
a la implementacion. El codigo ha sido escrito en C por eficiencia, y sigue la estructura
de un kernel de sistema operativo para efectividad en la ubicacion de los archivos re-
lacionados en la implementacion. Inicialmente, LMAN pretendıa ser ejecutada desde el
robot LEGO, siendo almacenada en los 10K o 14K de memoria RAM destinada para
el bloque del programa LEGO. Sin embargo, debido a que LMAN integra la implemen-
tacion de un Sistema de Restricciones parametrico inicialmente creado para el calculo
PiCO [CG01], el tamano de la implementacion excedio el tamano del espacio dispo-
nible. Por lo tanto, para suplir este inconveniente en la implementacion, se diseno un
ambiente de ejecucion particular para LMAN.
En este ambiente de ejecucion, LMAN y el Sistema de Restricciones asociado corren
sobre una estacion de trabajo, donde LMAN se comunica con el LEGO vıa protocolo
LNP(Lego Network Protocol). En el LEGO por su parte, se ejecuta un segundo com-
ponente de LMAN que realiza dos funciones: en primer lugar, se encarga de sensar el
ambiente del robot y enviarlo a la maquina y en segundo lugar, se encarga de recibir el
resultado de la computacion y de ejecutarlo sobre el robot LEGO, exhibiendo las tareas
programadas.
Cada uno de los componentes de la arquitectura de la maquina virtual anteriormente
mencionados y su funcionamiento, seran tratados en detalle en las siguientes secciones
de este capıtulo.
63
4.1.1. Memoria de Programa
La memoria de programa es una memoria estatica, es decir que no es modificable en
tiempo de ejecucion. Su funcion es almacenar el codigo del programa expresado en
codigo de bytes, por lo cual se implementa como un arreglo en memoria fısica.
En el modelo de memoria de LMAN, no se utiliza una memoria dinamica o de traduccion
para el manejo de variables. Tomando ventaja de la definicion de recursion que confiere
el calculo NTCC, en donde la recursion es reemplazada por replicacion “ !”, por lo cual
cada llamado recursivo se extiende al siguiente instante de tiempo, y tambien buscando
eficiencia en el desempeno de la maquina; se delega la tarea del manejo de variables,
particularmente de la generacion de nuevas variables y sus alcances o ligaduras, al
compilador.
A continuacion se describen cada uno de los aspectos relacionados con la memoria del
programa y su implementacion.
4.1.1.1. Estructura de Datos
La estructura de datos que representa la memoria del programa en LMAN sigue a
continuacion:
#define MAX_ARCH 1500
//memoria del programa
char fp[MAX_ARCH];
4.1.1.2. Formato de Instrucciones
El cuadro 4.1 describe el formato de instrucciones utilizado en el codigo de bytes de
LMAN. Para fines de optimizacion se eligio un formato fijo de longitud 24 bytes, que
admite 64 instrucciones de maquina y direccionar maximo 8192 lıneas de codigo. Se
manejan ademas de un opcode, dos fuentes en la definicion de las instrucciones.
64
Opcode src1 src2
6 13 5
Cuadro 4.1: Formato de Instrucciones de LMAN
4.1.1.3. Conjunto de Instrucciones
La figura 4.2 describe el conjunto de instrucciones, opcode, src1 y src2 de LMAN. En el
cuadro 4.3 se encuentran las especificaciones dadas para los campos fuentes Src1 y Src2.
Observese que cada una de estas instrucciones corresponde a los procesos definidos en
la semantica de NTCC. El uso de las instrucciones de LMAN se trata en detalle en el
anexo A sobre Traduccion de procesos NTCC a codigo de bytes de LMAN.
4.1.2. Interfaz STORE
Con el fin de lograr que el Sistema de Restricciones asociado a LMAN se adicione pa-
rametricamente, las restricciones son definidas como formulas–de–primer–orden (fpo).
Una fpo es una expresion construida a partir de formulas atomicas combinadas con
conectores logicos not, and, or, y cuantificadores ∃, ∀; los atomos basicamente tienen la
construccion de ecuaciones o inecuaciones matematicas. Ejemplos: (x+y > 6)∧(z = 1),
x = 2 , entre otras.
Teniendo en cuenta la definicion anterior, cualquier Sistema de Restricciones que pueda
expresar sus restricciones como fpo, puede ser integrado a LMAN. En la actual imple-
mentacion ha sido acoplado el Sistema de Restricciones optimizado para el Lenguaje
CORDIAL[CG01] y la Maquina MAPICO [AB98]. LMAN usa la sintaxis que se muestra
en la figura 4.4 para la especificacion de fpo[McA92]; esta se toma de la definicion usada
por MAPICO[AB98] en su adicion del Sistema de Restricciones ya mencionado[CG01].
Este sistema de restricciones de dominios finitos[CG01] usado en LMAN, contiene el
sistema de restricciones aritmetico–modular propuesto para NTCC.∑
esta dado por
>, <, ≤, ≥ . +, −, ∗, /, =, <>. Es parametrico como ya se ha mencionado anterior-
mente; de modo que, utiliza fpo como entradas representadas en estructuras de arbol.
Se basa en el modelo de Bjorn Carlson [Car95], ası que utiliza la nocion de indexicals y
algoritmos de arco-consistencia en su implementacion. Por eficiencia, fue implementan-
do en lenguaje C, registrandose tiempos de ejecucion aceptables para diversos problemas
65
Figura 4.2: Conjunto de Instrucciones de LMAN
66
Figura 4.3: Especificacion de Fuentes Src1 y Src2
en el dominio de concurrencia.
Para el acople del sistema de restricciones con LMAN, se realizaron algunas modifica-
ciones. Estas se describen a continuacion:
Para asegurar equivalencia entre las estructuras para representar restricciones
usadas en el sistema de restricciones y en LMAN, se modifico la implementacion
de arboles con encadenamiento sencillo, por arboles con encadenamiento al padre.
El doble puntero se hizo necesario para asegurar consistencia en el arbol cuando
se construye la restriccion a partir del codigo de bytes de LMAN.
Al final de cada instante de tiempo, se hace necesario realizar una consulta al
Store (Browse) acerca de las variables de ambiente. El resultado de esta consulta
es enviando al LEGO para ejecucion. De esta manera, se adiciono al sistema de
restricciones una funcion que consulta el estado de las variables; particularmente
en LMAN se consultan solamente las variables del ambiente. Si la variable tiene
un valor fijo, se envıa ese valor; de lo contrario, si la variable tiene asociado un
rango, se realiza un seleccion aleatoria de un valor en el rango.
El valor de n para el sistema de restricciones se redefinio en 500 (aritmetica–
modulo 501). De esta manera, es posible asignar rangos de 0 a 500.
En el acople del sistema de Restricciones con LMAN, se implementaron arboles
binarios; es decir, que los predicados y funciones deben definirse de aridad 2. No
obstante, la sintaxis de formulas bien formadas usada para expresar restricciones
67
en LMAN admite la definicion de aridad n, de manera que serıa posible extender
su uso.
Figura 4.4: Sintaxis para la especificacion de Formulas de Primer Orden en LMAN
4.1.2.1. Estructura de Datos
La estructura de datos que representa la interfaz con el STORE se muestra a continua-
cion:
typedef struct InterfazSTORE{
Store s;
Indexicals i;
Stamp st;
int indextemp;
}InterfazSTORE;
68
4.1.2.2. Instrucciones asociadas al Sistema de Restricciones de LMAN
Las instrucciones para construir fpo en LMAN se describen en la figura 4.5.
Figura 4.5: Instrucciones para construccion de restricciones en LMAN
Los posibles valores que se definen para funciones y predicados se describen a continua-
cion. El sistema de restricciones actualmente usado por LMAN, no modela conectores
logicos, ni rangos, ni cuantificadores.
Funciones: ADD, SUBS, MULT, DIV, MOD.
Pred: IGUAL, DIF, MAY, MAI(mayor o igual), MEN, MEI(menor o igual).
4.1.2.3. Construccion de Restricciones en LMAN
A partir de las instrucciones presentadas en la figura 4.5, se construyen las restricciones
en LMAN. La siguiente restriccion, se expresa en LMAN como un arbol binario de
notacion infija (ver figura 4.6).
69
( y + 2) = (x ? 4) – (z ÷ 6)
Figura 4.6: Arbol binario infijo que representa una restriccion en LMAN
Del arbol de la figura 4.6, que contiene una restriccion expresada como formula–de–
primer–orden se construye la restriccion que recibira el Sistema de Restricciones usado
por LMAN. Teniendo en cuenta las instrucciones descritas en la figura 4.5 y asumiendo
que la variable “x” tiene la etiqueta 74, “y” la etiqueta 75 y “z” la etiqueta 76; el codigo
necesario para construir la restriccion es el siguiente:
1 ATOM IGUAL 2 // =
2 TERMF ADD 2 // +
3 TERMV 75 0 // y
4 TERMC 2 0 // 2
5 TERMF SUBS 2 // -
6 TERMF MULT 2 // *
7 TERMV 74 0 // x
8 TERMC 4 0 // 4
9 TERMF DIV 2 // /
10 TERMV 76 0 // z
11 TERMC 6 0 // 6
Del anterior bloque de codigo, se aprecia como la restriccion se construye siguiendo
una notacion infija donde primero se describe el operador y luego los terminos varia-
70
bles o constantes asociados a la operacion. En el Sistema de Restricciones actual las
restricciones se construyen como arboles binarios, luego la aridad aceptada es 2. ( ari
= 2).YA que LMAN acepta cualquier Sistema de Restricciones parametrico; la sintaxis
de restricciones requiere que la aridad se haga explicita como un parametro. (Ver figura
4.5).
4.1.3. Interfaz LEGOS
Un RCX es un microcontrolador programable basado en LEGO brick con un Hitachi
H8/300 como corazon y 32K en memoria RAM. Este puede operar simultaneamente
tres actuadores, tres sensores y un sistema IR; adicionalmente, con el RCX se inclu-
ye una baterıa y diferentes piezas intercambiables para crear variedad de dispositivos
roboticos autonomos. Es posible programar RCX en alto nivel utilizando combinaciones
de firmwares como legOS, lejOS, Lego MindStorm firmware junto con lenguajes como
C, Java, NQC, entre otros.
El modulo de la interfaz LEGOS es el encargado de la interaccion con el ambiente, en
otras palabras, es el encargado de controlar las variables asociadas al RCX. En LMAN el
ambiente se define como una estructura que permite controlar los motores, los sensores,
el sonido y la baterıa; definiendo para cada uno de estos componentes los atributos
necesarios para modelar adecuadamente el comportamiento del robot. La figura 4.7
ilustra la estructura usada para modelar el ambiente y para construir el paquete de
datos que se transmite entre el computador y el RCX. Notese que este modulo permite
programar el doble de dispositivos de un RCX convencional, con el fin de admitir
expansiones sobre los RCX o para modelar sistemas colaborativos entre RCX.
Figura 4.7: Ambiente LEGO en LMAN
Al finalizar esta seccion que define la interfaz LEGOS, se presenta una breve descripcion
de los dispositivos LEGOS y sus capacidades.
71
4.1.3.1. Estructura de Datos
Las estructuras de datos utilizadas para modelar el ambiente LEGO se definen a con-
tinuacion:
//entrada define el estado y el valor
typedef struct {
char est;
char val;
}entrada;
//sensor define el tipo, estado y el valor de los sensores
typedef struct {
char tipo;
char est;
char val;
}sensor;
//soundl define el estado, la nota y la duracion de los controladores de sonido
typedef struct {
char est;
char nt;
char dur;
}soundl;
//se modela el ambiente LEGO
typedef struct {
//definicion de motores
entrada mot[7];
//definicion de sensores de movimiento
sensor sen[7];
//definicion de bateria
entrada bat[3];
//definicion para manejo de musica
soundl snd[3];
72
}ambiente;
4.1.3.2. Ambiente LEGO
En LMAN las variables son representadas por etiquetas numericas unicas, que comien-
zan desde 1 y van incrementandose de uno en uno. Para modelar la interaccion de
LMAN con el ambiente, se reservan unas etiquetas fijas destinadas para definir varia-
bles de entrada, las cuales informan sobre como se encuentra el ambiente y variables
de salida, que contienen la informacion de que va a ser ejecutado sobre el LEGO.
Se debe de tener en cuenta, que para dar escalabilidad a la implementacion de LMAN,
se habilitaron el doble de dispositivos de un RCX convencional. Es decir, que LMAN
permite trabajar con 6 sensores, 6 motores, 2 baterıas y 2 manejadores de sonido. El
LCD o display que permite visualizar mensajes en el LEGO no fue modelado, ya
que el Sistema de Restricciones no incluye la posibilidad del manejo de cadenas. No
obstante, el LCD se utiliza para visualizar mensajes de depuracion durante la ejecucion
de programas.
A continuacion se describe en detalle el uso de variables que hace LMAN. La notacion
utilizada para las variables es mayuscula, ya que se definen como constantes en la
maquina virtual.
4.1.3.2.1. Variables de Entrada .
Las variables de entrada comienzan en la etiqueta 1 y van hasta 34, estas se encuentran
divididas de la siguiente forma:
Motores: Cada uno de los 6 Motores, contiene 2 variables para indicar los atributos
a continuacion. El total de variables de Motores es 12.
Estado: Indica si esta encendido el motor y en que direccion se desplazara.
Los valores posibles: 0 Apagado, 1 Adelante, 2 Atras, 3 Frenar.
Ejemplo: IMOTEST1 = 1, indica que el motor 1 tiene estado Adelante.
Valor: Indica la velocidad que tiene el motor. Valores: 0 a 255.
Ejemplo: IMOTSP1=80 indica que la velocidad del motor 1 se configura en
73
80.
Sensores: Cada uno de los 6 Sensores contiene 2 variables para indicar los atributos
a continuacion. El total de variables definidas para los sensores es 12.
Tipo: Indica el tipo de sensor que se utiliza: 1 tacto, 2 luz, 3 rotacion, 4
temperatura; 5 y 6 se reservan en caso de que se adiciones mas sensores. Estos
valores deben asignarse a las constantes que definen los tipos de sensores en
la interfaz LEGO.
Estado: Indica si el sensor se ha habilitado o no. Valores: 1 o 0.
Ejemplo: ISENEST1=1 indica que el sensor 1 se encuentra activo.
Valor: Indica el valor del sensor, por ejemplo si el sensor es de tacto dice si
esta oprimido o no.
Ejemplo: ISENVAL1=1 para un sensor de tacto, indica que el sensor ha sido
oprimido.
Baterıas: Cada una de las 2 Baterıas contiene 2 variables para indicar los atributos a
continuacion. El total de variables definidas para baterıas es 4.
Estado: Indica si la Baterıa esta en funcionamiento o no. Valores: 1 o 0.
Ejemplo: IBATEST1=1, indica que la baterıa 1 esta en funcionamiento.
Valor: Indica le nivel de energıa de la Baterıa. Valores: 0 a 255.
Ejemplo: IBATVAL1=180, indica que la baterıa 1 tiene un nivel de energıa
de 180.
Sonido: Cada uno de los 2 controladores de Sonido contiene 3 variables para indicar
los atributos a continuacion. El total de variables asociadas a los controladores de
sonido es 6.
Estado: Indica si esta en funcionamiento el controlador de Sonido o no.
Valores: 1 o 0.
Ejemplo: ISNDEST2=1, idica que el estado del controlador 2es activo.
Nota: Indica la Nota y la escala de la misma. Valores: 0 a 255.
Ejemplo: ISNDNT2=55, representa la nota LA en escala 5 para el controla-
dor 2.
74
Duracion: Variable opcional para delimitar el tiempo de duracion de la nota.
Valores: 0 a 255.
Ejemplo: ISNDDUR2=2, representa duracion de una octava para una nota
ya definida en el controlador 2.
4.1.3.2.2. Variables de Salida .
El manejo de las variables de salida es similar a las variables de entrada, con la diferencia
que inician en la etiqueta 35 y terminan en la etiqueta 68. Para el caso de las constantes
que definen las etiquetas, solo se hace el cambio de la letra inicial I (INPUT) por la O
(OUTPUT).
Ejemplo:
Variable de Entrada: ISNDDUR1
Variable de Salida: ONDDUR1
4.1.3.2.3. Variables de Usuario .
A partir de la etiqueta 69 inician las variables que pueden usar los programas de usuario.
4.1.3.3. Protocolo de comunicaciones
LMAN utiliza en su funcionamiento el protocolo LNP (Lego Network Protocol) del
Sistema Operativo LegOS. Este protocolo posibilita la comunicacion entre varios RCX
y varias estaciones de trabajo. Existe sobre los lenguajes C, Java y Python. Actua como
un protocolo UDP (User Datagram Protocol), por lo cual no realiza acuso de recibo o
chequeos de integridad en la recepcion de paquetes.
LNP es usado en la implementacion de LMAN, para suplir el inconveniente de tamano
en memoria, por el cual se imposibilitaba la ejecucion de la maquina desde el mis-
mo dispositivo LEGO. Consecuentemente, se hizo necesario implementar un protocolo
de entrega y recepcion de datos que usa LNP para el envıo, tal como se describe a
continuacion.
El protocolo modelado no es complejo, utiliza asincronıa y time-out para asegurar
entrega de datos. Una Bandera determina el tipo del enlace.
75
Protocolo del lado de la estacion de trabajo: Ver figura 4.8
1. Se envıa al LEGO, la BANDERA en estado de sensar (1).
2. La estacion de trabajo espera la respuesta con el ambiente sensado por el
RCX.
3. Si se presenta un time-out(No se recibe respuesta), se regresa al paso 1.
4. Se envıa al LEGO, la BANDERA en estado de ejecutar (2).
Figura 4.8: Protocolo del lado de la estacion de trabajo en LMAN
Protocolo del ladol RCX: Ver figura 4.9
1. El RCX espera la BANDERA.
2. Si el estado de la BANDERA es sensar (1), el RCX sensa el ambiente.
3. EL RCX envıa el ambiente sensado a la estacion de trabajo.
4. Si el estado de la BANDERA es ejecutar (2), el RCX captura el ambiente
recibido.
5. El RCX ejecuta el ambiente.
4.1.3.4. Dispositivos Roboticos LEGO
El RCX 2.0 Robotics Command System (Ver figura 4.10) es un dispositivo brick pro-
gramable [Gro00]. Cuenta con 3 puertos de entrada para sensores, 3 puertos de salida,
76
Figura 4.9: Protocolo del lado del RCX en LMAN
cuatro botones de control, un display LCD, y un transmisor de infrarrojos. Adicional-
mente, posee un microprocesador para el procesamiento de programas, una memoria
interna para almacenar el firmware y los programas y un speaker para producir beeps
y tonos.
4.1.3.4.1. LEGO Brick .
Los puertos de sensores permiten conectar sensores de luz, tacto, rotacion y tempera-
tura. Los dos ultimos no se incluyen en el kit LEGO MindStorm. Los puertos de salida
permiten conectar motores y otros dispositivos como luces que no se incluyen en el
kit. Adicionalmente es posible conectar otros LEGO bricks. Internamente el dispositivo
cuenta con 3 sensores internos: temporizador, para mantener un rastro del tiempo; un
manejador de mensajes, que espera por mensajes enviados por otros RCX y por ultimo,
variables definidas por el usuario. Por medio de estos dispositivos, el robot puede mo-
verse y reaccionar con su ambiente.El brick requiere 6 baterıas AA/LR6 de 1.5 voltios
para su funcionamiento.
La torre IR es la encargada de establecer un enlace inhalambrico entre la estacion de
trabajo y el RCX. Por medio de la torre IR que utiliza senales infrarrojas para enviar
mensajes, se descarga el firmware y los programas a la memoria del RCX. Para descarga
la distancia sugerida entre la torre y el RCX es 10-12 cm; en condiciones optimas de
luz se puede transmitir hasta una distancia de 30 metros usando una torre USB.
77
Figura 4.10: RCX LEGO brick
4.1.3.4.2. Firmware y lenguajes de programacion .
El firmware es un software especial que posibilita la comunicacion entre una estacion de
trabajo y el RCX. Actua como el sistema operativo del RCX. En la actualidad existen
diversos metodos para programar RCX; los cuadros 4.2 y 4.3 resumen algunos de los
mas utilizados.
4.1.3.4.3. Modelos de Robots .
Las piezas intercambiables de LEGO pueden utilizarse para construir diferentes tipos
de robots, la figura 4.11 muestra algunas de las opciones mas utilizadas. EL presente
trabajo se prueba sobre un modelo Roverbot.
78
Firmware BrickOS (legOS)Autor Markus L. NogaTipo Reemplazo de FirmwareLenguajes C,C++Plataformas Desarrollado sobre x86 GNU/Linux, probado sobre PPC Linux.
Es portable en Cygwin-DJGPP sobre MSWindows y soportado en Mac.Descripcion LegOs es un sistema operativo multitarea para el RIS
(Robotics Invention System). Los programas son escritos en C,C++compilados en la estacion usando gcc-cross-compilery luego descargados al RCX para ejecucion. Incluye random, puntoflotante, hilos con semaforos, y almacenamiento multiple deprogramas. Permite recibir y enviar datos entre estaciones windows olinux. Usa la velocidad nativa del mircroprocesador (16 MHz) yutiliza LNP como protocolo de comunicacion basado en transmisor deinfrarrojo con el RCX. Es una poderosa alternativa para RCX.
Firmware Not Quite C (NQC)Autor Dave BaumTipo compilador de codigo de bytes nativoLenguajes lenguaje similar a C, llamado Not Quite C.Plataformas GNU/linux, MS Windows, y Macintosh.Descripcion NQC es un compilador de codigo de bytes que toma programas
escritos en una sintaxis similar a C y la traduce a un codigode bytes que el firmware utilizado en el LEGO pueda entender.NQC tiene limitaciones en el numero de variables dispobiblesque es 32, no existen estructuras de datos, las subrutinasno pueden retornar valores, solo pueden usarse variablesglobales y las subrutinas no admiten parametros.
Firmware Tiny VM y leJOSAutor Jose SolorzanoTipo Reemplazo de firmwareLenguajes JavaPlataformas GNU/Linux, Win32.Descripcion Tiny VM es una implementacion de la Maquina Virtual de Java
que se descarga en el RCX para sustituir el firmware estandar.Los programas para Tiny VM, pueden usar algunas librerıas javaestandar y una librerıa disponible para el control desensores y motores del LEGO. Los programas escritos en java,requieren ser compilados y luego descargados en el RCX para suejecucion. leJOS es un proyecto similar realizado por el mismoautor, que incluye adiciones como soporte de punto flotante y cadenas.
Cuadro 4.2: Alternativas de programacion de RCX
79
Firmware PylnpAutor Les SmithsonTipo Libreria de control remotoLenguajes PhytonPlataformas GNU/Linux.Descripcion Pylnp es una libreria de control remoto que a difrencia
de otras librerias, interactua con legOS y no con elfirmware estandar. Esto posibilita que el usuario puedainvocar funcionalidades legOS.
Firmware Lego::RCX.pmAutor John C. QuillanTipo Remote control libraryLenguajes PerlPlataformas GNU/Linux, MS Windows y SolarisDescripcion Lego::RCX.pm es una librerıa perl para el control remoto
de el RCX utilizando la torre IR para enviar los comandosal firmware estandar para que este, los interprete y actue.
Cuadro 4.3: Alternativas de programacion de RCX
Figura 4.11: Algunos ejemplos de modelos LEGO
80
4.1.4. ControlLMAN
Con todos los modulos anteriores dispuestos, controlLMAN es quien se encarga de
gestionar recursos, tareas y el tiempo. Cabe mencionar que el instante de tiempo definido
para LMAN no se rige por un reloj explıcito; el fin del instante lo define la ausencia de
procesos en las colas. Es decir, que el instante termina cuando tanto la cola de procesos
listos (CL) como la cola de procesos Unless(CU) se encuentran vacias.
4.1.4.1. Estructura de Datos
La estructura de Datos que modela el control se muestra a continuacion. ColaM es
la implementacion de colas de maquinas y ColaP es la implementacion de colas de
procesos. LZumatoria es la implementacion de listas de guardas, donde el TAD guarda
es utilizado para modelar la lista de ask del proceso guarded-choise en el calculo. Solo se
admite un nivel en esta estructura, es decir que no puede definirse un proceso sumatoria
dentro de otro proceso sumatoria. Las estructuras de maquinas y procesos se muestran
a continuacion:
typedef struct controlLMAN{
//cola de maquinas, se define una maquina por instante
ColaM cMaquinas;
//cola de construccion de la maquina del siguiente instante
ColaP cConstruccion;
//memoria del programa
char fp[MAX_ARCH];
//store
InterfazSTORE iStore;
}ControlLMAN;
typedef struct MAQUINA {
int PCN; //registro contador PCN de la maquina
FrameConst PAN; //registro apuntador de restricciones de la maquina
FrameConst PAUX; //registro auxiliar de la maquina
ColaP cListos; //cola de procesos listos
ColaP cAsk; //cola de procesos ask suspendidos
81
ColaP cUnless; //cola de procesos unless
} Maquina;
typedef struct PROCESO {
int PC; //registro contador del programa
FrameConst PA; //registro apuntador al arbol restricciones
FrameConst PAux; //registro auxiliar
int instante; //almacena instante actual, usado para reglas star y next
ListaG lZumatoria; //guarda la lista de when asociadas a una zumatoria
} Proceso;
typedef struct GUARDA {
int PC; //registro contador del programa
FrameConst PA; //registro apuntador arbol restricciones
char marca; //utilizada para la regla gask, ndet
} Guarda;
4.1.4.2. Gestion de ControlLMAN
La gestion que realiza el control puede resumirse en la figura 4.12. ControlLMAN es
quien regula la ejecucion de la maquina ”mientras no se presente un error”, es decir
que mientras existan reducciones que no generen bloqueos o errores en la maquina,
esta se ejecutara infinitamente. El control define un nuevo instante e inicia el estado
de ”Planeacion de Maquinas”. En este estado y para un instante diferente al inicial, el
control destruye la maquina y el Store anterior, crea la nueva maquina y Store para el
instante actual; y procede a sensar el ambiente y a comentar su resultado en el Store.
Si se trata del instante inicial, simplemente crea la maquina y el Store para comenzar
la computacion.
A continuacion llega al estado de Ejecucion, en donde ejecuta secuencialmente las ins-
trucciones almacenadas en la memoria de programa. En este estado es donde realiza la
planeacion de procesos, que involucra la ejecucion de las reglas de reduccion definidas
en la maquina abstracta, en otras palabras, ejecuta las transiciones internas. Luego que
termina la computacion de reglas, llega al estado PonerAmbiente, en donde pregunta al
82
Store por el estado final de las variables asociadas al ambiente y procede a enviar esta
informacion al LEGO para su ejecucion. Con este ultimo estado, finaliza el instante,
es decir que se produce una transicion observable y de nuevo el control inicia su ciclo
reactivo.
Figura 4.12: Gestion del controlLMAN
4.2. Funcionamiento de LMAN
LMAN requiere como plataforma de Hardware (Ver figura 4.13) los siguientes ele-
mentos:
RCX 2.0 dispuesto en un modelo de robot LEGO.
Torre USB/serial. La transmision vıa LNP ha sido probada utilizando una torre
serial.
Estacion de trabajo para la comunicacion y procesamiento de LMAN. El sistema
ha sido probado ejecutandose desde una estacion Pentium III a 930Mhz, 256KB
RAM con linux Debian Woody 3.0.
LMAN requiere como plataforma de Software (Ver figura 4.14) los siguientes ele-
mentos:
83
Figura 4.13: Requerimientos Hardware del Sistema LMAN
Sistema operativo BrickOS, ejecutando Cross Compiler gcc y H8300binutils para
controlar el microprocesador del RCX. El sistema ha sido probado para BrickOS
version 2.6.1.
Modulo de Comunicacion LNP.
Driver USB/serial.
LMAN incluyendo los modulos del Sistema de Restricciones y el Compilador aso-
ciados.
Figura 4.14: Requerimientos Software del Sistema LMAN
Sobre la estacion de trabajo se ejecutan LMAN, el Sistema de Restricciones y el Com-
pilador. El RCX debe contener BrickOS (legOS) como firmware y el componente de
LMAN disenado para sensar el ambiente y ejecutar comandos sobre el robot. Con to-
dos estos requisitos dispuestos correctamente, el flujo de datos en el sistema se realiza
tal como se muestra en la figura 4.15.
84
La entrada de datos al Sistema se produce desde el editor VINE del Lenguaje Visual
VIN o desde el editor de texto gvin configurado para chequear sintaxis NTCC. Ası, una
vez construido el programa NTCC en una de estas dos herramientas y guardado con
extension .lmn, se compila haciendo uso del Compilador NTCC-LMAN que traduce
entradas NTCC a codigo de bytes de LMAN, generando un archivo extension .out.
La maquina virtual toma como entrada el archivo generado por el compilador e ini-
cia el ciclo reactivo de computacion mientras no se produzcan fallos de comunicacion
o bloqueos en el Store. Si no es el instante inicial, el control crea la maquina y Sto-
re actuales destruyendo los anteriores, y envıa una senal al RCX (Bandera=1) para
indicarle que debe sensar. El RCX recibe la senal y captura el estado de su mundo;
empaqueta esta informacion del ambiente y la envıa hacia LMAN usando la torre IR
y el modulo LNP. LMAN entonces, comenta esta informacion al Store y con ella inicia
el procesamiento del programa y las reducciones hasta determinar el fin de la unidad
de tiempo. Cuando las colas de ejecucion y de procesos unless se encuentran vacıas, el
control consulta el estado final del Store, y procede a empaquetar esta informacion y
enviarla al RCX(Bandera=2) para ejecucion; en este momento se determina el fin de la
unidad de tiempo y de nuevo se da inicio al ciclo reactivo.
Si entre el envıo de la senal de sensar(Bandera=1) y la recepcion del paquete con la
informacion del ambiente, la maquina no recibe respuesta; se genera un time–out que
retorna al paso de envıo de senal para sensar. Si durante 5 intentos continuos la maquina
no recibe el paquete, se aborta la ejecucion.
En este momento no ha sido liberado el driver USB para legOS, por lo tanto la comu-
nicacion vıa LNP en la actual implementacion se hace utilizando una torre serial.
La figura 4.16 muestra el comportamiento reactivo que sigue LMAN. Cada unidad de
tiempo comienza con un Store Inicial Si. Durante la unidad la maquina procesa con
esta informacion como entrada y al final genera una salida que se envıa al robot para
ejecucion. Este procedimiento lo realiza infinitamente mientras no exista un bloqueo en
el Store o un fallo en la comunicacion.
85
Figura 4.15: Funcionamiento del Sistema LMAN
Figura 4.16: Comportamiento reactivo del Sistema LMAN
86
5 COMPILADOR NTCC–LMAN
Como ya se ha mencionado en capıtulos anteriores, la implementacion del Calculo
NTCC define un flujo que incluye 3 modulos: un LENGUAJE VISUAL VIN, un COM-
PILADOR NTCC-LMAN y una MAQUINA ABSTRACTA LMAN para finalmente
permitir programacion concurrente de robots LEGO MindStorm.
El modulo del COMPILADOR NTCC–LMAN, es usado para definir una interfaz de
programacion de alto nivel para el usuario. Por medio del editor gvin configurado para
chequear sintaxis NTCC; el usuario puede construir programas usando la sintaxis propia
del calculo, y posteriormente compilarlos para generar el codigo de bytes de LMAN. En
este punto, ya LMAN toma el codigo de bytes, procesa y ejecuta sobre el robot.
Adicionalmente, debido a que tanto el lenguaje visual VIN ya mencionado, como el
compilador utilizan la sintaxis basica del calculo, se hace posible integrarlos. De esta
manera, el lenguaje visual genera codigo NTCC, que el compilador interpreta y traduce
a codigo de bytes de LMAN para ejecucion. Ası con estos tres modulos dispuestos,
se completa el flujo de implementacion de NTCC que permite al usuario programar
utilizando, sea el lenguaje iconico, el editor NTCC o directamente en las intrucciones
de la maquina virtual.
A continuacion se describen las consideraciones del diseno del compilador NTCC-
LMAN; su desarrollo no esta considerado entre los alcances del actual trabajo de tesis.
La implementacion de este, fue realizada como proyecto de semestre en el curso de
compiladores en la Pontificia Universidad Javeriana–Cali por F. Rocha, J. Chala y M.
Pabon [RCP03]. De comun acuerdo con el profesor del curso se diseno el compilador,
y se motivo a los estudiantes continuamente para lograr una buena implementacion.
Al finalizar el semestre se selecciono la mejor implementacion[RCP03], se acoplo con la
implementacion de LMAN y se realizaron las pruebas pertinentes de funcionamiento y
desempeno arrojando los resultados esperados en efectividad y eficiencia.
87
5.1. Sintaxis
5.1.1. Conjunto de Caracteres
El conjunto de caracteres basico esta formado por: Letras mayusculas, minusculas,
dıgitos y caracteres especiales:
( ) [ ] ! .. = + -- /
* > < & | \# . \&\& ,
Los identificadores de las constantes deben escribirse con letras mayusculas y los de
las variables empiezan con letras minusculas y pueden seguir con letras mayusculas o
minusculas y numeros.
Debido a que LMAN interactua con el robot, es necesario definir una serie de variables
que manejan su ambiente. Estas actuan como variables globales a todo proceso en
NTCC y se definen de dos tipos: de entrada anteponiendo la letra i al listado que se
describe a continuacion, y de salida anteponiendo la letra o. Ejemplo: imot1, omot1 ...
isen1, osen1 ... ivalsnd2, ovalsnd2, entre otras.
mot1,mot2, ..., mot6. Identifican los motores del robot.
spmot1, spmot2, ..., spmot6. Identifican las velocidades de los motores.
sen1,sen2, ..., sen6. Identifican los sensores en funcionamiento.
valsen1,valsen2, ..., valsen6. Identifican el estado de los sensores.
bat1, bat2. Identifican las baterıas en funcionamiento.
valbat1, valbat2. Identifican el estado de las baterıas.
snd1, snd2. Identifican el sonido en funcionamiento.
valsnd1, valsnd2. Identifican el estado del sonido activo.
88
when do max succunless tell min prednext local in skip
Cuadro 5.1: Palabras reservadas en el Compilador NTCC-LMAN
Las palabras propias del calculo son reservadas y no pueden ser usadas como nombres
definidos por el usuario; estas se muestran en el cuadro 5.1
Las variables son de tipo entero y tienen un rango definido en los numeros enteros
positivos de 0 a n, donde n es una constante definida previamente. Para efectos de este
compilador, se tomara n = 500.
Las variables de salida no pueden tener asignaciones directas mayores a 255, esto se
debe las limitaciones de los dispositivos LEGO descritas en la seccion Interfaz LEGO
del capıtulo que describe la maquina virtual. Ejemplo: tell(omot1=289) no es valido
pues es una asignacion directa a una variable de salida mayor a 255.
Los comentarios en NTCC se efectuan con dos guiones adyacentes “ —- ” en cualquier
posicion de una lınea, y terminan con nueva lınea. Ejemplo:
-- Proceso TELL de NTCC
(tell x=5)
5.1.2. Reglas de Produccion
En la definicion de la sintaxis para el compilador se tienen las siguientes consideraciones:
<nombre> identifica el nombre de un sımbolo (terminal o no terminal)
“→” especifica una regla de produccion y “|” separa las reglas de produccion que
corresponden a un mismo sımbolo no terminal.
En una regla de produccion, los sımbolos que no estan encerrados entre” <>”
son palabras o sımbolos propios del lenguaje.
Cuando la definicion no se hace con una regla de produccion (no lleva → ), esta
corresponde a una descripcion (no formal) del sımbolo.
89
A continuacion se describe las reglas de produccion utilizadas por el compilador:
5.1.2.1. Variables y Constantes
Los identificadores no declarados se asumen como variables globales. La declaracion de
variables locales tiene la siguiente forma:
< V ar dec > → local < ID list > in| ( local < ID list > )
< ID list > lista de nombres de variables
La declaracion de constantes tiene la forma:
< Const dec > → ε| < const dec > const < ID constante > = < Lit int >
< Lit int > literal entero
< ID constante > nombre de una constante
5.1.2.2. Restricciones
El Store se define como una conjuncion logica de restricciones expresadas como formulas
de primer orden. Las reglas para expresar restricciones como formulas de primer orden
siguen a continuacion:
< Constraint > → < Expresion >
< Expresion > → < Lit expresion >| < V ar reference >|(< Expresion >)| < Expresion > < Operador > < Expresion >| < V ar reference > in < Rango >|succ(< Expresion >)|pred(< Expresion >)
< Rango > → < Constante > :: < Constante >|– (< Rango >)|min(< Rango >)|max(< Rango >)| < Rango > && < Rango >| < Constante > .. < Constante >
90
< V ar reference > → < ID variable >| < ID constante >
< Lit expresion > → < Lit int >
< Operador > son todos los operadores del cuadro 5.2.
< ID variable > nombre de una variable
< Constante > → < Lit int >| < ID constante >
Los operadores para la construccion de restricciones se definen en el cuadro 5.2. En la
definicion del rango el sımbolo “::” significa union, el sımbolo “–” significa complemento,
el sımbolo “&&” interseccion, y el sımbolo “..” representa un rango (inicio y fın).
Clase de Operador Operador
Logico & | |Negacion Not
Relacionales = |! = | < | > | ≤ | ≥Aritmeticos +| − | ∗ |/|%
Cuadro 5.2: Operadores sobre restricciones
5.1.2.3. Procesos
A continuacion se muestran las reglas que definen los procesos NTCC:
< P > → when < Constraint > do P| < P > || < P >| ∗[< Constante >, < Constante >] < P >| ! < P >| unless < Constraint > next < P >| next < Const op > < P >| (< P >)| var dec < P >| < P > + < P >| tell < Constraint >| skip
< Const op > constante opcional
91
5.1.2.4. Programa
Un programa esta formado por la declaracion de constantes y una serie de procesos:
< Programa > → < Const dec > < Procesos >< Procesos > → < P >
| < Procesos > < P >
Ejemplos de programas NTCC se muestran en el capıtulo 7 de pruebas y ejemplos.
5.2. Semantica
Los chequeos semanticos que realiza el compilador tratan las operaciones aritmeticas,
relacionales y logicas de las restricciones. Adicionalmente trata los tres puntos que se
describen a continuacion:
Gramatica Ambigua . Para evitar que la gramatica definida para el compilador re-
sultara ambigua, se realizo una modificacion a la notacion con parentesis utiliza-
da en [Val03]. Esta modificacion obliga que toda restriccion debe escribirse entre
parentesis.
Precedencia de Procesos . La precedencia de procesos se presenta a continuacion.
Es importante notar, que los procesos estan organizados segun su alcance.
!,*,next,unless,local ligan al mas cercano
|| liga al proceso mas cercano de la suma (+)
Ejemplo: P + local x in next Q || RSignifica: P + ((local x in (next Q)) || R)
Se observa que el local x in P tambien se puede escribir como (local x)P
Restriccion Semantica . No pueden definirse procesos
local < ID list > in
( when < Constraint > do < P > + when < Constraint > do < P > + . . . ).
Lo anterior hace referencia al caso particular en que el programa NTCC incluya
!!P en ciertas condiciones, lo cual generarıa un estado de inconsistencia en la
maquina. Para solucionar lo anterior, se define que “!!P ∼= !P sii P tiene un local
92
con determinismo“; es decir que, mientras no exista un proceso tipo guarded-
choise en un local para P, se puede asegurar que !!P se ejecuta como !P.
5.3. Generacion de Codigo
La generacion de codigo es el paso final en la compilacion, en el cual se genera el archivo
con la traduccion al codigo de bytes de LMAN. La descripcion de como se traducen los
procesos, se describe detalladamente en el Anexo A, acerca de Traduccion de procesos
NTCC a codigo de bytes LMAN. El Anexo B describe todas las librerias usadas por el
compilador para construir programas en codigo de bytes LMAN.
93
6 Ejemplos y Pruebas
En este capıtulo se describen ejemplos de programacion y pruebas realizadas sobre
la maquina virtual LMAN ejecutado construcciones NTCC. Como se menciono ante-
riormente en la seccion 1.4, no conocemos alguna otra implementacion de un calculo
de procesos, temporal, concurrente por restricciones validado sobre robots LEGO; por
lo cual una comparacion entre LMAN y otras maquinas virtuales no serıa realmente
equitativa; sin embargo, en este capıtulo se expone una comparacion a nivel de recur-
sos entre LMAN, el lenguaje formal ESTEREL[MR82] y la maquina virtual estandar
LEGO.
6.1. Ejemplos
A continuacion se expondran los ejemplos que fueron compilados usando el compilador
NTCC-LMAN y ejecutados en LMAN.
6.1.1. Programa Zig-Zag
El ejemplo de zig-zag fue expuesto anteriormente en el capıtulo del calculo NTCC (ver
seccion 2.6.1), ahora se muestra su implementacion de acuerdo a la sintaxis valida en
LMAN :
Programa ZIG ZAG
--Definicion de constantes para el programa
const VEL = 50
const FWD = 1
94
const BACK = 2
const RGHT = 5
const LFT = 7
!(
-- Procesos 1 y 2:Asignacion de velocidades
(tell (ospmot1=VEL))
||
(tell (ospmot3=VEL))
||
--Proceso 3: ZIG ZAG
(
(when (a!=FWD) do
(tell (gf=1))
)
+
(when (b!=RGHT) do
(tell (gr=1))
)
+
(when (b!=LFT) do
(tell (gl=1))
)
)
||
--CELDAS
--Proceso 4: Implementacion de la primera celda (ca)
(when (ca=1) do
(
(next tell (ca=1))
||
(unless (changea=1) next
(
(when (a=0) do (next tell (a=0)))
+
95
(when (a=FWD) do (next tell (a=FWD)))
+
(when (a=RGHT) do (next (tell (a=RGHT))))
+
(when (a=LFT) do (next ( tell (a=LFT))))
)
)
)
)
||
--Proceso 5: Implementacion de la segunda celda (cb)
(when (cb=1) do
(
(next tell (cb=1))
||
(unless (changeb=1) next
(
(when (b=0) do (next tell (b=0)))
+
(when (b=FWD) do (next tell (b=FWD)))
+
(when (b=RGHT) do (next tell (b=RGHT)))
+
(when (b=LFT) do (next tell (b=LFT)))
)
)
)
)
||
--Proceso6: exchf, exchange forward.
(when (exchf=1) do
(
(tell (changea=1))
||
(tell (changeb=1))
96
||
(next (tell (a=FWD)))
||
(
(when (a=0) do (next tell (b=0)))
+
(when (a=FWD) do (next tell (b=FWD)))
+
(when (a=RGHT) do (next tell (b=RGHT)))
+
(when (a=LFT) do (next tell (b=LFT)))
)
)
)
||
--Proceso7: exchr, exchange right.
(when (exchr=1) do
(
(tell (changea=1))
||
(tell (changeb=1))
||
(next (tell (a=RGHT)))
||
(
(when (a=0) do (next tell (b=0)))
+
(when (a=FWD) do (next tell (b=FWD)))
+
(when (a=RGHT) do (next tell (b=RGHT)))
+
(when (a=LFT) do (next tell (b=LFT)))
)
)
)
97
||
--Proceso 8: exchl, exchange left.
(when (exchl=1) do
(
(tell (changea=1))
||
(next (tell (a=LFT)))
||
(tell (changeb=1))
||
(
(when (a=0) do (next tell (b=0)))
+
(when (a=FWD) do (next tell (b=FWD)))
+
(when (a=RGHT) do (next tell (b=RGHT)))
+
(when (a=LFT) do (next tell (b=LFT)))
)
)
)
||
--Procesos que determinan el movimiento y el exchange a ejecutar
--Proceso 9: gf, goforward
( when (gf=1) do
(
(tell (exchf=1))
||
(next (tell (omot1=FWD)))
||
(next (tell (omot3=FWD)))
)
)
||
--Proceso 10: gr, goright
98
( when (gr=1) do
(
(tell (exchr=1))
||
(next (tell (omot1=FWD)))
||
(next (tell (omot3=BACK)))
)
)
||
--Proceso 11: gl, goleft
( when (gl=1) do
(
(tell (exchl=1))
||
(next (tell (omot1=BACK)))
||
(next (tell (omot3=FWD)))
)
)
)
||
--Inicializacion de celdas
--Proceso 12 y 13
(tell (a=0))
||
(tell (b=0))
Descripcion del programa:
En la primera parte, los primeros dos procesos comentan restricciones sobre las veloci-
dades en los motores uno y tres, utilizando para ello las variables de salida del ambiente
de LMAN (ospmot1 = V EL, ospmot3 = V EL).
99
La segunda parte define el proceso encargado de escoger el siguiente movimiento del ro-
bot (tarea Zig-Zag) activando un proceso, esta decision se representa con una sumatoria
no-deterministica similar al ejemplo original de NTCC.
Los siguientes cinco procesos modelan las celdas (a y b) y el proceso exchage con
sus variantes; estas definiciones son similares a las que presenta el ejemplo dado en
[Val03] para el calculo NTCC ; sin embargo, el programa contiene algunas modificaciones
aplicadas, como lo son la generacion de guardas solo con los valores 0, FWD, RIGHT
y LEFT.
La cuarta parte, procesos nueve, diez y once, modela la ejecucion de los movimien-
tos del robot; estos procesos son los encargados de asignar la direccion a las varia-
bles de ambiente de LMAN, que controlan la direccion de los motores y su estado
actual(omot1, omot3).
Finalmente, la ultima parte es la encargada de dar valores iniciales a las celdas (a y b),
en la primera unidad de tiempo para ejecutar el programa.
Es importante mencionar que las guardas ejercen control sobre la ejecucion del bloque
de procesos al cual se antepone. Con esto se modela procedimientos y la llamada de un
proceso por otro; de lo contrario, todos los procesos se ejecutarıan concurrentemente
sin control, generando un comportamiento no esperado, fallas y bloqueos en el Store.
6.1.2. Programa de Evasion de Obstaculos
El siguiente programa es la tarea de evasion de obstaculos, que consiste ”en que el robot
se mueva hacia adelante y cuando encuentre un obstaculo, gire en alguna direccion,
en este caso hacia la izquierda, y posteriormente continue avanzando hacia adelan-
te”[Val00], el objetivo de esta tarea es como su nombre lo explica, el movimiento del
robot superando los obstaculos que encuentre.
PROGRAMA DE EVASION DE OBSTACULOS
(
--Proceso 1: Run Evasion
!( when (re=1) do
100
( when (ivalsen1=1) do next tell (gb=1)
||
when (ivalsen3=1) do next tell (gb=1)
||
when (ivalsen1=0) do ( unless (ivalsen3=1) next tell (gf=1))
)
||
--Procesos que determinan el movimiento a ejecutar
--Proceso 2: goForward
when (gf=1) do
( tell (omot1=1)
||
tell (omot3=1)
||
next tell (re=1)
)
||
--Proceso 3: goBack
when (gb=1) do
( tell (omot1=2)
||
tell (omot3=2)
||
next tell (tl=1)
)
||
--Proceso 4: turnLeft
when (tl=1) do
( tell (omot1=1)
||
tell (omot3=0)
||
next tell (re=1)
)
||
101
--Proceso 5 y 6: Asignacion de velocidades
tell (ospmot1>80)
||
tell (ospmot3>80)
||
--Proceso 7: Activacion del Sensor 1
tell (osen1=1)
)
||
--Activacion del proceso Run Evasion
tell (re=1)
)
Descripcion del programa:
El primer proceso re es el encargado de decidir cual es el siguiente movimiento que
ejecutara el robot LEGO. Si alguna de las variables de ambiente de entrada que contiene
LMAN para indicar los estados de los sensores 1 y 3 tiene el valor de oprimido(1);
entonces el robot LEGO a detectado un obstaculo, por lo cual retrocedera (gb) y girara a
la izquierda(tl), de lo contrario continuara su trayectoria(gf).
Los siguientes tres procesos se encargan de ejecutar los movimientos que debera hacer
el robot LEGO, asignando el valor a las variables de ambiente de LMAN que controlan
la direccion de los motores y su estado actual(omot1, omot3).
Los procesos cuatro y cinco son los encargados de comentar las restricciones sobre las
velocidades de los motores uno y tres, utilizando para ello las variables de salida del
ambiente de LMAN (ospmot1 = V EL, ospmot3 = V EL).
El proceso seis, se encarga de encender el sensor uno, por medio de la variable de salida
del ambiente de LMAN (ospmot1 = V EL, ospmot3 = V EL).
Finalmente, el ultimo proceso se encarga de iniciar la tarea de evasion de obstaculos
(re), en el primer instante.
102
6.1.3. Aplicaciones Musicales
Para mostrar los diversos ambientes de aplicacion del calculo NTCC, se incluye este
ejemplo que consiste en interpretar una melodıa en el robot LEGO. Las notas se modelan
teniendo en cuenta que cada unidad de tiempo vale por una corchea, por ejemplo; para
que una nota suene como negra,se debe tocar como corchea en dos unidades de tiempo
consecutivas. Su implementacion es la siguiente:
PROGRAMA CANON EN DO MAYOR
--Constantes para el programa
const ON = 1
const CORCHEA = 4
const BT = 38
const CC = 39
const CMC = 40
const DC = 41
const DMC = 42
const EC = 43
const FC = 44
const FMC = 45
const GC = 46
const GMC = 47
const AC = 48
const AMC = 49
const BC = 50
const CQ = 51
const CMQ = 52
const DQ = 53
const DMQ = 54
const EQ = 55
const FQ = 56
const FMQ = 57
const GQ = 58
const GMQ = 59
103
const AQ = 60
const AMQ = 61
const BQ = 62
(
--Proceso 1: Activacion del sonido
(! tell (osnd1=ON))
||
--Proceso 2: Duracion de la nota
(! tell(osnddur=CORCHEA))
||
--Proceso 3: Interpretacion de notas
(next 1 tell (ovalsnd1=GC))
||
(next 2 tell (ovalsnd1=GC))
||
(next 3 tell (ovalsnd1=CC))
||
(next 4 tell (ovalsnd1=DC))
||
(next 5 tell (ovalsnd1=EC))
||
(next 6 tell (ovalsnd1=FC))
||
(next 7 tell (ovalsnd1=GC))
||
(next 8 tell (ovalsnd1=GC))
||
(next 9 tell (ovalsnd1=CC))
||
(next 10 tell (ovalsnd1=CC))
||
(next 11 tell (ovalsnd1=CC))
||
(next 12 tell (ovalsnd1=CC))
104
||
(next 13 tell (ovalsnd1=AC))
||
(next 14 tell (ovalsnd1=AC))
||
(next 15 tell (ovalsnd1=FC))
||
(next 16 tell (ovalsnd1=GC))
||
(next 17 tell (ovalsnd1=AC))
||
(next 18 tell (ovalsnd1=BC))
||
(next 19 tell (ovalsnd1=CQ))
||
(next 20 tell (ovalsnd1=CQ))
||
(next 21 tell (ovalsnd1=CC))
||
(next 22 tell (ovalsnd1=CC))
||
(next 23 tell (ovalsnd1=CC))
||
(next 24 tell (ovalsnd1=CC))
||
(next 25 tell (ovalsnd1=FC))
||
(next 26 tell (ovalsnd1=FC))
||
(next 27 tell (ovalsnd1=GC))
||
(next 28 tell (ovalsnd1=FC))
||
(next 29 tell (ovalsnd1=EC))
||
105
(next 30 tell (ovalsnd1=DC))
||
(next 31 tell (ovalsnd1=EC))
||
(next 32 tell (ovalsnd1=EC))
||
(next 33 tell (ovalsnd1=FC))
||
(next 34 tell (ovalsnd1=EC))
||
(next 35 tell (ovalsnd1=DC))
||
(next 36 tell (ovalsnd1=CC))
||
(next 37 tell (ovalsnd1=DC))
||
(next 38 tell (ovalsnd1=DC))
||
(next 39 tell (ovalsnd1=EC))
||
(next 40 tell (ovalsnd1=DC))
||
(next 41 tell (ovalsnd1=CC))
||
(next 42 tell (ovalsnd1=BT))
||
(next 43 tell (ovalsnd1=CC))
||
(next 44 tell (ovalsnd1=CC))
||
(next 45 tell (ovalsnd1=CC))
||
(next 46 tell (ovalsnd1=CC))
)
106
Descripcion del programa:
El primer proceso activa en todas las unidades de tiempo el soporte de sonido en robot
LEGO; mediante las variables(osnd1) de salida del ambiente de LMAN.
El segundo proceso se encarga de dar la duracion de cada nota (en este caso una corchea)
para todos los instantes; esto se hace mediante las variables globales de LMAN (osnddur1).
Los siguientes procesos interpretan una nota de la melodıa en cada unidad de tiempo.
6.2. Pruebas
En esta seccion se comentan los resultados de la ejecucion de pruebas de los ejem-
plos anteriores, y se muestran los resultados de pruebas en otras caracterısticas de la
maquina virtual como tolerancia a fallos y depuracion de errores. Finalmente, se hacen
comparaciones con las maquina virtual estandar de LEGO[Leg00] y el compilador de
ESTEREL.
6.2.1. Etapa de pruebas de LMAN
Esta etapa, fue realizada probando cada uno de los modulos de la maquina por separado
y una vez superada la prueba individual de cada uno, se procedio a probar la maquina
en su totalidad. En cada modulo de LMAN se puede encontrar un makefile que genera
un ejecutable que corresponde a la prueba individual del respectivo modulo.
Luego de integrar cada uno de los modulos, se probo la maquina por completo ejecu-
tando los ejemplos anteriormente expuestos en una estacion de trabajo con procesador
pentium III a 930 Mhz, 256 Kb de memoria RAM y sistema operativo Linux Debian
Woddy 3.0. Cada uno de estos ejemplos utiliza propiedades particulares del calculo y
de la maquina, a continuacion se resaltan los detalles de la ejecucion de cada uno:
107
6.2.1.1. Programa Zig-Zag
Entre las propiedades del calculo que utiliza el programa Zig-Zag se encuentran el no–
determinismo, mediante el proceso de sumatoria∑
when cdoP , la replicacion infinita
de procesos (!) y la comunicacion con el Store a traves del proceso tell c
El programa Zig-Zag se ejecuto en una superficie homogenea de 80 cm, con una torre
de comunicacion serial ubicada a 80 cm de altura y un robot LEGO modelo roverbot.
La ejecucion del programa fue satisfactoria, con un tiempo de ejecucion promedio por
instante de 302.5 milisegundos (ver cuadro 6.1). Durante las pruebas, no presento pro-
blemas de comunicacion con la torre serial, debido a que se encontraba en un ambiente
libre de obstaculos.
Programa Tiempo de Unidad(milisegundos)
ZigZag 305ZigZag 305ZigZag 300ZigZag 300
Promedio 302.5
Cuadro 6.1: Desempeno del programa Zig-Zag
6.2.1.2. Programa de Evasion de Obstaculos
Entre las propiedades del calculo que se prueban en el programa de Evasion de Obstacu-
los, se encuentran la informacion negativa con el unless c next P , la sincronizacion de
procesos a traves del Store when c do P y la percepcion del entorno por medio de las
variables de entrada y salida del ambiente de LMAN que denotan el estado de los
perifericos del robot LEGO (sensores).
El programa de evasion de obstaculos se ejecuto en un laberinto de superficie de icopor
de 60 x 30 cm , con una torre de comunicacion serial ubicada a 80 cm de altura y un
robot LEGO modelo roverbot (Ver figura 6.1). El desempeno del programa resulto sa-
tisfactorio, con un tiempo de ejecucion promedio por una unidad de NTCC de 287.5
milisegundos (ver cuadro 6.2), y tiempo de ejecucion promedio de 2893 milisegundos
cuando se presentaron inconvenientes de comunicacion con la torre Serial. El tiempo
108
promedio de solucion del laberinto fue 1 minuto con 11 segundos, al evaluar este tiempo
se debe tener en cuenta el retardo que ocasionado por los inconvenientes de transmision.
Figura 6.1: Ejecucion del programa Evasion de obstaculos
Programa Tiempo de Unidad Tiempo de Tiempo de Solucion(milisegundos) Unidad con Retardo (minutos)
(milisegundos)
Evasion de obstaculos 290 2893 1.18Evasion de obstaculos 280 2666 1.05Evasion de obstaculos 290 2690 1.07Evasion de obstaculos 290 2825 1.17
Promedio 287.5 2768.5 1.11
Cuadro 6.2: Desempeno del programa Evasion de Obstaculos
6.2.1.3. Aplicaciones Musicales
El programa de la interpretacion de un fragmento de Canon en Do mayor permite
probar propiedades de NTCC como la nocion de tiempo multiforme, el modelamiento
en que cada unidad se considera una corchea, el retardo en la ejecucion de procesos,
entre otros. Los procesos next i (P ), posponen la ejecucion de P , i unidades de tiempo.
Con este programa, tambien se prueba el manejo del modulo de sonido del robot LEGO,
usando las variables de ambiente de LMAN.
109
El programa Canon sobre el robot se ejecuto en una superficie homogenea de 80 cm, con
una torre de comunicacion serial ubicada a 80 cm de altura y un robot LEGO modelo
roverbot. El desempeno del programa resulto aceptable con un tiempo de ejecucion
promedio por instante de 281.25 milisegundos (ver cuadro 6.3). Durante la ejecucion
no se presentaron problemas de comunicacion con la torre serial, debido a que no hubo
movimiento del robot LEGO, ni obstaculos en la comunicacion.
Programa Tiempo de Unidad
Canon 280Canon 285Canon 280Canon 280
Promedio 281.25
Cuadro 6.3: Desempeno del programa Canon en Do mayor
6.2.1.4. Recuperacion de Errores
LMAN permite recuperacion de errores en la transmision y admite depuracion de erro-
res en la ejecucion por medio de mensajes de error.
Debido a que el protocolo de transmision LNP es tipo UDP no tiene verificacion en
la recepcion; razon por la cual se hace necesario anadir un protocolo de control y
recuperacion de errores que sea capaz de identificar si hay comunicacion con el RCX, y
de lo contrario permita reintentar para establecer comunicacion. El funcionamiento del
protocolo se trata en la seccion 4.1.3.3 del capıtulo 4.
La depuracion de errores en LMAN, informa al usuario el tipo y descripcion del error
que se presento al ejecutar un programa. Los errores mas comunes suceden por incon-
sistencias en el Store, estado que genera un bloqueo en la maquina. Esta caracterıstica
de LMAN es de gran ayuda para diagnosticar errores en el codigo o funcionamiento de
un programa.
110
6.2.2. Comparacion entre LMAN , ESTEREL y La Maquinaestandar de LEGO
Se hara una comparacion de manejo de los recursos con la maquina estandar de LEGO[Leg00]
y el lenguaje formal de programacion deterministica ESTEREL[MR82]. Antes de iniciar
la comparacion se dara una breve descripcion de cada uno de los items a tratar:
Maquina Estandar de LEGO: Como ya se ha mencionado en capıtulos anteriores,
es el firmware original del robot LEGO. Tiene capacidad de almacenar 5 progra-
mas y realizar 10 tareas y 18 subrutinas por cada uno de ellos; maneja 32 variables
globales para todas las tareas y 16 locales por cada una de las tareas, permite
controlar todos los perifericos del robot LEGO: sensores, motores, timers, LCD.
ESTEREL: ESTEREL como herramienta de programacion, es un compilador que
realiza la transformacion del lenguaje sıncrono deterministico ESTEREL[MR82]
a codigo C del sistema operativo BrickOS(LegOS). Este compilador permite ma-
nejar una cantidad mayor de 10 tareas en paralelo y controla todos los perifericos
del robot LEGO. El numero de variables esta limitado por la cantidad disponible
de memoria que tenga el robot LEGO.
A continuacion se realiza la comparacion entre LMAN, ESTEREL y la Maquina Estandar
de LEGO, los criterios que se compararan son; expresividad, manejo de memoria de pro-
grama y manejo de tareas concurrentes.
Expresividad: LMAN maneja programacion formal temporal, concurrente por
restricciones y es no-deterministica, propiedades que le confieren un nivel mas alto
en expresividad del que maneja ESTEREL y la Maquina estandar de LEGO.
Capacidad de Memoria: Debido a que el nucleo principal de LMAN se ejecuta
en una estacion de trabajo, la capacidad de memoria que maneja es superior a la
de ESTEREL y a la maquina estandar de LEGO que se ejecutan internamente
desde el RCX. Esto permite ejecutar problemas complejos, que demanden nivel
de procesamiento y memoria que talvez desde el LEGO no sea posible ejecutar.
Si se observa de la manera anterior, la ejecucion del nucleo de la maquina desde
una estacion de trabajo, y el componente de transmision adicionado en LMAN
no resultaron realmente en desventaja frente a otras herramientas.
111
Manejo de tareas concurrentes: Ya que LMAN utiliza como plataforma de
desarrollo y ejecucion el sistema operativo BrickOS(LegOS)[MLNP00] y gracias
a la propiedad del calculo de modelar tareas concurrentes, el numero de tareas
concurrentes admitidas por LMAN es n. Lo cual es superior en funcionamiento
a la maquina estandar de LEGO. ESTEREL admite el modelamiento de tareas
concurrentes.
A continuacion se presenta un cuadro que resume las caracterısticas de cada uno de los
item comparados.
Criterios LMAN ESTEREL MaquinaEstandar de LEGO
Expresividad No-determninismo Determinismo Determinismo(formal) (formal)
Capacidad Limitada por Limitada por Muy limitadade hardware de hardware del
Memoria la estacion robot LEGOManejo Superior Superior Basico
de (10 o mas procesos) 10 o mas procesos) (10 procesos)tareas concurrentes
Cuadro 6.4: comparacion de LMAN, ESTEREL y Maquina estandar de LEGOS
Por las pruebas y los datos registrados en este capıtulo, es posible concluir que la
implementacion de LMAN que se reporta, resulta ser eficiente, robusta, tolerante a
fallos y de funcionamiento en tiempo real, a pesar que los programas realizados en
ella conllevan la resolucion de restricciones aritmeticas y el modulo de transmision de
instrucciones por torre serial/USB al robot LEGO.
112
7 CONCLUSIONES Y TRABAJOFUTURO
El objetivo propuesto para el presente trabajo de tesis, involucra el diseno e implementa-
cion de una maquina abstracta para el calculo NTCC, de modo que sea posible ejecutar
construcciones NTCC sobre robots LEGO. No obstante, para proveer una funcionali-
dad completa, se hizo fundamental involucrar en los objetivos del proyecto, acoplar un
sistema de restricciones para implementar el componente CC del calculo subyacente,
junto con un compilador para proveer una interfaz en alto nivel de programacion para
la maquina.
La maquina LMAN resulta una implementacion completa y eficiente del calculo NTCC,
que permite controlar y ejecutar en tiempo real programas escritos en NTCC sobre
Robots LEGO MindStorm. Su base formal en este calculo le confiere la expresividad
suficiente para modelar problemas complejos del mundo del robot, de una manera mas
natural y sin caer en detalles especıficos en la implementacion. Por ejemplo, no se
necesita especificar una velocidad fija para el robot, simplemente se da un rango (velo-
cidad > 80); tampoco es necesario especificar al robot una vıa de accion determinada
(cuando encuentre un obstaculo, gire hacia la izquierda), se le deja una escogencia
no–determinıstica de la accion; permite modelar problemas de la realidad como la in-
terpretacion de melodıas, en donde se define una unidad de tiempo como un nota (un
instante equivale a una corchea) y finalmente permite dar solucion a problemas que usan
la asincronıa para asegurar que el robot realiza una accion (chequear la temperatura),
en un instante de tiempo no determinado.
El modelo formal presentando en forma de maquina abstracta, provee la especifica-
cion de la maquina virtual para LMAN. Esta formalidad aseguro en LMAN un diseno
completo y consistente, de modo que, la implementacion fue transparente, fluida y el
113
comportamiento de la maquina siempre fue el esperado. Una vez finalizo la etapa de
implementacion con base en el diseno formal realizado, no fue necesario realizar modi-
ficaciones de fondo al codigo fuente.
El diseno modular de LMAN actua como un componente integrador. Ademas de que
combina los paradigmas de programacion reactiva, temporal, concurrente y por res-
tricciones en un entorno eficiente de programacion para dispositivos roboticos LEGO,
LMAN integra otros proyectos. De esta manera, se ha logrado acoplar a LMAN el tra-
bajo de grado que implementa el sistema de restricciones [CG01] para el calculo PiCO,
la gramatica que describe formulas de primer orden descrita en el trabajo de grado de
la maquina abstracta MAPiCO[AB98], el compilador NTCC-LMAN desarrollado como
proyecto de semestre en el curso de Compiladores (PUJ) [RCP03], el trabajo de grado
que implementa el lenguaje visual VIN, y por supuesto el calculo subyacente NTCC
[Val03].
El desarrollo de LMAN alrededor de una comunidad de codigo abierto y de un alto
nivel investigativo, agilizo el aprendizaje, la consecucion de soluciones y el desarrollo
colaborativo. El contacto continuo con otros grupos de investigacion y comunidades
de desarrollo sobre Internet, fue determinante para hallar solucion a los problemas en
implementacion de LMAN, principalmente en lo relacionado con el manejo de los dispo-
sitivos roboticos LEGO. Gracias a esta colaboracion fue posible disenar e implementar
un ambiente de ejecucion eficiente para LMAN, utilizando un protocolo de comunica-
ciones, por medio del cual la maquina virtual se ejecuta en una estacion de trabajo y
se comunica via infrarrojo con el dispositivo robotico para ejecucion.
Como trabajo futuro, se han considerado varias actividades y recomendaciones que
permitiran afinar la implementacion actual. Estas pueden clasificarse en dos grupos,
los cuatro primeros puntos tratan actividades y recomendaciones relacionadas con el
componente formal de LMAN y las siguientes estan relacionadas con el componente
funcional.
La maquina abstracta de LMAN modela de manera cercana el calculo NTCC. No
obstante, para probar su correctitud es importante realizar la prueba formal de
bisimilitud, desde el calculo hacia la maquina y desde la maquina hacia el calculo
NTCC.
Se recomienda implementar la definicion de celdas para NTCC dada en [Val03] a
114
nivel de la maquina virtual. Esto reducirıa el codigo de programa necesario para
modelar celdas en el calculo, ademas de que actuarıa como una plantilla generica
que es posible usar en cualquier problema computacional que implique el uso de
celdas.
Para lograr aun mas eficiencia y proveer mayor expresividad en las construccio-
nes NTCC ejecutadas sobre la maquina, es importante desarrollar un sistema de
restricciones propio para NTCC, tal como se describe en [Val03]. Gracias a la
propiedad de LMAN de definir restricciones como formulas de primer orden, su
acople serıa casi transparente siempre y cuando el nuevo sistema de restricciones
tambien exprese las restricciones de esta manera.
La sintaxis de la maquina abstracta y consecuentemente las instrucciones de la
maquina virtual, puede ser extendidas para modelar los procesos derivados del
calculo NTCC. La maquina virtual permite definir hasta 64 instrucciones.
Para futuras versiones de RCX que admitan mayores recursos de Hardware y gra-
cias a la modularidad del diseno de LMAN, se puede lograr optimizar la maquina
de tal modo que pueda ejecutarse desde el RCX, omitiendo ası el modulo que rea-
liza la transmision. Esta optimizacion debe partir de un sistema de restricciones
propio para aplicaciones NTCC, tal como se ha mencionado anteriormente.
Con la actual implementacion de LMAN que permite el control del doble de
dispositivos de los RCX convencionales, es posible disenar ambientes colaborativos
logrando crear programas que involucren la interaccion de dos o mas RCX.
La modularizacion de LMAN posibilita el acople de herramientas de simulacion.
La interfaz LEGO actuarıa como el componente integrador entre el simulador y
la maquina virtual.
LMAN actualmente ha sido probada ejecutandose sobre LINUX; es posible hacerla
portable a Windows y MacOS. Adicionalmente, es importante que exista el uso
del driver USB para la transmision via LNP, esto mejorarıa el desempeno de la
transmision. . En la actualidad LNP admite solamente torre serial.
Finalmente con todo el paquete afinado es importante generar una herramienta
de instalacion, que disminuya todas las tareas alrededor de la configuracion de
LMAN para su funcionamiento.
115
Anexo A. Traduccion de procesos NTCC a codigo de bytes de LMAN
Anexo A. Traduccion de procesos NTCC a codigo de bytes deLMAN
Las siguientes tablas describen la construccion de los procesos de LMAN en el codigo de
bytes entrada de la Maquina Virtual. Las instrucciones que se utilizan en este apendice,
se definen en el archivo opcodes.h como constantes para un mejor entendimiento. Las
construcciones descritas a continuacion fueron usadas para la generacion de codigo desde
el compilador.
A.1 Tell
La instruccion tell < constraint > se traduce a LMAN escribiendo las instrucciones
que corresponden a la restriccion, seguidas de las instrucciones lTELL y SKIP.
Ejemplo: para tell ( x > 5), se genera el codigo:
Lınea Opcode Src1 Src2
1 ATOM MAY 2
2 TERMV 74
3 TERMC 5
4 lTELL
5 SKIP
A.2 When
La instruccion when < constraint > do < P >, se traduce escribiendo las instruccio-
nes que corresponden a la restriccion, seguidas de la instruccion ASK que lleva como
parametro la direccion de la ultima instruccion del proceso hijo (P), finalizando con las
instrucciones correspondientes al proceso P.
Ejemplo: para when (x = 1) do tell (y = 0), se genera el codigo:
Lınea Opcode Src1 Src2
1 ATOM IGUAL 2
2 TERMV 74
3 TERMC 1
4 lASK 9
5 ATOM IGUAL 2
6 TERMV 75
7 TERMC 0
8 lTELL
9 SKIP
A.3 Composicion Paralela
La instruccion < P > || < P >, se traduce escribiendo la instruccion PAR que lleva
como parametro la direccion de la primera instruccion del segundo proceso, seguida de
las instrucciones que corresponden al primer proceso, y por ultimo las instrucciones del
segundo proceso.
Ejemplo: para tell (x > 5) || tell (y > 1), se genera el codigo:
Lınea Opcode Src1 Src2
1 PAR 7
2 ATOM MAY 2
3 TERMV 74
4 TERMC 5
5 lTELL
6 SKIP
7 ATOM MAY 2
8 TERMV 75
9 TERMC 1
10 lTELL
11 SKIP
A.4 Unless
La instruccion unless < constraint > next < P >, se traduce escribiendo las instruc-
ciones que corresponden a la restriccion, seguidas de la instruccion UASK que tiene
como parametro la direccion de la ultima instruccion del proceso hijo (P), finalmente
las instrucciones del proceso P.
118
Ejemplo: para unless (x > 5) next tell (y < 80), se genera el codigo:
Lınea Opcode Src1 Src2
1 ATOM MAY 2
2 TERMV 74
3 TERMC 5
4 UASK 9
5 ATOM MEN 2
6 TERMV 75
7 TERMC 80
8 TELL
9 SKIP
A.5 Next
La traduccion de la instruccion next < Const op > < P >, depende de la existencia o
no de la constante opcional.
Cuando la constante es vacıa, se traduce escribiendo la instruccion NEXT que lleva
como parametro la direccion la ultima instruccion del proceso hijo (P), seguida de las
instrucciones que corresponden al proceso P.
Cuando la constante no es vacıa, se traduce escribiendo la instruccion NEXTN que
lleva como parametro el numero de instantes que deben transcurrir antes de realizar
el proceso, seguida de la instruccion JMP que tiene como parametro la direccion de la
ultima instruccion del proceso hijo (P), y finaliza con las instrucciones que corresponden
al proceso.
Ejemplos: Para next ( tell (x = 1)), se genera el codigo:
Lınea Opcode Src1 Src2
1 NEXT 6
2 ATOM IGUAL 2
3 TERMV 74
4 TERMC 1
5 TELL
6 SKIP
119
Para next 2 ( tell ( x =1)), se genera el codigo:
Lınea Opcode Src1 Src2
1 NEXTN 2
2 JMP 7
3 ATOM IGUAL 2
4 TERMV 74
5 TERMC 1
6 TELL
7 SKIP
A.6 Replicacion
La instruccion ! < P >, se traduce escribiendo la instruccion REP sin parametros,
seguida de las instrucciones que corresponden al proceso.
Ejemplo: para !tell (x > 80), se genera el codigo:
Lınea Opcode Src1 Src2
1 REP
2 ATOM MAY 2
3 TERMV 74
4 TERMC 80
5 LTELL
6 SKIP
A.7 Asincronıa
Para traducir la instruccion *[< constante >,< constante >] < P >, el compilador
debe generar un valor aleatorio (random) en el rango comprendido entre los valores de
las dos constantes. Luego, se traduce escribiendo la instruccion STAR, cuyo parametro
es el numero aleatorio generado, seguida de la instruccion JMP que lleva la direccion
de la ultima instruccion del proceso hijo (P), finalizando con las instrucciones que
corresponden a P.
120
Ejemplo: para * [1,7] tell (x=1), se genera el siguiente codigo.Se asume que el random
genera el 4 (Src1 de la primera lınea).
Lınea Opcode Src1 Src2
1 STAR 4
2 JMP 7
3 ATOM IGUAL 2
4 TERMV 74
5 TERMC 1
6 TELL
7 SKIP
A.8 No determinismo
Los procesos de la instruccion < P > + < P > + < P > . . . , tienen dos interpretaciones
posibles:
Si el proceso NO es un when < constraint > do < P > (es cualquiera de los
otros procesos posibles), este se debe interpretar como when true do P, dado
que en NTCC no existen las constantes true o false, se crea una restriccion que
siempre sea verdadera: when (0=1) do P, donde 0 es una etiqueta que siempre
se comenta al Store con valor 1. Por ejemplo, si se tiene tell (a+b>5) + next
tell(a=10), esto se interpretarıa como la instruccion
when (1=1) do tell (a+b>5) + when (1=1) do next tell (a=10).
Si el proceso es un when < constraint > do < P > se ejecuta nomalmente
(evaluando la restriccion para decidir si P se ejecuta o no).
Finalmente, cada instruccion < P > + < P > + < P > representa una instruccion
de la forma when < constraint > do < P > + when < constraint > do < P > +
when < constraint > do < P >. La traduccion de esta instruccion es ası:
Cada instruccion when < constraint > do < P > se traduce escribiendo las
instrucciones que corresponden a la restriccion, seguidas de la instruccion GASK
que lleva como primer parametro la lınea donde se inicia el siguiente proceso, y
como segundo parametro 1 o 0 (1 para el primer when de la sumatoria, y 0 para
121
los when restantes), seguidos por las instrucciones del proceso hijo (P), y una
instruccion JMP que lleva como parametro la direccion de la ultima instruccion
de todo el conjunto de procesos (en el caso del ejemplo el skip de la direccion 32)
. Los codigos de los procesos se concatenan, y al final se agregan las instrucciones
NDET y SKIP.
Se debe tener en cuenta que para el GASK del ultimo proceso, el proceso siguiente
es el NDET (en el ejemplo el GASK de la lınea 24, tiene como parametro 31, lınea
del NDET).
Ejemplo: para when (x > 40) do tell(y = 1) + tell(y = 1) + when (x =1) do tell(y
= 0), se genera el codigo:
Lınea Opcode Src1 Src2
1 ATOM MAY 2
2 TERMV 74
3 TERMC 40
4 GASK 11 1
5 ATOM IGUAL 2
6 TERMV 75
7 TERMC 1
8 lTELL
9 SKIP
10 JMP 32
11 ATOM IGUAL 2
12 TERMV 0
13 TERMC 1
14 GASK 21 0
15 ATOM IGUAL 2
16 TERMV 75
17 TERMC 1
18 lTELL
19 SKIP
20 JMP 32
21 ATOM IGUAL 2
122
22 TERMV 74
23 TERMC 1
24 GASK 31 0
25 ATOM IGUAL 2
26 TERMV 75
27 TERMC 0
28 lTELL
29 SKIP
30 JMP 32
31 NDET
32 SKIP
A.9 Skip
El proceso skip se usa para sincronizar en LMAN. De esta manera la mayorıa de
procesos a excepcion de algunos como replicacion (!) y paralelo (||) deben incluir como
parametro un llamado al skip mas cercano, tal como se ha apreciado en lo ejemplos
anteriores.
A.10 Manejo de Rangos
Aunque el Sistema de Restricciones actual no implementa rangos, en LMAN se definen,
de modo que, si se adiciona un nuevo Sistema de Restricciones puedan ser utilizados en
las construcciones NTCC. Los rangos se definen de la siguiente manera:
x in 10.,20
< var reference > in < Constante > .. < Constante >
Los cuales se representan con la estructura
OPERACION
/ \
Variable RANGE
/ \
Inicio Fin
Ejemplo: Para la restriccion x in 10.,20, el arbol que expresa la restriccion se represen-
tarıa:
123
IN
/ \
x RANGE
/ \
10 20
Lo anterior se traduce en codigo de bytes LMAN como sigue: (se asume que la direccion
de x es 79):
Lınea Opcode Src1 Src2
1 ATOM IN 2
2 TERMV 79
3 TERMF RANGE 2
4 TERMC 10
5 TERMC 20
124
Anexo B. Librerıas para la construccion de Programas en LMAN
Anexo B. Librerıas para la construccion de Programas en LMAN
Como resultado de la compilacion de NTCC a LMAN, se debe generar un archivo
binario, que contendra el codigo que ejecutara la maquina virtual. Para ello, se provee
un conjunto de librerıas necesarias para escribir este archivo de forma correcta, las
cuales se describen a continuacion.
Para escribir una lınea de codigo de maquina de LMAN se utiliza la funcion:
escribirLinea(OPCODE, SRC1,SRC2 ,ARCHIVO)
que se encuentra definida en el modulo cargador (cargador.h y cargador.o) con
los siguientes parametros:
• OPCODE: Es el codigo de la operacion
• SRC1: Es el primer parametro de la operacion (si no es necesario va en
cero).
• SRC2: Es el segundo parametro de la operacion (si no es necesario va en
cero).
• ARCHIVO: Es el archivo donde se va a escribir el programa. Recuerde que
la precondicion de escribirLinea es que el archivo este abierto en modo de
escritura (Ejemplo: fopen(”lman.bin”, ”w”)).
El archivo binario debe finalizar con la instruccion (0, 0, 0) lo cual indica que es
el fin del archivo.
Las librerıas relacionadas para la construccion de programas son las siguientes:
• opcodes.h: contiene la definicion de los codigos de operacion -opcodes- de
LMAN.
• ValueFrameConst.h: contiene la definicion de los valores necesarios para rea-
lizar la interaccion con el sistema de restricciones (IGUAL, DIF, MAY, ...).
• varlman.h: contiene la definicion de las variables de ambiente de LMAN tanto
las de entrada como las de salida (ISENEST1, IMOTEST6).
Bibliografıa
[AB98] M. Heredia . A. Buss. MAPiCO: Maquina Abstracta para el Calculo Pico.Tesis de Pregrado, Facultad de Ingenieria, Pontificia Universidad Javeria-na. 1998.
[ADQV98] G. Alvarez, J. Diaz, L. Quesada, and F. Valencia. PiCO: A calculus ofconcurrent constraint object for musical applications. ECAI98, Workshopof Constraint and the Arts, Brighton, England. 1998.
[Bau00] D. Baum. http://www.baumfamily.org/nqc/. 2000.
[Car95] B. Carlson. Compiling and Executing Finite Domain Constraints. PhDthesis, Swedish Institute of Computer Science. 1995.
[CG01] A. Vasquez C. Garcia. Implementacion eficiente de un sistema de dominiosfinitos para el lenguaje cordial. Tesis de Pregrado, Facultad de Ingenieria,Pontificia Universidad Javeriana. 2001.
[Com00] Houghton Mifflin Company. The American Heritage r© Dictionary of theEnglish Language, Fourth Edition. Copyright c© 2000.
[FQ04] D. Fernandez and J. Quintero. VIN: Lenguaje Visual basado en el calculoNTCC. Tesis de Pregrado, Ingenierıa de Sistemas, Pontificia UniverisidadJaveriana. 2004.
[Fre99] J. Fredslund. The assumption architecture. Progress Report, Department ofComputer Science, University of Aarhus. 1999.
[Gro00] LEGO Group. Constructopedia. LEGO, MindStorms, Robotics InventionSystem. 1999/2000.
[HS96] T. Haynes and S. Sen. Evolving behavioral strtegies in predators and prey.In Proc of the IJCAI Workshop on Adaptation and Learning in Multi-AgentSystems, volume 1042 of Lecture Notes in Artificial Intelligence, pages 113-126. Springer Verlag. 1996.
127
[JNO97] S. Jones, T.Nordin, and D. Oliva. C–:A portable assembly language. InImplementation of Functional Languages. 1997.
[Jon92] S. Jones. Implementing Lazy Functional Languages on Stock Hardware: theSpineless Tagless g-machine. Journal of Functional Programmingd Concu-rrency. Preentice-Hall. 1992.
[Leg00] Lego. LEGO MindStorms RCX 2.0 Firmware Command Overview,. 2000.
[Lop99] L. Lopes. On the Design and Implementation of a Virtual Machine for Pro-cess Calculi. PhD Dissertation, Department of Computer Sciences, Univer-sity of Porto. 1999.
[LP99] H. H. Lund and L. Pagliarini. Robot soccer with LEGO mindstorms. LNCS,1064:141-151. 1999.
[LY97] T. Lindholm and F. Yellin. The Java Virtual Machine Specification. 1997.
[MBD86] V. Jagannathan M. Brenda and R. Dodhiawala. On optimal cooperationof Knowledge sources - an empirial investigation. Technical REport BCS-G2010-28, Boeing Advanced Techology Center. 1986.
[McA92] D. McAllester. First order logic. 1992.
[Mil89] R. Milner. Communication and Concurrency. 1989.
[Mil99] R. Milner. Communicating and Mobile Systems: the π calculus. CambridgeUniversity Press. 1999.
[MLNP00] L. Villa M. L.Noga and P. http://brickos.sourceforge.net/. 2000.
[MR] C. Mauras and M. Richard. LUSTRE Y ESTEREL synchronous languages.http://www.emn.fr/x-info/lego/.
[MR82] J. Marmorat and J. Rigault. http://www-sop.inria.fr/esterel.org/. 1982.
[RCP03] F. Rocha, J. Chala, and M. Pabon. Compilador NTCC-LMAN. Reporte delcurso de Compiladores, Pontificia Universidad Javeriana–Cali. 2003.
[SJG94] V. Saraswat, R. Jagadeesan, and V. Gupta. Foundations of timed concurrentconstraint programming. In Proc. Of the Ninth Annual IEEE Symposium ofLogic in Computer Science. 1994.
[SR00] J. Solorzano and T. Rinkens. http://lejos.sourceforge.net/index.html. 2000.
[SRP91] V. Saraswat, M. Rinard, and P. Panangaden. The semantic foundationsof Concurrent Constraint Programming. In ACM, Preceedings of eighteenthannual ACM symposium of Principles of programming languages. 1991.
128
[SRP03] V. Saraswat, M. Rinard, and P. Panangaden. JCC: Integrating Timed De-fault Concurrent Constraint Programming into java. 2003.
[SV00] P. Stone and M. Veloso. Multiagent systems: A survey from a machinelearning perspective. Autonomoues nRobots, 8: 345-383. 2000.
[Val00] F. D. Valencia. Reactive Constraint programing. Progress Report , Depart-ment of Computer Science, University of Aarhus. 2000.
[Val03] F. D. Valencia. Temporal Concurrent Constraint Programming. PhD Dis-sertation, Department of Computer Science, University of Aarhus. 2003.
[VS91] P. Panangaden V. Saraswat, M. Rinard. The semantic foundations of con-current constraint programming. In ACM, Prceedings of eighteenth annualACM symposium of Principles of programming languages. 1991.
[VSG96] R. Jagadeesan V. Saraswat and V. Gupta. Timed Default Concurrent Cons-traint Programming. J. Symbolic Computation. 1996.
[War83] D. Warren. An Abstract Prolog Instruction Set. Technical Report 309, SRIInternational. 1983.
129
