El modelado mediante un sistema basado en eventos discretos

El modelo conceptual de la Sección 4.3.1 brinda un panorama de los conceptos principales y el nivel de detalle que debe estar presente en el modelo lógico. Ahora, se presenta el diseño orientado a objetos de este último y el capa de abstracción de eventos discretos correspondiente al motor de ejecución que ejecuta los modelos configurados. Una vista estructural de los componentes principales se muestra en el diagrama de clases de la Figura 4.1.

Device -em: ExecutionManager -bm: BatteryManager -nm: IOManager +processEvent(e:Event) Proxy -s: Scheduler -devices: List<Device> +processEvent(e:Event) 1 1 Job +status: int +dataInputSize: int +dataOutputSize: int +totalOps: long +remainingOps: long +createJob(): Job IO -incomingTransfersQueue: List<Message> -outgoingTransfersQueue: List<Message> -destNode: Node +rssi: int +processEvent(e:Event) 1 * <<Interface>> Node +send(m:Message) +receive(m:Message) Entity -id: int -name: String +processEvent(e:Event) Event +time: long +data: Object +entity: int +type: int +createEvent(time:long,entity:int,type:int,data:Object): Event +compare(e:Event): int 1 * SimulationEngine -entities: Hash<Integer,Entity> -fel: SortedSet<Event> -clock: long +run(masterConfiguration:File) +addEntity(en:Entity) +addEvent(ev:Event) 1 * Message +size: int +source: IO +dest: IO +deliveredStatus: int +data: Object +seqNmb: int +totalNmb: int +createMessage() * * * * * 1

Figura 4.1:Clases principales del modelo de grilla de SMDs basado en infraestructura: Diagrama de clases -UML- .

Un objetoDeviceestá asociado a un objetoProxy, y este último está asociado a muchos dispositivos. Las clases Proxy y Device implementan la interfazNode que declara primitivas básicas de comunicación. El nodo es utilizado por objetos IO. Un par de objetosIOcoordinan el uso de un enlace y administran el colas de datos entrantes y salientes, es decir, modelan la comunicación dispositivo-proxy. Todas las operaciones de red entre el proxy y un dispositivo o viceversa se delegan a dicho par de objetosIO. Cada el dispositivo tiene su propio objetoIOmientras que elproxytiene muchos, uno por dispositivo. El par de instancias deIOforman un enlace punto a punto tiene un atributo de calidad de señal asociado (rssi) y que los objetosIOutilizan para definir el retraso (y la energía gastada por nodos) para una operación de transferencia de mensajes. La clase deMessagerepresenta los fragmentos en que todos los datos inter- cambiados a través de un enlace se dividen, que es cómo funcionan los protocolos de red. La división la operación se aplica a la entrada de datos de trabajo, salida de datos de trabajo, actualizaciones de estado de dispositivos y cualquier otro dato futuro transferencia admitida por el modelo de Grilla móvil. Al divi- dir una transferencia de datos en una secuencia de mensajes, el consumo de energía de las operaciones de red y los resultantes de otras fuentes de utilización, por ejemplo, Uso de la CPU, puede ser intercalado. Modelar este entrelazado es importante para reflejar fielmente la energía debido a la utilización simul- tánea de componentes de dispositivos conectados en paralelo Furthmüller y Waldhorst (2012) (CPU y tarjeta de red en este caso). Por último, los objetos de trabajo representan el estado y la atribución de tes

de trabajos enviados para su ejecución al sistema de Grilla móvil. Desde la perspectiva de la ejecución del modelo, trabajo y los objetos de mensaje son transitorios, es decir, objetos que se inundan a través de diferentes procesos que se modelan como entidades, por ejemplo, proceso de programación, proceso de transferencia y proceso de ejecución.

Vale la pena aclarar que los atributos, métodos auxiliares, por ejemplo, setters, getters y classes, se han omitido en el diagrama para evitar comprometer la legibilidad. Entre las clases excluidas, están las clases

ExecutionManager,BatteryManagereIOManager, que están asociadas a la claseDevicey encapsulan el

comportamiento para administrar la disponibilidad de recursos cómputo, el nivel de batería restante y las variables de estado relacionadas con la red, respectivamente. Además,Proxyutiliza un objetoScheduler

que contiene el lógica para decidir qué trabajo se asigna a qué dispositivo. Es importante resaltar que los criterios encapsulado por el objeto del planificador representa un punto fuerte de variabilidad que debe ser proporcionado por modeladores y como se indica en la introducción de este capítulo es lo que motiva la creación de esta herramienta.

Las clases de fondo gris representan la capa de abstracción que encapsula el tipo de objetos vistos por el motor de ejecución. En este punto, vale la pena mencionar que la dinámica del sistema se trata como un sistema de eventos discretos. Significa que todos los componentes (clases) referidos en el párrafo anterior se relacionan con el clases que encapsulan principios de funcionamiento y bloques de construcción bá- sicos de tal tipo de simulación. por Por ejemplo, en la Figura 4.1 se puede observar que las clasesProxy,

