2. runes - PUC-Rio

Jordan Janeiro
UM ESTUDO COMPARATIVO ENTRE MIDDLEWARES
DESTINADOS A SISTEMAS EMBARCADOS
Monografia apresentada ao curso de Introdução à Computação Móvel,
como parte do programa de pós-graduação da PUC-Rio.
Prof. Orientador: Markus Endler
Departamento de Informática
Rio de Janeiro - RJ
06 de Novembro de 2006
Sumário
1 . Introdução
3
2 . RUNES
5
3 . MicroQoSCORBA
9
4 . OCP
13
5 . Comparação dos Middlewares
16
5.1. Avaliação do RUNES
17
5.2. Avaliação do MicroQoSCORBA
18
5.3. Avaliação do OCP
19
6 . Conclusão
22
7 . Referências
24
1. Introdução
Sistemas embarcados ou embutidos (embedded systems) refere-se aos
sistemas microprocessados, embutidos nos dispositivos que eles irão controlar, e
que são capazes de realizar operações específicas com recursos computacionais
restritos e direcionados especificamente para as tarefas do dispositivo. Para ser ter
uma certa dimensão do mercado de sistemas embutidos, o número de dispositivos
manufaturados engloba cerca de 11 bilhões de peças por ano [2]. Esse mercado
não inclui somente os dispositivos microeletrônicos em si, como também
ambientes de desenvolvimento e execução, e aplicações, desde aquelas
direcionadas para uma pequena cozinha como para sistemas de controle de
grandes aeronaves, como o Boeing 747 [2].
Na última década, a pesquisa em ambientes embarcados com suporte à rede
focou
quase
que
exclusivamente
no
desenvolvimento
de
dispositivos
miniaturizados, com grande capacidade de processamento e comunicação.
Portanto, pouca atenção foi dada à produção de software para estes sistemas. Com
isso, o software para esses sistemas começou a ser desenvolvido de uma forma
ad-hoc, com pouca ou nenhuma atenção para componentização e reusabilidade.
Mesmo quando esforços eram despendidos para prover tais características, a vasta
gama de dispositivos controlados usados em ambientes embarcados enunciava
uma grande complexidade na configuração, desenvolvimento e reconfiguração
dinâmica de software. Assim, fica evidente a necessidade de plataformas de
programação com abstrações que permitam atender um espectro mais amplo de
sistemas embarcados heterogêneos e que ofereça mecanismo para configurar,
desenvolver e reconfigurar dinamicamente o software para aplicações envolvendo
sistemas embarcados [1].
Tais plataformas englobam middlewares, que para sistemas embarcados
heterogêneos são, geralmente construídos na forma de frameworks, e que mais
recentemente estão sendo usados em sistemas embarcados pequenos com
diferentes graus de sucesso. Como muitas estações de trabalho possuem mais
memório cache da UCP do que esses sistemas embarcados possuem de memória
do tipo ROM ou RAM [2]. Middlewares de propósito geral desenvolvidos para
esses ambientes ricos em memória geralmente falham quando atingem ambientes
com poucos recursos em termos de memória. Outras soluções foram
desenvolvidas para pequenos dispositivos embarcados, porém tipicamente essas
soluções são pontuais e atendem apenas a um pequeno conjunto de requisitos,
implementadas de uma forma estática (código estático). Portanto, essas soluções
não possuem a flexibilidade necessária para suportar o grande número de
aplicações para sistemas embarcados, ou então não provêm o conjunto adequado
de requisitos apropriadas para as funcionalidades de uma determinada aplicação
ou hardware.
Uma outra deficiência dos middlewares atuais nessa área é a ausência de
suporte para as diversas propriedades de qualidade de serviço ( QoS ) como:
tolerância a falha, segurança e comportamento de tempo-real [2].
Middlewares do tipo CORBA, provaram ser uma ferramenta bastante
valiosa, para resolver diversos problemas relacionados à comunicação e
heterogeneidade em sistemas distribuídos de sistemas distribuídos. CORBA provê
uma excelente arquitetura de middleware, independente de plataforma, que
permite o desenvolvimento de aplicações orientadas a objetos distribuídas. Dentre
suas características, separa interfaces das implementações, encapsula protocolos
de rede e ambientes de execução de linguagens de programação, e provê um
grande conjunto de serviços e APIs. Por essa razão muitos dos middlewares
existentes se baseiam em características do CORBA.
Nas próximas seções serão apresentados alguns tipos de middlewares
voltados para sistemas embarcados. Em seguida será apresentada uma
comparação entre estes middlewares com relação a de alguns parâmetros
definidos e explicados na Seção 5, e ao final, será apresentada uma conclusão
sobre o estudo.
2. RUNES
RUNES (Reconfigurable, Ubiquitous, Networked Embedded Systems) é um
projeto que visa criar uma arquitetura de uma plataforma de desenvolvimento para
sistemas embarcados em rede. Essa arquitetura abrange camadas de rádio
dedicadas, suporte a redes, um middleware e ferramentas específicas para
verificação e simulação de software [2].
A plataforma de programação, que é o núcleo dessa arquitetura, é formada
por um middleware baseado em componentes que separa e encapsula
funcionalidades providas pelos seus diversos componentes através de interfaces
bem definidas. Essa separação de funcionalidades presentes no middleware, não
apenas permite o desenvolvimento de variantes de um mesmo componente, como
também permite a reconfiguração dinâmica de instâncias de componentes e suas
interconexões. Essas características permitem a adaptação dinâmica da plataforma
de acordo com o contexto no qual ela está inserida, o que é um requisito
fundamental para ciência de contexto [2].
Uma característica do RUNES (middleware) é envolver funções que
tipicamente são consideradas da camada de rede e do sistema operacional. Dessa
forma o RUNES é capaz de prover acesso unificado à configuração,
desenvolvimento e reconfiguração em diversos níveis de abstração.
A abordagem do projeto considera a construção do middleware através de
uma linguagem de modelo de componentes, independente de qualquer modelo de
componentes concreto, e oferecer um conjunto de APIs genéricas para que tal
middleware seja utilizado.
Essas APIs genéricas são interfaces abstratas, por isso a implementação
delas pode ser feita posteriormente. Fica a cargo do programador escolher a
melhor forma de implementar as operações das quais a API se propõe a cumprir,
bem como a linguagem de programação a ser utilizada. Por exemplo, o
middleware pode definir a API enviar( menssagem, remetente, destinatário ). Em
um PDA com um sistema operacional convencional, essa interface pode ser
implementada utilizando classes da linguagem Java, ou no caso de um sistema
operacional Linux utilizando shared objects desenvolvido na linguagem C,
enquanto que em um microcontrolador de um nó sensor, os componentes podem
ser implementdos simplesmente como segmentos de código de máquina. Assim
todos os dispositivos implementam a mesma interface de formas diferentes, pois o
modelo de componentes é local e dependente do dispositivo.
O modelo genérico de componentes introduzido pelo RUNES é o
apresentado na ilustração a seguir, ele se baseia no Lancaster’s OpenCOM. Os
elementos do modelo de componentes são: componentes, cápsulas, interfaces,
receptáculos
e
ligações.
Componentes
são
unidades
encapsuladas
de
funcionalidade ou de desenvolvimento, que interagem com outros componentes
exclusivamente através de interfaces ou receptáculos. Cápsulas são entidades que
abrangem os elementos do modelo de componentes; é através delas que são
oferecidas as APIs de execução. Assim, as cápsulas podem ser implementadas
diferentemente em diferentes dispositivos. Interfaces são expressas em termos de
grupos de assinaturas e tipos de dados. Receptáculos são interfaces requeridas que
são usadas para explicitar as dependências de um componente. As ligações são
associações entre interfaces simples e receptáculos. [2].
Figura 1 – Elementos do Modelo de Componentes do RUNES
Esse modelo pode ser complementado por mais duas arquiteturas de
elementos: component frameworks e reflective meta-models.
Um component framework (CF) é uma composição de componentes
encapsulado, cuja finalidade é tratar de uma determinada área ou funcionalidade
do sistema. Essa composição também deve aceitar componentes adicionais (plugins) que modificam ou estendem o comportamento de um determinado CF. Cada
CF deve oferecer um conjunto de APIs genéricas para permitir sua utilização.
Alguns exemplos de CFs são:

Serviços locais do sistema operacional: esse CF é responsável por
prover funcionalidades, implementadas por grupos de plug-ins,
geralmente oferecidas por sistemas operacionais locais como:
políticas de escalonamento, gerenciamento de memória e protocolos
MAC. Cada plug-in de um grupo implementa diferentes versões das
funcionalidades oferecias por seu grupo. Por exemplo, no grupo de
políticas de escalonamento, cada plug-in poderia implementar uma
politica diferente;

Serviços de rede: Possuem diversos plug-ins de forma que o
objetivo de cada um deles seja implementar uma tecnologia de rede
específica. Aqui devem ser implementados protocolos para redes adhoc e redes infra-estruturadas. O CF deve disponibilizar APIs
genéricas para serem utilizadas por desenvolvedores, como:
send(message,address), para unicast; sendToAll(message) para
broadcast e sendToGroup(message, topic) para multicast.

Serviços de localização: esse CF deve ser responsável por conhecer
ou obter a posição física ou lógica do dispositivo host, no qual ele
está implantado. Ele poderia implementar um plug-in que obtivesse
dados de localização diretamente de um sensor GPS presente no
dispositivo, ou poderia implementar um plug-in que interagisse com
outros nós equipados com sensors GPS.
Alguns outros exemplos de CF são: serviços de descoberta e notificação e
serviços de coordenação.
As vantagens de utilizar CF’s são:

