IBMS
IBMS — Sistema Integrado de Gestão de Edifícios
O IBMS explicado: como um sistema integrado de gestão de edifícios unifica AVAC, iluminação, controlo de acesso, CCTV, energia e estado do sistema de incêndio numa única visão operacional.
O que significa IBMS
IBMS significa sistema integrado de gestão de edifícios. É uma camada de integração, não uma marca única de controlador. Recolhe dados do BMS e de outros sistemas do edifício, normaliza esses dados num modelo comum e dá aos operadores um único local para ver o estado, confirmar alarmes e emitir comandos. O BMS continua a controlar as instalações; o IBMS coordena entre sistemas e produz relatórios sobre o edifício como um todo. Esta distinção mantém a arquitetura honesta e impede que um projeto de integração se transforme numa substituição não planeada do controlo. Essa fronteira também é relevante do ponto de vista comercial: um IBMS não deve tornar-se uma forma de substituir um BMS funcional sem uma decisão separada. O IBMS deve ser orçamentado e definido como um serviço de integração, não como uma licença com engenharia não especificada. Um âmbito claro nomeia os sistemas, os dados, as regras e os perfis de operador que a plataforma deve suportar.
- Camada de integração acima do BMS
- Modelo comum de dados e de alarmes
- Uma vista única do operador sobre todos os sistemas
- O BMS mantém o controlo das instalações
Subsistemas num único modelo
Um âmbito típico de IBMS inclui AVAC e instalações técnicas, iluminação, sombreamento, controlo de acesso, CCTV, alarme de intrusão, estacionamento, sonorização, elevadores, contadores de energia, controlo de quartos de hotel e estado do sistema de incêndio. Cada subsistema mantém o seu próprio controlador e as suas próprias responsabilidades de segurança. O IBMS lê estados, escreve comandos permitidos e liga eventos entre sistemas. A matriz de integração deve indicar, para cada subsistema, que dados são apenas de leitura, quais são de escrita e qual o fornecedor que continua responsável pelo equipamento. Essa matriz é a definição prática do projeto. Cada subsistema deve ter um responsável identificado, um documento de interface e um modo de falha ensaiado. Os pontos apenas de leitura não são uma limitação; são uma fronteira que protege a segurança e a garantia do subsistema. A matriz deve também registar o sentido dos dados, a taxa de atualização e o comportamento quando a ligação se perde, porque estes três detalhes determinam se o operador pode confiar no ecrã.
- AVAC, iluminação e sombreamento
- Controlo de acesso, CCTV e intrusão
- Estacionamento, elevadores e sonorização
- Energia, quartos de hotel e estado do sistema de incêndio
Alarmes que os operadores conseguem utilizar
Um IBMS recolhe alarmes de sistemas que nunca foram concebidos para os partilhar. Sem racionalização, o resultado é uma parede de ruído. Um modelo de alarmes viável normaliza as descrições, elimina duplicados, hierarquiza os eventos por consequência, encaminha-os para o perfil correto e regista a confirmação e o escalonamento. Uma falha no circuito de água arrefecida, uma porta forçada e uma falha de comunicação de um contador não devem chegar com a mesma prioridade. A filosofia de alarmes é acordada durante o projeto, ensaiada durante o comissionamento e revista após a primeira época de operação. O operador deve poder ver porque é que um alarme foi gerado, e não apenas que existe; o contexto faz parte do alarme. O número de alarmes e os eventos repetidos devem ser revistos, porque um sistema ruidoso treina os operadores para o ignorarem. Uma métrica útil é quantos alarmes exigem ação; se a maioria forem eventos incómodos, o modelo de alarmes precisa de trabalho, não de mais ecrãs.
- Descrições de alarme normalizadas
- Hierarquização por consequência
- Encaminhamento, confirmação e escalonamento
- Revisão de alarmes após a época de operação
Interbloqueios e lógica entre sistemas
O valor de um IBMS manifesta-se quando os sistemas atuam em conjunto. O acesso que abre uma sala pode colocar a iluminação, o AVAC e o CCTV no estado correto. A entrada num parque de estacionamento pode elevar a iluminação na zona de aproximação. Um alarme de incêndio pode libertar portas e parar unidades de tratamento de ar, mantendo o painel de incêndio a autoridade sobre as funções de segurança de pessoas. Os interbloqueios devem ser configurados como regras visíveis, e não como cablagem oculta entre controladores de fornecedores. Cada regra necessita de um acionador, uma condição, uma ação, um tempo limite e um comportamento em caso de falha. Os ensaios provam que a regra funciona, e o registo de auditoria mostra quem a alterou. Uma regra que não pode ser ensaiada não deve ser implementada, porque o edifício acabará por depender dela. As regras entre sistemas devem falhar numa direção definida, deixando normalmente o subsistema afetado no seu estado seguro local. As regras também necessitam de um responsável e de uma data de revisão; caso contrário, acumulam-se e contradizem-se.
- Ligação entre acesso, iluminação e AVAC
- Estacionamento e iluminação de fachada
- Modo de incêndio com autoridade do painel
- Regras visíveis com registos de auditoria
Experiência do operador
Um IBMS é avaliado às 02:00, quando há uma pessoa de turno e algo está errado. A interface deve mostrar o que mudou, onde se situa, o que afeta e o que fazer a seguir. As vistas por perfil mantêm o operador, o engenheiro e a gestão sobre os mesmos dados, mas com níveis de profundidade diferentes. As plantas de piso, as tendências e o histórico de alarmes devem estar acessíveis sem procurar nos menus. O acesso móvel ajuda uma equipa pequena a cobrir um local grande. A formação e a documentação fazem parte do produto, não são um acrescento. Um teste útil consiste em pedir a alguém que não conhece o projeto para executar uma tarefa de rotina sem pedir ajuda. As vistas devem ser concebidas em torno de perfis e tarefas, e não da estrutura de menus do fornecedor. A interface deve também distinguir um valor medido de um valor desatualizado, porque um ecrã que parece em tempo real mas mostra dados antigos é pior do que nenhum ecrã.
- Hierarquia clara e detalhe progressivo
- Vistas e permissões por perfil
- Tendências, plantas de piso e histórico de alarmes
- Formação e documentação do operador
Protocolos abertos e controlo local em primeiro lugar
O IBMS depende de interfaces. O BACnet/IP e o Modbus são comuns para instalações técnicas e contadores, o KNX para iluminação e controlo de sala, o DALI para luminárias, as APIs e o ODBC para sistemas de gestão, e os contactos secos para equipamento que não oferece mais nada. A plataforma deve funcionar na rede local, manter o histórico no local e tratar o acesso remoto como uma opção com autenticação e registo. A segmentação de rede entre OT e IT faz parte do projeto. O proprietário deve poder mudar de integrador sem perder o modelo de pontos, os sinópticos e os dados. A documentação deve incluir o diagrama de rede, o modelo de pontos e a situação das licenças, para que o proprietário não fique vinculado a um único fornecedor. O acesso remoto deve ser revogável sem perturbar a operação local. Local em primeiro lugar não significa isolado: significa que o edifício continua a funcionar quando a ligação de área alargada falha, e que o operador continua a conseguir aceder aos dados no local.
- BACnet, Modbus, KNX e DALI
- APIs e ODBC para sistemas de gestão
- Servidores locais e histórico
- Segmentação e acesso remoto auditado
Arquitetura, redes e cibersegurança
Um IBMS é tanto um projeto de rede como um projeto de controlo. O servidor de integração, os gateways e os clientes dos operadores estão ligados a uma rede segmentada; os serviços do edifício não devem partilhar uma rede plana com a informática de escritório. Uma conceção comum utiliza uma VLAN OT dedicada, uma firewall entre OT e IT e acesso remoto controlado através de VPN ou de um broker com autenticação multifator. A sincronização horária é importante porque os alarmes e as tendências de sistemas diferentes têm de coincidir; sem uma fonte de tempo consistente, a correlação de eventos torna-se adivinhação. O armazenamento do histórico, a cópia de segurança e a reposição devem ser especificados, incluindo o período de retenção dos dados e quem os pode exportar. As contas de utilizador devem provir de um diretório sempre que possível, com permissões baseadas em perfis e um registo de auditoria para comandos e alterações de setpoints. O acesso remoto deve ser revogável sem perturbar a operação local. A cibersegurança não é uma funcionalidade acrescentada no fim; faz parte da arquitetura de integração.
- Segmentação entre OT e IT
- Sincronização horária consistente
- Contas por perfil e registos de auditoria
- Política de cópia de segurança, retenção e acesso remoto
Fases de entrega e modos de falha comuns
A entrega segue uma sequência. Uma auditoria confirma os sistemas, as versões e as interfaces disponíveis. Uma matriz de integração define direitos de leitura e escrita, responsáveis e fronteiras. Um modelo de pontos atribui a cada elemento um nome, uma unidade, uma permissão e uma prioridade de alarme. Os gateways e as interfaces são configurados e ensaiados em fábrica sempre que possível, e depois no local. O comissionamento passa das verificações ponto a ponto para as regras entre sistemas e os ensaios de falha, e termina com um período de acompanhamento em que os operadores utilizam o sistema em condições reais. A documentação inclui o diagrama de rede, o modelo de pontos, a matriz de integração, os registos de ensaio, a situação das licenças e o procedimento de recuperação. Os modos de falha comuns são previsíveis: uma API que foi assumida mas nunca ensaiada, inundações de alarmes que escondem o evento real, dados desatualizados de um gateway, nomes de pontos duplicados, desvio horário entre sistemas e um modelo de licenciamento que impede o proprietário de acrescentar pontos sem o fornecedor original.
- Auditoria e matriz de integração
- Modelo de pontos e ensaio de gateways
- Ensaios entre sistemas e de falha
- Acompanhamento pós-entrega e registos conforme construído
Matriz de integração do IBMS
18 rows| Subsistema | Interface típica | Função do IBMS | Fronteira |
|---|---|---|---|
| AVAC e BMS | BACnet/IP, Modbus, 0–10 V | Horários, setpoints, alarmes, tendências | O BMS mantém o controlo das instalações |
| Iluminação | DALI, KNX, relés | Cenas, ocupação, estado de falha | O controlador de iluminação mantém o controlo local |
| Sombreamento | KNX, Modbus, contactos secos | Regras de sol e vento, cenas | O controlador de motores ou de fachada mantém os limites |
| Controlo de acesso | API, OSDP via controlador, contactos secos | Estado da porta, libertação, ligação de eventos | O sistema de controlo de acesso mantém a lógica de permissões |
| CCTV | ONVIF ou API do fabricante | Mapa de câmaras, ligação de eventos, estado de funcionamento | O VMS mantém a gravação e a retenção |
| Alarme de intrusão | Contactos secos, API | Estado das zonas, eventos de armar/desarmar | Painel de alarme mantém a lógica de deteção |
| Alarme de incêndio | Contactos secos, entradas supervisionadas | Apenas estado, pré-alarme e interligação | A central de incêndio mantém a autoridade sobre a segurança de pessoas |
| Controlo de fumo | Contactos secos, API | Estado e posição da comporta | O sistema de controlo de fumo mantém a sua sequência |
| Estacionamento | API, TCP/IP | Estado de entradas, contagem de lugares e exceções | O sistema de estacionamento mantém o controlo da barreira |
| Sonorização | API, contactos secos | Estado das zonas, mensagens programadas | O sistema de sonorização mantém a sobreposição de emergência |
| Elevadores | Contactos secos, API | Sinais de estado, avaria e alarme | O controlador do elevador mantém a segurança do movimento |
| Contadores de energia | Modbus, M-Bus via gateway, impulsos | Submedição, linhas de base e repartição | O sistema de medição mantém os dados tarifários |
| Contadores de água e de gás | Modbus, M-Bus via gateway, impulsos | Tendências de consumo e alarmes de fuga | A medição de consumos mantém os dados de faturação |
| Carregamento de VE | OCPP, API do fabricante | Estado da sessão, controlo de carga e exceções | O operador do carregador mantém a faturação e a segurança |
| UPS e geradores | SNMP, Modbus, contactos secos | Horas de funcionamento, estado do combustível e eventos de transferência | O sistema de energia mantém a lógica de transferência |
| Quartos de hotel e PMS | API, ODBC, interface RCU | Eventos de check-in/check-out, estado do quarto e limites de energia | O PMS mantém as reservas e a faturação |
| Gestão de visitantes | API, contactos secos | Estado do pré-registo e eventos de porta | O sistema de visitantes mantém a verificação de identidade |
| Análise de dados do edifício e FDD | API do historizador, exportação de base de dados | Deteção de falhas, linhas de base e relatórios de desempenho | A camada de análise mantém os seus modelos |
Imagens do projeto
3 images
Perguntas frequentes
01O que é um IBMS?
Um sistema integrado de gestão de edifícios liga os subsistemas do edifício num único modelo de dados, numa única lista de alarmes e numa única vista para o operador. Acrescenta regras e relatórios transversais aos sistemas, mantendo cada subsistema o seu próprio controlador e as suas responsabilidades de segurança.
02Qual é a diferença entre IBMS e BMS?
Um BMS controla e supervisiona os serviços do edifício, sobretudo AVAC e instalações técnicas. Um IBMS situa-se acima dele e integra o BMS com controlo de acesso, CCTV, estacionamento, energia, quartos de hotel e estado do sistema de incêndio. O BMS continua a ser a camada de controlo.
03Temos de substituir o nosso BMS atual?
Não. A abordagem habitual consiste em integrar o BMS existente através de BACnet, Modbus ou outra interface disponível. A substituição é uma decisão comercial separada, não uma condição prévia para um IBMS.
04Um IBMS pode funcionar sem internet?
Sim. A plataforma de integração e a lógica de controlo devem funcionar na rede local, com o histórico armazenado no local. O acesso à internet é opcional para suporte remoto e relatórios.
05Que protocolos suporta um IBMS?
As interfaces habituais incluem BACnet/IP, Modbus RTU e TCP, KNX, DALI, APIs, ODBC e contactos secos. O conjunto efetivo depende do equipamento instalado e dos gateways selecionados para o projeto.
06Como são tratados os alarmes de incêndio?
O incêndio continua a ser um sistema separado de segurança de pessoas. O IBMS lê os sinais de estado e de pré-alarme através de contactos secos ou entradas supervisionadas e pode acionar interligações definidas, mas a central de incêndio mantém sempre a autoridade.
07Como são priorizados os alarmes?
Os alarmes são normalizados, desduplicados e ordenados por consequência, não por sistema de origem. A filosofia de alarmes define a prioridade, o encaminhamento, a confirmação e a escalada, e é testada durante o comissionamento.
08Um IBMS pode abranger vários edifícios?
Sim. Os controladores locais podem assegurar cada edifício, enquanto uma camada central consolida alarmes, energia e relatórios. O projeto deve definir o que permanece local e o que depende da rede entre locais.
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.