Metodologia do ESCoRT

O ESCoRT apresenta uma metodologia baseada em componentes para o desenvolvimento de software embarcado. Ela propõe que primeiramente seja construída uma plataforma de software para prover os serviços necessários à aplicação. Daí então, a aplicação embarcada é instalada sobre essa plataforma.

A metodologia do ESCoRT divide as atividades do processo de construção de sistemas entre papeis bem definidos. A parte do desenvolvimento que exige um conhecimento específico de sistemas embarcados é separada daquela que necessita apenas do conhecimento dos requisitos funcionais da aplicação. Dessa forma um profissional sem tanto expertise em software embarcado pode desenvolver uma aplicação embarcada a partir de uma plataforma de software criada pelo profissional especialista, que é mais escasso no mercado. Além disso, os fabricantes dos processadores podem fornecer suas próprias bibliotecas de componentes para acessar a CPU e os periféricos, independentemente de qualquer kernel, da aplicação e até mesmo do compilador.

O diagrama de atividades representado pela figura acima mostra a modelagem dinâmica da metodologia, cuja descrição é a seguinte:

1. O fluxo do trabalho começa com o Desenvolvedor do Compilador encapsulando a sintaxe específica do compilador, resultando no artefato Abstração do Compilador.
2. O Fabricante do Microcontrolador cria abstrações de hardware para os periféricos, resultando em artefatos Componente HAL.
3. Em seguida o Desenvolvedor da Plataforma se responsabiliza por criar a configuração da plataforma com o compilador desejado.
4. Então o Desenvolvedor da Plataforma adiciona alguns dos componentes criados pelo Fabricante do Microcontrolador necessários para construir a plataforma. Assim o artefato Configuração Plataforma começará a ser refinado.
5. O Desenvolvedor da Plataforma cria o componente Kernel e depois o adiciona na plataforma. Dessa forma o artefato Configuração Plataforma é incrementado.
6. Depois o Desenvolvedor da Plataforma deve criar os componentes Driver necessários e em seguida adicioná-los à plataforma para refinar o artefato Configuração Plataforma.
7. Nesta etapa o Desenvolvedor da Plataforma irá criar os componentes Service e depois adicioná-los, para assim finalizar a implementação da plataforma de software embarcado.
8. Então entra a figura do Desenvolvedor da Aplicação, que começa por criar a configuração da aplicação a partir da configuração da plataforma.
9. Depois o Desenvolvedor da Aplicação cria os componentes que implementam a aplicação embarcada e em seguida os adiciona ao sistema, que neste ponto do desenvolvimento está completamente instanciado.

Arquitetura do ESCoRT

A abordagem do ESCoRT para obter um bom nível de portabilidade é manter ao máximo o software modularizado, de forma que os módulos que interagem com o hardware possuam interfaces bem definidas, e qualquer alteração na plataforma de hardware só necessita modificar estes módulos. Outro fato é que, no campo de software embarcado, uma das grandes barreiras para a portabilidade e reuso dos códigos são os diversos compiladores existentes frequentemente apresentarem divergência em alguns pontos da sintaxe. A fim de atacar este problema, a metodologia do ESCoRT contempla uma forma de abstrair qual o compilador utilizado no projeto por meio de uma interface padronizada. Isso não quer dizer que todos os componentes implementados com o ESCoRT sejam independentes do compilador. Entretanto, o código é organizado de forma a isolar toda implementação específica de um determinado compilador, abstraindo esta dependência dos outros componentes.
Além do uso de interfaces padronizadas, o seccionamento do código segundo a sua função dentro dos sistemas embarcados também tem uma participação fundamental na forma como o ESCoRT lida com os problemas de portabilidade e reuso, mencionados acima. Separar fluxo de controle do fluxo de dados mostrou-se essencial para alcançar um alto grau de reuso.
A arquitetura que apoia o ESCoRT utiliza o padrão de projetos Layered Pattern , organizando o software embarcado em camadas. O foco principal da arquitetura é promover a portabilidade, dividindo os componentes de acordo com sua função na plataforma embarcada.

HAL