DeviceyIOheredan del resumen de la claseEntity. Un objeto que hereda de esta última clase debe pro-

porcionar una implementación concreta del método processEvent()que recibe un objeto de tipoEvent

como argumento. Una instancia de evento tiene, a su vez, cuatro argumentos asociados: un argumento de tiempo que especifica el punto en el tiempo de simulación donde ocurre el evento, una identificación de entidad que proporciona la información del motor de la entidad instancia/s que deben procesar el evento, un tipo de argumento de evento que le da a la entidad información de la naturaleza del evento y los datos asociados que almacenan información de estado o datos complementarios que necesita el entidad que procesa el evento. El procesamiento de eventos podría producir cambios en el estado del sistema, es de- cir, cambios en los atributos de los componentes del modelo y / o activar la creación de nuevos eventos. Más adelante en esta sección, se describirán eventos específicos y entidades modeladas para reflejar la dinámica del sistema conceptual modelo. Antes de eso, describiré el protocolo de ejecución utilizado para ejecutar diferentes infraestructuras basadas modelos de red móvil.

La Figura 4.2 describe el protocolo de ejecución -en términos de la cadena de llamadas al método involucrado- de la simulación motor cuando se invoca el método de ejecución de la clase Simulatio-

nEngine. El método primero se inicializa y carga todas las entidades y un conjunto mínimo de eventos

que son necesarios para comenzar la simulación del modelo configurado por el modelador. Las instancias de entidad se mantienen en un mapa de entidades, mientras que las instancias de eventos son agregado a la lista de eventos fel (lista de eventos futuros) del motor de ejecución del modelo. La inicialización consiste en leer entidades, atributos y eventos del archivo de configuración (modelConfigFile) proporcio- nado por el modelador. Toda la inicialización se realiza con varias clases auxiliares. Hay, por ejemplo,

un SchedulerLoader a cargo de crear el proxyentidad. Este último encapsula la lógica / criterio para

se:SimulationEngine run(modelConfigFile)

sl:SchedulerLoader dl:DevicesLoader jl:JobsLoader

load() addEntity(proxy) load() addEntity(device) addEvent(CPUChangeEvent) load() addEvent(jobArrivalEvent) addEvent(deviceJoinEvent) fel:SortedSet<Event> removeFirst() eventObject ent:Entity updateClock processEvent(eventObject) :Event createEvent(time=any,entity=proxy.id,type=device_join,data=device) deviceJoinEvent createEvent(time=any,entity=proxy.id,type=job_arrival,data=job) jobArrivalEvent createEvent(time=any,entity=device.id,type=CPU_usage_change,data=CPU_value) CPUChangeEvent loop loop loop [while fel.size > 0] loop

Figura 4.2:Intercambio de mensajes durante la carga y ejecución de un modelo de grilla de SMDs: Diagrama de secuencia UML

anidados dobles, crea todas las entidades de dispositivos, y para cada uno crea y agrega undeviceConnec-

tEventy todos losCPUChangeEventsconfigurados. La inicialización termina con la carga de todos los

trabajos configurados por el objetoJobsLoader. Tenga en cuenta que en cada creación de evento (llama- da de eventocreateEventde la claseEvent) una identificación de entidad, que es única para cada objeto de entidad, se pasa dentro de los argumentos del método constructor de eventos. Dicha identificación de entidad se usa para recuperar la instancia de entidad de la lista de entidades que deben manejar el evento. Por ejemplo, los objetos CPUChangeEventtienen identificación de dispositivo asociado, mientras que

DeviceJoinEventsy JobArrivalEvents tienen asociada la identificación delproxy. Vale la pena señalar

que, durante la inicialización del modelo, el argumento de tiempo de las llamadas acreateEventes, de hecho, instanciado con el hora correspondiente configurada por el modelador. Por ejemplo, si el tiempo de llegada configurado parajobId= 1 es 500 milisegundos, luego el argumento de tiempo de la llamada

createEvent, que devuelve el trabajo correspondiente evento de llegada, se creará una instancia con valor

500.

Antes de entrar en detalles del enfoque de programación de eventos que el motor de ejecución sigue para simular el modelo, es importante destacar que la fase de inicialización, que se realiza automáticamente por el motor, se basa en la configuración de los componentes proporcionada por el modelador. Por fa- vor refiérase a la Tabla 4.1 para obtener una lista de los atributos configurables admitidos actualmente para cada componente. La variabilidad del modelo se soporta principalmente a través de archivos de configuración y, como se dijo, la lógica de programación debe proporcionarse programáticamente.

