Um grupo de FFUs se apresenta como um problema de controle muito antes de se apresentar como um problema de fluxo de ar. Uma vez que as unidades estejam conectadas em rede a um gateway ou a um sistema de gerenciamento predial, o projeto precisa responder a uma pergunta diferente de “cada unidade está funcionando?” — ele precisa responder “o sistema de controle sabe, sem ambiguidade, qual unidade é qual, a que zona ela pertence e o que acontece quando algo dá errado?” Erros nesse aspecto geralmente não são percebidos durante o comissionamento de uma única unidade; eles só aparecem mais tarde, quando um alarme indica um local que não corresponde mais ao layout da obra concluída, ou quando um comando de zona atinge o grupo errado de unidades.

Mapeie cada endereço de FFU para um local físico e uma zona operacional

Cada FFU em uma rede precisa de um endereço, mas o endereço por si só não fornece ao sistema de controle nenhuma informação sobre onde essa unidade está localizada, o que ela deve fazer ou de quais outras unidades ela depende para uma resposta coordenada. O endereço é um identificador de comunicação; o mapeamento entre esse identificador e o contexto físico e funcional é uma informação separada que precisa ser criada e mantida deliberadamente. Quando esse mapeamento não existe como um registro discreto e consultável, a lógica de controle e o layout real da sala tendem a se distanciar com o tempo, especialmente à medida que as unidades são substituídas, re-cabeadas ou reatribuídas a uma zona diferente durante o ciclo de vida do projeto.

O mapeamento requer pelo menos quatro elementos vinculados a cada endereço: a localização física da unidade, a zona operacional à qual ela pertence, o controlador ao qual ela se reporta e o circuito de alimentação que a abastece. Cada um desses elementos altera a interpretação de um sinal proveniente dessa unidade. Um sinal de status proveniente de uma unidade significa uma coisa se o contexto da zona for conhecido e outra se não for — uma falha relatada sem o contexto da zona indica ao operador que algo está errado, mas não o que esse “erro” significa para o processo que a zona protege. Da mesma forma, conhecer o circuito de alimentação é importante porque uma unidade que fica inativa por um motivo relacionado à fiação não deve ser diagnosticada ou tratada da mesma forma que uma unidade que fica inativa por um motivo relacionado à comunicação, mesmo que ambas possam parecer idênticas do ponto de vista do status em si.

O próprio agrupamento por zonas merece atenção separada do endereço. Duas FFUs podem compartilhar uma sala física e, ainda assim, pertencer a zonas operacionais diferentes se suportarem processos distintos, limites de qualificação diferentes ou requisitos distintos de resposta a falhas. Por outro lado, unidades em salas adjacentes podem pertencer à mesma zona operacional se for esperado que respondam em conjunto a uma única decisão de controle. A atribuição de zonas deve seguir o processo que está sendo protegido, e não o layout físico da rede de dutos ou da fiação, pois o layout físico é uma conveniência de instalação, enquanto a atribuição de zonas é uma decisão de controle com consequências para o comportamento do sistema tanto em operação normal quanto em caso de falha.

Antes do início da programação, esse registro de endereçamento — localização, zona, controlador e circuito de alimentação de cada unidade física — precisa estar disponível como um documento que as equipes de comissionamento e controle possam consultar, e não como informações reconstruídas informalmente a partir de desenhos ou anotações de campo. Confirmar que esse registro existe e que está completo para todas as unidades do grupo é uma pré-condição para todas as etapas subsequentes na configuração do controle.

Definir comandos, sinais de status, alarmes e pontos de tendência para cada interface

Uma vez definidas a identidade de cada unidade e o contexto da zona, a próxima decisão é determinar o que realmente flui através do interface entre os controles da FFU e os sistemas ao seu redor — o controlador da unidade, qualquer gateway e o sistema de gerenciamento predial. Normalmente, quatro categorias de informação precisam ser definidas explicitamente: comandos enviados às unidades, sinais de status retornados por elas, alarmes que exigem uma resposta e valores de tendência ou registrados, mantidos para análise posterior. Tratar esses dados como um único fluxo indiferenciado gera ambiguidade sobre o significado de cada ponto e sobre quem deve agir em função dele.

