Resumo Executivo

André Ribeiro Cláudio; Everton Gomede

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

O avanço das tecnologias de conectividade, sensoriamento e a miniaturização de componentes eletrônicos impulsionaram o crescimento exponencial da Internet das Coisas. Nesse cenário, surgiram novas aplicações e desafios complexos relacionados à construção de sistemas operacionais para dispositivos embarcados, os quais exigem ambientes específicos para atender às restrições severas de hardware e operação (Santos et al., 2016). Historicamente, o desenvolvimento desses ambientes baseou-se em métodos manuais ou no uso de imagens pré-configuradas, como o Raspberry Pi OS. Tais práticas, contudo, demonstram limitações críticas quanto à reprodutibilidade e ao rastreamento das configurações e versões dos artefatos gerados. Torna-se difícil assegurar que ambientes distintos alcancem o mesmo estado funcional sem uma intervenção humana intensiva e propensa a falhas. A necessidade de padronização em larga escala exige abordagens que transcendam a configuração artesanal de dispositivos.

Dentro dessa problemática, o conceito de Infraestrutura como Código (IaC) surge como uma solução para definir infraestrutura e procedimentos operacionais por meio de arquivos de configuração legíveis por máquina. A aplicação de IaC facilita a padronização e a automação de fluxos de construção e distribuição de software, permitindo que a infraestrutura seja tratada com o mesmo rigor que o código-fonte de uma aplicação (Morris, 2021). No ecossistema de sistemas embarcados, surgiram práticas e ferramentas de código aberto que suportam a criação de processos altamente reproduzíveis e com histórico de versões. O Yocto Project destaca-se como uma plataforma para a geração de distribuições Linux customizadas, enquanto o KAS atua na orquestração declarativa das camadas de configuração e arquivos de compilação (Siemens, 2025). Complementarmente, o uso de Podman permite a abstração e o isolamento do ambiente de compilação, garantindo que as dependências do sistema hospedeiro não interfiram na geração da imagem final (Podman Project, 2025).

A fundamentação teórica que sustenta a automação de imagens Linux baseia-se na modularidade e na herança de camadas. O Yocto Project utiliza receitas e camadas para definir cada componente do sistema, desde o carregador de inicialização até as aplicações de nível de usuário. Essa estrutura permite que desenvolvedores criem sistemas enxutos, contendo apenas o necessário para a operação do dispositivo IoT, o que reduz a superfície de ataque e otimiza o uso de recursos de hardware limitados (Yocto Project, 2025). A integração dessas ferramentas visa substituir a configuração manual, que carece de auditabilidade, por um fluxo de trabalho onde cada alteração é registrada em sistemas de controle de versão. O objetivo central dessa transição é reduzir o esforço humano em tarefas repetitivas e garantir que uma imagem gerada hoje seja idêntica a uma gerada no futuro, independentemente do operador ou da máquina de compilação utilizada.

A justificativa para a investigação de métodos automatizados reside na crescente demanda por escalabilidade em projetos de Internet das Coisas. Em ambientes industriais ou de cidades inteligentes, a implantação de centenas de dispositivos exige que a atualização e a manutenção do software sejam realizadas de forma ágil e confiável. Métodos tradicionais, baseados em ferramentas de gravação de imagens oficiais seguidas de ajustes manuais, tornam-se gargalos operacionais. Assim, a comparação entre a abordagem baseada em IaC e o método tradicional permite quantificar os ganhos de eficiência e a redução de erros. O foco reside em avaliar o esforço necessário para alcançar um resultado funcional idêntico em um dispositivo embarcado, medindo variáveis como tempo de configuração, número de passos manuais e a consistência dos artefatos produzidos.

