Por que o BMS e o modelo não se falam?

O BMS e o modelo não se falam. Sensor de um lado, modelo do outro, ninguém no meio.

O edifício tem sensores. Dezenas deles. Temperatura do retorno do chiller, pressão diferencial do filtro da AHU, consumo elétrico por quadro, status de porta de acesso, nível do reservatório superior. Cada um gera dado — frequência que varia de minuto a minuto até hora a hora. Dado bruto, em protocolo industrial (BACnet, Modbus, MQTT, OPC-UA), coletado pelo BMS (do inglês Building Management System — sistema de gerenciamento predial) ou por gateway IoT. O dado existe. O dado é real. O dado é atualizado.

Do outro lado, o modelo BIM entregue no aceite tem a geometria dos mesmos equipamentos, com propriedades estáticas preenchidas: fabricante, modelo, capacidade nominal, tag. O IfcDistributionElement está lá. O IfcSystem agrupando os subsistemas também. O IfcSpace onde cada equipamento opera está definido. O modelo existe. O modelo é rico. O modelo é estático.

O problema é que esses dois mundos não se encontram. O sensor mede a temperatura real do retorno do chiller — mas o modelo não sabe. O BMS detecta que a pressão diferencial do filtro excedeu o limiar — mas o modelo não registra. O gateway IoT publica telemetria via MQTT a cada 30 segundos — e ninguém consome essa mensagem para atualizar uma propriedade ou acionar um evento no modelo. Sensor e modelo vivem em bases de dados separadas, em sistemas separados, operados por equipes separadas, sem canal de comunicação declarado entre eles.

Isso não é falha de sensor. O sensor funciona. Não é falha de modelo. O modelo está correto na data do aceite. É falha de integração: nenhuma camada de comunicação foi projetada para levar o dado do sensor até a entidade correspondente no modelo e atualizar seu estado. Sem essa camada, o gêmeo digital é mentira: tem representação digital (§3.2.2 da ISO 23247-1:2021), tem elemento observável (§3.2.5), mas não tem sincronização (§3.2.3). E sem sincronização, não é gêmeo digital — é modelo estático ao lado de planilha de sensor.

A resposta canônica para esse problema está na ISO 23247-1:2021, framework de gêmeo digital para manufatura cuja Introdução aponta a série ISO 16739 (IFC) como modelagem para edificação e construção. A §5.3.3 (Data collection) trata diretamente da aquisição: sensores podem estar no elemento ou ao redor dele, integrados ou remotos. A §5.3.2 (Communication) exige que o gêmeo esteja conectado ao elemento observável por protocolo que habilite sincronização. A §5.2 (Figura 3) posiciona device communication como a fronteira entre o sistema físico e o gêmeo digital — se essa fronteira não existe operacionalmente, o gêmeo não se alimenta. E a §5.3.5 (Data integrity) exige que o gêmeo descreva corretamente o estado do elemento. Sensor desconectado do modelo viola integridade porque o modelo para de descrever o estado real no momento em que o sensor detecta mudança e o modelo não a reflete.

Em AEC, a representação natural dessa integração é o mapeamento sensor → entidade IFC. O sensor de temperatura do retorno do chiller precisa estar amarrado ao IfcDistributionElement que representa o chiller, agrupado no IfcSystem de climatização, com o IfcSpace servido como destino da telemetria. Sem essa amarração, o dado do sensor é órfão — existe no BMS, não existe no gêmeo.

1. 1

   BMS e modelo vivem em sistemas separados sem canal entre eles · o BMS opera em rede de automação (BACnet/IP, Modbus TCP), o modelo vive no CDE como arquivo IFC. Nenhum middleware, nenhuma API, nenhum webhook conecta os dois.

2. 2

   Dashboard de operação mostra dados de sensor sem referência ao modelo · o painel exibe temperatura, pressão, consumo — mas não identifica qual entidade IFC está sendo medida. O operador vê o dado mas não vê o ativo no modelo.

3. 3

   Sensor instalado sem GlobalId correspondente · o sensor foi comissionado com tag do BMS (ex.: AHU-01.TMP.RET) mas ninguém amarrou esse tag ao GlobalId do IfcDistributionElement correspondente no modelo.

4. 4

   Modelo BIM nunca recebeu dado de sensor desde o aceite · o modelo entregue tem propriedades estáticas (capacidade nominal, fabricante, modelo) mas nenhuma propriedade dinâmica alimentada por telemetria.

5. 5

   Equipe de automação e equipe de BIM nunca se reuniram · o integrador de automação instalou sensores seguindo escopo próprio. O projetista BIM modelou seguindo BEP. Ninguém coordenou nomenclatura, protocolo nem mapeamento.

6. 6

   Telemetria publicada via MQTT sem consumidor no lado do modelo · o gateway IoT publica tópicos (edif/01/andar/03/ahu/01/tmp/ret) a cada 30 segundos. Ninguém assina esses tópicos para atualizar o modelo.

7. 7

   Manutenção preditiva impossível por falta de histórico vinculado ao ativo · o histórico de medições existe no BMS, mas não está vinculado ao IfcDistributionElement do ativo. Análise de tendência exige exportar CSV e cruzar manualmente.

