Domando o Hardware: Implementando DevOps no Desenvolvimento Industrial

Olá, Habr! Meu nome é Andrey Biryukov. Sou um especialista independente nas áreas de TI e Segurança da Informação, leciono em centros de treinamento e escrevo livros.

Na internet, é possível encontrar inúmeros artigos dedicados à implementação de DevOps. Eles abordam contêineres, servidores web, bancos de dados e outros serviços corporativos, e suas implementações. O custo de um erro nesses serviços é a indisponibilidade ou interrupção do sistema. No entanto, no desenvolvimento industrial, a situação é bem diferente. Se um erro no código fizer com que o braço de uma escavadeira se mova para uma posição não planejada ou parar a linha de montagem em uma fábrica de automóveis, a paralisação custará dezenas de milhares de dólares por hora. E a atualização do firmware de um parque de dois mil controladores manualmente pode levar um mês.

Mas os desenvolvedores de equipamentos industriais também desejam o DevOps "como no Google", mesmo quando lidam com RS-485 e "hardware puro sem sistema operacional". Neste artigo, veremos, com exemplos reais, como é possível implementar DevOps para o desenvolvimento de equipamentos industriais.

Três Maldições do Desenvolvimento Industrial

Antes de construir um pipeline, é preciso reconhecer algumas limitações que o DevOps web não enfrenta. Para começar, o hardware não é elástico e virtual. Seu controlador pode estar rodando em um processador com frequência de 200 MHz e 64 megabytes de RAM. Você não conseguirá instalar nenhum daemon Docker, runner do GitLab ou script Python nele. Há apenas uma porta serial e o protocolo Modbus.

E o que devemos fazer com isso? Aceitar como fato: os agentes de entrega contínua não vivem no hardware de destino, eles vivem ao lado. Você constrói um gateway de atualização – um dispositivo ou serviço separado que, através de um protocolo industrial (como OPC UA ou MQTT), transmite a imagem do firmware em pedaços e confirma sua integridade.

Vamos considerar um exemplo prático. Um dos clientes tinha controladores com FreeRTOS sem pilha de rede. Eles criaram um gateway em um Raspberry Pi (sim, cheira a DIY doméstico, mas é barato e eficaz), que se conectava fisicamente à porta de depuração JTAG através de um adaptador caseiro. O gateway recebia o binário do Artifactory via HTTPS e atualizava o firmware do controlador. O operador simplesmente apertava um botão na interface web do gateway, em vez de ir ao depósito com um notebook.

A próxima maldição é que a certificação não perdoa mudanças. Se o seu dispositivo entrar em produção médica ou aeronáutica, cada firmware deve ser certificado. O processo leva meses, e durante esse tempo, você não pode implantar cada alteração. Seu ciclo de lançamento não é de cinco minutos, mas de três meses.

Para resolver esse problema, o pipeline pode ser dividido em dois circuitos. O circuito de desenvolvimento – rápido, frequente, sem certificação. Ele roda apenas nos ambientes de teste dos desenvolvedores e nos ambientes HIL (Hardware-in-the-Loop). O circuito de release – raro, rigoroso, com todas as verificações e assinaturas. E o mais importante: automatize não a implantação, mas a preparação para a certificação.

Seu pipeline deve gerar um pacote de documentos:

• Lista de todas as dependências com versões.
• Resultados de cada teste com carimbos de data/hora.
• Diferença entre esta versão e a anterior no nível de linhas de código.

Por exemplo, em um projeto de tomógrafo médico, a certificação levava quatro meses. Não é possível reduzir esse prazo, mas é possível reduzir o tempo de preparação para a certificação de três semanas para duas horas. O pipeline coletava toda a base de evidências: relatórios de análise estática (MISRA), relatórios de cobertura de testes em ambiente HIL, SBOM (Software Bill of Materials) no formato SPDX. Quando o órgão certificador chegava, o engenheiro simplesmente abria a pasta com os artefatos de um release específico.

E, finalmente, o offline é a norma. Redes industriais são frequentemente isoladas fisicamente e não possuem acesso à internet. Não há acesso ao seu Docker Registry privado. Não há como baixar uma dependência do GitHub.

Nesses casos, projete seu pipeline DevOps como um terminal offline tolerante a falhas, talvez até em um fator de forma semelhante ao apresentado na imagem acima. Todos os artefatos devem residir dentro do perímetro.