A metodologia adotada para a realização deste estudo caracterizou-se como aplicada e experimental, fundamentada na comparação direta entre dois métodos de construção de imagens Linux para a placa Raspberry Pi Zero 2W. O primeiro método utilizou uma abordagem automatizada baseada nos princípios de IaC, integrando Yocto Project, KAS e Podman. O segundo método seguiu o fluxo tradicional, empregando a ferramenta Raspberry Pi Imager para a gravação de uma imagem oficial, seguida de intervenções manuais para configuração de serviços. O ambiente de hardware consistiu em um computador de desenvolvimento equipado com um processador AMD Ryzen 5600G, 16 GB de memória RAM DDR4 e um SSD NVMe de 1 TB, operando sob o sistema Fedora 42. Essa configuração robusta foi selecionada para garantir que a capacidade de processamento não fosse um limitador durante as etapas de compilação intensiva.

No escopo do software para a abordagem IaC, utilizou-se a versão scarthgap-5.0.11 do Yocto Project e a versão 4.8.1 do KAS. O isolamento do ambiente foi realizado pelo Podman na versão 5.5.2. O processo operacional iniciou-se com a criação de um arquivo de instruções denominado Containerfile, que definiu todas as etapas para montar o ambiente de compilação dentro de um contêiner. Esse arquivo incluiu a instalação de dependências essenciais e a configuração de permissões de usuário para preservar a integridade dos arquivos gerados. O comando de construção do contêiner utilizou argumentos para sincronizar o identificador de usuário e de grupo do sistema hospedeiro com o ambiente interno, facilitando o acesso aos arquivos de saída. Após a preparação do contêiner, executou-se a orquestração via KAS, que gerenciou o download das camadas necessárias para a Raspberry Pi Zero 2W e iniciou o processo de compilação através do BitBake.

O processo de compilação via BitBake envolveu o processamento de receitas para gerar uma imagem personalizada denominada rasp-custom-img-base. Esta etapa produziu um arquivo comprimido com extensão .bz2, contendo o sistema de arquivos raiz e o kernel. A gravação no cartão microSD foi realizada através do utilitário bzcat em conjunto com o comando dd, utilizando um tamanho de bloco de 8 MB para otimizar a transferência de dados e a opção de sincronização de dados para garantir a persistência física das informações. Todo o fluxo foi desenhado para ser executado com o mínimo de intervenção humana após o disparo dos comandos iniciais, refletindo a filosofia de infraestrutura declarativa.

Para o método tradicional, utilizou-se o Raspberry Pi Imager, ferramenta oficial da Raspberry Pi Foundation (2025). O procedimento envolveu a seleção manual da imagem Raspberry Pi OS Lite, a escolha do dispositivo de destino e a confirmação da gravação. Após a conclusão da escrita no cartão microSD, o dispositivo foi inicializado para a realização das configurações pós-instalação. Estas etapas manuais incluíram a configuração de credenciais de rede sem fio, a edição de arquivos de configuração do sistema para habilitar interfaces de comunicação e a instalação manual de um serviço de mensageria baseado em MQTT. Cada comando foi digitado individualmente pelo operador, e a verificação do funcionamento do serviço foi feita através de ferramentas de monitoramento de processos no terminal.

A coleta de dados quantitativos concentrou-se no registro rigoroso dos tempos de execução de cada etapa. Para a abordagem IaC, mediram-se os tempos da primeira execução, que envolve o download de todas as bibliotecas e a compilação completa, e das execuções subsequentes, que aproveitam os artefatos pré-compilados armazenados em cache. Também foi registrado o tempo necessário para adicionar uma nova ferramenta de depuração, o htop, ao escopo declarativo da imagem. No método tradicional, cronometrou-se o tempo de download e gravação da imagem oficial e, separadamente, o tempo gasto nas operações manuais de configuração. A análise qualitativa focou na consistência dos artefatos, verificando se o tamanho das imagens e os serviços ativos eram idênticos entre diferentes rodadas de teste.