8. 8

   Ordem de serviço aberta com base em alarme do BMS sem referência ao modelo · o BMS gera alarme, o operador abre OS no CMMS descrevendo o problema em texto livre. Ninguém referencia o GlobalId do ativo — o modelo não entra no fluxo.

9. 9

   Frequência de sincronização nunca definida · ninguém declarou se o modelo deveria ser atualizado a cada evento de mudança de estado ou em intervalos regulares (§5.3.13 da ISO 23247-1:2021). Sem frequência, não há SLA.

10. 10

    IfcSensor não presente no modelo entregue · o modelo tem IfcDistributionElement para equipamentos mas não modelou os sensores como entidades próprias — o sensor não existe no modelo, só no BMS.

1. 1

   Protocolo de comunicação entre sensor e modelo nunca declarado · a §5.3.2 (Communication) da ISO 23247-1:2021 exige protocolo que habilite sincronização entre elemento observável e gêmeo. O BMS tem protocolo (BACnet, Modbus). O modelo tem formato (IFC). Mas ninguém declarou o protocolo que conecta os dois — o middleware, a API, o broker MQTT que faz a ponte. Sem protocolo declarado, a ponte não existe.

2. 2

   Sensor tratado como infraestrutura predial, não como fonte de dado do gêmeo · o sensor foi especificado pela engenharia de automação para controle do BMS — ligar/desligar equipamento, abrir/fechar válvula. Nunca foi tratado como fonte de dado para alimentar o gêmeo digital. A §5.3.3 (Data collection) da norma distingue sensor integrado ao elemento de sensor remoto — ambos são fontes válidas, mas nenhum alimenta o gêmeo se o canal não é projetado.

3. 3

   Mapeamento sensor → entidade IFC inexistente · cada sensor no BMS tem um tag (ex.: AHU-01.TMP.RET). Cada ativo no modelo tem um GlobalId. Ninguém produziu a tabela de correspondência tag↔GlobalId. Sem mapeamento, o dado do sensor não sabe para qual entidade do modelo deve fluir.

4. 4

   Frequência de aquisição não alinhada entre sensor e modelo · o sensor mede a cada 30 segundos. O modelo é atualizado nunca. A §5.3.3 estabelece que a aquisição pode ser contínua ou periódica, mas exige declaração. Sem declarar a frequência com que o modelo incorpora os dados do sensor, a integração não tem cadência — e sem cadência, não opera.

5. 5

   IfcSpace como destino da telemetria não mapeado · em AEC, o dado do sensor geralmente descreve o estado de um espaço (temperatura do ambiente, ocupação, luminosidade) ou de um equipamento que serve um espaço. O IfcSpace é o destino natural da telemetria. Se o modelo não tem IfcSpace definido ou não tem relação IfcRelServicesBuildings ligando sistema a espaço, o dado do sensor não tem onde pousar no modelo.

6. 6

   Integridade do gêmeo violada por omissão · a §5.3.5 (Data integrity) exige que o gêmeo descreva corretamente o estado do elemento observável. Quando o sensor detecta que o chiller está em falha e o modelo continua mostrando status nominal, o gêmeo viola integridade. Não é erro de dado — é ausência de canal para levar o dado correto ao lugar correto.

1. 1

   Gêmeo digital que não reflete a realidade em tempo real · modelo mostra estado nominal do aceite. Sensor mostra estado real da operação. Quando divergem — e divergem sempre —, o gêmeo mente. Decisão baseada no gêmeo é decisão baseada em ficção.

2. 2

   Manutenção preditiva impossível · análise preditiva exige série temporal vinculada ao ativo. Sem integração sensor→modelo, a série temporal vive no BMS isolada do contexto do ativo (localização, sistema, especificação). Modelo de machine learning treinado sem contexto dá resultado sem sentido.

3. 3

   Alarme sem contexto espacial nem funcional · BMS gera alarme "sensor 347 — temperatura alta". Operador pergunta: onde fica? Que equipamento é? Que espaço serve? Sem amarração ao modelo, cada alarme exige investigação manual. Tempo de resposta sobe, risco operacional cresce.

4. 4

   Duplicação de esforço entre equipes · equipe de automação mantém cadastro de ativos no BMS. Equipe de facilities mantém cadastro no CMMS. Equipe de BIM mantém cadastro no modelo. Três cadastros do mesmo ativo, sem sincronização, divergem progressivamente.

5. 5

   ROI do gêmeo digital não se materializa · o caso de negócio do gêmeo prometia otimização energética, redução de downtime, manutenção preditiva. Sem integração sensor→modelo, nenhuma dessas promessas se concretiza. Investimento vira custo afundado.

6. 6

   Compliance operacional comprometido · certificações como LEED O+M, WELL Performance e ISO 50001 exigem evidência de monitoramento contínuo vinculado ao ativo. Sensor desconectado do modelo não gera evidência estruturada — gera CSV avulso que auditor pode rejeitar.

Curto prazo (30 dias):

