Update OTA IoT: como o caso Samsung brickou frigoríficos

Um update de firmware mal testado, milhares de frigoríficos Samsung travados, e um ex-funcionário da marca a confirmar o pior sobre o ecossistema da empresa. Segundo o Abertoatedemadrugada.com, a situação é tão grave que afecta eletrodomésticos de gama alta. Para quem trabalha com desenvolvimento, engenharia de software e sistemas distribuídos, o caso é uma aula prática sobre o que acontece quando uma empresa negligencia processos de deployment, testes de regressão e arquitetura de atualização em dispositivos IoT. Vou destrinchar isso do ponto de vista de quem programa — porque o mesmo erro que brickou frigoríficos acontece todos os dias em APIs, microsserviços e aplicações em produção.

O Caso Samsung: Quando um Update Vira um Tijolo de Luxo

O relato original do Abertoatedemadrugada.com mostra o pior cenário possível: um update de teste escapou do controle de qualidade e foi enviado para frigoríficos inteligentes da Samsung. Resultado? Aparelhos que provavelmente custam entre 2.000€ e 5.000€ transformaram-se em armários verticais climatizados. Sem resposta, sem display funcional, sem controle de temperatura.

Para um programador, isso é equivalente a um deploy em produção que derruba todas as instâncias de uma API e deixa clientes sem serviço. A diferença é que, no caso da Samsung, o “cliente” não consegue nem reiniciar manualmente — o aparelho virou tijolo até a marca resolver remotamente (se conseguir).

O ex-funcionário citado no artigo foi taxativo: “NAO COMPREM SAMSUNG! Baterias de telefones explosivas, frigorificos que encravam, televisoes que escutam, maquinas de lavar que explodem, exploracao de empregados, etc…”. Pode parecer exagero, mas vindo de quem trabalhou lá dentro, tem peso. E há um padrão aí: a Samsung tem histórico consistente em updates problemáticos, do Galaxy Note 7 ao firmware de smart TVs.

Por Que Isso Acontece do Lado de Quem Programa

Updates OTA (Over-The-Air) em dispositivos IoT são, na essência, pipelines de CI/CD rodando em hardware que o usuário final não pode abrir facilmente. O fluxo básico é:

1. Servidor backend envia nova versão do firmware
2. Dispositivo baixa, valida checksum, aplica
3. Reinicia e, idealmente, reporta sucesso

O erro mais comum — e o que provavelmente aconteceu com os frigoríficos — é falhar no passo 2 ou não implementar rollback robusto no passo 3. Quando o firmware novo corrompe a partição crítica, o dispositivo não tem como voltar atrás sem intervenção externa.

Na minha experiência lidando com sistemas embarcados e deploys em produção, vejo três causas raiz recorrentes:

• Falta de feature flags com kill switch — mesmo quando o update está aplicado, deveria haver uma forma remota de reverter sem novo flash.
• Partição única sem A/B update scheme — esquema clássico do Android moderno, mas que muitos fabricantes de IoT ignoram por economia.
• Testes em ambiente simulado, não em hardware real — emulador não reproduz edge cases de temperatura, memória fragmentada, ou wear leveling de flash.

Como Sistemas de Update Deveriam Funcionar

Se eu estivesse projetando o sistema de OTA da Samsung hoje, implementaria algo parecido com isto:

Na Prática: Estrutura Básica de um Sistema de Update com Rollback

O conceito central é simples: sempre manter duas partições (A e B), atualizar a inativa, validar, e só então promover como ativa. Se algo correr mal, basta voltar para a partição anterior.

# Exemplo simplificado de um gerenciador de update OTA
# Conceito aplicado a dispositivos IoT com partições A/B

import hashlib
import logging
from enum import Enum

logger = logging.getLogger(__name__)


class UpdateStatus(Enum):
    IDLE = "idle"
    DOWNLOADING = "downloading"
    VERIFYING = "verifying"
    APPLYING = "applying"
    PENDING_COMMIT = "pending_commit"
    COMMITTED = "committed"
    ROLLED_BACK = "rolled_back"


class OTAManager:
    def __init__(self, current_partition="A"):
        self.active_partition = current_partition
        self.inactive_partition = "B" if current_partition == "A" else "A"
        self.status = UpdateStatus.IDLE
        self.boot_count_after_update = 0
        self.MIN_BOOTS_TO_COMMIT = 3  # validação por 3 reboots antes de efetivar

    def verify_firmware(self, firmware_bytes, expected_sha256):
        """Verifica integridade ANTES de gravar na flash."""
        sha = hashlib.sha256(firmware_bytes).hexdigest()
        if sha != expected_sha256:
            logger.error(f"Checksum falhou: esperado {expected_sha256}, recebi {sha}")
            return False
        return True

    def apply_update(self, firmware_bytes, expected_sha256):
        """Aplica update na partição inativa. Falha silenciosa aqui = tijolo."""
        try:
            if not self.verify_firmware(firmware_bytes, expected_sha256):
                return False

            self.status = UpdateStatus.APPLYING

            # Grava na partição INATIVA (B), nunca na ativa (A)
            write_to_flash(self.inactive_partition, firmware_bytes)

            # Marca boot loader para usar B no próximo boot
            set_boot_partition(self.inactive_partition)

            self.status = UpdateStatus.PENDING_COMMIT
            logger.info(f"Update aplicado em {self.inactive_partition}. Aguardando confirmação.")
            return True

        except Exception as e:
            logger.exception(f"Falha crítica durante update: {e}")
            self.status = UpdateStatus.ROLLED_BACK
            return False

    def on_successful_boot(self):
        """Chamado pelo watchdog a cada boot bem-sucedido."""
        if self.status == UpdateStatus.PENDING_COMMIT:
            self.boot_count_after_update += 1
            logger.info(f"Boot OK pós-update: {self.boot_count_after_update}/{self.MIN_BOOTS_TO_COMMIT}")

            if self.boot_count_after_update >= self.MIN_BOOTS_TO_COMMIT:
                self.commit_update()

    def commit_update(self):
        """Efetiva a nova partição como ativa permanentemente."""
        self.active_partition = self.inactive_partition
        self.status = UpdateStatus.COMMITTED
        logger.info(f"Update commitado em {self.active_partition}")

    def rollback(self):
        """Volta para a partição anterior em caso de falha."""
        set_boot_partition(self.active_partition)
        self.status = UpdateStatus.ROLLED_BACK
        logger.warning(f"Rollback para partição {self.active_partition}")