Eles provêem uma abstração intermediária entre os componentes e
todo o sistema, dessa forma, essa abstração permite aumentar a
compreensibilidade e a mantenabilidade do sistema;

Eles simplificam o desenvolvimento de componentes, devido ao
reuso de outros componentes e ao direcionamento do foco de um
CF; e

Eles dão suporte ao compartilhamento de componentes leves
(lightweight), chamados de plug-ins, que atuam modificando as
funcionalidades de um CF.
A finalidade da reflexão é estabelecer e manipular meta-modelos de
sistemas, que estão conectados de forma causal. Tais meta-modelos são
representações de alguns aspectos ou visões de um sistema, e eles disponibilizam
as chamadas meta-interfaces, através das quais a representação do sistema, ou
parte dele, pode ser inspecionada ou manipulada. O maior benefício do uso da
reflexão é separar de forma arquitetural a construção do sistema (ou
configuração), da adaptação do sistema (ou reconfiguração).
O objetivo do RUNES é desenvolver meta-modelos reflexivos conectados
aos CFs. A idéia é que CFs possam encapsular meta-interfaces, e controlar os
acesso a elas. Além disso, tal encapsulamento também pode garantir que as metainterfaces serão acessadas apenas em condições adequadas. Por exemplo, um CF
pode restringir a substituição de componentes de um sistema, seguindo um metamodelo arquitetural (construído para um sistema visando à substituição de seus
componentes), às situações onde nenhuma invocação está sendo feita ao antigo
componente. Além disso, um CF pode implementar um protocolo para transmitir
o estado de execução, do componente substituído para o novo.
3. MicroQoSCORBA
MicroQoSCORBA é um middleware, projetado como um framework, e que
possui adicionalmente um toolkit de suporte ao desenvolvimento, que pode ser
utilizado em dispositivos com poucos recursos de memória. Seu principal objetivo
é a flexibilidade para sofrer adaptações direcionadas a atender propriedades
específicas de hardware, tais como baixa capacidade de processamento e pouca
disponibilidade de memória, assim como requisitos de configuração de aplicações.
MicroQoSCORBA, ele foi desenvolvido para dar apoio a diversas propriedades de
QoS, tais como: tolerância a falha, segurança e comportamento em tempo-real
(responsividade).
Sua capacidade de atender uma grande diversidade de dispositivos
embarcados se deve à exploração dos recursos individuais de cada dispositivo,
assim como a utilização de adaptações na arquitetura padrão CORBA. A maior
parte das adaptações feitas no MicroQoSCORBA são baseadas em determinadas
escolhas feitas pelo arquiteto do sistema durante a fase de projeto da aplicação.
Em seguida, esses parâmetros de configuração são encaminhadas para o
compilador IDL do MicroQoSCORBA, que se encarrega de gerar os componentes
correspondentes.
Figura 2 – Arquitetura do MicroQoSCORBA
Como em todos os ambiente de desenvolvimento CORBA, há um
compilador IDL, que é responsável por processar os arquivos IDL da aplicação e
produzir os códigos dos stubs e esqueletos. No caso desse middleware, houve a
necessidade de alterar o compilador IDL padrão, para que este não gere objetos
com um tamanho convencional, em termos de memória, pois isso seria
inapropriado para dispositivos com capacidade restrita de memória. Portanto, para
solucionar esse problema, o compilador IDL do MicroQoSCORBA, gera stubs e
esqueletos de código que são otimizados e configurados para usar determinadas
implementações customizadas de ORBs e POAs (Portable Object Adapter)
especificadas pelo desenvolvedor na fase inicial do projeto de uma aplicação de
sistema embarcado.
Muitas alterações podem ser feitas apenas nos códigos de stubs e esqueletos
para reduzir (ou aprimorar) o uso de recursos de uma determinada aplicação. Os
aperfeiçoamentos posteriores devem ser feitos otimizando as implementações de
ORBs. Devido à fina granularidade do projeto e implementação do
MicroQoSCORBA, este dá suporte à diversas configurações e otimizações de
ORBs, cada uma com seu perfil de uso de recursos e performance. Muitas das
implementações especializadas de ORBs mantém uma boa interoperabilidade com
outras implementações-padrão de ORBs. No entanto, em determinados casos, o
desenvolvimento precisa abrir mão da interoperabilidade, em troca de atender
requisitos específicos da plataforma de software e do hardware.
Como a capacidade de comunicação de um dispositivo embarcado é restrita,
e há a necessidade de camadas de comunicação bastante leves, o
MicroQoSCORBA faz com que no lado do cliente, os stubs gerados pelo IDL
possuam referências para diversos protocolos e camadas de transporte que podem
ser usados dependendo da sua disponibilidade em dispositivos em questão (Figura
2). As escolhas dessas referências são enviadas para os ORBs, de forma que
mensagens possam ser enviadas ou recebidas devidamente. Inicialmente, o
middleware suportava o IIOP, um protocolo baseado em TCP/IP e que inclua
muito código, e dependendo mais da aplicação do que do código da própria
aplicação [2]. O middleware também implementa um suporte ao UDP. Além
desses protocolos, o MicroQoSCORBA também usa subconjuntos de protocolos
de comunicação padrão do CORBA considerados leves. Tais subconjuntos são
resultados de escolhas de projeto que irão permitir a remoção de funcionalidades
desnecessárias, tais como: tratamento de mensagens desnecessárias, tipos de
dados extensos e exceções.
No MicroQoSCORBA é possível prover serviços com diferentes níveis de
qualidade (QoS). Portanto, o middleware oferece suporte à requisitos de QoS
relativos a tolerância à falha, segurança e responsividade. Portanto, em cada um
desses subsistemas, há algumas implementações de diferentes mecanismos de
QoS, que oferecem serviços que permitam balancear entre QoS e consumo de
recursos, como: cifragem de dados versus latência ou latência versus
gerenciamento de energia. No subsistema de tolerancia à falha, há mecanismos de
redundância temporal (onde k mensagens podem ser omitidas) e redundância de
valor (através do CRC32, que é anexado à mensagem) que podem ser usados. No
subsistema de segurança há o mecanismo baseado em confidencialidade (os
canais de informações e os canais de comandos podem ser separados em redes
diferentes) [2].
Para auxiliar o desenvolvedor no projeto e configuração de suas aplicações,
o MicroQoSCORBA conta com diversas ferramentas. Dentre elas há uma
ferramenta de configuração baseada em GUI, um gerador de código IDL, a
ferramenta make, ferramentas de desenvolvimento Java, ferramentas para o
hardware de dispositivos específicos e um processador de macros (m4). As
macros são usadas no ambiente de desenvolvimento para esconder algumas
diferenças entre a versão padrão Java e versão do Java móvel. Elas também
permitem um mecanismo leve para encapsular mecanismos de QoS do
MicroQoSCORBA.
4. OCP
O OCP (Open Control Platform) é um componente de tecnologia de
software importante para o programa de pesquisa SEC (Software Enabled
Control) financiado pelo DARPA (United States Defense Advanced Research
Projects Agency). O maior objetivo do SEC é desenvolver uma nova tecnologia de
software que permita novas aplicações de controle que são intratáveis usando as
metodologias atuais.
Na prática, O OCP é uma infraestrutura de software orientado a objetos que
foi projetada para analisar, desenvolver e testar algoritmos de controle para UAVs
(Uninhabited Aerial Vehicles) e sistemas de software embarcado. Essa plataforma
inclui um middleware, projetado como um framework, para integrar componentes
de aplicações de sistemas embarcados com serviços importantes para o domínio
de controle de UAVs; um simulador, projetado como um framework, para
simulações de software de UAVs e que se integra com outros simuladores; e uma
ferramenta para integração com ferramentas de projeto e análise de sistemas
embarcados.
Para conseguir resolver alguns desafios como: o convívio com sistemas
híbridos, controle multi-modal e requisitos de tempo real relacionados ao controle
de vôo de baixo nível, o middleware OCP, optou por utilizar a arquitetura do realtime common object request broker (RT CORBA) em sua implementação.
O OCP tem sua herança num software financiada pela Boeing, baseado em
CORBA, chamado de Bold Stroke. Esse software foi inicialmente desenvolvido na
Boeing com o intuito de fornecer uma abordagem de linha de produção para o
desenvolvimento de software de aviônica para os caças produzidos pela McDonell
Douglas Corporation.
O foco do Bold Stroke era restrito à classe de aplicações de sistemas
embarcados chamada de Mission Computing. Essa classe de sistemas trata de
tarefas realizadas a bordo, tais como: navegação, interface piloto-veículo (PilotVehicle Interface - PVI) e controle de armas. Porém, o middleware não foi usado
para o processamento do gerenciamento de veículos, onde controles de vôo
críticos são implementados. Portanto, um dos objetivos do OCP é permitir o
desenvolvimento de software para suportar todos os níveis de controle de vôo de
UAVs.
O middleware pode ser usado para integrar componentes de aplicações de
sistemas embarcados, controlando sua execução e comunicação. O ambiente de
simulação permite que as aplicações executem e sejam testadas em um mundo
virtual, onde é possível efetuar a leitura de sensores simulados e simular pilotos.
A ferramenta de integração provê a possibilidade de ligação com importantes
ferramentas de análise e projeto, como o Matlab/Simulink e o Ptolemy II,
permitindo que o controle de projetos feitos nessas ferramentas seja facilmente
transformado em aplicações de sistemas embarcados que usam o middleware
OCP.
A seguir segue uma ilustração da arquitetura do Bold Stroke e não do OCP,
pois esse último se encontrava em fase de construção (na época que o artigo foi
produzido). Porém, o OCP pretende implementar as seguintes características,
além das já providas pelo Bold Stroke: escalonamento dinâmico, gerenciamento
de recursos adaptativo, reconfiguração dinâmica, suporte a sistemas híbridos, e
acesso facilitado a gatilhos (triggers) de tempo real, sensores e atuadores
(simulação de pilotos).
Figura 3 – Arquitetura do Bold Stroke
O OCP é um middleware que está sendo escrito na linguagem de
programação C++. Ele inclui um componente RT CORBA que usa o ACE
(Adaptative Communication Environment) e o TAO (The ACE ORB), esse último
responsável por prover uma extensão de tempo real para o CORBA. Ainda sobre
o ACE e o TAO, algumas extensões de tempo real foram desenvolvidas pela
Boeing para serem utilizadas nas aplicações de sistemas embarcados do tipo
Gerenciamento de Missões (Mission Management) de seus caças.
Para aplicar as características do CORBA no domínio das aplicações críticas
de tempo real de aviões-caça, o software Boeing Bold Stroke, utilizou as
extensões de tempo real do TAO.
Diversas inovações estão sendo implementadas ao middleware que usa
ACE/TAO para aplicações de gerenciamento de missões em caças. Essas
inovações são necessárias para os desafios de controle de vôo de baixo nível e
para suportar as técnicas de controle de atalhos que sobrecarregam os recursos do
computador de bordo do veículo. As inovações são: implementação do
escalonamento dinâmico e gerenciamento de recursos adaptativo em um
framework de gerenciamento de recursos, suporte a sistemas híbridos e suporte
para gatilhos de tempo precisos no nível de aplicação.
5. Comparação dos Middlewares
Nesta seção serão comparados os middlewares apresentados, em relação a
determinados parâmetros: área de aplicação, maturidade, classificação de tempo
real, paradigma de programação, tolerância à falhas, heterogeneidade,
interoperabilidade,
adaptação
dinâmica,
extensibilidade,
ferramentas
de
simulação, ambientes de execução e usabilidade.
A seguir será apresentada uma lista com todos os parâmetros, que servem
de base para a comparação entre os middlewares, e a descrição do cada um deles
representa.

