ESCORT: um framework de componentes para a construção de software embarcado

Texto

(1)UNIVERSIDADE FEDERAL DE PERNAMBUCO CIN - CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO [email protected] www.cin.ufpe.br/~posgraduacao. ESCORT: UM FRAMEWORK DE COMPONENTES PARA A CONSTRUÇÃO DE SOFTWARE EMBARCADO por Gustavo André Fernandes Braga de Melo Dissertação de Mestrado. RECIFE, AGOSTO DE 2011..

(2) UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO CIn - CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Gustavo André Fernandes Braga de Melo. ESCORT: UM FRAMEWORK DE COMPONENTES PARA A CONSTRUÇÃO DE SOFTWARE EMBARCADO. Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Ciência da Computação, área de concentração em Engenharia de Software, do Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.. ORIENTADOR: André Luís de Medeiros Santos, PhD. CO-ORIENTADOR: Sérgio Vanderlei Cavalcante, PhD.. RECIFE, AGOSTO DE 2011..

(3) Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571. Melo, Gustavo André Fernandes Braga de. ESCORT: um framework de componentes para a construção de software embarcado / Gustavo André Fernandes Braga de Melo - Recife: O Autor, 2011. vii, 101 folhas : il., fig., tab. Orientador: André Luís de Medeiros Santos. Dissertação (mestrado) - Universidade Pernambuco. CIn, Ciência da computação, 2011.. Federal. de. Inclui bibliografia, anexos e apêndice. 1. Ciência da computação. 2. Sistemas embarcados. 3. Portabilidade. 4. Framework. I. Santos, André Luís de Medeiros (orientador). II. Título. 004. CDD (22. ed.). MEI2011 – 139.

(4)

(5) Aos meus pais.. i.

(6) AGRADECIMENTOS. Em primeiro lugar agradeço ao meu querido Deus, que sempre me deu o suporte pra nunca desistir. Agradeço também à minha família, que sempre acreditou em mim. Em especial aos meus pais, cujo empenho e carinho se traduzem nas minhas conquistas. À minha linda, Amanda, pela paciência e carinho que me mantiveram firme nesta jornada. Ao meu orientador Sérgio Cavalcante, que, mesmo tendo uma agenda cheia e muitas atribuições, aceitou me orientar. Ao meu amigo Bruno Silva pelas valiosíssimas discussões e até mesmo ajuda nas implementações. A todos os meus amigos que se mantiveram companheiros apesar das minhas frequentes ausências.. Meus sinceros agradecimentos.. ii.

(7) SUMÁRIO. Resumo .............................................................................................................. 1 Abstract .............................................................................................................. 2 1. 2. Introdução ................................................................................................... 4 1.1. Motivação ....................................................................................................... 4. 1.2. Justificativa ..................................................................................................... 5. 1.3. Objetivos ........................................................................................................ 6. 1.4. Estrutura da dissertação ................................................................................ 7. Estado da Arte ............................................................................................ 9 2.1. 2.1.1. Koala ....................................................................................................... 9. 2.1.2. PECOS .................................................................................................. 10. 2.1.3. SAVE ..................................................................................................... 10. 2.1.4. JavaBeans ............................................................................................. 11. 2.2. 3. Modelos de Componentes ............................................................................. 9. Frameworks de Componentes ..................................................................... 11. 2.2.1. Java ....................................................................................................... 12. 2.2.2. THINK .................................................................................................... 13. 2.2.3. Processor Expert ................................................................................... 13. 2.2.4. Windows CE .......................................................................................... 14. 2.2.5. eCos ...................................................................................................... 14. 2.2.6. Choices .................................................................................................. 14. 2.2.7. OSKit ..................................................................................................... 15. 2.2.8. PURE ..................................................................................................... 15. 2.3. Taxonomia ................................................................................................... 15. 2.4. Considerações Finais ................................................................................... 18. ESCoRT .................................................................................................... 22 iii.

(8) 3.1. 3.1.1. HAL........................................................................................................ 24. 3.1.2. Kernel .................................................................................................... 24. 3.1.3. Driver ..................................................................................................... 24. 3.1.4. Service ................................................................................................... 25. 3.1.5. Application ............................................................................................. 26. 3.2. Estrutura ................................................................................................ 27. 3.2.2. Artefatos ................................................................................................ 27. 3.2.3. Papeis .................................................................................................... 28. 3.2.4. Fluxo das atividades .............................................................................. 29. 3.2.5. Detalhamento das atividades ................................................................ 30. Considerações finais .................................................................................... 32. Framework ESCoRT ................................................................................. 35 4.1. Modelos do Framework ................................................................................ 35. 4.1.1. Componente .......................................................................................... 36. 4.1.2. Abstração do compilador ....................................................................... 40. 4.1.3. Configuração de componentes .............................................................. 41. 4.2. 5. Metodologia de Desenvolvimento ................................................................ 26. 3.2.1. 3.3 4. Arquitetura .................................................................................................... 23. Framework ................................................................................................... 44. 4.2.1. Pacotes .................................................................................................. 44. 4.2.2. escort-builder ......................................................................................... 45. 4.3. ESCoRT IDE ................................................................................................ 46. 4.4. Considerações finais .................................................................................... 49. Estudos de Caso ....................................................................................... 52 5.1. Echo ............................................................................................................. 52. 5.2. ARCanjo ....................................................................................................... 54. 5.3. Blink ............................................................................................................. 57 iv.

(9) 5.4 6. Considerações finais .................................................................................... 60. Conclusão ................................................................................................. 62 6.1. Trabalhos Futuros ........................................................................................ 64. Glossário .......................................................................................................... 66 Referências ...................................................................................................... 67 Apêndice 1 ....................................................................................................... 71 Anexo 1 ............................................................................................................ 77 1.1. Arquivo component.xml ................................................................................ 77. 1.2. Arquivo SysTickTimer.h ............................................................................... 77. 1.3. Arquivo SysTickTimer.cpp............................................................................ 78. Anexo 2 ............................................................................................................ 81 1.4. Arquivo configuration.xml ............................................................................. 81. 1.5. Arquivo Compiler.h ....................................................................................... 90. 1.6. Arquivo config.h ........................................................................................... 91. 1.7. Arquivo config.cpp ........................................................................................ 98. v.

