HERMIA – Hermes Reply Intelligent Assistant Sistema Inteligente de Prevenção de Falhas Industriai...

1. 0 Camada de Introdução - Explicações

1.1. Justificativa do problema e descrição da solução proposta;

2. Camada de Percepção – Sensores e Coleta de Dados

2.1. Question: O que será monitorado e por que esses dados são importantes?

2.1.1. Answer: Monitoraremos XXXXX (temperatura, pressão, vibração, corrente elétrica, velocidade do motor, etc etc?) porque essas variáveis revelam os primeiros sinais de desgaste, superaquecimento ou falhas mecânicas em equipamentos industriais.

2.2. Question: Como serão coletados os dados?

2.2.1. Usaremos ESP32 com sensores simulados, integrados a um script de coleta via Wi-Fi.

2.3. Question: Com que frequência os dados serão coletados?

2.3.1. A frequência será definida conforme o tipo de variável monitorada. Por exemplo, temperatura pode ser coletada a cada 10 segundos, enquanto vibração exige leituras a cada 2 segundos.

2.4. Question: Onde os sensores estarão fisicamente posicionados?

2.4.1. Junto aos pontos críticos da máquina, como motores, válvulas e rolamentos — locais mais sensíveis ao superaquecimento, variações de pressão e vibração. ???

2.5. Question: Como garantimos a confiabilidade dos dados coletados?

2.5.1. Através de: Verificação de valores inconsistentes (ex: temperatura impossível), e validação automatizada por algoritmos que descartam valores fora de faixas aceitáveis antes de enviar ao banco de dados. Comparação com faixas aceitáveis e calibração periódica. Histórico de características dos dados no momento em que a máquina falhou.

3. Camada de Comunicação – Transmissão dos Dados

3.1. Question: Como os dados saem dos sensores e chegam até o sistema?

3.1.1. Os dados coletados pelos sensores conectados ao ESP32 são enviados via Wi-Fi usando o protocolo MQTT, que é leve e ideal para dispositivos IoT.

3.1.1.1. OBS O uso do protocolo MQTT permite uma arquitetura desacoplada, onde sensores e consumidores de dados podem operar independentemente, favorecendo escalabilidade e modularidade

3.2. Por que escolhemos esse protocolo de comunicação?

3.2.1. O MQTT é altamente eficiente para IoT: ele envia dados pequenos com baixo consumo de energia, é confiável mesmo com instabilidade na rede e permite comunicação em tempo real.

3.3. Como garantimos segurança na comunicação dos dados?

3.3.1. Utilizaremos autenticação básica com usuário e senha no broker MQTT local, garantindo que apenas dispositivos autorizados consigam publicar ou assinar tópicos. Essa abordagem é simples de implementar, segura para o escopo do projeto e suficiente para proteger o fluxo de dados em um ambiente de testes.”

3.3.1.1. Qual a maneira mais simples (e realista) de garantir segurança no MQTT no seu projeto? ✅ Opção mais simples e viável para vocês: Usuário e Senha no broker MQTT (por exemplo, no Mosquitto) Essa abordagem é: Simples de configurar (linha de comando ou config file) Boa o suficiente para protótipos e projetos acadêmicos Já garante autenticação básica Funciona sem precisar instalar certificado SSL ou usar tokens complexos 🧠 Como funciona? No Mosquitto, por exemplo: Você cria um arquivo com nome de usuário e senha (criptografada com mosquitto_passwd) Ativa no arquivo de configuração o uso de autenticação Pronto: apenas quem tem usuário/senha válidos pode publicar ou assinar tópicos

3.3.1.1.1. MELHORIAS FUTURAS: Para versões futuras da solução, será possível incluir criptografia TLS e autenticação baseada em certificados ou tokens JWT, garantindo segurança de nível industrial para ambientes em produção

3.4. O que acontece se a conexão falhar?

3.4.1. O ESP32 pode armazenar dados temporariamente e reenviá-los assim que a conexão for restabelecida (buffer local), evitando perdas.

3.5. A comunicação é unidirecional ou bidirecional?

