Centro de Distribuição Automatizado — Protótipo IoT em Escala Reduzida

Do clique no navegador à esteira em movimento: pedido pelo dashboard, MQTT, ESP32 e Arduino, com estoque, sensores e métricas em tempo real.

Firmware C++ (Arduino Uno e ESP32) · MQTT/IoT · Dashboard em tempo real com vista 3D · Testável sem hardware

🌐 Conheça o projeto pela página de apresentação →

Uma visão geral visual, com a bancada em 3D e o caminho de um pedido contado pela rolagem. Código da página em dataflow-inventory-site.

---

SENAI São Caetano do Sul — Boa Vista
Engenharia de Controle e Automação

Escolha seu caminho

Quero...	Vá para	Precisa de hardware?
🌐 Conhecer o projeto em poucos minutos	Página de apresentação	Não
⚡ Ver funcionando em 30 segundos	Quick Start — Simulador	Não
🔧 Montar a bancada completa	Materiais, Como Rodar e o Guia de implantação	Sim
📈 Ver métricas e dashboards de performance	Observabilidade	Não exige a bancada (precisa de Docker e do servidor Node; sem a bancada, parte dos painéis fica vazia)
🤝 Contribuir	Contribuindo e o Guia de Contribuição	Não

Por que este projeto é interessante