Área de aplicação: refere-se à área para qual o middleware foi
projetado ou a área na qual ele se destacou sendo utilizado ou
testado;

Maturidade: refere-se ao tempo de uso do middleware em um
cenário real, que não seja apenas um ambiente de testes;

Classificação de tempo real: refere-se à classificação do
middleware como um sistema de tempo real suave (soft) ou rígido
(hard);

Paradigma de programação: refere-se ao padrão de técnicas que
foram utilizados na implementação ou que são disponibilizadas pelo
middleware;

Tolerância à falhas: refere-se aos mecanismos que o middleware
possui para tolerar certos tipos de falhas;

Heterogeneidade: refere-se ao número de plataformas no qual o
middleware pode ser implantado sem ser modificado;

Interoperabilidade: refere-se à facilidade que o middleware tem
para se comunicar com outros sistemas;

Adaptação dinâmica: refere-se à capacidade do middleware se
adaptar dinamicamente (em tempo de execução) a quaisquer tipos de
mudança;

Extensibilidade: refere-se à facilidade com que podem ser
agregadas novas funcionalidades ao middleware;

Ferramentas de simulação: refere-se às ferramentas de simulação
que o middleware disponibiliza para testar suas aplicações;

Ambiente de execução: refere-se aos ambientes de execução no
qual o middleware foi usado; e

