O que é o OpenAPS e por que a redundância importa

OpenAPS (Open Artificial Pancreas System) é uma plataforma de código aberto e orientada pela comunidade que permite às pessoas com diabetes construir um sistema de entrega automática de insulina personalizado. Funciona em pequenos computadores de uma só placa — tipicamente um Raspberry Pi ou BeagleBone Black — lendo dados de monitor de glicose contínuo (CGM), executando um algoritmo e controlando sem fio uma bomba de insulina compatível. Enquanto uma configuração de dispositivo único funciona bem para muitos, confiar em uma placa introduz um único ponto de falha. Um cartão SD desfeito, uma falha de energia, uma falha de rede ou um arquivo de configuração corrompido pode interromper a entrega de insulina sem aviso. Para um sistema vital-crítico, esse risco é inaceitável.

Executar dispositivos OpenAPS múltiplos cria uma plataforma redundante e tolerante de falhas que mantém o seu loop de controle funcionando mesmo quando componentes individuais falham. Este guia percorre todos os aspectos: escolher hardware, sincronizar dados entre dispositivos, implementar failover automático, testar sua configuração e mantê-lo ao longo do tempo. No final, você terá uma abordagem pronta para a produção de controle confiável 24/7.

A necessidade central de redundância em um circuito fechado DIY

Em qualquer sistema automatizado, o elo mais fraco determina a confiabilidade geral. Para um circuito fechado DIY, esse elo fraco é muitas vezes o computador de placa única. O hardware pode falhar, o software pode falhar e a conectividade de rede pode cair. Sem redundância, uma falha força o usuário a voltar ao modo manual – controle de loop aberto – até que o problema seja resolvido. Isso pode significar horas ou mesmo dias de gerenciamento de glicose menos otimizado.

  • Operação contínua: Se a placa primária morrer, uma placa secundária assume o controle em segundos.
  • Janelas de manutenção: Atualizar um dispositivo enquanto o outro lida com a terapia, sem interrupção.
  • Paz da mente:] Cuidadores e usuários sabem que há uma espera quente pronta para agir.

A redundância não é apenas sobre failover – ela também melhora ] integridade de dados. Com dois dispositivos registrando os mesmos eventos de forma independente, você tem um registro duplo de entrega de insulina e leituras de glicose. Isso pode ser inestimável para análise pós-hoc e solução de problemas.

Benefícios de um equipamento OpenAPS multidispositivo

Além de simples failover, uma configuração multidispositivo oferece várias vantagens práticas:

  • Resistência ao hardware: Usando dois tipos diferentes de placa (por exemplo, um Framboesa Pi 4 e um BeagleBone Black) protege contra falhas específicas de componentes. Se uma questão de corrupção de cartão SD generalizada afeta um modelo, o outro provavelmente não é afetado.
  • Diversidade de rede: Cada dispositivo pode conectar-se a um ponto de acesso Wi-Fi diferente ou usar uma conexão Ethernet com fio. Se um segmento de rede for abaixo, o outro equipamento mantém conectividade com Nightscout e bomba.
  • Distribuição do lote: Você pode atribuir o dispositivo primário para lidar com o loop (leitura do CGM + algoritmo + comandos de bomba) enquanto o dispositivo secundário atua como um uploader dedicado para Nightscout e uma estação de monitoramento. Isso reduz a latência no caminho crítico.
  • Solado solução de problemas: Quando um problema surge, você pode mudar para o backup e investigar o offline primário sem parar a terapia.
  • Degradação graciosa: Mesmo que um dispositivo falhe, o backup tem acesso aos últimos dados sincronizados, para que possa tomar decisões informadas imediatamente.

Escolher Hardware Compatível

Computadores de um único grupo apoiado

