1

Middleware de Comunicacin para Sistemas Distribuidos de Tiempo

Real en Java

Pablo Daniel Tejera Carballa
Alejandro Alonso
Resumen. Las facilidades e independencia de plataforma de Java han generado un gran inters en la
comunidad de tiempo real. Dicho inters ha sido reflejado en la especificacin RTSJ (Real-Time
Specification for Java), la cual extiende y adapta el lenguaje Java para permitir el desarrollo de
sistemas de tiempo real. Adicionalmente, perfiles RTSJ han surgido para garantizar la predecibilidad
en sitemas de tiempo real crticos. Sin embargo RTSJ y sus perfiles presentan la limitacin de no
introducir facilidades para sistemas distribuidos. Por lo tanto el objetivo de este trabajo es afrontar
dicha limitacin definiendo un nuevo modelo de RMI (Remote Method Invocation) basado en los
principales perfiles de RTSJ. Este trabajo presenta el diseo y la implementacin de RMI-HRT (RMI -
Hard Real-Time) que est enfocado a sistemas de tiempo real crtico con requisitos de alta integridad.
1 Introduccin
Los sistemas empotrados y distribuidos de tiempo
real son cada vez ms importantes para la sociedad.
Su demanda aumenta y se depende de los servicios
que proporcionan. Los sistemas de alta integridad
constituyen un subconjunto de gran importancia. Se
caracterizan por que un fallo en su funcionamiento
puede causar la prdidas de vidas humanas, daos en
el medio ambiente o cuantiosas prdidas econmicas.
La necesidad de satisfacer requisitos temporales
estrictos, hace ms complejo su desarrollo. Mientras
que los sistemas empotrados se expandan en nuestra
sociedad, es necesario garantizar un coste de
desarrollo ajustado mediante el uso tcnicas
adecuadas en su diseo, mantenimiento y
certificacin. En concreto, se requiere una tecnologa
flexible e independiente del hardware.
La tecnologa que se emplea en aplicaciones de alta
integridad como las de avinica, espaciales o
ferroviarias, se beneficia de varias dcadas de
innovacin y enfoques de desarrollo de software
avanzados, que han producido herramientas y
mtodos adecuados. Sin embargo, la situacin actual
presenta retos nuevos que requieren su mejora. La
falta de flexibilidad y el coste de desarrollo de los
sistemas de alta integridad, hace que los
desarrolladores no estn plenamente satisfechos con
las metodologas existentes. El coste de transportar
una aplicacin de una plataforma a otra es elevado.
En muchos casos, el cdigo resultante es dependiente
de las caractersticas especficas del procesador y del
comportamiento temporal y del uso de recursos en la
plataforma de ejecucin.
La evolucin de las redes y paradigmas de
comunicacin, as como la necesidad de mayor
potencia de cmputo y de tolerancia a fallos ha
motivado la interconexin de dispositivos
electrnicos. Los mecanismos de comunicacin
permiten la transferencia de datos con alta velocidad
de transmisin. En este contexto, el concepto de
sistema distribuido ha emergido, como sistemas
donde sus componentes se ejecutan en varios nodos
en paralelo y que interactan entre ellos mediante
redes de comunicaciones.
Un concepto interesante son los sistemas de tiempo
real neutrales respecto a la plataforma de ejecucin.
Se caracterizan por la falta de conocimiento de esta
plataforma durante su diseo. Esta propiedad es
relevante, por que conviene que se ejecuten en la
mayor variedad de arquitecturas, tienen una vida
media mayor de diez aos y el lugar donde se
ejecutan puede variar. El lenguaje de programacin
Java es una buena base para el desarrollo de este tipo
de sistemas.
La popularidad de Java, sus caractersticas y su
independencia de la plataforma le han convertido en
un lenguaje de inters para las comunidades de
tiempo real y de sistemas empotrados. Esta situacin
ha motivado el desarrollo de RTSJ (Real-Time
Specification for Java), que es una extensin del
lenguaje para permitir el desarrollo de sistemas de
tiempo real. Entre la extensiones que se han incluido,
se encuentran las hebras de tiempo real, eventos
asncronos y un modelo de memoria nuevo que
permite evitar o limitar el efecto del recolector de
memoria. Las ventajas potenciales de Java han
motivado su inters en el desarrollo de sistemas de
alta integridad.
El uso de Java en este tipo de sistemas requiere
tcnicas muy estrictas de desarrollo y prueba, as
como el seguimiento de estndares relevantes. La
versin actual de RTSJ incluye caractersticas que no
estn permitidas en el desarrollo de sistemas de alta
integridad, como la creacin dinmica de hebras, el
uso de memoria dinmica o algunas caractersticas de
la orientacin a objetos. El enfoque empleado en
otros lenguajes de programacin ha consistido en la
definicin de un perfil restringido de los mismos que
permita el anlisis esttico de sistemas de alta
integridad que deban ser certificados. HRTJ (Hard
2
Real-Time Java) define uno de stos perfiles, que fue
desarrollado en el marco del proyecto HIJA (High
Integrity Java Applications). Actualmente, se est
creando una especificacin similar en el contexto del
proceso comunitario de Java (JSR-302). Su objetivo
es definir el perfil SCJ (Safety Critical Java) para
crear aplicaciones de alta integridad con Java.
RTSJ no proporciona mecanismos para el desarrollo
de sistemas distribuidos, lo que constituye una
carencia importante, dado que la mayora de los
sistemas actuales y en el futuro sern distribuidos. Se
ha creado un grupo de expertos en sistemas
distribuidos de tiempo real en Java (JSR-50) para
definir abstracciones apropiadas para solucionar este
problema. Sin embargo, en este momento no hay una
especificacin formal de las mismas. El objetivo de
este trabajo es desarrollar un software de
intermediacin de comunicaciones que sea adecuado
para el desarrollo de sistemas distribuidos de tiempo
real crtico con Java.
1.1 Objetivos y Organizacin
El objetivo principal de este trabajo es desarrollar un
middleware de comunicaciones para el desarrollo
sistemas distribuidos de tiempo real crtico. El
objetivo subyacente es allanar el camino para la
certificacin de aplicaciones distribuidas con la
tecnologa Java. El modelo del middleware debe
permitir el uso de herramientas de anlisis para
obtener los tiempos de respuesta y optimizar los
recursos y servir de punto de partida para la
certificacin la certificacin de las aplicaciones que
lo usen. A continuacin se listan las actividades ms
relevantes realizadas:
Definir la lista de requisitos del middleware,
teniendo en cuenta las actuales alternativas y las
recomendaciones industriales, as como, los
requisitos del lenguaje de programacin.
Elegir los protocolos de red ms adecuados para
los objetivos del trabajo.
Determinar el modelo computacional del sistema
y asegurar que el tiempo de respuesta de las
actividades del sistema es analizable
estticamente.
Desarrollo de un prototipo operativo compatible
con las directrices para el desarrollo de sistemas
de alta integridad.
Validacin del prototipo desarrollado. Se deber
comprobar el comportamiento funcional y un uso
predecible de recursos.
En el resto del documento se presenta los principales
aspectos que caracterizan a RMI-HRT. Despus del
estado de la tcnica, la seccin 3 describe el modelo
computacional y la seccin 4 muestra el diseo del
middleware. La seccin 5 aborda la serializacin
predecible y la seccin 6 la validacin en un caso
industrial. Finalmente la seccin 7 describe las
conclusiones.
2 Estado de la Tcnica
2.1 Sistemas de Tiempo Real
Un sistema de tiempo real es aqul en el que la
correccin del sistema depende tanto del valor lgico
de los resultados, como del instante de tiempo en el
que se producen. Dentro de los sistemas de tiempo
real podemos distinguir diversos sistemas, los cuales
pueden ser clasificados en tres tipos diferentes
dependiendo de las causas que producen no respetar
los requisitos de tiempo:
Crticos: Un incumplimiento puede provocar
daos en seres humanos.
Firmes: Una respuesta fuera de plazo es intil
pero el sistema puede seguir funcionando aunque
la calidad de servicio se vea degradada.
Acrticos: una respuesta fuera de tiempo tiene una
validez relativa, pero el sistema sigue operativo.
2.2 RTSJ
RTSJ define un nuevo API con soporte desde la JVM
(Java Virtual Machine). La especificacin ha sido
creada segn las siguientes bases: no aadir
restricciones al entorno de ejecucin de Java,
compatibilidad con los programas de Java, no aadir
extensiones sintcticas ni palabras reservadas y una
ejecucin predecible. Las caractersticas ms
relevantes de RTSJ son:
Objetos planificables y Planificadores: RTSJ define
un modelo de concurrencia basado en un conjunto de
hebras o manejadores de eventos asncronos
(conocidos como objetos planificables). RTSJ
permite utilizar diferentes planificadores, pero el
planificador por defecto est basado en prioridades
con desalojo (28 prioridades como mnimo).
Transferencia asncrona de control: Es una
extensin al mecanismo de interrupcin de hebras de
Java para permitir la entrega de control y el manejo
de excepciones asncronas.
Sincronizacin: El algoritmo por defecto para evitar
una inversin de prioridad no acotada es el protocolo
de herencia de prioridad, aunque el protocolo de
techo de prioridad puede usarse bajo demanda.
Memoria: Se ha introducido un modelo nuevo de
memoria para evitar la incertidumbre que produce el
recolector de basura. Define nuevos tipos de
memoria:
Memoria Inmortal: contiene objetos que nunca
sern fragmentados o recolectados por el
recolector de basura y pueden ser compartidos por
diferentes objetos planificables. Los objetos en
memoria inmortal permanecern hasta el final de
la aplicacin.
Memoria Restringida (scoped): tiene un tiempo de
vida limitado. Los objetos ubicados en memoria
3
restringida permanecern ah hasta que no hayan
objetos planificables con acceso a los objetos
ubicados en dicha memoria. En ese momento
todos los objetos en la memoria restringida
pueden ser liberados.
Hay definidos otros tipos de memoria que
permiten tener acceso a memoria fsica.
Tiempo y Temporizadores: Se definen clases
adicionales para representar tiempos relativos o
absolutos con alta resolucin. A cada objeto que
representa un tiempo se le asocia un reloj de tiempo
real.
2.3 Requisitos
Con el fin de comparar diferentes middlewares se ha
definido un conjunto de requisitos relacionados con
las necesidades y las funciones de los sistemas de alta
integridad y sistemas distribuidos:
Gestin de hebras: Si el sistema contiene varias
hebras (tareas), cada hebra debe ser analizada de
manera independiente y la concurrencia debe ser
modelada y analizada para demostrar que las
situaciones peligrosas tales como: interbloqueo,
perdida de plazos, etc, no pueden ocurrir.
Adems, algunos modelos y tcnicas de anlisis
imponen una serie de restricciones sobre el
modelo de concurrencia, por ejemplo: la hebra
debe ser creada de forma esttica, y el patrn de
activacin debe ser peridico o espordico.
Comportamiento temporal predecible: Debe ser
posible calcular estticamente el tiempo de
respuesta ms desfavorable de las actividades,
para poder garantizar el correcto comportamiento
temporal del sistema. El middleware forma parte
de la aplicacin distribuida, por lo que debe ser
analizable y tener un comportamiento predecible.
Gestin de memoria: En STRC, la asignacin y
liberacin de memoria puede provocar latencias
impredecibles, por lo que gestin de memoria
debe asegurar que los objetos se crean y eliminan
de manera adecuada. Se debe evitar la creacin
dinmica de objetos debe ser evitada y
proporcionar mecanismos para crear objetos
temporales y mantener un estado entre diferentes
fases de la aplicacin.
Uso de memoria predecible: Debe ser posible
determinar una cota mxima a la capacidad de
memoria necesaria. Disponer de mecanismos para
su calculo tiene un alto valor aadido.
Gestin de conexiones: Una de las tareas ms
importantes de un middleware es administrar las
conexiones entre los nodos que forman el sistema
distribuido. Se debe evitar la creacin dinmica
de conexiones, por los que e deben establecer
durante la inicializacin del sistema y permanecer
activas hasta el final de la aplicacin. Adems, no
se deben usar conexiones multiplex a travs de
una conexin para evitar la generacin de
latencias.
Uso de red predecible: El protocolos de
comunicacin debe permitir el clculo del tiempo
de respuesta de cada mensaje en la red. Para ello,
se debe determinar estticamente el tamao
mximo de los mensajes a trasmitir.
Control sobre los parmetros de conexin:
Muchas aplicaciones de tiempo real requieren
manipular la configuracin y controlar el
protocolo de red. Por lo tanto, el middleware debe
definir una interfaz o un mecanismo para
seleccionar las propiedades de los protocolos.
Parmetros de activacin: Los parmetros de
activacin de las hebras o los manejadores de
eventos deben ser independientes de la
implementacin del middleware. Si el
planificador est basado en prioridades fijas, el
middleware debe proporcionar un mecanismo
para especificar las prioridades de todas las hebras
que forman la aplicacin distribuida. De igual
forma, si la red admite prioridades, el
middleware debe incluir mecanismos para su
asignacin a los mensajes en la red.
Serializacin predecible: Cuando un objeto va a
ser enviado a travs de una red, un procedimiento
de serializacin traduce el objeto especificado en
un flujo lineal de bytes. Del mismo modo, un
procedimiento de deserializacin construye un
objeto desde un flujo lineal de bytes. Las
implementaciones ms comunes usan algoritmos
recursivos, polimorfismo y reflexin, por lo que
es demasiado complejo determinar el WCET y el
uso de los recursos. Un middleware para STRC
debe incluir una serializacin predecible.
Evitar caractersticas orientadas a objetos:
Algunas de las funcionalidades de los lenguajes
orientados a objetos (OO) hacen que sea
complicado calcular: el cmputo del WCET y el
clculo del uso de memoria. Por esta razn, se
deben evitar.
Mecanismos de recuperacin de errores: Los
sistemas deben incluir mecanismos de deteccin
recuperacin de errores funcionales y temporales.
Interoperabilidad: Es habitual que un sistema
coexistan tareas con y sin requisitos de criticidad.
Es conveniente incluir mecanismos para la
interoperabilidad entre estos tipos de tareas.
Perfil de tiempo real crtico de Java: El
middleware debe utilizar un subconjunto de Java
que permita lograr un alto nivel de predecibilidad
y permitir el uso de tcnicas de verificacin.
Comportamiento funcional adecuado:
Obviamente, el comportamiento lgico debe ser
correcto en cuanto a las funcionalidades bsicas.
2.4 Trabajos Relacionados
Los middlewares ms relevantes (RT-CORBA
[7][8][9], PolyORB [10], RT-GLADE [11], DRTSJ
[5], DREQUIEMI [12] y RMI-QoS [13]) fueron
comparados de acuerdo a la lista de requisitos. La
tabla siguiente muestra los resultados.
4
Tabla 1: Comparacin de alternativas
Cada middleware fue analizado de acuerdo con los
requisitos asignando un valor de 0 a 4 (algunos
campos tienen un "-" cuando la informacin no est
disponible). La ltima fila de la tabla muestra que tan
bien cada uno de los middlewares cumplen todos los
requisitos principales. La ltima columna contiene
los porcentajes que representan que tan bien cada
requisito es tratado en los principales middlewares. El
anlisis revela que no hay ningn middleware en el
cual todas las caractersticas se cumplan en un buen
nivel. Ninguno de ellos alcanza el sesenta por ciento
de los requisitos. De acuerdo con la tabla, RT-
CORBA, RT-GLADE y DREQUIMI son los
mejores. DRTS es el peor con un 34,62 por ciento.
En promedio, slo el 50 por ciento de las necesidades
son satisfechas por las actuales alternativas.
La tabla est ordenada de acuerdo a la ltima
columna en orden descendente con el propsito de
identificar los requisitos que son los ms o los menos
tratados. Por lo tanto, las primeras filas demuestran
que todas las soluciones incluyen un manejo de
hebras adecuado. La mayora de ellos permite
especificar los parmetros de activacin, como la
prioridad y el plazo, y tienen una buena gestin de
conexiones. La interoperabilidad es lograda slo en
RT-CORBA y PolyORB. La gestin de memoria
presenta carencias en todas las soluciones. Requisitos
tales como: control sobre las conexiones,
mecanismos de recuperacin de errores y
conformidad con el perfil de tiempo real crtico de
Java solo se logran en pocos middlewares.
Finalmente, las ltimas filas revelan que hay falta de
predecibilidad en el uso de recursos tales como la
memoria y la red. Con casi todos los middlewares no
es posible calcular la cantidad de memoria utilizada
o cuanto ancho de banda es necesario para enviar los
mensajes por la red. Adems, la mayora de las
implementaciones usan algoritmos complejos o
caractersticas OO que dificultan los anlisis
temporales.
2.5 RMI
RMI es el modelo de objetos distribuidos de Java
que permite invocar un mtodo de un objeto que est
sobre otra maquina virtual. Su principal propsito es
permitir el desarrollo de aplicaciones distribuidas con
el mismo modelo de programacin que en sistemas
centralizados. RMI es una infraestructura poderosa
para la construccin de aplicaciones distribuidas
cliente - servidor. RMI emplea TCP / IP y
serializacin de objetos para serializar y deserializar
los argumentos y valor de retorno de los mtodos
remotos. Tambin utiliza los protocolos http y ftp
para el intercambio de clases.
El servidor crea un conjunto de objetos remotos, los
hace accesibles, y espera por los clientes.
Normalmente, el cliente recibe una o ms referencias
remotas a los objetos en el servidor mediante un
registro que almacena par de referencia remota -
objeto remoto. Con las referencias el cliente llama a
los mtodos que se encuentran en el servidor. El
cliente, el servidor y el registro forman la aplicacin
de objetos distribuidos, y RMI es el middleware que
proporciona servicios para el desarrollo de
aplicaciones de objetos distribuidos.
RMI es adecuado para sistemas distribuidos de
tiempo real crtico dado que provee la funcionalidad
requerida y puede ser analizable.
2.6 Limitaciones en RMI
Java RMI presenta algunas limitaciones en sistemas
de tiempo real:
El uso de tecnologas tales como: reflexin,
caractersticas OO y recursividad hacen que sea
muy difcil estimar el WCET y el uso de recursos.
El modelo de memoria no es apropiado. Las
hebras, las conexiones, los objetos remotos, etc.
se crean dentro del montculo. Por lo tanto, la
ejecucin de las invocaciones remotas sufren los
efectos del recolector de basura y los objetos se
crean de forma dinmica.
En las actuales implementaciones de RMI las
conexiones se generan de forma dinmica.
Cuando un cliente quiere enviar una invocacin,
primero crea una nueva conexin con el servidor.
Es difcil estimar el tiempo y los recursos son
necesarios para establecer la conexin.
Implementaciones de RMI (por ejemplo, GNU
Classpath) crean hebras dinmicamente, lo que no
es adecuado en sistemas de tiempo real crtico.
Uso de algoritmos de serializacin no predecibles.
El uso de recursos es completamente transparente,
y por lo tanto no es configurable. RMI no permite
al programador especificar los parmetros de red.
En RMI no se ha teniendo en cuenta los
parmetros de tiempo real. No se consideran los
parmetros de planificacin o de activacin del
cliente o del servidor.
RMI no es garantiza una calidad de servicio.
5
3 Modelo Computacional
3.1 Modelo de Anlisis Centralizado
El modelo de anlisis para cada nodo del sistema
distribuido est basado en el planificador de
prioridades fijas con desalojo. Donde a cada hebra se
le asigna una prioridad durante la fase de diseo y
durante la ejecucin, la hebra ejecutable con la mayor
prioridad es ejecutada primero. La planificacin
dentro la misma prioridad sigue el orden FIFO. El
acceso a los recursos compartidos es mediante el
protocolo de techo de prioridades. Es una tcnica
madura que permite calcular estticamente el tiempo
de respuesta de cada hebra y la planificabilidad de
todo el sistema.
3.2 Modelo de Anlisis Distribuido
El modelo de anlisis para toda la aplicacin
distribuida est basado en el modelo lineal, definido
en [14]. El sistema es compuesto de un conjunto de
transacciones, ver figura 1. Cada transaccin est
compuesta por un conjunto de acciones ordenadas y
es caracterizado por un patrn de activacin
peridico o espordico. Una accin puede ser una
hebra ejecutado una porcin de cdigo o un mensaje
enviado por el medio de comunicaciones. Una accin
es activada por la previa (excepto por la primera
donde el tiempo de activacin es igual al tiempo de
activacin de la transaccin) y activa a la siguiente.
El anlisis del tiempo de respuesta se basa en los
peores casos de tiempo de transmisin y ejecucin.
Aunque este modelo es adecuado para varios
sistemas, el trabajo [15] extiende el enfoque para
soportar transacciones que no son lineales, tales como
situaciones donde una accin puede activar varias
acciones.
Figura 1: Modelo Lineal

