JAVA CARD Java Card es una tecnologa que permite ejecutar de forma segura pequeas aplicaciones Java (applets)

en tarjetas inteligentes y similares dispositivos empotrados. Java Card da al usuario la capacidad de programar aplicaciones que se ejecutan en la tarjeta de modo que sta tenga una funcionalidad prctica en un dominio de aplicacin especfico (pe. identificacin, pago, etc.). Esta tecnologa se usa ampliamente en las tarjetas SIM (utilizadas en telfonos mviles GSM) y en tarjetas monedero electrnico. La primera tarjeta Java fue presentada en 1997 por varias empresas entre las que estaban Axalto (divisin de tarjetas de Schlumberger) y Gemplus. Los productos Java Card estn basados en la Plataforma Java Card cuyas especificaciones han sido desarrolladas por Sun Microsystems. La ltima versin de la plataforma JavaCard es la especificacin liberada por Sun en el 2000. Las principales caractersticas de esta tecnologa son la portabilidad y la seguridad.

Portabilidad Java Card tiene por objeto la definicin de un estndar de tarjeta inteligente que permite a la misma applet funcionar en diferentes tarjetas inteligentes, de forma muy parecida a cmo un applet de Java se ejecuta en diferentes ordenadores. Al igual que en Java, esto se consigue utilizando la combinacin de una mquina virtual (la Mquina virtual de Java Card), y unas libreras cuya API est especificada. La portabilidad, en todo caso, sigue siendo obviada en muchos casos por cuestiones de tamao de la memoria, el rendimiento y tiempo de ejecucin (por ejemplo para los protocolos de comunicacin o algoritmos criptogrficos). Seguridad La tecnologa Java Card fue desarrollada originalmente con el propsito de asegurar la informacin sensible almacenada en las tarjetas inteligentes. La seguridad est determinada por diversos aspectos de esta tecnologa:

Applet. El applet es una mquina de estados que slo procesa los comandos recibidos a travs del dispositivo lector enviando y respondiendo con cdigos de estado y datos. Separacin de applets. Las distintas aplicaciones estn, adems, separadas unas de otras por un cortafuegos que limita el acceso y control de los elementos de datos de un subprograma a otro. Encapsulacin de datos. Los datos se almacenan en la aplicacin y las aplicaciones Java Card se ejecutan en un entorno aislado (la tarjeta de Java VM), separada del sistema operativo y del equipo en que se lee la tarjeta. Criptografa. En esta plataforma estn implementados los algoritmos criptogrficos ms comnmente utilizados como DES, 3DES, AES, RSA (incluyendo el uso de criptografa de curva elptica). Otros servicios como la firma electrnica o la generacin de claves de intercambio tambin estn soportados.

Java Card frente a Java Lenguaje A nivel de lenguaje, Java Card es un subconjunto de Java: todas las construcciones del lenguaje Java Card existen en Java y se comportan de la misma manera. Esto va hasta el punto de que, como parte de un ciclo