Todas as dependências devem ser cacheadas localmente. Além disso, o cache não deve ser um "proxy transparente", mas uma cópia completa com verificação de checksums. E mais uma dica: sempre armazene o compilador e todas as toolchains dentro do sistema de controle de versão ou do artifact repository. Daqui a três anos, você não encontrará aquela versão do GCC para MSP430, mas precisará mostrar o produto.

Aqui está mais um pequeno exemplo. Um cliente do setor de petróleo e gás tinha uma instalação na tundra, com comunicação via satélite com um lag de 700 milissegundos e um limite de tráfego de 500 megabytes por mês. O pipeline nessa infraestrutura foi feito em duas etapas. No escritório central, um "kit" era montado – uma imagem de máquina virtual com todos os ambientes, dependências, toolchains e os firmwares estáveis mais recentes. Essa imagem era gravada em um drive NVMe e levada para o local por um trabalhador em um helicóptero. No local, um GitLab Runner local e toda a infraestrutura eram implantados em um único servidor.

Arquitetura de Pipeline Industrial

Agora, vamos à estrutura específica. Aqui, teremos que esquecer o clássico trio Dev – Test – Prod, pois para a indústria ele funciona de maneira diferente. Teremos várias camadas, cada uma utilizada para tarefas específicas.

Camada Zero: Sandbox – estação de trabalho do desenvolvedor. Nesta camada, tudo é permitido. Emulação QEMU, kernel panics, depuradores, profilers. O desenvolvedor compila o código em seu ambiente, adiciona testes unitários, verifica a estática. Esta etapa não deve levar mais de dez minutos, caso contrário, o desenvolvedor começará a commitar código não depurado "para o servidor, para que eles verifiquem lá".

Aqui, configuramos a compilação automática a cada salvamento de arquivo (por exemplo, via act ou nektos local), bem como a inicialização de um emulador de periféricos e a execução de testes modulares rápidos.

Camada Um: Hardware-in-the-Loop (HIL) – hardware real em condições controladas. Nesta camada, já temos um controlador real (ou vários) na bancada do laboratório. Sinais de teste são aplicados a ele por um gerador. Ele controla não a instalação real, mas seu emulador – uma segunda placa ou um simulador de carga.

Um pequeno exemplo da vida de desenvolvedores de equipamentos de elevador. O ambiente de teste consistia em dois PLCs industriais. Um era o que estava sendo testado (nosso software), o outro era um emulador de poço (movia motores, fechava sensores de porta). Entre eles – isolamento elétrico por relés. No pipeline, após cada pull request, um cenário era executado: "abra a porta, carregue a cabine com 300 kg, vá para o terceiro andar". Se o elevador errasse o andar – o teste falhava.

Vale ressaltar aqui que o hardware é sempre menor que o número de desenvolvedores. Portanto, os ambientes HIL são um recurso limitado. E para trabalhar com eles, é preciso implementar uma fila de execução. Um pull request não inicia os testes imediatamente, mas entra em uma fila. No entanto, um merge na branch principal – inicia obrigatoriamente o conjunto completo em todos os ambientes disponíveis, mesmo que isso leve a noite toda.

Camada Dois: FAT (Factory Acceptance Testing) – testes de aceitação. Esta etapa não é realizada pelo desenvolvedor, mas pelo tecnólogo ou engenheiro de serviço. O sistema completo é montado: vários controladores, painel do operador, sensores reais e atuadores (mas sem carga de produção). Aqui, o código não é atualizado automaticamente. Apenas por comando humano.

Nesta camada, o DevOps deve automatizar a preparação do ambiente para o FAT. Seu pipeline, por meio de uma tag de release (por exemplo, v2.3.0-fat), deve:

• Compilar os firmwares para todos os tipos de controladores (painel principal, estação remota, sensores de pressão).
• Empacotá-los em um único arquivo com um manifesto.
• Gerar instruções de atualização com um checklist para o tecnólogo.
• Registrar o log de compilação e os checksums de cada binário.

O tecnólogo pega este arquivo, carrega-o em um notebook, vai até o ambiente de teste e atualiza tudo de acordo com as instruções. Ele faz isso manualmente. Porque, se algo der errado durante o FAT, ele deve estar ciente do processo.

