BMS vs IBMS — supervisão ou integração?

Profundidade da integração: gateways versus um modelo comum

Muitos projetos de BMS integram por gateway: cada subsistema mantém o seu próprio modelo e o BMS mapeia pontos selecionados para sinópticos. Isso funciona para monitorização, mas a lógica entre sistemas torna-se frágil, porque cada regra depende da nomenclatura de um fornecedor. Espera-se que um IBMS normalize os pontos num único modelo de objetos, com identidade, unidades, qualidade e histórico, e aplique depois um único modelo de alarmes e um único motor de interbloqueios. A diferença revela-se durante as alterações: renomear um ponto num sistema não deve quebrar uma regra noutro. Revela-se também no reporte, onde a mesma métrica tem de significar o mesmo em todos os subsistemas. Um modelo comum também torna mais barato acrescentar um novo subsistema, porque as regras de nomenclatura e de alarme já existem.

Quando um IBMS se justifica

Um IBMS justifica o seu custo quando as decisões atravessam fronteiras entre sistemas: um evento de incêndio que tem de libertar o controlo de acesso, a entrada de um inquilino que deve ativar o AVAC e a iluminação, um campus que precisa de uma visão energética única, uma sala de controlo que supervisiona vários edifícios. Também ajuda quando a responsabilização está distribuída, porque um registo de auditoria comum torna cada ação rastreável. Um edifício único com uma instalação técnica pequena, um operador e poucos sistemas de terceiros normalmente não precisa dessa maquinaria; um BMS bem delimitado, com exportações abertas, é mais fácil de operar. O critério não é a dimensão do edifício, mas o número de decisões acopladas. Se um edifício tem uma sala técnica e uma equipa, um IBMS pode acrescentar custo sem acrescentar qualquer decisão que alguém tenha de tomar.

O risco de entrega está no âmbito, não na tecnologia

A maioria dos problemas de IBMS são problemas de âmbito. Integrar tudo produz integrações superficiais, responsabilidades pouco claras e uma lista de alarmes em que ninguém confia. Comece por uma matriz de subsistemas: linhas para cada sistema, colunas para monitorização, controlo, alarmes, interbloqueios e reporte. Assinale o que está fora do âmbito e porquê. Atribua a interface a uma única parte, indique o protocolo e defina um teste de aceitação para cada linha. Esse documento é mais valioso do que uma demonstração de plataforma, porque perdura até ao comissionamento e à entrega. Também permite ao cliente comparar propostas sem comparar apresentações. Redija-o antes do concurso, não depois da reunião de arranque, e mantenha-o atualizado ao longo das alterações de projeto.

• Linhas: todos os subsistemas, incluindo os explicitamente excluídos
• Profundidade: monitorizar, controlar, alarmar, interbloquear ou reportar
• Interface: protocolo, responsável pelo gateway e mapa de pontos
• Aceitação: o teste que comprova cada linha