estndar de desarrollo, un applet Java Card se compila en un archivo de clase Java (.class) por un compilador Java normal, sin ningn tipo de opcin especial (aunque el fichero compilado ser procesado posteriormente por herramientas especficas para la plataforma Java Card). No obstante, muchas caractersticas del lenguaje Java no son compatibles con Java Card (en particular algunos tipos bsicos (char, double', float y long); los enums; los arrays de ms de una dimensin; los hilos (threads);... y algunas caractersticas son opcionales y estn ausentes en la mayora de las tarjetas inteligentes (pe. el tipo int, en particular, que es el valor por defecto de un tipo de expresin de Java, la recoleccin de basura). Bytecode El bytecode de Java Card gestionado por la mquina virtual de Java Card es un subconjunto funcional de Java (Java 2 Standard Edition) aunque utiliza una codificacin diferente optimizada para ocupar menos espacio. Libreras de ejecucin fe Las libreras estndar de Java Card difieren en mucho de las de Java, y el subconjunto comn es mnimo. Por ejemplo, la clase del Java Security Manager no es compatible con Java Card, donde las polticas de seguridad son ejecutadas por la mquina virtual de la tarjeta. Desarrollo Las tcnicas de codificacin utilizadas en la programacin de Java Cards difieren significativamente de las que se utilizan en un programa Java. An as, al utilizar Java Card un subconjunto del lenguaje Java se acelera la curva de aprendizaje, y permite utilizar un entorno Java para desarrollar y depurar un programa Java Card.

SISTEMA OPERATIVO DE TIEMPO REAL Un sistema operativo de tiempo real (SOTR o RTOS -Real Time Operating System en ingls), es un sistema operativo que ha sido desarrollado para aplicaciones de tiempo real. Como tal, se le exige correccin en sus respuestas bajo ciertas restricciones de tiempo. Si no las respeta, se dir que el sistema ha fallado. Para garantizar el comportamiento correcto en el tiempo requerido se necesita que el sistema sea predecible (determinista).

Caractersticas Generales Usado tpicamente para aplicaciones integradas, normalmente tiene las siguientes caractersticas:

No utiliza mucha memoria Cualquier evento en el soporte fsico puede hacer que se ejecute una tarea Multi-arquitectura (cdigo portado a cualquier tipo de CPU) Muchos tienen enfermedades predecibles para eventos electrnicos

Se caracterizan por presentar requisitos especiales en cinco reas generales:

Determinismo Sensibilidad Control del usuario Fiabilidad Tolerancia a los fallos

En la actualidad hay un debate sobre qu es tiempo real. Muchos sistemas operativos de tiempo real tienen un programador y diseos de controladores que minimizan los periodos en los que las interrupciones estn deshabilitadas, un nmero llamado a veces duracin de interrupcin. Muchos incluyen tambin formas especiales de gestin de memoria que limitan la posibilidad de fragmentacin de la memoria y aseguran un lmite superior mnimo para los tiempos de asignacin y retirada de la memoria. Un ejemplo temprano de sistema operativo en tiempo real a gran escala fue el denominado programa de control desarrollado por American Airlines e IBM para el sistema de reservas Sabre. Procesador Este tipo de sistemas operativos no es necesariamente eficiente en el sentido de tener una capacidad de procesamiento alta. El algoritmo de programacin especializado, y a veces una tasa de interrupcin del reloj alta pueden interferir en la capacidad de procesamiento. Aunque para propsito general un procesador moderno suele ser ms rpido, para programacin en tiempo real deben utilizarse procesadores lo ms predecibles posible, sin paginacin. Todos estos factores aaden una aleatoriedad que hace que sea difcil demostrar que el sistema es viable, es decir, que cumple con los plazos. Un sistema operativo de tiempo real puede ser implementado en microcontroladores o procesadores digitales de seal "DSP's", asi, se pueden desarrollar aplicaciones embebidas en diferentes reas de la electrnica. Diseo Hay dos diseos bsicos:

Un sistema operativo guiado por eventos slo cambia de tarea cuando un evento necesita el servicio. Un diseo de comparticin de tiempo cambia de tareas por interrupciones del reloj y por eventos.

El diseo de comparticin de tiempo gasta ms tiempo de la UCP en cambios de tarea innecesarios. Sin embargo, da una mejor ilusin de multitarea. Normalmente se utiliza un sistema de prioridades fijas. Uno de los algoritmos que suelen usarse para la asignacin de prioridades es el Rate-Monotonic Schedule. Si el conjunto de tareas que tenemos es viable con alguna asignacin de prioridades fijas, tambin es viable con el Rate-Monotonic Schedule, donde la tarea ms prioritaria es la de menor periodo. Esto no quiere decir que si no es viable con Rate-Monotonic Schedule no sea viable con asignaciones de prioridad variable. Puede darse el caso de encontrarnos con un sistema viable con prioridades variables y que no sea viable con prioridades fijas. Programacin En los diseos tpicos, una tarea tiene tres estados: ejecucin, preparada y bloqueada. La mayora de las tareas estn bloqueadas casi todo el tiempo. Solamente se ejecuta una tarea por UCP. La lista de tareas preparadas suele ser corta, de dos o tres tareas como mucho. El problema principal es disear el programador. Usualmente, la estructura de los datos de la lista de tareas preparadas en el programador est diseada para que cada bsqueda, insercin y eliminacin necesiten interrupciones de cierre solamente durante un perodo muy pequeo, cuando se buscan partes de la lista muy definidas. Esto significa que otras tareas pueden operar en la lista asincrnicamente, mientras que se busca. Una buena programacin tpica es una lista conectada bidireccional de tareas preparadas, ordenadas por orden de prioridad. Hay que tener en cuenta que no es rpido de buscar sino determinista. La mayora de las listas de tareas

preparadas slo tienen dos o tres entradas, por lo que una bsqueda secuencial es usualmente la ms rpida, porque requiere muy poco tiempo de instalacin. El tiempo de respuesta crtico es el tiempo que necesita para poner en la cola una nueva tarea preparada y restaurar el estado de la tarea de ms alta prioridad. En un sistema operativo en tiempo real bien diseado, preparar una nueva tarea necesita de 3 a 20 instrucciones por cada entrada en la cola y la restauracin de la tarea preparada de mxima prioridad de 5 a 30 instrucciones. En un procesador 68000 20MHz, los tiempos de cambio de tarea son de 20 microsegundos con dos tareas preparadas. Cientos de UCP MIP ARM pueden cambiar en unos pocos microsegundos. Comunicacin entre Tareas Las diferentes tareas de un sistema no pueden utilizar los mismos datos o componentes fsicos al mismo tiempo. Hay dos mtodos para tratar este problema. Uno de los mtodos utiliza semforos. En general, el semforo binario puede estar cerrado o abierto. Cuando est cerrado hay una cola de tareas esperando la apertura del semforo. Los problemas con los diseos de semforos son bien conocidos: inversin de prioridades y puntos muertos (deadlocks). En la inversin de prioridades, una tarea de mucha prioridad espera porque otra tarea de baja prioridad tiene un semforo. Si una tarea de prioridad intermedia impide la ejecucin de la tarea de menor prioridad, la de ms alta prioridad nunca llega a ejecutarse. Una solucin tpica sera otorgar a la tarea que tiene el semforo la prioridad de la tarea ms prioritaria de las que estn esperando dicho semforo. Esto se denomina algoritmo de herencia bsica de prioridad. En un punto muerto, dos tareas (T1,T2) pretenden adquirir dos semforos (semA,semB) en orden inverso. En este caso si T1 adquiere semA y T2 adquiere semB cuando intenten adquirir el segundo semforo no podrn hacerlo ya que lo tiene la otra tarea. De esta forma entran en un punto muerto del que ninguna de las dos tareas puede salir sin intervencin externa. Esto se resuelve normalmente mediante un diseo por ej. obligando a adquirir los semforos en un orden concreto. La otra solucin es que las tareas se manden mensajes entre ellas. Esto tiene los mismos problemas: La inversin de prioridades tiene lugar cuando una tarea est tratando un mensaje de baja prioridad, e ignora un mensaje de ms alta prioridad en su correo. Los puntos muertos ocurren cuando dos tareas realizan envos bloqueantes (se quedan en la funcin de envo esperando a que el receptor reciba el mensaje). Si T1 manda un mensaje de forma bloqueante a T2 y T2 manda un mensaje de igual forma a T1 ninguna de las dos tareas saldr de la funcin de envo quedando ambas bloqueadas ya que no podrn llegar a la funcin de recepcin. Puede resolverse reordenando envos y recepciones o empleando envos no bloqueantes o temporizados. Aunque su comportamiento en tiempo real es algo ms difcil de analizar que los sistemas de semforos, los sistemas basados en mensajes normalmente son ms sencillos de desarrollar que los sistemas de semforo. Interrupciones Las interrupciones son la forma ms comn de pasar informacin desde el mundo exterior al programa y son, por naturaleza, impredecibles. En un sistema de tiempo real estas interrupciones pueden informar diferentes

eventos como la presencia de nueva informacin en un puerto de comunicaciones, de una nueva muestra de audio en un equipo de sonido o de un nuevo cuadro de imagen en una videograbadora digital. Para que el programa cumpla con su cometido de ser tiempo real es necesario que el sistema atienda la interrupcin y procese la informacin obtenida antes de que se presente la siguiente interrupcin. Como el microprocesador normalmente solo puede atender una interrupcin a la vez, es necesario que los controladores de tiempo real se ejecuten en el menor tiempo posible. Esto se logra no procesando la seal dentro de la interrupcin, sino enviando un mensaje a una tarea o solucionando un semforo que est siendo esperado por una tarea. El programador se encarga de activar la tarea y esta se encarga de adquirir la informacin y completar el procesamiento de la misma. El tiempo que transcurre entre la generacin de la interrupcin y el momento en el cual esta es atendida se llama latencia de interrupcin. El inverso de esta latencia es una frecuencia llamada frecuencia de saturacin, si las seales que estn siendo procesadas tienen una frecuencia mayor a la de saturacin, el sistema ser fsicamente incapaz de procesarlas. En todo caso la mayor frecuencia que puede procesarse es mucho menor que la frecuencia de saturacin y depende de las operaciones que deban realizarse sobre la informacin recibida. Memoria Hay dos problemas con el reparto de la memoria en SOTR (sistemas operativos en tiempo real). El primero, la velocidad del reparto es importante. Un esquema de reparto de memoria estndar recorre una lista conectada de longitud indeterminada para encontrar un bloque de memoria libre; sin embargo, esto no es aceptable ya que el reparto de la memoria debe ocurrir en un tiempo fijo en el SOTR. En segundo lugar, la memoria puede fragmentarse cuando las regiones libres se pueden separar por regiones que estn en uso. Esto puede provocar que se pare un programa, sin posibilidad de obtener memoria, aunque en teora exista suficiente memoria. Una solucin es tener una lista vinculada LIFO de bloques de memoria de tamao fijo. Esto funciona asombrosamente bien en un sistema simple. La paginacin suele desactivarse en los sistemas en tiempo real, ya que es un factor bastante aleatorio e impredecible, que vara el tiempo de respuesta y no nos permite asegurar que se cumplirn los plazos, debido al trasiego de pginas de memoria con un dispositivo de almacenamiento (trashing) Comunicaciones Para las comunicaciones se suelen usar conexiones o redes deterministas CAN bus o puertos serie, ya que las redes ms usuales, como Ethernet son indeterministas y no pueden garantizarnos el tiempo de respuesta. El sistema CAN bus es utilizado para la interconexin de dispositivos electrnicos de control (ECU) en los vehculos.