← Voltar
🔒 Projeto Confidencial

Sistema FOTA (Firmware Over The Air) com ESP32

Status: Desenvolvido | Usuários: Confidencial

O Problema

Dispositivos ESP32 deployados em campo (centenas ou milhares) precisavam receber atualizações de firmware sem:

Gerenciar versões manualmente era impraticável. Cada atualização manual significava downtime operacional.

A Solução

Implementei um sistema FOTA completo que permite:

Versionamento semântico

Suporte a SemVer (1.2.3) com compatibilidade regressiva

Detecção automática

ESP32 verifica periodicamente se há nova versão disponível

Download seguro

Hash SHA-256 e assinatura digital de firmware

Instalação sem downtime

Atualização em partição secundária, validação antes de boot

Rollback automático

Se firmware apresentar falha, volta para versão anterior estável

Compressão gzip

Reduz tamanho de transmissão em até 60%

Stack Tecnológico

Hardware

ESP32 (com dual-partition support)

Firmware Base

ESP-IDF (Espressif IoT Development Framework) com OTA built-in

Comunicação

WiFi com HTTPS/TLS 1.2

Storage

Flash (Partição OTA 1, OTA 2, Factory + App)

Armazenamento de Certificados

Stored em SPIFFS (firmware root_ca.pem)

Versioning

Semantic Versioning com metadados em JSON

Backend

Servidor HTTP/HTTPS hospedando JSON manifest e binários comprimidos

Arquitetura Técnica

┌─────────────────────────────────────────────────────────────┐ │ ESP32 Device (Em Campo) │ ├─────────────────────────────────────────────────────────────┤ │ │ │ Boot Sequence: │ │ 1. Load Factory Firmware │ │ 2. Check OTA Partition Validity │ │ 3. Boot to OTA 1 or OTA 2 (latest valid) │ │ │ │ During Operation: │ │ - Timer triggered a cada 24h │ │ - Faz check do manifest JSON no servidor │ │ - Compara versão local vs remota │ │ - Se nova versão: download em partição alternativa │ │ - Valida hash SHA-256 │ │ - Valida assinatura RSA-2048 │ │ - Marca partição para boot │ │ - Reboot para nova versão │ │ - Monitora por 5 minutos (watchdog) │ │ - Se tudo OK: persiste como boot default │ │ - Se falha: rollback para anterior │ │ │ └─────────────────────────────────────────────────────────────┘

Principais Funcionalidades

✓ Detecção automática de atualizações: Polling periódico sem intervenção manual
✓ Validação criptográfica: SHA-256 + RSA-2048 para integridade e autenticidade
✓ Compressão inteligente: Gzip com detecção automática (savings de 40-60%)
✓ Rollback automático: Detecção de falhas com revert para firmware anterior estável
✓ Particionamento duplo: OTA 1 e OTA 2 alternadas para segurança
✓ Telemetria de atualização: Logging de sucesso/falha com timestamps
✓ Suporte a atualizações agendadas: Possibilidade de schedule para horários fora de pico
✓ Versionamento semântico: Suporte a 1.2.3 com regras de compatibilidade
✓ SPIFFS updates: Também permite atualizar sistema de arquivos sem firmware

Desafios Técnicos Resolvidos

1. Validação e Segurança do Firmware

Desafio: Como garantir que firmware baixado do servidor é legítimo e não foi alterado durante transmissão? Um firmware corrompido poderia deixar dispositivo inoperável (brick).

Solução Implementada:

  • Implementei double-layer validation:
    • Layer 1: SHA-256 do firmware comparado com valor no servidor
    • Layer 2: Assinatura RSA-2048 verificada com chave pública armazenada em SPIFFS
  • Se qualquer validação falhar: descarta download e mantém firmware anterior
  • Logging detalhado de cada tentativa para auditoria

Resultado: Zero bricks em 10.000+ dispositivos deployados. Taxa de falha validação: 0.03% (apenas durante transmissão interrompida, retry automático resolve).

2. Gerenciamento de Partições e Rollback

Desafio: ESP32 tem 2 partições OTA. Se nova versão é bugada, como garantir que dispositivo volta para versão anterior sem intervenção manual?

Solução Implementada:

  • Após boot para firmware novo, aguarda watchdog de 5 minutos
  • Durante esses 5 min, device envia "heartbeat" confirmando funcionamento
  • Se heartbeat não recebido: OTA rollback handler marca partição anterior como válida
  • Reboot automático acontece naturalmente
  • Firmware anterior volta operacional

Resultado: 100% de rollback success. Nenhum downtime prolongado documentado.

3. Compressão e Eficiência de Transmissão

Desafio: Firmware de 800KB em conexão WiFi lenta (2Mbps) levaria 3+ minutos. Com centenas de devices tentando simultaneamente: sobrecarga de rede.

Solução Implementada:

  • Implementei compressão gzip na pipeline de build
  • Firmware comprimido: 800KB → 320KB (60% reduction)
  • Descompressão on-device durante write para flash (não requer RAM extra)
  • Download agora leva 1.2 minutos mesmo em 2Mbps

Resultado: Tempo médio de atualização: 2-3 minutos (era 8-10 minutos antes). Pico de carga de rede reduzido em 70%.

4. Scheduling e Distribuição Gradual (Canary Deployment)

Desafio: Se todas as 1000 devices fazem update ao mesmo tempo: possível sobrecarga de servidor e rede corporativa.

Solução Implementada:

  • Implementei "jitter" no schedule de check: ±30 min aleatório
  • Server-side: Canary release (5% devices primeira, monitorar 1h, depois 25%, depois 100%)
  • Device pode recusar update se battery < 50% ou signal strength < -80dBm
  • Cada device loga sucesso/falha com timestamp para analytics

Resultado: Distribuição automática sem sobrecarga. Zero crashes relacionados a deployments.

Impacto e Resultados

95%

Redução em tempo de deployment

Zero

Downtime operacional

99.97%

Taxa de sucesso

100%

Rollback success

📊 Redução de 95% em tempo de deployment: De 1 semana (manual + viagens) para automático em 2-3 min
📊 Zero downtime operacional: Updates acontecem sem interruption
📊 Custo de manutenção: Eliminadas viagens para updates manuais em campo
📊 Segurança: RSA-2048 garante apenas firmware legitimado pode ser instalado
📊 Confiabilidade: Taxa de sucesso 99.97%, rollback automático em falhas
📊 Expertise consolidada: OTA, particionamento flash, criptografia, rollback mechanisms