3.3 Perfil de tiempo real critico de Java
El modelo computacional y la implementacin estn
basados en el perfil HRTJ (un subconjunto de RTSJ
definido dentro del proyecto HIJA) y la
especificacin SCJ. Estos perfiles eliminan las
caractersticas que implican una gran sobrecarga y
semntica compleja, para proveer un comportamiento
predecible.
Cada aplicacin ejecuta en dos fases: la fase de
inicializacin (donde se llevan a cabo todas las tareas
que no son de tiempo real) y la fase de misin
(donde la propia funcionalidad de la aplicacin es
ejecutada). Todos los objetos que son necesarios
durante toda la vida de la aplicacin se crean durante
la fase de inicializacin en memoria inmortal y nunca
son eliminados. Cada objeto planificable tiene su
propia memoria restringida y durante la fase de
misin los objetos se crean en memoria restringida de
los objetos planificables. Entre cada ejecucin del
objeto planificable la memoria privada restringida se
libera. No se permiten reas de memoria restringida
anidadas ni que sean compartidas por varias hebras.
El sistema est compuesto por un conjunto de objetos
concurrentes gestionados con un planificador basado
en prioridades estticas y con expulsin. Los objetos
pueden ser hebras o manejadores de eventos, y deben
tener parmetros de activacin peridicos o espordi-
cos. Para prevenir una inversin de prioridades
ilimitada, se utiliza el protocolo de techo de prioridad
para todos los objetos con bloques o mtodos
sincronizados. Las transferencias asncronas de
control estn prohibidas ya que dificultan el anlisis
y la maquina virtual.
3.4 Extensiones al perfil para sistemas
distribuidos
Para sistemas distribuidos el modelo de
comunicaciones est basado en invocaciones
remotas. En el caso ms simple, figura 2, dos flujos
de control (o dos hebras), uno como cliente y otro
como servidor, componen el modelo computacional.
El cliente llama a mtodos sobre un equipo remoto.
Un servidor obtiene las invocaciones, ejecuta el
mtodo apropiado y retorna la salida del mtodo.
Como se ve en la figura las invocaciones pueden ser
sncronas cuando el cliente invoca un mtodo remoto
y espera por la respuesta del servidor. O asncronas
cuando el cliente no espera por la respuesta. En una
aplicacin ms compleja, puede formarse una cadena
de invocaciones donde el servidor ejecuta tambin el
rol de cliente.
Figura 2: Modelo Computacional
En este tipo de sistemas, es necesario emplear un
protocolo de comunicaciones con comportamiento
temporal predecible. Los mensajes deben cumplir sus
plazos de repuesta y estos deben ser verificados por
construccin o analticamente. Hay varias redes que
ofrecen estas garantas, con diferentes enfoques:
6
Dirigidas por Tiempos (redes de este tipo
soportan el protocolo TTP [16]): Los mensajes
son enviados en precisos instantes de tiempo,
definidos en unas tablas. La construccin de estas
tablas permiten garantizar cierto ancho de banda y
limitar el peor caso de entrega de un mensaje.
Dirigidas por Prioridades (ejemplo: redes CAN
[17]): Las prioridades se asignan a los mensajes y
se usan para decidir cual es el orden de envi de
mensajes. Hay mtodos analticos para calcular el
peor tiempo de entrega de mensajes.
Enlaces Virtuales: (por ejemplo: redes AFDX
[18]): Estas redes aseguran a cada enlace un cierto
ancho de banda y limitan la variabilidad (jitter)
que pueden sufrir los enlaces virtuales.
Algunos aspectos del modelo de invocaciones
remotas no son apropiados, comos los servicios web,
el servidor de nombre y el recolector de basura
distribuido hacen complicado el anlisis. Adems, el
nmero de invocaciones en cada activacin tiene que
ser conocido y acotado. Con estas restricciones las
invocaciones remotas son analizables.
3.5 Requisitos adicionales
Hay dos tipos de requisitos adicionales, los que
apuntan a la flexibilidad del sistema y los que buscan
predecibilidad. Flexibilidad:
El servidor debe ser capaz de brindar varios
servicios remotos a uno o varios clientes.
El cliente debe ser capaz de acceder a uno o
varios objetos remotos
El servidor debe ser capaz de manejar diferentes
clientes de forma concurrente.
(tanto los del cliente as como los de la red y los del
servidor) deben ser definidos y fijados antes de la
ejecucin de los mtodos. Ejemplos: patrones de
activacin, prioridades de las hebras, ancho de bando
o prioridades del medio de comunicacin.
4 Diseo del middleware RMI-HRT
4.1 Referencias remotas
En RMI, el concepto de variable de referencia de
Java se extiende a las aplicaciones distribuidas como
referencia remota. Una aplicacin puede utilizar las
referencias para invocar mtodos en objetos locales o
referencias remotas para invocar mtodos en objetos
remotos. La referencia remota contiene: la direccin
IP, un puerto TCP, un identificador de objeto, y otros
parmetros necesarios para invocar mtodos en un
objeto remoto especfico. La mayora de los
parmetros se refieren a donde el objeto remoto se
encuentra, y cualquier referencia remota a in objeto
incluye los mismos parmetros. Cuando un cliente
utiliza una referencia remota, los parmetros se
utilizan para crear una nueva conexin con el
servidor. A pesar de que la referencia contiene varios
parmetros, es independiente de la conexin y el
cliente. Por esta razn, puede ser compartida por
varios clientes.
En RMI-HRT, cada referencia remota a un objeto
remoto se asocia con todos los recursos necesarios
para manejar todas las solicitudes invocadas por
medio de la referencia. Cada referencia se asocia
tambin con los parmetros de tiempo real que debe
el cliente, as como el servidor y en la red. Adems,
RMI-HRT introduce el concepto de creacin de
referencias. Es el proceso por el cual el cliente y el
servidor interactan para asignar recursos a las
referencias. Se trata de la creacin de una nueva
conexin y recursos tales como: hebras y reas de
memoria. Todas las referencias en el sistema tienen
que ser creadas antes de que los clientes puedan
llamar a los mtodos remotos.
Este enfoque permite a la aplicacin especificar todos
los parmetros de los recurso. Una vez que los
recursos estn reservados, no se puede cambiarlos.
Cada referencia tiene que tratar con sus parmetros y
sus recursos hasta el final de la aplicacin. Si un
cliente quiere hacer invocaciones diferentes sobre el
mismo objeto remoto con diferentes parmetros, es
necesario tener diferentes referencias.
Las referencias ya no son genricas, por que
representan a un cliente, un servidor, los parmetros
de tiempo real, las hebras y las reas de memoria. Por
tano, no pueden ser compartidos por varios clientes.
La referencia es el medio bsico para llamar a
mtodos especficos de un determinado objeto remoto
con atributos de tiempo real fijos.
4.2 Modelo de hebras en RMI-HRT
El modelo utilizado por RMI contiene slo una fase
en la que un servidor siempre espera nuevas
conexiones. Cuando se crea una conexin nuevas, se
crean las hebras necesarias para manejar las
invocaciones que llegan a travs de las nuevas
conexiones. La asignacin de recursos y la ejecucin
sucede al mismo tiempo. De acuerdo con la
especificacin de RMI, las implementaciones pueden
utilizar un mecanismo arbitrario de hebras para el
manejo de invocaciones ya que los requisitos
temporales no se consideran. RMI-HRT define dos
fases y un mecanismo de hebras especfico para
garantizar un comportamiento temporal adecuado,
que es compatible con el modelo computacional.
Un enfoque comn es incluir a dos hebras (llamadas
Acceptor y Handler) para ejecutar las invocaciones
en el lado servidor, como se muestra en la figura 3. El
Acceptor acepta nuevas peticiones. Normalmente,
crea una nueva conexin a nivel de red y del
middleware. Recibe nuevas solicitudes y las entrega
al Handler, que realiza la ejecucin del mtodo. En
algunos casos, el Handler se crea a peticin del
Acceptor. En otros casos, el Handler se toma de un
conjunto de hebras ya creadas.
7
Figura 3: Modelo de hebras genrico
Con este enfoque, todas las invocaciones nuevas se
tratan con los mismos parmetros de planificacin y
la primera invocacin en llegar ser la primera en ser
tratada. Por lo general, el Acceptor tiene la mxima
prioridad para evitar la inversin de prioridades
(invocaciones de prioridad alta deben desalojar a
invocaciones de baja prioridad en curso). Sin
embargo, este enfoque tiene la desventaja de
desalojar a una invocacin de prioridad media en
proceso (un Handler) para aceptar una nueva
invocacin que podra tener una prioridad baja.
RMI-HRT tambin se basa en dos hebras: (Listener y
Handler). Como se muestra en la figura 4, el Listener
es el encargado de crear las referencias remotas
durante la fase de inicializacin. Esta operacin
supone la creacin de una nueva conexin y un nuevo
Handler. En la fase de misin, el Handler es el
encargado de aceptar y ejecutar las invocaciones
remotas con los parmetros asociados de
planificacin.
Figura 4: Modelo de hebras en RMI-HRT
En RMI-HRT, la inversin de prioridades se evita por
que las invocaciones de prioridad media no sern
desalojadas por una invocacin de baja prioridad. En
otras palabras, el Handler de ms alta prioridad se
ejecuta en primer lugar y sin interrupciones.
RMI-HRT no requiere la creacin de hebras en el
lado del cliente para manejar las llamadas. La hebra
que invoca el mtodo remoto, ejecuta el cdigo que
enva la solicitud y espera una respuesta. RMI-HRT
incluye tambin llamada asincrnica. Se modifica el
flujo de control habitual y se permite al cliente llevar
a cabo otras tareas mientras el servidor procesa la
llamada remota. Sin embargo, RMI-HRT permite este
tipo de operaciones nicamente cuando el mtodo
remoto no devuelve un valor de retorno.
4.3 Fase de inicializacin
En la fase de inicializacin se crean y se reservan los
recursos, de acuerdo a los parmetros que describen
la configuracin del sistema. Por lo tanto, el cliente y
el servidor interactan para reservar recursos tales
como: conexiones, hebras y reas de memoria. La
Figura 5 describe las tareas llevadas a cabo durante la
fase de inicializacin:
1. Cuando la aplicacin del servidor se inicia, la
hebra que se encarga de llevar a cabo la
inicializacin es ejecutado para crear los objetos
utilizados por la aplicaciones, entre ellos, los
objetos remotos. Cuando un objeto remoto es
creado y exportado, RMI-HRT lleva a cabo
varias tareas:
Figura 5: Fase de Inicializacin
Las clases de configuracin y todas las clases de
RMI-HRT (las utilizadas por el servidor) se
cargan en memoria (esta tarea se ejecuta slo una
vez, cuando el primer objeto remoto es creado).
Las clases de serializacin se cargan en la
memoria inmortal.
El objeto remoto se asocia a un identifcado, que
se usa en RMI-HRT para obtener la configuracin
de los parmetros de tiempo real y los parmetros
de red correspondientes.
RMI-HRT carga la clase del esqueleto en la
memoria. Una instancia del esqueleto se utiliza
para invocar el proceso de serializacin y el
mtodo remoto correspondiente.
Con los parmetros de red, RMI-HRT configura
el protocolo de red subyacente para aceptar
nuevas conexiones.
Un objeto planificable (Listener) se crea para
recibir y manejar el proceso de creacin de
referencias.
2. En el lado del cliente, un inicializador cliente
crea un objeto planificable asociado a una
memoria restringida, y una referencia remota
para llevar a cabo la aplicacin cliente. Cuando
se crea una referencia remota un conjunto de
tareas se llevan a cabo:
8
La configuracin y todas las clases de RMI-HRT
se cargan en memoria (esta tarea se ejecuta slo
una vez, durante la creacin de la primera
referencia remota). Adems, las clases de
serializacin se cargan en la memoria inmortal.
RMI-HRT carga el suplente (stub) y se crea una
instancia (la referencia utilizada para la aplicacin
cliente es una referencia a un suplente).
Con los parmetros de red, una conexin entre el
servidor y el cliente es establecida. Mediante
algunos mensajes los parmetros no funcionales
son propagados desde el cliente hasta el servidor
y vice versa.
El Listener se encarga de asociar un nuevo objeto
planificable (Handler) a la nueva conexin, que
se encargar de tratar las llamadas recibidas a
travs de la conexin (referencia). El Listener
tambin crea la memoria restringida utilizada por
el Handler.
A partir de este momento los recursos han sido
asignados, y el cliente puede utilizar la referencia
para invocar mtodos remotos.
4.4 Fase de misin
En la fase de la misin, los recursos ya han sido
reservados, por lo tanto, los clientes llevan a cabo las
invocaciones remotas y el servidor las procesa. La
Figura 6 describe las actividades llevadas a cabo
durante la fase de misin:
Figura 6: Fase de misin
1. El cliente inicia la invocacin remota llamando a
un mtodo auxiliar del suplente, con la misma
signatura que el mtodo remoto.
2. El suplente serializa los argumentos del mtodo
mediante las clases apropiadas.
3. La solicitud se transmite por la red. Se envan
uno o ms mensajes, dependiendo del tamao de
la solicitud y la implementacin del propio
protocolo. Si la solicitud representa una
invocacin asncrona, el suplente devuelve el
control al cliente. En caso contrario, espera la
respuesta.
4. En el lado del servidor, cuando se recibe una
nueva invocacin, se activa el Handler. ste
llama al mtodo correspondiente del esqueleto,
para extraer los argumentos de la solicitud
usando las clases de serializacin.
5. El esqueleto tambin es responsable de invocar
el mtodo remoto.
6. El esqueleto invoca las clases de serializacin
serializar el valor de retorno. RMI-HRT
compone la respuesta con un encabezado fijo y
el valor de retorno. Para detectar posibles
errores, la respuesta se almacena en un buffer
intermedio antes de enviar el mensaje.
7. Si la invocacin es sncrona, el Handler enva la
respuesta al cliente y queda a la espera de nuevas
invocaciones.
8. En una invocacin sncrona, el suplente llama a
las clases de serializacin para obtener el valor de
retorno, y pasa retorna el control a la aplicacin.
4.5 Gestin de errores
RMI-HRT incluye mecanismos para que la aplicacin
adopte medidas en caso de posibles errores. RMI-
HRT gestiona las excepciones y controla los tiempos
de ejecucin. Se lanza una excepcin, cuando no se
cumple el plazo, o cuando el tiempo de ejecucin es
superado. RMI-HRT permite a la aplicacin llevar a
cabo acciones correctivas o conducir el sistema a un
estado seguro.
La figura 7 muestra la interaccin entre aplicaciones
y el RMI-HRT. Si una excepcin se produce cuando
un mtodo remoto se est ejecutando en el servidor,
el Hander enva una respuesta al cliente notificando
la excepcin, llama al mtodo catchException, y
restablece todos las variables y los bferes internos.
Al final de la operacin, el Handler puede de recibir
nuevas peticiones del cliente. Sin embargo, la
aplicacin es quien debe determinar si eliminar el
objeto remoto o parar un Handler determinado (una
referencia determinada).
Figura 7: Gestin de errores
Cuando el Handler no cumple su plazo o su mximo
tiempo de ejecucin (coste en RTSJ) durante la
ejecucin del mtodo remoto, se invoca a
missDeadline o a missCost Estos mtodos permiten a
la aplicacin las acciones necesarias para tratar estos
eventos. Aunque RTSJ no permite dejar un hilo
activo, la aplicacin puede tomar medidas para
reducir el consumo de CPU. El controlador ejecuta el
mtodo catchException, mientras que missDeadline y
9
missCost las ejecutan manejadores de eventos
asociados con el Handler: MissHandler y
OverrunHandler respectivamente.
En el lado cliente, las excepciones son manejadas al
igual que con RMI, por lo tanto, la aplicacin cliente
puede capturarlas y manejarlas. Se emplean
temporizadores para detectar un comportamiento
temporal anmalo. Por ejemplo, cuando se produce
un error inesperado en el servidor, el temporizador
desbloquea el cliente. El valor del temporizador es el
tiempo de respuesta de extremo a extremo de la
invocacin, calculado analticamente.
4.6 Interfaz de red
La figura 8 muestra cmo RMI-HRT asla la parte
dependiente de la red en mdulos para soportar
diferentes protocolos y que el middleware sea
independiente de la red. La configuracin del sistema
es responsable de definir qu mdulo ser utilizado
para cada referencia remota.
Figura 8: Mdulos de red
RMI-HRT supone que los mdulos de red encapsulan
protocolos de tiempo real, donde el tiempo de
transmisin est acotado y puede ser analizado.
Adems, RMI-HRT supone que los mdulos de red
tienen un comportamiento orientado a conexin y se
garantiza la entrega de mensajes. Por lo tanto, RMI-
TRH no tiene que encargarse de funciones tales
como: la retransmisin de mensajes, algoritmos de
gestin de congestin, etc.
Se ha definido una interfaz de red para especificar las
comunicaciones entre el ncleo de RMI-HRT y el
mdulo de red. En la figura 9, podemos ver los cinco
grupos de primitivas.
Figura 9: Interfaz de Red
1. El primer grupo tiene como objetivo crear
conexiones entre el cliente y el servidor.
2. RMI-HRT asume que el nombre de computador
est asociado con los parmetros de red (en
muchas redes el nombre del host est asociada
con una direccin IP). Por lo tanto, el mdulo de
red debe proporcionar a RMI-HRT este nombre.
3. El tercer grupo introduce el concepto de stream,
que es una secuencia de bytes. Son una
abstraccin que permiten enviar o recibir
mensajes a travs de una red.
4. El cuarto grupo es el encargado de proporcionar
un mecanismo simple para leer y escribir bytes
en el stream.
5. Finalmente, el ltimo grupo slo incluye una
primitiva para cerrar las conexiones.
RMI-RHT gestiona estas primitivas sin saber qu
protocolo de red es implementado por el mdulo de
red. Los tres primeros grupos de primitivas se
invocan durante la fase de inicializacin para crear
las conexiones y los streams asociados. En la fase de
la misin, RMI-HRT emplea primitivas como read o
write para intercambiar mensajes. Al final de la
aplicacin o cuando un objeto remoto es eliminado,
se ejecuta la primitiva close para liberar la conexin y
sus recursos.
El servidor utiliza las primitivas accept y
createServerHrtSocket para esperar a conexiones
nuevas. La primitiva createServerHrtSocket da la
orden al mdulo de red para prepararse para recibir
nuevas conexiones y la primitiva accept da la orden
de esperar y aceptar nuevas conexiones. El cliente
tiene que usar la primitiva createHrtSocket para crear
una conexin con el servidor. Tanto la primitiva
createHrtSocket y accept requieren dos parmetros
importantes: el mximo tamao de la solicitud y el
mximo tamao de la respuesta. Estos valores se
usan para establecer buffers internos.
Las primitivas getOutputStream y getInputStream
permiten obtener un stream de salida y de entrada de
una conexin especfica. Las primitivas write y flush
operan sobre un stream de salida, y las primitivas
read, available y reset operan sobre un stream de
entrada. RMI-HRT supone que la escritura no
bloquea la hebra de tiempo real y los valores se
almacenan en un buffer interno. Por medio de la
primitiva flush RMI-HRT solicita al mdulo de red
que enve los datos por la red. El modelo requiere una
implementacin predecible de la primitiva flush, con
un tiempo de transmisin limitado.
La primitiva read obtiene una secuencia de bytes
desde el stream de entrada. Cuando el stream est
vaco, la hebra de tiempo real que realiza la llamada
se bloquea hasta que el stream tenga datos. En el lado
servidor, este mecanismo es adecuado ya que el
servidor debe esperar de forma indefinida por nuevas
solicitudes. Sin embargo, el cliente debe esperar un
perodo corto de tiempo por la respuesta. La primitiva
10
available permite a RMI-HRT saber cuntos bytes
estn disponibles en el flujo de entrada.
4.7 HRT-JRMP
La especificacin de RMI define un protocolo de
conexin conocido como JRMP (Java Remote
Method Protocol) que establece un formato estndar
para el intercambio de peticiones y respuestas. El
protocolo es flexible, ya que permite enviar mensajes
con diferentes protocolos. Por ejemplo, el protocolo
HTTP no permite conexiones directas, pero se puede
utilizar para encapsular invocaciones. Adems, JRMP
permite multiplexar varias conexiones en una. Estas
propiedades permiten ampliar las situaciones en las
que se puede emplear RMI, pero complica el anlisis
de tiempos de respuesta. Por otro lado, este protocolo
tiene algunas caractersticas que reducen su
flexibilidad. Por ejemplo, JRMP no permite el
intercambio de parmetros no funcionales entre el
cliente y el servidor y fue desarrollado
principalmente para el protocolo TCP / IP.
Aunque algunos middleware utilizan el protocolo
JRMP y aaden los parmetros no funcionales como
argumento, este trabajo propone HRT-JRMP (Hard
Real Time - JRMP), un subconjunto de JRMP
adaptado a RMI-HRT y donde las fases de
inicializacin y la misin estn claramente definidas.
Adems, el HRT-JRTMP es independiente del
protocolo de red subyacente.
De acuerdo con JRMP, cuando la aplicacin requiere
un flujo simple los mensajes son envueltos en el
protocolo StreamProtocol. Por lo tanto, el protocolo
StreamProtocol es extendido para definir el protocolo
HrtStreamProtocol.
La figura 10 muestra los mensajes intercambiados en
la fase de inicializacin para establecer una conexin.
El cliente inicia la negociacin enviando un mensaje;
el servidor debe reconocer la negociacin mediante el
envo de un ServerIdentifier (el nombre del nodo del
servidor). El cliente debe responder con un
ClientIdentifier, un hash (de la interfaz del suplente),
y un conjunto de parmetros no funcionales. Con el
hash, el servidor puede verificar que suplente del
cliente se corresponde con el esqueleto. Si no
corresponde, el servidor enva un mensaje con un
cdigo de error y la excepcin correspondiente.
Este mecanismo permite al cliente propagar sus
requisitos y al servidor confirmarlos o actualizarlos.
La implementacin sabe que todos los parmetros
estn disponibles en archivos de configuracin, por lo
que se envan referencias a la configuracin (nombre
de la referencia) como parmetros no funcionales.
Figura 10: HRT-JRMP: Fase de inicializacin
La figura 11 muestra la fase de la misin. El cliente
puede enviar solicitudes basadas en la versin 1.1 de
RMI. El nmero de campos se ha reducido a tres: un
valor que representa un mensaje de llamada, un
nmero que representa el mtodo que se invoca
(asignado por rmic-hrt), y la lista de argumentos. No
son necesarios parmetros par identificar el objeto
remoto, dado que cada referencia, conexin y
Handler hacen referencia al mismo. El hash tambin
fue eliminado ya que se envan slo una vez en la
fase de inicializacin.
Figura 11: HRT-JRMP: Fase de misin
La respuesta tiene tres campos: un valor que
representa un mensaje de retorno, un cdigo de
retorno (un retorno normal o excepcional), y el valor
de retorno o la excepcin. Con este nuevo protocolo,
la tasa entre el tamao de los datos (en bytes) y el
nmero de bytes enviados a travs de la red en la fase
de la misin se increment en un porcentaje
significativo.
4.8 Gestin de memoria
La figura 12 muestra los componentes y los tipos de
memorias que interactan durante la ejecucin del
mtodo remoto en el cliente. RMI-HRT asume que la
hebra del cliente entra en su memoria restringida
(CSM) antes de invocar a un mtodo remoto. Por lo
que todos los objetos temporales son almacenados en
dicha memoria, y se eliminarn en el momento que la
hebra del cliente tome la iniciativa de abandonar la
memoria. La aplicacin cliente puede utilizar objetos
en la memoria inmortal (COI) o crear nuevos objetos,
11
tanto en la memoria inmortal (COI) como en la
memoria de restringida (COS).
Figura 12: Gestin de memoria en el cliente
La solicitud de la invocacin remota no consume
memoria restringida, la cabecera y los datos son
almacenados en un buffer dentro de la memoria
inmortal (B1). RMI-HRT reutiliza objetos en
memoria inmortal. A pesar de que la respuesta
tambin se almacena en otro buffer en la memoria
inmortal (B2), el proceso de deserializacin
reconstruye el valor de retorno (ReturnValue) dentro
de la memoria restringida (CSM). Adems, algunos
mdulos de red necesitan crear objetos temporales
(TemporaryObjects). La memoria restringida tiene
que ser lo suficientemente grande para contener todos
los objetos temporales creados por la aplicacin
cliente, el valor de retorno y los objetos creados por
el mdulo de red. Si el cliente quiere mantener el
valor de retorno o de un estado entre diferentes
invocaciones tiene que utilizar memoria inmortal.
En el servidor (figura 13), TriggerHandler es una
hebra para abordar una carencia de la maquina virtual
usada: el Handler no se puede activar cuando llega
un mensaje. Esta hebra emplea una memoria
restringida (TSM) para esperar por una nueva
solicitud y sale de la memoria cuando la invocacin
ha sido procesada por el Hanlder. Como
consecuencia, todos los objetos creados
(TemporaryObjects) por el mdulo de red son
eliminados entre invocaciones. Esto no es necesario
si el mdulo de red reutiliza objetos en la memoria
inmortal.
El Handler tambin emplea una memoria restringida
(HSM) cada vez que es activado por el
TriggerHandler para manejar la nueva solicitud.
Puede ser liberada despus de enviar la respuesta al
cliente. Como resultado, todos los objetos temporales
generados por el proceso de deserializacin se
almacenan en la memoria restringida del Handler.
Como consecuencia, la implementacin del objeto
remoto se debe desarrolladar con estas caractersticas
en mente para evitar la generacin asignaciones de
memoria ilegales. Adems, la aplicacin tiene que
evitar entrar en nuevas memorias restringidas. A
pesar de estas limitaciones, la aplicacin puede crear
todos los objetos necesarios (SOI y SOS). Por lo
tanto, la memoria restringida tiene que ser lo
suficientemente grande para contener todos los
argumentos de la invocacin y los objetos creados
por la ejecucin del mtodo remoto. La solicitud y la
respuesta se guardan en buffers ubicados en memoria
inmortal (B3, B4). Para mantener un estado entre las
invocaciones, la aplicacin se tienen que utilizar
objetos en memoria inmortal (SOI).
Figura 13: Gestin de memoria en el servidor
En resumen, el modelo de memoria propuesto incluye
las siguientes caractersticas: i) los objetos
planificables, las reas de memoria, los buffers, y
todos los objetos necesarios durante la ejecucin de
un mtodo remoto se crean en la memoria inmortal;
ii) los objetos temporales (ya sean generados por el
middleware o por el mtodo remoto) se crean en la
memoria restringida; iii) el mtodo remoto puede
mantener un estado entre invocaciones utilizando
memoria inmortal; iv) la implementacin de RMI-
HRT respeta las reglas de asignacin de memoria
impuestas por RTSJ y su perfil HRTJ; v) con este
modelo, es posible calcular la cantidad de memoria
necesaria para invocar un mtodo remoto.
5 Serializacin Predecible
5.1 Introduccin
La serializacin es una de las operaciones
fundamentales para asegurar la adecuada transmisin
de datos independientemente de la representacin de
los datos en los nodos y la complejidad de los objetos
a ser propagados. Sin embargo, las actuales
implementaciones no son validas para sistemas
crticos y no hay alternativas:
Hacen uso de algoritmos recursivos y tcnicas
orientadas a objetos.
Estn basadas en la asignacin dinmica de
objetos y el uso del recolector de basura.
Serializan objetos complejos, que referencian
otros objetos formando grafos y bucles, lo que
complica la realizacin de anlisis estticos.
12
Finalmente, estos algoritmos no funcionan con
una maquina virtual RTSJ, dado que realizan
asignaciones ilegales de memoria.
5.2 Requisitos
La solucin debe considerar los siguientes requisitos:
Conforme con el perfil de tiempo real crtico de
Java empleado.
Reducir y limitar el uso de recursos,
principalmente el uso de memoria y CPU durante
la fase de misin.
Acotar estticamente el nmero de bytes
necesario para representar los objetos. Esta cota
es de gran utilidad para estimar el ancho de
banda, el tiempo de transmisin y el tiempo de
respuesta de extremo a extremo.
Tratar un conjunto suficiente de clases
Mantener el formato subyacente definido por la
especificacin, con la finalidad de potenciar la
interoperabilidad.
Lograr una serializacin eficiente.
5.3 Enfoque de la serializacin predecible
El enfoque propuesto se basa en mover la mayor
cantidad posible de tareas hacia el compilador. Por lo
tanto, la serializacin se lleva a cabo en diferentes
intervalos de tiempo:
En tiempo de compilacin, el compilador analiza
las clases empleadas y determina la secuencia de
valores que representarn el estado de un objeto.
Finalmente genera las clases de serializacin que
transforman una instancia en una secuencia de
bytes.
Durante la fase de inicializacin, las clases de
serializacin se cargan en memoria.
Durante la fase de misin, las clases se invocan
para serializar o deserializar objetos.
Este enfoque tiene varias ventajas:
Se evitan ciertas restricciones: Las restricciones
impuestas sobre las aplicaciones de tiempo real no
se aplican en el compilador.
Cdigo personalizado: Genera un cdigo
optimizado para cada clase, sin incluir sentencias
innecesarios.
Perfil HRTJ: El cdigo generado es ms sencillo,
lo que facilita la conformidad con los perfiles de
tiempo real crtico.
Reduccin de la asignacin dinmica de objetos:
Dado que el compilador ejecuta parte de las
tareas, en la fase de misin solo se crean los
objetos estrictamente necesarios.
Reduccin del uso de CPU: El cdigo optimizado
que se genera reduce el tiempo de CPU necesario
para realizar las operaciones de serializacin.
Simplifica el clculo del WCET: La sencillez del
cdigo permite definir ms fcilmente el camino
de peor caso.
5.4 Estructura de la implementacin
La figura 14 representa las clases que participan en la
operacin de la serializacin predecible y la
integracin con RMI-HRT. Las clases RMI-HRTC,
RMICObjectOutputSream y RMICObjectInputSream
se utilizan en la primera parte de la serializacin
predecible. El suplente, el esqueleto, las clases de
serializacin, y las clases RMIHrtObjectOutputSream
y RMIHrtObjectInputSream se utilizan en tiempo de
ejecucin.
Figura 14: Implementacin
El compilador rmic-hrt analiza las clases empleadas y
genera la correspondiente clase de serializacin y
deserializacin. Cuando rmic-hrt genera el suplente y
el esqueleto incluye las llamadas adecuadas a los
mtodos de serializacin y deserializacin de las
clases a la que pertenecen los parmetros de la
invocacin y de retorno.
5.5 Clases de serializacin
La clase de serializacin est formada principalmente
por el mtodo esttico writeObject y, de manera
similar, la clase deserializacin est formada
principalmente por un mtodo esttico readObject.
Las clases RMIHrtObjectOutputStream y
RMIHrtObjectInputStream representan el tipo de
stream manejado por la serializacin predecible. El
mtodo writeObject tiene dos argumentos, el stream
de salida y el objeto que se va a convertir. El mtodo
readObject necesita el stream de entrada, y devuelve
el objeto reconstruido.
Las figuras 15 y 16 resumen las tareas llevadas a
cabo por los mtodos writeObject y readObject
cuando las clases representan un objeto estndar.
Cuando las clases representan una cadena o una
matriz los mtodos tienen algunas modificaciones.
Dado que la serializacin predecible soporta los
campos que hacen referencia a un valor nulo, la
primera accin es verificar si el estado de la instancia
se puede representar con el valor nulo, que se
corresponde con el valor TC_NULL
13
Figura 15: mtodo writeObject
La secuencia de acciones de serializacin es:
Despus de escribir el valor TC_OBJETO al
stream, se escribe el descriptor de la clase.
Despus del descriptor, cada campo serializable
se aade al stream. Los campos de la primera
super-clase no serializable aparecen en primer
lugar y los campos de la clase en cuestin
aparecen al final. Dentro de cada clase, los
campos se ordenan cannicamente por el nombre.
Todos los campos se leen mediante objetos
especficos creados cuando la clase de
serializacin es carga en memoria.
- Los tipos primitivos se escriben al stream
directamente con mtodos genricos de la clase
RMIHrtObjectOutputStream.
- Los objetos se escriben al stream invocando el
mtodo writeObject de la clase correspondiente.
Como resultado, un conjunto de mtodos
writeObject permite la serializacin de objetos
complejos.