Os resultados obtidos revelaram disparidades significativas entre as duas abordagens, especialmente no que tange à distribuição do esforço ao longo do tempo. Na primeira execução do método baseado em IaC, o processo demandou 1 h 25 min 35 s. Esse intervalo compreendeu o download de 4813 tarefas, a análise de receitas, a compilação de binários e a geração da imagem final de 93.092.556 bytes. Embora o tempo inicial seja elevado, ele reflete a construção de uma base sólida e totalmente automatizada. Em contrapartida, quando se realizou uma execução subsequente sem alterações no código, o tempo de processamento caiu drasticamente para apenas 13 s. Esse fenômeno ocorre devido à capacidade do Yocto Project de reutilizar artefatos pré-compilados, processando apenas o que é estritamente necessário para validar a integridade da imagem.

A eficiência da abordagem incremental foi testada ao adicionar a ferramenta de depuração htop ao arquivo de configuração declarativo. O sistema identificou a mudança na camada de aplicação e realizou a recompilação apenas dos componentes afetados, concluindo a tarefa em 2 min 23 s. O tamanho da imagem resultante foi de 93.258.971 bytes, representando um acréscimo de 166.415 bytes, correspondente ao binário da ferramenta adicionada. Esse resultado demonstra a precisão do controle de versão e a previsibilidade do impacto de cada alteração no sistema final. A discussão desses dados aponta que o esforço inicial de configuração das receitas e do ambiente de contêiner é compensado pela agilidade extrema em iterações futuras, o que é vital em ciclos de desenvolvimento ágil.

No método tradicional, o tempo total para atingir o estado funcional foi de aproximadamente 26 min 50 s. A etapa de download e gravação via Raspberry Pi Imager foi rápida, consumindo cerca de 3 min 58 s, seguida por uma verificação automática de 52 s. No entanto, a pós-configuração manual exigiu 22 min de intervenção direta do operador. Durante esse período, foram realizados procedimentos de cópia de arquivos, edição de parâmetros de rede e habilitação de serviços via linha de comando. Embora o tempo total inicial seja menor que a primeira compilação do IaC, o esforço humano é repetitivo. Se fosse necessário gerar 10 cartões microSD idênticos, o método tradicional exigiria a repetição dos 22 min de configuração manual para cada unidade, ou a criação manual de uma imagem de backup, o que introduz riscos de inconsistência se pequenos ajustes forem esquecidos entre as cópias.

A comparação da reprodutibilidade evidenciou que a metodologia IaC garante resultados idênticos em diferentes execuções, pois o processo é regido por scripts e arquivos de configuração estáticos (Morris, 2021). No caso do Raspberry Pi Imager, a ferramenta fornece sempre a versão oficial mais recente, o que pode introduzir variações inesperadas se a imagem base for atualizada pelo fabricante sem aviso prévio. Além disso, a dependência da memória e da precisão do operador para repetir comandos manuais introduz uma variável de incerteza que compromete a auditabilidade do processo. A análise mostrou que a abordagem IaC concentrou o esforço na etapa de definição, enquanto o método tradicional transferiu o trabalho para etapas operacionais que se repetem a cada nova execução.

O fator de aceleração observado na abordagem IaC, ao comparar a primeira execução com as subsequentes, foi de aproximadamente 395 vezes. Esse dado é um indicador potente da eficiência da automação em projetos de longo prazo. A discussão sobre a implicação prática desses resultados sugere que, para desenvolvedores de soluções IoT, a adoção de ferramentas como Yocto e KAS reduz o custo técnico da manutenção. A capacidade de documentar a infraestrutura como código permite que novos membros da equipe compreendam rapidamente como o sistema é construído, eliminando o conhecimento tácito e isolado que geralmente acompanha processos manuais. A integração com o broker MQTT (Eclipse Mosquitto Project, 2025) foi validada em ambos os métodos, mas apenas no IaC a configuração do serviço estava intrinsecamente ligada à definição da imagem, garantindo que o serviço estivesse ativo desde o primeiro boot sem ajustes extras.