Esta sigla significa Camada de Abstração de Hardware (Hardware Abstraction Layer) e é um conceito muito comum no campo de sistemas operacionais. Tem a finalidade de abstrair as especificidades de hardware de uma plataforma. Já que os diferentes microcontroladores possuem vários periféricos em comum, esta camada tem a função de fornecer uma API padronizada para estes periféricos. Dessa forma as camadas superiores podem ser independentes do hardware que está sendo utilizado. Um componente HAL é implementado herdando as características de um componente abstrato. Por exemplo: o componente nxp.lpc2368.hal.SPI herda de escort.hal.ISPI , que é abstrato e apenas define a interface padrão da SPI.

Kernel

A função desta camada não é criar uma interface padrão para todos os kernels, diferentemente da camada HAL. A ideia é encapsular esta parte do sistema e assim facilitar o reuso. A fim de promover uma maior modularidade, esta camada tem uma subdivisão, chamada Kernel Port . Os componentes que se encaixam nesta classificação implementam a parte do kernel que é dependente do processador e do compilador utilizados. Dessa forma, é possível, por exemplo, trocar de microcontrolador sem precisar criar outro componente Kernel.

Driver

Esta camada, assim como a camada HAL, provê uma abstração de hardware. Entretanto, os drivers assumem um papel de controle de acesso dos dados, realizando os tratamentos de interrupção e implementando os protocolos de acesso aos dispositivos de hardware. Os componentes HAL, por sua vez, apenas fazem alteração e leitura de dados nos periféricos. Dessa forma, se o sistema precisar mudar de processador, somente a camada HAL precisará ser alterada, uma vez que a lógica de controle dos dados continuará a mesma. Um componente Driver é construído com base na API da camada HAL e por isso não depende de um hardware específico. Um driver também pode fazer uso de outro driver , como é o caso do componente atmel.memory.serialflash.driver.AT45DB que utiliza um componente do tipo escort.driver.ISPI para acessar a interface SPI do chip de memória. Além disso, alguns componentes Driver necessitam de serviços do kernel para controlar a sincronização de acesso aos dados. Por exemplo, o componente freertos.driver.UARTDriver utiliza o serviço de fila do componente freertos.kernel.FreeRTOSKernel para armazenar os bytes que são recebidos pela interface da UART.

Service

Existem certas funcionalidades numa plataforma de software que estão além do controle de dispositivos de I/O. Tais funcionalidades normalmente são serviços compartilhados entre as tarefas do sistema e disponibilizados pelo sistema operacional, como File System e TCP/IP. Estes serviços são reusados em diversas aplicações e por este motivo foi criada a camada Service. Os componentes desta camada utilizam os componentes da camada Driver ou acessam diretamente componentes da camada HAL. Este último caso pode ser ilustrado por um serviço de piscagem de LED, que precisa apenas ligar e desligar um pino do processador. Essa funcionalidade não requer a complexidade de um driver para manipular o status de um pino, um componente do tipo escort.hal.IGPIOPin é suficiente para implementar este componente Service. Alguns serviços precisam executar uma tarefa para prover a funcionalidade a que se destinam. Um exemplo é o componente service.GPS, que precisa ler as informações de posicionamento periodicamente enviadas pelo dispositivo de GPS e atualizar as variáveis de latitude e longitude correntes. Neste caso a tarefa criada pelo componente deve ser escalonada junto com as tarefas da aplicação.

Application

Esta camada contém os componentes da aplicação embarcada propriamente dita. O desenvolvedor implementa as funcionalidades do sistema embarcado tendo como base a plataforma constituída pelos componentes das camadas subjacentes.

Por que usar o ESCoRT?

O aumento crescente da capacidade de processamento e de armazenamento dos componentes de hardware aliado ao barateamento destas infraestruturas tem permitido atender à demanda por sistemas embarcados mais complexos. Entretanto, o time-to-market exigido pelo mercado está cada vez mais curto, o que tem levado à necessidade de técnicas de desenvolvimento mais eficientes, que produzam sistemas com menos erros, de forma mais barata e com maior produtividade.