3.5.1. Bidirecional. O ESP32 envia dados ao servidor (telemetria), mas também pode receber comandos remotamente (ex: reiniciar, mudar frequência de leitura).

3.6. Qual serviço na nuvem gerencia essa troca de mensagens?

3.6.1. Utilizaremos inicialmente um broker MQTT local, como o Mosquitto, para simulação e testes. Futuramente, a solução pode ser migrada para um serviço em nuvem como o AWS IoT Core, que possui camada gratuita e permite gerenciar conexões seguras com escalabilidade

4. Camada de Processamento – Análise e Armazenamento

4.1. Question:Onde os dados serão armazenados?

4.1.1. Optamos por utilizar o Oracle como banco relacional principal da solução, por já termos familiaridade com sua estrutura no ambiente acadêmico. A versão gratuita atende perfeitamente aos requisitos do protótipo e nos permite aplicar conceitos de modelagem relacional, normalização, e integridade de dados. Caso necessário, o sistema poderá ser migrado para PostgreSQL em ambiente de produção

4.1.1.1. Como funciona o fluxo completo: O ESP32 (ou script simulando sensor) publica mensagens no tópico MQTT → ex: fabrica/linha1/temperatura. Um cliente Python atua como assinante, recebe os dados em tempo real via MQTT. Esse cliente insere os dados diretamente num banco de dados, como: Oracle PostgreSQL MySQL Firebase etc. 🧠 O que você precisa: 1. Um broker MQTT (ex: test.mosquitto.org ou AWS IoT) 2. Um assinante Python que: Escuta os dados do MQTT Faz conexão com o banco de dados Oracle Executa um INSERT INTO a cada nova leitura ✅ Exemplo de como salvar em banco Oracle (via Python) Instale os pacotes necessários: bash Copiar Editar pip install paho-mqtt pip install cx_Oracle Código de exemplo: python Copiar Editar import paho.mqtt.client as mqtt import cx_Oracle # Conexão com o banco Oracle conn = cx_Oracle.connect("usuario/senha@localhost/XE") # Exemplo: scott/tiger@localhost/XE cursor = conn.cursor() # Função ao receber mensagem def on_message(client, userdata, message): valor = message.payload.decode() print(f"Recebido: {valor}") # Salvando no banco sql = "INSERT INTO sensores (tipo, valor, data_leitura) VALUES (:1, :2, SYSDATE)" cursor.execute(sql, ("temperatura", valor)) conn.commit() # MQTT broker = "test.mosquitto.org" topic = "fabrica/linha1/temperatura" client = mqtt.Client("LeitorBancoOracle") client.on_message = on_message client.connect(broker) client.subscribe(topic) print("Escutando MQTT e gravando no Oracle...") client.loop_forever() 🗃️ Estrutura da tabela no Oracle (exemplo): sql Copiar Editar CREATE TABLE sensores ( id NUMBER GENERATED ALWAYS AS IDENTITY, tipo VARCHAR2(50), valor VARCHAR2(50), data_leitura DATE ); ✅ Conclusão Sim, você consegue integrar MQTT com Oracle tranquilamente: MQTT traz os dados Python escuta e insere no banco Oracle armazena para análise futura ou dashboards

4.1.1.2. Quando faz sentido usar o Oracle no seu projeto? Se o foco for mostrar domínio técnico e trabalhar com um banco real; Se o grupo conseguir fazer a conexão do Python com o Oracle (é super possível); E se vocês quiserem evitar depender da nuvem para armazenamento, mas ainda assim usar uma solução forte.

4.2. Como os dados serão organizados?

4.2.1. Cada leitura terá campos como: timestamp, ID do sensor, tipo de sensor, valor lido, unidade de medida e status (normal/anômalo).

4.3. Quais técnicas de IA serão aplicadas? SUPER IMPORTANTE!!!!

4.3.1. Aplicaremos inicialmente: Prophet para análise de séries temporais; Isolation Forest para detecção de anomalias; Random Forest para classificação de padrões que precedem falhas. Todos os modelos serão desenvolvidos em Python, com bibliotecas como Scikit-learn, PyCaret e Pandas. Futuramente, o sistema poderá incorporar modelos supervisionados mais avançados, como SVM, ou aplicar aprendizado contínuo, adaptando-se a novos padrões operacionais