(10) LISTA DE FIGURAS Figura 1 – Arquitetura ESCoRT................................................................................. 23 Figura 2 – Diagrama de pacote da metodologia do ESCoRT ................................... 27 Figura 3 – Artefatos da metodologia ......................................................................... 28 Figura 4 – Fluxo de atividades .................................................................................. 30 Figura 5 – Framework ESCoRT ................................................................................ 35 Figura 6 – Modelo UML do componente ................................................................... 37 Figura 7 – Modelo UML da abstração do compilador ................................................ 40 Figura 8 – Modelo UML da configuração de componentes ....................................... 42 Figura 9 – Estutura de diretório do pacote escort.hal ................................................ 44 Figura 10 – Wizard para nova abstração do compilador ........................................... 47 Figura 11 – Wizard para novo componente .............................................................. 48 Figura 12 – Editor de componente (aba Options)...................................................... 48 Figura 13 – Editor de configuração (aba Configuration) ............................................ 49 Figura 14 – Menu do editor de configuração de componentes ................................. 49 Figura 15 – Aplicação Echo....................................................................................... 52 Figura 16 – Echo modificado para compilar com YAGARTO .................................... 54 Figura 17 – Arquitetura da aplicação ARCanjo ......................................................... 54 Figura 18 – Placa de avaliação MCB2300 ................................................................ 55 Figura 19 – Placa de avaliação STM3210C-Eval ...................................................... 55 Figura 20 – Portando o ARCanjo da MCB2300 para STM3210C-Eval ..................... 56 Figura 21 – Reconfigurando o driver do display LCD ................................................ 56 Figura 22 – Arquitetura da aplicação Blink ................................................................ 57 Figura 23 – Reusando os componentes do ARCanjo ............................................... 58 Figura 24 – Portando o Blink da STM3210C-Eval para MCB2300 ............................ 59 Figura 25 – Mudando o compilador do projeto Blink ................................................. 60. vi.

(11) LISTA DE TABELAS Tabela 1–Comparação entre modelos de componente ............................................. 16 Tabela 2 – Comparação entre frameworks de componentes .................................... 17 Tabela 3 – Notação da metodologia.......................................................................... 26 Tabela 4 – Detalhamento da atividade Criar Abstração do Compilador .................... 30 Tabela 5 – Detalhamento da atividade Criar Componente HAL ................................ 30 Tabela 6 – Detalhamento da atividade Criar Componente Kernel ............................ 31 Tabela 7 – Detalhamento da atividade Criar Componente Driver ............................. 31 Tabela 8 – Detalhamento da atividade Criar Componente Service ........................... 31 Tabela 9 – Detalhamento da atividade Criar Componente Application ..................... 31 Tabela 10 – Detalhamento da atividade Criar Configuração Plataforma ................... 31 Tabela 11 – Detalhamento da atividade Criar Configuração Aplicação .................... 31 Tabela 12 – Detalhamento da atividade Instanciar Componente HAL ...................... 31 Tabela 13 – Detalhamento da atividade Instanciar Componente Kernel................... 32 Tabela 14 – Detalhamento da atividade Instanciar Componente Driver ................... 32 Tabela 15 – Detalhamento da atividade Instanciar Componente Service ................. 32 Tabela 16 – Detalhamento da atividade Instanciar Componente Application ........... 32 Tabela 17 – Pacotes do ESCoRT ............................................................................. 45 Tabela 18 – Sintaxe de declaração de componente ................................................. 71 Tabela 19 – Sintaxe de declaração de abstração de compilador .............................. 73 Tabela 20 – Sintaxe de configuração de componentes ............................................. 73. vii.

(12) RESUMO 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. Este trabalho apresenta também três estudos de caso para demonstrar as vantagens do ESCoRT, incluindo um projeto comercial real. Palavras-chave: ESCoRT; sistemas embarcados; desenvolvimento baseado em componentes; reuso; portabilidade. 1.

(13) ABSTRACT Imagine a world where the design of embedded systems is as easy as creating Java systems. Imagine if every manufacturer of microcontroller made available packages of software components related to their hardware. Imagine if developers of operating systems provided libraries of generic drivers for their products. Imagine if embedded software developers could create their systems with a high-level modeling just defining an architecture of components. Imagine also if it were possible to generate code automatically for this model. ESCoRT proposes to bring this imagination into reality. It is a theoretical, methodological and operational structure for componentbased development of embedded systems. It is based on an architecture that separates the components into layers according to the function they perform in the system, and one of the main advantages is the distinction that is made by assigning hardware access to the HAL layer and the interrupt handling and access synchronization to Driver layer. This allows the drivers not be so tied to the hardware, so that it is not necessary to change the implementation of the drivers if the processor is replaced by another. ESCoRT proposes a development methodology focused on portability and reuse, allowing multiple levels of abstraction, such as hardware abstraction, compiler abstraction and kernel abstraction. The methodology applies a paradigm in which the part of the development that requires specific knowledge of embedded systems is separate from that responsible for the implementation of the application, which allows a developer with little expertise to create an embedded application, once a specialist has assembled a software platform. ESCoRT also provides a framework of configurable components that generates code automatically and is available in form of plugin for Eclipse. This thesis also presents three case studies to demonstrate the advantages of ESCoRT, including a real commercial project. Keywords: ESCoRT; embedded systems; component-based development; reuse; portability. 2.

(14) 1 Introdução. 3.