Comandos e sinais de status não são imagens espelhadas um do outro, embora muitas vezes percorram o mesmo caminho físico. Um comando indica a uma unidade ou zona o que fazer; um sinal de status informa o que está realmente acontecendo. Quando um sistema de controle confunde os dois — por exemplo, ao inferir que um comando foi executado com sucesso em vez de confirmá-lo por meio de um ponto de status independente —, um projeto perde a capacidade de distinguir entre “o sistema solicitou isso” e “o sistema verificou que isso aconteceu”. Essa distinção é mais importante justamente quando algo falha, que é quando ela se torna mais difícil de reconstruir a posteriori, caso não tenha sido incorporada desde o início.

Os alarmes precisam de uma definição própria, distinta do status comum, pois um alarme implica uma resposta obrigatória, enquanto um sinal de status pode ser meramente informativo. Quais condições geram um alarme, em que ponto da lógica de controle esse alarme é acionado e para onde ele é encaminhado são decisões específicas de cada projeto, que dependem de como o processo protegido responde à condição de falha subjacente. Os pontos de tendência, por sua vez, têm uma finalidade diferente: eles são mantidos para análise, em vez de serem acionados em tempo real; portanto, seu valor depende do que é registrado, com qual resolução e por quanto tempo, e não de uma resposta imediata.

A questão da responsabilidade permeia todas as quatro categorias. Para cada item — comando, status, alarme ou tendência —, o projeto precisa saber qual sistema o registra, qual sistema é a fonte oficial e qual sistema o revisor deve consultar caso o valor registrado venha a ser questionado. Definir isso no nível da interface, antes que o plano de controle seja finalizado, evita uma situação em que o mesmo sinal pareça ter origem em dois sistemas, sem que haja um registro acordado sobre qual deles prevalece.

Atribuir responsabilidade entre controladores de unidade, gateways e o BMS

Uma arquitetura de controle com um controlador de unidade, um gateway e um sistema de gerenciamento predial cria três camadas, cada uma das quais pode, com plausibilidade, assumir a responsabilidade por uma determinada decisão ou por um determinado dado. A responsabilidade deve ser atribuída explicitamente, pois a mera existência de um caminho de dados entre as camadas não determina qual delas tem autoridade quando os valores divergem ou quando é necessário emitir um comando.

O controlador da unidade é, normalmente, o que está mais próximo do equipamento físico e possui a visão mais imediata de seu estado operacional real. O gateway, quando existe, traduz e agrega informações entre o controlador da unidade e o BMS e, ao fazer isso, introduz um ponto em que os dados podem sofrer atrasos, ser transformados ou perdidos, caso sua função não esteja claramente delimitada. O BMS está localizado mais distante da unidade física e, normalmente, possui a visão mais abrangente entre as zonas, mas essa visão ampla é tão precisa quanto os dados que recebe por meio das camadas abaixo dele. Nenhuma dessas três posições é automaticamente a “correta” para assumir a responsabilidade por uma decisão específica; quem deve assumir essa responsabilidade depende do que a decisão exige — uma resposta física imediata favorece que a responsabilidade seja assumida perto da unidade, enquanto a coordenação entre zonas favorece que a responsabilidade seja assumida no nível do BMS.

Quando a responsabilidade fica implícita, um sistema de controle pode apresentar comportamentos conflitantes: um comando emitido no nível do BMS pode ser substituído localmente no controlador da unidade sem que haja qualquer registro dessa substituição, ou um gateway pode armazenar temporariamente uma mudança de status por tempo suficiente para que o BMS atue com base em informações desatualizadas. Nenhum desses modos de falha requer que um único componente apresente mau funcionamento — ambos podem ocorrer mesmo com todos os componentes funcionando exatamente conforme projetado, simplesmente porque a atribuição de autoridade nunca foi explicitada para aquele ponto de dados ou para aquele caminho de comando.