Usabilidade: refere-se à facilidade que um desenvolvedor tem para
utilizar o middleware.
5.1. Avaliação do RUNES
Área de aplicação: Não há uma área específica definida, porém seus testes se
voltaram para a área civil, permitindo a coordenação de equipes para o combate a
incêndios.
Maturidade: A maturidade do sistema é baixa. O grupo trabalhou na
implementação das API’s do middleware sobre o sistema operacional Contiki,
voltado para redes de sensores. Dessa forma seria possível validar nesse teste a
viabilidade do uso do RUNES em ambientes com recursos escassos. O grupo
também trabalhou para usar o RUNES em um ambiente de teste no cenário de
combate a incêndios, onde são utilizados pelo menos três tipos de dispositivos:
nós sensores, PDAs e computadores do tipo estações de trabalho.
Classificação de tempo real: Pelo que pude avaliar no middleware, parece ser do
tipo soft, pois o cenário mais crítico no qual ele foi testado refere-se ao combate
de incêndios, o que imagino que seja permitido alguma margem mínima de atraso
no sistema.
Paradigma de programação: No RUNES define-se o modelo de componentes e
a implementação pode ser feita utilizando qualquer linguagem de programação.
Porém se utilizam técnicas de frameworks e reflexão computacional.
Tolerância a falhas: Não há nenhum mecanismo pré-definido, porém podem ser
criados através dos CF’s e dos meta-modelos reflexivos.
Heterogeneidade: É atingida devido à abstração do middleware. Depois de
definidas as interfaces, a linguagem de programação a ser utilizada fica a cargo do
desenvolvedor
Interoperabilidade: A interoperabilidade é atingida devido a utilização do
modelo de componentes, pois as interfaces são bem definidas e independentes de
uma linguagem de programação específica.
Adaptação dinâmica: É permitida a reconfiguração dinâmica dos componentes e
suas interconexões.
Extensibilidade: Através dos component frameworks e dos meta-modelos, é
possível estender, sempre que desejado, as funcionalidades do middleware
definindo novos CF’s.
Ferramentas de simulação: Utiliza o TrueTime, uma ferramenta baseada no
MatLab.
Ambiente de execução: Dispositivos utilizando o sistema operacional Contiki.
Usabilidade: Deve-se saber utilizar o modelo de componentes OpenCOM de
Lancaster e no mínimo uma linguagem de programação de escolha do
desenvolvedor para implementar os CF’s. Também é necessário conhecer reflexão
computacional.
5.2. Avaliação do MicroQoSCORBA
Área de aplicação: Genérica, o sistema ainda não se dedicou a uma área
específica.
Maturidade: Pouca.
Classificação de tempo real: Esse sistema parece ser um sistema de tempo real
do tipo hard, pois suas preocupações com QoS (tolerância à falhas, segurança e
responsividade) demonstram tal comportamento.
Paradigma de programação: Esse middleware utiliza CORBA, portanto não há
um paradigma de programação previamente definido, pois não há uma linguagem
de programação definida.
Tolerância a falhas: O middleware provê mecanismos de tolerância à falhas. Os
mecanismos implementados foram de redundância temporal, redundância
espacial, redundância de valor, detecção de falhas e comunicação de grupo.
Heterogeneidade: Através desse middleware é possível adequar aplicações para
determinados requisitos de hardware e software. Um fator muito importante para
isso é o uso de CORBA.
Interoperabilidade: A interoperabilidade é atingida através do uso do CORBA,
que possui bindings (interfaces) para várias linguagens.
Adaptação dinâmica: É possível que sejam feitas adaptações dinâmicas.
Extensibilidade: A extensibilidade é facilitada. Para prover novas soluções
otimizadas para o middleware é necessário alterar o compilador IDL.
Ferramentas de simulação: Não foi encontrada a ferramenta de simulação do
toolkit do sistema.
Ambiente de execução: Placas TINI da Dallas Semiconductor, placas SaJe da
Systronix e plataformas Linux x86. Todas as plataformas possuíam Java Virtual
Machines, já que o protótipo testado foi construído na linguagem de programação
Java.
Usabilidade: Deve-se saber utilizar o compilador IDL da arquitetura e a
arquitetura CORBA.
5.3. Avaliação do OCP
Área de aplicação: Militar, voltado para controle de veículos aéreos de combate
não-tripulados (UCAV).
Maturidade: A maturidade do sistema é muito alta. Pois o Bold Stroke (a base do
OCP, financiado pelo DARPA e pela USAF) já é utilizado nos softwares de
aviônica de UCAVs.
Classificação de tempo real: Esse middleware pode ser considerado um sistema
de tempo real hard, por ser voltado para o controle de veículo aéreos.
Paradigma de programação: O paradigma de programação é orientado a
objetos. O middleware foi construido usando C++. O middleware inclui um
componente RT CORBA, que permite o uso do ACE e TAO.
Tolerância a falhas: Não há mecanismos explícitos
Heterogeneidade: A heterogeneidade é atingida nesse middleware. Na fase de
testes do OCP, ele foi implantado em um UAV e um avião-caça guiado por um
piloto. Através do OCP foi possível a comunicação entre os sistemas dos dois
veículos aéreos [3]. Porém não são todas as plataformas que podem suportar todos
os recursos da linguagem C++.
Interoperabilidade: A interoperabilidade não parece ser atingida de uma forma
tão ampla, uma vez que o middleware foi implementado usando a linguagem C++.
Adaptação dinâmica: É possível que sejam feitas adaptações dinâmicas,
acoplando novos subsistemas na forma de plug-ins.
Extensibilidade: Sua extensibilidade não é tão grande, pois aqui deve-se extender
classes utilizando a linguagem C++. Para adicionar funcionalidades aos
mecanismos que tratam do comportamento de tempo real do middleware, deve-se
alterar funcionalidades oferecidas pelos objetos ACE/TAO do RT CORBA.
Ferramentas de simulação: Utiliza o Simulink.
Ambiente de execução: Os ambientes iniciais apena para um pré-teste foram o
Windows NT e Linux. Posteriormente na fase de testes reais, foram utilizados os
sistemas operacionais VxWorks e QNX, que são sistemas POSIX de tempo real.
Usabilidade: Deve-se ter domínio da linguagem de programação C++ e saber
utilizar o RT CORBA (ACE/TAO).
A seguir é apresentada a tabela com o resumo da avaliação dos middlewares,
baseado em seus parâmtros.
OCP
Área de aplicação
MicroQoSCORBA RUNES
Controle
de
veículos
aéreos
Combate
Genérica
não-habitados
(seus sistemas)
Maturidade
Classificação
de
tempo real
Paradigma
Tolerância
Falhas
Heterogeneidade
à
(primeiro
teste
feito)
Baixa
Média
Hard
Hard
Soft
objetos
programação
incêndios
Alta
de Orientado
a
a
Frameworks
ORB
Reflexão
Computacional
Ausente
Presente
Ausente
Média
Média-Alta
Alta
e
Interoperabilidade Baixa
Adaptação
dinâmica
Extensibilidade
Ferramentas
Alta
Alta
Presente
Presente
Presente
Baixa
Alta
Alta
Ausente
TrueTime
de Simulink
Simulação
Nos
Ambientes
Execução
sistemas No
de operacionais:
sistema No
sistema
operacional Linux e operacional
Windows, Linux, nas placas SaJe e Contiki
VxWorks e QNX TINI
(sensores)
Difícil
(Framework,
Usabilidade
Fácil (C++)
Média (CORBA)
Reflexão
Computacional,
OpenCOM)
Tabela 1: Resumo das Comparações dos Middlewares
6. Conclusão
Esse capítulo de conclusão será destinado aos pareceres finais da
comparação dos middlewares, feitos através dos parâmetros do capítulo anterior.
O primeiro fator a ser avaliado é a arquitetura dos middlewares, o segundo é a
qualidade de serviço provida e o terceiro a confiabilidade. Em cada um desses
fatores será apresentado o middleware que melhor atende o fator.
O primeiro fator a ser descrito é a arquitetura de cada middleware. Nesse
foco, o destaque é o RUNES. Pois sua capacidade de trabalhar em uma camada
abstrata o torna um opção muito boa para os sistemas embarcados. Cabe lembrar
que ele utiliza o modelo de componentes para definir apenas as interfaces entre os
componentes. Ele também utiliza os chamados Component Frameworks para
automatizarem e encapsularem áreas funcionais do middleware. Ele é flexível o
bastante para permitir que novas funcionalidades sejam alteradas em tempo de
execução apenas acoplando novos plug-ins aos CF’s, ou agregando e
desagregando componentes. Ele também utiliza a reflexão computacional,
permitindo que o sistema possa ser alterado de uma forma mais concisa e
automatizada, evitando erros comuns de desenvolvedores. No caso do OCP, por
mais que ele utilize componentes RT CORBA (ACE/TAO), o middleware foi
implementado em C++ e sua arquitetura já é previamente definida. Devido a essa
característica o middleware perde um pouco de flexibilidade em comparação ao
RUNES. Já no caso do MicroQoSCORBA, ele é mais flexível que o OCP, pelo
fato de utilizar CORBA, porém ainda assim é considerado inferior ao RUNES por
não possuir um modelo dinâmico, como a reflexão computacional, para permitir a
configuração automática do sistema. Além disso ele também não conta com o
modelo de Component Frameworks, onde pode-se criar mecanismo de controle
direcionados para determinadas áreas apenas com a composição de componentes.
O segundo fator é a qualidade de serviço. Quanto a essa perspectiva, é
incontestável a vantagem do MicroQoSCORBA em relação aos outros
middlewares, pois ele é o único dos três que se preocupa explicitamente com
requisitos não-funcionais como: tolerância à falhas, segurança e responsividade,
de uma forma ampla. Nem mesmo o OCP, que é um middleware voltado para
aplicações realmente críticas, menciona suas preocupações quanto à QoS,
abertamente, em sua arquitetura como o MicroQoSCORBA. Certamente, o OCP
implementa mecanismo de forma otimizada para permitir que os serviços sejam
realizados da melhor forma possível, porém nada a ponto de se comparar a uma
adaptação dinâmica para permitir diferentes níveis de serviços.
O terceiro fator é a confiabilidade e maturidade do middleware. Nesse
quesito, o OCP é superior a todos os outros. Sua base (o middleware Bold Stroke),
foi usado nos aviões-caça produzido pela McDonnell Douglas Corporation para
controlar todos os sistemas do avião, com exceção do chamado gerenciamento de
veículo. Seu foco (OCP) agora está na implantação de todos os sistemas,
incluindo o gerenciamento do veículo, dos chamados UCAVs. Por mais que
alguns testes tenham sido executados no RUNES e no MicroQoSCORBA, eles
ainda não estão tão operacionais e não foram testados em situações tão reais
quanto o OCP, como na demonstração de um ataque coordenado entre um aviãocaça e um UCAV, que recebe sua missão em pleno vôo pelo piloto do caça, que
está coordenando o ataque.
Todos os middlewares representam plataformas que fornecem serviços abstratos
para os desenvolvedores de aplicações, facilitando o desenvolvimento das
mesmas, já que não há a preocupação de se programar para uma plataforma
específica. Porém no caso dos sistemas embarcados, fica difícil oferecer uma
abstração única para os desenvolvedores, já que as plataformas são muito
diferentes. Dessa forma, seria necessário que o middleware soubesse lhe dar com
uma diversidade muito grande de hardwares. Devido a esse problema, pôde-se
notar que todos os middlewares, com exceção do OCP, são definidos de tal forma
que detalhes de implementação não são tratados. O MicroQoSCORBA, por
exemplo, se preocupa em otimizar o código de objetos CORBA, postergando a
instanciação do framework. O RUNES é o mais abstrato de todos, pois ele apenas
define as interfaces (independentes de plataforma) e recomenda algumas
funcionalidades que devem ser oferecidas (através dos CFs). O único middleware
que é uma plataforma previamente implementada para fornecer serviços abstratos
é o OCP, que está direcionado para os sistemas operacionais descritos
anteriormente e encontra-se implementado em C++.
7. Referências
[1] P.Costa, G. Coulson, C. Mascolo, G. Picco, S. Zachariadis. The RUNES
Middleware: A Reconfigurable Component-based Approach to Networked
Embedded Systems. 2005.
[2] A. McKinnon, K. Dorow, T. Damania, O. Haugan, W. Lawrence, D. Bakken,
J. Shovic. A Configurable Middleware Framework with Multiple Quality of
Service Properties for Small Embedded Systems. 2003.
[3] J. Paunicka, B. Mendel, D. Corman. The OCP - An Open Middleware
Solution for Embedded Systems. 2001.