(15) 1 INTRODUÇÃO Este capítulo apresenta o contexto sobre o desenvolvimento de software embarcado, destacando algumas das principais deficiências que motivaram a realização deste trabalho. Em seguida é exposta a abordagem que esta dissertação propõe para atacar estes problemas. 1.1. Motivação Os sistemas computacionais estão cada vez mais presentes no cotidiano das. pessoas. Computadores pessoais, notebooks, smartphones, tablets, dentre outros, têm sido importantes atores na melhora da qualidade de vida das pessoas. Hoje em dia a dependência é tão grande que é quase impossível abrir mão desta tecnologia. Alguns destes sistemas muitas vezes passam despercebidos dentro de outros sistemas maiores, são os chamados sistemas embarcados. Freios ABS, injeção eletrônica e condicionador de ar são exemplos de produtos que possuem tais sistemas. Normalmente sistemas embarcados funcionam como sistemas de controle, nos quais as saídas dos atuadores são respostas às entradas lidas através dos sensores. Este tipo de sistema se caracteriza pelas restrições de recursos, como memória e consumo de energia. Segundo Xu et al. [1], o aumento da capacidade de processamento e armazenamento dos componentes de hardware aliado ao barateamento destas infraestruturas tem permitido atender à demanda por sistemas embarcados mais complexos. Entretanto, o time-to-market cada vez mais curto exigido pelo mercado 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 toda essa necessidade de técnicas mais eficientes de desenvolvimento é a reusabilidade. A possibilidade de reusar códigos de implementações anteriores para construir novos sistemas traz aumento de produtividade, pois se baseia em usar o que já foi feito, e diminui a quantidade de erros, uma vez que as partes reusadas já foram testadas outras vezes. 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 4.

(16) 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, apresentam-se como 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, proveem abstração de hardware e modularidade [2]. Entretanto, mesmo com os avanços no sentido de baratear e otimizar as infraestruturas utilizadas nas plataformas embarcadas, 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. O desenvolvimento baseado em componentes é uma abordagem atraente para a construção de software e que facilita o reuso [3]. O conceito fundamental é que os sistemas sejam construídos pela composição de partes independentes, que são os componentes. Esta técnica já é bem difundida no desenvolvimento de sistemas computacionais de propósitos gerais, mas ainda caminha para uma consolidação no projeto de software embarcado. 1.2. Justificativa Muitos trabalhos têm sido desenvolvidos com o intuito de proporcionar a. modularidade. e. reusabilidade. da. abordagem. baseada. em. componentes. compatibilizando com as restrições inerentes a sistemas embarcados [4] [5] [6]. Entretanto, a maior parte das soluções para desenvolvimento com componentes é 5.

(17) focada na construção da aplicação. A nossa experiência aponta que é pouco difundida a utilização de frameworks de componentes para desenvolver plataformas de software embarcado, o que envolve prover serviços de escalonamento de tarefas, criar drivers para os dispositivos da plataforma de hardware, gerenciar operações de Entrada/Saída, etc. Muitas das opções baseadas em componentes para auxiliar na construção de plataformas de software embarcado são sistemas operacionais componentizados [7] [4] [8]. Contudo, estas abordagens caem no problema da forma predefinida e fixa como os componentes interagem e são unidos [5]. Além disto, a implementação de tais componentes normalmente dependem de uma família específica de kernel [5]. Alguns trabalhos sugeriram frameworks de componentes para domínios específicos [9] [10] [11]. Entretanto, isso não contribui para uma adoção generalizada da comunidade de desenvolvimento, como acontece com Java. Além de que, é inviável aos fabricantes de microcontroladores e de dispositivos periféricos fornecerem seus próprios componentes, uma vez que cada domínio de aplicação precisa de componentes específicos. O ideal seria construir sistemas embarcados de forma tão fácil como construir sistemas em Java. Cada fabricante de microcontrolador disponibilizaria pacotes de componentes de software referentes aos seus processadores. Os desenvolvedores de sistemas operacionais forneceriam bibliotecas de drivers genéricos para os seus produtos. Os desenvolvedores de aplicações embarcadas poderiam criar seus sistemas com uma modelagem de alto nível apenas definindo uma arquitetura de componentes, e também seria possível gerar código automaticamente para esta modelagem. 1.3. Objetivos Tendo em vista todos estes fatores discorridos acima, este trabalho apresenta. como solução o ESCoRT, um arcabouço teórico, metodológico e operacional para o desenvolvimento de sistemas embarcados utilizando componentes. Seus principais objetivos são: Propor uma metodologia de desenvolvimento ESCoRT propõe uma metodologia de desenvolvimento baseada em componentes cujo foco principal é proporcionar altos níveis de portabilidade e reusabilidade, permitindo abstrações de hardware, abstrações de compilador 6.

(18) e abstrações de kernel. Ela é norteada por uma arquitetura que divide os componentes nas camadas HAL, Kernel, Driver, Service e Application, de acordo com a função que desempenham no sistema. Essa metodologia aplica o 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. Fornecer um framework para auxiliar a metodologia ESCoRT dispõe também de um framework com bibliotecas de componentes implementados em C++, e que possuem opções configuráveis, o que permite aproveitar as vantagens da reusabilidade ao mesmo passo em que comporta otimizações para os requisitos específicos de uma aplicação. Este framework contempla também um builder que gera código automaticamente a partir de uma configuração de componentes (modelagem) montada pelo usuário. A utilização do framework é automatizada por uma ferramenta gráfica, disponibilizada como um plugin para o Eclipse, com o intuito de agilizar o processo de desenvolvimento. 1.4. Estrutura da dissertação Esta dissertação é estruturada da seguinte forma. O Capítulo 2 descreve o. estado da arte relacionado ao desenvolvimento baseado em componentes para construção de plataformas de software embarcado e exibe uma taxonomia que compara as abordagens existentes ao ESCoRT. O Capítulo 3 apresenta formalmente o ESCoRT, define os conceitos teóricos nos quais ele se baseia e descreve a metodologia de desenvolvimento proposta. O framework fornecido pelo ESCoRT, os modelos de componentes utilizados e as ferramentas que dão suporte a ele são mostrados no Capítulo 4. A fim de demonstrar as vantagens do ESCoRT, o Capítulo 5 mostra três estudos de caso, sendo um deles um projeto comercial real. Finalmente, o Capítulo 6 apresenta as conclusões acerca deste trabalho.. 7.

