Manutenção de BMS: rotinas para preservar supervisão, alarmes e históricos
Defina verificações e evidências para manter as funções de supervisão compreensíveis e disponíveis à operação.
A manutenção de BMS deve comprovar que os dados exibidos correspondem ao campo, os alarmes chegam aos responsáveis, os históricos podem ser consultados e as configurações podem ser recuperadas. Para isso, cada rotina precisa indicar quais funções foram verificadas, em que condição, com qual evidência e quais pendências ficaram abertas. Conseguir entrar no supervisório é apenas uma parte dessa verificação.
Delimite quais funções entram na manutenção
Um BMS — Building Management System, ou sistema de gestão predial — reúne funções de supervisão e controle cuja disponibilidade precisa ser acompanhada ao longo da operação. O guia sobre o que é BMS apresenta essa arquitetura. Na manutenção, a pergunta passa a ser: quais funções continuam entregando o resultado previsto para este edifício?
Relacione servidores, controladoras, interfaces, estações e equipamentos atendidos. Para cada conjunto, identifique o responsável pela automação, pela rede, pelo servidor e pelo equipamento de campo. Uma ocorrência que aparece na tela pode exigir atuação de mais de uma equipe; o registro deve permitir acompanhar essa fronteira.
Defina também o alcance da visita. Conferir a leitura de uma temperatura na tela não equivale a calibrar o sensor, e verificar uma indicação de funcionamento não substitui a manutenção mecânica do equipamento. Esses serviços precisam de procedimentos e responsáveis próprios.
Confronte a supervisão com uma condição conhecida em campo
Selecione os pontos conforme criticidade, ocorrências recentes e mudanças no empreendimento. Registre a identificação do ponto, sua origem, a unidade, o estado observado e a condição de atualização. Quando o sistema disponibilizar qualidade do dado ou horário da leitura, inclua essas informações na evidência.
Uma indicação estável merece interpretação: pode representar uma condição real ou um dado que deixou de ser atualizado. A equipe deve confrontar a informação com uma referência válida e com o comportamento esperado do equipamento, usando o procedimento aplicável. Não conclua que houve falha de sensor apenas porque a tela parece congelada.
Para investigar comunicação ou reinicializações, preserve os registros de diagnóstico disponíveis antes de alterar o sistema. Como exemplo específico, a Schneider Electric descreve o SystemLog do EcoStruxure Building Operation como fonte de eventos de inicialização, falhas e estado de servidores e dispositivos. A mesma documentação distingue esse registro dos logs de depuração destinados ao suporte técnico. Fonte: documentação oficial do EBO.
Testes que comandem equipamentos ou alterem sua condição operacional devem ter janela, responsável e retorno previstos. O plano deve informar o que foi observado e o que foi efetivamente ensaiado; uma amostra verificada não representa automaticamente todos os pontos do edifício.
Acompanhe o alarme até o tratamento da ocorrência
Para os eventos incluídos na rotina, verifique identificação, origem, horário, apresentação ao operador e encaminhamento previsto no projeto. Quando houver notificação externa configurada, confirme também o recebimento pelo destinatário e registre a evidência. A visualização no supervisório não comprova, sozinha, a entrega em outro canal.
Separe o reconhecimento feito pelo operador da confirmação técnica de correção. A documentação do Metasys UI 16.0 informa que alarmes reconhecidos permanecem na linha do tempo e que as ações dependem das permissões do usuário. Esse comportamento ilustra por que o registro da interação com o alarme precisa ser lido junto com a condição do sistema e a intervenção executada. Fonte: System Activity, Johnson Controls.
Na entrega da manutenção, relacione ocorrências reincidentes, eventos sem responsável e inibições encontradas, com sua justificativa e situação. Alterar limites, atrasos ou prioridades para reduzir a quantidade de eventos exige avaliação da função; não deve ser uma forma de encerrar pendências. O detalhamento da engenharia de alarmes pertence ao projeto e à gestão de mudanças.
Verifique se os históricos respondem à pergunta da operação
Escolha uma pergunta verificável, como investigar o comportamento de um equipamento durante um turno. Consulte o intervalo necessário e confira identificação, unidade, datas e eventuais lacunas. Relacione o registro à configuração de coleta: a ausência de amostras pode exigir investigação do modo de registro, da comunicação ou do armazenamento.
No Metasys 13.0, o fabricante documenta buffers locais de tendências nos engines e transferência de amostras para a base do servidor, quando ele existe no site. A documentação também descreve informações sobre amostras perdidas. Portanto, nessa arquitetura, a consulta deve considerar o caminho entre coleta e armazenamento, não apenas o gráfico apresentado. Fonte: Historical Data Management, Johnson Controls.
Registre o período que foi possível recuperar e as condições de interpretação dos horários. Se o contrato prevê exportação, abra o arquivo resultante e confira se ele contém os pontos e o intervalo solicitados. Não prometa retenção de dados sem verificar a configuração e a capacidade da instalação. Recursos, limites e ferramentas variam conforme plataforma e versão.
Prepare a recuperação antes de precisar dela
O plano deve identificar o conteúdo de cada cópia, sua data, os componentes cobertos, a versão correspondente e quem tem acesso para recuperá-la. Na documentação do EBO, a opção Configuration Only inclui configurações; All data acrescenta dados históricos. Assim, chamar um arquivo de “backup” não esclarece o que ele preserva. Fonte: opções de backup do EBO.
O guia de proteção do Metasys Release 14 distingue cópias de dados históricos e de configuração e descreve teste dos backups em ambiente fora de produção, conforme escopo contratual. Essa orientação é específica do produto; o método para a instalação deve seguir sua documentação e as condições acordadas. Fonte: Metasys Release 14 Hardening Guide, seção 3.1.
Como critério de gestão, diferencie cópia gerada, cópia armazenada e restauração demonstrada. Se não houver ambiente ou autorização para ensaiar a recuperação, registre essa limitação. Não substitua essa evidência pela simples existência de um arquivo, nem execute restauração sobre o sistema operacional como teste de rotina.
Organize cada rotina pelo resultado que será entregue
O quadro abaixo é uma proposta editorial de organização do serviço, a adaptar ao projeto, aos manuais e ao risco operacional. Não estabelece periodicidades universais nem substitui procedimentos do fabricante.
| Frente | Verificação a combinar | Evidência de conclusão |
|---|---|---|
| Supervisão | Confrontar pontos selecionados com condição conhecida | Lista de pontos, condições e divergências |
| Alarmes | Confirmar apresentação e encaminhamento previstos | Evento identificado, destinatário e registro do tratamento |
| Históricos | Consultar e, quando previsto, exportar o período necessário | Intervalo recuperado, arquivo conferido e lacunas registradas |
| Recuperação | Conferir cobertura das cópias e ensaio autorizado | Inventário de backups e resultado ou limitação do teste |
| Alterações | Revisar o que mudou e a condição deixada à operação | Registro de mudança, pendências e responsável pelo próximo passo |
Defina frequência e profundidade conforme criticidade, histórico de falhas, recomendações aplicáveis e mudanças de uso. Após intervenções em servidor, rede ou programa, inclua verificações das funções afetadas. O plano de manutenção preventiva dos sistemas prediais ajuda a organizar essas rotinas no calendário geral.
O relatório deve separar função aprovada, função com falha e função não ensaiada. Para cada pendência, indique impacto observado, responsável e próxima ação. Evite um aceite global quando apenas parte do escopo foi verificada.
Use a evidência para decidir o próximo atendimento
Cenário hipotético: a operação de um edifício consegue acessar o supervisório, mas não encontra o histórico necessário para investigar uma queixa de temperatura. O atendimento registra primeiro quais pontos e períodos estão disponíveis. Depois, a equipe responsável verifica a coleta e o armazenamento conforme a plataforma, corrige a causa identificada e acompanha novas amostras.
A conclusão deve informar desde quando a coleta voltou a funcionar e se os dados antigos foram recuperados. Restabelecer o registro daqui para frente não comprova a recuperação do intervalo perdido. Se a investigação apontar limitações de suporte ou necessidade de migração, a decisão passa para um plano de retrofit de automação predial e BMS, com escopo próprio.
Para contratar a manutenção, reúna plataforma e versões, arquitetura disponível, funções críticas, ocorrências recentes, responsáveis pelas dependências e janelas permitidas. Peça que a proposta identifique testes, evidências, exclusões e tratamento de pendências. O guia de escopo do contrato de manutenção aprofunda esses anexos.
A página de automação predial e BMS da MB Control apresenta a atuação relacionada ao sistema. Envie o material disponível para discutir um escopo coerente com a operação do empreendimento.
Fontes técnicas consultadas
Consulta em 6 de outubro de 2026. Os exemplos de funcionalidades referem-se aos produtos e versões documentados, sem pressupor recursos iguais em todos os BMS.
- Schneider Electric — backup e logs do EcoStruxure Building Operation, publicação de 02/06/2026.
- Johnson Controls — Metasys UI 16.0, System Activity, revisão de 15/06/2026.
- Johnson Controls — Metasys 13.0, Historical Data Management, revisão de 02/12/2024, documentação indicada como ativa.
- Johnson Controls — Metasys Release 14 Hardening Guide, Rev. A, 2025, seção 3.1.
Vamos organizar a manutenção do seu BMS?
Envie a plataforma instalada, as ocorrências recentes e a documentação disponível para discutir as funções e evidências que precisam entrar no escopo de manutenção.