Figura 16: mtodo readObject
La secuencia en el caso de la deserializacin es:
El primer byte en el stream indica si la instancia
es nula o si se debe lanzar una excepcin.
Se recuperar el descriptor.
El mtodo readObject asigna una nueva instancia
de la clase para reconstruir el objeto original. Los
campos serializables se leen en orden.
- Los campos primitivos se leen con mtodos
genricos.
- readObject de las clases de deserializacin
correspondientes se emplea para leer los objetos.
Para las matrices, el valor TC_OBJECT cambia por
el valor TC_ARRAY. A continuacin, se indica el
nmero de elementos. Los elementos primitivos de
las matrices se leen con mtodos de la clase
RMIHrtObjectOutputStream /
RMIHrtObjectInputStream. Si las matrices son de
objetos, se emplean los mtodos writeObject /
readObject de las clases correspondientes.
5.5 Clases Serializables
La estructura de un objeto puede ser compleja. Los
objetos pueden incluir referencias a otros objetos y
componer grafos con bucles. Si se limita la
complejidad de este tipo de objetos, no es posible
proporcionar un proceso de serializacin predecible.
En la implementacin actual, slo es posible tratar
con objetos cuya estructura no cambia en forma
dinmica. En otras palabras, las clases serializables
deben tener las siguientes caractersticas:
Las clases no pueden incluir referencias
recursivas.
Las clases debe tener un constructor por defecto
y todos las cadenas o matrices se debe inicializar
en el constructor por defecto con el mximo
tamao.
Las clases deben implementar la interfaz
java.io.HrtSerializable, que permite identificar las
clases serializables.