(19) 2 Estado da Arte. 8.

(20) 2 ESTADO DA ARTE Este Capítulo apresenta o estado da arte sobre o desenvolvimento de software embarcado utilizando framework de componentes configuráveis. São descritos alguns modelos de componentes e depois explicitados alguns frameworks de. desenvolvimento. de. software. e. sistemas. operacionais. baseados. em. componentes. No final é apresentada uma taxonomia para as abordagens apresentadas e são feitas considerações comparativas acerca do framework proposto nesta dissertação. 2.1. Modelos de Componentes O. desenvolvimento. baseado. em. componentes. é. uma. abordagem. relativamente nova e que tem tido sucesso em muitos projetos de software [10]. Porém, o seu uso em sistemas embarcados ainda é pouco frequente, principalmente por causa das características e restrições específicas deste tipo de sistema. Contudo, algumas soluções dedicadas ao desenvolvimento de software embarcado vêm sendo apresentadas nos últimos anos. A seguir serão apresentados alguns modelos de componente que podem ser utilizados para o desenvolvimento de sistemas embarcados. 2.1.1 Koala Koala [9] é um modelo de componentes idealizado pela Philips para a construção de eletrônicos de consumo, como televisores, CD e DVD players, etc. Um componente é uma unidade de desenvolvimento reusável que possui uma especificação e uma implementação. Os componentes se comunicam com o ambiente por meio de interfaces. A descrição dos componentes se limita a determinar as interfaces do componente e especificar que papel essas interfaces assumem. Existem dois papeis: requires indica que o componente precisa acessar outro componente que possua esta interface e provides indica que o componente fornece esta interface para que outro componente o acesse. Cada item da interface é associado a uma função do código de implementação do componente. Koala descreve a configuração como sendo um conjunto de componentes conectados de forma a constituir um produto. Essa ligação entre componentes é feita por meio de conectores, que podem ser de três tipos: binding, glue code e 9.

(21) switch. Conector binding é utilizado para ligar uma interface requires com uma interface provides do mesmo tipo. Conector glue code é utilizado para ligar uma interface requires com uma interface provides de um tipo diferente. Conector switch é uma especialização de glue code que permite que um componente seja ligado a mais de um componente pela mesma interface, dirigido por uma expressão condicional. Koala também permite que vários componentes sejam ligados entre si, formando um novo componente. 2.1.2 PECOS PECOS [11] [12] é um projeto destinado a possibilitar o uso da tecnologia de desenvolvimento baseado em componentes para a classe de sistemas embarcados chamada field devices, muito usada em automação industrial. Em PECOS, um componente é uma unidade arquitetural que possui uma especificação e uma implementação. As entradas e saídas dos componentes são representadas como portas, que é a forma de interação do componente com o ambiente. As portas são como variáveis compartilhadas (possuem inclusive tipo), permitindo a leitura (direção in) e a escrita (direção out) de dados. Os componentes são acoplados por meio de conectores ligando portas de tipos compatíveis. Além das portas, os componentes possuem um conjunto de propriedades que definem requisitos não funcionais relacionados à inicialização, escalonamento e uso de memória. O comportamento de um componente é definido por uma função ou algoritmo que consome dados de algumas portas e produzem dados em outras. 2.1.3 SAVE SAVE [10] é um projeto com o objetivo de estabelecer uma disciplina de engenharia para o desenvolvimento baseado em componentes de software embarcado crítico, focado em sistemas veiculares. SaveCCM [13] é o modelo de componentes definido pelo projeto. SaveCCM consiste de três principais elementos. Components. (componentes). são. as. unidades. básicas. de. comportamento. encapsulado. Switches (inspirado no Koala [9]) fornecem facilidades para rotear dinamicamente (em tempo de execução) as conexões entre componentes. Assemblies. são. subsistemas. encapsulados,. interconectados. 10. formados. por. componentes.

(22) Segundo. SaveCCM,. os. sistemas. são. construídos. com. elementos. interconectados, onde cada elemento possui interfaces bem definidas. As interfaces são constituídas por portas de entrada e de saída, que permitem a interação dos elementos com o ambiente. Há ainda dois aspectos que caracterizam uma porta. Portas data-only são como variáveis que permitem ler e escrever dados em um elemento. Portas triggering-only são usadas para controlar a ativação de componentes. Portas data and triggering combinam essas duas características. O modelo em questão utiliza um paradigma que separa a definição da estrutura de transferência de dados e a modelagem do fluxo de controle. Essa separação resulta num modelo que suporta tanto atividades periódicas quanto atividades dirigidas a evento. Este aspecto de controle de fluxo explícito permite avaliação do comportamento temporal do sistema e consequente análise de previsibilidade. SaveCCM apresenta também o conceito de quality attributes (absorvido de PECOS [11]), que são parâmetros relacionados às características temporais e de segurança de componentes e assemblies. 2.1.4 JavaBeans JavaBeans [14] é um modelo de componente idealizado para a plataforma Java, que é descrita na Seção 2.2.1. De acordo com este modelo um componente, chamado bean, é uma classe Java que tem métodos, eventos e propriedades. A ideia é que um bean seja construído e manipulado por uma ferramenta visual. As propriedades são atributos relacionados ao estado ou às características do bean, e que podem ser lidos ou escritos por meio de métodos get e set. Métodos são as interfaces que permitem a um bean ser acessado por outro componente. Logicamente são considerados os métodos públicos, visíveis externamente. Eventos proveem uma forma de um componente notificar a outros componentes um acontecimento. Quando a fonte do evento detecta que algo importante aconteceu ela chama um método apropriado dos componentes que aguardam o evento (listeners). 2.2. Frameworks de Componentes A abordagem de desenvolvimento baseado em componentes pode ser. utilizada não só na construção da aplicação, mas também no projeto da plataforma 11.

