Uma prova de conceito de IIoT deve responder a uma pergunta de negócio com dados reais da planta, em um prazo curto e fixo, e 30 dias são suficientes se você mantiver o escopo enxuto. Neste guia você vai encontrar um plano semana a semana, as métricas de sucesso a combinar antes de começar, uma stack leve com um gateway, um broker MQTT gerenciado e um dashboard, e um simulador funcional para construir o pipeline de dados antes mesmo de o hardware chegar.
Por que a maioria dos pilotos de IIoT empaca
Pilotos de IoT industrial raramente fracassam porque a tecnologia não funciona. Eles empacam porque o escopo cresce até "conectar a linha inteira", porque ninguém combinou o que é sucesso ou porque o piloto depende de uma infraestrutura que leva meses para ser aprovada. O resultado é o famoso purgatório dos pilotos: uma demo que impressiona uma vez e nunca mais é usada.
Uma boa prova de conceito é o oposto. Ela é pequena o bastante para ser concluída, importante o bastante para que alguém no chão de fábrica, de uma metalúrgica em Joinville a um frigorífico no interior, queira o resultado e construída sobre componentes que podem escalar sem reescrita caso ela dê certo.
Passo 1: escolha um escopo estreito e valioso
Escolha uma pergunta que uma pessoa específica precisa ver respondida. Bons exemplos:
- "Por que a CNC gargalo da célula 3 para, e por quanto tempo?"
- "O compressor fica ligado quando a planta está parada à noite?"
- "Com que frequência o forno 2 sai da sua faixa de temperatura?"
Depois, limite o escopo de propósito:
- Uma a três máquinas, de preferência do mesmo tipo.
- Três a dez sinais, como estado, contagem de peças, corrente e um alarme.
- Somente leitura. Nada de escrever em CLPs na prova de conceito.
- Um dashboard, usado por pessoas com nome e sobrenome.
Se a máquina-alvo não tiver interface de rede, planeje sensores adicionais. Nosso guia de retrofit de máquinas legadas para IoT aborda alicates de corrente e contadores de peças.
Passo 2: combine as métricas de sucesso antes do dia 1
Registre as métricas por escrito e peça ao gerente da planta para assiná-las. Misture medidas técnicas e de negócio.
| Métrica | Meta de exemplo | Como medir |
|---|---|---|
| Completude dos dados | Dados presentes em pelo menos 98% dos minutos de produção | Lacunas na série temporal |
| Latência | Estado da máquina visível no dashboard em até 5 segundos | Comparar com um cronômetro junto à máquina |
| Precisão | Eventos de parada batem com o registro do operador | Comparação lado a lado por uma semana |
| Adoção | O supervisor consulta o dashboard diariamente | Perguntar, ou verificar o acesso ao dashboard |
| Insight | Pelo menos uma ação tomada por causa dos dados | Decisão documentada |
| Esforço para adicionar uma máquina | Menos de um dia por máquina extra | Cronometrar a última inclusão |
As metas acima são exemplos. Defina as suas, mas torne-as mensuráveis. "Mostrar o valor da IIoT" não é uma métrica. Muitas equipes também estimam o payback esperado para o business case; nosso artigo sobre ROI de IIoT explica como apresentá-lo com honestidade.
Passo 3: escolha uma stack leve
Resista à tentação de construir uma plataforma. Uma prova de conceito precisa de quatro coisas:
- Uma fonte de dados. O CLP da máquina por meio de um gateway de protocolo, ou sensores adicionais por meio de um microcontrolador.
- Um gateway de borda. Um pequeno PC industrial ou um Raspberry Pi rodando Node-RED, um script Python ou um gateway comercial que lê a fonte e publica em MQTT.
- Um broker. Um broker MQTT gerenciado, para que ninguém passe a primeira semana instalando e protegendo um servidor.
- Um dashboard. Node-RED Dashboard, Grafana alimentado por um pequeno subscriber ou o próprio dashboard do broker nos primeiros dias.
É o mesmo modelo em camadas descrito na nossa referência de arquitetura IIoT, só que com um componente por camada. Como todas as camadas falam MQTT, cada peça pode ser trocada depois sem mexer nas outras.
O plano de prova de conceito de IIoT em 30 dias
| Semana | Objetivo | Atividades principais | Critério de saída |
|---|---|---|---|
| 1 | Fundações | Confirmar escopo e métricas, mapear o caminho de rede, solicitar regra de firewall de saída para a 8883, criar o broker, definir nomes de topics, executar o simulador | Dados simulados visíveis em um dashboard |
| 2 | Dados reais | Instalar o gateway, conectar ao CLP ou aos sensores em modo somente leitura, publicar no broker, validar os valores contra a IHM | Dados ao vivo de todas as máquinas do piloto |
| 3 | Torná-lo útil | Construir o dashboard com os operadores, adicionar durações de estado e lista de paradas, configurar alertas por limite | O supervisor usa o dashboard diariamente |
| 4 | Provar e decidir | Medir as métricas, comparar com os registros manuais, documentar esforço e lições, apresentar os resultados | Decisão de seguir ou não, com números |
Para o trabalho de rede da semana 1, o checklist de conectividade IIoT traz as regras exatas e os comandos de teste.
Construa o pipeline antes de o hardware chegar
Aprovações de hardware e de firewall muitas vezes levam uma semana ou mais. Não espere. Construa o pipeline completo contra um simulador no primeiro dia, usando o servidor MQTT público (apenas dados de teste), para que, quando o gateway real entrar em operação, ele simplesmente substitua o simulador.
import json
import random
import time
import uuid
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
POC_ID = uuid.uuid4().hex[:6]
BASE = f"connectmq/demo/{POC_ID}/plant1/cell3"
MACHINES = ["cnc01", "cnc02"]
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"poc-sim-{POC_ID}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
print(f"Subscribe to: {BASE}/#")
state = {m: {"state": "RUNNING", "parts": 0} for m in MACHINES}
while True:
now = datetime.now(timezone.utc).isoformat(timespec="seconds")
for m in MACHINES:
s = state[m]
# Mudanças aleatórias de estado: quase sempre rodando, às vezes ociosa ou parada
r = random.random()
new_state = "RUNNING" if r < 0.85 else ("IDLE" if r < 0.95 else "STOPPED")
if new_state != s["state"]:
s["state"] = new_state
client.publish(f"{BASE}/{m}/state",
json.dumps({"value": new_state, "ts": now}),
qos=1, retain=True)
if s["state"] == "RUNNING":
s["parts"] += 1
client.publish(f"{BASE}/{m}/parts",
json.dumps({"value": s["parts"], "ts": now}),
qos=1, retain=True)
amps = round(random.uniform(8, 12) if s["state"] == "RUNNING" else random.uniform(0.5, 2), 2)
client.publish(f"{BASE}/{m}/current",
json.dumps({"value": amps, "unit": "A", "ts": now}), qos=0)
time.sleep(5)
Acompanhe o fluxo em outro terminal com o topic que o script imprime:
mosquitto_sub -h broker.connectmq.com -p 1883 -i poc-watch-$RANDOM \
-t 'connectmq/demo/<POC_ID>/plant1/cell3/#' -v
O simulador usa a mesma estrutura de topics e o mesmo formato de payload que o gateway real vai usar: estado e contagem de peças retidos, leituras de corrente não retidas e um timestamp ISO em cada mensagem. Construa seu dashboard contra ele. Quando o gateway estiver pronto, troque o dashboard e o gateway para o seu broker privado, com TLS e as credenciais do portal. O broker público serve apenas para desenvolvimento, porque qualquer pessoa pode lê-lo.
Quem faz o quê durante os 30 dias
Uma prova de conceito precisa de uma equipe pequena com papéis claros, não de um comitê gestor. Três ou quatro pessoas normalmente bastam:
- O patrocinador, muitas vezes o gerente da planta ou de produção, é dono da pergunta de negócio e toma a decisão de seguir ou não no dia 30.
- O engenheiro de automação é dono de tudo o que está na máquina: quais tags ou sensores ler, o acesso somente leitura e a validação dos valores contra a IHM.
- A pessoa de TI ou de dados é dona do caminho de rede, das credenciais do broker e do dashboard.
- O usuário final, normalmente um supervisor de turno ou um líder de manutenção, testa o dashboard todos os dias a partir da semana 3 e diz com sinceridade se ele ajuda.
Faça uma reunião rápida de quinze minutos duas vezes por semana. Qualquer bloqueio que dure mais de dois dias vai direto para o patrocinador, porque um plano de 30 dias não tem folga para esperar aprovações.
Armadilhas comuns em provas de conceito
- Escolher primeiro a máquina mais difícil. Comece por uma máquina com interface acessível e um responsável colaborativo.
- Não envolver os operadores. Se os operadores não participaram do dashboard, não vão usá-lo, e a adoção é uma métrica de sucesso.
- Coletar tudo. Duas mil tags deixam o piloto mais lento e o insight mais difícil de encontrar. Comece pelos sinais que respondem à sua pergunta.
- Pular as métricas chatas. Completude dos dados e latência são o que as equipes de TI e TO vão perguntar antes de escalar. Meça-as.
- Construir infraestrutura descartável. Um broker no notebook de alguém precisa ser reconstruído para escalar. Use algo que aguente o rollout em produção.
Da prova de conceito ao rollout
Se o piloto der certo, a próxima pergunta é com que rapidez você consegue adicionar máquinas. Com uma hierarquia de topics limpa e um broker que escala conforme o plano, adicionar a décima máquina é igual a adicionar a segunda. O ConnectMQ permite começar no plano Serverless gratuito (até 25 conexões, QoS até 1, mensagens de 256 KB), que cobre com folga um piloto de 30 dias, e migrar para o Serverless pago com QoS 2 e assinaturas compartilhadas ou para um cluster Dedicated à medida que o rollout cresce, sem mudar topics nem código dos clients. O explorador de topics ao vivo do portal, a visão de dispositivos ISA-95 e as regras de alerta por limite apoiam diretamente as semanas 2 e 3. Para a jornada completa depois do piloto, leia o guia de IoT Industrial com MQTT. Com dados confiáveis fluindo, a planta também ganha a base para um futuro gêmeo digital.
Comece seu piloto de 30 dias no ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Execute o simulador contra o seu próprio broker ConnectMQ no primeiro dia, construa o dashboard enquanto o hardware está a caminho e chegue ao dia 30 com números reais.
Perguntas frequentes
Quanto tempo deve durar uma prova de conceito de IIoT?
Cerca de 30 dias é realista para uma a três máquinas e uma pergunta bem delimitada. Pilotos mais longos tendem a crescer em escopo sem produzir uma decisão.
Quanto custa uma prova de conceito de IIoT?
Principalmente o tempo das pessoas, mais um gateway e, possivelmente, sensores. Um plano gratuito de broker MQTT gerenciado e ferramentas open source como o Node-RED mantêm baixo o custo de software.
Quantas máquinas um piloto deve incluir?
Uma a três, de preferência do mesmo tipo. Isso basta para provar o caminho dos dados e o valor sem transformar o piloto em um rollout.
O que acontece depois de uma prova de conceito bem-sucedida?
Use o esforço documentado por máquina e as métricas medidas para planejar um rollout em fases. Mantenha a mesma hierarquia de topics e o mesmo broker, para que o piloto se torne a primeira fase em vez de algo descartável.