def write_to_flash(partition, data):
    # implementação real dependeria do hardware (mtd, ubi, mmcblk)
    pass

def set_boot_partition(partition):
    # escrever em u-boot env ou equivalente
    pass

Esse padrão — conhecido como A/B update, dual partition ou seamless updates — é usado pelo Android, ChromeOS e sistemas críticos. Frigoríficos inteligentes com Wi-Fi, tela LCD e processador ARM rodando Linux têm capacidade técnica para isso. Não é rocket science. É boa engenharia.

Erros Comuns em Sistemas OTA que Destroem Dispositivos

Lista de armadilhas que vejo em código de produção e que provavelmente estavam presentes no update da Samsung:

• Atualizar a partição ativa sem testar — sem watchdog timer que volte à versão anterior se o boot falhar.
• Ignorar validação de assinatura digital — permite que updates maliciosos ou corrompidos sejam aplicados.
• Não testar com pouca memória flash disponível — wear leveling e fragmentação causam comportamentos inesperados.
• Aplicar update durante horário impróprio — interromper no meio do flash (queda de energia) = tijolo garantido.
• Falta de feature flags remotas — desligar uma função problemática sem precisar de novo update.
• Telemetria insuficiente — não saber qual versão cada dispositivo está rodando antes de mandar update.

Na minha experiência, o pior de todos é o primeiro. Equipas apressadas para cumprir prazo mandam update sem implementar watchdog. Quando o firmware novo tem bug de boot, o dispositivo morre silenciosamente.

Comparação: Outras Marcas e Abordagens

A Samsung não é a única, mas é a mais midiática. Veja como outras gigantes lidam (ou não) com isso:

Note como o ecossistema mobile evoluiu bem, mas IoT doméstico (eletrodomésticos, smart TVs, routers) ficou para trás. É exactamente aí que a Samsung pisa na bola.

FAQ — Perguntas Que Todo Dev Faz

1. Como um update pode brickar um frigorífico?
Gravando firmware corrompido ou buggy na partição ativa sem sistema de rollback. Sem forma de voltar atrás, o dispositivo torna-se inútil até intervenção técnica externa.

2. Existe forma de o utilizador recuperar?
Depende do fabricante. Samsung geralmente oferece reparação, mas em alguns casos é necessária substituição completa. Para devs que constroem estes sistemas, a recomendação é sempre oferecer caminho de recuperação — porta serial, recovery mode via combinação de botões, ou DFU mode.

3. O que é A/B update e por que é importante?
É esquema onde o dispositivo tem duas cópias do sistema. Updates vão para a partição ociosa. Se o novo falhar, o bootloader volta automaticamente para a anterior. É o padrão usado em Android moderno e essencial para qualquer IoT sério.

4. Como saber se um dispositivo que vou comprar tem update seguro?
Procure na documentação menção a “rollback”, “A/B partition”, “dual bank firmware” ou “failsafe update”. Marcas como Apple, Google e algumas linhas premium da Bosch já adotam. Eletrodomésticos genéricos raramente têm.

5. Isso pode acontecer com qualquer dispositivo IoT?
Sim. Qualquer dispositivo que receba update remoto sem proteção adequada está sujeito. É por isso que, ao desenvolver IoT, implementar watchdog, rollback e validação de assinatura não é opcional — é obrigação.

Implicações Para Quem Trabalha com Tech

Se você está a desenvolver qualquer sistema que envia código remotamente — seja uma app mobile, firmware embarcado, configuração de servidor ou modelo de IA em edge — copie as lições deste caso:

• Sempre tenha plano B — rollback automático é obrigatório.
• Teste em hardware real, não só em emulador — frigoríficos reais têm comportamentos diferentes de ambientes simulados.
• Implemente staged rollout — 1% dos dispositivos primeiro, depois 10%, depois 100%. Se a Samsung tivesse feito isso, afetaria centenas, não milhares.
• Tenha telemetria honesta — saber rapidamente quais dispositivos falharam pós-update é a diferença entre recall e suporte reactivo.
• Feature flags salvam vidas — desligar uma feature problemática remotamente é melhor que flash novo.

No fundo, o caso dos frigoríficos Samsung é um lembrete brutal de que engenharia de software não é só fazer código bonito — é entender os riscos do que se coloca em produção. O mesmo princípio que derrubou eletrodomésticos de luxo pode derrubar a sua aplicação, o seu cluster Kubernetes ou o seu pipeline de IA.

Para devs que trabalham com deploy contínuo, vale a pena estudar sistemas como o OSTree (usado no Fedora IoT), RAUC (Robust Auto-Update Controller) para Linux embarcado, e SWUpdate. São projetos maduros que resolvem exactamente o problema que a Samsung claramente não resolveu.

💻 Ver no GitHub

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.