(23) de software. Alguns frameworks dão o suporte necessário para a realização desta atividade, que envolve prover serviços de escalonamento de tarefas, criar drivers para os dispositivos da plataforma de hardware, gerenciar operações de Entrada/Saída, etc. Outra possibilidade para a elaboração da plataforma de software é utilizar um sistema operacional baseado em componentes. Este tipo de SO fornece uma plataforma estabelecida, mas que pode ser customizada para atender aos requisitos de uma aplicação específica. A seguir serão apresentados alguns exemplos de frameworks e sistemas operacionais baseados em componentes. 2.2.1 Java Java [15] é uma plataforma de desenvolvimento criada para proporcionar portabilidade das aplicações. A JVM (Máquina Virtual Java) cria uma abstração sobre o sistema operacional, permitindo que todas as aplicações escritas na linguagem Java (orientada a objetos e definida pela plataforma) e compiladas para a JVM (compilador fornecido pela plataforma) possam ser executadas em qualquer computador que possua a máquina virtual. A plataforma Java provê também bibliotecas de classes padrões que facilitam o trabalho do desenvolvedor. Por estas características,. Java. tem. sido. largamente. utilizada. e. a. comunidade. de. desenvolvedores desta tecnologia é uma das maiores. Entretanto, a utilização desta plataforma para o desenvolvimento de sistemas embarcados fica longe de ser a primeira opção [16], principalmente para sistemas profundamente embarcados, que possuem restrições de recursos mais acentuadas. Java requer mais memória, torna a execução mais lenta, não tem garantias para tarefas de tempo real e, portanto, se torna muitas vezes inviável para o tipo de sistema em questão. Existe também uma distribuição chamada Java Embedded, disponível para processadores ARM, Power Architecture e x86, mas que requer no mínimo 32MBytes de RAM e 37MBytes de ROM [17]. Ademais, a construção de um sistema embarcado engloba muito mais coisas além do desenvolvimento da aplicação. Java não possui bibliotecas de classes dedicadas à construção da plataforma subjacente à aplicação, como drivers, kernel, etc... 12.

(24) 2.2.2 THINK THINK. [5]. [18]. é. um. framework. de. componentes. destinados. ao. desenvolvimento de sistemas embarcados. Segundo Hošek et al. [19], a ideia original de THINK era simplificar o desenvolvimento de kernels para sistema embarcado, mas gradualmente ele se tornou um conjunto de componentes úteis para o desenvolvimento de software embarcado no geral. THINK possui linguagens dedicadas para determinar a arquitetura e as interfaces dos componentes (ADL e IDL). O código funcional dos componentes é escrito em linguagem C estendida com uma sintaxe de anotações (por meio de comentários), chamada nuptC. THINK traz uma biblioteca de componentes, chamada Kortex, contendo módulos genéricos e módulos para plataformas de hardware específicas. Uma toolchain associada ao framework gera o código a partir da arquitetura e interfaces definidas e um compilador gcc compila e gera a imagem do sistema. Toda essa infraestrutura é apoiada por um plugin para o Eclipse [20] que permite a composição de componentes utilizando uma interface gráfica. 2.2.3 Processor Expert Processor. Expert. [6]. é. um. framework. destinado. a. automatizar. o. desenvolvimento da camada de abstração de hardware (HAL). Provê um ambiente visual para o gerenciamento de recursos de microcontroladores e geração de código da plataforma de acesso ao hardware. Está integrado a uma IDE chamada CodeWarrior, que atualmente possui uma versão para o Eclipse [20]. O wizard para criação de novos componentes é um exemplo da boa usabilidade proporcionada pelo Processor Expert, além de possuir uma boa documentação.. Entretanto,. não. é. possível. utilizar. outras. ferramentas. de. desenvolvimento que não sejam aquelas às quais ele está atrelado. O framework fornece uma vasta coleção de componentes, mas que se limitam a algumas famílias de microcontroladores de um único fabricante. Cada componente apresenta uma granularidade de configurações que permite otimizações como implementar ou não um método do componente ou habilitar ou não uma determinada interrupção. Contudo, o código de implementação dos componentes exige o emprego de uma sintaxe específica. Além disso, instâncias de um mesmo tipo de componente têm código replicado.. 13.

(25) 2.2.4 Windows CE É um sistema operacional criado pela Microsoft para sistemas embarcados [21]. Possui uma arquitetura modular e componentizável que permite ao desenvolvedor instanciar somente os módulos do SO que serão necessários para o sistema. Possui um rico conjunto de recursos, que engloba interface gráfica do usuário e tecnologias multimídia. Entretanto, o Windows CE é usado apenas em algumas CPU’s com arquitetura 32 bits (MIPS, X86, ARM, SH), além de requerer no mínimo uma memória SDRAM de 1MByte e uma unidade de gerenciamento de memória capaz de realizar memória virtual de 32 bits [22]. 2.2.5 eCos eCos [4] [23] é um SO orientado a componentes que podem ser configurados para aplicações específicas. Ele fornece um framework de configuração para customizar o RTOS. Da mesma forma que o Windows CE, somente os componentes requeridos são inseridos. Isso permite que o tamanho de memória consumido seja o mínimo necessário. O eCos possui uma arquitetura em camadas que contempla HAL (Hardware Abstraction Layer), Device Drivers, Kernel, Networking Stack (ex.: pilha TCP/IP), FileSystem, WebServer, ISO C lib e Compatibility Interface (POSIX, uITRON). Essa divisão dos componentes permite um alto poder de portabilidade do SO. Uma vez que os componentes HAL forem portados, o sistema está pronto para rodar na nova plataforma. A configuração de componentes possui vários níveis, desde colocar ou não um determinado componente, até opções específicas de um componente ou mesmo opções de otimização do código. Uma desvantagem é que eCos foi projetado para compilação somente com uma toolchain GNU. A declaração de novos componentes utiliza uma linguagem específica (CDL – Configuration Description Language), embora não muito complexa, para determinar as opções de configuração do componente. 2.2.6 Choices Choices [8] [24] é um sistema operacional customizável orientado a objetos, cujo principal objetivo é permitir ao desenvolvedor adaptar e otimizar o sistema para os requisitos específicos da aplicação. Ele possui diversos subsistemas, como gerenciamento de memória, gerenciamento de processos, sistema de arquivos, cujas entidades são representadas por classes em C++, que permitem customização 14.