Una vez que se completa la fase de inicialización, el método de ejecución entra en el ciclo de ejecución del modelo que consiste en consumir repetidamente eventos del conjunto clasificado fel, actualizando el reloj actual a la hora asociado al evento consumido e invocar el método processEventde la entidad asociada al evento. Estos pasos se repiten hasta que el conjunto está vacío. Tenga en cuenta que durante una invocaciónprocessEventlos nuevos eventos se pueden crear y agregar dinámicamente, lo que se hace llamando al métodoaddEventdeSimulationEngine. Cada evento agregado al conjunto Fel se inserta en un orden cronológico, que se realiza por comparando eventos basados en su tiempo asociado.

Ahora, explico cómo los componentes específicos de la capa de componentes de Grid móvil basada en infraestructura interactúan a través de eventos concretos para reflejar la dinámica del sistema. La Figura

Proxy Events in Events out IO Events in Events out Mobile Device Events in Events out ready_to_transfer scheduled_job job_arrival device_join device_left device_status update ready_to_transfer _device_status_update ready_to_transfer _job_output message_transferred battery_level_update CPU_usage_change job_received job_finished job_output

Figura 4.3:Conexiones entre componentes y eventos del modelo: Vista esquemática (notación propia)

4.3 ofrece una visión general esquemática de los eventos procesados y creados por cada componente mientras se simula una Grilla móvil. Las flechas que ingresan por el lado izquierdo de los componentes representan eventos de entrada, es decir, eventos para los cuales el componente proporciona la lógica de manejo. Las líneas que salen de un componente por su lado derecho representan eventos de salida, es decir, eventos que el componente agrega al motor de simulación. Algunos eventos son procesados por el mismo componente que los crea, por ejemplo,battery_update,CPU_usage_changeyjob_finishedse crean y procesado por un componente de dispositivo móvil. Otros eventos son creados por un compo- nente pero procesados por otros componentes: estos son cualquiera de los que salen del lado derecho de un componente y se conectan por el lado izquierdo a un componente diferente. Tenga en cuenta que los trabajos y los mensajes no están presentes en la Figura 4.3 ya que no se modelan como componentes que procesan o crean eventos. En cambio, los trabajos y mensajes son objetos transitorios cuyo estado se actualiza a medida que completan una fase en su flujo a través del sistema. Trabajo los estados se dife- rencian entresubmit,input_transferred,finishedycompleted, mientras que los mensajes se diferencian entre entregado y no entregado. Antes de describir el funcionamiento interno de cada componente, pre- sento la Tabla 4.1, que resume las variables de estado, los contadores de estadísticas y todos los atributos configurables admitidos actualmente del modelo. Los modeladores pueden usar atributos configurables

para variar características de la cuadrícula móvil, por ejemplo, número de nodos, características de los nodos, como capacidad informática, energía rastreos de consumo, rastreos de uso de la CPU, lógica de programación del proxy, etc. Esto es precisamente cómo Los modeladores pueden evaluar exhaustiva- mente el rendimiento de los nuevos criterios de planificación de trabajos propuestos para dispositivos móviles Grids.

Componente Variables de estado y contadores Atributos configurables Device Current battery level, Future battery update,

Current job in execution, Current CPU usage, Current owner CPU usage, Queued jobs, Current battery depletion trace, Last notified status

Computing capability (in MFLOPS), initial battery level, baseline CPU usage trace, baseline battery depletion trace, full CPU usage trace, full battery depletion trace

IO Queued data transfers, Total energy spent in data transferring, data being transferred progress, Current link RSSI, link active

Link RSSI

Proxy Active connected devices, Submitted jobs

Scheduler criterion, list of connected devices

Message Sender I/O end, Receiver I/O end, Data type, Data size, Data, Delivered status

Maximum size

Job Completion status, Execution progress, Device in charge of execution

MFLOP, data input size, data output size, arrival time

Cuadro 4.1:Componentes del modelo de grilla de SMDs con comunicación basada en infraestructura

Los diagramas de actividad UML de las figuras 4.4, 4.5 y 4.6 describen las acciones tomadas por los com- ponentesProxy,IOyDevicecuando se procesan eventos de entrada. El procesamiento de cada evento de entrada es representativo por actividades individuales, con sus propios nodos de inicio y final, y nom- brado como "Process <nombre_de_evento> event". Los diagramas muestran los pasos ejecutados por el componente que desencadenan cambios de estado y/o cambios en estructuras de datos internas. Desde la perspectiva del protocolo de ejecución, el procesamiento de un evento es la secuencia de las llamadas internas que la entidad a cargo de manejar el evento realiza antes de devolver el control a el motor de simulación. Los nodos de acción cuyo nombre comienza con el prefijo "Create_event" representan la salida eventos, es decir, creación y adición de nuevos eventos a la lista de eventos internos del motor de simulación. Nodos con el símbolo de tridente invertido indica nodos de actividad de llamada, cuyo nombre es el nombre de una actividad rodeado por un marco visual.

