Elementos de processamento em uma plataforma computacional se comunicam através de suas interfaces. Esta comunicação pode ocorrer de maneira direta, quando as interfaces são conectadas diretamente umas com as outras (ponto-a-ponto), ou, o que é bastante comum, através de um elemento de comunicação compartilhado. Um elemento de comunicação compartilhado, como por exemplo um barramento, representa logicamente os canais de comunicação entre as tarefas sendo executadas nos elementos de computação do sistema conectados a ele. 1: Física 2: Protocolo 2: MAC 2: Stream 2: Enlace 3: Rede 4: Transporte 5: Sessão 6: Apresentação 7: Aplicação Tarefa 1 1: Física 2: Protocolo 2: MAC 2: Stream 2: Enlace 3: Rede 4: Transporte 5: essão 6: Apresentação 7: Aplicação Tarefa 2
Elemento de Processamento 1 Elemento de Processamento 2
Dependente da Aplicação (Tarefa) Dependente dos Canais 1 e 2 (meio de transmissão) Dependente do Elemento de Processamento Canal 2 Canal 1 Meio de Transmissão
Figura 5 – Escopo da validação do protocolo de comunicação proposto.
Para explicar o que foi dito, a Figura 5 mostra a comunicação entre dois elementos de processamento através de um meio comum de transmissão de dados. Com base em uma adequação proposta por Gajski et al. (2009) da pilha de protocolos do modelo International Organization for Standardization (ISO)/Open Systems Interconnection (OSI) (ZIMMERMANN, 1980) aplicada para a comunicação entre tarefas em sistemas
Capítulo 2. Fundamentação Teórica 35
computacionais, a Figura 5 mostra a ordem das camadas envolvidas e a dependência que elas têm em relação aos elementos do sistema. Como pode ser visto, cada camada na figura tem associado a si um número equivalente à camada no modelo OSI. Por uma questão de detalhamento, Gajski et al. (2009) subdividiu a camada de enlace do modelo OSI em quatro camadas: Enlace, Stream, MAC e Protocolo.
Semelhante às redes de computadores, cada camada presta um serviço para as camadas acima delas e quanto mais abaixo é a camada, maior é a sua dependência com o meio físico de transmissão de informação, ou seja, menor é a sua abstração.
A camada de aplicação é a camada mais próxima da tarefa em execução. Através de funções de comunicação em alto nível de abstração, permitindo inclusive o uso de tipos de dados complexos, esta camada é o início da comunicação entra as tarefas 1 e 2. Esta camada é completamente independente da implementação do outro elemento de processamento, assim como do meio de transmissão. Ela é apenas dependente da tarefa em questão.
Já as camadas de Apresentação, Sessão e Transporte, envolvidas pela linha tracejada na Figura 5, implementam funcionalidades relacionadas à tradução e organização de dados suportados pelo outro elemento de processamento. Estas 3 camadas implementam o protocolo de comunicação de alto nível entre os componentes, o qual é o alvo desta abordagem. Este protocolo é dependente exclusivamente do componente com o qual o elemento em questão está se comunicando, sendo completamente independente do meio de transmissão envolvido.
A camada de Apresentação define a tradução dos dados enviados da camada de aplicação para um formato suportado pelo componente remoto. Esta camada agrupa as informações em grupos de bits e na ordem correta. Esta ordem é justamente a sequência dos dados esperada pelo componente remoto.
Já a camada de Sessão é responsável por unificar os canais de envio e recebimento de dados em um único meio e multiplexar o seu uso para enviar os dados da camada de apresentação, tratar interrupções e solicitar dados ao dispositivo. É através da camada de sessão que há o gerenciamento de vários contextos de comunicação (sessões) entre um mesmo componente remoto e logicamente associados a diferentes canais, mesmo que utilizando um único meio de transmissão.
A camada de Transporte é responsável por dividir os dados enviados e reagrupar os dados recebidos pela/para a camada de Sessão. Esta camada divide os dados em quadros com tamanhos suportados pela arquitetura. Todos os dados enviados desta camada para as camadas de níveis mais baixos são abstraídos pela abordagem.
As camadas abaixo da camada de Transporte englobam o protocolo de comunicação do meio de transmissão (barramentos, Network-on-Chip (NoC), pontes, transdutores, etc.) e não dos dispositivos que agregam as funcionalidades da aplicação à plataforma. Este protocolo atende a todos os dispositivos, sendo o protocolo base para a transmissão de
Capítulo 2. Fundamentação Teórica 36
dados.
Focar nas camadas de Apresentação, Sessão e Transporte possibilita analisar apenas o protocolo de comunicação específico do dispositivo envolvido, sem se preocupar com o protocolo do meio de transmissão sob o qual ele está sendo encapsulado. Este protocolo de alto nível, puramente dependente do componente, é único e é ele que irá ditar como este componente irá se comportar. É neste conjunto de camadas que se encontram os HdS, os quais serão detalhadas na próxima seção.
2.1.1 Software dependente de Hardware (HdS)
Atualmente o projeto de software embarcado tem impacto nos custos de projeto. Até a uma década atrás, apenas 10% dos custos de projetos de sistemas eletrônicos eram decorrentes do software e os outros 90% eram para o desenvolvimento de hardware. Entretanto esse quadro se inverteu (ECKER; MUELLER; DOMER, 2009).
Ecker, Mueller e Domer (2009) mostram que essa mudança no custo do desenvolvimento de hardware e software se deu por dois motivos principais: flexibilidade e configurabilidade. A flexibilidade desejada só pode ser alcançada através do reuso e compartilhamento de recursos de hardware, resultando em uma necessidade de software robusto para controle e uso destes recursos.
O outro aspecto, configurabilidade, diz respeito ao uso de processadores de propósito geral, como por exemplo microprocessadores e Digital Signal Processor (Digital Signal Processor (DSP)). Para redução de custos na manufatura, os processadores são produzidos em grandes quantidades e são aplicados em diversos cenários como telecomunicações, aviação, automobilismo e etc. Logo, é através do software que são feitas as reconfigurações necessárias para a adaptação destes componentes. É importante frisar que as partes de software que são mais críticas em relação à flexibilidade e configurabilidade são as camadas mais ligadas ao hardware, conhecidas como software dependente de hardware (HdS).
Ecker, Mueller e Domer (2009) definem HdS como sendo funções do software embarcado que interagem diretamente com o hardware no qual estas funções estão sendo executadas. Cada HdS é construído especificamente para um determinado recurso de hardware da plataforma, sendo ele completamente desnecessário na ausência deste recurso. Assim hardware e HdS juntos implementam funcionalidades dentro dos sistemas que permitem fazer uso do recurso disponível. Devido a isso, essas funções de software devem ter uma interface simples e clara para as camadas mais superiores.
A Figura 6 mostra uma arquitetura de sistemas onde se destacam claramente os componentes de hardware, as camadas de HdS e o software da aplicação. Na camada acima se encontram as aplicações que são suportadas pelo HdS. No meio se encontram os vários tipos de software dependentes de hardware, servindo de infraestrutura e interface de comunicação entre as aplicações e o hardware.
Capítulo 2. Fundamentação Teórica 37
Figura 6 – Contexto geral da arquitetura de sistemas (ECKER; MUELLER; DOMER, 2009)
Ainda de acordo com a Figura 6, os HdS incluem os seguintes tipos de software: Sistema Operacional e Sistemas operacionais de tempo real (Real-Time Operating System (RTOS)), Boot Firmware, Pilhas de protocolos de comunicação, device drivers e a Camada de abstração de Hardware (Hardware Abstraction Layer (HAL)). A técnica proposta neste trabalho tem como objetivo suportar o desenvolvimento de device drivers. A próxima seção descreverá com mais detalhes esse tipo de HdS.
2.1.1.1 Device Drivers
Device drivers são funções de software responsáveis em prover acesso aos serviços disponíveis
pelo hardware. Do ponto de vista das aplicações, os drivers podem ser vistos como uma camada de software que abstrai os recursos que o hardware oferece, servindo como uma interface de acesso aos dispositivos e, quando associados a sistemas operacionais, eles podem ser vistos como uma extensão do kernel (SWIFT et al., 2002).
As principais responsabilidades dos device drivers incluem suportar a interação com a aplicação e o sistema operacional, a interação com o hardware, realização de alocação de canais de comunicação e gerenciar a utilização concorrente e identificação dos dispositivos. A Figura 7 mostra os diversos cenários em que os device drivers podem ser aplicados.
São os device drivers que viabilizam a comunicação entre tarefas sendo executadas em diferentes elementos de processamento em uma plataforma computacional, mais especificamente a comunicação entre aplicações sendo executadas em processadores e dispositivos. Dispositivos integrados em uma plataforma são recursos disponíveis para todo o sistema. Entretanto, para utilizá-los é preciso conhecê-los e entender principalmente a forma como eles se comunicam. Dessa maneira drivers precisam assumir a tradução e formação de dados, a sincronização entre componentes, bem como a escolha e uso do meio
Capítulo 2. Fundamentação Teórica 38
de transmissão de dados entre os pontos que se comunicam (GAJSKI et al., 2009).
Fazendo uma analogia com a realidade, quando duas pessoas de diferentes idiomas ou com deficiências auditivas e de fala querem se comunicar, quando elas não dominam o idioma ou a linguagem do outro, elas precisam de intérpretes. Estes intérpretes são pessoas especializadas nas linguagens que as duas pessoas dominam. Assim, sua tarefa é escutar o que uma das pessoas quer dizer para o outro, interpretar, traduzir a mensagem e montar a frase que será repassada, verificar se a outra pessoa está prestando atenção e escolher o meio de repassar a mensagem (gestos, fala ou escrita), repassar a mensagem e se certificar de que a outra pessoa entendeu. Numa plataforma computacional, um device driver é similar a este intérprete.
Figura 7 – Cenários em que device drivers podem ser aplicados (LISBOA et al., 2009)
Através da Figura 7 é possível visualizar dois cenários principais: device drivers utiliza- dos com e sem sistemas operacionais. Sempre que há um sistema operacional o driver se encontra em uma parte do kernel e, por esse fato, sua execução normalmente é feita em modo kernel, apesar de existirem trabalhos, como Ganapathy et al. (2007) por exemplo, que sugerem que partes de drivers sejam executas no modo usuário.
Considerados elementos críticos em um sistema eletrônico, os drivers, por serem códigos de terceiros e por serem executados pelo kernel do sistema operacional, têm sido uma das maiores causas de falhas de sistemas. Dentre os motivos para este fato estão a complexidade de codificação e verificação, uma vez que seu comportamento é intrinsecamente ligado ao comportamento do hardware (TANENBAUM; HERDER; BOS, 2006; SWIFT et al., 2002).
Assim, faz-se necessária a utilização de técnicas e metodologias que auxiliem os pro- jetistas de device drivers a desenvolverem estes HdS de maneira mais rápida e confiável. Algumas metodologias de projeto já vêm sendo largamente utilizadas no desenvolvimento de plataformas computacionais. Porém, como discutido no sec:intro, algumas lacunas ainda precisam ser cobertas, principalmente no desenvolvimento de software embarcado, em especial software dependente de hardware. A seções seguintes irão detalhar sobre estas metodologias.
Capítulo 2. Fundamentação Teórica 39