(26) por meio de herança. Choices é suportado pelas arquiteturas SPARC, x86 e ARM. Este framework provê também uma ferramenta, OS View, que dá o suporte à reconfiguração do sistema (carregamento de novas classes) em tempo de execução. 2.2.7 OSKit OSKit [7] [25]apresenta uma forma de construir sistemas operacionais específicos para processadores Intel x86 por meio de módulos com interfaces bem definidas. Segundo [26], OSKit é basicamente uma coleção de segmentos de código que precisam ser conectados manualmente. Além disso, sua implementação não é focada em sistemas embarcados. 2.2.8 PURE PURE [27] foi criado para oferecer um sistema operacional configurável, a fim de atender os requisitos específicos de uma aplicação profundamente embarcada, que possui restrições extremas de recursos. Os componentes são organizados numa estrutura formada por um núcleo e uma extensão. O núcleo é a implementação de um subconjunto mínimo de funções para o escalonamento de interrupções e threads. Recursos e funcionalidades que representam algum tipo de extensão (extensões mínimas do sistema) são adicionados à extensão do núcleo. 2.3. Taxonomia Esta Seção propõe uma taxonomia para os modelos e frameworks. apresentados anteriormente. A Tabela 1 resume a avalição dos modelos apresentados neste Capítulo e do modelo de ESCoRT. A Tabela 2 dá uma visão geral das características dos frameworks da Seção 2.2 e do ESCoRT. O sinal de visto () indica que a abordagem avaliada possui a determinada característica, o sinal de exclusão (×), obviamente, indica que a característica não é comtemplada e o sinal de mais ou menos (±) explicita que o item (modelo ou framework) avaliado atende em parte ou de forma limitada a referida característica. Os critérios para avaliação dos modelos de componente são descritos a seguir: Dedicado a sistemas embarcados – Avalia se o modelo foi idealizado para atender algumas necessidades especiais, como otimizações de memória e configurações temporais, normalmente associadas a sistemas embarcados.. 15.

(27) Componentes definidos como classes – Avalia se, de acordo com o modelo, um componente é uma classe, o que facilita a criação e utilização de componentes. Os modelos nos quais um componente é uma unidade arquitetural exigem a separação da descrição estrutural e a implementação dos componentes. Implementação orientada a objetos – Avalia se a implementação dos componentes é realizada com uma linguagem orientada a objetos, que é o paradigma de programação mais difundido na atualidade [28].. PECOS. SAVE. JavaBeans. Dedicado a sistemas embarcados. . . . ×. . Componentes definidos como classes. × ×. ×. × ×.  . ±. Característica. Implementação orientada a objetos. . ESCoRT. Koala. Tabela 1–Comparação entre modelos de componente. . Os critérios de avaliação dos frameworks reúnem um conjunto de características maior que aquele direcionado à avaliação dos modelos de componentes. Tais critérios são descritos a seguir: Dedicado a sistemas embarcados – Leva em consideração as restrições de recursos associadas a sistemas embarcados, fornecendo uma infraestrutura de baixo consumo de memória e computação mais rápida. Adequado a pequenos sistemas embarcados – Permite a construção de sistemas embarcados de menor porte, com footprint mais reduzido, de forma que a plataforma de hardware não necessite de unidade de gerenciamento de memória (MMU). Suporte à construção da plataforma de software – Permite ao desenvolvedor projetar, além da aplicação, a plataforma de software subjacente, incluindo componentes de kernel, driver, serviços de SO, etc. Focado na portabilidade – Provê facilidades para permitir que uma aplicação seja migrada de uma plataforma de hardware para outra de forma minimamente traumática (com poucas alterações no mínimo de componentes). Não exige conhecimento de linguagem de descrição específica – Não requer que o desenvolvedor conheça linguagens específicas para declarar os 16.

(28) componentes. Caso o framework possua uma ferramenta gráfica que exima o desenvolvedor da responsabilidade de conhecer a sintaxe da linguagem, considerase que a exigência é negativa. Orientação a objetos – Os componentes do framework são implementados utilizando o paradigma de orientação a objetos. Não restringe a implementação a uma sintaxe adaptada – Não exige que os componentes sejam implementados com linguagens de programação adaptadas (adição de sintaxe específica). Abstração do compilador – Minimiza a dependência das implementações dos componentes a um compilador específico, abstraindo características comuns aos compiladores. Suporte de ferramenta gráfica – A utilização do framework e a construção de componentes é apoiada por uma ferramenta gráfica que agiliza o processo de desenvolvimento. Variedade de plataformas de hardware suportadas – Permite construir aplicações para um conjunto vasto de processadores. Variedade de kernels suportados – Permite utilizar qualquer tipo de kernel para construir a plataforma de software.. Suporte à construção da plataforma de software Focado na portabilidade Não exige conhecimento de linguagem de descrição específica Orientação a objetos Não restringe a implementação a uma sintaxe adaptada Abstração do compilador Suporte de ferramenta gráfica. 17. OSKit.    . Choices.  ± ×   × ×        ± . eCos. Processor Expert Windows CE. ESCoRT. Adequado a pequenos sistemas embarcados. ±    ×   × ×  ±   ± ±   ×    × ×   ± ±  - × × × ×   . PURE. Dedicado a sistemas embarcados. THINK. Característica. Java. Tabela 2 – Comparação entre frameworks de componentes. ×     ×  ×       . × × × ×    × × .

