Middlewares para Sistemas
Embarcados (Embutidos)
Jordan Janeiro
Introdução - Esclarecimento

Sistemas embarcados ou sistemas
embutidos?
Introdução - Definição

O que são sistemas embarcados?
–
São sistemas microprocessados, embutidos nos
dispositivos que eles irão controlar, capazes de
realizar tarefas específicas com recursos
computacionais restritos.
Dificuldades

Escassez de recursos.
–

Forma de programação atingida.
–

Estações de trabalho com memória cache da
UCP maior do que memória ROM ou RAM de
dispositivos embarcados.
Algoritmos otimizados.
Lembra o passado.
Demanda

Não se deve menosprezar o mercado !
–

11 bilhões de dispositivos manufaturados por ano
(2003).
Porém o mercado foi menosprezado no
início e ...
Motivação





Devido ao ciclo da oferta x demanda, o
mercado de hardware obteve maior atenção.
Fábricas de software ignoradas.
Desenvolvimento de software ad-hoc.
Problemas com heterogeneidade de
equipamentos.
Reflexão ...
Middlewares

MicroQoSCORBA

OCP - Open Control Platform

RUNES - Reconfigurable, Ubiquitous,
Networked Embedded Systems
MicroQoSCORBA – Visão Geral




Sistema baseado em CORBA.
Adaptações no compilador IDL.
Adaptações na interação entre ORBs.
Tecnologia de comunicação das camadas
mais baixas alterada.
MicroQoSCORBA – Compilador IDL


Configurar arquivos e gerar stubs e esqueletos.
Não é um compilador genérico (one size fits
all).
–

Gera códigos otimizados para determinados ORBs
customizados.
Permite que códigos de protocolos e da
camada de transporte sejam selecionados e
codificados nos stubs.
–
–
Remove complexidade do ORB;
Elimina ligação desnecessária com o código de
protocolos e transportes no lado do cliente;
MicroQoSCORBA – Customização de
ORBs


Muito pode ser feito no código do stub ou
esqueleto para reduzir o uso de recursos.
ORBs podem ser customizados.
–

Eles podem ser configurados para possuírem perfis
de uso de recursos e perfomance.
ORBs customizados mantém interoperabilidade
com ORBs padrão.
–
Interoperabilidade x Requisitos de HW e SW
MicroQoSCORBA - Comunicação


Suporta IIOP e UDP.
Suporta também um subconjunto de padrões de
comunicação CORBA (MQC IOP).
–

São eliminadas: exceções, tipos de dado muito
grandes e mensagens desnecessárias.
Adiciona na arquitetura CORBA uma camada de
transporte
–
Dessa forma camadas de transporte específicas de
um ambiente serão desenvolvidas conforme
necessário.
MicroQoSCORBA - QoS

Suporta alguns requisitos de QoS.
–

Tolerância à falhas (redundância temporal e redundância
por valor), segurança (separar canais de controle dos
canais de dados) e responsividade.
Cada um dos requisitos possui diferentes
mecanismos implementados que ponderam QoS x
Consumo de Recursos.
–
Criptografia x latência x uso de memória e energia.
OCP – Visão Geral

Baseado no Bold Stroke.

Utiliza componentes do RT CORBA (ACE/TAO).

Agrega novas funcionalidades ao Bold Stroke.

Ferramentas de simulação e integração em
anexo.
–
Simulink
OCP – Herança (Bold Stroke)





Baseado em CORBA.
Software financiado pela Boeing.
Utilizado nos caças da McDonell Douglas Corporation.
Implementava todos os sistemas (navegação, interface
piloto-veículo e controle de armas).
Não era utilizado no gerenciamento do veículo.
–

Controles de vôo críticos eram implementados.
Seus maiores objetivos são: implementar o
gerenciamento do veículo no middleware (OCP) e
permitir todos os níveis de controle de vôo de UAVs.
OCP – RT CORBA


O ACE/TAO foi usado para permitir o
desenvolvimento de aplicações de controle de vôo.
Era necessário algumas otimizações.
–
–
–
Prover eventos leves para diminuir o fluxo de mensagens
no agente central do Serviço de Eventos de TR do TAO.
Cache local de um objeto distribuído no lado do cliente,
evitando que a thread fique bloqueada e que o canal de
eventos fique congestionado.
Suporte a protocolos plugáveis (GIOP-lite sobre memória
compartilhada).
OCP - Novas funcionalidades



Implementa um framework para
gerenciamento de recursos, garantindo a
qualidade de serviço de um aplicação.
Suporte a sistemas híbridos
Suporte a gatilho de tempo precisos nos
nível de aplicação.
–
Foi criado um framework para encapsular tarefas
específicas de hardware, expondo-as para uma
aplicação através de uma interface limpa.
RUNES - Visão Geral



A construção do middleware se baseia em
uma linguagem independente de modelos de
componentes (OpenCOM de Lancaster).
Complementado pelos Component
Frameworks
Complementado pelos Meta-modelos
reflexivos
RUNES – Modelo de Componentes
Comparações (1/2)
OCP
MicroQoSCORBA
RUNES
Área de aplicação
Controle de veículos aéreos nãohabitados (seus sistemas)
Genérica
Combate a incêndios
(primeiro teste feito)
Maturidade
Muito Alta
Média
Média
Classificação de
tempo real
Hard
Hard
Soft
Paradigma de
programação
Orientado a objetos
ORB
Frameworks e Reflexão
Computacional
Tolerância à
Falhas
Presente
Presente
Ausente
Heterogeneidade
Média
Média-Alta
Alta
Interoperabilidade
Baixa
Alta
Alta
Comparações (2/2)
Adaptação dinâmica
Presente
Presente
Presente
Extensibilidade
Baixa
Baixa
Alta
Ferramentas de Simulação
Simulink
Ausente
TrueTime
No sistema operacional Linux
e nas placas SaJe e TINI
No sistema operacional
Contiki (sensores)
Média (CORBA)
Difícil (Framework,
Reflexão
Computacional,
OpenCOM)
Ambientes de Execução
Usabilidade
Nos sistemas
operacionais:
Windows, Linux,
VxWorks e QNX
Fácil (C++)
Conclusões

Há pelo menos um ponto positivo em cada um
dos middlewares.

MicroQoSCORBA
–

OCP
–

Tolerância a falhas (QoS), interoperabilidade.
Maturidade e usabilidade (C++).
RUNES
–
Extensibilidade, interoperabilidade,
heterogeneidade.