O primeiro passo natural em um projeto de IoT é pedir um kit de desenvolvimento e alguns sensores. Parece progresso, custa pouco e dá ao time algo para ligar. A maioria dos projetos começa assim.
O problema é que hardware comprado antes do escopo decide por você. Um sensor LoRaWAN amarra você a uma rede que talvez não tenha cobertura no local. O firmware dele fixa o formato do payload e limita as variáveis que você vai conseguir extrair dele. O intervalo de envio padrão define a vida da bateria, o volume de dados e o tamanho da sua fatura da plataforma pelos próximos três anos. O hardware faz todas essas escolhas de uma vez, e são as mais difíceis de reverter. Devolver um kit de desenvolvimento é fácil. Trocar quatrocentos sensores já instalados porque o rádio é o errado é recomeçar o projeto.
O que funciona é uma sequência de passos que produz um escopo de uma página antes de qualquer ordem de compra, e depois comprova esse escopo na plataforma com um dispositivo simulado. O hardware vem por último, e a essa altura você já sabe o que pedir.
Passo 1: nomeie a decisão que os dados precisam mudar
Todo projeto de IoT que se paga muda uma decisão que alguém toma hoje sem dados. Escreva essa decisão em uma frase, com um cargo específico: “o gerente da unidade decide quais câmaras frias inspecionar toda manhã” ou “o líder de manutenção decide quando trocar as vedações da bomba”. Se a frase precisa da palavra “insights”, ela não está pronta.
Esse passo decide todo o resto. Uma decisão tomada uma vez por dia tolera um sensor que reporta a cada hora. Uma decisão que interrompe uma linha de produção precisa de segundos. Os times que pulam esse passo terminam com um dashboard que ninguém abre.
Passo 2: liste as variáveis, as unidades e o intervalo de envio
Partindo da decisão, trabalhe de trás para frente até chegar ao mínimo de dados: quais variáveis, em quais unidades, em qual intervalo, com qual precisão. Temperatura com 0,5 C a cada 15 minutos exige um sensor, um orçamento de bateria e um volume de dados diferentes de temperatura com 0,1 C a cada minuto.
O intervalo é o número que esconde o custo. Um sensor que envia a cada minuto gera 60 vezes o volume de dados de um que envia a cada hora, consome a bateria em uma fração do tempo e empurra a frota para as faixas mais caras de entrada de dados de qualquer plataforma. Defina o intervalo a partir da decisão do Passo 1, não a partir do padrão do sensor.
Passo 3: confira os locais e a realidade da conectividade
Liste todos os locais onde um dispositivo vai ficar e responda, para cada um: qual rádio chega de verdade até lá? LoRaWAN precisa de um gateway com caminho real até o ponto do sensor, e subsolos, caixas metálicas e concreto denso derrubam bastante o alcance do datasheet. Celular precisa de cobertura da operadora dentro do prédio, e não do lado de fora dele. Wi-Fi precisa que o TI do cliente diga sim, por escrito, sobre uma rede que você não controla.
Um teste de cobertura custa uma tarde e um gateway emprestado. Pular esse teste é o que faz um projeto especificado para LoRaWAN terminar em celular, com o triplo do custo por unidade. Leia o alcance real do LoRaWAN em um projeto de verdade antes de supor qualquer número.
Passo 4: conte os dispositivos no piloto e no terceiro ano
Dois números honestos: quantos dispositivos no piloto e quantos se o piloto der certo e a implantação seguir por três anos. O número do piloto dimensiona seu primeiro pedido. O número do terceiro ano dimensiona todo o resto: qual modelo de preço faz sentido e quais limites da plataforma você vai bater primeiro (entrada de dados, saída de dados, armazenamento, notificações).
Um modelo de preço que é barato com 30 dispositivos pode ser o mais caro com 3.000. Como os modelos de preço de plataformas IoT diferem, e qual é o mais previsível mostra os formatos. Escreva o número do terceiro ano mesmo que seja um chute; um chute no papel é corrigido, um chute na cabeça de alguém não.
Passo 5: defina quem são os usuários e o que cada um vê
Separe quem constrói a aplicação de quem a usa. Na TagoIO, quem constrói trabalha no Admin: cadastra dispositivos, escreve Payload Parsers, monta Dashboards, configura Actions. Os usuários finais, o gerente da unidade do Passo 1, entram em um portal TagoRUN com a sua marca, na web ou no app mobile, e veem apenas o que a política de Access Management deles permite.
Para cada tipo de usuário, escreva o que ele vê e o que ele pode fazer: quais locais, quais dashboards, quais alertas no celular e se ele pode mudar os limites de alerta ou apenas visualizar. Se um tipo de usuário precisa de notificações push em campo, o app mobile entra no escopo desde o primeiro dia, o que muda como você organiza os dashboards.
Passo 6: liste as integrações que precisam existir
A maioria dos projetos de IoT termina em outro sistema. O alerta tem que virar um ticket. Os totais do dia têm que cair no ERP. Escreva cada integração com a direção (entrada ou saída), o gatilho (por evento, por agendamento) e o protocolo (webhook, API REST, entrega de arquivo). Na plataforma, isso vira uma Action que faz POST em um webhook ou uma Analysis agendada chamando a API externa.
Uma integração que ficou de fora é o motivo mais comum de um piloto pronto nunca chegar à produção: os dados estavam certos, mas nunca chegaram ao sistema que age sobre eles.
Passo 7: escreva os critérios de aceite do piloto
Antes do hardware, combine o que significa “o piloto funcionou”. Disponibilidade de entrega de dados por dispositivo. Latência do alerta, do evento até a notificação. Consumo de bateria em relação à vida projetada. A decisão do Passo 1, tomada de verdade a partir do dashboard, pela pessoa nomeada, durante um número definido de semanas.
Critérios escritos agora são baratos. Critérios negociados depois de um piloto que funcionou pela metade são caros, porque cada stakeholder se lembra de uma promessa diferente. Coloque os critérios no escopo, do lado do nome de quem aprova.
Mapeie o escopo para objetos da plataforma e simule o primeiro dispositivo
Cada linha do escopo de uma página corresponde a algo que você já consegue construir na plataforma hoje, sem nenhum sensor em mãos:
- Variáveis e unidades (Passo 2) viram um Device com variáveis nomeadas. O Connector ou o Payload Parser desse Device decodifica o payload que o hardware candidato vai enviar.
- Locais e conectividade (Passo 3) viram o Network do dispositivo e as tags que agrupam dispositivos por local.
- Usuários e telas (Passo 5) viram Dashboards e uma política de Access Management que mostra a cada usuário do TagoRUN apenas os locais dele.
- Integrações (Passo 6) viram Actions com uma condição e um destino webhook, ou uma Analysis agendada.
- Critérios de aceite (Passo 7) viram os limites de alerta e os widgets pelos quais você vai julgar o piloto.
Depois, crie um dispositivo, pegue o payload de exemplo do datasheet do sensor candidato e envie pela API no intervalo do Passo 2. Em uma hora você tem um dashboard mostrando os dados da decisão, um alerta no seu celular pelo app do TagoRUN e um webhook batendo em um endpoint de teste. Você também descobre se o payload carrega as variáveis de que você precisa, se o intervalo fica bom em um gráfico e se o usuário final entende a tela.
Agora peça o hardware. Você está comprando com base em uma especificação que o time já viu funcionando, e se o primeiro dispositivo real discordar da simulação, você descobre no primeiro dia em vez de na implantação.