(29) Variedade de plataformas de hardware suportadas Variedade de kernels suportados. ±  × ±  ± ×   ×  × × ×  × ± . A Seção seguinte reúne considerações, tomando como base essa taxonomia apresentada, para comparar o framework proposto por este trabalho e as abordagens descritas neste Capítulo. 2.4. Considerações Finais Como pudemos ver neste Capítulo, o desenvolvimento baseado em. componentes é uma tendência crescente. Muitas abordagens para a construção de aplicações embarcadas têm surgido. A utilização de frameworks de componentes para aumentar a produtividade no desenvolvimento de software é uma possibilidade promissora. Entretanto, a nossa experiência aponta que o emprego deste tipo de tecnologia no projeto de sistemas embarcados ainda não é muito difundido. Uma das possíveis razões para isto é a grande diversidade de domínios de aplicação para os quais este tipo de sistema é desenvolvido, além das inúmeras plataformas de hardware disponíveis. Koala, PECOS e SAVE apresentam abordagens dedicadas a domínios bem específicos (eletrônicos de consumo, automação industrial e sistemas veiculares, respectivamente). Java, Windows CE e Choices só atendem a um conjunto muito limitado de processadores. Processor Expert e OSKit são ainda mais restritivos e só podem ser utilizados para tipos bem específicos de microcontroladores. Este trabalho apresenta ESCoRT, um framework de componentes para o desenvolvimento de plataformas de software embarcado cujo modelo de componente configurável permite bons níveis de otimização e adequação aos requisitos de uma aplicação específica. ESCoRT privilegia a portabilidade da aplicação, o que também é focado em Java, Windows CE, eCos, Choices e PURE. THINK e Processor Expert, embora permitam algum nível de portabilidade às aplicações, não assumem esta questão como uma das principais finalidades. A implementação dos componentes em ESCoRT é orientada a objetos utilizando C++. Isto permite que haja maior reusabilidade no desenvolvimento através de características como herança de classes e polimorfismo. Koala, SAVE, THINK,. 18.

(30) Processor Expert, eCos e OSKit não admitem orientação a objeto para implementar os componentes. Os modelos de componentes de Koala, PECOS e SAVE impõem um paradigma muito diferente do que a maioria dos desenvolvedores está acostumada. Estes modelos separam a especificação da estrutura dos componentes e a implementação do comportamento. Koala ainda separa a especificação das interfaces. ESCoRT utiliza um modelo mais parecido com JavaBeans. Classes em C++ definem a estrutura dos componentes e servem tanto para especificar as interfaces (funções) quanto para implementar o comportamento. Enquanto os três primeiros modelos citados utilizam elementos conectores para fazer a ligação entre componentes, ESCoRT acessa outros componentes por referência com chamadas diretas de funções. Uma abordagem muito mais natural para os desenvolvedores. Diferencia-se de JavaBeans porque as opções configuráveis dos componentes de ESCoRT são declaradas separadamente das classes, o que permite otimizações em tempo de compilação sem precisar alterar as classes. Um ponto positivo de ESCoRT é que, assim como THINK e Choices, ele não impõe uma determinada família de kernel. Windows CE, eCos e OSKit definem um conjunto fixo e específico de possibilidades de kernel, do qual os outros componentes dependem ou se baseiam. PURE fornece um conjunto diversificado, porém fixo, de possibilidades de escalonamento. Java e Processor Expert não fornecem componentes deste tipo. O framework apresentado nesta dissertação dá a possibilidade de o desenvolvedor utilizar desde um executor cíclico até uma implementação de escalonamento preemptivo. Com a abordagem proposta por ESCoRT, não é necessário que o desenvolvedor tenha conhecimento de linguagens de descrição específicas, como acontece com Koala, PECOS, SAVE, THINK e eCos. A declaração dos componentes é feita em estrutura de XML por meio de uma ferramenta gráfica. Da mesma forma, a instanciação de componentes e a configuração das suas opções são realizadas com o apoio desta ferramenta. Diferentemente de THINK, Processor Expert e PURE, ESCoRT não utiliza uma sintaxe específica na implementação dos componentes, o que possibilita o uso de código de terceiros. THINK implementa os componentes com uma linguagem C. 19.

(31) estendida com um esquema de anotações. Processor Expert também usa C, mas exige também a aplicação de uma sintaxe específica. Ao contrário de todas as abordagens mostradas, ESCoRT se propõe a abstrair características comuns dos compiladores, de forma que sejam minimizadas as alterações de componentes para atender a uma possível mudança de escolha do compilador. Algumas abordagens, como eCos, THINK e Processor Expert, nem sequer permitem que outro compilador, além daquele determinado para o framework, seja usado. A descrição detalhada do ESCoRT é apresentada no Capítulo 3 e Capítulo 4.. 20.

(32) 3 ESCoRT. 21.

(33) 3 ESCORT ESCoRT (Embedded Software Component: a Reuse Technology) é um arcabouço teórico, metodológico e operacional para a construção de software embarcado. Foi idealizado por causa da necessidade real em atacar dois dos principais problemas observados no desenvolvimento de sistemas embarcados, portabilidade e reuso. A grande diversidade de domínios de aplicação para os quais este tipo de sistema é desenvolvido, além das inúmeras plataformas de hardware disponíveis, dificulta a portabilidade das aplicações. As restrições de recursos, inerentes a sistemas embarcados, muitas vezes exigem que o código seja implementado de forma otimizada e específica, o que demonstra ser um dos principais fatores que desfavorecem o reuso de código. Considerando isto, ESCoRT apresenta uma metodologia de desenvolvimento que maximiza a portabilidade e o reuso. Além disso, fornece um framework de componentes destinado à utilização junto com esta metodologia, o que facilita bastante a adoção da mesma no processo de desenvolvimento de software embarcado. 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. 22.