Atribuir a responsabilidade também significa decidir o que acontece quando as camadas entram em conflito — se a leitura local do controlador da unidade prevalece, se o gateway tem permissão para substituir por um valor padrão quando não consegue acessar a unidade e se o BMS exibe um valor que ele próprio não pode verificar. Essas decisões devem constar na tabela de controle, juntamente com o registro de endereçamento e as definições de pontos, pois determinam como o restante do sistema se comporta assim que os dados começam a fluir corretamente.

Especifique o comportamento da zona em caso de falhas de comunicação, de alimentação e da unidade

Endereçamento, definições de pontos e atribuições de propriedade descrevem como o sistema deve se comportar em condições normais. O comportamento em caso de falha é uma especificação separada e não pode ser derivado automaticamente da lógica de operação normal — um sistema que funciona corretamente quando todos os componentes estão se comunicando não possui, por si só, um comportamento definido para o que acontece quando uma unidade deixa de se comunicar, perde alimentação ou fica indisponível por qualquer outro motivo.

Três condições de falha se repetem entre os grupos de FFUs: perda de comunicação com uma unidade, falta de energia em uma unidade e uma unidade que simplesmente está indisponível por algum outro motivo. Cada uma delas tem uma causa subjacente diferente, e tratá-las como intercambiáveis resulta em uma resposta de controle que pode ser inadequada para pelo menos uma delas. Uma perda de comunicação não significa necessariamente que o ventilador tenha parado de movimentar o ar; uma perda de alimentação, quase certamente, sim; e uma unidade relatada como indisponível por algum outro mecanismo pode ou não corresponder a qualquer alteração real no fluxo de ar. Como a consequência física difere nesses três casos, a resposta programada da zona não deve, por padrão, adotar um comportamento idêntico para todos os três simplesmente porque todos são “falhas” do ponto de vista do sistema de controle.

O comportamento correto da zona para cada falha depende do processo que a zona protege e da própria avaliação de riscos da instalação, e não de uma configuração padrão geral adequada para todos os projetos. Quando uma zona protege um processo que não pode tolerar nenhuma interrupção no fluxo de ar coordenado, a perda de comunicação de uma única unidade pode precisar acionar um alarme imediato no nível da zona e um comando de contingência definido para as unidades restantes, mesmo antes que a causa subjacente seja confirmada. Quando a zona protege um processo menos sensível, a mesma perda de comunicação pode ser tratada com um alarme retardado, que dá tempo para distinguir um problema transitório de rede de uma falha real da unidade, evitando uma resposta desnecessária em toda a zona a uma condição que se resolve por si só. Nenhuma das abordagens é universalmente correta; cada uma é uma decisão que depende do processo protegido e das consequências de uma resposta falsa em comparação com uma resposta atrasada.

É também aqui que a decisão de zoneamento do projeto, tomada anteriormente ao mapear endereços para zonas operacionais, determina o escopo da resposta à falha. Uma falha em uma unidade atribuída a uma zona estritamente delimitada não deve propagar automaticamente uma resposta para unidades em uma zona adjacente, a menos que o próprio processo exija um comportamento coordenado além desse limite. Especificar esse escopo explicitamente, para cada um dos três tipos de falha, é o que permite que o cronograma de controle defina uma resposta específica, em vez de deixar que o comportamento real seja descoberto somente quando ocorrer uma falha em operação.

Verificar o endereçamento, o roteamento de alarmes e os dados registrados durante a aceitação no local

Todas as decisões tomadas anteriormente — o registro de endereçamento, as definições de pontos, as atribuições de propriedade e o comportamento em caso de falha — constam no papel como o esquema de controle aprovado até que sejam verificadas em relação ao sistema instalado. Aceitação do local É nessa etapa que o projeto confirma se o que foi especificado é realmente o que foi construído e programado, e essa verificação precisa ser feita ponto a ponto, em vez de ser dada como certa apenas pelo fato de o sistema parecer funcionar.

A verificação do endereçamento consiste em confirmar se o endereço de cada FFU física, conforme informado pelo sistema de controle, corresponde efetivamente à localização, zona, controlador e circuito de alimentação registrados no registro. Essa verificação é necessária porque as atividades de instalação e comissionamento — refação da fiação, substituição de unidades ou reetiquetagem — podem romper silenciosamente o mapeamento entre uma unidade física e sua identidade registrada, sem produzir nenhum sintoma visível até que um alarme ou um comando seja direcionado incorretamente.