1. Inventariar pontos de medição. Exportar a point list do BMS: cada sensor, seu tag, o equipamento que mede, a grandeza (temperatura, pressão, status), a frequência de leitura. Cruzar com a lista de IfcDistributionElement do modelo. Identificar correspondências e lacunas.

2. Produzir tabela de mapeamento tag↔GlobalId. Para cada sensor ativo, documentar: tag do BMS, GlobalId do IfcDistributionElement correspondente, grandeza medida, unidade, frequência. Publicar no CDE como artefato versionado.

3. Definir protocolo de comunicação. Reunir integrador de automação, BIM Manager e fornecedor de plataforma de gêmeo. Escolher o canal: API REST, broker MQTT, OPC-UA. Documentar decisão com justificativa técnica.

Médio prazo (60-90 dias):

4. Implementar piloto com 5 sensores críticos. Selecionar sensores de ativos críticos (chiller, AHU principal, bomba de recalque, quadro elétrico geral, medidor de energia). Implementar fluxo completo: sensor → BMS → middleware → modelo. Validar que o modelo reflete estado real em frequência declarada.

5. Declarar frequência de sincronização formalmente. Registrar no contrato ou no BEP: sincronização event-based, time-based ou ambas. Definir SLA de latência máxima. Sem declaração formal, sincronização é voluntária.

6. Modelar sensores como entidades IFC. Incluir IfcSensor ou IfcDistributionControlElement no modelo para cada sensor do piloto. Associar ao IfcDistributionElement que mede via IfcRelNests ou IfcRelConnectsPortToConnector. Manter relação IfcRelServicesBuildings ao IfcSpace servido.

7. Implementar verificação de integridade automatizada. Criar rotina que compara estado do sensor (via BMS) com estado no modelo a cada ciclo de sincronização. Divergência gera alerta no CDE. Sem verificação, degradação silenciosa é inevitável.

1. 1

   Integrador de automação no kickoff do BEP · nenhum projeto que prevê gêmeo digital começa sem o integrador de automação na mesa desde o BEP. Nomenclatura de sensores, protocolo de comunicação e mapeamento sensor→entidade IFC são definidos antes da modelagem, não depois.

2. 2

   Point list do BMS como entregável contratual · a lista de pontos de medição do BMS é entregável contratual do integrador de automação, com tag, grandeza, unidade, frequência e GlobalId do IfcDistributionElement correspondente. Sem point list cruzada, sem aceite.

3. 3

   Protocolo de comunicação declarado antes da instalação de sensor · o canal que conecta sensor ao modelo (API REST, MQTT, OPC-UA) é declarado formalmente antes da instalação do primeiro sensor. Sensor instalado sem canal é dado perdido.

4. 4

   Frequência de sincronização como cláusula contratual · event-based ou time-based, com SLA de latência máxima. Sem frequência declarada em contrato, ninguém é auditável e a sincronização morre por inanição.

5. 5

   Verificação de integridade periódica · rotina trimestral que amostra sensores ativos, compara estado no BMS com estado no modelo e documenta fidelidade. Fidelidade abaixo de 95% aciona correção contratada.

• ISO 23247-1:2021 §5.3.3Data collection — aquisição de dados do elemento observável. Sensores podem estar no elemento (integrados) ou ao redor dele (remotos). Ambos são fontes válidas de dado para o gêmeo, desde que o canal de comunicação esteja projetado.
• ISO 23247-1:2021 §5.3.2Communication — o gêmeo digital deve estar conectado ao elemento observável por protocolo que habilite sincronização. Sem protocolo declarado (BACnet, MQTT, OPC-UA, REST API), não há sincronização.
• ISO 23247-1:2021 §5.2Limitations and boundaries — Figura 3 posiciona device communication como fronteira entre o sistema físico (com sensores) e o gêmeo digital. Se essa fronteira não existe operacionalmente, o gêmeo não se alimenta de dado real.
• ISO 23247-1:2021 §3.1.9Sensor — dispositivo que detecta evento ou mudança no ambiente e envia informação a outro dispositivo eletrônico. Definição normativa da fonte de dado primária do gêmeo.
• ISO 23247-1:2021 §3.1.5Internet of Things (IoT) — rede de objetos físicos com sensores, software e conectividade que permite coletar e trocar dados. Base tecnológica da aquisição distribuída.
• ISO 23247-1:2021 §5.3.5Data integrity — o gêmeo digital deve descrever corretamente o estado do elemento observável. Sensor que detecta falha enquanto o modelo mostra estado nominal viola integridade.
• ISO 23247-1:2021 §5.3.13Synchronization — método de atualização entre elemento e gêmeo: event-based (a cada mudança de estado) ou time-based (leitura contínua de stream com timestamp). Base normativa da frequência de integração sensor→modelo.
• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes. Define IfcDistributionElement, IfcSystem, IfcSpace, IfcSensor e IfcDistributionControlElement como entidades de representação de ativos, sistemas, espaços e sensores em AEC. Destino natural da telemetria no modelo.
• ABNT NBR ISO 19650-3:2022Fase operacional dos ativos. Define AIR e AIM. A integração sensor→modelo é parte do AIM vivo — sem ela, o AIM é estático e não reflete operação real.