Argussalas técnicas

A TicTrens opera trens em São Paulo, e ao longo da via existem salas técnicas que recebem manutenção. O problema é de segurança operacional: a empresa não tinha como acompanhar ativamente quem estava dentro dessas salas, nem confirmar que quem entrou saiu.

Isso importa porque a sala é um espaço de risco perto de via ativa. Um técnico que entra e não é registrado como tendo saído precisa ser detectado na hora, não no fim do turno.

Como o Argus resolve

São duas camadas que se conferem mutuamente.

Declaração. Antes de entrar, o técnico se identifica no dispositivo. É multifator, e as duas etapas existem por motivos diferentes: ele aproxima um cartão RFID, que identifica quem é sem contato e sem digitar nada, e depois digita uma senha num teclado matricial. O cartão sozinho vale enquanto ninguém perder ou emprestar ele, e é por isso que ele não decide sozinho. Isso registra a intenção: quem, onde, quando.

Verificação. Uma câmera montada acima da porta conta quantas pessoas entram e quantas saem, e a contagem vai para o banco junto com os eventos de autenticação. Isso registra o fato.

A operação planejada é a terceira referência. Quando as três batem, está tudo certo. Quando não batem (entrou mais gente do que se identificou, ou saiu menos gente do que entrou), há algo para alguém olhar.

Por que não só a câmera

Contagem por visão computacional sozinha diz quantas pessoas, não quais. Autenticação sozinha diz quem se identificou, não quem passou pela porta. Juntas, uma cobre a lacuna da outra, e é isso que torna o sistema utilizável em operação.

O ESP32 e o retorno para quem está na porta

O ESP32 coordena o lado embarcado: leitura do cartão, teclado, display LCD e o retorno para o técnico por LED RGB e buzzer. Quem está do lado de fora de uma sala perto de via ativa precisa saber em um segundo se pode entrar, sem parar para ler tela.

O log é o produto

Cada tentativa vira registro: quem, quando, e se passou ou não. Os eventos saem do dispositivo por MQTT e chegam num dashboard, e é ali que o sistema passa de controle de acesso a ferramenta de operação. Dá para ver padrão de uso, tentativa negada se repetindo, e conferir o que aconteceu contra o que estava planejado.

O MQTT não foi a primeira escolha. A versão inicial falava HTTP, e a gente trocou porque o dispositivo publica evento curto e esporádico para um servidor que pode não estar ouvindo naquele instante, que é exatamente o caso em que abrir uma requisição inteira a cada evento não se paga.

Do protoboard à case

Começou em protoboard, para validar ligação e comportamento dos módulos com fio solto e fácil de trocar. Depois disso as conexões foram soldadas e tudo foi para uma case, que é o modelo 3D que está nesta página. A parte mecânica não é acabamento. É ela que decide se o técnico consegue usar o dispositivo de luva, se o leitor RFID fica na altura certa e se a fiação sobrevive a alguém fechando a porta.