Depois de integrar a station ao Niagara Cloud, é necessário definir quais dispositivos, pontos e históricos serão disponibilizados no ambiente Cloud. Essa configuração é feita a partir da própria station Niagara.
Nesta terceira parte da série, serão apresentados os conceitos de modelagem de dados, configuração da exportação de históricos para o Niagara Data Service e utilização do Niagara Cloud History Provider para consultar dados arquivados no Cloud.
Este procedimento considera que o JACE ou Supervisor já passou pelo onboarding e está corretamente registrado no Niagara Cloud Suite. A configuração desta etapa determina quais dados da station serão contextualizados e disponibilizados no Cloud.
1. Antes de iniciar
O onboarding do JACE ou Supervisor deve estar concluído e a conexão com o Niagara Cloud Suite deve estar ativa.
Para exportar históricos e utilizar os recursos de dados Cloud, a instância deve possuir uma subscription compatível com o Niagara Data Service.
Utilize uma versão suportada do Niagara Framework e mantenha o Software Maintenance Agreement ativo conforme os requisitos do Niagara Cloud Suite.
A qualidade do modelo enviado ao Cloud depende da estrutura, tags, relações e histories configurados na station.
2. O que a configuração da station controla
O Niagara Data Service não trabalha apenas com valores isolados. Os dados podem ser enviados juntamente com o contexto criado no Niagara por meio de tags, relações e da estrutura do modelo.
| Configuração | Função |
|---|---|
| Data Model | Define os dispositivos, equipamentos, pontos e relações que serão contextualizados no Niagara Cloud. |
| Tags e Relations | Adicionam significado ao dado e permitem preservar o contexto semântico no Cloud. |
| History Export | Determina quais históricos da station serão enviados ao Niagara Data Service. |
| Cloud History Provider | Permite consultar pela station dados históricos arquivados no Cloud quando necessário. |
Um valor de temperatura não precisa ser exportado apenas como “22,5 °C”. O modelo pode preservar informações como equipamento, localização, grandeza, unidade e relações com outros componentes, permitindo que aplicações Cloud entendam o significado daquele ponto.
3. Modelar dispositivos e pontos na station
A modelagem é feita no Niagara, normalmente durante a engenharia da station. O objetivo é identificar quais componentes representam equipamentos, sistemas e pontos que deverão fazer parte do modelo disponibilizado ao Niagara Cloud.
Utilize a estratégia de tagging adotada no projeto para classificar os componentes e estabelecer as relações necessárias. O Niagara Data Service preserva as tags e relações associadas aos dados exportados.
Evite utilizar tags apenas para “fazer o ponto aparecer no Cloud”. A mesma estratégia de modelagem deve ser aplicada de forma consistente em equipamentos equivalentes, facilitando consultas, dashboards, APIs e análises posteriores.
4. Definir o que será representado no Niagara Cloud
Nem todos os componentes técnicos da station precisam necessariamente fazer parte do modelo disponibilizado ao Cloud. Priorize dispositivos e pontos que possuam significado operacional ou que serão utilizados em histórico, análise, dashboard ou integração por API.
| Tipo de componente | Exemplo de uso no modelo |
|---|---|
| Equipamento | AHU, fan coil, chiller, bomba, medidor ou outro ativo operacional. |
| Ponto de medição | Temperatura, umidade, consumo, pressão, vazão ou potência. |
| Ponto de estado | Ligado/desligado, modo de operação, alarme ou condição operacional. |
| Ponto de comando | Setpoint ou comando que poderá fazer parte de uma integração habilitada para leitura/escrita. |
5. Validar o modelo antes da exportação
Antes de configurar os históricos, revise o modelo e confirme se os principais equipamentos aparecem com a estrutura esperada.
Confira as tags
Verifique se os equipamentos e pontos possuem as tags previstas pela estratégia do projeto.
Confira as relações
Confirme se as relações entre equipamentos, pontos, sistemas e localizações estão coerentes.
Evite duplicidades
Revise componentes duplicados, tags conflitantes ou estruturas que possam representar o mesmo ativo mais de uma vez.
6. Configurar a exportação dos históricos
O Niagara Data Service pode enviar automaticamente históricos da station para o Cloud. Conforme a configuração utilizada, é possível disponibilizar todos os histories elegíveis ou selecionar quais históricos serão exportados.
Utilize as políticas de exportação de histórico da station para definir quais dados serão armazenados no Niagara Data Service.
A seleção deve considerar o objetivo do projeto, o período de retenção necessário, a frequência de coleta e o volume de dados. Exportar histories sem uso definido aumenta o volume armazenado e dificulta a organização do ambiente.
7. Selecionar os histories que serão enviados ao Cloud
Ao definir a política de exportação, confirme se cada histórico possui origem, unidade e contexto coerentes com o modelo de dados.
| Verificação | Por que é importante |
|---|---|
| History correto | Evita enviar para o Cloud o histórico de outro ponto ou equipamento. |
| Unidade | Permite interpretar corretamente os valores em dashboards e integrações. |
| Intervalo de coleta | Afeta resolução, volume de dados e utilização futura. |
| Tags e relações | Preservam o contexto semântico do history no Niagara Data Service. |
8. Validar a exportação no Niagara Data Service
Depois de aplicar as políticas, valide se os históricos esperados aparecem no Niagara Cloud e se os dados são atualizados de forma coerente.
O history deve estar associado ao dispositivo e ao ponto corretos, apresentar os valores e unidades esperados e manter o contexto definido pelas tags e relações da station.
9. Entender o Niagara Cloud History Provider
O Niagara Framework possui o recurso de Archive History Provider, que permite consultar dados históricos armazenados fora da base local da station. No Niagara Cloud Suite, esse mecanismo é utilizado para acessar histories arquivados no Niagara Data Service.
Quando a integração compatível está habilitada, o provider Cloud é configurado para permitir que consultas históricas utilizem também dados arquivados no Niagara Cloud.
A station pode manter sua base histórica local para operação normal enquanto dados mais antigos permanecem disponíveis no Cloud. Quando uma consulta precisa alcançar um período que não está mais armazenado localmente, o Archive History Provider pode recuperar os registros arquivados.
10. Consultar históricos arquivados
Os dados disponibilizados pelo provider podem ser utilizados por recursos do Niagara que consultam histories, como gráficos, consultas e interfaces compatíveis.
Isso permite analisar períodos maiores sem manter todo o volume histórico permanentemente armazenado na base local da station.
O ponto precisa possuir um histórico válido e uma política de exportação adequada. O provider é utilizado para consultar dados arquivados; ele não cria automaticamente uma estratégia de coleta para pontos que não possuem history.
11. Validar a configuração da station
A configuração está concluída quando os equipamentos e pontos esperados aparecem contextualizados no Niagara Cloud, os histories selecionados são exportados para o Niagara Data Service e a station consegue consultar os dados arquivados conforme a configuração do Cloud History Provider.
12. Se os dados não aparecerem corretamente no Cloud
| Comportamento | O que verificar |
|---|---|
| O dispositivo aparece no Cloud, mas os pontos não. | Revise a modelagem, tags, relações e critérios utilizados para disponibilizar os componentes. |
| O ponto aparece sem contexto suficiente. | Revise tags, relações, equipamento pai, localização e demais informações do modelo. |
| O history não aparece no Niagara Data Service. | Confirme se o ponto possui history, se ele está incluído na política de exportação e se a conexão Cloud está ativa. |
| O history aparece, mas não recebe novos valores. | Revise a coleta local do history e depois valide o processo de exportação. |
| Existem histories desnecessários no Cloud. | Revise as políticas de exportação e mantenha somente os dados previstos para o projeto. |
| Dados antigos não aparecem pela station. | Revise o Archive/Cloud History Provider, a disponibilidade dos dados no Cloud e o período solicitado na consulta. |
| O provider Cloud não está disponível. | Confirme versão compatível, onboarding, módulos instalados e subscription do Niagara Data Service. |
| Os dados estão associados ao equipamento errado. | Revise a modelagem, tags e relações antes de alterar a configuração de exportação. |
13. Boas práticas de modelagem e históricos
- Defina uma estratégia de tags antes de iniciar a exportação em larga escala.
- Mantenha nomes, tags e relações consistentes entre equipamentos equivalentes.
- Exporte somente histories que possuam finalidade definida no projeto.
- Revise unidades e intervalos de coleta antes de enviar os dados ao Cloud.
- Valide o modelo no Niagara Cloud antes de liberar dashboards ou integrações externas.
- Documente alterações na modelagem que possam afetar consultas, APIs ou aplicações que consomem os dados.
14. Vídeo — Niagara Cloud Suite Parte 3
Assista ao vídeo em português utilizado como referência para esta parte da série, com a demonstração da modelagem de dados, exportação de históricos e utilização do Niagara Cloud History Provider.
Com a modelagem e a exportação de históricos configuradas, o Niagara Data Service pode ser utilizado para visualização, dashboards, consultas e integrações por API, conforme os serviços habilitados no projeto.
Ainda precisa de ajuda?
Entre em contato com o suporte técnico da Mercato. Para agilizar o atendimento, informe o equipamento, produto ou sistema relacionado e descreva brevemente a dúvida ou o problema encontrado.
Falar com o suporte no WhatsApp →