Hasta este punto del desarrollo, los eventos de sincronización de procesamiento estaban ligados a clocks sincrónicos, pudiéndose elegir cual mecanismo de reloj (clock) se asociaba un sistema a ser simulado en el vindigente, como por ejemplo una función fisiológica o un comportamiento. Por ejemplo, si una salida de impresión de un autómata es OUT P+1 P y se asocia a un reloj que produce un evento de ejecución de base 1 segundo, P se incrementará en 1 cada segundo. Los clock sincrónicos pueden asociarse a autómatas como a bloques de procesamiento.
Ahora en la nueva versión de desarrollo hemos incorporado mecanismos de reloj programables. Estos nuevos clocks pueden ser asociados a cualquier variable de la Unidad de Procesamiento Programable[1] del vindigente (indigente virtual). De esta manera podrá crearse cualquier función para generar un evento de clock complejo. Cada vez que la variable pase de false a true generará un evento de clock. Por cada variable que se defina como Clock se generará un Clock Programable asociado a dicha variable y que a su vez podrá ser asociado a diferentes sistemas de simulación (Simulated Systems). Esto da una gran flexibilidad de simulación, programación y disminuye el procesamiento.
Los Clock sincrónicos se definen directamente en cada Autómata y Bloque de Procesamiento (Funciones) que procesen sincrónicamente con dicho clock. No, en todos los casos, pueden ser necesarios dado que tanto los Autómatas como los Bloques de Procesamiento pueden ser asincrónicos, es decir que procesen automáticamente las variaciones de sus entradas sin estar sincronizadas a un clock.
Los clocks sincrónicos pueden tener los siguientes parámetros:
36000, Evento cada 1 hora
6000, Evento cada 1 minuto
3000, Evento cada 30 segundos
1000, Evento cada 10 segundos
500, Evento cada 5 segundos
100, Evento cada 1 segundo
50, Evento cada 0.5 segundos
10, Evento cada 0.5 segundos
5, Evento cada 0.05 segundos
Por ejemplo:
AUTOMATA: DeltaProcess
Clock: 100
…
El autómata DeltaProcess evaluará sus cambios de estado cada 1 segundo.
Los Clock Programables se asocian a una variable sitandolas en su formato remoto (o Global). Por ejemplo si tenemos la variable: Delta.DeltaProcess.Delta.Deltas esta nomenclatura determina que a la variable a la cual se hace referencia corresponde a la de nombre local: Delta, del autómata o proceso: DeltaProcess, del Sistema Simulado (SimulatedSystem): Delta, del Grupo de Sistemas agrupados con el nombre: Deltas .
Si tenemos la definición:
AUTOMATA: DeltaProcess2
Clock: Delta.DeltaProcess.Delta.Deltas
…
Se determina que el atómata DeltaProcess2 procesará los cambios de estado cada vez que la variable Delta.DeltaProcess.Delta.Deltas cambia de estado. En realidad un cambio de estado puede ser tomado como:
-Cambio de false a true
-Cambio de cero o un número menor de cero a un número mayor que cero sea entero o flotante
Seguimos trabajando para dar mucha más flexibilidad a la definición de comportamientos y funciones fisiológicas por fuera del sistema. Es decir, definiéndolas sin tener que tocar código fuente dentro de Realidad Empoderada y así dar flexibilidad a administradores e investigadores locales. Si queremos continuar en la línea de hacer un desarrollo no colonizador[2] debemos continuar desarrollando para que los entornos locales tengan en poder de definir la funcionalidad de Realidad Empoderada según su contexto local.
[1] Unidad de Procesamiento Programable, ver: G. Reimondo, “Desarrollo y avances para la simulación de la praxis social solidaria”, RealidadEmpoderada.com
[2] Desarrollo no colonizador, ver:
“Una nueva etapa en el desarrollo de Realidad Empoderada: las percepciones”, Realidad Empoderada
“Desarrollo y avances para la simulación de la praxis social solidaria”, Realidad Empoderada
“Poniéndole movimiento y capacidad de interacción a los avatares”, Realidad Empoderada
Be the first to comment