
Cenários · Multi-site
IBMS multi-site: uma visão operacional única entre edifícios
Como conceber um IBMS multi-site com um modelo de dados comum, autonomia local e uma camada central que resiste a falhas de rede.
Resposta rápida
Um IBMS multi-site dá a uma carteira um modelo de dados, um modelo de alarmes e uma camada de relatórios únicos, enquanto cada edifício mantém o controlo local. As instalações executam as suas próprias sequências e guardam o seu próprio histórico; o centro compara desempenho, distribui normas e gere acessos, mas não é necessário para a operação diária.
O que uma visão operacional única exige realmente
Um painel de controlo de carteira não é um IBMS multi-site. O trabalho mais difícil é acordar o que um ponto significa entre edifícios: o mesmo nome para a temperatura exterior, as mesmas unidades, a mesma gravidade de alarme, o mesmo tratamento de fusos horários e a mesma definição de ocupação. Sem esse modelo, o centro recebe dados que não consegue comparar e os operadores passam o tempo a reconciliar definições. O modelo deve ser escrito antes de o primeiro local ser configurado, com uma convenção de nomenclatura, um dicionário de objetos e uma regra para extensões específicas de cada local. A uniformização nesta camada é o que torna credível o relatório de carteira e também o que torna um novo local mais rápido de comissionar.
Autonomia local e camada central
Cada local deve permanecer totalmente operacional quando a ligação de área alargada está em baixo. Os controladores locais executam as sequências de AVAC, iluminação, sombreamento e medição e guardam histórico suficiente para sobreviver a uma falha. A camada central agrega, visualiza, reporta e gere utilizadores. Também pode distribuir atualizações do modelo, mas essas atualizações devem ser faseadas e reversíveis. Esta divisão mantém a segurança e o conforto no local, dando simultaneamente à gestão uma visão de carteira. Também limita o raio de impacto de uma falha central e torna a arquitetura de rede mais fácil de proteger. A plataforma central pode ser atualizada sem tocar na lógica de controlo local. O teste é simples: desligue um local e confirme que o edifício continua a funcionar, que os alarmes continuam a ser registados e que o histórico não se perde.
Uniformize o modelo, documente o perfil do local
Uma carteira precisa de um modelo comum: grafismos, nomenclatura de pontos, classes de alarme, objetos de programação, definições de relatórios e perfis de utilizador. Precisa também de um perfil de local para o que difere legitimamente: tipo de central, clima, horário de funcionamento, medição por inquilino, regulamentos locais e topologia de rede. O modelo deve ser versionado e cada local deve registar a versão que executa. Quando um local precisa de um desvio, registe-o e decida se deve ser promovido para a versão seguinte do modelo. Isto evita a divergência lenta que transforma uma carteira num conjunto de sistemas sem relação entre si. Também dá à equipa central uma forma de implementar uma melhoria sem reengenharia manual de cada edifício.
Implementação, segurança e governação
Implemente por vagas, com um local de referência que comprove o modelo antes de ser replicado. Defina quem pode alterar setpoints, quem pode reconhecer alarmes e quem pode acrescentar utilizadores em cada nível. Segmente as redes dos edifícios da TI corporativa, exija contas nominativas e mantenha uma política de atualizações e de firmware que abranja controladores, gateways e a plataforma central. Teste um local isoladamente e depois teste a vista de carteira, incluindo o que acontece quando um local está offline. A governação não é burocracia: é a diferença entre um sistema que se mantém comparável e um que se fragmenta silenciosamente. O modelo de operação deve nomear as pessoas responsáveis por cada camada e a cadência de revisão do desempenho. Um relatório mensal curto basta para manter a carteira visível.
Camadas num IBMS multi-site
7 rows| Camada | Função | Decisão de conceção |
|---|---|---|
| Controlo do local | Sequências de AVAC, iluminação, sombreamento e medição | Funciona localmente e sobrevive a uma falha de WAN |
| Histórico do local | Armazenamento de tendências e registo de alarmes | Retém dados suficientes para a operação local e para carregamento posterior |
| Agregação central | Painéis de controlo e relatórios da carteira | Lê um modelo de dados comum, não pontos em bruto do fabricante |
| Gestão de alarmes | Encaminhamento e escalonamento entre locais | Separa os alarmes críticos da carteira dos alarmes locais incómodos |
| Acesso de utilizadores | Perfis e permissões | Aplica o menor privilégio ao nível do local e do centro |
| Gestão do modelo | Grafismos, sequências e nomenclatura normalizados | Versiona o modelo e regista a versão de cada local |
| Rede e segurança | Segmentação, acesso remoto, atualizações | Mantém as redes dos edifícios separadas da TI corporativa |
Imagens do projeto
3 images


Perguntas frequentes
01Todos os locais precisam do mesmo BMS?
Precisam de um modelo de dados e de uma camada de relatórios comuns. O hardware de cada local pode ser diferente, desde que o modelo defina como são expostos os pontos, os alarmes e o histórico.
02O que acontece quando um local perde a ligação?
O local continua a funcionar com controlo local e guarda o histórico localmente. O centro deve apresentar o local como offline e preencher os dados quando a ligação regressar.
03A quem pertencem os dados?
O proprietário. Os contratos devem indicar onde os dados são armazenados, como são exportados e o que acontece no final de um contrato de serviço.
04Como lidamos com fusos horários diferentes?
Guarde as marcas temporais com um fuso horário explícito e sincronize os relógios. Os relatórios devem indicar se usam a hora local ou a hora central.
05Podemos acrescentar um novo local mais tarde?
Sim, se o modelo for versionado e o novo local for perfilado face a ele. O custo e o esforço dependem do grau de desvio do local em relação à norma.
Próximo passo
Traga-nos o edifício.
Diga-nos o tipo de edifício, os sistemas abrangidos e o resultado pretendido. Indicaremos o caminho mais curto para um sistema funcional.