Camada Três: Production – hardware em um local real. Aqui, o princípio "pull, não push" é aplicado. O sistema não implanta atualizações forçadamente. Em vez disso, cada dispositivo (gateway, controlador) consulta periodicamente um servidor especial: "Existe uma nova versão assinada para o meu modelo e revisão?". Se houver – o dispositivo baixa, verifica a assinatura, compara a compatibilidade e aplica a atualização (nem sempre pela rede – às vezes através do próprio gateway via RS-485).

Como isso se parece no código. Você tem um repositório Git de releases. Cada release é uma tag no formato release/2025.03.18/tomograph-2.4.1. Na pasta manifests há um arquivo YAML:

yaml
device_model: "Tomograph-X7"
hw_revision: "Rev.C"
firmware_version: "2.4.1"
sha256: "a7f3c9e1..."
signature: "RSA:... (assinado com chave privada)"
url: "https://updates.internal.company/firmwares/tomograph_x7_v2.4.1.bin"
min_compatible_hw: "Rev.B" # pode atualizar a partir de Rev.B, mas não de Rev.A

O dispositivo baixa este manifesto, verifica a assinatura com a chave pública embutida na memória não volátil e, se tudo estiver OK, baixa o binário.

O princípio principal: você não gerencia a atualização forçadamente. Você anuncia a disponibilidade de uma nova versão. Quando instalá-la – decide o proprietário da produção. Às vezes – nunca, e isso também é normal.

Automação de Segurança

O desenvolvedor web pensa em segurança como proteção contra invasões. O desenvolvedor industrial pensa em segurança também como proteção contra o "idiota". Aqui, é preciso assimilar uma regra simples: sem assinatura digital, não há deploy.

Cada binário que chega ao hardware real (e até mesmo ao ambiente HIL) deve ser assinado. A chave de assinatura está em um módulo HSM separado, ao qual apenas o responsável pelos releases tem acesso. Além disso, não se assina apenas um arquivo, mas toda a compilação. Se alguém substituir o firmware do controlador, mas não assinar o manifesto novamente – o dispositivo rejeitará a atualização.