As limitações observadas no estudo referem-se principalmente à curva de aprendizado inicial das ferramentas de IaC. A complexidade de configurar o Yocto Project e o KAS exige um conhecimento técnico mais profundo em comparação ao uso de ferramentas gráficas simples como o Raspberry Pi Imager. No entanto, os dados quantitativos reforçam que esse investimento inicial se paga rapidamente através da redução do tempo de iteração e da garantia de qualidade. Para pesquisas futuras, sugere-se a investigação da integração desses fluxos de IaC com pipelines de Integração Contínua e Entrega Contínua (CI/CD), permitindo que a geração de imagens seja disparada automaticamente a cada commit no repositório de código.

A análise do impacto no espaço de armazenamento revelou que a inclusão de pacotes via IaC é cirúrgica. O acréscimo de 166.415 bytes ao adicionar o htop confirma a relação direta entre a declaração de dependências e o crescimento da imagem. No método tradicional, muitas vezes instalam-se pacotes que trazem dependências desnecessárias, aumentando o tamanho do sistema de arquivos de forma descontrolada. A precisão do Yocto Project em compilar apenas o necessário resulta em sistemas mais leves e eficientes, adequados para dispositivos com armazenamento limitado, como a Raspberry Pi Zero 2W. A consistência dos artefatos foi comprovada pela verificação de que cada bit da imagem gerada por IaC correspondia ao planejado no escopo declarativo.

Conclui-se que o objetivo foi atingido, uma vez que a comparação detalhada demonstrou que a abordagem baseada em Infraestrutura como Código (IaC) supera o método tradicional em termos de reprodutibilidade, auditabilidade e eficiência em longo prazo. Embora a metodologia IaC exija um esforço inicial significativamente maior, com um tempo de compilação de 1 h 25 min 35 s na primeira execução, a redução para apenas 13 s em iterações subsequentes gera um fator de aceleração de 395 vezes que viabiliza o desenvolvimento ágil. O método tradicional, apesar de permitir uma inicialização rápida em cerca de 26 min 50 s, mostrou-se ineficiente devido à dependência de intervenções manuais repetitivas e à falta de controle de versão rigoroso sobre as configurações do sistema. A utilização de ferramentas como Yocto Project, KAS e Podman consolidou-se como a estratégia mais adequada para a criação de soluções IoT escaláveis, garantindo que a infraestrutura seja tratada com a mesma precisão e rastreabilidade do software de aplicação.

Referências Bibliográficas:

Eclipse Mosquitto Project. (n.d.). Eclipse Mosquitto — documentação / broker MQTT. Disponível em: <https://mosquitto.org/>. Acesso em: 31 ago. 2025

Morris, K. (2021). Infrastructure as Code: Dynamic Systems for the Cloud Age (2ª ed.). O’Reilly.

Podman Project. (n.d.). Podman — documentação oficial / Getting started. Disponível em: <Podman.io>. Acesso em: 31 ago. 2025

Raspberry Pi Foundation. (n.d.). Raspberry Pi Imager / Raspberry Pi software & documentation. Disponível em: <https://www.raspberrypi.org/>. Acesso em: 31 ago. 2025

Santos, Bruno P and Silva, LA and Celes, CS and Borges, João B and Neto, Bruna S Peres and Vieira, Marcos Augusto M and Vieira, Luiz Filipe M and Goussevskaia, Olga N and Loureiro. 2016. Minicursos SBRC-Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, páginas 5-5.

Siemens / KAS. (n.d.). kas — Setup tool for bitbake based projects (GitHub / docs). Disponível em: <https://github.com/siemens/kas>. Acesso em: 31 ago. 2025

Yocto Project. (n.d.). Yocto Project Reference Manual. The Yocto Project. Disponível em: <docs.yoctoproject.org>. Acesso em: 31 ago. 2025

Resumo executivo oriundo de Trabalho de Conclusão de Curso de Especialização em Engenharia de Software do MBA USP/Esalq

_{Saiba mais sobre o curso; clique aqui:}