BAS vs BMS — onde fica a fronteira de controlo

Porque é que os termos são usados indiferentemente

Num único edifício com um só fornecedor, o mesmo software desempenha frequentemente ambas as funções, pelo que os compradores ouvem os dois termos aplicados ao mesmo pacote. Isso é razoável até o edifício crescer. Quando existem várias salas técnicas, inquilinos, contadores e sistemas de terceiros, a supervisão torna-se uma atividade distinta, com os seus próprios utilizadores, modelo de dados e obrigações de reporte. A nomenclatura só é relevante quando esconde essa distinção durante a aquisição. A pergunta útil não é qual a sigla correta, mas sim que funções estão incluídas, quem é responsável por cada uma e o que acontece quando um controlador ou um servidor falha. Um pacote de fornecedor único pode ser perfeitamente sólido; o risco está num contrato pouco claro, não na forma como o pacote é composto.

O que muda à escala

À escala, o BMS torna-se a visão única do operador para vários edifícios. Normaliza dados de fornecedores diferentes, aplica prioridades de alarme comuns e compara o desempenho energético entre locais. Isso exige decisões que um BAS isolado não impõe: convenções de nomenclatura, retenção de histórico, perfis de acesso e um processo de controlo de alterações. Também altera o modelo de manutenção, porque a equipa que repara um controlador não é sempre a equipa responsável pela camada de reporte. Separar as funções torna essas responsabilidades visíveis no contrato, na lista de pontos e no dossiê de entrega. A lista de pontos e a filosofia de alarmes são os dois elementos que tornam essa separação real. Um teste útil é perguntar quem é chamado às 02:00 quando um alarme se repete em três sistemas.

Como especificar a separação

Redija uma matriz de responsabilidades antes do preço. Indique que sequências são executadas localmente, que horários são editáveis no BMS e como é auditada uma alteração de setpoint. Confirme que o BAS se mantém autónomo se a rede de supervisão falhar e que o BMS pode exportar o histórico num formato aberto na entrega. Acorde desde cedo a convenção de nomenclatura de pontos e a filosofia de alarmes, porque ambas sobrevivem à equipa do projeto. Uma separação clara é mais barata do que resolver litígios durante o comissionamento e dá a todos os concorrentes a mesma base de comparação. A matriz deve ser uma tabela com uma linha por função, não um parágrafo de intenções. Reveja-a em todas as fases de projeto, porque o âmbito de integração cresce silenciosamente.

• Sequências locais: o que tem de funcionar sem o BMS
• Horários: quem os pode editar e com que limites
• Alarmes: prioridade, encaminhamento e responsabilidade pela confirmação
• Histórico: período de retenção e formato de exportação