# Como é uma implantação de IoT real, do início ao fim

> Uma implantação genérica, 40 câmaras frias em 6 unidades, com todas as fases na ordem de dependência, prazos realistas e para onde o tempo realmente vai.

![Como é uma implantação de IoT real, do início ao fim](https://tago.io/og/pt-br/blog/what-a-real-iot-deployment-looks-like-start-to-finish.png)

Todo diagrama de fornecedor sobre implantação de IoT tem três caixas: sensor, nuvem, dashboard. O desenho não está errado. Em uma plataforma decente, conectar as peças é a parte fácil.

O desenho erra no tempo. Uma implantação real é uma sequência de etapas sem glamour, com uma ordem de dependência, e a maioria das equipes de primeira viagem faz tudo ao contrário: o dashboard primeiro porque é divertido, o hardware depois porque é quando o projeto parece real, e os usuários no fim porque alguém lembra, uma semana antes do go-live, que a equipe do cliente precisa fazer login. Cada inversão custa semanas.

Abaixo, uma implantação genérica percorrida em ordem: um integrador de sistemas instalando sensores de temperatura e de porta em 40 câmaras frias, distribuídas por 6 unidades de um distribuidor de alimentos. Troque por tanques ou medidores; as fases não mudam.

![Treze semanas até a entrega, na ordem de dependência, para 40 câmaras frias em 6 unidades: escopo e aceite, vistoria das unidades, compra de hardware levando de quatro a seis semanas com a configuração da plataforma concluída dentro desse prazo, comissionamento, alertas e usuários, ajuste no go-live e entrega, com o terceiro mês adicionando Data Retention e um relatório mensal](https://tago.io/images/blog/what-a-real-iot-deployment-looks-like-start-to-finish/thirteen-weeks-to-handover.svg)

## Escopo e critérios de aceite (semanas 1 a 2)

"Queremos monitorar as câmaras frias" é um desejo, não um escopo. A implantação precisa de uma definição de pronto por escrito. Aqui: temperatura a cada 10 minutos, sinalização de porta aberta por mais de 5 minutos, alarme acima de 5 C por 20 minutos, notificação push para o gerente da unidade e e-mail para o líder de operações, uma página por unidade com o histórico de cada câmara.

Duas semanas parecem muito para um documento. O tempo vai para a espera: o líder de operações e o empreiteiro de manutenção discordam sobre quem responde pelos alarmes, e ninguém resolve isso até você perguntar por escrito. Pular essa etapa empurra as duas semanas para o go-live, onde elas custam mais. Mais detalhes no [guia de planejamento para gerentes de projeto não técnicos](https://tago.io/blog/planning-an-iot-project-non-technical-pm).

## Vistoria das unidades e teste de conectividade (semanas 2 a 3)

Câmaras frias são caixas de metal com portas isoladas. Sinal de rádio não gosta disso. Antes de comprar 40 sensores, você precisa saber, câmara por câmara, se um gateway LoRaWAN no corredor alcança o interior com a porta fechada, e se esse gateway tem energia e backhaul.

Uma pessoa, dois sensores de teste, um gateway, um dia por unidade. A vistoria reescreve a lista de hardware: duas unidades precisam de um segundo gateway, uma não tem sinal celular na casa de máquinas. Descobrir isso agora custa uma semana; descobrir no comissionamento custa uma nova visita a cada unidade. O [alcance real do LoRaWAN em um projeto de verdade](https://tago.io/blog/lorawan-range-in-the-real-world) tem os números.

## Compra de hardware (semanas 3 a 8) e configuração da plataforma (semanas 3 a 5), em paralelo

Sensores e gateways chegam em quatro a seis semanas. Quem está começando espera. Equipes experientes constroem toda a parte que roda na plataforma nessa janela, sem hardware em mãos, o maior ganho de cronograma do projeto.

Na TagoIO, a ordem é:

- Crie um Device usando o [Connector](https://docs.tago.io/docs/tagoio/devices/adding-devices-with-connectors) do modelo do sensor e o Network do provedor LoRaWAN. O Connector decodifica os bytes do fabricante em temperatura, estado da porta e bateria.
- Passe um uplink de exemplo do datasheet pelo Payload Parser e confirme que ele gera os nomes de variáveis que o dashboard e os alertas vão usar. Conversões de unidade e renomeações entram no Parser agora, uma vez só.
- Defina a convenção de tags antes de qualquer outra coisa existir: site, room, `asset_type`, customer. Dashboards, alertas, políticas de acesso e relatórios filtram por elas.
- Monte um [Blueprint Dashboard](https://docs.tago.io/docs/tagoio/dashboards/blueprint-dashboard) que seleciona os Devices por tag. Um dashboard atende as 40 câmaras e todas as que vierem depois. Envie dados simulados para o Device de teste para que os widgets tenham o que mostrar.

Duas semanas de um engenheiro. Quando o hardware chega, a plataforma está pronta, e não apenas iniciada.

## Comissionamento do hardware e disciplina de tags (semanas 8 a 10)

A instalação leva o tempo que leva: um sensor por câmara, gateways na parede, etiqueta em tudo. Seis unidades a dois dias cada dão duas semanas para um instalador.

A metade que roda na plataforma é onde a disciplina de tags se paga. Para cada sensor, crie o Device a partir do mesmo Connector, ajuste as tags para a câmara onde ele fica e confirme o primeiro uplink. A câmara 17 da unidade 3 aparece no Blueprint Dashboard no momento em que seu Device tem as tags certas e um ponto de dado. Ninguém monta dashboard durante o comissionamento. Se alguém estiver montando, a fase anterior foi pulada.

Mantenha uma planilha de comissionamento: EUI do dispositivo, unidade, câmara, data de instalação, instalador. Quando um sensor parar de reportar no terceiro mês, essa planilha transforma uma tarde de trabalho em uma correção de cinco minutos.

## Alertas via Actions, e quem recebe (semana 10)

Os limites vieram do escopo; a semana vai para combinar quem recebe o que. Configure [Actions](https://docs.tago.io/docs/tagoio/actions/defining-actions) que disparam pela condição da variável (temperatura acima do limite pela duração acordada, porta aberta por tempo demais) e enviam notificação push para os usuários TagoRUN daquela unidade, mais um e-mail para o líder de operações. Uma Action por tipo de alarme, filtrada por tag, cobre todas as câmaras. Crie também uma Action de "dispositivo silencioso por 2 horas": bateria descarregada é a falha mais comum e não produz dado nenhum, então nenhum limite dispara. Nos primeiros dias, direcione tudo para você mesmo.

## Acesso do usuário final via TagoRUN (semanas 10 a 11)

Os gerentes de unidade nunca veem o Admin da TagoIO. Eles entram em um portal [TagoRUN](https://docs.tago.io/docs/tagoio/tagorun) com a marca do integrador, na web e no app TagoRUN, para que as notificações push cheguem ao celular deles. Uma [política de Access Management](https://docs.tago.io/docs/tagoio/tagorun/access-management/creating-a-policy) dá a cada usuário o Blueprint Dashboard restrito aos Devices cuja tag site corresponde à unidade dele; o líder de operações recebe uma política que abrange as seis unidades. Crie os usuários uma semana antes do go-live e percorra o app com um gerente de unidade em uma ligação. As perguntas dele viram a primeira página do runbook.

## Go-live e as duas primeiras semanas (semanas 11 a 13)

O go-live é um e-mail dizendo que os alertas agora vão para o cliente. Depois começam os falsos alarmes.

Toda implantação em câmara fria produz as mesmas duas semanas: o limite de 5 C dispara sempre que uma empilhadeira escora a porta para repor produto, o alarme de porta dispara durante a limpeza programada, e uma câmara opera mais quente de propósito porque guarda hortifruti. Nada disso dava para saber pelo documento de escopo. As Actions ganham durações maiores, a janela de limpeza fica de fora, a câmara 22 ganha o próprio limite por uma tag. Avise o cliente com antecedência que essas semanas são de ajuste, senão ele lê o ruído como sistema quebrado.

## Entrega para operações (semana 13)

A entrega é um documento e uma reunião: o runbook (o que cada alarme significa, quem responde, como trocar um sensor e refazer as tags do Device), a planilha de comissionamento, os limites atuais e um responsável com nome de cada lado. Se o projeto for vendido como [serviço gerenciado](https://tago.io/blog/how-to-price-an-iot-managed-service), a mensalidade começa aqui e o orçamento do projeto se encerra.

## Terceiro mês

No terceiro mês, a implantação está sem graça, que é o objetivo. Aí chegam os pedidos que ninguém planejou.

O volume de dados vira item de custo. Quarenta sensores a cada 10 minutos passam de 5.700 leituras por dia, e o histórico bruto não é necessário depois de alguns meses. O [Data Retention](https://docs.tago.io/docs/tagoio/devices/data-management/data-retention-feature) em cada Device limita isso.

O cliente pede um relatório mensal. Uma Analysis agendada calcula os minutos fora da faixa e os minutos de porta aberta por unidade e grava um resumo para um widget ou um e-mail. Um dia de código, porque as tags já separam os dados por unidade.

O cliente quer duas unidades a mais. A expansão é vistoria, hardware, Devices com o mesmo Connector e o novo valor de site, e usuários com uma política para isso. O dashboard, as Actions e o relatório já funcionam.

Treze semanas até a entrega, com o trabalho de plataforma cabendo dentro do prazo do hardware e a maior parte do calendário indo para a espera de pessoas, rádio e entrega. As três caixas nunca foram o problema.

[llms.txt](https://tago.io/llms.txt)