Uma solução para atacar essa necessidade de técnicas mais eficientes de desenvolvimento é investir em reuso. A possibilidade de reusar códigos de implementações anteriores para construir novos sistemas traz aumento de produtividade e diminui a quantidade de erros, uma vez que as partes reusadas já foram testadas várias outras vezes por muitas outros desenvolvedores.

Um dos maiores desafios à reusabilidade na construção de plataformas de software é a grande diversidade de hardware. Diferentemente dos computadores de propósitos gerais, as plataformas embarcadas dispõem de uma gama imensa de processadores com as mais variadas arquiteturas. Dessa forma, é muito comum existir a necessidade de migrar a aplicação embarcada de uma plataforma para outra. Os motivos para isso podem ser vários, desde diminuir o preço do produto com um hardware de menor custo até obter mais recursos como memória e capacidade de processamento. A capacidade e/ou facilidade de um sistema ser migrado chamamos de portabilidade.

Outro fato que compromete a reusabilidade no desenvolvimento da plataforma de software embarcado é a grande quantidade de domínios de aplicação para os quais são construídos os sistemas embarcados. Este tipo de sistema é aplicado a diversos contextos, como eletroeletrônicos, automação industrial e aviação. Isto é um grande problema porque para reusar a implementação de um software é necessário adaptar o código para os requisitos específicos do outro domínio. 

Sistemas operacionais, como Linux e Windows CE, podem até ser uma boa opção para aumentar a eficiência no desenvolvimento de sistemas embarcados. Eles têm uma boa aceitação da comunidade de desenvolvimento, ou seja, já possuem muito código pronto disponível e proveem abstração de hardware e modularidade. Entretanto, mesmo com os avanços no sentido de baratear e otimizar as infraestruturas utilizadas nas plataformas embarcadas, estes tipos de sistemas operacionais exigem hardwares mais potentes, que consomem mais energia, exigem mais memória e processadores mais complexos. Isto pode ser crítico principalmente para sistemas embarcados que são construídos em escala industrial, onde centavos fazem diferença no faturamento da empresa.

Isso abre espaço para o ESCoRT, que promove o reuso, a modularização e a fácil portabilidade ao mesmo passo em que permite a construção de sistemas que utilizem bem menos recursos que um Linux, por exemplo.

ESCoRT

Imagine um mundo onde a construção de sistemas embarcados é tão fácil como criar sistemas em Java. Imagine se cada fabricante de microcontrolador disponibilizasse pacotes de componentes de software referentes aos seus processadores. Imagine se os desenvolvedores de sistemas operacionais fornecessem bibliotecas de drivers genéricos para os seus produtos. Imagine se os desenvolvedores de software embarcado pudessem criar seus sistemas com uma modelagem de alto nível apenas definindo uma arquitetura de componentes. Imagine ainda se fosse possível gerar código automaticamente para esta modelagem. O ESCoRT se propõe a trazer este imaginário para a realidade. 

Ele é um arcabouço teórico, metodológico e operacional para o desenvolvimento de sistemas embarcados utilizando componentes. É fundamentado por uma arquitetura que separa os componentes em camadas de acordo com a função que desempenham no sistema, sendo um dos principais trunfos a distinção que é feita atribuindo acesso ao hardware para a camada HAL e deixando para a camada Driver o tratamento de interrupções e a sincronização de acesso. Isto permite que os drivers não fiquem tão atrelados ao hardware, de forma a não ser necessário alterar a implementação dos drivers caso o processador seja substituído por outro. 

ESCoRT propõe uma metodologia de desenvolvimento focada na portabilidade e reuso, permitindo  vários níveis de abstração, como abstração de hardware, abstração de compilador e abstração de kernel. A metodologia aplica um paradigma no qual a parte do desenvolvimento que exige conhecimento específico de sistemas embarcados é separada daquela responsável pela implementação da aplicação, o que permite que um desenvolvedor sem tanto expertise crie uma aplicação embarcada, uma vez que um profissional especializado tenha montado uma plataforma de software. ESCoRT também fornece um framework de componentes configuráveis que gera código automaticamente e é disponibilizado em forma de plugin para o Eclipse.