Entenda PIM e AIM em profundidade: ISO 19650, requisitos de informação, handover, COBie, Asset Register, sistemas de registro, CMMS, Facility Management e governança do ativo.
Confira!
PIM e AIM são dois modelos de informação com finalidades diferentes ao longo do ciclo de vida de um ativo. O Project Information Model (PIM) suporta a fase de entrega — projeto, coordenação, contratação, construção, testes e entrega — enquanto o Asset Information Model (AIM) suporta a gestão e a operação do ativo. A diferença não está em usar outro software ou outro formato de arquivo, mas em mudar a finalidade, os usuários, as decisões suportadas, os requisitos e a governança da informação.
Essa distinção é importante porque um empreendimento pode terminar a obra com milhares de documentos, modelos e registros e ainda assim iniciar a operação sem informação utilizável. Projetos geram grande volume de conhecimento, porém a operação necessita apenas de parte desse conteúdo e, ao mesmo tempo, necessita de informações que frequentemente surgem depois do projeto: fabricante efetivamente instalado, número de série, garantia, data de entrada em operação, resultado de testes, configuração final, plano de manutenção, criticidade, documentos do fornecedor e vínculos com sistemas operacionais.
O handover, portanto, não deveria ser tratado como uma transferência de pastas ou uma cópia integral do PIM para um repositório de operação. Ele é uma transição controlada de informação, na qual dados são selecionados, reconciliados com a condição instalada, validados contra requisitos do ativo, conectados a identificadores persistentes e encaminhados aos sistemas que passarão a mantê-los. O que não possui valor operacional pode permanecer como registro do projeto; o que possui valor precisa chegar à operação com qualidade demonstrável.
Esse processo conecta a série ISO 19650, requisitos OIR/AIR/PIR/EIR, LOIN, CDE, COBie, comissionamento, as-built, BIM 7D, Facility Management, CMMS/EAM, gestão de ativos e Digital Twin. Quanto mais cedo o proprietário ou operador define as decisões que dependerão da informação, menor é o custo de reconstruir cadastros depois da entrega e maior é a chance de o AIM começar sua vida como uma fonte confiável de contexto para o ativo.
PIM e AIM são modelos de informação, não arquivos BIM
A primeira distinção necessária é entre information model e modelo geométrico. Um modelo de informação pode combinar múltiplos information containers: modelos disciplinares e federados, desenhos, documentos, bases estruturadas, registros, especificações, relatórios, listas de ativos, evidências de testes, fotografias, certificados e outros conjuntos de informação relacionados a uma finalidade.
O que caracteriza o PIM
O PIM é orientado à fase de entrega. Seu conteúdo é produzido e organizado para desenvolver, coordenar, verificar, contratar, construir e entregar o empreendimento. Ele pode conter informações que nunca terão utilidade operacional, mas que foram necessárias para uma decisão de projeto ou para demonstrar conformidade durante a execução.
| Elemento do PIM | Uso típico durante a entrega | Deve necessariamente ir ao AIM? |
| modelos disciplinares | autoria e desenvolvimento técnico | não integralmente |
| modelo federado | coordenação e análise de interfaces | apenas se tiver uso operacional definido |
| desenhos e especificações | contratação e execução | somente versões relevantes ao ativo entregue |
| relatórios de clash/BCF | coordenação e resolução de issues | normalmente como registro, não como dado operacional ativo |
| quantitativos e estudos | orçamento e decisão de projeto | somente quando houver uso posterior |
| submittals de fornecedores | validação técnica | sim, quando vinculados a ativos mantidos |
| registros de mudança | rastreabilidade | sim, quando explicam a configuração final |
| as-built | condição entregue | normalmente é uma fonte crítica para o AIM |
O PIM muda intensamente. Alternativas são criadas e descartadas, modelos são revisados, especificações são substituídas e decisões evoluem. Essa volatilidade é normal para a fase de entrega, mas não deve ser transferida indiscriminadamente à operação.
O que caracteriza o AIM
O AIM é orientado à gestão do ativo. Seu conteúdo precisa responder perguntas operacionais: o que existe, onde está, qual sua função, como foi configurado, quais documentos se aplicam, quem é responsável, quando precisa ser mantido, que mudanças ocorreram e quais riscos ou requisitos estão associados.
| Dimensão do AIM | Exemplos de informação |
| identidade | asset tag, código patrimonial, GUID, identificador corporativo |
| localização | site, edifício, pavimento, sala, coordenada ou zona |
| classificação | sistema, disciplina, classe do ativo, criticidade |
| configuração | tipo, fabricante, modelo, capacidade, parâmetros e setpoints |
| ciclo de vida | fabricação, instalação, comissionamento, garantia, substituição |
| documentação | manuais, certificados, desenhos, relatórios, fichas técnicas |
| manutenção | periodicidades, tarefas, estratégia, recursos e histórico |
| condição e desempenho | inspeções, falhas, medições e indicadores |
| relações | sistema ao qual pertence, upstream/downstream, espaços atendidos |
| governança | owner do dado, sistema de registro, status, versão e última validação |
A ISO 19650-3 estrutura a gestão da informação na fase operacional. Isso reforça que o AIM não é um produto entregue uma única vez: ele é uma capacidade de informação que precisa continuar sendo atualizada conforme o ativo sofre manutenção, substituições, ampliações, mudanças de uso e novos projetos.
PIM e AIM podem coexistir
A transição não é necessariamente um instante único. Durante a execução, o PIM pode continuar evoluindo enquanto partes da informação de ativos já são preparadas, validadas ou incorporadas ao ambiente operacional. Em ampliações de um ativo existente, um AIM já existente também pode fornecer informação de entrada para um novo PIM; ao final desse novo projeto, informações validadas retornam para atualizar o AIM.
Isso cria um ciclo, e não uma seta simples:
AIM existente → requisitos e informação de partida → novo PIM → execução e comissionamento → informação validada → atualização do AIM.
O as-built não é o AIM
As-built descreve a condição executada em determinado nível de documentação. AIM é mais amplo. Ele pode usar o as-built como fonte, mas também precisa de informação não geométrica, regras de governança, registros operacionais e conexão com sistemas que continuarão mudando durante a vida do ativo.
Confundir as-built com AIM cria um problema recorrente: entrega-se um modelo atualizado geometricamente, porém números de série, garantias, vínculos documentais, planos de manutenção e identificadores corporativos continuam faltando.
As-built não é AIM. A condição executada é uma fonte essencial, mas o modelo de informação do ativo precisa acrescentar identidade, documentação, relações, governança e informação necessária à operação.
Requisitos de informação determinam o que pertence ao PIM e ao AIM
PIM e AIM não devem ser montados por acumulação. A lógica correta começa pelas decisões que precisam ser suportadas e deriva delas os requisitos de informação.
OIR conecta informação aos objetivos da organização
Os Organizational Information Requirements (OIR) descrevem necessidades de informação associadas aos objetivos e funções da organização. Uma empresa pode precisar conhecer risco de indisponibilidade, capacidade instalada, custo de ciclo de vida, consumo energético, estado de garantias, ocupação de espaços ou exposição regulatória. Esses objetivos ajudam a determinar que informação dos ativos precisa existir e ser confiável.
AIR define o que a gestão do ativo precisa saber
Os Asset Information Requirements (AIR) transformam necessidades organizacionais em requisitos relacionados aos ativos. Eles são decisivos para o AIM porque especificam quais dados, documentos e relações serão necessários na operação.
Um AIR útil não pede “todos os dados disponíveis”. Ele relaciona informação a decisões e processos.
| Decisão operacional | Informação necessária | Possível sistema consumidor |
| programar preventiva | ativo, classe, criticidade, tarefa, periodicidade | CMMS/EAM |
| controlar garantia | fabricante, modelo, série, início/fim, condições | CMMS/ERP/documental |
| localizar equipamento | identificador, espaço, sistema e posição | AIM/CAFM/IWMS/BIM |
| avaliar substituição | idade, falhas, manutenção, desempenho e custo | EAM/BI/gestão de ativos |
| investigar falha | configuração, histórico, documentos e relações | CMMS/AIM/CDE |
| planejar reforma | condição atual, espaço, interfaces e documentação | AIM/PIM/CDE |
| auditar conformidade | certificados, inspeções, datas e evidências | GED/CDE/CMMS |
Essa abordagem reduz duas perdas opostas: excesso de informação sem uso e ausência do dado necessário no momento da operação.
O AIM deve ser derivado de decisões operacionais, não de tudo o que o projeto consegue produzir. OIR e AIR ajudam a transformar necessidade real em requisito de informação verificável.
PIR organiza as necessidades do projeto
Os Project Information Requirements (PIR) estabelecem o que a organização precisa saber para conduzir decisões de um projeto específico. Eles podem gerar informação que pertence somente à fase de entrega — alternativas de solução, estudos temporários, análises de construtibilidade — e informação que precisa sobreviver ao projeto porque será utilizada na operação.
EIR transforma necessidade em obrigação de troca
Os Exchange Information Requirements (EIR) especificam informação a ser trocada nos appointments e marcos. Eles conectam requisitos às equipes responsáveis pela produção e precisam declarar conteúdo, formato, momento, critérios de aceitação e responsabilidades.
Um requisito de handover que diga apenas “entregar BIM as-built” é insuficiente. A equipe precisa saber quais ativos devem possuir cadastro, quais propriedades são obrigatórias, como os documentos serão vinculados, quais identificadores devem ser preservados, qual formato será aceito e como a operação verificará o resultado.
LOIN evita modelagem excessiva e dados insuficientes
O nível de informação necessária deve ser definido conforme a finalidade. Ativos críticos podem exigir propriedades, documentação e relações muito mais completas que componentes sem necessidade de manutenção individual. Aplicar o mesmo nível de informação a todos os objetos aumenta custo sem aumentar necessariamente o valor do AIM.
Uma matriz de requisitos pode combinar classe de ativo × marco × uso × informação geométrica × informação alfanumérica × documentação. Essa estrutura permite planejar progressivamente o que deverá ser produzido e quando cada campo passa a ser exigível.
A transição PIM → AIM precisa ser tratada como processo de engenharia
O handover é o ponto em que qualidade de informação passa a afetar diretamente manutenção e operação. Por isso, a transição deve possuir critérios de prontidão, evidências e aceite, da mesma forma que outros entregáveis técnicos.
Nem tudo do PIM deve sobreviver
Conteúdo temporário pode ter valor histórico ou contratual sem integrar o AIM operacional. Estudos rejeitados, versões intermediárias, simulações sem uso futuro, objetos auxiliares e registros de coordenação resolvidos podem permanecer no arquivo do projeto sem ocupar a camada ativa de informação do ativo.
A decisão deveria responder a três perguntas:
- essa informação suporta alguma decisão, obrigação ou processo operacional?
- precisa permanecer acessível como registro, mas não como dado operacional ativo?
- existe outra fonte autoritativa mais adequada para mantê-la?
Nem tudo do AIM nasce no projeto de design
Grande parte dos atributos mais importantes para manutenção só pode ser conhecida depois da compra e instalação. Um projeto pode especificar “bomba centrífuga 30 m³/h”, enquanto o AIM precisa saber qual unidade foi realmente comprada e instalada, seu fabricante, modelo, serial, data de partida, garantia, motor associado, configuração final e documentação específica.
Isso significa que procurement, fornecedores, execução e comissionamento são produtores de informação do AIM. Se o contrato só cobra dados no encerramento, a organização perde a oportunidade de validar progressivamente a qualidade e acaba reconstruindo cadastros em um momento de alta pressão por entrega.
Asset Register deve ser definido antes da coleta em escala
Antes de exigir dezenas de propriedades, é necessário decidir o que é um ativo controlado individualmente. Nem todo objeto BIM precisa receber asset tag ou existir como item no CMMS.
Critérios comuns incluem manutenção individual, criticidade, garantia, reposição, obrigação legal, necessidade de inspeção, valor relevante, risco operacional ou necessidade de histórico próprio.
| Elemento | Tratar como ativo individual? | Justificativa típica |
| UPS | sim | criticidade, manutenção, garantia e histórico |
| câmera IP | frequentemente sim | serial, manutenção, firmware e localização |
| luminária comum | depende da estratégia | pode ser mantida por lote/área |
| válvula de bloqueio crítica | frequentemente sim | isolamento e manutenção |
| parafuso ou conexão | normalmente não | ausência de processo operacional individual |
| detector de incêndio | depende do sistema e requisitos | inspeção e identificação podem exigir controle unitário |
Essa decisão antecede COBie, CMMS ou qualquer formato de cadastro. Caso contrário, a organização digitaliza uma taxonomia de ativos que nunca foi definida.
Identidade persistente é a espinha dorsal da transição
Um mesmo equipamento pode aparecer em modelo BIM, planilha de procurement, relatório de comissionamento, CMMS, ERP e BMS. Se cada sistema usa um identificador diferente sem mapeamento governado, a informação se fragmenta.
A estratégia de identificação precisa definir identificadores primários, aliases e regras de mudança. GUID de IFC ou identificador interno do software podem ser úteis, mas não devem ser presumidos como a única chave corporativa. O importante é que a organização consiga reconciliar inequivocamente registros entre sistemas.
Sem identidade persistente, não existe continuidade informacional. BIM, procurement, comissionamento, CMMS e ERP precisam conseguir reconhecer o mesmo ativo mesmo quando usam sistemas e identificadores técnicos diferentes.
Reconciliar projeto, procurement e condição instalada
A transição deve tratar divergências entre especificado, comprado, instalado, testado e aceito. A cadeia pode ser representada assim:
| Estado | Pergunta de controle |
| projetado | o que foi previsto tecnicamente? |
| aprovado | qual fornecedor/produto foi aceito? |
| comprado | qual item foi efetivamente adquirido? |
| instalado | qual unidade está fisicamente no local? |
| configurado | quais parâmetros e ajustes foram aplicados? |
| testado | quais resultados demonstram desempenho? |
| aceito | quais pendências ou ressalvas permanecem? |
| operacional | qual sistema passa a manter o registro? |
O AIM confiável precisa refletir o estado aceito, não apenas o estado previsto em projeto.
Comissionamento completa informação que o modelo não produz sozinho
Testes funcionais e integrados podem gerar setpoints, curvas, resultados, evidências, configurações, certificados, listas de pendências e condições de aceite. Quando esses elementos são necessários para manutenção ou operação, precisam ser associados aos ativos e sistemas correspondentes.
Comissionamento, portanto, não é apenas uma etapa física anterior à entrega; é uma fonte de informação operacional.
COBie pode estruturar parte da transferência
COBie pode organizar dados de facilities, espaços, tipos, componentes, sistemas, documentos, garantias e outras informações de handover. Ele é útil quando o contrato e os sistemas de destino adotam essa estrutura, mas não deve ser confundido com o AIM completo.
O AIM é mais amplo e pode ser realizado por diferentes combinações de sistemas e information containers. COBie é um mecanismo estruturado de intercâmbio e pode ser uma das entradas usadas para construir ou atualizar esse ambiente.
A operação precisa realizar aceite de informação
A validação do AIM não pode se limitar a verificar se um arquivo abre ou se campos estão preenchidos. É necessário testar se a informação serve ao processo real.
Uma bateria de aceite pode verificar localização de ativos, códigos, relacionamentos, documentos, garantias, importação para CMMS, associação de planos de manutenção, acesso por usuários, consultas de sistemas, rastreabilidade de alterações e capacidade de recuperar evidências.
O indicador mais importante é simples: a equipe operacional consegue trabalhar com os dados sem reconstruí-los manualmente?
AIM é uma arquitetura governada, não necessariamente um único sistema
Na prática, informações do ativo ficam distribuídas. A ISO 19650-3 admite que o AIM seja realizado por uma combinação de sistemas novos e existentes adequadamente conectados e governados. Isso é mais realista que imaginar um único software contendo toda a verdade operacional.
Defina systems of record por domínio de informação
O conceito de system of record ajuda a decidir qual plataforma é autoritativa para cada classe de dado.
| Domínio | Fonte autoritativa possível | Sistemas consumidores |
| cadastro técnico do ativo | EAM/CMMS ou master data de ativos | BIM, BI, mobile, ERP |
| documentos controlados | CDE/GED | CMMS, BIM, portal técnico |
| geometria e localização espacial | AIM/BIM/GIS | manutenção, engenharia, emergência |
| ordens e histórico de manutenção | CMMS/EAM | BI, gestão de ativos |
| custo e cadastro financeiro | ERP | EAM, BI |
| telemetria | BMS/SCADA/historian/IoT | Digital Twin, BI, manutenção |
| ocupação e espaços | CAFM/IWMS | FM, BIM, BI |
| configuração de automação | sistema de controle + documentação | manutenção, engenharia |
Nenhuma arquitetura é universal. O importante é declarar quem mantém cada dado e como os demais sistemas o consomem.
O AIM não precisa morar em um único software. O requisito é governança: cada domínio de informação precisa ter fonte autoritativa, owner e regra de integração com os demais sistemas.
AIM não é sinônimo de CDE
O CDE pode controlar documentos, modelos e estados da informação, mas muitos dados operacionais possuem sistemas especialistas. Ordens de serviço, históricos de falha, telemetria ou movimentações patrimoniais podem não pertencer ao CDE como fonte principal.
O CDE continua importante como mecanismo de governança e acesso a information containers, porém a arquitetura precisa reconhecer que a operação é heterogênea.
AIM não é sinônimo de CMMS ou EAM
CMMS/EAM executa processos de manutenção e gestão do ativo: planos, ordens, histórico, recursos, custos, falhas, backlog e indicadores. Ele pode armazenar uma parte significativa dos dados do AIM, mas normalmente não substitui modelos, desenhos, documentos complexos, registros espaciais ou outros sistemas especializados.
A melhor integração evita duplicar dados sem necessidade. Em vez de copiar manuais para vários sistemas, por exemplo, o CMMS pode manter um vínculo controlado para o documento oficial no repositório corporativo.
AIM não é sinônimo de BIM 7D
“BIM 7D” é uma denominação de mercado para usos ligados à operação, manutenção e Facility Management. AIM é um conceito formal de gestão da informação dentro da série ISO 19650. Um projeto pode usar BIM 7D como linguagem comercial ou funcional e, ao mesmo tempo, estruturar o AIM com requisitos e governança consistentes.
AIM não é Digital Twin
Um Digital Twin normalmente adiciona sincronização com o estado real, telemetria, eventos, análises ou modelos de comportamento para suportar casos de uso específicos. Um AIM pode existir sem Digital Twin e continua essencial porque fornece identidade, contexto, documentação e relações necessárias para conectar dados em tempo real a um ativo conhecido.
Um twin construído sem cadastro confiável apenas associa medições a entidades mal governadas.
Facility Management e gestão de ativos usam o AIM de formas diferentes
Facility Management pode utilizar informação de espaços, serviços, ocupação, contratos e desempenho do ambiente construído. Gestão de ativos pode focar valor, risco, desempenho e ciclo de vida. Manutenção pode focar tarefas, falhas e disponibilidade. O mesmo AIM pode suportar esses processos desde que os requisitos tenham sido estruturados para eles.
Qualidade, mudança e governança mantêm o AIM confiável depois do handover
Um AIM pode estar correto no dia da entrega e ficar obsoleto em poucos meses se a organização não possuir processo de atualização. A fase operacional é dinâmica: equipamentos falham, são substituídos, parâmetros mudam, espaços são reformados e novos projetos alteram a configuração do ativo.
Trigger events devem iniciar processos de informação
A gestão operacional precisa definir eventos que exigem revisão ou atualização de information containers. Exemplos incluem substituição de equipamento, modificação de setpoint crítico, reforma, mudança de ocupação, manutenção que altera configuração, atualização regulatória, incidente, expansão ou novo projeto.
| Trigger event | Atualizações possíveis |
| substituição de equipamento | tag, serial, fabricante, modelo, garantia, documentos, modelo |
| reforma de ambiente | geometria, espaço, ativos, documentação e classificação |
| alteração de automação | lógica, setpoints, narrativa, telas e documentação |
| manutenção relevante | condição, configuração, evidência e histórico |
| novo projeto | criação de PIM e posterior reconciliação com AIM existente |
| desativação | status, localização, histórico e documentação de retirada |
O evento precisa ter um owner e um critério de fechamento. Sem isso, o ativo físico muda e a informação digital permanece congelada.
O AIM precisa ser mantido, não apenas entregue. Substituições, reformas, alterações de configuração e novos projetos devem disparar atualização controlada da informação para evitar divergência entre o registro digital e o ativo físico.
Engineering Change Management · ISO 55000 e Gestão de Ativos
Gestão de mudanças conecta ECM, as-built e AIM
Mudanças técnicas precisam deixar rastros: origem, análise, aprovação, implementação, testes e atualização documental. O Engineering Change Management é uma disciplina importante nessa continuidade porque reduz o risco de a configuração real divergir silenciosamente dos registros.
Em ambientes críticos, a mudança pode exigir atualização coordenada de modelo, diagramas, lista de ativos, parâmetros, procedimentos, CMMS e documentos de operação.
Qualidade de informação precisa de dimensões explícitas
“Completo” não significa “correto”. A qualidade do AIM deve avaliar diferentes dimensões.
| Dimensão | Exemplo de verificação |
| completude | todos os ativos críticos possuem campos obrigatórios? |
| validade | valores seguem formato, unidade e domínio permitido? |
| unicidade | existem tags duplicadas? |
| integridade referencial | documentos e sistemas apontam para registros válidos? |
| consistência | fabricante/modelo são iguais entre bases relacionadas? |
| acurácia | registro corresponde ao equipamento instalado? |
| atualidade | última alteração do ativo foi refletida? |
| rastreabilidade | é possível identificar origem e aprovação do dado? |
| usabilidade | o sistema de destino consegue consumir a informação? |
Automação consegue verificar parte dessa qualidade, mas inspeção técnica e reconciliação de campo continuam necessárias para atributos que dependem da realidade instalada.
Segurança e acesso precisam ser proporcionais ao risco
Um AIM pode conter informações sensíveis: topologias, sistemas críticos, acessos, localização de equipamentos, configurações ou dados operacionais. A organização precisa classificar informação e definir privilégios, compartilhamento e auditoria compatíveis com o risco.
Nem todos os usuários precisam de acesso a todos os information containers. Governança adequada separa disponibilidade operacional de exposição desnecessária.
Métricas ajudam a medir prontidão e manutenção do AIM
Indicadores podem revelar se o modelo informacional continua confiável: percentual de ativos com cadastro aceito, taxa de documentos vinculados, divergências entre CMMS e campo, backlog de atualização, tempo para incorporar uma mudança, taxa de tags duplicadas, falhas de integração e percentual de ordens abertas contra ativos sem documentação válida.
A métrica não deve incentivar quantidade de dados. O objetivo é medir a capacidade de encontrar e utilizar informação confiável no processo correto.
Processo recomendado para estruturar PIM, transição e AIM
- Definir objetivos organizacionais e casos de uso operacionais. Identificar decisões que dependerão da informação do ativo.
- Estruturar OIR e AIR. Traduzir objetivos em requisitos de informação operacional.
- Definir PIR e EIR de cada projeto. Especificar informação necessária durante a entrega e nas trocas.
- Definir o Asset Register. Estabelecer classes e critérios para ativos individualmente controlados.
- Definir identificadores e taxonomias. Criar chaves persistentes entre BIM, procurement e operação.
- Mapear systems of record. Determinar qual plataforma será autoritativa para cada domínio de dado.
- Planejar PIM e entregas de informação. Integrar BEP, TIDP, MIDP, CDE e critérios de qualidade.
- Definir LOIN e atributos por marco. Evitar exigir informação antes de ela existir ou detalhamento sem uso.
- Capturar informação progressivamente. Incorporar dados de projeto, fornecedores, compras e execução conforme amadurecem.
- Controlar mudanças e substituições. Manter relação entre projetado, aprovado, comprado e instalado.
- Incorporar comissionamento. Associar testes, configurações, certificados e evidências aos ativos corretos.
- Reconciliar com a condição as-built. Verificar identificação, localização, relações e documentação contra o ativo entregue.
- Validar qualidade e integridade. Executar checks automatizados e revisão técnica/operacional.
- Testar os sistemas de destino. Importar dados, reconciliar contagens, vínculos e exceções antes do aceite.
- Formalizar handover e transferência de governança. Registrar baseline aceita, pendências e responsabilidades operacionais.
- Manter o AIM por trigger events e change control. Atualizar informação sempre que o ativo físico ou seus requisitos mudarem.
O resultado esperado não é um “modelo BIM final” mais pesado. É continuidade informacional: conhecimento produzido durante projeto e implantação chega à operação na forma necessária, em sistemas governados, com identidade persistente, qualidade verificável e processo de atualização. O AIM só gera valor quando continua representando o ativo que a organização realmente possui e opera.
Referências técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Organization and digitization of information about buildings and civil engineering works, including BIM — Information management using BIM — Part 1: Concepts and principles. Geneva: ISO, 2018. Disponível em: ISO.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Information management using BIM — Part 2: Delivery phase of the assets. Geneva: ISO, 2018. Disponível em: ISO.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-3:2020 — Information management using BIM — Part 3: Operational phase of the assets. Geneva: ISO, 2020. Disponível em: ISO.
[4] UK BIM FRAMEWORK. Guidance and resources for information management using the ISO 19650 series. Disponível em: UK BIM Framework.
[5] NATIONAL INSTITUTE OF BUILDING SCIENCES. Construction to Operations Building Information Exchange — COBie V3. Disponível em: NIBS.
Perguntas frequentes
PIM é Project Information Model, o modelo de informação usado principalmente na fase de entrega para desenvolver, coordenar, verificar, construir e entregar o empreendimento.
AIM é Asset Information Model, o modelo de informação que suporta a gestão e a operação do ativo ao longo da fase operacional.
Não. Eles são modelos de informação e podem reunir modelos geométricos, documentos, dados estruturados, registros e outros information containers.
Não. A transição deve selecionar informação com valor operacional, preservar o que precisa permanecer como registro e evitar carregar conteúdo temporário sem uso.
Não. Informações como serial, garantia, instalação, testes, configuração e manutenção podem surgir durante procurement, execução, comissionamento e operação.
Não. As-built registra a condição executada em determinado nível. O AIM é mais amplo e inclui dados, documentos, relações, governança e informação operacional.
Não. COBie é uma estrutura de intercâmbio que pode transportar parte dos dados necessários para construir ou atualizar um AIM.
Não. CMMS executa processos de manutenção e pode ser o sistema de registro de parte das informações do ativo, mas o AIM pode envolver vários sistemas e containers.
Não exatamente. BIM 7D é uma denominação de mercado para usos BIM em operação; AIM é um conceito de gestão da informação relacionado ao ativo na série ISO 19650.
Definindo systems of record, trigger events, responsabilidades, gestão de mudanças, identificadores persistentes, integrações e critérios de validação após alterações no ativo.
Materiais técnicos complementares
Requisitos e gestão da informação
- Gestão da Informação em BIM: ISO 19650
- Requisitos de Informação BIM: OIR, AIR, PIR e EIR
- BEP BIM
- MIDP e TIDP no BIM
- LOIN no BIM
- CDE BIM
- IDS BIM
- Gestão BIM e Informação de Engenharia
Handover, operação e gestão de ativos
- COBie no BIM
- BIM 7D
- Facility Management
- CMMS
- ISO 55000 e Gestão de Ativos
- Gestão de Ativos de Engenharia
- Engenharia de Manutenção
Arquitetura, interoperabilidade e integração
- Arquivo IFC no BIM
- Open BIM
- bSDD no BIM
- Digital Twin
- Integração de Sistemas, APIs e Conectores
- Ambiente Comum de Dados e Gestão da Informação BIM
- Governança Documental
