Sistemas distribuidos en tiempo real

Universidad Nacional de Rosario
FACULTAD DE CIENCIAS EXACTAS, INGENIERÍA Y AGRIMENSURA
ESCUELA DE INGENIERÍA ELECTRÓNICA - DEPARTAMENTO DE SISTEMAS E INFORMÁTICA
CÁTEDRA DE SISTEMAS DISTRIBUIDOS
Monografía
SISTEMAS DISTRIBUIDOS
DE TIEMPO REAL
Alumna:
FLAVIA E. FELICIONI
Profesores:
JOSE LUIS SIMÓN
JAVIER BELMONTE
- AGOSTO 2005 -
I . INTRODUCCION
En los últimos años los sistemas distribuidos de tiempo real se han vuelto más importantes en muchas
aplicaciones tales como los sistemas de control de procesos, la aviónica, el control industrial y otros menos críticos
como los sistemas de videoconferencia, el sistema bancario, la reserva de pasajes en una compañía aérea, entre
otros. Estos sistemas aprovechan la potencialidad de implementaciones en ambientes físicamente distribuidos, la
posibilidad de compartir recursos entre distintos nodos y la reducción de costos dado que los procesadores son cada
vez más económicos comparados con el hardware y software específicos.
Para poder dar soporte a tales aplicaciones se requiere hacer una cuidadosa evaluación de los requisitos a
satisfacer, para los cuales existen muchos métodos. Sólo una adecuada especificación de los requisitos puede
culminar en una implementación satisfactoria. Otras cuestiones fundamentales que hay que tener en cuenta para la
implementación de estos sistemas están relacionadas con el software y la administración de recursos. En la
actualidad existen muchos proyectos de investigación enfocados en estas áreas.
A lo largo de esta monografía se pretende plantear los puntos fundamentales que tienen que ver con los
Sistemas Distribuidos en Tiempo Real (cuyas siglas en español son SDTR). Por ende el desarrollo en detalle de cada
uno de los temas aquí tratados escapa a este objetivo y puede ser consultado en la bibliografía sugerida.
En la sección II se reúnen los conceptos básicos y las definiciones más comunes, dado que existen ciertas
dispersiones entre distintas fuentes bibliográficas. Luego en la sección III se exponen las cuestiones a tener en
cuenta en cada una de las decisivas etapas del diseño de SDTR. La sección IV describe los elementos de software
que requieren los SDTR para su implementación. En la sección V se describen los algoritmos de planificación que
se usan en estos sistemas. Y por último en VI se analizan dos ejemplos de SDTR.
II . CONCEPTOS DE SDTR
En el campo de sistemas de computadoras, la tendencia durante los últimos años ha sido distribuir los cómputos
entre varios procesadores, con el objetivo de incrementar el número de procesos que son completados por unidad de
tiempo (conocido como throughput). Los sistemas con varios procesadores pueden compartir o no los siguientes
recursos: el bus de la computadora, el reloj (clock) y algunos dispositivos y/o periféricos como la memoria. En el
primer caso se dice que estamos en presencia de un sistema “fuertemente acoplado” (tightly coupled system),
mientras en el segundo será uno “débilmente acoplado” (loosely coupled system).
SISTEMA DISTRIBUIDO
A lo largo de la literatura existe una dispersión en cuanto a que se entiende cuando se usan los términos
“sistema distribuido”. A continuación se presentará una definición de tales sistemas (Silverschatz, Galvin).
Sistema distribuido: Sistema de varios elementos de procesamiento autónomos que cooperan en un objetivo en
común o para lograr una meta común.
Es decir, teniendo en cuenta esta definición, cada elemento de procesamiento tiene su propia memoria por lo
cual, y según lo establecido anteriormente, cuando se hace referencia a un “sistema distribuido” se hablará de un
sistema del tipo “débilmente acoplado”.
Entre las numerosas y ventajosas razones para usar sistemas distribuidos destacaremos las siguientes:
‰
Compartir recursos (Resource Sharing): Si un número de nodos (con diferentes capacidades) están
conectados con otros, entonces un usuario en un nodo puede estar habilitado para usar recursos disponibles
en otro nodo.
‰
Velocidad de cómputo (Computation Speedup): Si un cómputo particular puede ser descompuesto en una
cierta cantidad de subcómputos que se realicen concurrentemente (en el mismo momento), entonces el
tener un sistema distribuido posibilita distribuir tales subcómputos entre los nodos que lo componen.
‰
Fiabilidad (Reliability): Si un nodo falla en un sistema distribuido, los nodos restantes pueden
potencialmente continuar operando. Para ello suele ser necesario tener implementado algún tipo de
redundancia y algún mecanismo de detección de fallas.
‰
Comunicación: Cuando varios nodos están conectados por una red de comunicación, los usuarios o
procesos de usuario en diferentes nodos tienen la posibilidad de intercambiar información. Este
intercambio suele ser hecho mediante el envío de mensajes.
Nodo C
Nodo A
servidor
Recursos
Red
Nodo B
comunicación
cliente
Figura 1: Un sistema distribuido. Cliente-Servidor.
SISTEMAS DE TIEMPO REAL
Los sistemas de tiempo real (STR) son usados cuando existen requerimientos temporales en la operación de un
procesador o flujo de dato. Una definición de los STR es presentada a continuación (Silverschatz, Galvin).
Sistemas de tiempo real: Un sistema de proceso de información que tiene que responder a un estímulo de entrada
generado externamente en un período finito y especificado.
Extendiendo un poco esta definición, un sistema de tiempo real que recibe información (eventos) de su entorno
debe realizar alguna acción (reaccionar) para provocar cambios en dicho entorno, y tales cambios dependen tanto
del resultado lógico que resulta de los cálculos que realiza el sistema como del tiempo en el cual los realiza.
A pesar de que un sistema de tiempo real tiene restricciones de tiempo fijas bien definidas, un error común
consiste en asociar esta restricción temporal con la idea de un sistema que debe responder rápidamente.
Tales restricciones temporales dependen de cada sistema en particular y pueden ser estrictas (o rígidas) o
flexibles caracterizando a los STR como rígidos (hard real time), flexibles (soft real time) y los menos comunes
firmes (firm real time).
Un sistema rígido garantiza que las tareas críticas se completen en tiempo, dado que el incumplimiento puede
tener consecuencias más o menos graves, tales como pérdida de vidas o catástrofes. Mientras que en un STR
flexible, las tareas críticas de tiempo real obtienen mayor prioridad sobre otras tareas y retienen tal prioridad hasta
ser completadas. Por último los sistemas de tiempo firme son STR rígidos que pueden tolerar pérdidas, si la
probabilidad de ocurrencia de las mismas es baja.
SISTEMA DISTRIBUIDO DE TIEMPO REAL
En un STR, rígido o flexible, la(s) computadora(s) interfiere(n) normalmente en forma directa con algún
equipamiento, por ello a menudo se dice que los STR son también Sistemas Embebidos. Una definición mas
adecuada de estos últimos es provista por la IEEE (P1003.13/D2.1, febrero 2003):
Sistema de computadoras embebido (Embedded Computer System): Una computadora (y su software) es
considerada embebida (embedded) si es un componente integral de un gran sistema y es usada para controlar y/o
directamente monitorear el sistema, utilizando dispositivos de hardware especiales.
Naturalmente el uso de sistemas distribuidos en la implementación de sistemas embebidos de tiempo real está
asociado con los requerimientos de cada aplicación en particular. Por ejemplo cuando las aplicaciones requieran un
cálculo muy complejo, que deba ser realizado de manera fiable y en un tiempo relativamente bajo, o que las partes
del sistema estén distribuidas físicamente se debe utilizar SDTR. Ejemplos de SDTR son, entre otros: la reserva de
pasajes de una compañía aérea, el sistema de telefonía celular, el sistema bancario de cajeros automáticos, sistemas
multimedia, sistemas de realidad virtual y juegos, las intervenciones quirúrgicas computarizadas, el control de
tráfico aéreo, y los sistemas de producción industrial de plantas altamente automatizadas.
En la fase del establecimiento de requisitos, para cualquiera de los STR, existe una tarea fundamental y
compleja que es especificar los deadline, definidos según:
Tiempo Límite (Deadline): instante tope para finalizar la ejecución del último requerimiento de una tarea (o
proceso). Si la tarea es periódica, es el instante en el cual llegará el próximo requerimiento.
El garantizar el comportamiento dentro de estos deadlines requiere que el sistema sea predecible
(predictability), otra característica clave del STR. Es interesante destacar que sólo se puede conocer que una tarea
perdió su deadline luego de que el deadline ocurrió, lo que implica que no puede haber ninguna acción correctiva.
Para aplicaciones de tiempo real flexible, típicamente el objetivo es satisfacer algunos requerimientos de
Calidad de Servicio, QoS (Quality of Service).
Calidad de Servicio: La calidad de servicio es un efecto colectivo del rendimiento de un servicio dado, que
determina el grado de satisfacción de un usuario del mismo.
Por ejemplo los parámetros de QoS típicos de una red son: el retardo, la variación del retardo y la pérdida de
paquetes. Una red debe garantizar que puede ofrecer un cierto nivel de calidad de servicio para un nivel de tráfico
que sigue un conjunto especificado de parámetros.
En (Blum) los parámetros QoS fueron usados, para evaluar la transferencia de datos de las diferentes redes
industriales (CAN, FIP, ARINC 629 CP) en aplicaciones de control.
A continuación se expondrán los puntos más relevantes de los SDTR, relacionados con su diseño, software, la
planificación de sus tareas y las redes típicas que se usan en su implementación.
III . DISEÑO DE SISTEMAS DE TIEMPO REAL
La etapa más importante del desarrollo de un STR es la denominada de diseño, dado que el STR debe ser
diseñado de manera de que satisfaga una dada especificación de requisitos. Luego, una interpretación adecuada de
tal buen diseño llevará a una exitosa implementación del STR.
Las fases habituales en el desarrollo de los SDTR son:
‰
Especificación de requisitos
‰
Diseño arquitectónico y detallado.
‰
Implementación y prueba.
Para documentar cada una de estas etapas se requiere cierta notación, entre los cuales se pueden destacar tres
métodos (Burns, Wellings): 1) informales, que suelen hacer uso del lenguaje y diagramas imprecisos; 2)
estructurados, que suelen emplear notación gráfica usando bloques bien definidos; 3) formales, está notación tiene
una base matemática que permite escribir operaciones y también probar ciertas propiedades.
ESPECIFICACIÓN DE REQUISITOS
Debido a que los requisitos de alta fiabilidad son fundamentales en los STR, la tendencia actual es emplear una
combinación de los métodos 2) y 3) mencionados en la subsección anterior. Además en esta etapa se deberá
explicitar el comportamiento temporal del sistema (por ejemplo se deben definir los deadlines de las tareas) y los
test de verificación que se aplicarán al software (Burns, Wellings).
En el análisis de requisitos se pueden usar los métodos estructurados: PSL y CORE y los mas novedosos
orientado a objetos (OO), destacandosé entre ellos el Lenguaje Unificado de Modelado (sus siglas en inglés UML);
o los métodos formales: Forest y el lenguaje ALBERT Agent-Oriented Language for Building and Eliciting
Requierement for Real Time Systems. Dentro de los métodos formales más nuevos y que están empezando a ser
utilizados más frecuentemente, se pueden destacar VDM y Z. Estos emplean la teoría de conjuntos y la lógica de
predicados.
DISEÑO ARQUITECTÓNICO Y DETALLADO
En el diseño de un STR distribuido (o también un STR grande), se recomienda utilizar un método de diseño
jerárquico que permita aislar los subcomponentes (componentes más elementales) o módulos, basados en las
abstracciones de procesos y de objetos. Estos subcomponentes deben tener roles bien definidos e interfaces y
conexiones perfectamente definidas y abstractas. Si se emplea una notación formal para la especificación de
requisitos es conveniente utilizar la misma notación en los diseños de alto nivel para poder demostrar si se cumplen
tal especificación.
La descomposición exitosa del sistema en los módulos requiere llegar a un situación de fuerte cohesión,
característica que expresa el grado de unión dentro de un módulo, y débil acoplamiento, que es una medida de la
interdependencia de los módulos.
En el modelado de sistemas distribuidos y concurrentes se pueden emplear las Redes de Petri, las cuales son
definidas matemáticamente y soportan un análisis formal. Dado que usando esta técnica un diseño se puede volver
demasiado grande y complicado, y a menudo hay lugares del sistema que realizan las mismas acciones se pueden
utilizar RdP coloreadas. Existen varios software que permiten probar los diseños de RdP.
En (De Giusti et al.) se discute el modo de modelizar y verificar las restricciones de tiempo de un SDTR,
utilizando Redes de Petri extendidas, tomando como ejemplo un sistema de software para Capital Federal que
detecta en tiempo real el corte de cables telefónicos troncales y utiliza información para alertar a los responsables de
seguridad de la zona del corte. En la figura 2 se puede observar uno de los diagramas de RdP que fue diseñado en el
artículo mencionado.
Figura 2: RdP con comunicaciones sin reinteintos, y máquina-máquina. Imagen tomada de (De Giusti et al.).
Otra posibilidad dentro de los métodos formales es usar en el diseño autómatas temporizados y comprobación
de modelos (Model Cheking). Con esto el sistema se representa por medio de máquinas de estado finito y con
métodos de exploración de estados se determinan los posibles comportamientos del sistema.
En general en ambientes industriales en el mejor de los casos se utilizan métodos estructurados, y los métodos
formales quedan reservados solo para ambientes de investigación. Aunque actualmente en la carrera de Licenciatura
en Ciencias de la Computación de la FCEIA de la UNR se enseñan técnicas formales, como la especificación Z y
con esto es esperable que en un futuro no muy lejano haya licenciados formados en estas técnicas trabajando en
industrias de la zona de Rosario.
Entre los métodos de diseño estructurado (Burns, Wellings) más comunes para STR mencionaremos JSD,
Mascot3 y HTR-HOOD (para Ada). El primero emplea una notación precisa para la especificación (diseño de alto
nivel) y la implementación (diseño detallado). Un grafo JSD consta de procesos y una red de interconexión.
Mascot3 se caracteriza por emplear gráficos de redes de flujo de datos y un diseño jerárquico como el que se
mencionó anteriormente (en módulos). También proporciona las sincronizaciones necesarias para el uso de canales
y depósitos de información.
HRT-HOOD fue diseñado para STR rígidos específicamente para ADA. En el proceso de refinamiento del
diseño las restricciones están impuestas por el conjunto de componentes hardware y software (ej., procesadores,
distribuidores de tareas, dispositivos controladores). Las restricciones pueden ser sobre los recursos (ej., velocidad
de procesamiento, ancho de banda de comunicación) o sobre mecanismos (prioridades de interrupción, bloqueo de
datos, etc.).
IMPLEMENTACIÓN Y PRUEBA
Una implementación que satisfaga los requisitos de una manera lo más aproximada posible requiere utilizar un
adecuado lenguaje de programación. Los lenguajes que potencialmente se pueden utilizar son: Assembler: lenguaje
de máquina (la programación es tediosa y compleja y es raro poder utilizar este programa en otra computadora,
portabilidad); lenguajes de alto nivel C y C++, Ada y Java (para Tiempo Real). Los dos primeros tienen problemas
con respecto al control y la fiabilidad requeridas en tiempo real por lo que necesitan un adecuado soporte del SO.
Una vez implementado el SDTR resulta lógico efectuar ciertas pruebas de manera de comprobar si funciona
correctamente. Para ello resulta útil probar cada uno de los módulos que conforman la arquitectura del diseño,
descriptos en la subsección anterior, en vez de enfocarse en el sistema completo. Es muy importante, en cuanto a la
fiabilidad someter al sistema a una actuación del entorno correcta (según lo esperado) e incorrecta (para ver la
respuesta de peor caso). Todas las pruebas apuntan a una verificación de satisfacción de requisitos y a una
depuración de los posibles errores de implementación. Para realizar estas pruebas se pueden usar simuladores,
emuladores o las más costosas implementaciones de prototipos.
IV . SOFTWARE PARA SDTR
En las aplicaciones de SDTR (es decir, STR en un hardware distribuido) aparecen nuevos desafíos frente a las
aplicaciones de STR centralizados (en un único procesador).
La implementación de un programa distribuido será más sencilla (Burns, Wellings) si el lenguaje de
programación distribuida y el SO (o alguna extensión del mismo) soportan el particionado: proceso de dividir el
sistema en partes; la configuración, asociar los componentes particionados sobre los elementos del sistema; la
ejecución transparente, ejecución del software distribuido de manera que sea posible acceder a los recursos
remotos con transparencia de ubicación. En cuanto a la asignación, proceso real de convertir el sistema configurado
en un conjunto de módulos ejecutables y cargar estos últimos en los elementos de procesamiento y la
reconfiguración, cambio dinámico de ubicación de un componente o recurso, se requiere el soporte del entorno de
programación y del SO.
En el área de ejecución transparente, existen para la comunicación de programas distribuidos tres importantes
estándares de comunicación, a saber: 1) mediante Interfaz de Programación de Aplicaciones (API), 2) mediante el
paradigma de llamada a procedimiento remoto (RPC) y 3) mediante el paradigma de objetos distribuidos.
En cuanto al procesamiento en paralelo que existe en un ambiente distribuido se requieren nuevos algoritmos
para el control de los recursos, por ejemplo el no contar con una referencia de tiempo común puede afectar el
proceso de exclusión mutua sobre datos que estén distribuidos. Para ello deben ser tenidas en cuenta cuestiones de
tiempo y ordenamiento.
ESTRATEGIAS PARA INTERCAMBIO DE DATOS EN SDTR
En la mayoría de los sistemas operativos modernos está provisto un acceso al hardware de la red a través de la
pila de protocolos TCP/IP. Dado que las complejas aplicaciones distribuidas requieren un modelo más poderoso de
comunicación han surgidos varios tipos de tecnologías de software, comúnmente conocidos como middleware.
Estos se pueden clasificar en tres categorías (Rogosin): cliente - servidor (o invocación de objeto remoto), pasaje de
mensaje (Message-passing) y Publicar-Subscribir (Publish-Subscribe).
Figura 3: Cliente-Servidor con datos centralizados.
La mayoría de los diseños con middleware cliente – servidor presentan una API que procura hacer aparecer al
nodo remoto como local y para obtener datos se llaman a métodos en objetos remotos como si estuvieran en el nodo
local (RMI). El middleware, entonces, intenta esconder la naturaleza de la red subyacente. Los middleware
cliente/servidor incluyen CORBA, HTTP, EJB (Enterprise Java Bean). El modelo cliente – servidor funciona bien
para sistemas con información centralizada, tales como bases de dato, sistemas de procesamiento de transacciones y
servidores de archivos centralizados. Sin embargo, si múltiples nodos están generando información, las arquitecturas
cliente-servidor requieren que toda la información sea enviada al servidor para luego ser redistribuida a los clientes.
Esta comunicación indirecta entre clientes es particularmente ineficiente dado que el tener un servidor centralizado
agrega un retardo desconocido por lo que se pierde el determinismo requerido en el ambiente del tiempo real.
Las arquitecturas de pasaje de mensajes emplean el paradigma de diseño de implementación de colas de
mensajes. Los procesos pueden crear colas, enviar mensajes y atender mensajes que les llegan. Con este diseño es
mucho más sencillo intercambiar información entre los nodos de un sistema distribuido. Algunos SO usan el pasaje
de mensajes como mecanismo de sincronización de bajo nivel. Mientras que otros lo proveen en la forma de
librerías de SO (por ejemplo, VxWorks, colas de mensaje POSIX). Los diseños pueden usar la secuencia sendreceive-reply bloqueante en la comunicación y sincronización entre nodos (y entre procesos).
Alternativamente, empresas de middleware como BEA e IBM implementan arquitecturas de pasaje de
mensajes. El pasaje de mensajes permite las conexiones punto a punto, es decir con esta arquitectura las aplicaciones
tienen que encontrar los mensajes indirectamente por un identificador específico de la fuente (por identificación del
procesos, del canal o nombre de la cola) en cada nodo. El diseñador debe determinar donde tomar los datos, donde
mandarlos, y cuando hacer la transacción.
Estos sistemas no permiten, en general, el control sobre el comportamiento de los mensajes o la calidad de
servicio (QoS).
Figura 4: Pasaje de mensaje, con varios canales.
En Publicar-subscribir (Publish-subscribe) los nodos simplemente se subscriben a los datos que necesitan y
publican la información que producen. Los mensajes pasan directamente entre los nodos de comunicación. Estos
sistemas son buenos en distribuir gran cantidad de información de tiempo crítico rápidamente.
Esta arquitectura soporta el desafío propuesto por las comunicaciones embebidas dado que encontrar los datos
correctos resulta simple, los nodos declaran su interés y los que publican envían los datos cuando los datos están
disponibles. Además esta arquitectura es eficiente debido a que los datos fluyen directamente desde la fuente al
destino sin requerir servidores intermediarios. Múltiples fuentes y destinos son fácilmente definidas dentro del
modelo posibilitando el agregado de redundancia que permite tolerancia a fallas.
Las modernas implementaciones del middleware publicar/subscribir (tales como DDS) permiten implementar
mecanismos eficientes de QoS para stream de datos.
Figura 5: Publicar-Subscribir desacopla flujos de datos.
La correcta implementación de estos middleware implica que se pueden conseguir los datos correctos en el
lugar correcto en el momento correcto. Desde hace décadas en las redes de campo Fieldbus (ver sección VI) usadas
en automación industrial se usan diseños publih-subscribe dependientes del hardware. En el ambiente de sistemas
embebidos, middleware comerciales controlan completamente barcos, simuladores de vuelo y sistemas militares
entre otros.
TIEMPO Y ORDENAMIENTO EN SDTR
Los lenguajes de programación usados en STR presentan las siguientes facilidades de tiempo real:
‰
acceder a relojes de manera de poder medir el tiempo y entonces retardar la ejecución de procesos y
programar límites de tiempo de espera (timeouts).
‰
representar los requisitos temporales, (deadlines de las tareas), tasas de ejecución.
‰
satisfacer los requisitos temporales.
Pero dado que en un SDTR no existe un reloj común, como ya fue mencionado, la única posibilidad de utilizar
correctamente tales facilidades (provistas por los lenguajes) requiere la sincronización de los relojes de cada uno de
los equipos que lo conforman, mediante alguna técnica, para tener una hora común (asumiendo pequeñas derivas).
También en un ambiente distribuido resulta importante determinar el orden de la ocurrencia de eventos. Para
sincronizar relojes y ordenar los eventos se pueden consultar los algoritmos explicados en (Simón).
SOPORTE DEL SISTEMA OPERATIVO
Las características de sistemas operativos avanzados tienden a separar al usuario del hardware, y esta
separación implica una incerteza sobre la cantidad de tiempo que una operación puede tomar (Silberschatz). Por lo
tanto un STR rígido, que requiere una garantía de que las tareas críticas que tiene asignadas serán cumplimentadas a
tiempo, tiene conflictos con las operaciones de sistemas operativos de propósito general. Entre las deficiencias que
aparecen al tratar de implementar un STR rígido, usando un SO de propósito general se pueden destacar las
siguientes:
‰
Pocas prioridades de hilos (threads).
‰
Planificación no determinística.
‰
Inversión de prioridades, particularmente en interrupción de procesos.
Como se mencionó anteriormente, existen extensiones de SO, por ejemplo RTX que es una extensión de
tiempo real rígido para Windows NT/2000/XP que provee capacidades determinísticas y de alta velocidad
satisfaciendo las necesidades de respuestas determinísticas para procesos de E/S de dispositivos (TGA Ingeniería).
Los STR flexibles son menos restrictivos, e implementarlos requiere un diseño adecuado del planificador
(scheduler) y tener en cuenta ciertos aspectos relacionados con el SO. Primero, los procesos de tiempo real deben
tener las prioridades más altas. Segundo, la latencia del despachante (dispacher) debe ser lo más baja posible. A
medida que esta sea más baja, más rápidamente un proceso que está listo puede empezar a ejecutarse. Una manera
de mantener baja esta latencia es insertar puntos de preemption (expropiación o apropiación) en largas llamadas al
sistema (syscall). Una planificación expropiativa en un SO, permite que si un proceso que llega a la cola de Listos
(Ready) tiene mayor prioridad que el que está siendo ejecutado, se interrumpa este último para que se pueda correr
el proceso de mayor prioridad.
En el caso de que el STR se implemente de forma distribuida se utilizan aparecen nuevos requerimientos y
problemas asociados también con la comunicación, dado que ahora un factor importante que determina el tiempo en
el que la proceso es terminado tiene que ver con el acceso al medio desde cada nodo (MAC). Frente a este tiempo la
latencia del despachante suele ser despreciada. Además el recurso red debe ser al menos predecible, por ello también
deben ser usados algoritmos de planificación como veremos a continuación.
V . PLANIFICACION EN SDTR
El problema de planificación (scheduling) es un punto muy importante a tener en cuenta en la implementación
de un SDTR, dado que mediante algún algoritmo de planificación se deben asignar las tareas que tienen deadlines y
requieren ciertos recursos de un SD.
Estos algoritmos suelen, según la estrategia de planificación de las tareas, ser clasificados como:
‰
dinámicos: puede haber un conjunto de tareas conocido de antemano, pero ante la aparición de una nueva
tarea, el sistema analiza si la puede garantizar sin afectar a las tareas que ya maneja, y en ese caso la agrega
a la lista de tareas. Mayor costo de ejecución, porque el planificador tiene un trabajo de análisis adicional.
‰
estáticos: todas las tareas, por su naturaleza y características son conocidas de antemano, y en tiempo de
diseño se planifica la ejecución de las mismas. El sistema no admite la aparición de una nueva tarea sobre
la marcha.
Los algoritmos pueden estar implementados de una manera centralizada o decentralizada y pueden ser
expropiativos o no.
PROBLEMAS CON ALGORITMOS STR
Partiendo de la suposición que el SD es síncrono, es decir existe una cota superior en los retrasos de mensajes,
los nodos en si mismos progresan a cierta velocidad y la deriva entre relojes de los nodos está acotada
(sincronizando los mismos) se ha demostrado que los algoritmos de planificación óptimos que suelen usarse para
STR de un sólo procesador no son óptimos en presencia de sistemas de varios procesadores apareciendo en ciertos
casos de manera impredecible.
Como ejemplo citando (Burns, Wellings), si tres procesos periódicos están en la cola de listos, y pueden ser
ejecutados en dos procesadores puede observarse una situación como la siguiente
P1(C=25; D=50), P2(C=25; D=50) y P3(C=80; D=100), C es el tiempo de ejecución y D el deadline de c/ proceso.
D1
Procesador 1
P1
0
CPU ociosa
25
D3
D2
Procesador 2
P2
0
P3
25
105
Figura 6: Pérdida de deadline usando tasa monotónica.
Utilizando la tasa monotónica (rate monotonic), la cual asocia a cada proceso una prioridad de acuerdo a su
período de ejecución (mayor prioridad para menor C). Luego se puede dar una situación como se ve en el diagrama
de Gantt de la figura en el cual luego de completar el proceso 1 el Procesador 1 queda ocioso, durante buena parte
del tiempo y el proceso 3 no alcanza a satisfacer su deadline. Si en vez de utilizar tasa monotónica el algoritmo
asignara P1 y P2 al procesador 1 y P3 al procesador 2 se pueden satisfacer los tres deadlines.
Tampoco usar el algoritmo de STR óptimo Earliest Deadline First (EDF), el cual selecciona el proceso que
tiene el más cercano deadline de entre el conjunto de procesos listos (las prioridades cambian dinámicamente en
tiempo de ejecución) proporciona una solución siempre satisfactoria en ambientes distribuidos.
PLANIFICACIÓN SDTR
Los problemas de planificación en SDTR son complicados dado que además de los deadlines y los tiempos de
ejecución de los procesos, se deben tener en cuenta también los requerimientos de recursos que los procesos
necesitan. Esto es lo que ocurrió en el ejemplo de la figura 6 (donde el recurso eran los 2 procesadores).
Por esto, los recursos necesarios para satisfacer los deadlines de procesos críticos típicamente se asignan
previamente y estos procesos son usualmente planificados estáticamente de manera que sus deadlines resulten
satisfechos incluso en las condiciones de peor caso. Cabe recalcar que esta solución tan inflexible implica una
utilización pobre de los recursos disponibles.
Dado que el no cumplimiento de los deadlines de las procesos no críticos degradan sólo, aunque seriamente, la
performance resulta aconsejable tratar tales tareas de manera dinámica.
Una posibilidad en cuanto a la selección de algoritmos de planificación, presentada en (Burns, Wellings),
requiere la abstracción de procesos definidos más comunes en los SDTR. Tales procesos pueden ser del tipo
periódico, que se ejecuta en instantes de tiempo espaciados regularmente (ciclo); esporádico, que se ejecuta en
respuesta a eventos que ocurren de forma asíncrona imposibles de prever y aperiódico, generalización del caso
anterior.
Este algoritmo sugiere asignar los procesos periódicos y esporádicos estáticamente, es decir impidiendo que
migren a otros procesadores (lo que podría desbalancear la asignación degradando la performance del sistema).
Usando este despliegue estático sobre cada procesador se pueden usar los algoritmos de planificación de un sólo
procesador (EDF, tasa monotónica, Round Robin), con la consecuente posibilidad que haya nodos sobrecargados
mientras otros tienen capacidad de reserva.
En (Ramamritham et al.) se presenta un algoritmo para SDTR rígidos como un ejemplo de planificación
decentralizada y dinámica. Al igual que el algoritmo anterior todos los procesos periódicos críticos y los procesos
esporádicos se asignan estáticamente pero ahora los procesos aperiódicos no críticos tienen la posibilidad de migrar.
Es decir cuando un proceso aperiódico llega a un nodo, el planificador local en ese nodo debe verificar si puede
garantizar que el proceso se complete antes de su deadline, agregando este proceso a su carga existente en el mismo
nodo. Si la verificación falla, los componentes del planificador de otros nodos cooperaran para determinar cual otro
nodo en el sistema tiene suficientes recursos disponibles que permitan realizar la tarea en el tiempo requerido (se
asume que se el estado de la red, y el tiempo es común). Entonces el proceso migrará a algún nodo donde había altas
probabilidades de que pudiera ser completado, pero dado que la transmisión del mismo a través de la red tiene una
demora podría ocurrir que cuando llegué a este nodo ya no haya más disponibilidad. Por ello se vuelve a realizar el
test de garantía en este nodo y en caso negativo el proceso debería volver a migrar. Todas estas migraciones pueden
conducir a que se pierda el deadline del proceso.
Obviamente la base de este método es que los procesos aperiódicos puedan migrar, pero esto no siempre ocurre
dado que algunos de tales procesos están fuertemente acoplados con el hardware de algún nodo, y por tanto deben
ser ejecutados en él mismo.
ACCESO A LA RED DE COMUNICACIÓN
Como ya mencionamos los mensajes deben competir para ganarse el acceso al medio de comunicación, por
ejemplo usando conmutadores, buses o anillos. Para que los procesos de TR cumplan sus deadlines este acceso
deberá ser planificado, de forma que sea consistente con la planificación de ejecución de los procesos en cada nodo.
Si esto no se planifica puede ocurrir un problema de inversión de prioridades, es decir cuando un proceso de
alta prioridad debe esperar que uno de baja prioridad se complete, liberando el canal de comunicación en este caso.
Además en los algoritmos de administración de la red existen varias limitaciones debido a que a diferencia de
un nodo la red tiene varios puntos de acceso en cada nodo, el usar preemption en los algoritmos de acceso a la red
no es una alternativa admisible dado que los mismo provocan que si un mensaje le expropia el recurso red a otro
luego de completado el mismo se debe retransmitir nuevamente el mensaje que fue cortado y habrá que poner
deadlines asociados con la disponibilidad del buffer.
Los protocolos estándares de Ethernet no soportan el tráfico con restricciones de tiempo rígidas ya que cuando
se produce una colisión de mensajes se introducen tiempos aleatorios y por ende se pierde el determinismo.
Por esto y en el sentido de que el recurso red debería ser al menos predecible se suelen usar tres esquemas que
garantizan esto último:
‰
TDMA: es una extensión de Round Robin para la red. Cada nodo dispone de un reloj sincronizado, y se le
asignan franjas de tiempo en las que puede comunicarse durante cada ciclo de comunicación. Existen
problemas al intentar planificar los procesos esporádicos y es muy eficiente para procesos periódicos.
‰
Esquemas de paso de testigo temporizado: cierto mensaje testigo (token) es pasado de un nodo a otro.
Los nodos pueden enviar los mensajes sólo cuando poseen el token impidiendo las colisiones. Cada nodo
posee el token durante un cierto tiempo, por ello el tiempo de rotación del token es limitado. Es usado en
FDDI (Fiber Distributed Data Interface), ControlNet y PROFIBUS.
‰
Protocolos Basados en Prioridad: Cada nodo indica la prioridad del dato que desea transmitir. Para
evitar colisiones se requiere un gran número de prioridades posibles para asignar. Por ejemplo CAN
(Controller Area Network) tiene destinado una cantidad de bits al comienzo de cada mensaje que indica la
prioridad. El problema que tiene es que la velocidad de transmisión resultada limitada.
‰
ATM: Permite la comunicación punto a punto mediante el uso de conmutadores. Soporta los requisitos de
comunicación para algunos SDTR flexibles, como por ejemplo transmisión de voz y video (usados en
videoconferencia, telefonía celular) y transmisión de datos.
VI . EJEMPLOS DE SDTR
Los SDTR están presentes en muchas áreas de implementación técnica. Así, los siguientes ejemplos exponen
dos aplicaciones distintas, ambas integradas de manera transparente a la vida cotidiana, el primero en el ámbito
industrial y el segundo en el área de desarrollo de aviónica.
REDES INDUSTRIALES
Las necesidades de control en aplicaciones industriales dependen fundamentalmente del tipo de sistema que se
quiere controlar, los objetivos que se desean alcanzar y el tipo de equipamiento a disposición. Las primeras redes de
comunicación industrial surgieron para resolver los problemas asociados con la distribución física de los
componentes del SD a controlar un sistema extendido físicamente. Desde mediados de los ’80, las innovaciones
tecnológicas han permitido la integración en sensores y actuadores de unidades de procesamiento de información e
interfaces de red, dando origen a los así llamados sensores y actuadores inteligentes, listos para ser usados a
distancia por un controlador remoto en un ambiente distribuido.
Para conectar estos dispositivos de campo (es decir los actuadores y los sensores), y los controladores (PLC’s,
reguladores, etc.) se utiliza una red de comunicación que se denomina bus de campo (fieldbus). El bus de campo
también es un sistema de comunicación en tiempo real que está basado en la estructura de capas del modelo OSI de
siete capas. Para cada capa del bus se pueden elegir distintos protocolos, los cuales proveen diferentes QoS según las
restricciones temporales.
Supervisor
Red de Supervisión
DCS
PLC
Bus de campo
Válvula
I/O
Encoder
Drive
Figura 7: Redes de control (con buses de campo).
Las redes industriales se organizan según tres niveles (Ferreira et al.). Cada uno de estos presenta características
propias de intercambio de información y utilizan diferentes equipos.
‰
El nivel más bajo (nivel de control discreto) trata con las conexiones físicas al nivel de I/O discretas (ej.,
sensores, contactores). Se manejan bits.
‰
El nivel intermedio (nivel de control de red) involucra a la red que une los controladores (PLC, DCS, PC´s de
control). Se requiere un flujo de información en tiempo real a fin de garantizar la actualización necesaria en los
controladores y las estaciones de monitoreo. Se manejan bytes.
‰
El nivel más alto está asociado con una red de computadoras que permite acceder a información de la planta
para su procesamiento y monitoreo estadístico (ej. SCADA). Se manejan paquetes.
La mayoría de los buses de campo proponen dos tipos de red: un bus de campo-control y un bus basado en
Ethernet para el nivel de información (Foundation Fieldbus propone H1 para el nivel de control y HSE para el nivel
de información). Otros buses del nivel más bajo (como AS-i) fueron diseñados para obtener comunicación de muy
bajo costo para un número reducido de equipos.
Para utilizar un bus industrial se deben satisfacer los siguientes requerimientos relacionados con el objetivo
final y con las restricciones temporales (restricciones de tiempo real), a saber:
‰
Disponibilidad operativa (Dependability) Asociado con la necesidad de que el bus permanezca siempre en
condiciones de operación confiable.
‰
Optimización del mantenimiento. Se requiere que la inclusión del bus radique en mejoras en el
mantenimiento general del sistema automatizado.
‰
Adaptabilidad del sistema. El bus debe permitir al sistema evolucionar con facilidad.
‰
Interoperabilidad. Capacidad de que equipos de distintos fabricantes puedan interactuar (o trabajar juntos)
para lograr un determinado objetivo.
‰
Periodicidad. capacidad de la red de transmitir todos los datos periódicos dentro de un determinado lapso
de tiempo.
‰
Jitter (varianza). Variación en la transmisión periódica de mensajes.
‰
Demora en la transferencia de mensajes. Los tiempos de respuesta de todo el sistema deben garantizar que
los datos lleguen a destino cuando aún son válidos.
‰
Coherencia Temporal. Se debe garantizar que todos los destinatarios de un dato reciben el mismo valor del
dato dentro de un intervalo de validez.
‰
Capacidad de respuesta ante eventos Se refiere a que se garantice la respuesta en un tiempo máximo del
sistema a la reacción ante alarmas o eventos esporádicos con ocurrencias no predecibles.
BOEING 787
En (Wlad) se presentan las nuevas tecnologías de software utilizadas en el programa de desarrollo de aviones
comerciales Boeing 787. También incluye una descripción de la evolución del software a lo largo de las tres
generaciones de diseño de aviónica (electrónica de aviación). A continuación resaltaremos un resumen de las
características más relevantes de este desarrollo.
El primer vuelo del 787 está planeado para 2007. Este avión de 2 motores tomará para ir desde New York a
Tokio un vuelo de menos de 13 horas. Cada asiento estará equipado con su propio teléfono celular, y conectividad a
internet. Una alta reducción del gasto de combustible en este avión se debe a la gran pérdida de peso de las
computadoras de a bordo.
Figura 8: Red de comunicaciones, sensores en el 787. Imagen tomada de (Wlad).
En este diseño Boeing expandirá el uso de su tecnología de aviónica modelar integrada (IMA), que fuera
incorporada en la tercera generación, mejorando la velocidad a la cual las aplicaciones pueden comunicarse entre sí.
El cerebro del 787 es el sistema núcleo común (CCS). Este CCS tiene que proveer un alto nivel de integridad para
aplicaciones de vuelo asegurando que los requerimientos de seguridad sean conseguidos y preservados.
El CCS está compuesto de recursos computarizados comunes (CCR), que son esencialmente un rack de cpu’s,
una red común de datos y concentradores de datos remotos. Se utiliza el sistema operativo particionado VxWorks
653 de Wind Rivers, el cual provee la partición robusta que se requiere para separar el software, completamente, de
manera que se puedan certificar los diferentes niveles de DO-178B (ver tabla). VxWorks maneja cientos de
aplicaciones software separadas en tiempo y en espacio. Este rango va desde funciones no-críticas como el control
del lavatorio hasta funciones críticas de vuelo como los display de los pilotos.
La red común de datos es Ethernet (aérea), y provee velocidades entre 10 y 100 Mbps. Para hacer que la red del
avión sea determinística y segura, el sistema debe ser impermeable a los efectos de fluctuaciones y colisiones de
datos.
Nivel de Software Condiciones de Falla
A
Catastrófico
B
Arriesgado/Severo
C
Mayor
D
Menor
E
Sin Efecto
Tabla 1. Niveles de software en aviónica comercial (DO-178B).
Por ello en el Boeing 787 se usa ADFX (Avionics Full - Duplex Switched Ethernet) que permite conseguir el
determinismo que requiere satisfacer la red. Con ADFX, cada conexión punto a punto ARINC 429 (utilizada a partir
de la segunda generación) es reemplazada por un link virtual. Este link virtual es una conexión entre sensores y
computadoras donde los cables dedicados fueron reemplazados por una red de cobre o fibra óptica y switches de
Ethernet. La tecnología AFDX elimina la colisión de datos usando canales dedicados a funciones de transmisión y
recepción. Con AFDX por ejemplo, si un sensor de temperatura quiere enviar un mensaje a la computadora de datos
de aire, un concentrador de datos digitaliza la medición del sensor, adjunta al mensaje una dirección y este dato es
routeado hasta su destino a tiempo.
BIBLIOGRAFÍA
(Blum) Blum, Isabelle, “Qualité de Service dans les réseaux locaux industriels: modélisation et évaluation – lien
avec les performances d’applications de contrôle-commande”, Thèse de Docteur de l’Université Paul Sabatier de
Toulouse, Enero 2000.
(Burns, Wellings), Burns A. y A. Wellings, “Sistemas de tiempo real y lenguajes de programación”, 3ª edición,
Pearson. Madrid 2003.
(De Giusti et al.), De Giusti A., H. Ramón , P. Fernandez, A. Artime, “Ingeniería de Software de Sistemas
distribuídos de Tiempo Real. Modelización y Evaluación de las Restricciones de Tiempo.” Depto. de Informática,
Fac. Ciencias Exactas, Universidad Nacional de La Plata.
(Ferreira et al.) Ferreira F, M. Feldgen y O. Clúa, “Requerimientos para aplicacion de buses de campo en control
industrial”, AADECA 2002. Bs. As. Argentina.
(Rogosin) Mike Rogosin, “Design strategies for real-time data in distributed systems”. Real-Time Innovations. Junio
2005. Disponible en www.rti.com
(Silverschatz y Galvin) Silverschatz A. y P. Galvin, “Operating System Concepts” , 5ed. Wesley 1997.
(Simón) Simón J., Tiempo y coordinación. Transparencias de Clase. Disponible en www.dsi.fceia.unr.edu.ar/sistdist
(Ramamritham et al.) Ramamritham K, Stankovic J. W. Zhao. “Distributed Scheduling of Tasks with Deadlines and
Resource Requirements” IEEE Transactions on computer. Vol. 38 8. Agosto 1989.
(Wlad) Joseph Wlad, “A new generation in aircraft avionics design”. Wind Rivers. Disponible en www.embeddedcontrol-europe.com