(34) Este Capítulo define uma arquitetura na Seção 3.1, cuja intenção é dividir os componentes em camadas de acordo com suas características a fim de garantir maior reuso. A Seção 3.2 explica a metodologia de desenvolvimento proposta por este trabalho. O framework fornecido pelo ESCoRT será formalmente apresentado no Capítulo 4. 3.1. Arquitetura ESCoRT é apoiado por uma arquitetura que foi inspirada em um trabalho. anterior nosso [29]. Ela utiliza o padrão de projetos Layered Pattern [30], organizando o software embarcado em camadas, de modo a facilitar o reuso e a manutenibilidade dos componentes. O foco principal da arquitetura é promover a portabilidade, dividindo os componentes de acordo com sua função na plataforma embarcada.. Figura 1 – Arquitetura ESCoRT. A Figura 1 mostra as camadas da arquitetura, que serão descritas nas subseções a seguir.. 23.

(35) 3.1.1 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. O controle do hardware é feito pela manipulação de registradores de funções especiais. Esses registradores normalmente são definidos em arquivos header (extensão .h) fornecidos pelo compilador. Dessa forma, cada compilador acaba definindo um nome diferente para um mesmo registrador. A fim de evitar dependência do código a um compilador específico, foi criada uma subclassificação dentro desta camada nomeada ADL. Esta API (Architecture Dependent Layer – Camada Dependente da Arquitetura) tem a função de prover a interface específica de acesso ao hardware, ou seja, representar em termos de métodos e funções as escritas e leituras aos registradores. 3.1.2 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. 3.1.3 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 24.

(36) 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. freertos.driver.UARTDriver. aos utiliza. dados. o. Por. serviço. exemplo, de. fila. o. componente. do. componente. freertos.kernel.FreeRTOSKernel para armazenar os bytes que são recebidos pela interface da UART. 3.1.4 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.. 25.

(37) 3.1.5 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. 3.2. Metodologia de Desenvolvimento Este trabalho 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. A estrutura de definição da metodologia foi inspirada no ipPROCESS [31], que é um processo para desenvolvimento de IP-cores. A notação que define a metodologia do ESCoRT é descrita na Tabela 3, logo abaixo: Tabela 3 – Notação da metodologia. Nome. Descrição. Notação. Papel. É a atribuição de habilidades e responsabilidades. Artefato. É qualquer coisa produzida, consumida ou modificada por uma atividade. Atividade. É uma unidade de trabalho realizada por um papel. 26.

(38) 3.2.1 Estrutura A Figura 2 mostra a modelagem da metodologia. Podemos identificar a seguinte estrutura no diagrama: Artefatos produzidos – Abstração do Compilador, Componente ADL, Componente HAL, Componente Kernel, Componente Driver, Componente Service, Componente Application, Configuração Plataforma e Configuração Aplicação. Papeis envolvidos – Desenvolvedor do Compilador, Fabricante de Microcontrolador, Desenvolvedor da Plataforma e Desenvolvedor da Aplicação. Atividades do papel Desenvolvedor do Compilador – Criar Abstração do Compilador. Atividades do papel Fabricante de Microcontrolador – Criar Componente HAL. Atividades do papel Desenvolvedor da Plataforma – Criar Configuração Plataforma, Instanciar Componente HAL, Criar Componente Kernel, Instanciar Componente Kernel, Criar Componente Driver, Instanciar Componente Driver, Criar Componente Service, Instanciar Componente Service. Atividades do papel Desenvolvedor da Aplicação – Criar Configuração Aplicação, Criar Componente Application, Instanciar Componente Application.. Figura 2 – Diagrama de pacote da metodologia do ESCoRT. 3.2.2 Artefatos Os artefatos da metodologia estão esquematizados com a notação de diagrama de classe da UML na Figura 3 e são descritos abaixo: 27.

(39) Abstração do Compilador – encapsulamento de um compilador por meio de uma interface padronizada que abstrai características comuns a compiladores. Isso permite que o código do sistema seja minimamente dependente do compilador. Componente (HAL, Kernel, Driver, Service e Application) – declaração de uma unidade arquitetural que compõe a implementação de um sistema embarcado. Configuração Plataforma – composição da arquitetura da plataforma de software embarcado (ausência dos componentes da aplicação). Configuração. Aplicação. –. especialização. do. artefato. Configuração. Plataforma. Agrega os componentes que implementam a aplicação.. Figura 3 – Artefatos da metodologia. 3.2.3 Papeis Desenvolvedor do Compilador – pessoa ou empresa que constrói o compilador. Fabricante do Microcontrolador – empresa que projeta e fabrica o microcontrolador. Desenvolvedor da Plataforma – desenvolvedor especialista, que conhece bem o hardware utilizado no projeto, tem boas noções de desenvolvimento embarcado e de sistemas operacionais. Desenvolvedor da Aplicação – desenvolvedor que não precisa ter conhecimento especializado de desenvolvimento embarcado, mas conhece os requisitos da aplicação embarcada.. 28.

(40) 3.2.4 Fluxo das atividades O diagrama de atividades representado pela Figura 4 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 (como descrito na Seção 3.1.1), 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.. 29.

(41) Figura 4 – Fluxo de atividades. 3.2.5 Detalhamento das atividades As atividades da metodologia, listadas anteriormente, são detalhadas abaixo: Tabela 4 – Detalhamento da atividade Criar Abstração do Compilador. Atividade: Criar Abstração do Compilador Objetivo: criar e implementar a abstração do compilador Artefatos de entrada: Artefatos de saída: Abstração do Compilador Tabela 5 – Detalhamento da atividade Criar Componente HAL. Atividade: Criar Componente HAL Objetivo: criar e implementar componente da camada HAL Artefatos de entrada: Artefatos de saída: Componente HAL. 30.