Tema	O que você encontra	Onde está detalhado
🧠 C++ embarcado	Máquina de estados finita (5 estados) no Arduino Uno, protocolo serial em JSON e gateway ESP32 com LWT e reconexão Wi-Fi não bloqueante	Funcionamento · docs/ARCHITECTURE.md
🏭 Automação e intralogística	4 esteiras, 6 sensores infravermelhos, controle de estoque e timeout de entrega	Visão Geral · Funcionamento
📡 IoT e MQTT	Mosquitto local ou HiveMQ Cloud, tópicos dataflow/*, mensagens retained e LWT	Tópicos MQTT
⏱️ Tempo real	Servidor Node.js com Socket.IO, dashboard responsivo e vista 3D da bancada	Destaques Técnicos
📈 Observabilidade	Prometheus + Grafana com 17 métricas dfi_* e três dashboards	observability/README.md
✅ Qualidade	Testes unitários, testes E2E com Playwright e CI que compila os sketches	Estrutura do Repositório

Status de validação: o broker Mosquitto local foi validado em bancada; o HiveMQ Cloud está parcialmente validado; as esteiras A, B e C acionam e entregam (03/10; a C usa provisoriamente o módulo IRF520 da A); o firmware do Uno v3.0 (supervisão por marcos, no padrão de processos de automação) passou nos testes automatizados, mas ainda não foi validado em bancada (Semana 8: roteiro). Veja Próximos Passos para o estado atual de cada item.

Sumário

• Escolha seu caminho
• Por que este projeto é interessante
• Sobre
• Quick Start — Simulador
• Visão Geral
• Destaques Técnicos
• Arquitetura
• Estrutura do Repositório
• Funcionamento
• Diagrama Elétrico
• Materiais
• Como Rodar
• Próximos Passos
• Equipe
• Contribuindo
• Licença
• Referências

---

Sobre

O Data Flow Inventory é um protótipo funcional que simula um centro de distribuição automatizado em escala reduzida, controlado por microcontroladores e monitorado remotamente via dashboard web em tempo real.

O projeto se insere no setor de Automação Industrial da Logística, com foco em:

• 📦 Intralogística e centros de distribuição
• 🛒 E-commerce e gestão de estoque
• 🔄 Sistemas de recebimento automático

📄 Para o projeto completo, consulte Projeto de pesquisa - Final.docx na pasta docs/artigo/.

⚡ Quick Start — Simulador

Experimente o dashboard em menos de 30 segundos, sem nenhum hardware:

git clone https://github.com/MatheusNespolo/DataFlowInventory.git
cd DataFlowInventory/simulator
npm install && npm start

Abra http://localhost:3000 — pronto! O simulador reproduz o ciclo completo (pedido → verificação de estoque → acionamento da esteira → entrega) emitindo os mesmos eventos Socket.IO que o servidor real, então o frontend funciona sem nenhuma alteração.

💡 Para o modo completo com hardware (Arduino + ESP32 + MQTT), veja a seção Como Rodar abaixo.

Visão Geral

O sistema é composto por:

Componente	Função
🏗️ 4 esteiras transportadoras	1 principal (liga direto na fonte) + 3 secundárias com driver IRF520
🔍 6 sensores infravermelhos	TCRT5000 — 3 no topo + 3 nas junções
🎡 Roda giratória (melhoria)	3 compartimentos para separação de peças
🎛️ Arduino Uno	Controlador principal (FSM de 5 estados)
📡 ESP32	Gateway MQTT (bridge Serial ↔ Wi-Fi)
🖥️ Dashboard web	HTML/CSS/JS + Socket.IO em tempo real
⚙️ Servidor Node.js	Ponte entre MQTT e WebSocket
☁️ Broker MQTT	Mosquitto local (validado em bancada) / HiveMQ Cloud (parcialmente validado — TLS/8883 OK, E2E remoto pendente)

A roda giratória é um aprimoramento futuro do projeto, uma sugestão de melhoria. Atualmente existem menções ao controle no motor de passo no código, mas ele está comentado para ajustes durante o desenvolvimento até a integração final.

Destaques Técnicos

Capacidade	Detalhe
🏭 Indicadores IEC-60073	Painel anunciador com LEDs de status: verde (ok) / amarelo (atenção) / vermelho (fault), seguindo a norma de cores para sinais industriais.
🔮 Diagrama 3D	Visualização panorâmica da bancada com three.js e depth CSS, com parallax controller — SVG estático como fallback.
🎨 Tipografia IBM Plex	Sans (UI) e Mono (readouts de estado), reforçando a identidade visual industrial.
📊 Alertas de estoque graduados	Aviso (=3 peças), alerta (=2), crítico (≤1) — com badges, cores e anunciador luminoso dedicados.
🔐 Segurança	Helmet + CSP, CORS restrito por ALLOWED_ORIGIN, rate limit por socket (COMANDO_INTERVALO_MS), validação de entrada de comandos.
📡 LWT e Health Check	Last Will and Testament para monitoramento de presença; endpoint /api/status retorna HTTP 503 quando o broker está indisponível.
🔄 Resiliência	Reconexão Wi-Fi não-bloqueante, shutdown gracioso (SIGINT/SIGTERM), estoque e gateway como retained.
📱 Responsivo	Layout adaptável testado em 1920×1080, 1366×768 e ≤720px.
🗺️ Hash routing	Vistas #/ (painel principal) e #/status (histórico/equipamentos) com navegação por hash.
🖥️ Simulador offline	FSM completa em JavaScript emitindo os mesmos eventos Socket.IO do servidor real — teste sem hardware.

Arquitetura

Modo Simulador (sem hardware)

Para testar o dashboard sem nenhum componente físico conectado, o projeto inclui um simulador (simulator/) que reproduz o ciclo da máquina de estados em JavaScript — pedido → verificação de estoque → acionamento da esteira → entrega — emitindo os mesmos eventos Socket.IO que o servidor real (server/), servindo o frontend/ sem nenhuma alteração.

Diferente do modo real, os tempos de verificação/acionamento/entrega são temporizadores fixos (não dependem de sensores físicos) e não há MQTT nem broker envolvidos. Cobre o fluxo de sucesso e a rejeição por falta de estoque; cenários de timeout do firmware real ainda não são simulados, rejeição por estoque zero e FSM ocupada já são cobertos.

🖥️ Detalhes de implementação em docs/ARCHITECTURE.md.

┌──────────────┐   Serial   ┌──────────┐   MQTT    ┌────────────────┐   WebSocket  ┌─────────────┐
│ Arduino Uno  │ ────────── │  ESP32   │ ────────  │ Broker MQTT    │ ──────────── │  Dashboard  │
│  (FSM + I/O) │ ←────────  │(Gateway) │           │ Mosquitto/     │              │  (Frontend) │
│              │            │          │           │ HiveMQ Cloud   │              │             │
└──────────────┘            └──────────┘           └───────┬────────┘              └─────────────┘
                                                           │ MQTT                       ↑
                                                           │                            │
                                                   ┌───────┴────────┐                   │
                                                   │ Node.js Server │ ──────────────────┘
                                                   │ (Express+WS)   │
                                                   └────────────────┘

Fluxo de dados:

• Publicação (Arduino → Dashboard): Arduino detecta evento → Serial.print(JSON) → ESP32 → MQTT Broker → Node.js → Socket.IO → Dashboard
• Controle Remoto (Dashboard → Arduino): Botão clicado → Socket.IO → Node.js → MQTT Broker → ESP32 → Serial → Arduino executa comando

Estrutura do Repositório

DataFlowInventory/
├── arduino/
│   └── data_flow_inventory/
│       ├── data_flow_inventory.ino        # Sketch do Arduino (setup/loop)
│       ├── config.h                       # Pinos, prazos por esteira e constantes
│       └── src/
│           ├── logica/                    # FSM, supervisor de entrega, protocolo, filtro, telas (testável em g++)
│           └── hw/                        # Motores, sensores, LCD, comunicação e diagnóstico
│
├── esp32/
│   ├── gateway_mqtt/
│   │   ├── gateway_mqtt.ino               # Código ESP32 (Serial ↔ MQTT)
│   │   └── secrets.h.example              # Modelo das credenciais (secrets.h não versionado)
│   └── test_mqtt_cloud/                   # Sketch de teste de conexão com o HiveMQ Cloud
│
├── server/
│   ├── package.json                       # Dependências Node.js
│   ├── server.js                          # Express + Socket.IO + MQTT
│   ├── metrics.js                         # Métricas Prometheus (GET /metrics)
│   ├── metrics-correlacao.js              # Correlação comando → confirmação
│   └── .env                               # Configurações (não versionado)
│
├── simulator/
│   ├── package.json                       # Dependências Node.js
│   └── server.js                          # Simulador offline (FSM em JS, mesmo frontend/)
│
├── frontend/
│   ├── index.html                         # Dashboard principal
│   ├── css/
│   │   └── style.css                      # Estilos (dark theme)
│   ├── js/
│   │   ├── app.js                         # Lógica WebSocket + UI
│   │   └── arquitetura-*.js, *3d.js       # Vista de arquitetura e ambiente 3D
│   └── vendor/                            # three.js e controles (terceiros)
│
├── observability/                         # Provisionamento do Prometheus e do Grafana
├── docker-compose.yml                     # Stack de observabilidade (Prometheus + Grafana)
├── scripts/                               # setup, validate-env, precommit-checks, observability-smoke
├── .github/workflows/                     # CI (lint, segurança, testes, compilação dos sketches)
│
├── test/
│   ├── esteira_peca_a/                    # Códigos de teste incrementais (1 esteira)
│   ├── esteira_peca_b/                    # Teste 5: duas esteiras (A+B) com FSM completa
│   ├── mqtt_probe/                        # Sonda MQTT (escuta dataflow/# com timestamp)
│   ├── server_metrics/                    # Testes das métricas e da infra de observabilidade (sem Docker)
│   ├── firmware_uno/                      # Testes da lógica do Uno (g++ + Makefile, tempo simulado)
│   ├── frontend/                          # Testes unitários do frontend (node --test)
│   └── frontend_smoke/                    # Testes E2E com Playwright (portas 3100–3102)
│
├── docs/
│   ├── ARCHITECTURE.md                    # Referência técnica única (arquitetura, tópicos, mensagens, observabilidade)
│   ├── DEPLOYMENT.md                      # Implantação do zero
│   ├── CI-CD.md, CHANGELOG.md             # Pipelines e histórico de mudanças
│   ├── INTEGRATION_GUIDE.md               # Integração Beckhoff CX9240
│   ├── broker_local_mosquitto.md          # Teste local com Mosquitto (sem nuvem)
│   ├── FRONTEND.md                        # Guia do dashboard e da estrutura do frontend
│   ├── DIVULGACAO.md                      # Material de divulgação do projeto
│   ├── cards_comments/                    # Comentários dos cards de planejamento
│   ├── grafana/                           # Dashboards versionados
│   ├── artigo/
│   │   └── Projeto de pesquisa - Final.docx   # Documentação acadêmica
│   ├── fluxogramas/                       # Diagramas (FSM, ciclo do pedido, elétrico)
│   └── testes/
│       ├── plano_de_testes.md             # Plano de testes de integração (Serial → E2E)
│       ├── roteiros/                      # Roteiros semanais de execução dos testes
│       └── validações/                    # Checklists e automação de validação de infra
│           ├── README.md                  # Guia dos artefatos de validação
│           ├── checklist_pre_teste_rede_infra.md
│           └── validar_infra.ps1          # Script PowerShell de validação (broker/firewall/portas)
│
├── start_services.bat                     # Sobe broker + probe + server em sequência
├── .gitignore
└── README.md

Funcionamento

Máquina de Estados (Arduino)

O Arduino opera com 5 estados:

#	Estado	Descrição
1	AGUARDANDO_PEDIDO	Sistema em repouso, aguarda comandos remotos (botões físicos desabilitados)
2	VERIFICANDO_ESTOQUE	Verifica sensor do topo + contador interno
3	ACIONANDO_ESTEIRA	Liga o motor da esteira escolhida (kick-start e depois o PWM de regime)
4	ENTREGANDO_PECA	Supervisão por marcos: topo livre em 3 s, junção em 12,5 s (débito na confirmação) e 3 s de saída
5	ERRO	Motores desligados; LCD e dashboard mostram onde falhou (ver docs/ARCHITECTURE.md §3); aguarda reset

📊 Diagramas completos (máquina de estados, fluxo operacional e sequência de comunicação) em docs/ARCHITECTURE.md.

🧪 Testes de integração da cadeia de comunicação (Serial → Broker → Dashboard) em docs/testes/plano_de_testes.md.

Tópicos MQTT

Tópico	Direção	Descrição
dataflow/status	Arduino → Cloud	Estado da FSM e uptime
dataflow/estoque	Arduino → Cloud	Quantidade de peças
dataflow/eventos	Arduino → Cloud	Pedidos, entregas, erros
dataflow/sensores	Arduino → Cloud	Leituras dos sensores IR
dataflow/esteiras	Arduino → Cloud	Status das esteiras
dataflow/comandos/sub	Cloud → ESP32	Comandos do front-end
dataflow/comandos/pub	ESP32 → Cloud	Confirmação de comandos

Diagrama Elétrico

📐 Diagrama elétrico completo do protótipo:

• 🖼️ Visualização: docs/fluxogramas/Diagrama elétrico.png (GitHub renderiza a imagem)
• 📝 Editável: docs/fluxogramas/Diagrama elétrico.pptx (PowerPoint — baixe para editar)
• Conteúdo: Esquema unifilar com pinagem completa, alimentação 12V/5V, proteções (fusível, diodos), e integração com Arduino Uno, ESP32, 3× IRF520, 6× TCRT5000, LCD I²C e motor de passo 28BYJ-48
• Publicação: 23/09/2026 — Gap resolvido ✅

Materiais

Configuração Principal (Recomendada)

Componente	Quantidade	Especificação
Esteira transportadora	3	BR Eletrônica 35cm, motor DC 3–6V
Esteira transportadora (já com fonte e motor integrados)	1	BR Eletrônica 35cm, motor DC 3–6V # não necessita driver
Arduino Uno	1	Controlador principal
ESP32 Dev Module	1	Gateway MQTT
Driver IRF520	3	Controle de 1 motor cada
Sensor IR TCRT5000	6	Detecção de peças
Display LCD 16x2	1	Com módulo I2C (endereço 0x27)
Botões	4	3 solicitação + 1 reset (opcionais)
Fonte 12V DC	1	Alimentação geral

Alternativas Técnicas (Viáveis)

Nota: As configurações abaixo foram validadas tecnicamente e podem substituir a configuração principal conforme necessidade de custo ou disponibilidade de componentes.

Opção A — Módulos IRF520 ao invés de L298N

Aspecto	L298N	IRF520
Controle de direção	Frente e ré (H-bridge)	Apenas um sentido (MOSFET)
Motores por módulo	2	1
Quantidade necessária	2	3 (1 esteira principal liga direto na fonte, sem driver)
PWM (velocidade)	✅ Sim	✅ Sim
Corrente máxima	~2A por canal	~5A (com dissipador)
Tensão	5–35V	Até 24V
Custo	Mais alto	Mais baixo

⚠️ Atenção: Os motores das esteiras neste projeto operam em apenas um sentido, portanto a perda de reversão do IRF520 não impacta o funcionamento. É necessário 1 módulo IRF520 por esteira secundária (total de 3). A esteira principal é ligada diretamente na fonte 12 V e não utiliza driver.

Opção B — Arduino Mega ao invés de Uno (com botões físicos)

Aspecto	Arduino Mega	Arduino Uno
Pinos digitais	54	20 (0–13 + A0–A5)
Pinos PWM	15	6 (3, 5, 6, 9, 10, 11)
Memória Flash	256 KB	32 KB
Memória RAM	8 KB	2 KB
Serial hardware	4 portas	1 porta (pins 0/1)

Pinos necessários com Uno (sem botões físicos):

Componente	Pinos	Alocação no Uno
3 motores (IRF520)	3 PWM	9, 10, 11
6 sensores TCRT5000	6 digitais	A0, A1, A2, A3, 2, 4
LCD I2C	2 (SDA/SCL)	A4 (SDA), A5 (SCL)
Serial ESP32	2 (RX/TX)	0 (RX), 1 (TX)
Total	14	Uno tem 20 disponíveis ✅

⚠️ Atenções com Arduino Uno:

• Pins 0 e 1 são compartilhados com a porta USB de programação. Desconecte o ESP32 durante upload de código.
• Memória RAM de 2KB é suficiente para o código atual (usa StaticJsonDocument de tamanho fixo), mas deixa menos margem para expansões futuras.
• O uso de botões físicos requer 4 pinos adicionais, o que tornaria o Uno inadequado. Nesta configuração, todo o controle de peças deve ser feito via dashboard web.

Resumo das Combinações Possíveis

Configuração	Controlador	Driver	Pinos Usados	Custo
Principal (econômica)	Uno	3× IRF520	14 (sem botões)	Baixo
Alternativa B (misturada)	Mega 2560	3× IRF520	17 + 4 botões	Médio-Baixo
Alternativa C (limitada)	Uno	2× L298N	10 + 4 botões	Botões não cabem ❌

A Alternativa A (Uno + 3× IRF520) é a opção de menor custo viável para este projeto, desde que se aceite o controle exclusivamente via dashboard web (sem botões físicos).

Como Rodar

Setup Automatizado (Recomendado)

Você pode instalar as dependências e criar os arquivos de configuração necessários automaticamente:

# Windows (PowerShell):
.\scripts\setup.ps1

# Linux / macOS / Git Bash:
bash scripts/setup.sh

Caminho rápido — Simulador (sem hardware)

Para ver o dashboard funcionando sem montar nenhum componente físico:

cd simulator
npm install
npm start

Acessar http://localhost:3000 no navegador. ⚠️ O simulador sobe na mesma porta 3000 usada pelo servidor real (server/) — não rode os dois ao mesmo tempo sem alterar a variável PORT de um deles.

Sistema Completo (com hardware)

Pré-requisitos

• Arduino IDE (com suporte a Arduino Uno e ESP32)
• Node.js v22+
• Mosquitto rodando localmente (porta 1883) — caminho padrão validado em bancada. Veja docs/broker_local_mosquitto.md
• Conexão Wi-Fi 2.4 GHz para o ESP32
• Conta gratuita no HiveMQ Cloud — apenas para o Teste 6 de migração para broker remoto (TLS/8883)

1. Configurar o Arduino

1. Abrir arduino/data_flow_inventory/data_flow_inventory.ino
2. Selecionar placa: Arduino Uno R3
3. Fazer upload

2. Configurar o ESP32

1. Na pasta esp32/gateway_mqtt/, criar o arquivo de segredos a partir do exemplo (arquivo não versionado, ignorado pelo .gitignore):

   copy secrets.h.example secrets.h   # Windows
   cp   secrets.h.example secrets.h   # Linux/Mac

2. Preencher em secrets.h as credenciais de Wi-Fi (SECRET_WIFI_*) e do broker (SECRET_MQTT_*_LOCAL ou SECRET_MQTT_*_CLOUD). As credenciais não ficam mais no .ino.
3. Abrir esp32/gateway_mqtt/gateway_mqtt.ino e definir o modo de conexão pela flag USE_TLS:
   • false → broker local Mosquitto (porta 1883) — ideal para testes sem nuvem. Veja docs/broker_local_mosquitto.md
   • true → broker nuvem HiveMQ Cloud (porta 8883, TLS)
4. Selecionar placa: ESP32 Dev Module
5. Fazer upload

📘 Para um passo a passo completo (hardware, firmware, broker, servidor e validação), veja docs/DEPLOYMENT.md.

3. Rodar o Servidor

cd server
npm install
# Editar .env conforme o broker escolhido:
#   Local (padrão):  MQTT_BROKER_URL=mqtt://127.0.0.1  | MQTT_PORT=1883
#   Nuvem (HiveMQ):  MQTT_BROKER_URL=mqtts://<cluster>.s1.eu.hivemq.com | MQTT_PORT=8883 + credenciais
npm start

4. Acessar o Dashboard

Abrir http://localhost:3000 no navegador.

Próximos Passos

• 🚀 CI/CD Automatizado: workflows de linting, secret detection e compilação de firmware via GitHub Actions (ver docs/CI-CD.md).
• 🎡 Roda de Separação (3 compartimentos): motor de passo 28BYJ-48 + ULN2003 para separação automática das peças A/B/C ao fim da esteira principal (ver docs/INTEGRATION_GUIDE.md).
• 🏭 Integração Beckhoff CX9240: persistência do histórico e estoque em banco de dados relacional (lado do simulador implementado; validação com PC industrial em bancada própria).
• ☁️ Broker Remoto (HiveMQ Cloud): validação E2E via internet/TLS (porta 8883) com credenciais em nuvem (parcialmente validado). Ver docs/testes/plano_de_testes.md (Teste 6).
• 🧪 Validação de infraestrutura: scripts em scripts/ e docs/testes/validações/validar_infra.ps1 automatizam a checagem de broker, firewall e serviços antes de cada bancada.
• 📈 Telemetria histórica (Prometheus + Grafana): GET /metrics no servidor e três dashboards (Visão Geral, Performance e Confiabilidade) em docs/grafana/, com stack Docker opcional em docker-compose.yml. Telemetria concluída em 01/10/2026: código, testes automatizados e validação do stack (smoke test e conferência dos painéis). Ver observability/README.md.
• 📘 Guia de implantação: passo a passo para subir o sistema do zero em docs/DEPLOYMENT.md (versão inicial, ainda não validada em máquina limpa).
• 🔧 Diagnóstico IRF520 (esteiras B/C) — resolvido em 03/10: a falha era elétrica (módulo IRF520 e motor da C, trocados; o firmware anterior estava correto). A C usa provisoriamente o módulo da A. Ver docs/testes/roteiros/semana_07_28_setembro-3_outubro.md (seção 4.2.1).
• 🧪 Semana 8 (05–09/10): validação em bancada do firmware v3.0 (esteira A, depois A+B e A+B+C, com calibração) e integração do separador. Roteiro em docs/testes/roteiros/semana_08_05-09_outubro.md, com aprovação a cada bloco.

Equipe

Nome
Henrique Moni de Souza
Matheus Nespolo Silva
Murilo Tolardo da Silva
Vitor Marcolongo Silva

Orientação: Professora Tatiani de Paula Pinotti Sabaris Meglhioratti e Professor Jorge Antonio Giles Ferrer

Contribuindo

Contribuições são bem-vindas! Antes de abrir um PR, leia o Guia de Contribuição — ele cobre as regras de segurança (segredos em secrets.h / .env, nunca no código), convenções de commit e as validações obrigatórias. O histórico de mudanças fica em docs/CHANGELOG.md.

⭐ Se este projeto te ajudou, deixe uma estrela no GitHub! Sua avaliação nos motiva bastante! 🙏

Licença

MIT License — Veja o arquivo LICENSE para mais detalhes.

Referências

• AFFIA; AAMER (2022) — IoT-based smart warehouse infrastructure
• ALKHATEEB et al. (2022) — Smart Warehouse Management System
• TUBIS; ROHMAN (2023) — Intelligent Warehouse in Industry 4.0
• HUSSEIN; MUHUDIN (2024) — IoT Based Warehouse Management System
• Ver docs/artigo/Projeto de pesquisa - Final.docx para referências completas

---

"A forma mais fácil de estagnar é considerar que não há nada a aprender."