O projeto OpenAPS suporta oficialmente várias plataformas. Para uma configuração redundante, escolha duas placas que são idênticas ou suficientemente semelhantes em capacidades. As opções populares incluem:

  • Raspberry Pi 3B+/4B/5 – Existem muitos guias e suporte comunitário amplamente disponíveis. Use um cartão SD de alta resistência (por exemplo, Samsung Pro Endurance) ou arranque de um SSD ligado a USB para minimizar o risco de corrupção.
  • BeagleBone Black (ou BeagleBone Green) – Inclui armazenamento em flash embutido, tornando-o menos suscetível a problemas de cartão SD. Também tem melhores capacidades em tempo real para comunicação direta com bombas.
  • Intel NUC ou ODROID – Mais poderoso, mas o suporte comunitário é mais fino. Eles podem ser úteis se você precisar de processamento extra para recursos avançados, como aprendizado de máquina.

Para um sistema multidispositivo, usar dois dos mesmos scripts simplifica a configuração e failover. No entanto, misturar um Pi e um BeagleBone também é viável se você mantiver as versões de algoritmo e software idênticas.

Potência e conectividade

A energia confiável é fundamental. Cada dispositivo deve ser alimentado por uma fonte de alimentação 5V dedicada e regulada que possa lidar com o pico de saque da placa (2,5A para um Pi 4, 1A para um BeagleBone). Considere uma pequena fonte de alimentação UPS (ininterruptível) ou uma bateria de alta capacidade que pode manter ambas as placas funcionando através de curtos interrupções de energia. Além disso:

  • Utilizar Ethernet com fios para pelo menos um dispositivo reduzir a latência e evitar interferências Wi-Fi.
  • Se usar Wi-Fi, configure cada dispositivo para um canal diferente ou conecte-se a diferentes pontos de acesso para evitar que ambos percam conectividade simultaneamente.
  • Atribuir endereços IP estáticos ou usar reservas DHCP para garantir que os dispositivos têm sempre os mesmos endereços para monitorização do batimento cardíaco.

Configurar vários dispositivos

Instalação Inicial

Siga a documentação oficial do OpenAPS para cada quadro. Passos para adaptar para multidispositivo:

  • Nomes de máquinas únicos: Nome de um dispositivo e o outro (ou similar) para evitar conflitos de rede e tornar os logs claros.
  • A mesma versão de software: Instale a mesma versão do OpenAPS (por exemplo, oref0 versão 0.7.x) em ambos os dispositivos.Versões incorretas podem levar a diferentes comportamentos de algoritmo durante o failover.
  • Separar arquivos de configuração: Cada dispositivo precisa de seu próprio , , e . Não simplifique-os através de dispositivos – mantenha cópias para evitar sobreposições acidentais.
  • Configurações controladas por versão: Armazenar arquivos de configuração em um repositório Git privado (por exemplo, no GitHub ou em um servidor pessoal). Isso rastreia as mudanças e permite sincronizar rapidamente as configurações entre dispositivos.

Sincronizar os Dados entre Dispositivos

Para um failover contínuo, ambos os dispositivos devem compartilhar dados em tempo real. O objetivo: o dispositivo de espera sempre sabe o último valor de glicose, histórico recente de entrega de insulina e status da bomba. Existem vários métodos, cada um com trade-offs:

  • Nightscout (baseado em nuvens): Ambos os dispositivos enviam para o mesmo site Nightscout. O backup pode obter as últimas horas de dados através da API Nightscout na inicialização e, em seguida, pesquisa periodicamente. Isso funciona bem, mas requer acesso à internet e introduz latência.
  • Corretor local MQTT (recomendado): Execute um servidor MQTT Mosquitto em um Framboesa Pi Zero ou em sua rede doméstica. Cada dispositivo OpenAPS publica tópicos (por exemplo, , ) e se inscreve nesses tópicos do outro dispositivo. O MQTT é rápido, leve e funciona offline.
  • Sistema de ficheiros partilhado (NFS/SMB): Montar uma partilha de rede onde ambos os dispositivos escrevem ficheiros de estado. Usar atômico escreve (escrever para um ficheiro temporário, depois renomear) para evitar leituras parciais. Este método pode ser mais lento e pode sofrer de problemas de bloqueio de ficheiros.
  • [[FLT: 0]] Replicação de base de dados (avançada): Configurar o InfluxDB em um servidor separado. Ambos os dispositivos gravam medições para os mesmos bancos de dados. O backup pode consultar o InfluxDB para obter os dados mais recentes. Isto oferece dados históricos robustos, mas adiciona complexidade.

