Middlewares para Sistemas Embarcados (Embutidos)

Apresentação em tema: "Middlewares para Sistemas Embarcados (Embutidos)"— Transcrição da apresentação:

1 Middlewares para Sistemas Embarcados (Embutidos)
Jordan Janeiro

2 Introdução - Esclarecimento
Sistemas embarcados ou sistemas embutidos?

3 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.

4 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. Forma de programação atingida. Algoritmos otimizados. Lembra o passado. Muitas estações de trabalho possuem mais memória cache da UCP do que sistemas embarcados possuem de memória ROM ou RAM.

5 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 ... a comunidade teve que rever seus conceitos.

6 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 ... Devido ao vasto numero de sistemas embarcados(heterogeneidade), seria dificil configurar, desenvolver e reconfigurar (4 ponto). Portanto a comunidade começou a pensar em middlewares e plataformas de auxilio (ferramentas adicionais e simuladores).

7 Middlewares MicroQoSCORBA OCP - Open Control Platform
RUNES - Reconfigurable, Ubiquitous, Networked Embedded Systems

8 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.

9 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;

10 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

11 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.

12 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.

13 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

14 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.

15 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).

16 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.

17 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

18 RUNES – Modelo de Componentes

19 Classificação de tempo real Paradigma de programação
Comparações (1/2) OCP MicroQoSCORBA RUNES Área de aplicação Controle de veículos aéreos não-habitados (seus sistemas) Genérica Combate a incêndios (primeiro teste feito) Maturidade Muito Alta Média Classificação de tempo real Hard Soft Paradigma de programação Orientado a objetos ORB Frameworks e Reflexão Computacional Tolerância à Falhas Presente Ausente Heterogeneidade Média-Alta Alta Interoperabilidade Baixa

20 Ferramentas de Simulação
Comparações (2/2) Adaptação dinâmica Presente Extensibilidade Baixa Alta Ferramentas de Simulação Simulink Ausente TrueTime Ambientes de Execução Nos sistemas operacionais: Windows, Linux, VxWorks e QNX No sistema operacional Linux e nas placas SaJe e TINI No sistema operacional Contiki (sensores) Usabilidade Fácil (C++) Média (CORBA) Difícil (Framework, Reflexão Computacional, OpenCOM)

21 Conclusões Há pelo menos um ponto positivo em cada um dos middlewares.
MicroQoSCORBA Tolerância a falhas (QoS), interoperabilidade. OCP Maturidade e usabilidade (C++). RUNES Extensibilidade, interoperabilidade, heterogeneidade.