Cuando el componenteproxyprocesa un eventojob_arrival, actualiza el estado de la instancia de trabajo al valor ’recibido’. Luego se evalúa, de acuerdo al criterio de planificación de trabajos configurado, si el trabajo debe asignarse inmediatamente (planificación en línea) o después de que se cumpla alguna condición, por ejemplo, se llega a un volumen de trabajo recibido determinado (programación por lotes). Las asignaciones de trabajo están representadas por la creación de eventos de tipo ready-to-transfer

scheduled job. El procesamiento de un evento device_status_updateimplica que el la información de

Update job status to submitted

Is scheduler

active? _{Create event}

ready_to_transfer_scheduled_job [yes]

[no] Process job_arrival event

Read device information Process device_status_update event

Update job status to complete Process job_output event

Add device to candidates list Process device_join event

Remove device from candidates list Process device_left event

Process device_status_update event

Figura 4.4:Procesamiento y creación de eventos en el componenteProxy: Diagrama de actividades UML

Los modelos de eventos la falta de información del dispositivo de actualización administrada por la lógica de programación. El procesamiento de un job_output evento desencadena una actualización de estado del trabajo asociado que se establece en ’completado’. El procesamiento de un eventodevice_join

agrega un dispositivo a la lista de dispositivos candidatos que la lógica de programación puede usar para asignar trabajos. Después de actualizar la lista, se obtiene la información de los recursos del dispositivo. Por último, el procesamiento de un evento device_left implica eliminar un dispositivo de la lista de dispositivos candidatos para ejecutar trabajos.

Un componenteIOprocesa eventos que indican la existencia de datos listos para transferir y mensajes transferidos. Para procesar eventos de tipo listo para transferir comoready_to_transfer_scheduled_job,

ready_to_transfer_job_output y ready_to_transfer_device_status_update se realiza una secuencia co-

mún de acciones. La secuencia implica primero verificar si el objeto IO ya está ocupado realizando otra operación de transferencia de datos. Si hay otra operación en progreso, la nueva transferencia de datos se pone en cola, de lo contrario se inicia, lo que desencadena la creación del primer eventomes-

sage_transferred. El momento de tal evento define la demora después del cual el componente IO del

nodo receptor procesa el mensaje. El modelo actual para enviar y recibir mensajes se gestiona trans- ferencia basada en un esquema de cola FIFO (First In First Out). Además, el momento del próximo mensaje es calculado cuando se recibe la hora del mensaje anterior. El procesamiento de un evento

message_transferred implica actualizar primero el nivel actual de la batería del nodo con el consumo

de energía correspondiente asociado a la transferencia del mensaje. Los valores de tiempo y energía se calculan utilizando el tamaño del mensaje y el RSSI del enlace. Estudios empíricos Ding et al. (2013); Rice y Hay (2010); Balasubramanian et al. (2009) muestran una correlación entre el indicador RSSI y el tiempo gastado/energía consumido al transferir datos. Entonces, si el mensaje no pudo ser entregado, es decir, la batería del nodo se agotó, el estado del mensaje se establece en ’no entregado’ y la actividad fi- naliza. De lo contrario, la transferencia la operación continúa actualizando el progreso de la transferencia actual. Si la transferencia se completa, según el tipo de transferencia de un eventojob_received, evento

Process message_transferred event Process ready_to_transfer_scheduled_job event

Queue transferring

Process battery_level_update event Update transferring

progress Could message been delivered? Set success message status [yes] Set failed message status [no] Create event job_received Is data transferring completed? [yes] [yes] Is data a scheduled job? Update job status Dequeue next transferring Create event job_output [no] [yes] Is data a job output? [no] [yes] Is data a device status? Create event device_status_update

Transfer data Is IO busy?

[yes] Create event message_transferred [no] Transfer data Transfer data Process ready_to_transfer_job_output event

Transfer data Process ready_to_transfer_device_status_update event

Transfer data

Create event message_transferred

[no]

Figura 4.5:Procesamiento y creación de eventos del componenteIO: Diagrama de actividades UML

job_outputo eventodevice_status_updatees creado. Las entidades asociadas a esos eventos sonDevice,

ProxyyProxy, respectivamente.

Con respecto a los eventos del componente de dispositivo, el procesamiento de eventos de tipo bat-

tery_level_update activa una actualización del nivel actual de la batería del dispositivo. Después de

realizar esta acción, se verifica si el actualización no significa que la batería se agota. Si no es así, se crea el siguiente evento de actualización del nivel de la batería; de lo contrario, se realiza el apagado del dispositivo. El nivel de batería y el tiempo en el que se suceden los eventosbattery_level_updatetienen relación con un cierto uso de la CPU. Todos estos datos, a su vez, se derivan de un procedimiento de