Recomendação prática: Comece com sincronização Nightscout porque já faz parte da maioria das configurações do OpenAPS. Depois adicione MQTT para compartilhamento de dados locais de baixa latência. Teste ambos para garantir que o backup tenha dados com menos de 30 segundos de idade.

Implementação de Falha Automática

Monitorização do batimento cardíaco

O fracasso depende de um batimento cardíaco: cada dispositivo envia periodicamente um sinal "Estou vivo". Simples implementação:

  • Criar um ponto de avaliação HTTP leve em cada dispositivo (por exemplo, ]) que retorna uma data e um estado.
  • Em alternativa, use o MQTT com um tópico reservado: e . Cada plataforma publicará uma mensagem JSON a cada 15-30 segundos.
  • No dispositivo de backup, execute um script que verifica o batimento cardíaco do primário. Se três batimentos cardíacos consecutivos são perdidos (por exemplo, 90 segundos sem um sinal), o backup declara o morto primário.

Comutação automática

Quando o backup decide que o primário é inacessível, ele deve assumir o controle sem intervenção do usuário. Passos para um interruptor confiável:

  1. Claim control: Escreva uma bandeira para uma localização compartilhada (por exemplo, um tópico MQTT ou um arquivo na compartilhamento de rede) indicando que o backup está ativo. O primário, quando recuperar, irá ler esta bandeira e permanecer em standby.
  2. Assumir a comunicação da bomba: Se ambos os dispositivos partilharem uma bomba física (por exemplo, através de Bluetooth ou série), garantir que apenas um dispositivo tenha a ligação da bomba. Na comutação, o backup deverá libertar qualquer ligação da bomba anterior e estabelecer uma nova.
  3. Continua o loop:] O backup usa os dados sincronizados mais recentes para reiniciar o loop OpenAPS. Ele deve registrar o evento no Nightscout como uma nota de tratamento (por exemplo, "Falha: backup agora ativo").
  4. Enviar alerta: Use Pushover, email, SMS ou um buzzer local para notificar o usuário de que ocorreu failover.

Prevenir o Bater

O bater de raspão ocorre quando o controle primário recupera e imediatamente retoma, causando oscilações. Use um temporizador de tempo morto: uma vez que o backup assume o controle, ele não deve renunciar ao controle por pelo menos 5-10 minutos, mesmo que o batimento cardíaco primário reaparece. Depois desse período, o backup pode se desmotivar se o primário estiver estável. Uma abordagem melhor: requer confirmação manual para voltar. O usuário pode então optar por restaurar o primário após verificar que ele está totalmente saudável.

Sobrescrever Manual

Apesar da automação, sempre fornecer um sobreposição manual. Implemente uma interface web simples (por exemplo, usando Node-Red ou uma aplicação web Flask) com um botão para designar qual dispositivo está ativo. Além disso, um interruptor físico que corta a energia de um dispositivo pode servir como último recurso. Documente o procedimento manual com clareza e teste-o regularmente.

Teste e Validação

Seu sistema de failover é tão bom quanto seus testes. Crie um cronograma para simular falhas a cada 2-4 semanas. Use uma lista de verificação:

  • Simulação de falha de hardware: Remova a energia do primário, então puxe seu cartão SD enquanto estiver ligado (simular corrupção de cartão). Verifique se o backup ativa dentro do tempo de espera (normalmente 60-90 segundos).
  • Simulação de falha de rede: Desligue o cabo de rede do primário. Confirme que o backup ainda pode acessar Nightscout e se comunicar com a bomba.
  • Teste de sincronização de dados: Intencionalmente, parar o fluxo de dados para o backup (por exemplo, pausando sua assinatura MQTT). Reative-o e verifique se o backup alcança os últimos 15 minutos de dados antes de assumir o controle.
  • Recupera teste: Traga o primário de volta on-line. Certifique-se de que ele reconhece o backup está ativo e permanece em modo de espera sem ativar outro interruptor.
  • Teste de alerta: Verifique se o alerta de failover chega até você (notificação de impulso, e-mail ou qualquer método que você use) dentro de 30 segundos após o switch.