4.4. Onde o processamento será feito?

4.4.1. O processamento dos dados será feito localmente, por scripts Python conectados ao banco Oracle. Essa decisão reduz custos e aumenta a autonomia da equipe no desenvolvimento. Caso o sistema cresça, o pipeline poderá ser migrado para instâncias EC2 na AWS, com reaproveitamento da estrutura existente.

4.5. Como o sistema aprende a prever falhas?

4.5.1. O sistema é treinado com um conjunto de dados históricos simulados, contendo exemplos de comportamentos normais e anômalos. Com isso, ele identifica padrões sutis que precedem falhas, permitindo alertas preventivos com base em aprendizado supervisionado.

5. Camada de Aplicação – Visualização e Interface

5.1. Question: Como os dados serão apresentados para os usuários?

5.1.1. Através de dashboards interativos, com informações em tempo real e análises históricas. Haverá dois tipos de dashboards: Operacional (simples, para operadores): status atual das máquinas (normal, alerta ou falha). Gerencial (estratégico, para gestores): tendências, relatórios semanais, previsões de falha e recomendações. SERÁ que precisa de tudo isso? kkkk

5.2. Qual ferramenta será utilizada para construir os dashboards?:

5.2.1. Preferência inicial por Power BI Desktop (gratuito) para criar dashboards locais conectados ao banco de dados. ta certo isso? misere ?????

5.3. Como os dados dos dashboards serão atualizados?

5.3.1. Os dashboards estarão conectados ao banco de dados (PostgreSQL ou Firebase) e serão atualizados automaticamente a cada intervalo configurado (ex: a cada 1 minuto).

5.4. Quem poderá acessar os dashboards?

5.4.1. Em ambiente de protótipo: acesso local (computador de apresentação). Em ambiente real: via servidor web interno ou disponibilizado na nuvem para acesso remoto controlado. será que precisamos mesmo do ambiente real?

5.5. Como será a experiência do usuário (UX)?

5.5.1. Simples e intuitiva para operadores (ícones de cores, mensagens claras). Analítica e detalhada para gestores (gráficos de tendência, alertas categorizados, relatórios exportáveis). SRRÁAAAAA que é mesmo necessário?

5.6. Que tipo de insights será possível obter?

5.6.1. Histórico de falhas por equipamento Previsão de falha num intervalo de dias - com no mínimo de 7 dias de antecedência - isso é coerente? ou é pouco tempo? ou muito tempo? Sugestões de manutenção baseada em comportamento anômalo detectado Análise de máquinas mais críticas

6. Camada de Ação – Alertas e Recomendação Inteligente

6.1. Question: O que acontece quando o sistema detecta um comportamento anômalo?

6.1.1. Um alerta automático é gerado no dashboard. Um e-mail, SMS ou mensagem WhatsApp é enviado para o operador/gestor responsável. Uma recomendação de ação é exibida junto ao alerta, orientando sobre a melhor resposta imediata.

6.2. Quais tipos de ação serão sugeridos?

6.2.1. Reduzir a carga de trabalho da máquina Realizar inspeção física em componentes Agendar manutenção preventiva Desligar a máquina para evitar danos maiores

6.3. Como as ações serão priorizadas?

6.3.1. Classificação automática de criticidade: Isento de risco: apenas monitoramento Baixo risco: agendar a manutenção em uma semana Médio risco: agendar manutenção em 24h. Alto risco: ação imediata recomendada (interromper máquina).

6.4. Haverá rastreamento de ações tomadas?

6.4.1. O sistema poderá registrar no banco de dados o timestamp do alerta, a ação recomendada e, posteriormente, a ação tomada (inserida manualmente ou automaticamente).

6.5. As ações serão apenas manuais ou haverá automação?

6.5.1. Inicialmente, a resposta às ações será manual (operador age conforme orientação). Em uma evolução futura, é possível integrar com PLCs (controladores lógicos programáveis) para resposta automática (por exemplo: desligar a máquina automaticamente em caso de falha crítica). - questão de proteção