Para implementar isso no pipeline, adicione um passo sign artifacts após todos os testes, mas antes da arquivagem. Ele funciona apenas para tags release/* e não funciona para branches de desenvolvimento. A assinatura é colocada em um arquivo separado .sig ao lado do binário. Ao mesmo tempo, no dispositivo, a verificação leva microssegundos.

Além da assinatura digital, para cada release, um SBOM (Software Bill of Materials) deve ser desenvolvido. Esta é uma lista de todos os componentes: bibliotecas, frameworks, até mesmo fragmentos de código de repositórios de terceiros. Para a indústria, isso é crítico: se amanhã uma vulnerabilidade for encontrada em sua versão do FreeRTOS, você deve ser capaz de dizer instantaneamente em quais dispositivos ela está instalada.

Para gerar o SBOM, no final do pipeline, uma ferramenta é executada (por exemplo, FOSSA ou um script simples que analisa as dependências do linker). Ele cria um arquivo no formato CycloneDX XML. Este arquivo é colocado nos artefatos do release e assinado com a mesma chave. Meio ano depois, em uma auditoria, você simplesmente mostra a pasta com todos os releases e seus SBOMs.

Exemplo prático. Em um projeto de petróleo e gás, o regulador exigiu um relatório sobre uma biblioteca com uma vulnerabilidade crítica. O cliente tinha 3000 controladores em três locais. Um script que em três minutos percorreu todos os manifestos, encontrou 42 dispositivos com a versão vulnerável e gerou uma tarefa para a equipe de serviço. Sem SBOM, seria necessário visitar cada gabinete manualmente.

O que fazer com Projetos Legados

Sim, legados na indústria são abundantes, mas se livrar de soluções desatualizadas aqui é ainda mais difícil do que em ambientes corporativos. Suponha que você tenha um sistema de dez anos. A compilação é feita via Makefile, que não armazena nada em cache, os binários são distribuídos por pendrives, a documentação está em arquivos Word em um disco compartilhado. Você dirá que DevOps não pode ser implementado lá. Na verdade, pode ser implementado, mas não integralmente.

Para começar, remova as pessoas do ciclo de compilação. Atualmente, seu engenheiro compila o firmware localmente, depois o copia para um pendrive. Crie um script de compilação (envolva suas instruções em um script bash) que é executado em um servidor dedicado por comando de chat. O artefato é armazenado em uma pasta compartilhada com a data e o commit. Do ponto de vista da automação, isso já é um progresso.

Em seguida, adicione uma verificação automática após a compilação. Um teste simples: "o binário não excede 512 kilobytes? Ele tem uma seção .text?". Se falhar – a compilação é considerada malsucedida, não é copiada para o pendrive.

No próximo passo, introduza controle de versão para firmwares. Crie um simples SQLite ou até mesmo um arquivo de texto onde você registra: data de compilação, versão do firmware, de qual commit, em quais dispositivos está instalado. Isso já é um banco de dados de configurações.

Como resultado, em três meses, você não terá DevOps, mas "rotina bem organizada", e isso é 80% do caminho.

Armadilhas Organizacionais e Como Contorná-las

A parte técnica é metade do trabalho. A outra metade é convencer as pessoas a trabalhar de novas maneiras. E nesse caminho, algumas armadilhas nos espreitam.

Armadilha um: "temos requisitos especiais aqui, a automação não serve". Geralmente, isso é dito pelo principal tecnólogo ou engenheiro de segurança. Eles estão certos no sentido de que a automação não deve quebrar os processos de validação. Mas eles estão errados ao dizer que a automação é impossível.

Para resolver esse problema, convide-os a participar do projeto do pipeline. Deixe-os definir as regras: "antes de compilar o firmware de release, a verificação A, B e C deve ser executada". Você implementa essas regras no código do pipeline. Como resultado, seus requisitos não são ignorados, mas se tornam passos rígidos e reproduzíveis. E os engenheiros param de ter medo.

A próxima armadilha, ou melhor, um equívoco clássico: "de qualquer forma, não podemos implantar com frequência, para que precisamos de CI/CD?". DevOps na indústria não é medido pela frequência de releases, mas pelo tempo de recuperação após uma falha e pelo custo de certificação. Mostre os números: quantas horas-homem por mês são gastas na compilação manual de firmwares. Quantas vezes um engenheiro esqueceu de ativar a otimização no compilador e compilou uma versão de debug que fica lenta. Quanto custa a paralisação porque "o arquivo HEX necessário foi levado por aquele notebook do Petrov em uma viagem de negócios".

Outro problema sério é a falta de tempo. A automação requer investimentos agora, e o retorno vem em seis meses. Projetos com ciclos longos são característicos da indústria.

Para resolver isso, não pegue o projeto inteiro, mas um único ponto problemático. O mais doloroso. Aquele onde os engenheiros amaldiçoam o processo atual todos os dias. Automatize apenas isso. Não construa um pipeline perfeito – crie um script feio que resolve 80% do problema, mas é executado com um clique. Quando todos virem que ficou mais fácil, o resto virá naturalmente.

O que resta no final

Todo este guia pode ser resumido em uma tese: na indústria, DevOps não tem a velocidade como métrica. A métrica é a previsibilidade. Você deve saber exatamente qual código está em cada dispositivo, como ele foi compilado, quem o assinou, quais testes ele passou e como reverter para uma versão de um ano atrás, se os novos sensores não chegarem ao depósito.

Comece pequeno. Pegue um tipo de controlador, um ambiente de teste, um firmware. Automatize sua compilação. Adicione assinatura digital. Escreva um script que verifique a assinatura antes de atualizar o firmware. Isso já é uma vitória.

E lembre-se: daqui a cinco anos, alguém dará manutenção ao seu sistema. E essa pessoa agradecerá se seus firmwares estiverem em um artifact repository, e não em um pendrive esquecido na gaveta de um engenheiro demitido.

Se você quiser continuar o tema de DevOps, automação e infraestrutura confiável, dê uma olhada nas aulas abertas da OTUS. Elas são ministradas gratuitamente como parte de cursos online por professores – você pode conhecer os especialistas e fazer perguntas.

3 de junho, 20:00 – "Internal Developer Platform: infraestrutura self-service em uma noite". Inscrever-se Discutiremos como simplificar o trabalho dos desenvolvedores através de uma plataforma interna e infraestrutura self-service.

4 de junho, 20:00 – "Bash Avançado". Inscrever-se Falaremos sobre scripts e técnicas de automação que ajudam a eliminar a rotina manual dos processos de engenharia.

Mais eventos – no calendário de aulas da OTUS. E também assine o canal OTUS no MAX para não perder novos materiais e anúncios.