Grave cada teste em um log ou em notas Nightscout. Se você tiver um cuidador, envolva-os nos testes para que eles saibam o que esperar.

Manutenção e Atualizações

Manter ambos os dispositivos na mesma versão de software é essencial para o comportamento previsível. Siga estas práticas:

  • Atualizações estáticas: Sempre atualizar um dispositivo primeiro, deixando o outro em execução. Após 24-48 horas de operação estável, atualizar o segundo. Se surgir um problema, você pode reverter o dispositivo atualizado sem interromper a terapia.
  • Use uma placa de encenação:] Mantenha uma terceira placa de “espalhamento” que você atualiza primeiro. Após duas semanas de estabilidade, aplique alterações em ambas as plataformas de produção.
  • Automatize atualizações com cautela: Um trabalho de cron pode verificar se novos lançamentos OpenAPS são feitos todas as noites, mas só baixar e aplicar se uma bandeira aprovada por humanos estiver configurada. Nunca auto-atualize um sistema crítico.
  • Registros de monitores: Configurar rotação de logs e encaminhar erros críticos para o seu telefone através de um diário systemd ou rsyslog. Ferramentas como podem enviar resumos diários.

Garantir a sua configuração multidispositivos

Mais dispositivos significam mais superfícies de ataque. Aplicar estas medidas de segurança:

  • Autenticação forte: Use senhas únicas e longas para SSH e interfaces web. Desativar a autenticação de senha inteiramente e confiar em chaves SSH com senhas.
  • Segmentação de rede: Coloque ambas as plataformas em um VLAN isolado se o seu roteador suporta. Eles só devem ter acesso ao Nightscout, servidores de atualização e ao corretor MQTT. Bloqueie todas as conexões de entrada da internet.
  • Encriptação: Enforce HTTPS para toda a comunicação Nightscout. Use MQTT sobre TLS (porto 8883). Gere certificados auto-assinados ou use Vamos criptografar se o seu corretor estiver exposto (não recomendado).
  • Segurança física: Montar as placas em uma caixa ou gabinete acolchoado. Certifique-se de que cartões SD ou SSDs não são facilmente deslocados. Use o alívio de tensão para cabos de energia e rede.
  • Auditorias regulares: Reveja portas abertas com ou .Desativar quaisquer serviços que não sejam estritamente necessários (por exemplo, Bluetooth, Wi-Fi se usar Ethernet).

Recursos e Apoio Comunitários

Você não está construindo isso sozinho. A comunidade OpenAPS é ativa, conhecedora e acolhedora.

Ao pedir ajuda, forneça seus detalhes de hardware, versões de software, método failover e quaisquer registros de erros. Os valores da comunidade são perguntas detalhadas e respeitosas.

Conclusão

Executar o OpenAPS com vários dispositivos transforma um bom sistema de entrega de insulina automatizado em um hardware verdadeiramente robusto. Ao selecionar hardware compatível, sincronizar dados de forma eficaz, implementar failover baseado em batimentos cardíacos e testar rigorosamente, você cria uma configuração que pode resistir a falhas de hardware, falhas de rede e erros humanos. O esforço inicial – placas de escolha, escrita de scripts failover e testes completamente – compensa com controle contínuo e confiável dia e noite.

Comece pequeno: obtenha duas placas idênticas, configure a sincronização Nightscout e crie um script simples de batimentos cardíacos que lhe envie uma notificação quando o primário ficar offline. Depois adicione gradualmente o failover automático. A comunidade OpenAPS abriu caminho com anos de experiência no mundo real. Agora você pode construir sobre os ombros deles para um sistema mais seguro e resistente que você pode confiar em sua vida.