A verificação dos comandos de zona consiste em testar se um comando emitido para uma determinada zona realmente chega às unidades mapeadas para essa zona — e se é executado por elas —, e apenas por essas unidades. Isso confirma que a decisão de zoneamento tomada durante a etapa de mapeamento de endereços foi corretamente incorporada à lógica programada, e não apenas documentada.

Verificar o roteamento de alarmes significa testar se os caminhos de alarme definidos anteriormente — quais condições geram um alarme e por onde esse alarme é roteado entre os controles da FFU e o BMS — se comportam conforme especificado em uma condição de teste, e não apenas durante a operação normal. Um caminho de alarme que nunca foi testado não oferece garantia de que será roteado corretamente quando ocorrer uma falha real, uma vez que o modo de falha de um caminho de alarme costuma ser silencioso, em vez de óbvio.

Verificar os valores registrados significa conferir se a tendência e os dados registrados disponíveis na interface entre os controles da FFU e o BMS correspondem ao que foi especificado na programação de controle — os pontos corretos, da fonte correta, mantidos de forma que um revisor possa consultá-los posteriormente. Isso fecha o ciclo de volta à atribuição de responsabilidade, já que um valor registrado só é útil se sua fonte oficial tiver sido estabelecida com antecedência. A confirmação dessas quatro áreas em relação ao cronograma de controle aprovado, nesta etapa, é o que permite que o projeto trate o comportamento do sistema de controle como estabelecido, e não como uma suposição, daqui em diante.

Perguntas frequentes

Q: O que precisa ser corrigido antes do início do endereçamento final das FFUs?
A: Defina o identificador de localização física, a zona operacional, o controlador e a relação com o circuito de alimentação para cada unidade no registro de endereçamento. Se alguma dessas atribuições ainda estiver sujeita a alterações, mantenha os endereços afetados como provisórios até que o layout seja definido; caso contrário, um remapeamento posterior poderá desconectar as rotas de alarme e os registros de aceitação da unidade instalada.

Q: É necessário enviar todos os pontos de controle da FFU para o BMS?
A: Não. Selecione os comandos, sinais de status, alarmes e valores de tendência necessários para o plano de operação e monitoramento da instalação e, em seguida, registre a origem, o destino e o responsável por cada ponto selecionado. Uma interface cuja responsabilidade não esteja clara pode fazer com que tanto a equipe de controles da FFU quanto a equipe do BMS presumam que a outra parte irá configurá-la ou verificá-la.

Q: Como o projeto deve definir o comportamento da zona em caso de falha de comunicação, de alimentação ou da unidade?
A: Defina a resposta para cada tipo de falha com base na avaliação de riscos do processo protegido e do local, e registre o comportamento esperado da zona separadamente no plano de controle aprovado. Utilize uma solução alternativa comum somente quando o projeto tiver estabelecido que as diferentes falhas têm a mesma consequência; caso contrário, a resposta pretendida pode ser mantida em sigilo até os testes de aceitação.

Q: O que deve ser acordado entre o fornecedor de sistemas de controle e o integrador de BMS antes da elaboração do orçamento?
A: Forneça o registro de endereçamento e a lista de pontos de interface e, em seguida, atribua a responsabilidade por cada comando, sinal de status, alarme e valor de tendência entre o controlador da unidade, o gateway e o BMS. Resolva os pontos não atribuídos e o comportamento de falha exigido antes que o escopo e o orçamento sejam finalizados, para que o trabalho de comissionamento não fique a cargo de diferentes contratantes.

Q: Como um comprador pode evitar uma aprovação aparente que esconde um erro de integração de controle?
A: Utilize a tabela de controle aprovada como base de aceitação e teste o mapeamento de endereços físicos, os comandos de zona, os caminhos de alarme e os valores registrados de ponta a ponta. Registre o resultado esperado e o observado para cada verificação; uma resposta em tempo real, por si só, é insuficiente quando o endereço, o destino ou o valor armazenado não corresponderem à tabela aprovada.