Figura 17: Gestin de memoria
14
5.6 Consideraciones sobre la memoria
La aplicacin debe cargar todas las clases de
serializacin en la memoria inmortal e inicializa sus
variables. La figura 17 muestra cmo el mtodo
writeObject, no asigna memoria adicional durante su
ejecucin. Por esta razn, la serializacin de
cualquier nmero de instancias de la misma clase no
consume ms memoria que la asignada en la fase de
inicializacin. El mtodo readObject, que
implementa la deserializacin en la fase de la misin,
crea nuevos objetos para recuperar el objeto original,
por lo que debe ser invocado desde memoria
restringida para tener la opcin de eliminar los
objetos.
6 Validacin
Con objeto de validar el diseo e implementacin de
RMI-HRT, se ha llevado a cabo un exigente proceso
de validacin. Se han empleado varios mtodos para
satisfacer todos los requisitos establecidos, como la
revisin de la documentacin e inspeccin de cdigo,
la ejecucin de pruebas especficas en una plataforma
determinada. La mayor parte del se ha dedicado a
validar el diseo, el prototipo y el compilador
respecto: al comportamiento funcional, al uso de
memoria, al uso de la CPU (tiempo de respuesta de
extremo a extremo y en cada uno de los bloques
funcionales) y al uso de la red (consumo real tiene
que ser conforme a lo estimado).
6.1 Caso de Uso
El diseo y el prototipo han sido validados en una
aplicacin industrial en el marco del proyecto HIJA.
El caso de uso lo propuso Thales Avionics. Thales, el
socio industrial responsable de la comprobacin y
validacin de las herramientas desarrolladas para los
sistemas crticos dentro del mencionado proyecto.
RMI-HRT se ha utilizado en las comunicaciones de
un sistema de gestin de vuelo (FMS). Un FMS lleva
a cabo una amplia variedad de tareas durante el
vuelo, por ejemplo: proporciona las predicciones de
tiempo de vuelo, el kilometraje, la velocidad, y
elimina muchas de las operaciones de rutina
realizadas normalmente por los pilotos. En una
operacin bsica, el piloto inserta una ruta planificada
de antemano de origen al destino y el FMS gua la
aeronave a lo largo del plan de vuelo generando
perfiles verticales y laterales de vuelo y prediciendo
el progreso a lo largo de la ruta. Este tipo de sistemas
implementan complejas operaciones matemticas y
procesamiento de datos con estrictos requisitos
temporales. El FMS se compone de las siguientes
funciones bsicas:
Funcin de plan de vuelo: permite al piloto
establecer una trayectoria especfica.
Funcin de navegacin: se encarga de determinar
la posicin actual de la aeronave.
Funcin de rendimiento: proporciona a la
tripulacin informacin sobre cada parmetro de
la trayectoria como la velocidad de despegue, la
capacidad de altitud, y avisos de perfil de
optimizacin.
Funcin de orientacin: se encarga de generar
comandos para guiar a la aeronave a lo largo de
los perfiles laterales y verticales.
Funcin de prediccin de la trayectoria:
responsable de calcular el perfil de vuelo a lo
largo de toda la ruta especificada.
Todas estas funciones se llevan a cabo utilizando la
arquitectura definida en la figura 18. El piloto elige
una trayectoria (MCDU), que enva una solicitud al
gestor del plan de vuelo con el fin de crear un nuevo
plan de vuelo (FP). El nuevo FP es envido a la
MCDU, la pantalla de navegacin (ND), un
simulador A / C y al gestor de orientacin. El gestor
de orientacin tambin recibe entradas desde el
simulador A / C para generar datos necesarios para el
gestor del piloto automtico que se encarga de
gestionar el simulador A / C por medio de un
conjunto de comandos. El gestor de prediccin
interacta con el gestor del plan de vuelo para
actualizar el estado actual de la aeronave (peso,
velocidad, actitud, etc.)
Figura 18: Sistema de gestin de vuelo
Dos middlewares fueron aplicados: una
implementacin de RMI de Thales (llamada RMI-
UDP) y nuestro middleware RMI-HRT. RMI-UDP se
utiliza para cubrir las comunicaciones sin
requerimientos temporales (que se representan con
lneas negro en la figura) y RMI-HRT se aplicada
para manejar la comunicacin entre los componentes
con estrictos requisitos de tiempo real (lneas rojas en
la figura). Por lo tanto, RMI-HRT interconecta seis
componentes importantes en un FMS.
La figura 19 describe la plataforma de ejecucin
utilizados en esta aplicacin distribuida. Por un lado,
la parte de tiempo real crtico se ejecuta en un IMA
(Integrated Modular Avionic module) con un sistema
operativo ARINC 653. Cada particin ejecuta una
mquina virtual de Java RTSJ, en este caso,
JamaicaVM. En el otro lado, la parte no crtica de la
aplicacin ejecuta en un PC estndar con Linux y una
mquina virtual J2SE. AFDX es el protocolo de red
15
que conecta las dos partes de la aplicacin y los
puertos de ARINC 653 proporcionar la comunicacin
entre particiones.
Figura 19: Plataforma de ejecucin
Durante la fase de desarrollo e integracin, todas las
funcionalidades bsicas fueron probadas La
serializacin predecible opero con objetos complejos,
y las invocaciones asncronas se utilizaron
ampliamente para cumplir con los plazos estrictos.
Antes de la prueba final, una serie de pruebas
exhaustivas fueron ejecutadas con el fin de garantizar
un comportamiento correcto. Adems, el anlisis de
memoria, CPU y red han sido exhaustivos y han
demostrado la robustez de la aplicacin. Al final, la
aplicacin distribuida funciono correctamente y el
proyecto finaliz con xito demostrando que nuestro
prototipo es fiable para aplicaciones industriales con
estrictos requisitos temporales.
7 Conclusiones
Este trabajo identifica la necesidad de un middleware
que permita a la tecnologa Java desarrollar sistemas
distribuidos de tiempo real crtico. RMI-HRT
proporciona esta funcionalidad y permite la
evaluacin esttica de los tiempos de respuesta de ex-
tremo a extremo. Las contribuciones ms destacadas
son:
Separacin de la asignacin de los recursos de la
ejecucin: Se separa la asignacin de los recursos
de la ejecucin para mejorar la predecibilidad. En
una fase de inicializacin, todos los recursos
necesarios para la siguiente fase se crean y todas
las operaciones no deterministas (como la
creacin de conexiones) se llevan a cabo. En la
fase de misin, las invocaciones remotas se
realizan con los recursos asignados.
Referencia remotas asociadas a recursos y
parmetros: Cada referencia se asocia a un
conjunto especfico de recursos (objetos
planificables, memoria, red).
Gestin de errores: RMI-HRT supervisa el
comportamiento funcional y temporal. La
aplicacin ejecuta el cdigo de tratamiento de
errores cuando stos se producen.
Invocaciones sncronas y asncronas: Gestiona el
modo de invocacin sncrona y asncrona. La
aplicacin puede elegir si el cliente tiene que
esperar por una respuesta o no. El modo asncrono
reduce el uso de los recursos, menos memoria,
CPU y ancho de banda.
Optimizacin del protocolo JRMP: Se define un
protocolo de conexin (HRT-JRMP) para reducir
la sobrecarga y mejorar la predictibilidad durante
la invocacin remota.
Independencia del protocolo de red: Se asla la
parte dependiente de la red. Se define una interfaz
clara que permite al middleware operar sin
conocer detalles del protocolo subyacente.
Clculo esttico del tamao mximo de la
llamada y de la respuesta: el compilador
determina el tamao de la solicitud y la respuesta
para cada uno de los mtodos remotos
considerando el peor de los casos. Estos valores
permiten calcular el ancho de banda necesario.
Conforme al perfil de tiempo real crtico de Java:
El prototipo incluye todas las caractersticas
conforme al perfil HRTJ y a los principales
conceptos de la especificacin SCJ actual.
Cumplimiento de los requisitos: Los principales
requisitos se han satisfecho.
Serializacin predecible: Los objetos son
transformados en un modo predecible.
Agradecimientos
Los autores agradecen a los miembros del grupo
Sistemas de Tiempo Real y Arquitectura de
Servicios Telemticos de la Universidad Politcnica
de Madrid por sus tiles apreciaciones.
Referencias
[1] G. Bollella. The Real-Time Specification for
Java http://www.rtj.org.
[2] Kwon, J., Wellings, A. and King, S.
Ravenscar-java: a high-integrity profile for
real-time java: Research articles. Concurr.
Comput.: Pract. Exper. 17(5-6): 681713, 2005.
[3] High Integrity Java. http://www.hija.info.
[4] Locke, D., Andersen, B. S., Brosgol, B., Fulton,
M., Henties, T., Hunt, J. J., Nielsen, J. O.,
Nilsen, K., Schoeberl, M., Tokar, J., Vitek, J.
and Wellings, A. Safety-critical java
technology specification, public draft. 2011
http://www.jcp.org/en/jsr/detail?id=302
[5] Jsr-50: Distributed Real-Time Specification.
http://www.jcp.org/en/jsr/detail?id=050.
[6] Sun Microsystems. Java Remote Method
Invocation Specification.
http://java.sun.com/docs/index.html
[7] Rtzen. http://doc.ece.uci.edu/rtzen/.
[8] Object Management Group, The Common
Object Request Broker: Architecture and
Specification: Revision 2.3.1.
www.omg.org/cgi-bin/doc?formal/99-10-07/.
[9] Object Management Group, Real-Time
CORBA Specification. Object anagement
Group, August 2002.
16
[10] Vergnaud, T., Hugues, J., Pautet, L. and
Kordon, F. Polyorb: A schizophrenic
middleware to build versatile reliable distributed
applications. Ada-Europe 2004.
[11] Garca, J. J. G. and Harbour, M. G. Towards a
real-time distributed systems annex in ada. Ada
Lett. XXI(1): 6266. 2001.
[12] P. Basanta, Marisol Garca-Valls, Iria Estevez-
Ayres. No Heap Remote Objects: Leaving Out
the Garbage Collector at the Server Side.
Second International Workshop on Java
Technologies for Real-Time and Embedded
Systems JTRES04, LNCS 3292 On the Move to
Meaningful Internet Systems 2004: OTM 2004
Worshops, 25-29 Obctober 2004.
[13] Tejera, D., Tolosa, R., de Miguel, M. A. and
Alonso, A. Two alternative rmi models for
real-time distributed applications. ISORC 05:
Proceedings of the Eighth IEEE International
Symposium on Object-Oriented Real-Time
Distributed Computing, IEEE Computer
Society, Washington, DC, USA, pp. 390397.
2005.
[14] J. P. Gutirrez, J. J. G. Garca, and M. G.
Harbour. On the Schedulability Analysis for
Distributed Hard Real-Time Systems. In 9th
Euromicro Workshop on Real Time Systems
(euromicro-rts 97), June 1997.
[15] J. J. Gutirrez Garca, J.C. Palencia Gutirrez
and M. Gonzlez Harbour. Schedulability
Analysis of Distributed Hard Real-Time
Systems with Multiple- Event Synchronization.
In Proceedings of 12th Euromicro Conference
on Real-Time Systems, Stockholm (Sweden),
IEEE Computer Society Press, pp. 15-24, June
2000.
[16] H. Kopetz y G. Grnsteidl. TTP-A Protocol for
Fault-Tolerant Real-Time Systems. IEEE
Computer, pp 14-23, January 1994.
[17] Robert Bosch GmbH, Stuttgart. CAN
Specification Version 2.0. Germany, 1991.
[18] ARINC 664. Aircraft Data Network, Part 7
Avionics Full Duplex Switched Ethernet
(AFDX) Network, Draft 3. September, 2004.