Nbims-Us v3 4.2 Cobie - En.es

Norma Nacional BIM - Estados Unidos ® La versión 3
4 Las normas de intercambio de información
4.2 Operación de construcción segundo el intercambio de información uilding (Cobie) - Versión 2.4
CONTENIDO
4.2.1 Alcance .................................................. .................................................. .................................................. ..... 2
4.2.2. Referencias normativas .................................................. .................................................. ....................... 17
4.2.3 Términos y definiciones .................................................. .................................................. .......................... 22
4.2.4 Símbolos y términos abreviados .................................................. .................................................. ........ 45
4.2.5 documentación de procesos de negocios .................................................. .................................................. ...... 47
4.2.6. documentación de necesidad de cambio .................................................. .............................................. 92
4.2.8 procedimientos de pruebas de conformidad .................................................. .................................................. .... 221
4.2.9 Recursos de implementación .................................................. .................................................. ................ 236
4.2.10 planes de revisión .................................................. .................................................. .................................. 243
Bibliografía .................................................. .................................................. .................................................. 245
Tabla de Figuras .................................................. .................................................. ........................................... 248
Anexo A - Cobie reglas de asignación .................................................. .................................................. ............. 252
Anexo B - el intercambio de información de Ciclo de Vida (LCIE) para el producto y tipo de producto intercambios de datos, un anexo técnico a
Cobie - Verion 2.4 .................................................. .................................................. .... 252
Norma Nacional BIM - Estados States® versión 3

© 2015 Instituto Nacional de Ciencias de la Construcción buildingSMART Alliance®. Todos los derechos reservados.
INFORMATIONEXCHANGEST ANDARDS - COB es decir, - edad P | 2
4.2.1 Alcance
4.2.1.1 Caso Descripción de actividad
Comentario del autor Editorial: modelos de procesos de negocios de apoyo COBIE se documentaron por primera vez en un Informe Técnico del Ejército de Estados
Unidos (East 2007). Estos modelos de negocio se han desarrollado a partir de una serie de reuniones de grupos de la industria de asesoramiento realizado en fueron
propuestos en el este de 2010. En el momento de la presentación de este documento otro 2006 y 2007. aclaración adicional del alcance de los procesos relacionados
con el ciclo de vida de los activos de las instalaciones actualización de los procesos de negocio relacionados con Cobie se está terminando para la edición como parte
de una
Informe Técnico del Ejército de EE.UU. (Fallon 2013). El objetivo de la investigación contenida en este informe era utilizar el modelado de procesos de
negocio en conjunto con los enfoques de gestión “pobre”, como en este 2011, para comparar con los actuales procesos de negocio basados en Cobie.
Como parte de la norma NBIMS-estadounidense ™ V3 COBIE, se proporciona un conjunto de modelos de negocio actualizados desarrollados en el
último informe para su inclusión directa en la norma. Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación
Subcomité para la presentación de intercambio de información revisados, la información proporcionada en esta sección deben considerarse un cambio
moderado.
Lista Fase 4.2.1.1.1 del ciclo de vida
• Estudiar y definir las necesidades
• Desarrollar criterios de diseño
• Estudio de viabilidad técnico
• Comunicar los resultados de la Decisión
• Desarrollar Programa - Programa Espacial
• Desarrollar Programa - Programa de Producto
• Preparar la invitación a hacer una oferta y recepción de propuestas (Pre-Diseño)
• Explora Conceptos - Diseño Temprano
• Desarrollar - Diseño esquemático
• Desarrollar - Diseño Coordinado
• Finalizar Diseño - Diseño Final
• Preparar la invitación a hacer una oferta y recibir propuestas (post Diseño)
• Responder a consultas de propuesta
• Desarrollar el Plan de Pre-Construcción
• identificar las discrepancias
• Preparar información de Presentación - Tipo de producto Selección
• Preparar información de Presentación - Disposición del sistema
• Organizar la información de Presentación
• Realizar revisión de Presentación - Edición Presentación
• proporcionar recursos
• Ejecutar las Actividades de Construcción
• Realizar pruebas de Equipo

• Inspeccionar y aprobar el Trabajo
• Definir, registrar y certificar discrepancias
• Cerrar
Aunque el uso de compartida, la información estructurada, como COBIE, puede ser demostrado que tienen un efecto directo tienen un impacto en la
velocidad y la calidad de las tareas de valor añadido, los casos de negocio que se describen a continuación no tienen en cuenta estos efectos
beneficiosos. Esto es porque en un modelo genérico, estos efectos eran demasiado complejas para modelar en el primer estudio del impacto del ciclo
de vida de contar con datos COBIE. Como resultado, los casos de negocio que se describen aquí son conservadores en sus estimaciones. Cobie 2,4
casos de negocio se basan en la técnica de análisis de valor añadido publicado en 2010. Este Este enfoque organiza operaciones de trabajo en tareas
que agregan valor al producto final y los que no lo hacen. En situaciones de trabajo que no agregan valor son objeto de eliminación en el proceso de
negocio aerodinámico.
Los siguientes oportunidades para la racionalización de la producción, el intercambio, el uso y mantenimiento de los datos COBIE través de
la eliminación de las operaciones sin valor agregado se caracterizan por la siguiente clasificación:
1. ahorros de validación por parte de la capacidad de comprobar mediante programación los datos de espacio y equipo para la integridad, la
conformidad con las normas y la conformidad con los requisitos.
2. ahorro copiando desde la confianza en los documentos electrónicos y datos que el registro del proyecto.
3. MANIPULACIÓN ahorro derivado de la adopción de sistemas de colaboración y gestión de proyectos gestionados para su transmisión y
registro automatizado de los documentos del proyecto.
4. BÚSQUEDA ahorro de la capacidad de comparar electrónicamente los datos del producto a las especificaciones del producto.
5. REFORMATEAR ahorros de la adopción de un único formato de datos, estándar abierto para la información relativa a los activos
gestionados.
6. La recreación de ahorros de la utilización de una norma, formato de datos estructurado para mover el espacio y la información del equipo a
través del proceso del proyecto y en la gestión de instalaciones, lo que elimina la necesidad de datos de reingreso. Además, la reanudación es
una forma de recreación.
Los ahorros pueden ser alcanzados en las tareas sin valor agregado a diferentes grados. Algunas tareas pueden ser eliminados por completo,
mientras que otros pueden ser automatizados o racionalizarse. De los 25 procesos del ciclo de vida estudiadas en Fallon 2013, 19 de ellos obtendría
un ahorro de la prevista de aproximación. Los siguientes procesos se definen y se incluyen el análisis de los posibles ahorros de la utilización de los
intercambios de información basados en COBIE.
4.2.1.1.1.1 Estudiar y definir las necesidades
información de las instalaciones estándar debe estar disponible a fin de determinar los requisitos básicos para un proyecto potencial. El propietario
identifica la necesidad y, o bien se desarrolla criterios técnicos para la instalación si no existe o utiliza criterios técnicos existentes si está disponible.
Si existe, esta información debe ser revisado para
relevancia cada cinco años para mantener la coherencia con las necesidades generales. ahorros potenciales en este proceso incluyen, pero no se
pueden limitar a, los siguientes:
• ahorro de reproducción de dependencia de los documentos electrónicos y la eliminación del papel.

4.2.1.1.1.2 Desarrollar criterios de diseño
la información relativa a equipos basados en criterios de instalación se genera temprano en el proceso de planificación por parte del propietario. Esta
información debe ser revisado para determinar su relevancia cada cinco años para mantener la coherencia con las necesidades generales. ahorros
potenciales en este proceso incluyen, pero no se pueden limitar a, los siguientes:
4.2.1.1.1.3 viabilidad técnica Estudio
El estudio de viabilidad permite al propietario para evaluar diferentes opciones (normalmente tres) en base a las necesidades identificadas antes de
finalizar la información específica sobre un proyecto. El arquitecto o planificador desarrolla el estudio sobre la base de la información contenida en los
Criterios de las instalaciones y los intercambios de información disciplina especificación. ahorros potenciales en este proceso incluyen, pero no se
pueden limitar a, los siguientes:
• ahorros de reproducción de la dependencia de los documentos electrónicos y la eliminación de papel
• Eliminación de los costes administrativos asociados con el manejo de las transmisiones de documentos de papel, así como el gasto de la entrega.
sistemas de colaboración electrónicos gestionados notificarán a los destinatarios previstos cuando los documentos electrónicos son liberados y
registrar tanto la emisión y la visualización de los documentos de forma automática.
4.2.1.1.1.4 comunicar los resultados de las decisiones
criterios iniciales sobre un proyecto deben ser establecidos con el fin de evaluar la viabilidad del proyecto. El propietario evalúa los criterios de
instalación, especificaciones de disciplina y estudio de viabilidad para determinar si debe o no seguir adelante con el proyecto. ahorros
4.2.1.1.1.5 Desarrollar un programa - programa espacial
Una vez que la definición del proyecto se ha establecido y aprobado, se puede producir un mayor desarrollo de los requisitos del proyecto. El arquitecto
o planificador evalúa la información contenida en el intercambio de información Definición del Proyecto para identificar las necesidades de espacio en
función del tipo de instalación. los requisitos de espacio, según el tipo de instalación, se encuentran en línea en formato de documento electrónico y
deben ser descargados. Estos documentos se imprimen típicamente por el usuario final. Si no existen criterios espaciales instalación estándar, debe ser
creada por referencia a los tipos de establecimientos similares. ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los
siguientes:
• Los profesionales del diseño típicamente volver a entrar en los requisitos de espacio del usuario en el sistema que utilizan para la programación del
espacio. Cobie con formato de datos de permisos de datos que se transfieren directamente del propietario para el arquitecto o el sistema del planificador
• Requisitos asociados a cada espacio son típicamente se reunieron y después se documentan en las Hojas de Datos de habitaciones. Cobie
formato eliminaría o bien la necesidad de producir hojas de datos de la habitación o la automatización de apoyo de su producción
• El Arquitecto / planificador envía el programa espacial para el representante del propietario para su revisión. Actualmente, esto se hace mediante la
comparación de 2 documentos. El uso del formato de Cobie permitiría la comprobación automatizada.
• Si el Arquitecto / planificador podría automatizar la comprobación de su producto de trabajo frente a los requisitos del usuario, a continuación, un ciclo
de reproceso / nueva revisión podría ser eliminado.

automáticamente registrar tanto la emisión y la visualización de los documentos
4.2.1.1.1.6 Desarrollar un programa - programa de productos
El arquitecto o planificador evalúa la información contenida en el intercambio de información Definición del Proyecto para identificar las necesidades de
productos basados en el tipo de instalación. Requisitos para los productos según el tipo de instalación se encuentran en línea en formato de documento
electrónico y deben ser descargados. Estos documentos se imprimen típicamente por el usuario final. Si no existen criterios de productos instalación
estándar, debe ser creada por referencia a los tipos de establecimientos similares. ahorros potenciales en este proceso incluyen, pero no se pueden limitar a,
los siguientes:
• Los profesionales del diseño típicamente volver a entrar en las normas de productos del usuario en el sistema que utilizan para el diseño. normas de
producto con formato COBIE permitirían la transferencia directa del propietario para el arquitecto o el sistema del planificador
• Si el propietario del Representante devuelve el Programa del producto, ya que no cumple con los requisitos del producto del propietario, el
arquitecto / planificador debe volver a crear el Programa del producto.
• El Arquitecto / planificador envía el Programa de Producto del representante del propietario para su revisión. Actualmente, esto se hace mediante la
comparación de 2 documentos. El uso del formato de Cobie permitiría la comprobación automatizada.
• Si el Arquitecto / planificador podría automatizar la comprobación de su producto de trabajo frente a los requisitos del usuario, a continuación, un ciclo
de reproceso / nueva revisión podría ser eliminado.
4.2.1.1.1.7 Preparar llamado a licitación y recibir propuestas (pre-diseño)
Una vez que se han determinado los principales criterios, del propietario del Representante prepara y distribuye una solicitud de propuesta
(RFP). ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los siguientes:
• ahorro de reproducción de dependencia de los documentos electrónicos y la eliminación del papel en las dos propuestas que solicitan y que
presentan
Un sistema de colaboración electrónica gestionada con un módulo de “hacer una oferta” puede manejar la distribución de las Solicitudes de
Propuesta, que reciben preguntas, la emisión de enmiendas y recibir y asegurar las propuestas presentadas por las empresas de diseño.
4.2.1.1.1.8 Explora conceptos - inicial de diseño
El arquitecto utiliza la información específica producida durante la pre-diseño para desarrollar una solución que refleje los requisitos indicados en
la definición del proyecto, programa espacial, y el Programa del producto. En la actualidad, el propietario requiere 6 copias en papel para ser
presentados para cada ciclo de examen. El arquitecto realiza una comprobación de QA / QC antes de enviar al representante del propietario.
Después de recibir la petición, el propietario del Representante valida los documentos (comentarios) y proporciona comentarios al arquitecto.
entonces se requieren el arquitecto y consultores para actualizar los documentos basados en los comentarios. Después

las revisiones se hacen, el arquitecto vuelve a presentar. ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los siguientes:
• A pesar de los requerimientos del usuario podrían ser incluidos como documentos electrónicos, el equipo de diseño típicamente vuelve a formatear
la información para que sea compatible con sus sistemas de diseño. Cobie con formato de datos requisitos permite la transferencia directa del
propietario para sistemas de los consultores de diseño.
• Si el propietario del Representante rechaza el concepto de diseño, ya que no cumple con los requisitos de espacio del propietario, el
arquitecto debe volver a crear el concepto de diseño.
• Cobie permitiría al arquitecto para automatizar la comprobación de su concepto de diseño frente a las necesidades de espacio del usuario,
ahorrando el tiempo Arquitecto y eliminando potencialmente un ciclo de revisión de retrabajo / re.
• El arquitecto envía el diseño de documentos tempranas para el representante del propietario para su revisión. Actualmente, esta revisión se realiza
de forma manual. El uso del formato de Cobie permitiría la comprobación automatizada del programa espacial en esta fase.
• En un proceso basado en papel, comentarios de revisión a menudo necesitan ser transferidos a múltiples copias de documentos.
4.2.1.1.1.9 Desarrollar - Diseño esquemático
El arquitecto desarrolla aún más el diseño Los primeros documentos de entrega aprobados para producir los documentos de diseño esquemático.
En la actualidad, el propietario requiere 6 copias en papel para ser presentados para cada ciclo de examen. El arquitecto realiza una
comprobación de QA / QC antes de enviar al representante del propietario. Después de recibir la petición, el propietario del Representante valida
los documentos y proporciona comentarios al arquitecto. entonces se requieren el arquitecto y consultores para actualizar los documentos
basados en los comentarios. Después de hacer revisiones, el arquitecto vuelve a presentar. ahorros potenciales en este proceso incluyen, pero no
se pueden limitar a, los siguientes:
• Fase de diseño esquemático requiere de cantidades despegues (qtos) para la estimación de costos. Qtos son una recreación de la
información debido a que los elementos que ya se han documentado en los dibujos o BIM. Cobie aborda espacios y productos /
equipos. Proporciona áreas espaciales y los tipos de productos y los recuentos.
• Si el propietario del Representante rechaza los documentos de diseño de esquemas porque el diseño no cumple con los requisitos de
espacio o de productos del propietario, el arquitecto debe volver a crear el diseño.
• A pesar de los requerimientos del usuario podrían ser incluidos como documentos electrónicos, el equipo de diseño pasa un tiempo considerable el
desarrollo de las plantillas tipo de producto (o contenido BIM), así como las especificaciones. Requisitos de datos con formato COBIE podrían ser
utilizados directamente.
• Si el arquitecto y sus consultores podrían automatizar la comprobación de su diseño frente a los requisitos de espacio y de productos del
propietario, que ahorrarían tiempo de comprobación y un ciclo de reproceso / nueva revisión podrían ser eliminados.
• El arquitecto envía los documentos de diseño esquemático para el representante del propietario para su revisión. Actualmente, esta es la revisión se
realiza de forma manual. El uso del formato de Cobie permitiría la comprobación automatizada del espacio y del programa de productos en esta fase.

• ahorros de reproducción de la dependencia de los documentos y datos electrónicos y la eliminación de papel
4.2.1.1.1.10 Desarrollar el diseño - plantilla del tipo de producto, tipo de producto candidato
A medida que progresa el diseño, se identifican las características de rendimiento y productos adecuados para los sistemas del edificio. tipos y equipos
del sistema se identifican por el especificador basado en los requisitos de las instalaciones. Se requieren seis copias para ser presentado para su
revisión. Algunos productos se definen con más detalle mediante la identificación de los fabricantes y los números de modelo, que cumplan con los
requisitos de diseño (BASE). En estos casos, 3 productos calificativo se enumeran a continuación. ahorros potenciales en este proceso incluyen, pero
no se pueden limitar a, los enumerados en la sección anterior.
4.2.1.1.1.11 Desarrollar el diseño - diseño coordinado
El arquitecto desarrolla aún más los documentos de entrega al diseño esquemático aprobados para producir los documentos de diseño
coordinado. Además, los sistemas de construcción se coordinan para eliminar espacial
interferencias. Esta es la principal presentación coordinación antes de que el paquete de entrega final. El propietario requiere 6 copias en
papel para ser presentados para cada ciclo de examen. Debido al mayor nivel de coordinación y aumento del número de partes
interesadas que repasan, a veces son necesarias más copias. El arquitecto realiza una comprobación de QA / QC antes de enviar al
representante del propietario. Después de recibir la petición, el propietario del Representante valida los documentos y proporciona
comentarios al arquitecto. entonces se requieren el arquitecto y consultores para actualizar los documentos basados en los comentarios.
Después de hacer revisiones, el arquitecto vuelve a presentar. ahorros potenciales en este proceso incluyen, pero no se pueden limitar a,
los siguientes:
• Fase de diseño coordinado requiere de cantidades despegues (qtos) para la estimación de costos. Qtos son una recreación de la
información debido a que los elementos que ya se han documentado en los dibujos o BIM. Cobie aborda espacios y productos /
equipos. Proporciona áreas espaciales y los tipos de productos y los recuentos.
• Si el propietario del Representante rechaza los documentos de diseño coordinado porque el diseño no cumple con los requisitos
de espacio o de productos del propietario, el arquitecto debe volver a crear el diseño.
• A pesar de los requerimientos del usuario podrían ser incluidos como documentos electrónicos, el equipo de diseño pasa un tiempo considerable el
desarrollo de las plantillas tipo de producto (o contenido BIM), así como las especificaciones. Requisitos de datos con formato COBIE podrían ser
utilizados directamente.
• Los productos candidatos (típicamente 3 productos de calificación) se identifican para cada plantilla de tipo de producto. Esto se hace a través de la
literatura del producto revisión. Estándar, datos de productos estructurados disponibles en formato COBIE permitiría la selección de productos
automatizado basado en las plantillas de tipo de producto.
• Si el arquitecto y sus consultores podrían automatizar la comprobación de su diseño frente a los requisitos de espacio y de productos del
propietario, que ahorrarían tiempo de comprobación y un ciclo de reproceso / nueva revisión podrían ser eliminados.
• El arquitecto envía los documentos de diseño coordinado con el representante del propietario para su revisión. Actualmente, esta es la revisión se
realiza de forma manual. El uso del formato de Cobie permitiría la comprobación automatizada de áreas espaciales y los datos de los productos
respecto a los requisitos del propietario.

4.2.1.1.1.12 Desarrollar el diseño - Tipo de producto candidato
Los requisitos de rendimiento de los sistemas y equipos de construcción son más refinado y documentado por el especificador durante esta
fase. Cualquier equipo, productos o sistemas no son identificados previamente seleccionado. se observan fabricantes específicos y
números de modelo. Tres productos que califican son identificados. Seis ejemplares se presentan para cada ciclo de examen. ahorros
potenciales en este proceso incluyen, pero no se pueden limitar a, los enumerados en la sección anterior.
4.2.1.1.1.13 diseño Finalizar - diseño final
El diseño de paquete final es el conjunto final de documentos del contrato listos para llamado a licitación por el propietario. Esta entrega de
diseño final no requiere otra revisión por el representante del propietario. ahorros potenciales en este proceso incluyen, pero no se pueden
limitar a, los siguientes:
• Diseño Fase final requiere de cantidades despegues (qtos) para la estimación de costos. Qtos son una recreación de la información
debido a que los elementos que ya se han documentado en los dibujos o BIM. Cobie aborda espacios y productos / equipos.
Proporciona áreas espaciales y los tipos de productos y los recuentos.
• El diseño final requiere de una revisión de control de calidad para evaluar tanto la precisión técnica y la coordinación disciplina. Cobie soporta
automatizar la comprobación del diseño frente a las necesidades de espacio y de productos del propietario, el ahorro de tiempo de verificación.
• ahorros de reproducción de la dependencia de los documentos y datos electrónicos y la eliminación de papel.
4.2.1.1.1.14 Finalizar el diseño - tipo de producto candidato
En esta fase del proyecto, todos los tipos de equipos y sistemas deben ser identificados por el especificador. información del producto desde
la fase de diseño coordinado se incorpora en esta fase. Tres (3) productos autorizados para cada tipo requerido deben estar inscritos.
ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los enumerados en la sección anterior.
4.2.1.1.1.15 Preparar llamado a licitación y recibir propuestas (post-diseño)
Una vez que el diseño está completo, el propietario empaqueta el diseño de la información de documentos finales, junto con otra información del propietario
suministrado (por ejemplo, los términos contractuales) y crea una Solicitud de Propuestas (RFP)

Paquete. Este se convierte en el conjunto oficial de la oferta. ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los siguientes:
• ahorro de reproducción de dependencia de los documentos electrónicos y la eliminación del papel en las dos propuestas que solicitan y que
presentan
• Eliminación de los costes administrativos asociados con el manejo de las transmisiones de documentos de papel, así como el gasto de la
entrega. Un sistema de colaboración electrónica gestionada con un módulo de “hacer una oferta” puede manejar la distribución de solicitudes de
propuestas, recibir preguntas, la emisión de enmiendas y recibir y asegurar las ofertas presentadas por los contratistas.
consultas 4.2.1.1.1.16 Responder a propuesta previa
Antes de finalizar una propuesta de oferta, el contratista normalmente solicita información adicional o aclaración de algunos documentos de licitación.
ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los siguientes:
Eliminación de los costes administrativos asociados con el manejo de las transmisiones de documentos de papel, así como el gasto de la entrega. Un sistema
de colaboración electrónica gestionada con un módulo de “hacer una oferta” puede manejar la recepción de preguntas postor y adiciones emisoras.
4.2.1.1.1.17 Desarrollar un plan de pre-construcción
El contratista está obligado a desarrollar un plan de pre-construcción que describe cómo el contratista hará disposiciones para la gestión de la
construcción de la instalación. Esto se envía como un paquete de presentación. Consulte el intercambio paquete de presentación para todos los
requisitos relacionados con la transmisión y el manejo de los envios Pre- plan de construcción.
Los ahorros de los intercambios COBIE no fueron identificados explícitamente en el
referenciada estudio.
4.2.1.1.1.18 identificar las discrepancias
El contratista presenta una solicitud de información (RFI) para pedir una aclaración durante el proceso de construcción.
Estas preguntas pueden ser debido a, pero no limitado a ambigüedades o contradicciones en el
dibujos o a las condiciones del sitio. ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los siguientes:
Un sistema de colaboración electrónica gestionada con un módulo de “hacer una oferta” puede manejar la recepción de preguntas postor y adiciones
emisoras.
4.2.1.1.1..19 Preparar información de presentación - selección del tipo de producto
El contratista y subcontratistas reúnen información de los productos identificados en los documentos finales de diseño y preparan los envios. Consulte el
intercambio paquete de presentación para todos los requisitos relacionados con la transmisión y el manejo de los envios de selección del tipo de producto.
Los ahorros de los intercambios COBIE no fueron identificados de manera explícita en el estudio de referencia. Tenga en cuenta que se espera que se
beneficia de tener datos de la plantilla de productos estándar a través del intercambio de información del ciclo de vida de Equipos Activos y proyectos
especificadores Propiedades de intercambio de información (SPIE) para hacer frente a muchas cuestiones relacionadas con la racionalización de la
entrega de la información de activos instalación.
4.2.1.1.1.20 Preparar información de presentación - Descripción del sistema
La información del contratista y subcontratistas reseña de los productos identificados en los documentos finales de diseño y preparar los
planos de taller. Consulte el intercambio paquete de presentación para todos los requisitos relacionados con la transmisión y el manejo de
los envios disposición del sistema. Los ahorros de Cobie

los intercambios no fueron identificados de manera explícita en el estudio de referencia. Tenga en cuenta que se beneficia de tener datos de configuración
del sistema estándar a través del intercambio de información HVAC (HVACie), se espera que el intercambio de información Sistema de agua (WSIE),
Sistema eléctrico de intercambio de información (Sparkie), y el intercambio de información de gestión de edificios Automatización (BAMie) para ser tratado
directamente en esos proyectos.
Organizar la información 4.2.1.1.1.21 presentación
El contratista organiza el envío de información requerida y crea los paquetes de presentación para ser revisados por el propietario de
Representante y / o Arquitecto. Se requieren seis copias impresas para ser presentado para su revisión. ahorros potenciales en este proceso
incluyen, pero no se pueden limitar a, los siguientes:
• Contratistas y subcontratistas deben extraer requisitos de producto de las especificaciones. COBIE proporciona los requisitos
del producto en una forma concisa, computable.
• Los contratistas deben compilar formatos de datos de productos dispares en los Artículos de Presentación de productos y paquetes de presentación para la
aprobación del Arquitecto. Cobie formatos de datos de productos constantemente.
• Los contratistas deben validar los datos de productos contra las especificaciones antes de incluirlos en una Presentación. Cobie soporta
automatizar la comprobación de los datos en contra de las especificaciones del producto, ahorrando tiempo y reduciendo el número de
Presentaciones de productos rechazados. Esto reduce el retrabajo. (Ver Recreando anteriormente).
• En un proceso basado en papel, comentarios de revisión a menudo necesitan ser transferidos a múltiples copias de Presentación.
• Eliminación de los costes administrativos asociados con la manipulación Presentaciones de documentos de papel, así como el gasto de la
entrega. Estos costos son altos, debido a la gran cantidad de documentos y la necesidad de múltiples copias. sistemas de colaboración
electrónicos gestionados notificarán a los colaboradores cuando se cargan los paquetes de presentación, automáticamente registrar tanto la
liberación y la revisión de los documentos y la responsabilidad pista de bola en la corte y fechas de vencimiento.
4.2.1.1.1.22 Realizar revisión presentación - tema presentación
El arquitecto y / o Subconsultores validan la de los planos proporcionados por el contratista y proporcionar comentarios. Se requieren
múltiples copias en papel. ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los siguientes:
• Si un artículo de Presentación es rechazado por el revisor (típicamente el Arquitecto y consultores del arquitecto), el contratista o
subcontratista deberán hacer de nuevo la presentación. COBIE soporta características automatizadas de productos validación contra
la memoria descriptiva, la reducción del número de Presentaciones producto rechazado.
• los colaboradores de Presentación (por lo general el arquitecto y los consultores del Arquitecto) También debe comprobar los datos de Presentación
del producto contra las especificaciones. Cobie apoya automatizado de cheques, ahorro de tiempo.
• En un proceso basado en papel, comentarios de revisión a menudo necesitan ser transferidos a múltiples copias de Presentación.
• Eliminación de los costes administrativos asociados con la manipulación Presentaciones de documentos de papel, así como el gasto de la
entrega. Estos costos son altos, debido a la gran cantidad de documentos y la necesidad de múltiples copias. sistemas de colaboración
electrónicos gestionados notificarán a los colaboradores

cuando se cargan Cuestiones de Presentación, iniciar sesión automáticamente tanto la liberación y la revisión de los documentos y la
responsabilidad pista de bola en la corte y fechas de vencimiento.
4.2.1.1.1.23 Proporcionar recursos
Los contactos contratista un proveedor para ordenar los equipos y materiales. El Proveedor proporciona entonces una cotización al contratista
para el equipo y / o materiales. El contratista verifica las especificaciones de los equipos y / o materiales en la cita contra la presentación de
documentación aprobada y luego los somete a representante del propietario y / o arquitecto para su aprobación. Los ahorros de los
intercambios COBIE no fueron identificados de manera explícita en el estudio de referencia.
4.2.1.1.1.24 Ejecutar las actividades de construcción
El contratista instala el equipo de construcción, los materiales y los sistemas que utilizan los planos finales de diseño, planos de instalación aprobados,
los datos del producto y las instrucciones del fabricante. El potencial de ahorro en este
proceso incluyen, pero no puede limitarse a, lo siguiente:
• Si bien el proyecto está en marcha, el contratista debe preparar continuamente un informe de instalación del producto que describe el estado de
los componentes instalados y los datos correspondientes. El contratista luego pasa el tiempo en la oficina de procesamiento de estas notas y
preparar el Informe. La hoja de cálculo COBIE sería un vehículo para la entrada de datos de campo, así como una referencia a los
componentes. Esto permitiría que el contratista para reducir el tiempo de oficina.
• Eliminación de los costes administrativos asociados con el manejo de documentos en papel, así como el gasto de la entrega.
4.2.1.1.1.25 Realizar la prueba del equipo
Después de que el contratista completa el proceso de instalación, los equipos / sistemas deben ser probadas mediante la activación de los equipos.
Esta prueba debe ser completada con el representante del propietario y la presencia de un representante del fabricante. Los ahorros de los
intercambios COBIE no fueron identificados de manera explícita en el estudio de referencia.
4.2.1.1.1.26 inspeccionar y aprobar el trabajo
Cuando el contratista haya completado la instalación de equipos o sistemas, se envía una notificación al Arquitecto que indica el elemento
instalado está listo para la inspección / observación. El arquitecto lleva a cabo inspecciones periódicas de las obras de construcción instalada.
Los resultados de las inspecciones, incluida cualquier deficiencia con la instalación de las obras de construcción están documentados en un
informe. Si se detectan deficiencias en el informe de inspección, el contratista los corrige y luego solicita una nueva inspección. ahorros
• El arquitecto debe validar cada solicitud de pago del contratista a través de una visita al lugar para determinar el progreso del trabajo.
Normalmente, el arquitecto toma dibujos al sitio para comprobar que los artículos facturados se han puesto en marcha. El arquitecto también toma
nota de cualquier defecto en mano de obra. El arquitecto entonces pasa el tiempo en la oficina componer notas de campo y cuantificar el trabajo
puesto en marcha para apoyar o refutar la solicitud de pago. Cobie proporcionaría una lista definitiva de los artículos requeridos por habitación o
piso que podría ser “marcadas” y automáticamente se sumaron. Esto permitiría que el arquitecto para reducir el tiempo de oficina.
• Eliminación de los costes administrativos asociados con el manejo de documentos en papel, así como el gasto de la entrega. sistemas de
colaboración electrónicos administrados pueden notificar al contratista si la solicitud de pago ha sido aceptada o rechazada y entregar el
Informe de campo de observación con el seguimiento.
4.2.1.1.1.27 definir, registrar y certificar discrepancias

El arquitecto crea un punzón de lista final basado en una encuesta de la obra ejecutada. El contratista corrige las deficiencias identificadas en la
lista de verificación. El arquitecto verifica que el contratista ha corregido las deficiencias en la lista de verificación mediante la realización de un
recorrido final. Los ahorros de los intercambios COBIE no fueron identificados de manera explícita en el estudio de referencia.
4.2.1.1.1.28 liquidación
El contratista reúne toda la información conforme a obra relacionada con el proyecto y envía la información al propietario. Cuatro copias
suelen ser necesarios. ahorros potenciales en este proceso incluyen, pero no se pueden limitar a, los siguientes:
• Contratista debe armar el paquete de rotación. Un sistema de colaboración que gestiona las tiendas de electrónica y los índices de
todos los documentos presentados, ya que se cargan. Esto reduce enormemente el tiempo necesario para encontrar los documentos
necesarios y montar el paquete de rotación, ahorrando el tiempo del contratista, la mejora de la integridad y calidad del paquete de
rotación, y haciendo que el paquete de rotación a disposición del propietario en una fecha anterior.
• ahorro de reproducción de facturación de documentos y datos electrónicos y la eliminación del papel. Por lo general se requieren
cuatro juegos de documentos de facturación.
• Eliminación de los costes administrativos asociados con el manejo de documentos en papel, así como el gasto de la entrega.
4.2.1.1.2 Análisis de Casos de Negocios
Se desarrollaron tres casos de negocio para apoyar la especificación COBIE 2.4. Los dos primeros fueron desarrollados para el edificio de
oficinas de uso común y Clínica Médica modelos Oriente 2012a). Estos modelos fueron utilizados como una representación de instalaciones
comerciales y médicas. El caso de negocio tercero, un programa de construcción de estaciones de Autoridad de Tránsito de Chicago (CTA),
también se analizó. La inclusión del programa de construcción CTA permitió a los autores del estudio para evaluar: (1) los supuestos con
respecto a los ahorros y los valores utilizados en los modelos BIM experimentales y (2) para demostrar cómo mixto de papel / enfoques
electrónicos están incluidos en el análisis de procesos de negocio.
El análisis llevado a cabo procesos de negocio contiene 210 variables relacionadas con la especificación, la documentación y el cumplimiento de
los requerimientos de activos administrados en todo el ciclo de vida completo de los intercambios de información relacionados COBie-. Estas
variables incluyen información sobre los números de estuches de dibujo, contar y complejidad de los inventarios de espacio, el alcance de las
especificaciones, números de horarios de equipos y copias requeridas de hojas de datos de producto. El análisis supone que no hubo cambios
en los requisitos de los contratos distintos de un cambio de lo tradicional a los procesos de negocio basados en Cobie.
La línea de base, o proceso actual, que se utiliza en el análisis de los proyectos de oficinas y Clínica asumieron un sistema de
comunicación y documentación basado en papel. El proceso que se espera asume un sistema de colaboración comunicación y
documentación electrónica y el uso de la norma, datos estructurados (Cobie) para el intercambio de datos. La calculadora de Cobie
determina los valores esperados de las variables afectadas. El análisis realizado evalúa considera que de las actividades sin valor
añadido previamente clasificado podría eliminarse o aerodinámico, en comparación con un proceso tradicional.
El proyecto se basó en la oficina de un edificio de oficinas federales típica Ejército estándar. El total de pies cuadrados era 40.053 SF. Había
50 tipos de productos y 1.706 componentes programados en el modelo de muestra. La siguiente tabla muestra los resultados del análisis total
a través de cada uno de los nuevos procesos de negocio COBIE, y todos los tipos de usuarios.

Tabla 1 Caso de Negocios - Oficina de Proyectos
OmniClass ™ Fase del Proyecto El costo actual ($) El costo esperado ($) Ahorros ($) Ahorros (%)
(Table31)
Criterios de instalaciones - - - 0%
Especificación de diseño $ 15.00 - $ 15.00 100%
Estudio de factibilidad $ 560.00 $ 25.00 $ 535.00 96%
Definición del proyecto $ 10.00 - $ 10.00 100%
Programa espacial $ 615.00 $ 10.00 $ 605.00 98%
Programa de productos $ 790.00 $ 5.00 $ 785.00 99%
Solicitud de propuesta $ 800.00 $ 100.00 $ 700.00 88%
diseño temprano $ 5,300.00 $ 90.00 $ 5,210.00 98%
diseño esquemático $ 9,900.00 $ 600.00 $ 9,300.00 93%
diseño Coordinado $ 26,300.00 $ 4,100.00 $ 22,200.00 85%
diseño final $ 12,900.00 $ 900.00 $ 12,000.00 93%
Edición consulta $ 1,210.00 $ 30.00 $ 1,180.00 98%
Plan de Pre-Construcción - - - 0%
Consulta Edición (RFI) $ 1,280.00 $ 10.00 $ 1,270.00 95%
Tipo de Producto Selección - - - 0%
Disposición del sistema - - - 0%
paquete de presentación $ 34,400.00 $ 3,000.00 $ 31,400.00 91%
Edición presentación $ 73,500.00 $ 400.00 $ 73,100.00 99%
Orden de compra - - - 0%
Instalación del producto $ 41,005.00 $ 5.00 $ 41,000.00 100%
Puesta en marcha - - - 0%
inspección del producto $ 15.900,00 $ 600.00 $ 15,300.00 96%
Punch-lista de Emisión - - - 0%
Volumen de negocios paquete $ 6,300.00 $ 100.00 $ 6,200.00 98%
Total $ 232,000.00 $ 10,000.00 $ 222,000.00 96%
El proyecto de clínica médica se basa en una clínica médica actual gobierno cuyos dibujos y las operaciones de diseño y manuales de
mantenimiento se han proporcionado, en forma redactada. El total de pies cuadrados era 49.571 SF. Había 155 tipos de productos y 3.950
componentes en el modelo de muestra. La siguiente tabla muestra los resultados del análisis total a través de cada uno de los nuevos
procesos de negocio COBIE, y todos los tipos de usuarios.
Tabla 2 Business Case - Clínica Médica
OmniClass ™ Fase del Proyecto

El costo actual ($) El costo esperado ($) Ahorros ($) Ahorros (%)
(Table31)
Especificación de diseño $ 135.00 - $ 135.00 100%
Estudio de factibilidad $ 670.00 $ 10.00 $ 660.00 99%
Definición del proyecto - - - 0%
Programa de productos $ 1,900.00 $ 5.00 $ 1,895.00 99%
diseño temprano $ 20,840.00 $ 300.00 $ 20.900,00 98%
diseño esquemático $ 33,400.00 $ 1,900.00 $ 31,500.00 94%


(Table31)
diseño final $ 30,400.00 $ 2,200.00 $ 28,200.00 93%
Solicitud de propuesta $ 1,990.00 $ 30.00 $ 1,960.00 98%
Edición consulta $ 1,210.00 $ 30.00 $ 1,180.00 98%
Consulta Edición (RFI) $ 1,800.00 - $ 1,800.00 100%
Instalación del producto $ 94,800.00 - $ 94,800.00 100%
inspección del producto $ 29,100.00 $ 1,200.00 $ 27,900.00 96%
Total $ 598,000.00 $ 24,000.00 $ 574,000.00 96%
El tercer modelo de negocio se llevó a cabo en el programa de la estación Autoridad de Tránsito de Chicago (CTA). A diferencia del análisis de la Oficina y
Clínica, descrito anteriormente, el CTA utiliza un sistema de colaboración gestionado basado en web con flujo de trabajo automatizado y algunos la
comunicación basada en papel en la ejecución de sus proyectos. procesos CTA combinan el intercambio de documentos en papel y de papel electrónico.
CTA no hizo uso de datos estándar, estructurados de intercambio, es decir, Cobie. Se hicieron cambios en las variables del modelo de procesos de negocio
para tener en cuenta el uso de herramientas de colaboración basadas en la web de CTA. Este resultado de la comparación de los procesos actuales de CTA
con un proceso que capturó la información de activos, a través de COBIE se proporciona en la siguiente tabla.
Tabla 3 - Negocios Autoridad de Tránsito de la caja

(Table31)
Especificación de diseño - - - 0%
Estudio de factibilidad $ 10.00 $ 10.00 - 0%
Definición del proyecto - - - 0%
Programa de productos $ 890.00 $ 30.00 $ 860.00 97%
Solicitud de propuesta $ 80.00 $ 80.00 - 0%
diseño temprano $ 11,800.00 $ 300.00 $ 11,500.00 97%
diseño esquemático $ 31,800.00 $ 1,500.00 $ 30,300.00 95%
diseño final $ 28,200.00 $ 1,900.00 $ 26,300.00 93%
Edición consulta $ 100.00 $ 100.00 - 0%
Consulta Edición (RFI) $ 3,200.00 $ 300.00 $ 2,900 91%
Instalación del producto $ 12,900.00 - $ 12,900.00 100%


(Table31)
inspección del producto $ 326,800.00 $ 13,100.00 $ 313,700.00 96%
Total $ 594,000.00 $ 28,000.00 $ 566,000.00 95%
En la comparación de los ahorros proyectados a partir de dos primeros proyectos, desarrollados a partir de la buildingSMART Alliance® repositorio BIM
archivos más comunes y los ahorros proyectados en el tercer proyecto, con base en información real del ciclo de vida recogida a través de la
observación directa de la conclusión se alcanza cuando la evaluación de estos casos es negocio que los ahorros previstos son sorprendentemente
consistente. En retrospectiva, este resultado es
consistente con el modelo que se ha desarrollado para evaluar estos casos de negocios. Esto se debe a un porcentaje constante de ahorro se puede
lograr para proyectos de cualquier tamaño cuando se cambia de procesamiento de documentos basado en papel a la utilización de herramientas
basadas en web que intercambian información basada en Cobie. Este consistentes por ciento de ahorro en todos los tipos de proyectos se debió
directamente a los tipos de operaciones comerciales contenidas en los modelos de procesos de negocio que podrían ser eliminados como resultado
de no tener que crear, recrear, transmitir y comprobar manualmente los datos proporcionados en Cobie frente documento formatos basados.
4.2.1.2 Los participantes y las partes interesadas
Autor del Comentario editorial: Información sobre los participantes y las partes interesadas no se prevea explícitamente en la documentación
NBIMS-estadounidense ™ V2 COBIE aunque la información se puede encontrar en los informes de proyectos que se hace referencia en un principio. Como
parte de la presentación NBIMS-estadounidense ™ V3 COBIE, una lista actualizada de los participantes y las partes interesadas se proporciona para la
inclusión directa en la norma. Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación Subcomité para docuemnts de
intercambio de información revisados, la información proporcionada en esta sección debe considerarse como un cambio moderado .
Lista 4.2.1.2.1 Los participantes
4Projects AEC 3 Graphisoft SE Hitchcock Consulting, Inc
Ltd AssetWORKS International Business Machines, Inc. Kristine
ARCHIBUS Fallon y Asociados LATISTA Onuma
Asite Solutions Ltd
Autodesk, Inc
Instalaciones de Bentley Organización para el Avance de Estándares de

Información Estructurada, Comité Abierto de
Bentley Systems
Building Information Exchange (oBIX) Técnica
Ciudad de Chicago, Chicago Transit Authority CxAlloy
DRofus DRRW, Inc EagleCMMS EcoDomus, Inc FM: Modelo de Intercambio de Información Nacional (NIEM)
Sistemas Nemetschek Vectorworks, Inc. Plannon TC9, Universidad Inc
TMA Sistemas de Chicago

INFORMATIONEXCHANGEST ANDARDS - COB es decir, - edad P | dieciséis
Ejército de Estados Unidos, Cuerpo de Ingenieros, Ingeniero de Investigación y Desarrollo Centro
4.2.1.2.2 Lista de partes interesadas
Propietarios Agentes de los fabricantes de puesta
Arquitectos en marcha operadores de las
Planificadores instalaciones Facility Managers Los
Ingenieros consultores encargados gestores de activos de software
de la construcción Contratistas analistas de sistemas Desarrolladores
subcontratistas los fabricantes de integradores de sistemas
Proveedores
4.2.1.2.3 análisis de la cobertura de las partes interesadas
La siguiente tabla describe brevemente cómo afecta a cada COBIE mandantes se abordan mediante el estándar COBIE.
Tabla de Análisis 4 Cobertura de las partes interesadas
Constitucion Análisis de la cobertura
propietarios El formato para la especificación de requisitos es proporcionada por Cobie. Una guía genérica al
contenido de Cobie, la Guía COBIE, debe ser actualizado para las necesidades de un determinado
propietario antes de especificar COBIE.
planificadores Una versión extendida de Cobie el formato, la definición específica

requisitos para la etapa de planificación y programación ha sido definida como el proyecto
BPie.
arquitectos los estándares de calidad exigidos por la Guía COBIE aseguran que los diseñadores crean datos COBIE que
coincide con el contenido de todos los activos programados.
Consultoría los estándares de calidad exigidos por la Guía COBIE aseguran que los diseñadores crean datos
Ingenieros COBIE que coincide con el contenido de todos los activos programados. lógica de las normas
descritas en esta norma proporcionan apoyo a la ejecución requerida.
encargados de la análisis caso de negocio COBIE apoya la racionalización de las actividades que tienen
construcción operaciones no de valor añadido.
Contratistas análisis caso de negocio COBIE apoya la racionalización de las actividades que tienen
operaciones no de valor añadido.
Sub- análisis caso de negocio COBIE apoya la racionalización de las actividades que tienen
Contratistas operaciones no de valor añadido.

Fabricantes análisis caso de negocio COBIE apoya la racionalización de las actividades que tienen
proveedores análisis caso de negocio COBIE apoya la racionalización de las actividades que tienen
fabricantes análisis caso de negocio COBIE apoya la racionalización de las actividades que tienen
COMISIÓNde g análisis caso de negocio COBIE apoya la racionalización de las actividades que tienen
Agentes operaciones no de valor añadido.
Los operadores Permite la información de traspaso a ser importados antes de la operación de la instalación.
de las instalaciones
administradores Permite la información de traspaso a ser importados antes de la administración de la instalación.

de instalaciones
Los Permite la información de traspaso a ser importados antes de la administración de los activos de la instalación.
administradores de activos
Desarrolladores de especificación IFC mejorado, y soporte para IFC 4, ayudan a los que utilizan IFC. formatos XML
software actualizados disminuirán el costo de los intercambios basados en XML y su uso en servicios
web.
analistas de especificación IFC mejorado, y soporte para IFC 4, ayudan a los que utilizan IFC. formatos XML
Sistemas actualizados disminuirán el costo de los intercambios basados en XML y su uso en servicios
web.
integradores de especificación IFC mejorado, y soporte para IFC 4, ayudan a los que utilizan IFC. formatos XML
sistemas actualizados disminuirán el costo de los intercambios basados en XML y su uso en servicios
web.
4.2.2. Referencias normativas
Comentario editorial del autor: Esta sección actualiza los “Criterios de Estándares de Referencia (Otro)” incluidas en la documentación COBIE
NBIMS-estadounidense ™ V2, el apartado A.8. Nuevos estándares de referencia, Schematron y NIEM, se han añadido a este documento para reflejar los
cambios necesarios para NBIMS-estadounidense ™ V3. Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación
Subcomité para la presentación de Intercambio de Información revisados, la información proporcionada en esta sección debe considerarse como un cambio
moderado.
4.2.2.1 Referencias y normas
4.2.2.1.1 lista de patrones de referencia
4.2.2.1.1.1 Industria Foundation Class (IFC) modelo, la versión 2x3
4.2.2.1.1.2 Industria Foundation Class (IFC) Modelo, versión 4 (ISO 16739)

4.2.2.1.1.3 estándar para el intercambio de productos (PASO) (ISO 10303)
ISO 10303-11, Sistemas de automatización industrial e integración - la representación de datos y el intercambio de productos - Parte 11: Métodos
Descripción: El Manual de Referencia del lenguaje EXPRESS. Este es el formato de las figuras que se encuentran en el Ministerio del Interior se hace
referencia.
ISO 10303-21, Sistemas de automatización industrial e integración - la representación de datos y el intercambio de productos - Parte 21: Métodos
de ejecución: la codificación de texto claro de la estructura de intercambio. Esto normalmente se conoce como el paso de formato de archivo
físico.
ISO 10303-28, Sistemas de automatización industrial e integración - la representación de datos y el intercambio de productos - Parte 28:
Métodos de ejecución: representaciones XML de esquemas y datos EXPRESS, utilizando esquemas XML. Esto se conoce típicamente
como ifcXML.
4.2.2.1.1.4 Schematron (ISO / IEC 19757-3: 2006)
Comentario del autor Editorial: El código abierto Tool Kit COBIE ha sido desde marzo de 2012, la herramienta que se utiliza para probar los archivos contra
los requisitos de formato COBIE. Las reglas que se utilizan en el Kit de herramientas COBIE dadas como anexo a la presente norma, se han desarrollado y
se mantienen en formato Schematron.
Un formato estándar internacional para el desarrollo de normas de ensayo para los archivos de Cobie se basa en la norma ISO / IEC 19757-3: 2006
Tecnología de la información - documento de esquema de lenguaje de definición (dsdl) - Parte 3: validación basada en reglas - Schematron.
Schematron es ampliamente usada y disponible de ISO de forma gratuita. Schematron ha demostrado ser fácil de utilizar ya que sus reglas se basan
en la búsqueda de árbol XML y utiliza el lenguaje de programación XPath.
El uso de Schematron es opcional. Cualquier otra herramienta de prueba se puede utilizar siempre que dichas herramientas a prueba sus algoritmos
de equivalencia con las normas Schematron previstos en esta norma y se incluyen en la aplicación Tool Kit COBIE.]
4.2.2.1.1.5 Información Nacional del Mercado Modelo (NIEM), versión 2.1
Comentario del autor Editorial: NBIMS-estadounidense ™ V2 COBIE 2.26 permite tres formatos de intercambio alternativos. Estos
formatos son el paso Formato de archivo físico, el formato ifcXML, y el formato SpreadsheetML. A los efectos de la norma COBIE no
hay diferencia entre estos formatos. El criterio de selección de formato se ha dejado hasta el interés del mercado. El más utilizado de
estos tres formatos, hasta la fecha, ha sido el formato SpreadsheetML. SpreadsheetML es un esquema XML que refleja la
organización de los datos de hoja de cálculo de Microsoft Excel 2003.
Mientras que la vista de hoja de cálculo de datos de Cobie ha sido esencial para la comprensión y el éxito hasta la fecha de Cobie, los proveedores de
software han expresado su preocupación con el formato de hoja de cálculo. La primera preocupación es que el esquema SpreadsheetML es una
especificación XML semi-propietario directamente ligada a Microsoft Excel 2003. Con el tiempo tal formato se amortizará por Microsoft y
NBIMS-estadounidense ™ tendrá que seleccionar un formato alternativo. Los usuarios europeos de Cobie también han expresado su preocupación ya
que está restringido y en algunos casos prohibida la adopción de estándares de datos propietarias.
La segunda preocupación con el XML SpreadsheetML es la complejidad de ese esquema. La estructura de SpreadsheetML está estrechamente ligada
a la estructura de una hoja de cálculo. Un problema con esta estructura a base de hoja de cálculo es que el Cobie en forma de hoja de cálculo es un
esquema de “referencia” en lugar de un esquema “anidada”. El enfoque “anidado” es más probable que sea utilizado por los desarrolladores de
software, ya que es más compacto y requiere menos pruebas de que el esquema anidado.

La tercera preocupación expresada por muchas empresas de software e integradores de sistemas ha sido una preocupación de que los estándares
basados en buildingSMART PASO o la SpreadsheetML son incompatibles con el esquema XML simplificado utilizado para soportar interfaces de servicios
web de sistema a sistema directo. Tal XML aerodinámico
esquema también apoyaría más fácilmente el desarrollo y la adopción de sub-esquema que podría ser utilizado para provocar una revolución de la
productividad en la industria de la construcción.
Como resultado de estas preocupaciones, el equipo del proyecto COBIE desarrolló un esquema XML alternativa para apoyar un uso más amplio de la
información de los activos instalación que se encuentra en los archivos de Cobie. El nuevo formato de esquema XML para los datos COBIE, cuyos
detalles técnicos se describen detalladamente en secciones posteriores de esta norma, se llama COBieLite. Un criterio de diseño esencial en el desarrollo
de COBieLite fue que COBieLite se ajustan a las normas existentes, y de libre acceso, de gran visibilidad de los Estados Unidos de esquema XML
nacional. El Modelo Nacional de Intercambio de Información (NIEM) un estándar de Gobierno de los Estados Unidos ha sido seleccionada como la base
desde la cual se desarrollaría el esquema COBieLite.
NIEM es un estándar de Gobierno de los Estados Unidos desarrollado por el Departamento de Seguridad Nacional y el Departamento de
Justicia de Estados Unidos. NIEM contiene actualmente una variedad de esquemas utilizados a nivel federal y estatal de gobierno de los
Estados Unidos. Dominios incluidos en este esquema que se relacionan con la misión buildingSMART incluyen la justicia, la seguridad pública,
emergencias y desastres, y las empresas de seguridad nacional. Esquemas para la construcción de interiores, tales como los que podrían ser
proporcionados a través de normas buildingSMART Alliance® actualmente no están incluidas en el catálogo NIEM; Sin embargo, COBieLite
facilitará una discusión tal y promover el intercambio de datos COBIE en comunidades que utilizan información sobre las instalaciones, no sólo
los que diseñan, construyen y operan ellos.
4.2.2.1.2. (No utilizado)
4.2.2.1.2.1 Sistema de Clasificación de Construcción OmniClass ™
Comentario del autor Editorial: OmniClass ™ se ha utilizado en archivos de ejemplo COBIE en lugar de utilizar contrato- sistemas de clasificación
específicos o específicos del cliente.
Se requiere el uso de la clasificación para la siguiente información COBIE: Contactos, Instalación, Espacio, Tipo y Zona. La
especificación de las taxonomías específicas debe ser especificado por contrato o basados en la especificación propietario regional,
local. Desde el punto de vista de la norma la selección de un sistema de clasificación es, por lo tanto, arbitraria. Ejemplos desarrollados
para archivos COBIE se han desarrollado utilizando OmniClass taxonomía. Dado que OmniClass se ha utilizado en los ejemplos COBIE,
se hace referencia a las siguientes tablas OmniClass en esta norma:
Tabla 11 - Entidades Construcción de Función
Tabla 13 - Espacios de Función
Tabla 21 - Resultados de trabajo
Tabla 23 - Productos
4.2.2.1.3 programas y proyectos de referencia
4.2.2.1.3.1 Los especificadores Propiedades de intercambio de información (SPIE)
El objetivo del proyecto SPIE es crear un conjunto de plantillas de productos que pueden ser utilizados por los fabricantes de productos para exportar los
datos a un formato estándar abierto consumida por los diseñadores, especificadores, constructores, propietarios y operadores. Este proyecto se extiende
esfuerzos de los fabricantes en Building Information Modeling, mercados electrónicos, y el etiquetado de identificación estándar y proporciona valor a través
de toda la cadena de suministro. por

más información sobre SPIE favor ver http://www.nibs.org/?page=bsa_spie para más información sobre este proyecto.
4.2.2.1.3.2 Los operadores Propiedades de intercambio de información (Opie)
El objetivo de Opie fue identificar las propiedades que necesitan los operadores de las instalaciones y técnicos de mantenimiento más allá de aquellas
propiedades identificadas por el proyecto de SPIE. Este proyecto fue iniciado por el Cuerpo de Ingenieros del Ejército, Laboratorio de Investigación de
Ingeniería de la Construcción en el año 2011. Durante estos formularios de la encuesta de proyectos para validar la información utilizada por el personal
de comando de instalación del Ejército de Estados Unidos que trabajan en instalaciones militares fue creado y distribuido al Instituto Nacional de
Ciencias de la Construcción , Instalación de Mantenimiento y Operaciones Comité para su revisión. Se recibió un número insuficiente de respuestas
(tres respuestas parciales). El proyecto fue cerrado debido a la falta de interés de la industria. No ser un patrocinador para mover este proyecto
adelante, un oficial buildingSMART Alliance® proyecto nunca se ha inicializado.
Después de 2012 las conversaciones entre el Dr. Medio y miembros del gobierno noruego puede ser posible que la información que se recoge en
las propiedades de los operadores en Noruega podría ser utilizado para validar la información obtenida de las fuentes del Ejército de Estados
Unidos. En el momento de esta norma no hay más información disponible sobre el proyecto Opie.
4.2.2.1.3.3 intercambio de información del ciclo de vida (LCIE)
LCIE es un refinamiento de los procesos requeridos para intercambiar conjuntos de datos COBIE completas o parciales. Mientras COBIE se centra en las
principales bolsas contractuales de los archivos de modelos completos, LCIE se centra en las transacciones individuales necesarios para construir los
conjuntos completos de datos COBIE. En primer lugar se propone en este 2010, LCIE se ha desarrollado desde entonces y ahora es la base de los
modelos de procesos que se encuentran en esta norma. Un estándar adicional NBIMS-estadounidense ™ V3 que define la cadena de suministro de
producto, desarrollado a partir del proyecto LCIE, se espera que sea presentado. Información adicional sobre el proyecto LCIE se puede encontrar aquí:
http://www.nibs.org/?page=bsa_lcie.
4.2.2.1.3.4 de calefacción, ventilación y el intercambio de información Aire Acondicionado (HVACie)
Para modelar un sistema de construcción completa para requerir más de información COBIE. En el momento de la presentación COBIE
NBIMS-estadounidense ™ V2 se propuso por el autor de que un proyecto de intercambio genérico información Equipamiento de diseño (Elie) sería
suficiente para este propósito. Investigaciones posteriores revelaron que se necesitarán versiones de dominio específico de Elie para implementar
reglas de negocio específicos de dominio que rigen cada sistema. Como resultado, el proyecto Elie se deprecia en 2011 y una serie de nuevos
proyectos se llevó a cabo por el Ejército de EE.UU., Cuerpo de Ingenieros, Ingeniero de Investigación y Desarrollo Centro.
Un modelo de sistema debe describir el conjunto completo de componentes que componen esos sistemas, los conjuntos de esos componentes,
tales como enfriadores y cuadros de distribución eléctrica, y las lógicas (sistemas, zonas, circuitos) y las conexiones físicas (alimentadores,
tuberías, conductos) que permiten estos sistemas para llevar a cabo su función. La geometría del sistema también es fundamental para la
comprensión de su función de modo también se requiere la geometría completa. El formato de la propuesta de la CFI MVD debe ser CFI. Un
subconjunto del modelo de sistema que contiene activos programados se puede representar en Cobie.
La primera demostración del formato HVACie se celebró en el buildingSMART Alliance® de enero de 2013 evento Challenge.
Más información sobre este proyecto específico puede ser encontrado aquí:
http://www.nibs.org/?page=bsa_hvacie.
intercambio 4.2.2.1.3.5 información Sistema eléctrico (Sparkie)
NBIMS-estadounidense ™ V2 se propuso por el autor que un genérico información Equipamiento de diseño

proyecto de intercambio (Elie) sería suficiente para este propósito. Investigaciones posteriores revelaron que se necesitarán versiones de
dominio específico de Elie para implementar reglas de negocio específicos de dominio que rigen cada sistema. Como resultado, el proyecto Elie
se deprecia en 2011 y una serie de nuevos proyectos se llevó a cabo por el Ejército de EE.UU., Cuerpo de Ingenieros, Ingeniero de
Investigación y Desarrollo Centro.
subconjunto del modelo de sistema que contiene activos programados se puede representar en Cobie. Más información sobre este proyecto
específico se puede encontrar aquí: http://www.nibs.org/?page=bsa_sparkie.
4.2.2.1.3.6 intercambio de información Sistema de agua (WSIE)
específico se puede encontrar aquí: http://www.nibs.org/?page=bsa_wsie.
4.2.2.1.3.7 intercambio de información de gestión de edificios Automatización (BAMie)
específico se puede encontrar aquí: http://www.nibs.org/?page=bsa_bamie.
4.2.2.1.3.8 el intercambio de información de programación de construcción (BPie)
Ha habido varios buildingSMART y relacionados proyectos dirigidos a la captura de información de programación de arquitectura para soportar
tanto el esfuerzo de programación arquitectónica, la entrega de la solicitud estándar para los documentos de propuestas a comunicarse con mayor
claridad los requisitos de los propietarios, y para llevar a cabo la evaluación automatizada de cumplimiento espacial de la tarde documentos de
diseño. Estos proyectos incluyen la

Cartera y gestión de activos - Requisitos de Desempeño (PAMPER), Alianza Internacional para el Proyecto AR-5 de la
interoperabilidad, el proyecto Hoja buildingSMART International Data Room 'acuario', el proyecto de Estados Unidos Administración
de Servicios Generales, la buildingSMART espacial Cumplimiento
el intercambio de información (SCIE, pronunciado 'esquí') del proyecto, y un nuevo esfuerzo de Noruega, cuyo objetivos son similares a los proyectos
anteriores. Aunque cada uno de estos proyectos proyectos han explorado algunos aspectos de los intercambios de información contratados
necesarios para crear un estándar abierto para la programación arquitectónica, ninguno de estos proyectos han alcanzado una masa crítica para ser
reconocidos como estándares nacionales y sea ampliamente implementado a nivel internacional. El objetivo del proyecto es desarrollar BPie una
especificación internacional consolidado para la prestación contratada de información de programación arquitectónica por la evaluación y
consolidación de los resultados anteriores del proyecto.
Una preocupación fundamental para los que tratan de utilizar los intercambios de información contratados es la necesidad de repetir los resultados de las
pruebas llevadas a cabo bajo condiciones controladas. Esto requiere la especificación precisa de ambas formato de datos y restricciones de contenido. Además,
los modelos comunes de prueba deben ser utilizados en el contexto de los programas de pruebas automatizadas. Por último, se exigirá que las empresas de
software para proporcionar versiones nativas de modelos de prueba, guías de configuración y las instrucciones de uso para asegurar la repetibilidad de los que
no participan directamente en estos esfuerzos.
La primera demostración del formato BPie se llevó a cabo en enero de 2013 en la Alliance® Desafío buildingSMART. En este caso la
información BPie se exportó utilizando el formato COBIE SpreadsheetML. Más información sobre este proyecto se puede encontrar
aquí: http://www.nibs.org/?page=bsa_bpie.
4.2.3 Términos y definiciones
Comentario del autor Editorial: La lista de términos y definiciones no se requiere en presentaciones NBIMS-estadounidense ™ V2. La información aquí
proporcionada refleja la compilación de los términos y definiciones que se encuentran en los Estados Unidos NBIMS-™ V2 y actualizado para la versión
actual COBIE. Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación Subcomité para la presentación de
Intercambio de Información revisados, la información proporcionada en esta sección debe considerarse como un cambio moderado.
4.2.3.1 términos normativos y definiciones
Los siguientes términos y definiciones son aplicables los términos derivados de la definición de rama Foundation Class Model View. Estos
términos se enumeran en orden alfabético.
4.2.3.1.1 el
actor
persona, una organización o persona que actúe en nombre de una organización. Una especialización del objeto general plazo. Ver contacto
COBIE.
4.2.3.1.2
atributo
unidad de información dentro de una entidad, definida por un tipo particular o referencia a una entidad particular. Hay tres tipos de
atributos: atributos directas, inversas y atributos atributos derivados. Ver atributo COBIE.
4.2.3.1.3
edificio
un edificio representa una estructura que proporciona refugio para sus ocupantes o de los contenidos y se encuentra en un solo lugar. El edificio también se utiliza
para proporcionar un elemento básico dentro de la jerarquía de la estructura espacial de los componentes de un proyecto de construcción (junto con el sitio, la
historia, y en el espacio). Ver las instalaciones COBIE.

4.2.3.1.4
historia de la construcción
La historia edificio tiene una elevación y típicamente representa un (casi) la agregación horizontal de los espacios que están unidas
verticalmente. Ver piso COBIE.
4.2.3.1.5
restricciones sobre los atributos
Tipo de datos de la restricción de los valores de los atributos. La limitación más general es acerca de la existencia de valores de atributos. Hay
básicamente dos tipos: atributos obligatorios y opcionales. Los valores de atributos obligatorios deben ser proporcionados mientras que los valores de
los atributos opcionales se pueden omitir. Para los tipos de datos de agregación tales como Set, Lista o Array, la restricción de existencia es a menudo
refinado por un número mínimo y máximo de los elementos, que también se conoce como cardinalidad.
4.2.3.1.6
atributo derivado
unidad de información calcula a partir de otros atributos utilizando una expresión definida en el esquema.
4.2.3.1.7
atributo directa
valores escalares o colecciones incluidos conjunto (no ordenado, único), la lista (ordenada) o Array (ordenada, escaso) como se define en [ISO 10303-11]
Al igual que en el término "campo" en lenguajes de programación comunes.
4.2.3.1.8
elemento
producto físico tangible que puede ser descrito por su representación de forma, representaciones materiales, y otras propiedades. Una
especialización del producto término general. Ver COBie.Component.
4.2.3.1.9
elemento de ocurrencia
La posición de elemento dentro del proyecto de sistema de coordenadas y su contención dentro de la estructura espacial.
4.2.3.1.10
entidad
clase de información definida por atributos y limitaciones comunes como se define en [ISO 10303-11]. Al igual que en el término "clase" en lenguajes de
programación comunes pero que describe la estructura de datos única (no el comportamiento, tales como los métodos).
4.2.3.1.11
enumeración
constructo que permite un valor de atributo para ser uno de varios valores predefinidos identificados por su nombre. Similar a la "Enumeración"
constructo como se define en [ISO 10303-11]. Similar en concepto a la "enumeración" en lenguajes de programación comunes.
4.2.3.1.12
referencia externa
Enlace a la información fuera del conjunto de datos, con una relación directa con la información específica del enlace se origina desde el interior del conjunto de datos.
4.2.3.1.13
función
información paramétrica y la información de propiedad adicional modificando la representación de forma de un elemento al que se
aplica.
4.2.3.1.14
grupo

recopilación de información que cumple una finalidad determinada. Una especialización del objeto general plazo. Ver COBie.Zone y
COBie.System.
4.2.3.1.15
identificación
la capacidad de encontrar, recupera informe, cambiar o eliminar los casos específicos y sin ambigüedad.
4.2.3.1.16
instancia
ocurrencia de una entidad. Al igual que en el término "instancia de una clase" en la programación orientada a objetos.
4.2.3.1.17
atributo inversa
unidad de información definición de consultas para obtener datos relacionados y hacer cumplir la integridad referencial. Al igual que en el término "propiedad de
navegación" en los marcos de programación de entidad-relación.
4.2.3.1.18
biblioteca
catálogo, base de datos o titular de los datos, que es relevante a la información en el conjunto de datos. Es la información que se hace referencia de una
fuente externa que no se copia en el conjunto de datos.
4.2.3.1.19
objeto
nada perceptible o concebible que tiene una existencia distinta, aunque no material.
4.2.3.1.20
ocurrencia objeto
características de un objeto como un individuo. Similar a "objeto", "ejemplo", "individual" “componente” en otras publicaciones.
4.2.3.1.21 tipos de
objetos
características comunes compartidas por múltiples objetos-ocurrencias. Al igual que en "clase", "plantilla", y “tipo" en otras publicaciones.
4.2.3.1.22
proceso
oponerse-ocurrencia situado en el tiempo, lo que indica "cuando". Ver COBIE trabajo.
4.2.3.1.23
ocurrencia proceso
objeto conceptual que puede ocurrir en un momento determinado.
tipo 4.2.3.1.24
proceso
características comunes compartidas por múltiples ocurrencias de proceso.
4.2.3.1.25
producto
objeto físico o conceptual que se produce en el espacio. Es especialización del objeto general plazo. Ver COBie.Component.
4.2.3.1.26
ocurrencia producto
objeto físico o conceptual que puede tener una ubicación en las características de espacio y forma.

tipo 4.2.3.1.27
producto
características comunes compartidas por múltiples ocurrencias de productos. Ver COBie.Type.
4.2.3.1.28
proyecto
encapsulación de información relacionada para un propósito particular, proporcionar un contexto para la información que contiene. La información
de contexto puede incluir unidades de medida por defecto o el contexto de representación y precisión.
4.2.3.1.29
propiedad
unidad de información que se define dinámicamente como una instancia de la entidad particular. Al igual que en "tarde-bound" o "tiempo de ejecución" en la
terminología de programación. Ver COBie.Attribute.
4.2.3.1.30
ocurrencia propiedad
unidad de información que proporciona un valor para una propiedad identificada por su nombre.
4.2.3.1.31
plantilla de propiedades
metadatos para una propiedad que incluye el nombre, la descripción y el tipo de datos. Similar en concepto a la "propiedad de extensión" en lenguajes de
programación comunes.
4.2.3.1.32
conjunto de propiedades ocurrencia
unidad de información que contiene un conjunto de ocurrencias de propiedad, cada uno con un nombre único dentro del conjunto de propiedades.
4.2.3.1.33
plantilla de conjunto de propiedades
conjunto de plantillas de propiedad que sirve a un propósito común y tienen aplicabilidad a los objetos de una entidad en particular. Similar en
concepto a la "clase de extensión" en lenguajes de programación comunes.
4.2.3.1.34 de
proxy
objeto que no mantenga una información específica de tipo de objeto. Una especialización de ocurrencia objeto.
4.2.3.1.35
cantidad
la medición de una métrica basada en alcance, específicamente longitud, área, volumen, peso, contar, o tiempo.
4.2.3.1.36
ocurrencia cantidad
unidad de información que proporciona un valor para una cantidad.
4.2.3.1.37 cantidad
establecida
unidad de información que contiene un conjunto de ocurrencias de cantidad, teniendo cada uno un nombre único dentro de la cantidad ajustada.
4.2.3.1.38
relación
unidad de información que describe una interacción entre artículos.

4.2.3.1.39
representación
unidad de información que describe cómo se visualiza un objeto, tal como la forma física o topología.
4.2.3.1.40
recursos
entidad con la disponibilidad limitada, tales como materiales, mano de obra o equipo. Una especialización del objeto general plazo. La sección de "recursos
esquemas de datos definición" no está relacionado con este concepto. Vea el recurso COBIE.
4.2.3.1.41
ocurrencia de recursos
entidad con el coste inherente financiera, que puede ser pasado en procesos, productos y controles a los que se ha asignado.
4.2.3.1.42 tipo de
recursos
características comunes compartidas por múltiples ocurrencias de recursos.
4.2.3.1.43
seleccione
constructo que permite un valor de atributo para ser uno de varios tipos o entidades. Similar a la "Seleccionar" construir como se define en
[ISO 10303-11]. Similar a una "interfaz de marcador" en lenguajes de programación comunes.
4.2.3.1.44
espacio
área o volumen delimitadas real o teórica. Ver espacio COBIE.
4.2.3.1.45
sistema
organizado combinación de partes relacionadas dentro de un producto de AEC, compuesto para un propósito o función común o para proporcionar un
servicio. Sistema es esencialmente una agregación funcionalmente relacionados de productos. Ver COBIE sistema.
4.2.3.1.46
transacción
un cambio discreto de específica un subconjunto definido de una especificación de intercambio de información más grande.
4.2.3.1.47
tipo
constructo información básico derivado de un primitivo, una enumeración, o un selecto de entidades. Similar a la "Type" construir como se
define en [ISO 10303-11]. Similar en concepto a "typedef" o "tipo de valor" en lenguajes de programación comunes. Ver tipo COBIE.
4.2.3.1.48
zona
una zona es un grupo de espacios, espacios parciales u otras zonas. Ver COBIE zona.
4.2.3.2 términos informativos y definiciones
Los términos y definiciones a continuación la lista de títulos de las columnas y los términos comunes que se encuentran en el formato de aplicación COBIE hoja
de cálculo.

4.2.3.2.1 términos y definiciones comunes de hojas de Cobie
Hay dos conjuntos de información presentes en cada hoja de una hoja de cálculo COBIE. Estos son información sobre el autor y la información del
sistema de origen. La información del autor permite a los productores de un conjunto de datos COBIE específicos establecidos para identificar si ellos, o
alguien antes, crear o cambiar la información proporcionada. La información del autor es obligatorio en todas las filas de datos COBIE. La información del
autor se compone de:
4.2.3.2.1.1
CreatedBy
el correo electrónico de contacto de la persona o compañía crear o actualizar una fila de datos COBIE.
4.2.3.2.1.2
CreatedOn
la fecha en que fue creado o actualizado por la persona o empresa identificada en el campo creado por la información proporcionada en una fila
de datos COBIE. información del sistema originario es información que permite COBIE una fila de datos COBIE que se hace referencia de nuevo
a los programas de ordenador que generó inicialmente esa información.
Si es compatible con el software del ordenador, esta información permite que los datos sean COBIE
sincronizado con el software del ordenador de origen. información de sistema de origen sólo es necesario si la información proporcionada en una
fila determinada de datos COBIE se produce a través de programas de computación. Originario de información del sistema se compone de:
4.2.3.2.1.3
ExternalSystem
el nombre del sistema de ordenador que genera la fila de datos COBIE.
4.2.3.2.1.4
ExternalObject
el nombre del objeto de datos dentro del sistema informático que contiene los datos proporcionados en una fila determinada de datos COBIE. Los valores por
defecto para el objeto externo son las entidades asociadas IFC que se asignan (y aquellos que están excluidos) cuando la transformación de los datos de la
IFC para una fila dada de datos COBIE.
4.2.3.2.1.5
ExternalIdentifier
el identificador único del objeto externo identificado que permitiría datos COBIE que se ajustará de nuevo a los datos de los que se
desarrolló en el sistema externo llamado.
4.2.3.2.2 términos y definiciones específicas de hoja de cálculo COBIE
Los siguientes términos y definiciones se proporcionan en el orden en que las hojas de trabajo COBIE se presentan en forma de hoja de cálculo
COBIE. autor común y la información del sistema de origen, descrito anteriormente, se excluyen.
4.2.3.2.2.1
contactos
Una hoja de cálculo en la hoja de cálculo COBIE. Cada fila de la hoja de trabajo Contacto identifica a una persona o empresa que se hace referencia
en otras partes de una hoja de cálculo COBIE. Contact.Email es la clave principal de esta hoja de trabajo.
4.2.3.2.2.2
Contact.Email
Una dirección de correo electrónico bien formada utiliza para identificar este contacto específico.
4.2.3.2.2.3
Contact.Category

la categoría de negocio en el que se activa el contacto específico. Si los valores permitidos no están especificados en el contrato, el valor por
defecto de esta información es la corriente OmniClass Tabla 34.
4.2.3.2.2.4
Contact.Company
el nombre de la empresa para el contacto.
4.2.3.2.2.5
Contact.Phone
el número de teléfono del contacto.
4.2.3.2.2.6
Contact.Department
el nombre del departamento para el contacto.
4.2.3.2.2.7
Contact.OrganizationCode
el código de organización para el contacto.
4.2.3.2.2.8
Contact.GivenName
Si el contacto es una persona, el nombre dado del Contacto
4.2.3.2.2.9
Contact.FamilyName
El contacto es una persona, el nombre del contacto de la familia
4.2.3.2.2.10
Contact.Street
la dirección de la calle para el contacto.
4.2.3.2.2.11
Contact.PostalBox
la dirección de la caja postal para el contacto.
4.2.3.2.2.12
Contact.Town
la dirección de la ciudad o la ciudad para el contacto.
4.2.3.2.2.13
Contact.StateRegion
el estado o la dirección regional para el contacto.
4.2.3.2.2.14
Contact.PostalCode
la cremallera, o el código postal, la dirección del contacto.
4.2.3.2.2.15
Contact.Country
el país para el contacto.
4.2.3.2.2.16
facililty
una hoja de cálculo en la hoja de cálculo COBIE. Sólo puede haber una fila en la hoja de trabajo de instalación. Proyectos compuestos por múltiples
instalaciones, se describirán mediante hojas de cálculo COBIE separadas. Facility.Name es la clave principal de esta hoja de trabajo.

4.2.3.2.2.17
Facility.Name
el nombre de la instalación tal como aparece en los dibujos de diseño, o como se especifique lo contrario en el contrato.
4.2.3.2.2.18
Facility.Category
la categoría de instalación descrito por el conjunto de datos COBIE. Si los valores permitidos no están especificados en el contrato, el valor por defecto de
esta información es la corriente OmniClass Tabla 11.
4.2.3.2.2.19
Facility.ProjectName
el nombre del proyecto tal como aparece en los dibujos de diseño, o como se especifique lo contrario en el contrato.
4.2.3.2.2.20
Facility.SiteName
el nombre del sitio tal como aparece en los dibujos de diseño, o como se especifique lo contrario en el contrato.
4.2.3.2.2.21
Facility.LinearUnits
la unidad de medida asociada aplica a toda la información COBIE distinta de la que se encuentra en el atributo y hojas de trabajo de impacto.
4.2.3.2.2.22
Facility.AreaUnits
4.2.3.2.2.23
Facility.VolumeUnits
4.2.3.2.2.24
Facility.CurrencyUnit
4.2.3.2.2.25
Facility.AreaMeasurement
el método de medición asociada utilizada para calcular espacial son de medición aplicado a toda la información COBIE distinta de la que se
encuentra en la hoja de atributos.
4.2.3.2.2.26
Facility.ExternalSiteObject
para información que se origina en los modelos IFC esta información es un identificador de objeto adicional, permitiendo que la información acerca de esta
instalación que se hace referencia de nuevo a los programas de ordenador que generó inicialmente esa información.
4.2.3.2.2.27
Facility.ExternalSiteIdentifier

4.2.3.2.2.28
Facility.ExternalFacilityObject
4.2.3.2.2.29
Facility.ExternalFacilityIdentifier
4.2.3.2.2.30
Facility.Description
una descripción de texto general de la instalación.
4.2.3.2.2.31
Facility.ProjectDescription
una descripción de texto general del proyecto.
4.2.3.2.2.32
Facility.SiteDescription
una descripción de texto general del sitio.
4.2.3.2.2.33
Facility.Phase
la designación de la fase del proyecto se refleja en un conjunto de datos COBIE dado.
4.2.3.2.2.34
piso
una hoja de cálculo en la hoja de cálculo COBIE. Los suelos son de los niveles verticales de una instalación vertical. áreas geográficas, como el sitio de una
instalación, también se pueden identificar en la hoja de planta. Floor.Name es la clave principal de esta hoja de trabajo.
4.2.3.2.2.35
Floor.Name
el nombre de la planta tal como aparece en los documentos de contrato, tales como dibujos de diseño.
4.2.3.2.2.36
Floor.Category
una clasificación del tipo de información contenida dentro de una fila. Si los valores permitidos no están especificados en el contrato, los valores por
defecto son: “piso”, “Techo”, y “Sitio”.
4.2.3.2.2.37
Floor.Description
una descripción de texto general de la planta.
4.2.3.2.2.38
Floor.Elevation
elevación en la parte superior de la estructura de piso. Si los valores permitidos no están especificados en el contrato, el valor por defecto se mide como un
valor relativo en comparación con el dato instalaciones.
4.2.3.2.2.39
Floor.Height

distancia entre la parte superior de la estructura de suelo al fondo de la estructura anterior. Típicamente aplicable a filas que tienen la Floor.Category de
“piso”.
4.2.3.2.2.40
Espacial
una hoja de cálculo en la hoja de cálculo COBIE. Los espacios son la descomposición horizontal del suelo en áreas que tienen el propósito funcional
común y el usuario. Verticalmente, espacios van desde la parte superior del suelo a la base de la losa superior. espacio ocupado se extiende hasta la
parte inferior del techo según lo expresado por Space.UsableHeight. Los grandes espacios que tienen más de un solo propósito funcional o usuario se
pueden separar en los espacios individuales. Los espacios también se pueden usar en pisos de tipo “techo” o “sitio” para identificar las regiones
espaciales fuera de una cámara instalación. Space.Name es la clave principal de esta hoja de trabajo.
4.2.3.2.2.41
Space.Name
la Space.Name debe coincidir con el valor encontrado en los dibujos de diseño en la fase de proyecto equivalente de la entrega actual.
4.2.3.2.2.42
Space.Category
la categoría de espacio descrito por el conjunto de datos COBIE. Si los valores permitidos no están especificados en el contrato, el valor por defecto de
4.2.3.2.2.43
Space.FloorName
una clave externa que identifica la COBie.Floor.Name.
4.2.3.2.2.44
Space.Description
la descripción del espacio de encontrar en los dibujos de diseño en la fase de proyecto equivalente del entregable actual.
4.2.3.2.2.45
Space.RoomTag
señalización proporcionada para cada espacio. Señalización aplica a las puertas, si es diferente, se identifica como registros de atributos relacionados con cada
puerta aplicable. La información que aquí es equivalente a la encontrada en los envios construcción de señalización.
4.2.3.2.2.46
Space.UsableHeight
la distancia desde la parte superior del piso terminado a fondo del techo. Si no hay límite a continuación, este valor debe coincidir con Floor.Height.
4.2.3.2.2.47
Space.GrossArea
área de espacio total como se especifica en el contrato de diseño y calculado por el Facility.AreaMeasurement identificado.
4.2.3.2.2.48
Space.NetArea
áreas de espacios utilizables según lo especificado en el contrato de diseño y calculado por el Facility.AreaMeasurement identificado
Zona
4.2.3.2.2.49

una hoja de cálculo en la hoja de cálculo COBIE. Las zonas son agregaciones de espacios que proporcionan algún propósito común.
Zone.Name, Zone.Category, y Zone.SpaceName proporcionan la clave para este compuesto
hoja de cálculo.
4.2.3.2.2.50
Zone.Name
el nombre de la función específica realizada por un grupo de espacios dentro de un dado
4.2.3.2.2.51
Zone.Category
defecto son: “zona de circulación”, “Zona de Iluminación”, “Zona de alarma de incendio”, “Zona de Preservación Histórica”, “Zona de ocupación”, y “zona
de ventilación”.
4.2.3.2.2.52
Zone.SpaceNames
una clave externa que identifica la COBie.Space.Name. La designación plural de “SpaceNames” que indican el uso de una lista delimitada de
valores Space.Name se deprecia en COBIE versión 2.4.
4.2.3.2.2.53
Zone.Description
una descripción de texto general de la zona.
4.2.3.2.2.54
Tipo
una hoja de cálculo en la hoja de cálculo COBIE. Los tipos son los diferentes productos y equipos que se instalarán en la instalación. Type.Name es la
clave principal de esta hoja de trabajo.
4.2.3.2.2.55
Type.Name
la Type.Name debe coincidir con el valor encontrado en los horarios de dibujo de diseño en la fase de proyecto equivalente de la entrega actual.
4.2.3.2.2.56
Tipo Type.Category
la categoría de tipo descrito por el conjunto de datos COBIE. Si los valores permitidos no están especificados en el contrato, el valor por defecto de
4.2.3.2.2.57
Type.Description
una descripción de texto general del tipo. Si la descripción está presente en desging dibujos horarios, este valor debe coincidir.
4.2.3.2.2.58
Type.Asset
tipo A clasificación del activo dentro de una fila. Si los valores permitidos no están especificados en el contrato, los valores por defecto
son: “fijo” y “móvil”.
4.2.3.2.2.59
Type.Manufacturer
durante la fase de construcción y de traspaso: el Contact.Email del producto instalado. Durante la planificación y la fase de diseño: no
aplicable.
4.2.3.2.2.60
Type.ModelNumber

durante la fase de construcción y entrega: el número de modelo de la fabricación del producto instalado. Durante la planificación y la fase
de diseño: no aplicable.
4.2.3.2.2.61
Type.WarrantyGuarantorParts
anillo en D construcción y fase de entrega: el Contact.Email de la parte, o partes, responsable de piezas de repuesto durante el
periodo de garantía. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.62
Type.WarrantyDurationParts
durante la fase de construcción y de traspaso: la longitud del período de garantía para piezas de recambio proporcionadas por el fabricante del
producto. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.63
Type.WarrantyGuarantorLabor
durante la fase de construcción y entrega: el Contact.Email de la parte, o partes, responsable de los costos de mano de obra durante el periodo de
garantía. Típicamente, el mismo que Type.WarrantyGuarantorParts. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.64
Type.WarrantyDurationLabor
durante la fase de construcción y entrega: la longitud del período de garantía para reparaciones de trabajo proporcionadas por el fabricante del
producto. Típicamente, el mismo que Type.WarrantyDurationParts. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.65
Type.WarrantyDurationUnit
la identificación de la unidad de medida asociada con los valores encontrados en Type.WarrantyDurationParts y Type.WarrantyDurationLabor.
Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “mes” y “años”.
4.2.3.2.2.66
Type.ReplacementCost
durante la fase de construcción y entrega: precio de venta sugerido del fabricante para este tipo. Durante la planificación y la fase de
diseño: no aplicable.
4.2.3.2.2.67
Type.ExpectedLife
durante la fase de transferencia: la vida útil esperada del tipo de producto dado el nivel de servicio dentro de la instalación. Durante la planificación, el
diseño y la fase de construcción: se deja en blanco a menos que la realización de estudios de coste total de propiedad.
4.2.3.2.2.68
Type.DurationUnit
la identificación de la unidad de medida asociada con el valor encontrado en Type.ExpectedLife. Si los valores permitidos no están especificados
en el contrato, los valores por defecto son: “mes” y “años”.
4.2.3.2.2.69
Type.Warranty
Descripción descripción de texto de la garantía.
4.2.3.2.2.70
Type.NominalLength
una medida aproximada de la caja delimitadora que rodea el tipo de producto.

4.2.3.2.2.71
Tipo. Ancho nominal
4.2.3.2.2.72
Type.NominalHeight
4.2.3.2.2.73
Type.ModelReference
durante la construcción y la entrega de fase: catálogo o referencia de recurso del fabricante, tales como la página web, donde la información tope
con el tipo de producto instalado puede ser encontrado. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.74
Type.Shape
durante la fase de planificación y diseño: las limitaciones específicas que deben estar / han sido considerados durante el proceso de
especificación. Durante la fase de construcción y de traspaso: la descripción de texto de la información asociada encontrado en una hoja de datos
de producto del producto.
4.2.3.2.2.75
Type.Size
4.2.3.2.2.76
Type.Color
4.2.3.2.2.77
Type.Finish
4.2.3.2.2.78
Type.Grade
4.2.3.2.2.79
Type.Material
4.2.3.2.2.80
Type.Constituents

4.2.3.2.2.81
Type.Features
4.2.3.2.2.82
Type.AccessibilityPerformance
4.2.3.2.2.83
Type.CodePerformance
4.2.3.2.2.84
Type.SustainabilityPerformance
Componente
4.2.3.2.2.85
una hoja de cálculo en la hoja de cálculo COBIE. Los componentes son los casos individuales de los productos identificados por tipo.
Component.Name es la clave principal de esta tabla.
4.2.3.2.2.86
Nombre del componente
la Component.Name debe coincidir con el valor encontrado en los horarios de dibujo de diseño en la fase de proyecto equivalente de la
entrega actual. Para el equipo programado por tipo (y no de componentes) nombrar los requisitos para garantizar nombres únicos para cada
componente se especificarán en el contrato.
4.2.3.2.2.87
Component.TypeName
una clave externa que identifica la COBie.Type.Name.
4.2.3.2.2.88
Component.Space
una clave externa que identifica la COBie.Space.Name. Para componentes no contenidos en un solo espacio, el valor se referirá al
espacio desde el que es más probable que se mantenga el equipo.
4.2.3.2.2.89
Descripción de Componente
una descripción de texto general del componente.
4.2.3.2.2.90
Component.SerialNumber
el número de serie de los equipos instalados. Component.SerialNumber debe coincidir con el valor que se encuentra en las placas de los equipos
instalados. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.91

Component.InstallationDate
la fecha en que se colocó el producto o equipo en su ubicación final. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.91
Component.WarrantyStartDate
la fecha en que se enciende por primera vez el producto o equipo. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.92
Component.TagNumber
si se requiere una etiqueta para ser fijada en el producto o el equipo durante la construcción, este valor es la designación para este producto o
equipos que se encuentran en la etiqueta asociada. Durante la planificación y la fase de diseño: no aplicable. Durante la planificación y la fase de
diseño: no aplicable.
4.2.3.2.2.93
Component.BarCode
el código de barras se encuentra en la placa de identificación instalada. Durante la planificación y la fase de diseño: no aplicable.
4.2.3.2.2.94
Component.AssetIdentifier
un identificador alternativa para el componente específico que se utilizará como definido por contrato asociado.
4.2.3.2.2.95
Sistema
una hoja de cálculo en la hoja de cálculo COBIE. Los sistemas son agregaciones de componentes que proporcionan alguna función común.
System.Name, System.Category, y proporcionan la System.ComponentNames
clave compuesta para esta hoja de trabajo.
4.2.3.2.2.96
System.Name
el nombre de la función específica realizada por un grupo de componentes dentro de un System.Category dado.
4.2.3.2.2.97
System.Category
la categoría del sistema descrito por el conjunto de datos COBIE. Si los valores permitidos no están especificados en el contrato, el valor por
defecto de esta información es la corriente OmniClass Tabla 21.
4.2.3.2.2.98
System.ComponentNames
una clave externa que identifica la COBie.Component.Name. La designación plural de “ComponentNames” que indican el uso de una lista
delimitada de valores Component.Name se deprecia en COBIE versión 2.4 a favor de la utilización de una sola fila para cada
System.Component.
4.2.3.2.2.99
Descripción del sistema
una descripción de texto general del sistema.
4.2.3.2.2.100
Asamblea
una hoja de cálculo en la hoja de cálculo COBIE. Ensamblajes son tipos (o componentes) que contienen otros tipos o (componentes).
Assembly.Name es la clave principal de esta tabla.
4.2.3.2.2.101
Assembly.Name

el nombre del conjunto identifica un tipo o componente que posee o encierra otros tipos o componentes.
4.2.3.2.2.102
Assembly.SheetName
especifica las referencias en esta fila como perteneciente a los datos COBIE ya sea en el “tipo” u hoja de trabajo “Componente”.
4.2.3.2.2.103
Assembly.ParentName
identifica el la COBie.Type.Name o COBie.Component.Name de la envolvente objeto
Assembly.ChildNames.
4.2.3.2.2.104
Assembly.ChildNames
identifica el COBie.Type.Name o COBie.Component.Name de los objetos propiedad o cerrados por el Assembly.ParentName.
4.2.3.2.2.105
Assembly.AssemblyType
una clasificación del tipo de información contenida dentro de una fila. Si los valores permitidos no están especificados en el contrato, los
valores por defecto son: “fijo”, “opcional”, “incluido”, “Excluidos”, “Capa”, “Patch”, y “Mix”.
4.2.3.2.2.106
Assembly.Description
una descripción de texto general del montaje.
Conexión
4.2.3.2.2.107
una hoja de cálculo en la hoja de cálculo COBIE. Conexiones describen las conexiones lógicas entre los datos COBIE, ya sea en el “tipo” u hoja
de trabajo “Componente”. Connection.Name es la clave principal de esta tabla.
4.2.3.2.2.108
Connection.Name
el nombre de la conexión entre las dos partes identificó una fila de datos COBIE.
4.2.3.2.2.109
Connection.ConnectionType
defecto son: “Control”, “flujo”, “Volver”, “suministro”, y “estructural”.
4.2.3.2.2.110
Connection.SheetName
especifica las referencias en esta fila como perteneciente a los datos COBIE ya sea en el “tipo” u hoja de trabajo “Componente”.
4.2.3.2.2.111
Connection.RowName1
una clave externa que identifica la COBie.Type.Name o COBie.Component.Name aguas arriba.
4.2.3.2.2.112
Connection.RowName2
una clave externa que identifica la COBie.Type.Name aguas abajo o COBie.Component.Name.
4.2.3.2.2.113

Connection.RealizingElement
el objeto, en su caso, que crea la conexión.
4.2.3.2.2.114
Connection.PortName1
el nombre del puerto de conexión de salida en Connection.RowName1
4.2.3.2.2.115
Connection.PortName2
el nombre del puerto de conexión de entrada en Connection.RowName2
4.2.3.2.2.116
Connection.Description
una descripción general de la conexión de texto
4.2.3.2.2.117
repuesto
una hoja de cálculo en Cobie la hoja de cálculo. Piezas de registros identifican las piezas de repuesto in situ, piezas de recambio y lubricantes
necesarios para mantener la instalación. Spare.Name y Spare.TypeName forman la
clave compuesta para esta hoja de trabajo.
4.2.3.2.2.118
Spare.Name
El nombre del artículo.
4.2.3.2.2.119
Spare.Category
defecto son: “Parte”, “PartSet”, “lubricante”, “Otros”, “repuesto”, y “SpareSet”.
4.2.3.2.2.120
Spare.TypeName
4.2.3.2.2.121
Spare.Suppliers
una clave externa que identifica la COBie.Contact.Name de las empresas proveedoras de piezas de repuesto.
4.2.3.2.2.122
Spare.Description
una descripción de texto general de la llanta de repuesto.
4.2.3.2.2.123
Spare.SetNumber
una descripción general de texto, en su caso, identificar el número de pieza juego de repuesto del fabricante.
4.2.3.2.2.124
Spare.PartNumber
una descripción general de texto, en su caso, el número de identificación de piezas de repuesto del fabricante.
4.2.3.2.2.125 de
recursos
una hoja de cálculo en la hoja de cálculo COBIE. Los registros de recursos a identificar las herramientas, materiales, y la formación necesaria para mantener
la instalación. Resource.Name es la clave principal de esta tabla.

4.2.3.2.2.126
Resource.Name
el nombre del recurso que se requiere para ser utilizado en el proyecto. Este recurso puede ser compartido a través de varios trabajos.
4.2.3.2.2.127
Resource.Category
una clasificación del tipo de información contenida dentro de una fila. Si los valores permitidos no están especificados en el contrato, los valores por defecto
son: “Herramientas” “Trabajo”, “Material”, y “Formación”.
4.2.3.2.2.128
Resource.Description
una descripción general del texto del recurso.
4.2.3.2.2.129
Trabajo
una hoja de cálculo en la hoja de cálculo COBIE. registros de trabajo identificar la variedad de trabajo que se requiere para operar, mantener,
arranque, parada, solucionar un COBie.Type dado. Job.Name, Job.TypeName y Job.TaskNumber crear la clave de compuesto para esta hoja
de trabajo.
4.2.3.2.2.130
Job.Name
el nombre del trabajo
4.2.3.2.2.131
Job.Category
defecto son: “Inspección”, “Funcionamiento”, “PM”, “seguridad”, “parada” “ajuste”, “Calibración”, “Emergencia”, “Puesta en marcha”, El “control” y
“Trouble”.
4.2.3.2.2.132
Job.Status
defecto son: “no ha comenzado”, “Iniciado”, y “Completado”.
4.2.3.2.2.133
Job.TypeName
4.2.3.2.2.134
Job.Description
una descripción de texto general del trabajo. En general, existen tres usos de este campo. En primer lugar, la Job.Description puede contener una
descripción general del trabajo, con todos los pasos descritos en un documento asociado. En segundo lugar, la Job.Description puede contener el conjunto
completo de todos los pasos numerados. Para ayudar CMMS / CAFM proveedores de estos pasos se deben separar con un punto y coma. Por último, el
Job.Description puede contener uno de varios pasos con enlaces utilizando el Job.TaskNumber y Job.Priors.
4.2.3.2.2.135
Job.Duration
cantidad de tiempo necesario para realizar el trabajo.
4.2.3.2.2.136
Job.DurationUnit
unidad de tiempo asociada con Job.Duration.

4.2.3.2.2.137
Job.Start
la longitud de tiempo, a partir de la entrega del conjunto de datos COBIE cuando la siguiente aparición de la trabajo debe tener lugar.
4.2.3.2.2.138
Job.TaskStartUnit
la unidad de tiempo asociado con Job.Start.
4.2.3.2.2.139
Job.Frequency
la longitud de tiempo entre cada período de servicio
4.2.3.2.2.140
Job.FrequencyUnit
la unidad de tiempo asociada con Job.Frequency.
4.2.3.2.2.141
Job.TaskNumber
si Job.Description contiene una serie de operaciones individuales, esto es los números enteros no nulos de identificación utilizados para hacer
referencia a cada paso. Job.TaskNumber se convierte en la tercera parte de la clave compuesta, si Job.Description contiene una serie de operaciones
individuales; de lo contrario, se ignora. La primera Job.Description en la serie tendrá un valor de “0” y proporcionar la información general sobre el
trabajo cuyas tareas seguir.
4.2.3.2.2.142
Job.Priors
Si Job.Description contiene una serie de operaciones individuales, esta es una lista separada por comas de la Job.TaskNumber para todos los
trabajos anteriores. La primera Job.Description en la serie tendrá un valor de “0”.
4.2.3.2.2.143
Job.ResourceNames
una coma lista de claves externas que contienen valores Resource.Name delimitada.
4.2.3.2.2.144
Impacto
una hoja de cálculo en la hoja de cálculo COBIE. registros de impacto identifican la salud, la seguridad económica, o
impactos ambientales relacionados con los activos que se encuentran en las instalaciones. Impact.Name es la clave principal de esta hoja de trabajo.
4.2.3.2.2.145
Impact.Name
el nombre del impacto.
4.2.3.2.2.146
Impact.ImpactType
defecto son: “Costo”, “climatechange”, “PrimaryEnergyConsumption”
4.2.3.2.2.147
Impact.ImpactStage
una clasificación del tipo de información contenida dentro de una fila. Si los valores permitidos no están especificados en el contrato, los valores
por defecto son: “Producción”, “Instalación”, “Mantenimiento”, “Reserva”, “uso”, y “reutilización”.
4.2.3.2.2.148

Impact.ImpactStage
una clasificación de la etapa del ciclo de vida de la información contenida dentro de una fila. Si los valores permitidos no están especificados en el
contrato, los valores por defecto son: “Producción”, “Instalación”, “Mantenimiento”, “Reserva”, “uso”, y “reutilización”.
4.2.3.2.2.149
Impact.SheetName
especifica una referencia a los datos requeridos COBIE en cualquier otra hoja de trabajo COBIE.
4.2.3.2.2.150
Impact.RowName
una clave externa que identifica la fila de la Impact.SheetName asociado.
4.2.3.2.2.151
Impact.Value
una cuantificación del impacto descrito en una fila dada.
4.2.3.2.2.152
Impact.ImpactUnit
por defecto son: “moneda”, “kgCO2e”, “MJ”, “sí”, o “n / a”.
4.2.3.2.2.153
Impact.LeadInTime
Se espera que una descripción de la cantidad de tiempo antes del impacto.
4.2.3.2.2.154
Impact.Duration
una descripción de la longitud de tiempo durante el cual se produce el impacto.
4.2.3.2.2.155
Impact.LeadOutTime
una descripción de la cantidad de tiempo después del impacto antes de que las hojas de vida de ciclo.
4.2.3.2.2.156
Impact.Description
una descripción de texto general del impacto.
Documento
4.2.3.2.2.157
una hoja de cálculo en la hoja de cálculo COBIE. registros de documentos identifican los archivos externos que proporcionan información asociada con
los datos en un entregable COBIE dado. Document.Name, Document.SheetName,
Document.RowName, Document.Stage comprenden la clave principal de esta hoja de trabajo.
4.2.3.2.2.158
Document.Name
el nombre del documento.
4.2.3.2.2.159
Document.Category
por defecto son: “Preconstruction Presentaciones”, “Taller Dibujos”, “modelos” “Datos del producto”, “Diseño de Datos”, “informes de ensayo”,
“Certificados”, “las instrucciones del fabricante ”,‘informes de campo del fabricante’,‘Operación y Mantenimiento’,‘Presentaciones de
liquidación’,‘Contrato Dibujos’,“Design Review

Comentario”,‘Especificaciones’,‘solicitud de información’,‘Requisitos del cliente’,‘Especificaciones del Contrato’,‘contrato de

dibujos’,‘Solicitudes de Información’,‘contrato Modificaciones’y‘lista de verificación Items’.
4.2.3.2.2.160
Document.ApprovalBy
defecto son: “la aprobación del propietario”, “contratista certificado”, y “sólo información” /
4.2.3.2.2.161
Document.Stage
una clasificación del tipo de información contenida dentro de una fila. Si los valores permitidos no están especificados en el contrato,
los valores por defecto son: “As Built”, “Enviado”, “Aprobado”, “requisito exacto”, “exigencia máxima”, “requisito mínimo” y “requisito”.
4.2.3.2.2.162
Document.SheetName
especifica las referencias en esta fila como perteneciente a los datos COBIE en cualquier otra hoja de trabajo COBIE.
4.2.3.2.2.163
Document.RowName
una clave externa que identifica la fila de la Document.SheetName asociado.
4.2.3.2.2.164
Document.Directory
la ruta de acceso al archivo. Si COBIE se entrega en un medio portátil el directorio debe ser el nombre de la ruta relativa del archivo COBIE
al documento referenciado. Si el archivo COBIE referencia, los documentos que están disponibles en la World Wide Web, se incluirá el
nombre de la ruta completa al documento que incluye el protocolo de Internet utilizado. En todos los casos el directorio documento debe
incluir el arrastre “/” de todos los nombres de ruta.
4.2.3.2.2.165
Document.File
el nombre del archivo, la extensión de archivo, que contiene la información asociada.
4.2.3.2.2.166
Document.Description
una descripción de texto general de la descripción.
4.2.3.2.2.167
Referencia de documento
si es diferente de la Document.Directory/Document.File esto es una referencia a los documentos proporcionado por catálogos o sitios web de los
fabricantes
4.2.3.2.2.168
Atributo
una hoja de cálculo en la hoja de cálculo COBIE. Atribuir registros identifican los archivos externos que proporcionan información asociada con
los datos en un entregable COBIE dado. Attribute.Name, Attribute.SheetName,
Attribute.RowName, Attribute.Category comprende la clave compuesta para esta hoja de trabajo.
4.2.3.2.2.169
Attribute.Name
El nombre del atributo.
4.2.3.2.2.170
Attribute.Category

una clasificación del tipo de información contenida dentro de una fila. Si los valores permitidos no están especificados en el contrato,
los valores por defecto son: “As Built”, “Enviado”, “Aprobado”, “requisito exacto”, “exigencia máxima”, “requisito mínimo” y “requisito”.
4.2.3.2.2.171
Attribute.SheetName
4.2.3.2.2.172
Nombre Attribute.Row
una clave externa que identifica la fila de la Attribute.SheetName asociado.
4.2.3.2.2.173
Attribute.Value
El valor del atributo.
4.2.3.2.2.174
Attribute.Unit
la unidad que define el valor del atributo.
4.2.3.2.2.175
Attribute.Description
una descripción general del texto del atributo.
4.2.3.2.2.176
Attribute.AllowedValues
una coma lista de uno o más valores permitidos delimitada.
Coordinar
4.2.3.2.2.177
una hoja de cálculo en la hoja de cálculo COBIE. Registros de coordenadas identifican información geométrica simple asociado con los
datos en un entregable COBIE dado. Coordinate.Name es la clave principal de esta hoja de trabajo.
4.2.3.2.2.178
Coordinate.Name
el nombre de la coordenada.
4.2.3.2.2.179
Coordinate.Category
una clasificación del tipo de información contenida dentro de una fila. Si los valores permitidos no están especificados en el contrato, los valores por defecto
son: “punto”, “lineendone”, “lineend de dos”, “caja inferior izquierda”, y “caja superior derecha”.
4.2.3.2.2.180
Coordinate.SheetName
especifica las referencias en esta fila como perteneciente a los datos COBIE en un COBie.Facility, COBie.Floor, COBie.Space, COBie.Type
u hoja de trabajo COBie.Coordinate.
4.2.3.2.2.181
Coordinate.RowName
una clave externa identificar una fila específica en el Coordinate.SheetName.
4.2.3.2.2.182
Coordinate.CoordinateXAxis
coordenada relativa del objeto referenciado.

4.2.3.2.2.183
Coordinate.CoordinateYAxis
4.2.3.2.2.184
Coordinate.CoordinateZAxis
4.2.3.2.2.185
Coordinate.ClockwiseRotation
la rotación del objeto referenciado alrededor del punto identificado, en su caso.
4.2.3.2.2.186
Coordinate.ElevationalRotation
4.2.3.2.2.187
Coordinate.YawRotation -
4.2.3.2.2.188
Edición
una hoja de cálculo en la hoja de cálculo COBIE. registros de emisión identifican permitir el intercambio de procesos de negocio y generación de informes
excepción información relacionada con otras partes de un entregable COBIE dado. Issue.Name, Issue.SheetName, Issue.RowName comprenden la tecla
compuesto para esta hoja de trabajo.
4.2.3.2.2.189
Issue.Name
el nombre de la coordenada.
4.2.3.2.2.190
Issue.Type
una clasificación del tipo de información contenida dentro de una fila. Si los valores permitidos no están especificados en el contrato, los
valores por defecto son: “Cambio”, “Demanda”, “Coordinación”, “ambiental”, “Función”, “IndoorAirQuality”, “Instalación”, “RFI”, “seguridad”,
y “Specification”.
4.2.3.2.2.191
Issue.Risk
defecto son: “Muy Alto”, “Alto”, “moderado”, “Bajo”, y “Desconocido”.
4.2.3.2.2.192
Issue.Chance
defecto son: “Se ha producido”, “Alto”, “moderado”, “Bajo”, y “Desconocido”.
4.2.3.2.2.193
Issue.Impact
defecto son: “Muy Alto”, “Alto”, “moderado”, “Bajo”, y “Desconocido”.
4.2.3.2.2.194
Issue.SheetName1

4.2.3.2.2.195
Issue.RowName1
una clave externa identificar una fila específica en el tema. SheetName1.
4.2.3.2.2.196
Issue.SheetName2
4.2.3.2.2.197
Issue.RowName2
una clave externa identificar una fila específica en el tema. SheetName2.
4.2.3.2.2.198
Issue.Description
una descripción de texto general sobre el tema.
4.2.3.2.2.199
Issue.Owner
una clave externa que identifica la COBie.Contact.
4.2.3.2.2.200
Issue.Mitigation
una descripción de texto general de la mitigación.
4.2.4 Símbolos y términos abreviados
Comentario del autor Editorial: La lista de símbolos y abreviaturas no era necesaria en las comunicaciones de EE.UU. NBIMS- ™ V2. La información aquí
proporcionada refleja la compilación de los términos y definiciones que se encuentran en los Estados Unidos NBIMS-™ V2 y actualizado para la versión
actual COBIE. Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación Subcomité para la presentación de Intercambio
de Información revisados, la información proporcionada en esta sección debe considerarse como un cambio moderado.
4.2.4.1
AEC
arquitectura, ingeniería y construcción
4.2.4.2
BAMie
formato de intercambio de información de gestión de automatización de edificios
4.2.4.3
BIM
el modelado de información de edificios
4.2.4.4
BSA
Alliance® buildingSMART
4.2.4.5
BSI
buildingSMART Internacional
4.2.4.6

Cobie
construcción-operaciones de construcción de formato de intercambio de información
4.2.4.7
COBieLite
NIEM esquema que cumpla XML COBIE, archivos conforme a dicho esquema
4.2.4.8
FM
Gestión de instalaciones
4.2.4.9
GUID
identificador único global
4.2.4.10
CFI
clases Fundación de la Industria
4.2.4.11
ifcXML
un esquema XML para los archivos del paso de la CFI sobre la base de reglas de transformación PASO XML
4.2.4.12
IFD
marco internacional de los diccionarios
4.2.4.13
HVACie
calefacción, ventilación y formato de intercambio de información de aire acondicionado
4.2.4.14
LCIE
Formato de intercambio de información del ciclo de vida
4.2.4.15
MVD
Ver modelo de definición
4.2.4.16
NBIMS-nosotros ™
Nacional BIM-Standard Estados States®
4.2.4.17
NIBS
Instituto Nacional de Ciencias de la Construcción
4.2.4.18
NIEM
modelo de intercambio de datos
4.2.4.19
Sparkie
formato de intercambio de información del sistema eléctrico

4.2.4.20
SPF
PASO archivo físico
4.2.4.21
SpreadsheetML
un esquema XML para Microsoft Excel hoja de cálculo 2003
4.2.4.22
PASO
estándar para el intercambio de datos del producto
4.2.4.23
URI
identificador de recursos uniforme
4.2.4.24 de
EE.UU.
Estados Unidos de America
4.2.4.25
UUID
identificador único universal
4.2.4.26
WSIE
formato de intercambio de información del sistema de agua
4.2.5 documentación de procesos de negocios
Comentario del autor Editorial: Los procesos de negocio de apoyo COBIE se documentaron por primera vez en un Informe Técnico del Ejército de Estados Unidos
(East 2007). Estos modelos de negocio se han desarrollado a partir de una serie de reuniones de grupos de la industria de asesoramiento realizado en fueron
propuestos en el este de 2010. En el momento de la presentación de esta norma otro 2006 y 2007. aclaración adicional del alcance de los procesos relacionados
con el ciclo de vida de los activos de las instalaciones actualización de los procesos de negocio relacionados con Cobie se está terminando para la edición como
parte de una
Informe Técnico del Ejército de EE.UU. (Fallon 2013). El objetivo de la investigación contenida en este informe era utilizar el modelado de procesos de
negocio en conjunto con los enfoques de gestión “pobre”, como en este 2011, para comparar con los actuales procesos de negocio basados en Cobie.
Como parte de la norma COBIE actualizado NBIMS-estadounidense ™ V3, un conjunto actualizado modelos de negocio desarrollados en el último informe
se proporciona para su inclusión directa en la norma. Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación Subcomité
para los estándares de intercambio de información revisados, la información proporcionada en esta sección debe ser considerado un moderado cambio.
4.2.5.1 Los modelos de proceso proporcionadas
4.2.5.1.1 lista de procesos de negocios

• Estudiar y definir las necesidades • Desarrollar Programa - Programa de Producto
• Desarrollar criterios de diseño • Preparar la invitación a hacer una oferta y recepción de

propuestas (Pre-Diseño)
• Estudio de viabilidad técnico
• Explora Conceptos - Diseño Temprano
• Comunicar los resultados de la Decisión
• Desarrollar - Diseño esquemático
• Desarrollar Programa - Programa Espacial

• Desarrollar - Diseño Coordinado • Organizar la información de Presentación
• Realizar revisión de Presentación - Edición

• Finalizar Diseño - Diseño Final Presentación
• Preparar la invitación a hacer una oferta y recibir • proporcionar recursos

propuestas (post Diseño)
• Ejecutar las Actividades de Construcción
• Responder a consultas de propuesta
• Realizar pruebas de Equipo
• Desarrollar el Plan de Pre-Construcción
• Inspeccionar y aprobar el Trabajo
• identificar las discrepancias
• Definir, registrar y certificar
• Preparar información de Presentación - Tipo de discrepancias
producto Selección
• Cerrar
• Preparar información de Presentación - Disposición
del sistema
4.2.5.1.2 descripciones de procesos de negocio
Definición: información de las instalaciones estándar deben estar disponibles con el fin de determinar los requisitos básicos para un proyecto potencial.
El propietario identifica la necesidad y, o bien se desarrolla criterios técnicos para la instalación si no existe o utiliza criterios técnicos existentes si está
disponible. Si existe, esta información debe ser
comprobar la relevancia cada cinco años para mantener la coherencia con las necesidades generales.
4.2.5.1.2.2 Desarrollar criterios de diseño
la información relativa a equipos basados en criterios de instalación se genera temprano en el proceso de planificación por parte del propietario. Esta
información debe ser revisado para determinar su relevancia cada cinco años para mantener la coherencia con las necesidades generales.
Definición: El estudio de viabilidad permite al propietario para evaluar diferentes opciones (normalmente tres) en base a las necesidades identificadas
antes de finalizar la información específica sobre un proyecto. El arquitecto o planificador desarrolla el estudio sobre la base de la información contenida
en los Criterios de las instalaciones y los intercambios de información disciplina especificación.
4.2.5.1.2.4 comunicar los resultados de las decisiones
criterios iniciales sobre un proyecto deben ser establecidos con el fin de evaluar la viabilidad del proyecto. El propietario evalúa los criterios de
instalación, especificaciones de disciplina y estudio de viabilidad para determinar si debe o no seguir adelante con el proyecto.
Una vez que la definición del proyecto se ha establecido y aprobado, se puede producir un mayor desarrollo de los requisitos del proyecto. El
arquitecto o planificador evalúa la información contenida en el intercambio de información Definición del Proyecto para identificar las necesidades de
espacio en función del tipo de instalación. los requisitos de espacio, según el tipo de instalación, se encuentran en línea en formato de documento
electrónico y deben ser descargados. Estas

los documentos se imprimen típicamente por el usuario final. Si no existen criterios espaciales instalación estándar, debe ser creada por referencia a los tipos de
establecimientos similares.
El arquitecto o planificador evalúa la información contenida en el intercambio de información Definición del Proyecto para identificar las necesidades de
productos basados en el tipo de instalación. Requisitos para los productos según el tipo de instalación se encuentran en línea en formato de documento
electrónico y deben ser descargados. Estos documentos se imprimen típicamente por el usuario final. Si no existen criterios de productos instalación estándar,
debe ser creada por referencia a los tipos de establecimientos similares.
4.2.5.1.2.7 Preparar llamado a licitación y recibir propuestas (pre-diseño)
Una vez que se han determinado los principales criterios, del propietario del Representante prepara y distribuye una solicitud de propuesta
(RFP).
El arquitecto utiliza la información específica producida durante la pre-diseño para desarrollar una solución que refleje los requisitos indicados en
la definición del proyecto, programa espacial, y el Programa del producto. En la actualidad, el propietario requiere 6 copias en papel para ser
presentados para cada ciclo de examen. El arquitecto realiza una comprobación de QA / QC antes de enviar al representante del propietario.
Después de recibir la petición, el propietario del Representante valida los documentos (comentarios) y proporciona comentarios al arquitecto.
entonces se requieren el arquitecto y consultores para actualizar los documentos basados en los comentarios. Después de hacer revisiones, el
arquitecto vuelve a presentar.
El arquitecto desarrolla aún más el diseño Los primeros documentos de entrega aprobados para producir los documentos de diseño esquemático.
En la actualidad, el propietario requiere 6 copias en papel para ser presentados para cada ciclo de examen. El arquitecto realiza una comprobación
de QA / QC antes de enviar al representante del propietario. Después de recibir la petición, el propietario del Representante valida los documentos
y proporciona comentarios al arquitecto. entonces se requieren el arquitecto y consultores para actualizar los documentos basados en los
comentarios. Después de hacer revisiones, el arquitecto vuelve a presentar.
4.2.5.1.2.10 Desarrollar el diseño - plantilla del tipo de producto
A medida que progresa el diseño, se identifican las características de rendimiento y productos adecuados para los sistemas del edificio. tipos y
equipos del sistema se identifican por el especificador basado en los requisitos de las instalaciones. Se requieren seis copias para ser presentado
para su revisión. Algunos productos se definen con más detalle mediante la identificación de los fabricantes y los números de modelo, que cumplan
con los requisitos de diseño (BASE). En estos casos, 3 productos calificativo se enumeran
El arquitecto desarrolla aún más los documentos de entrega al diseño esquemático aprobados para producir los documentos de diseño
coordinado. Además, los sistemas de construcción se coordinan para eliminar espacial
interferencias. Esta es la principal presentación coordinación antes de que el paquete de entrega final. El propietario requiere 6 copias en
papel para ser presentados para cada ciclo de examen. Debido al mayor nivel de coordinación y aumento del número de partes
interesadas que repasan, a veces son necesarias más copias. El arquitecto realiza una comprobación de QA / QC antes de enviar al
representante del propietario. Después de recibir la petición, el propietario del Representante valida los documentos y proporciona
comentarios a la

Arquitecto. entonces se requieren el arquitecto y consultores para actualizar los documentos basados en los comentarios. Después de hacer
revisiones, el arquitecto vuelve a presentar.
4.2.5.1.2.12 Desarrollar el diseño - Tipo de producto candidato
Los requisitos de rendimiento de los sistemas y equipos de construcción son más refinado y documentado por el especificador durante esta
fase. Cualquier equipo, productos o sistemas no son identificados previamente seleccionado. se observan fabricantes específicos y números
de modelo. Tres productos que califican son identificados. Seis ejemplares se presentan para cada ciclo de examen.
El diseño de paquete final es el conjunto final de documentos del contrato listos para llamado a licitación por el propietario. Esta entrega de
diseño final no requiere otra revisión por el representante del propietario.
4.2.5.1.2.14 Finalizar el diseño - tipo de producto candidato
En esta fase del proyecto, todos los tipos de equipos y sistemas deben ser identificados por el especificador. información del producto desde
la fase de diseño coordinado se incorpora en esta fase. Tres (3) productos autorizados para cada tipo requerido deben estar inscritos.
4.2.5.1.2.15 Preparar llamado a licitación y recibir propuestas (post-diseño)
Una vez que el diseño está completo, el propietario empaqueta el diseño de la información de documentos finales, junto con otra información del propietario
suministrado (por ejemplo, los términos contractuales) y crea una Solicitud de Propuestas (RFP) del paquete. Este se convierte en el conjunto oficial de la oferta.
Antes de finalizar una propuesta de oferta, el contratista normalmente solicita información adicional o aclaración de algunos documentos de licitación.
El contratista está obligado a desarrollar un plan de pre-construcción que describe cómo el contratista hará disposiciones para la gestión de la
construcción de la instalación. Esto se envía como un paquete de presentación. Consulte el intercambio paquete de presentación para todos los
requisitos relacionados con la transmisión y el manejo de los envios Pre- plan de construcción.
El contratista presenta una solicitud de información (RFI) para pedir una aclaración durante el proceso de construcción.
Estas preguntas pueden ser debido a, pero no limitado a ambigüedades o contradicciones en el
dibujos o a las condiciones del sitio.
4.2.5.1.2.19 Preparar información de presentación - selección del tipo de producto
El contratista y subcontratistas reúnen información de los productos identificados en los documentos finales de diseño y preparan los envios.
Consulte el intercambio paquete de presentación para todos los requisitos relacionados con la transmisión y el manejo de los envios de
selección del tipo de producto.

La información del contratista y subcontratistas reseña de los productos identificados en los documentos finales de diseño y preparar los
planos de taller. Consulte el intercambio paquete de presentación para todos los requisitos relacionados con la transmisión y el manejo de los
envios disposición del sistema.
El contratista organiza el envío de información requerida y crea los paquetes de presentación para ser revisados por el propietario de
Representante y / o Arquitecto. Se requieren seis copias impresas para ser presentado para su revisión.
El arquitecto y / o Subconsultores validan la de los planos proporcionados por el contratista y proporcionar comentarios. Se requieren seis
copias impresas.
Los contactos contratista un proveedor para ordenar los equipos y materiales. El Proveedor proporciona entonces una cotización al
contratista para el equipo y / o materiales. El contratista verifica las especificaciones de los equipos y / o materiales en la cita contra la
presentación de documentación aprobada y luego los somete a representante del propietario y / o arquitecto para su aprobación.
El contratista instala el equipo de construcción, los materiales y los sistemas que utilizan los planos finales de diseño, planos de instalación aprobados, los
datos del producto y las instrucciones del fabricante.
Después de que el contratista completa el proceso de instalación, los equipos / sistemas deben ser probadas mediante la activación de los
equipos. Esta prueba debe ser completada con el representante del propietario y la presencia de un representante del fabricante.
Cuando el contratista haya completado la instalación de equipos o sistemas, se envía una notificación al Arquitecto que indica el elemento
instalado está listo para la inspección / observación. El arquitecto lleva a cabo inspecciones periódicas de las obras de construcción instalada.
Los resultados de las inspecciones, incluida cualquier deficiencia con la instalación de las obras de construcción están documentados en un
informe. Si se detectan deficiencias en el informe de inspección, el contratista los corrige y luego solicita una nueva inspección.
El arquitecto crea un punzón de lista final basado en una encuesta de la obra ejecutada. El contratista corrige las deficiencias
identificadas en la lista de verificación. El arquitecto verifica que el contratista ha corregido las deficiencias en la lista de verificación
mediante la realización de un recorrido final.
El contratista reúne toda la información conforme a obra relacionada con el proyecto y envía la información al propietario. Cuatro copias suelen
ser necesarios.

4.2.5.1.3 comerciales diagramas de modelo de proceso
modelos de procesos de negocios fueron creados en un menor nivel de detalle que se requiere típicamente. Este nivel de detalle adicional se incluye para
demostrar el valor de intercambio de información centrada en los datos, en comparación con los intercambios basados en documentos típicos de la práctica
en el diseño y la industria de la construcción hoy en día. Esto permite que los propios modelos para abordar directamente la cuestión de modelo de negocio,
ya que, con intercambios centrados en datos; todas las tareas que no aportan valor añadido necesarios para trabajar con documentos pueden ser
eliminados. Cada diagrama de procesos de negocio comienza con la definición del flujo de trabajo actual del proceso. Encima de que los códigos de color
de proceso actuales que describen donde se eliminaron las tareas, automatizada, o aerodinámico se muestran en el proceso que se espera basados en
Cobie.
Cuando se utilizan estos modelos de procesos de negocio, por favor consulte la siguiente leyenda.
• Tareas eliminadas
• Las tareas automatizadas
• Tareas simplificados
• Tareas sin cambios desde LCIE proceso actual

Figura 1 Estudio / Definir las necesidades del proceso Modelo

Figura 2 Desarrollar criterios de diseño Modelo de Proceso

Figura 3 Estudio de viabilidad técnica de proceso Modelo

Figura 4 comunicar los resultados de decisiones de proceso Modelo

Figura 5 Desarrollo de Programa - Programa Modelo de espacio de proceso

Figura 6 Desarrollar Programa - Programa Modelo de Proceso Producto

Figura 7 Prepare la invitación a hacer una oferta y recibir propuestas (Pre-Diseño) Modelo de Proceso

Figura 8 Explora Conceptos - Diseño temprana Modelo de Proceso

Figura 9 Desarrollar - Diseño Esquema Modelo de Proceso

Figura 10 Desarrollar - Diseño Coordinado Modelo de Proceso

Figura 11 Plantilla del producto Tipo de proceso Modelo

Figura 12 Desarrollo de Diseño - Tipo de producto Proceso Candidato Modelo

INFORMATIONEXCHANGEST ANDARDS - COB es decir, - edad P | sesenta y cinco
Figura 13 Finalizar - Diseño final Modelo de Proceso

Figura 14 Finalizar Diseño - Tipo de producto Proceso Candidato Modelo

Proceso LCIE: Prepare la invitación a hacer una oferta y recibir propuestas (post-Diseño) | LCIE Exchange: 120 Solicitud de propuesta
El El
Representante del propietario Arquitecto Contratista
intercambio de datos intercambio de datos
120.01 Recibe
Información A / E
para la elaboración
de los documentos
de licitación
120,02
Frente producir RFP
Importar
120.03
Copia Solicitud de
Propuesta (RFP)
Paquete
120.04
120.05
Enviar solicitud de
Recibe RFP
propuesta (RFP)
Paquete
Paquete
Solicitud de
Propuesta (RFP)
LEYENDA
Tareas eliminadas tareas
automatizadas
Simplificación de Tareas
Tareas Sin cambios
Figura 15 Prepare la invitación a hacer una oferta y recibir propuestas (Post-Diseño) Modelo de Proceso

Figura 16 Respuesta a propuesta previa Modelo Consult Proceso

Figura 17 Desarrollar planes de pre-construcción Modelo de Proceso

Figura 18 identificar las discrepancias Modelo de proceso

Figura 19 Preparar información Presentación del producto Tipo de selección Modelo de Proceso

Figura 20 Sistema Modelo proceso de disposición

Figura 21 organizar la información de Presentación de Modelo de proceso

Figura 22 Realizar revisión de Presentación - Edición Presentación Modelo de Proceso

Figura 23 proporcionan recursos Modelo de proceso

Figura 24 Ejecutar Actividades de Construcción Modelo de proceso

Proceso LCIE: Ejecutar actividades de construcción | LCIE Exchange: 210 Instalación del Producto
El El
Representante del propietario Arquitecto Contratista
intercambio de datos intercambio de datos
210.01 recibir
equipo y
materiales
210,07
Recibe Informe de
instalación del producto
210.02
Compra opinión
Orden
Equipo
correctas
recibidas?
210.08
No Sí
La recepción de log
Informe de
instalación del Instalación del

producto producto
Informe 210.03.10 Entrar
210.03.20 La recepción de
Contactar al proveedor equipos y
materiales
210.03.11
210.03.21
Revisión del
Emisión correcta con la
Fabricante
orden de compra
Instrucciones de
instalación
210.03.12
Instalar equipos, materiales
y sistemas de construcción
- Registro de componentes
Datos
210,04
reformateo
Informe de
instalación del
producto
210.05
Enviar informe de
Ha terminado la
instalación del
instalación? No
producto
210,06
Transmisión de registro
Informe de
LEYENDA instalación del
Tareas eliminadas tareas producto
automatizadas
Simplificación de Tareas
Tareas Sin cambios
Figura 25 Producto Proceso de instalación del Modelo

Figura 26 Realizar pruebas Process Equipment Modelo

Figura 27 inspeccionar y aprobar Proceso de Trabajo Modelo

Figura 28 definir, registrar y certificar discrepancias Modelo de proceso

Figura 29 Modelo de proceso Closeout

4.2.5.2 modelos de procesos representativos
4.2.5.2.1 análisis de la cobertura de las partes interesadas
Las filas de la figura a continuación ilustran los actores que participan en cada procesos de negocio relacionados con COBIE. Los
procesos específicos se enumeran en cada columna.
Figura Cobertura 30 partes interesadas
4.2.5.2.2 Proceso de análisis de la cobertura
Véase la Figura 30, arriba.
4.2.5.2.3 Contrato lista entregable documental
Para cada uno de los procesos de negocio identificados en la norma COBIE se proporciona una lista de la correspondiente entrega
contraído tradicional. Esta información se proporciona como parte de la norma NBIMS- EE.UU. ™ V3 para identificar entregables basados
en documentos actuales que se pueden sustituir, en todo o en parte, por el estándar de intercambio de información se define en este
documento.
Tabla 5 Estudio y definir las necesidades Doc Lista ument
Contenido de informacion: • Programa de instalación
Contrajo Cambio / Entregable: • Criterios de instalaciones

Tabla 6 Desarrollar criterios de diseño Doc Lista ument

Contenido de informacion: • tipo de datos
• Datos del producto
Contrajo Cambio / Entregable: • disciplina Especificación
Tabla 7 Viabilidad de Estudios Técnicos D Lista OCUMENTO
Contenido de informacion: • Opciones de Estudio de Viabilidad
Contrajo Cambio / Entregable: • Estudio de factibilidad
Tabla 8 comunicar los resultados Decisi en la Lista de documentos
Contenido de informacion: • Alcance del proyecto detallado

• Información preliminar coste presupuestario
• Sitio Ubicación y Aprobación
• Análisis Economico
• Datos planificación de instalaciones
Contrajo Cambio / Entregable: • Definición del proyecto
Tabla 9 Desarrollar Programa - Espacio Pr ograma Lista de documentos
Contenido de informacion: • Requisitos de espacio en las instalaciones
Contrajo Cambio / Entregable: • Programa espacial
Tabla 10 Desarrollar Programa - Producto Programa Lista de documentos
Contenido de informacion: • Requisitos de instalación del producto
Contrajo Cambio / Entregable: • Programa de productos
Tabla 11 Preparar una invitación a subasta re Recibe Propuesta (Pre-Diseño) Lista de documentos
Contenido de informacion: • Definición del proyecto
• Programa espacial
• Programa de productos
Contrajo Cambio / Entregable: • Solicitud de Propuesta (RFP)
Tabla 12 Explora Conceptos - Diseño Lista de documentos temprana
Contenido de informacion: • Dibujos concepto de diseño

• Costo estimado
• cálculos
Contrajo Cambio / Entregable: • diseño temprano
Tabla 13 Desarrollar - Diseño S Lista de documentos chematic

Contenido de informacion: • Bases de diseño narrativo
• Diseño Dibujos esquemáticos
• Análisis de energía
• Análisis del Ciclo de Vida Costo
• Costo estimado
• Informe geotécnico
• cálculos
• Informe ambiental
• Especificaciones de contorno
Contrajo Cambio / Entregable: • diseño esquemático

• Plantilla Tipo de Producto
Tabla 14 Desarrollar - Diseño C oordinated Lista de documentos

• Diseño coordinado Dibujos
• Análisis del Ciclo de Vida de costos
• Costo estimado
• cálculos
• Formulario de Información del Proyecto
• Especificaciones de contorno
• Registro de presentación
Contrajo Cambio / Entregable: • diseño Coordinado

Tabla 15 Finalizar - Diseño Fi Lista de documentos nal

• Diseño Esquemas finales
• Análisis del Ciclo de Vida de costos
• Costo estimado
• cálculos
• Formulario de Información del Proyecto
• Datos de Control de Calidad
• Carpeta de documentación del color
• Certificación de Cumplimiento de Códigos
• Presupuesto
Contrajo Cambio / Entregable: • diseño final

• Tipo de Producto Candidato
Tabla 16 Preparar una invitación a subasta re Recibe Propuestas (Diseño Post) Lista de documentos
Contenido de informacion: • Documentos de Diseño de finales
• Presupuesto
Contrajo Cambio / Entregable: • Solicitud de Propuesta (RFP)
Tabla 17 Responder a propuesta previa En quiries Lista de documentos
Contenido de informacion: • Solicitud de aclaración
Contrajo Cambio / Entregable: • Consulta Edición (Aclaración)
Tabla 18 Desarrollar Pre-Construcción P lan Lista de documentos

Contenido de informacion: • listas de equipo
• Certificados de seguros
• Bonos de garantía
• Lista de subcontratistas propuestos

• Lista de Productores de propuestas

• Horario progreso de la construcción
• Análisis de la red del cronograma
• Calendario de precios
• Salud y Planes de Seguridad
• El plan de trabajo
• Plan de control de calidad
• Plan de Protección del Medio Ambiente
Contrajo Cambio / Entregable: • Plan de Pre-Construcción
Tabla 19 identificar las discrepancias Doc Lista ument

Contenido de informacion: • Solicitud de información
Contrajo Cambio / Entregable: • Consulta Edición (RFI)
Tabla 20 Preparar Submittal Informati en - Producto Lista de selección Tipo de documento

Contenido de informacion: • Datos del producto
• Las muestras
• Datos de diseño
• Informes de las pruebas
• certificados
• Instrucciones del fabricante
• Los informes de campo del fabricante
• Operaciones y Mantenimiento de Datos
Contrajo Cambio / Entregable: • Tipo de Producto Selección
Tabla 21 Preparar Submittal Informati en - Sistema de Distribución Lista de documentos
Contenido de informacion: • Dibujos de Taller
Contrajo Cambio / Entregable: • Disposición del sistema
Tabla 22 Organizar Submittal Informa ción Lista de documentos

Contenido de informacion: • Plan de Pre-Construcción
• Tipo de Producto Selección
• Disposición del sistema
• (Consulte la información para cada uno de estos elementos
individuales para obtener una lista completa de información
incluida).
Contrajo Cambio / Entregable: • paquete de presentación
Tabla 23 Realizar revisión de Presentación - Lista de documentos Edición presentación
Contenido de informacion: • Marcado-Up Presentación Paquete

• Comentarios sobre el de Presentación
Contrajo Cambio / Entregable: • Edición presentación

Tabla 24 proporcionan recursos Docume Lista nt

Contenido de informacion: • Orden de compra
Contrajo Cambio / Entregable: • Orden de compra
Tabla 25 Ejecutar construcción Activi lazos Lista de documentos

Contenido de informacion: • Diseño Esquemas finales
• Tipo de Producto Candidato
• Dibujos de taller aprobados
• Instrucciones del fabricante
Contrajo Cambio / Entregable: • Instalación del producto
Tabla 26 Realizar Equipo de prueba Lista de documentos

Contenido de informacion: • Resultados Equipo Prueba de inicio
Contrajo Cambio / Entregable: • Equipo de puesta en marcha Informe
Tabla 27 inspeccionar y aprobar el Trabajo Lista de documentos
Contenido de informacion: • Reportaje desde el campo de observación
Contrajo Cambio / Entregable: • inspección del producto
Tabla 28 definir, registrar y certificar Las discrepancias Lista de documentos

Contenido de informacion: • Las inspecciones de productos anteriores
• Informe final Tutorial
• Los informes de campo
Contrajo Cambio / Entregable: • Punch-lista de Emisión
Tabla 29 Lista de documentos de liquidación
Contenido de informacion: • Operaciones y manuales de mantenimiento

• Inventario del equipo Designado
• Archivos de datos de materiales
• Informe de puesta
• Especificaciones de registro
• Record (AS-construidos) Dibujos
• Final aprobado Planos de Taller
Contrajo Cambio / Entregable: • Volumen de negocios paquete
análisis entregable documental 4.2.5.2.4 Contrato
Criterios de instalaciones pueden proporcionarse en formato COBIE como plantillas de tipos de espacios específicos. Los requisitos para acabados y equipos
espaciales también pueden ser fácilmente incorporados en el formato COBIE.
Permitiendo que los tipos de espacio para ser representados en un formato Cobie es una regla de negocio adicional que se define en el proyecto previamente
señaló BPie.

4.2 5.2.4.2 Desarrollar criterios de diseño
información Tipo de producto se encuentran comúnmente en las especificaciones de construcción puede ser desarrollado como un modelo de restricción en
formato COBIE contra los tipos de productos específicos. Los requisitos específicos para tipos de productos pueden ser definidos en COBIE como atributos.
COBie.Attributes permite la especificación de propiedades como requisitos. COBie.Attributes también permite la inclusión de conjuntos permitidos de valores
y los valores opcionales.
La definición de las especificaciones del producto se puede abordar en los documentos LCIE y SPIE. Sobre la base de tales definiciones comprobación automatizada de
información específica del producto puede llevarse a cabo en muchos tipos de intercambios más tarde en el proyecto. Tenga en cuenta que estos controles no son los
mismos que los proyectos relacionados con la verificación del cumplimiento del código de construcción.
Los estudios de factibilidad que producen información para cada opción sobre los espacios de las instalaciones, equipos y otros activos pueden ser
comparados con los requisitos de los criterios técnicos. Dichos controles pueden identificar violaciónes de restricción, pero no van a evaluar la calidad del
diseño de cualquier otro de un punto de vista puramente técnico.
4.2.5.2.4.4 Comunicar los resultados de decisiones
Hay muchos aspectos de la definición del proyecto que no son compatibles con los intercambios COBIE; Sin embargo, la información sobre el alcance
del proyecto detallado puede ser comunicada.
El programa espacial puede proporcionarse en formato COBIE como tipos de espacios específicos y ejemplos de esos tipos. Los requisitos
para acabados y equipos espaciales también pueden ser fácilmente incorporados en el formato COBIE.
tipos de espacios representados por Cobie se define en el proyecto BPie se señaló anteriormente. Tenga en cuenta que el tener los criterios para cada tipo
de espacio en formato COBIE y tener los entregables del programa espacial también en formato COBIE permite automatizar la comprobación de restricción
a llevarse a cabo entre la instalación proyectada y los criterios de los propietarios.
El programa de productos se puede proporcionar en formato COBIE como tipos de espacios específicos y ejemplos de esos tipos. Los requisitos
para acabados y equipos espaciales también pueden ser fácilmente incorporados en el formato COBIE.
Tenga en cuenta que el tener los criterios para cada tipo de producto en formato COBIE y tener los productos del programa del producto también en
formato COBIE permite automatizar la comprobación de restricción a llevarse a cabo entre la instalación proyectada y el programa del propietario y
criterios especificaciones.
4.2.5.2.4.7 Preparar llamado a licitación y recibir propuesta (pre-diseño)
Si bien hay muchos aspectos de la solicitud de propuestas de diseño que no se puede representar en formato COBIE, claramente el Programa Espacial del
producto y son capaces de ser representados en Cobie.

La mayoría de los entregables producidos en la etapa inicial de diseño no son relevantes para Cobie. Al considerar diseños alternativos durante la
etapa inicial de diseño, sin embargo, el control de estas distribuciones en función de criterios de los propietarios y Espacio RFP / Programa de
productos puede ayudar al diseñador de la toma de decisiones en violación de los requisitos del propietario.
Los dibujos de arquitectura producidos en esta etapa no contienen información de activos instalación programada perteneciente a los
espacios, puertas, ventanas, fijaciones de fontanería y aparatos de iluminación. La información de estos horarios está representado en Cobie
y presentado con los dibujos.
Muchos de los entregables producidos durante el diseño tienen contenido de la información que está parcial o completamente, que se encuentra dentro del
conjunto de datos COBIE. Como resultado diseñadores pueden obtener importantes beneficios de la exportación de diseño de entregar informes utilizando los
datos requeridos por el Cobie que presentan en sus sistemas de diseño nativos. Varios resultados específicos se describen en los párrafos siguientes.
La base del diseño Narrativa, con respecto a aquellos aspectos que son necesarios para el proceso de puesta en marcha, se puede
asignar directamente al conjunto de datos COBIE. La identificación de sistemas de edificios y zonas, y los factores de diseño global puede
ser documentada en las entidades COBie.Zone, COBie.System y COBie.Attributes. Esos tipos de productos cuya base de diseño ha sido
seleccionados en este punto en el diseño pueden ser capturados a través de las entidades COBie.Type y COBie.Attribute.
Otro formato de los Fundamentos de diseño narrativo, con respecto a los detalles de la selección de los activos y sus propiedades está representado en los
dibujos de diseño como los horarios. De hojas programados de información de activos de datos de productos de diseño (plantillas tipo de producto) y hojas
de datos habitación también pueden ser exportados. Dicha información puede usarse para comprobar el diseño actual contra las fases de diseño anteriores
para los cambios, y para evaluar las solicitudes posteriores de contratistas para las selecciones de acabado y productos adecuados.
La información que sustenta una variedad de tipos de análisis de costos tales como el análisis costo del ciclo de vida y las estimaciones de costos puede ser
apoyado por Cobie. El uso de los datos para los activos a Cobie contando sería una
valiosa acceso directo al realizar la elaboración despegues. Información sobre el nivel de calidad de los activos, contenida en entidades
COBie.Type y COBie.Attribute puede apoyar tanto la estimación de costos conceptual y detallado.
La información relacionada con los requisitos para diversos productos que se encuentran en COBie.Type también puede ser usado para crear
especificaciones de esquema para el proyecto de las propiedades identificadas en el modelo COBIE. Tales aplicaciones no son de uso generalizado;
Sin embargo, la demostración de una aplicación, en diciembre de 2010 confirmó este uso potencial de los datos COBIE.
Cobie archivos no contienen los siguientes tipos de prestaciones contractuales durante la etapa de diseño: dibujos, esquemas, informes y
cálculos. La información contenida en los informes de diseño y cálculos está fuera del alcance de la especificación COBIE. Los archivos de
dibujo contienen un nivel de detalle geométrico que no es adecuado para su inclusión en COBIE. El contenido de información de dibujos, en
particular la información que se encuentra en los horarios de dibujo debe ser incluido en COBIE. De hecho, la comparación entre los dibujos
información de la programación y entregables asociados Cobie es la base para la evaluación de la calidad de la COBIE.
Además de la discusión de la cobertura de diseño entregable señaló en la sección anterior, la entrega de diseño coordinado incluye
prestaciones como el Formulario de información del proyecto y de Presentación de Registro. Estos entregables contractuales adicionales se
describen en los párrafos siguientes.

Dado que la información sobre el alcance general del proyecto está disponible a través COBIE, ya sea a través de información de atributos, o
contando objetos, áreas y volúmenes de una parte significativa de los datos del proyecto Forma menudo necesarios en esta etapa de diseño está
disponible. informes automáticos desde el diseño de productos, o directamente a partir de los datos COBIE, pueden proporcionar el primer borrador
de este informe.
Una porción del registro de presentación puede ser creado directamente de los archivos de diseño COBIE través de la identificación de una
plantilla para cada producto de la categoría. La entidad COBie.Document permite al
identificación de documentos “necesarios”. La lista de cada uno de estos documentos está, de hecho, la presentación registro. Más allá de la exigencia de una
COBie.Document del tipo “Datos del producto” para cada COBie.Type, el valor de categoría COBie.Type puede ser usado para crear un conjunto estándar de
los envios para diferentes clases de productos. Productos cuya categoría es los dispositivos de control de flujo puede requerir la presentación del informe de
la prueba, mientras que los productos clasificados como puertas metálicas pueden no requerir (por defecto) un informe de la prueba.
Además de la discusión de la cobertura de diseño entregable señaló en la sección anterior, la entrega de diseño coordinado incluye
prestaciones tales como Calidad de Datos de Control, Color Documentación Binder, Certificación de Cumplimiento de Códigos y
especificaciones de construcción. Estos entregables contractuales adicionales se describen en los párrafos siguientes.
Al igual que con la producción automatizada de una parte de la presentación de registro, entradas de COBie.Types, sus categorías y atributos podrían ser
utilizados con una plantilla de normas de control de calidad para producir una especificación de proyecto de control de calidad y / o plan para el proyecto.
Mientras que una aplicación de este tipo no existe en la actualidad, el desarrollo de plantillas basadas en las clasificaciones nacionales de tipo de producto
está dentro de un ámbito de posibles aplicaciones para automatizar la producción de entregables contrato basado en los datos COBIE.
Información sobre las selecciones de color a partir de los datos COBIE se puede utilizar para proporcionar el contorno de la carpeta de
documentación del color. chips de color específico podría proporcionarse como COBie.Documents adjuntos automatizar aún más el proceso.
Fotografías de muestras de tela y textura deben ser necesarios para la documentación del proyecto y estos pueden ser incluidos como entradas
COBie.Document. Mientras que el propietario debe ser capaz de tener una copia física de los colores y de muestras, el documento de registro
electrónico tal vez completamente genera a partir de un informe simple basado en COBie.Data.
4.2.5.2.4.12 Preparar llamado a licitación y recibir propuestas (diseño post)
El entregable de esta etapa del proyecto es la solicitud de paquete de propuesta. La inclusión de un archivo COBIE construcción-documentos
etapa, sólo a título informativo, se aseguraría de que los licitadores tienen una base más aún para sus ofertas ya que las empresas
individuales contaría constantemente información proporcionada en electrónica frente dibujo o formatos nativos.
Las preocupaciones de responsabilidad son discutibles ya que los datos COBIE coincide con los datos de programación en los dibujos. Si hay errores, entonces los
normales avanza el proceso de resolución de errores.
La captura de las solicitudes de información o aclaraciones se puede realizar directamente a través del formato de datos COBIE. El uso de
este formato en realidad aumenta el valor de la información y mejora la velocidad de procesamiento de la consulta. El valor de la información
se incrementa ya que tal información se vincula directamente con los objetos en cuestión. La velocidad de la investigación podrá ser mejorado
ya que los meta-datos contenidos en el paquete de información relacionada con el Cobie se pueden usar para enrutar el objeto a la parte
correspondiente responsable de responder a la pregunta de forma automática.

Hay muchos productos requeridos del contratista de la construcción durante la fase de pre-construcción. Los párrafos siguientes describen la
manera en que los datos COBIE pueden ser utilizados para apoyar y racionalizar tales procesos. Tal simplificación es posible ya que el contratista
producir la entrega puede utilizar los informes de los archivos de documentos de construcción de escenarios COBIE para llenar en gran parte del
contenido de esa entrega.
El primer conjunto de información proporcionada por los contratistas es a menudo las listas de empresas y personas que necesitan acceso al lugar de trabajo.
Esta lista, si se proporciona en COBie.Contacts, permite la captura de información que puede ser utilizada por el resto del proyecto de construcción. Como
instaladores de captura de datos de la placa de identificación, o agentes de puesta a identificar elementos de pinchado de la lista, los nombres de cada una de
estas personas estarán disponibles a través COBIE listas de selección desarrollados a partir del control de acceso del proyecto
listas que se actualizan a partir
COBie.Contacts medida que avanza el proyecto.
Si bien los datos COBIE no contribuirán directamente a la creación del programa de contratistas crítico Método del Camino, los vínculos entre los
activos de construcción para ser instalados en una determinada actividad y sus actividades de control de calidad y la cadena de suministro aguas
arriba, pueden estar ligados a programar las actividades. Tal capacidad, disponible como resultado de tener los datos COBIE, permite al contratista
para integrar los sistemas de datos asegurando que el trabajo sobre el proyecto puede llevarse a cabo sin ningún tipo de información que sea “entre
las grietas”. Para configurar el software de programación con el ejemplo instalación de equipos productos hojas de trabajo del equipo se va a
instalar, y dirigirlos al personal de subcontratistas asociados apoyaría directamente la capacidad de evaluar la realización de actividades específicas
del cronograma y el porcentaje de los equipos instalados en una determinada actividad.
Dadas las zonas, sistemas y equipos que se instalan en el proyecto algunos aspectos de Heath y planes de seguridad, planes de trabajo, planes de
control de calidad y planes de protección del medio ambiente pueden ser desarrollados a partir de datos COBIE. Esto se logra haciendo que las
plantillas para las clasificaciones específicas de trabajo. Cuando ese trabajo se identifica en un COBIE presentar esa parte de la plantilla se utiliza
para crear el plan específica para el proyecto.
Los párrafos anteriores se identifican entregables pre-construcción que son propensos a ser soportado por los extractos de datos basados
COBie- son identificados. También hay varios entregables pre-construcción que están fuera del alcance de los flujos de trabajo asociados con
COBIE. Estos incluyen certificados de seguros, bonos, Lista de Precios, y las listas de equipos de los contratistas.
Al igual que en la cobertura se señala en Responder a propuesta previa consultas.
4.2.5.2.4.16 Preparar información de presentación - selección del tipo de producto
Una variedad de información relacionada con Presentaciones es ya sea directamente o indirectamente, capturado en COBIE. La mayor parte de esta
información se puede vincular a conjuntos de datos COBIE través de la entidad COBie.Document. Dicha información incluye: datos del producto, datos de
diseño, informes de pruebas, certificaciones, Instrucciones, Manufacturers' Fabricantes informes de campo, y de Operaciones y Mantenimiento de datos.
Aunque no práctica común es hoy en día, varios tipos de datos de Presentación pueden proporcionarse en un formato orientado a datos usando
discretos intercambios de datos COBIE ya sea a través SpreadsheetML o versiones COBieLite directamente de los fabricantes de productos. Esa
información incluye datos del producto y de Operaciones y Mantenimiento de datos. Trabajar en otros proyectos tales como el proyecto de SPIE y
LCIE proporcionará especificaciones de contenido y formato específicos para tales intercambios de información directos.

dibujos de implantación del sistema se concibieron originalmente para ser capaz de ser proporcionada a través de Cobie, sin embargo, el trabajo adicional
sobre los proyectos HVACie, WSIE, Sparkie y BAMie han indicado que el mejor método para el intercambio de información sobre la disposición del sistema
son de dominio específico modelo de vista Definiciones . Un extracto de COBIE de los activos gestionados contenidos dentro de ese sistema de dominio
específico, por los manuales del sistema obstante, sería posible producir.
La preparación y la transmisión de Presentaciones es fuera del contexto de COBIE. Mientras que los datos basados en COBIE pueden ser el contenido
de dichos intercambios de información, LCIE define una estructura de datos de ejemplo para el intercambio de dicha información.
Al igual que en la cobertura se señala en Responder a propuesta previa consultas.
La producción de las órdenes de compra como resultado de las aprobaciones de Presentación está fuera del contexto de la COBIE. Mientras que los datos
basados en COBIE pueden ser el contenido de dichos intercambios de información, AGC-XML define una estructura de datos de ejemplo para el intercambio de
dicha información.
Durante el proceso de construcción de edificios se requiere un número de entregas de contrato específico. Algunas de estas prestaciones son
compatibles directamente, o indirectamente, por el uso de Cobie. La producción de dibujos, tales como dibujos conforme a obra y planos de
construcción de tiendas no son compatibles con Cobie. los
información de los activos prevista en estos dibujos, sin embargo, se traducen directamente a Cobie.
A medida que los activos están instalados en el proyecto de la lista de equipos instalados entregable, que se utiliza para apoyar las solicitudes de pago
contratista, tal vez directamente representado en formato COBIE. El subconjunto específico del esquema COBIE aplicable para tal intercambio se definen
en el LCIE para la especificación activo administrado.
Equipo puesta en marcha y los informes de ejecución pueden estar vinculados a los datos COBIE. Además, la puesta en marcha, o la activación, la fecha
para una determinada pieza de equipo se debe documentar en COBIE como el
COBie.Component.WarrantyStartDate. Los propios informes pueden estar vinculados a la COBie.Component específica a través de
la entidad COBie.Document.
Al igual que en la cobertura se señala en la Sección 5.2.3.2.13 Responder a propuesta previa consultas. Informes desarrollados en esta etapa se compilan
conjuntos de COBie.Issues.
Al igual que en la cobertura se señala en la Sección 5.2.3.2.13 Responder a propuesta previa consultas. Informes desarrollados en esta etapa se compilan
conjuntos de COBie.Issues.

Teniendo en cuenta que Cobie fue diseñado específicamente para capturar el paquete de construcción de traspaso de todo el contenido del paquete de
rotación pueden estar incluidos, o se hace referencia, dentro de la estructura de datos COBIE. Los párrafos siguientes describen cada una de estas
contenido de la caja de transferencia y cuando dicha información se encuentra dentro del formato COBIE.
Operaciones y Mantenimiento manuales producidos por los fabricantes pueden incluirse en COBIE en uno de los tres métodos. En primer lugar, una copia
electrónica del manual del fabricante que contiene manuales de un producto puede ser referenciado en la entidad COBie.Document y se hace referencia de
nuevo a la entidad COBie.Type asociado. En segundo lugar, el conjunto de actividades para una tarea dada puede estar directamente incluido en la hoja de
trabajo COBie.Job. Por último, si las actividades individuales dentro de todo el conjunto de actividades requieren diferentes herramientas, materiales o la
formación para llevar a cabo, a continuación, las actividades individuales se pueden enumerar por separado y unidas a la COBie.Resource necesario. Es la
expectativa de que cuando los fabricantes de productos comienzan a proporcionar datos de productos en formato SPIE, que estas empresas proporcionarán a
sus manuales de O & M en formato COBIE también.
Documentación de los equipos instalados también llamado, Inventario del equipo designado, todos pueden proporcionarse en formato de Cobie. El
COBIE entregable reemplaza completamente a esta entrega. Material asociado archivos de datos y hojas de datos de seguridad (MSDS) se
pueden proporcionar archivos en formato PDF y vinculados a la COBie.Type a través de la pestaña COBie.Document.
Gran parte de la información que se encuentra en el protocolo de puesta se relaciona directamente con los datos COBIE. Las pruebas específicas de una
evaluación de las narrativas de diseño asociados se pueden capturar directamente en formato COBIE. La información no es propicio para la captura de formato
COBIE tal vez capturada en archivos PDF y directamente vinculada a la zona asociada, sistema o componente.
Si copias en papel de los ejemplares originales de finales de los dibujos Para incorporados conjunto completo de los documentos del contrato con todas las
modificaciones y los planos de taller, no se requieren estas pueden proporcionarse en formato PDF y se vinculan a través de la pestaña COBie.Document.
4.2.5.3 modelos proceso de formateo
Se utilizó la plantilla de Business Process Modeling Notation (BPMN) para MS Visio para crear los modelos de procesos que se encuentra anteriormente en
esta sección. La producción de estos modelos contenía dos mejoras.
En primer lugar, un baño-tierra para el intercambio de información identificadas se ha añadido para simplificar el diagrama y hacer hincapié en que su propósito
principal para identificar los intercambios de información. En segundo lugar, el nivel de detalle y la leyenda se usa para el estándar estadounidense NBIMS ™
V3 COBIE apoya directamente a la evaluación económica de los cambios de procesos de negocio.
4.2.6. documentación de necesidad de cambio
Comentario del autor Editorial: El estándar NBIMS-estadounidense ™ V3 COBIE actualiza la información proporcionada en NBIMS-estadounidense ™ V2. En
algunos casos también se proporciona nueva información requerida por los criterios de presentación NBMS-estadounidense ™ V3.
Los siguientes errores en NBIMS-estadounidense ™ V2 fueron corregidos en esta versión de la
estándar:
• Zonas de uso IfcZone en lugar de IfcSpatialZone para facilitar la compatibilidad con IFC2x3.
• asignaciones de tareas cambia para utilizar IfcRecurrencePattern.Interval
• Dimensiones del producto cambian de usar la propiedad personalizada establecida en lugar de IfcBoundingBox, como las dimensiones
nominales no son necesariamente la misma que la extensión geométrica calculada, y excluyendo la geometría de Cobie simplifica su
uso.

• asignaciones de materiales producto modificado para utilizar IfcMaterialConstituentSet.
• asignaciones de archivo ahora utilizan IfcProxy (además de IfcRelAssociatesDocument) para capturar los metadatos de manera
consistente y documentos de apoyo sin objetos asociados. Estos documentos deben estar asociados con el objeto general Facility.
Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación Subcomité para la presentación de Intercambio de Información
revisados, la información proporcionada en esta sección debe considerarse como un cambio moderado.
4.2.6.1 Requisitos de intercambio de legibilidad
4.2.6.1.1 lista de requisitos de intercambio
• Criterios de instalaciones • Instalación del producto
• Especificaciones de disciplina • inspección del producto
• Definición del proyecto • Emisión de construcción
• Programa espacial • Piezas tipo de producto
• Programa de productos • Tipo de Producto Garantía
• diseño temprano • Tipo de Producto de mantenimiento
• diseño esquemático • Operación del sistema
• diseño Coordinado • Condición del espacio
• Problema de diseño • El producto de reemplazo de piezas
• Plantilla Tipo de Producto • el espacio de ocupación
• del producto • Renovación Actividad Espacial
• Edición de la subasta • Remodelar
• Tipo de Producto Selección • Expandir
• Disposición del sistema • Demoler
4.2.6.1.2 lista de clasificación de necesidad de cambio
Tabla 30 Clas s ficación de la Iniciación de Cambio s
Fase del Fase de Los intercambios Tabla OmniClass 31-Fase OmniClass OmniClass Tabla 32-Servicio buildingSMART
proyecto contratación contratados Tabla 34- Actor Alliance® Proyecto Árbol
Criterios de no provisto 34-21 14 00 no provisto 2.44 Desarrollar criterios del sitio

instalaciones Propietario
criterios
Disciplina 34-21 14 00 no provisto 2.43
Las especificaciones no siempre Propietario Desarrollar criterios de diseño
Definición del 11 31 al 10, 14 32-11 11 15 2.5 Desarrollar el Plan de Ejecución

Iniciación Definición
proyecto Descripción Fase 34-21 14 00 Propietario Desarrollo del Proyecto
Programa Fase 31-10 14 21 34-21 17 00 32-11 14 24 3.413 Configurar distribución de las

Requisito espacial Programación Planificador Programación habitaciones y zonas

Programa de Fase 31-10 14 21 34-21 17 00 32-11 14 24 3.41 Realizar Desarrollo de

productos Programación Planificador Programación Sistemas y Diseños
Tabla 31 Clas s ficación de De s Los intercambios IGN

diseño 31-20 10 14 34-25 21 00 32-11 14 00 3.4 Desarrollar Diseño

temprano Diseño Arquitecto Proyectos
Conceptual
diseño 31-20 10 17 de diseño 34-25 21 00 32-11 14 00 3.4 Desarrollar Diseño
esquemático esquemático Arquitecto Proyectos
Documentos
diseño Coordinado 31-20 20 11 Diseño 34-25 21 00 32-11 14 00 3.4 Desarrollar Diseño
detallado Arquitecto Proyectos
Diseño Problema de 31-20 20 21 34-25 21 00 32-11 14 00 3.52 Realizar revisiones de diseño

diseño Análisis de Arquitecto Proyectos
Ingeniería
Plantilla Tipo de 31-20 20 24/37/31 Prod, 34-25 41 00 32-11 45 00 3.412 seleccionar los materiales y
Producto Matl.Equip Sel Prescripción Especificación equipo de construcción
Especificación
del producto 31-20 20 24/37/31 Prod, 34-25 41 00 32-11 45 00 3.412 seleccionar los materiales y
Matl.Equip Sel Prescripción Especificación equipo de construcción
Tabla 32 Clas s ficación de Co norte trucción excha nges

Edición de Preparación 31-30 34-35 14 00 32-21 21 11 pujas 1.43 Preparar y Presentar la subasta
la subasta 30 21 Propuesta contratista
Ofertas
Tipo de 31-40 20 27 34-35 14 00 32-21 00 00 4.2 Proporcionar recursos (bienes

Producto Procesamiento de contratista Servicios de y servicios)
Selección Presentación Ejecución
Selección
Disposición del 31-40 20 27 34-35 14 00 32-21 00 00 4.11 Desarrollar Plan de
sistema Procesamiento de contratista Servicios de Construcción
Presentación Ejecución
Instalación del 31-40 40 11 17 34-35 14 00 32-21 17 41 Edificio 4.3 Build
producto Instalación contratista Instalación
inspección del 31-40 40 91 17 34-35 14 00 32-21 17 00 4,34 inspeccionar y aprobar el
Instalación producto Evaluación contratista Construir Trabajo
Construcción
Emisión de 31-40 40 91 17 34-21 14 00 32-21 17 00 4,34 inspeccionar y aprobar el
construcción Evaluación Propietario Construir Trabajo
Piezas tipo de 31-40 50 00 Puesta en 34-35 17 00 Sub 32-21 00 00 4.4 Puesta en marcha Realizar
producto marcha contratista Servicios de
Ejecución
Tipo de Producto 31-40 50 00 Puesta en 34-35 17 00 Sub 32-21 00 00 4.4 Puesta en marcha Realizar
Garantía marcha contratista Servicios de
Ejecución
Comisión
Tipo de Producto de 31-40 50 00 Puesta en 34-35 17 00 Sub 32-21 00 00 4.4 Puesta en marcha Realizar
mantenimiento marcha contratista Servicios de
Ejecución
Operación del 31-40 50 00 Puesta en 34-35 17 00 Sub 32-21 00 00 4.4 Puesta en marcha Realizar
sistema marcha contratista Servicios de
Ejecución

Tabla 33 Clas s ficación de Op mi excha racional nges

Condición del Inspección 31-50 20 21 Gestor 34-41 11 32-41 51 11 5.3 evaluar las condiciones y
espacio Facility 00 Facility Inspección detectar problemas
Producto colocación Operación 31-50 20 11 34-41 21 00 Reparación 32-41 47 5.4 Desarrollar Soluciones
de piezas Re- Facility Mantenimiento 11 11 Facility
O&M
el espacio de 31-50 10 17 Uso Gestor 34-41 11 Planificación 32-41 47 5.7 Realizar uso de la
ocupación 00 Facility 21 Espacio facilidad / Edificio
Renovación Renovación 31-50 Gestor 34-41 11 Planificación 32-41 47 5.8 Realizar Instalación /
Actividad 30 11 Facility 00 Facility 21 Espacio Renovación del edificio
Espacial
Remodelar Remodelación Gestor 34-41 11 La actualización 32-41 5.10 Realizar Instalación /
31-50 30 14 00 Facility 47 11 17 Facility Expansión de construcción
Facility
Expandir Expansión 31-50 30 17 Gestor 34-41 11 La actualización 32-41 5.10 Realizar Instalación /
reutilizar Facility 00 Facility 47 11 17 Facility Expansión de construcción
Demoler 31-60 35 00 Gestor 34-41 11 La actualización 32-41 5.11 Eliminación, reutilización,

Reciclaje 00 Facility 47 11 17 Facility reciclaje
Análisis 4.2.6.1.3 Cobertura de necesidad de cambio
Tabla de cobertura Requisitos 34 Cambio
Intercambiar Proceso Remitente Receptor
Criterios de instalaciones 31-10 00 00 Fase de Inicio 34-10 11 00 Propietario 34-10 11 11 desarrollador
Especificaciones de disciplina 31-10 00 00 Fase de Inicio 34-10 11 17 Entidad Pública 34-10 11 11 desarrollador
Definición del proyecto Fase 31-20 00 00 Conceptualización 34-10 11 11 desarrollador 34-20 21 11 Planificador
Programa espacial 31-30 00 00 Criterios Definición Fase 34-10 11 11 desarrollador 34-20 11 11 Arquitecto
Programa de productos 31-30 00 00 Criterios Definición Fase 34-10 11 11 desarrollador 34-20 11 11 Arquitecto
diseño temprano 31-40 00 00 Fase de Diseño 34-20 11 11 Arquitecto 34-10 11 11 desarrollador
diseño esquemático 31-40 00 00 Fase de Diseño 34-20 11 11 Arquitecto 34-10 11 11 desarrollador
diseño Coordinado 31-40 00 00 Fase de Diseño 34-20 11 11 Arquitecto 34-20 11 21 Engineer
Problema de diseño 31-40 00 00 Fase de Diseño 34-20 11 21 Engineer 34-20 11 11 Arquitecto
Plantilla Tipo de Producto 31-40 00 00 Fase de Diseño 34-20 11 11 Arquitecto 34-20 11 41 Prescripción
del producto 31-40 00 00 Fase de Diseño 34-20 11 41 Prescripción 34-20 11 11 Arquitecto
Edición de la subasta 31-60 00 00 Implementación Fase 34-35 15 11 contratista 34-20 11 11 Arquitecto
Tipo de Producto Selección 31-60 00 00 Implementación Fase 34-35 10 21 Proveedor 34-20 11 11 Arquitecto
Disposición del sistema 31-60 00 00 Implementación Fase 34-35 15 11 contratista 34-20 11 21 Engineer
Instalación del producto 31-60 00 00 Implementación Fase 34-35 15 11 contratista 34-20 11 11 Arquitecto
inspección del producto 31-60 00 00 Implementación Fase 34-20 51 11 Crítico 34-35 10 21 Proveedor
Emisión de construcción 31-60 00 00 Implementación Fase 34-20 51 17 Inspector 34-35 15 11 contratista
Piezas tipo de producto 31-60 00 00 Implementación Fase 34-35 10 21 Proveedor 34-10 11 00 Propietario

Intercambiar Proceso Remitente Receptor
Tipo de Producto Garantía 31-60 00 00 Implementación Fase 34-35 10 21 Proveedor 34-10 11 00 Propietario
Tipo de Producto de mantenimiento 31-60 00 00 Fase de Ejecución 34-35 10 21 Proveedor 34-10 11 00 Propietario
Operación del sistema 31-60 00 00 Implementación Fase 34-35 15 11 contratista 34-10 11 00 Propietario
Condición del espacio 31-80 00 00 Fase de Operaciones 34-41 14 11 Fondo para el Administrador 34-10 11 00 Propietario
El producto de 31-80 00 00 Fase de Operaciones 34-41 14 11 Fondo para el Administrador 34-10 11 00 Propietario
reemplazo de piezas
el espacio de ocupación 31-80 00 00 Fase de Operaciones 34-41 14 11 Fondo para el Administrador 34-10 11 00 Propietario
Espacio Renovación 31-80 Actividad 00 00 Fase de Operaciones 34-41 14 11 Fondo para el Administrador 34-10 11 00 Propietario
Remodelar Fase 31-90 00 00 Cierre 34-10 11 00 Propietario 34-20 11 11 Arquitecto
Expandir Fase 31-90 00 00 Cierre 34-10 11 00 Propietario 34-20 11 11 Arquitecto
Demoler Fase 31-90 00 00 Cierre 34-10 11 00 Propietario 34-35 15 11 contratista
4.2.6.2 requisitos de intercambio detalle
4.2.6.2.1 Requisitos de intercambio de definición
4.2.6.2.1.1 Criterios - Criterios de instalación
Este intercambio incluye criterios de alto nivel específicas para el edificio a ser construido, pero sin tener en cuenta las disciplinas particulares. Entidades
exportados para este intercambio se incluyen los siguientes:
• Se proporciona Directorio y el contexto de los datos: IfcProject.
• IfcActor: Los participantes del proyecto, las funciones y la información de contacto se facilita.
• IfcSite: Sitio (general) información debe ser proporcionada para identificar el sitio sobre el cual se coloca la instalación.
• IfcBuilding: Fondo para la información (general) se debe proporcionar para identificar las instalaciones en las que los pisos y los espacios pueden ser
encontrados.
• IfcBuildingStory: Proporcionar el nombre de cada nivel conceptual / vertical física de cada una de las instalaciones identificadas en el
envoltorio del proyecto, valor de elevación y unidades anteriores dato proyecto local, altura de piso a piso y unidades.
• IfcSpace: Proporcionar el nombre y el piso para cada espacio.
• IfcSpatialZone: identificar las zonas conceptuales dentro del edificio que tiene un patrón similar o agrupados de uso. Por ejemplo, las zonas
pueden referirse a zonas mecánicos de calefacción, zonas de sistemas de alarma, o grupos de espacios que se utilizará para clientes
específicos.
• IfcPropertySet: Las propiedades pueden ser especificados para indicar requisitos a objetos particulares.
4.2.6.2.1.2 Criterios - especificaciones de disciplina
Este intercambio incluye criterios específicos de la disciplina, el alcance de indicación y función de los sistemas de construcción y sistemas de distribución.
Entidades exportados para este intercambio se incluyen los siguientes:

• IfcSystem: se pueden identificar y especificar los sistemas de construcción y sistemas de distribución.
4.2.6.2.1.3 iniciación del proyecto - definición del proyecto
Este intercambio incluye la información inicial del proyecto para describir un proyecto y su contenido. Entidades exportados para este intercambio se incluyen
los siguientes:
• IfcSite: Sitio (general) información debe ser proporcionada para identificar el sitio sobre el cual se coloca la instalación.
• IfcBuilding: Fondo para la información (general) se debe proporcionar para identificar las instalaciones en las que los pisos y los espacios pueden ser
encontrados.
4.2.6.2.1.4 Requisitos - programa espacial
Este intercambio incluye los requisitos para la disposición espacial de un edificio. Entidades exportados para este intercambio se incluyen los
siguientes:
• IfcSpatialZone: identificar las zonas conceptuales dentro del edificio que tiene un patrón similar o agrupados de uso. Por ejemplo, las zonas
pueden referirse a zonas mecánicos de calefacción, zonas de sistemas de alarma, o grupos de espacios que se utilizará para clientes
específicos.
• IfcRelAssociatesClassification: Clasificaciones pueden ser aplicados para clasificar espacios por función.
4.2.6.2.1.5 Requisitos - gama de productos
Este intercambio incluye requisitos para los componentes físicos de un edificio. Entidades exportados para este intercambio se incluyen los
siguientes:
• IfcElement: Identificar los requisitos generales de los productos a ser utilizados dentro del edificio.
• IfcRelAssociatesClassification: Las clasificaciones pueden ser aplicados para clasificar los productos según su función.
4.2.6.2.1.6 etapa de diseño - diseño inicial
Este intercambio de información incluye la construcción de la disposición y distribución de productos sin tener en cuenta para la colocación. Entidades

• IfcElement: Identificar los requisitos generales de los elementos dentro del edificio.
• IfcElementType: Identificar los tipos de modelos de productos específicos que deben considerarse para su uso.
• IfcSystem: Nombre del sistema para cada sistema debe ser identificado antes de que pueda estar asociado con los productos y zonas
específicas.
• IfcRelAssociatesClassification: Clasificaciones pueden ser aplicados para clasificar espacios por función.
4.2.6.2.1.7 etapa de diseño - diseño esquemático
Este intercambio de información incluye la construcción de la disposición y distribución de productos con la colocación y la conectividad. Entidades
• IfcSystem: Nombre del sistema para cada sistema debe ser identificado antes de que pueda estar asociado con los productos y zonas
específicas.
• IfcRelConnectsElements: Indicar las conexiones entre los elementos de montaje.
• IfcRelConnectsPorts: Indicar las conexiones del puerto entre los elementos.
• IfcRelAssociatesClassification: Las clasificaciones pueden ser aplicados para clasificar los productos según su función.
4.2.6.2.1.8 etapa ddesign - diseño coordinado
Este intercambio incluye distribución del edificio información y distribución de los productos con la colocación,
conectividad, y la asignación a los sistemas y los participantes del proyecto. En IFC4, las zonas pueden estar indicados
espacialmente con la designación funcional, constituyentes materiales son compatibles para identificar múltiples materiales y propiedades. Entidades
• IfcSystem: Diseño de sistemas de construcción, sistemas estructurales y sistemas de distribución.
• IfcSpatialZone: zonas de diseño para sistemas de distribución.
• IfcRelConnectsElements: Indicar las conexiones entre los elementos de montaje.
• IfcRelAssociatesMaterial: Indicar materiales, capas y perfiles de los elementos.
• IfcRelAssignsToActor: Indicar los participantes del proyecto responsables de sistemas y elementos.
• IfcRelAssignsToGroup: Indicar la partición de elementos de construcción a los sistemas.

• IfcRelAssociatesClassification: Clasificaciones pueden ser aplicados para clasificar productos y sistemas por función.
• IfcElementQuantity: Las cantidades pueden ser indica en elementos de construcción y estructuras espaciales.
4.2.6.2.1.9 etapa de diseño - problema de diseño
Este intercambio incluye la información de diseño final con documentos formales y enmendada con las peticiones y respuestas problema de diseño.
Entidades exportados para este intercambio se incluyen los siguientes:
• IfcActionRequest: Indique los problemas y resoluciones reportados.
• IfcRelAssociatesDocument: Indicar los documentos externos.
4.2.6.2.1.10 Etapa de Diseño - Plantilla Tipo de Producto
Este intercambio incluye definiciones de las propiedades para ser capturado por plantillas de productos.
las plantillas de las propiedades están ahora soportados en IFC4. Composición proyecto no incluido (no es necesaria la construcción de marcador de posición). Entidades
• IfcRelAssociatesClassification: Clasificaciones pueden aplicarse a categorizar propiedades por definiciones comunes.
• IfcPropertySetTemplate: Propiedad establece las plantillas se pueden especificar para indicar información que debe proporcionarse para este tipo de
productos.
• IfcSimplePropertyTemplate: Plantillas de propiedades pueden ser especificados para describir cada propiedad dentro de un conjunto de propiedades.
4.2.6.2.1.11 escenografía - plantilla de producto
Este intercambio incluye información de tipo de producto para los modelos de productos específicos proporcionados por los fabricantes.
tipos de productos pueden ser declaradas dentro de un proyecto sin tener ningún ocurrencias en IFC4. Composición proyecto no incluido (no es necesaria la
construcción de marcador de posición). bibliotecas de proyecto añadieron (para proporcionar un enlace a originarias plantillas de conjuntos de propiedades). Entidades
• IfcProjectLibrary: Referencia bibliotecas de plantillas de conjunto de propiedades se indican.
• IfcRelAssociatesClassification: Clasificaciones pueden ser aplicados para clasificar tipos de producto.
• IfcRelAssociatesMaterial: Identificar constituyentes materiales y propiedades del material.
4.2.6.2.1.12 etapa de construcción - apertura de tema
Este intercambio de información incluye una oferta presentación de documentos formales, y modificada con las solicitudes de emisión de oferta y
respuestas. La entidad IfcActionRequest captura todos los problemas reportados (o peticiones que hacer algo), para los que se pueden asignar tareas a
realizar un trabajo para resolver un problema. Entidades exportados para este intercambio se incluyen los siguientes:
• IfcActionRequest: Indique los problemas y resoluciones reportados.

• IfcRelAssociatesDocument: Indicar los documentos externos.
4.2.6.2.1.13 de construcción de escenarios - selección del tipo de producto
Este intercambio incluye información de tipo de producto para los modelos de productos seleccionados para ser utilizados, sin tener en cuenta en particular la colocación.
tipos de productos pueden ser declaradas dentro de un proyecto sin tener ningún ocurrencias en IFC4. Composición proyecto no incluido (no es necesaria la construcción
de marcador de posición). bibliotecas de proyecto añadieron (para proporcionar un enlace a originarias plantillas de conjuntos de propiedades). Entidades exportados
para este intercambio se incluyen los siguientes:
• IfcProjectLibrary: bibliotecas de referencia de tipos de productos se indican.
• IfcRelDefinesByType: Indicar los tipos de productos que se utilizarán en los sucesos específicos.
4.2.6.2.1.14 Etapa de Construcción - Disposición del sistema
Este intercambio incluye información detallada conectividad del sistema para los sistemas de construcción y sistemas de distribución. Entidades exportados
• IfcElement: Indicar la colocación elemento específico dentro del edificio.
• IfcSystem: Indicar el diseño del sistema y la topología.
• IfcRelConnectsElements: Indicar conexiones generales entre elementos.
la instalación del producto - 4.2.6.2.1.15 etapa de construcción
Este intercambio de información incluye la colocación de productos, incluidos los números de serie en instalaciones específicas. Entidades exportados para este
intercambio se incluyen los siguientes:
4.2.6.2.1.16 de construcción de escenarios - la inspección del producto
Este intercambio incluye temas de inspección de productos reportados, que pueden requerir la sustitución de los productos instalados. Entidades exportados
• IfcActionRequest: Informe de cuestiones relacionadas con los productos.
tema de la construcción - 4.2.6.2.1.17 etapa de construcción
Este intercambio incluye problemas de construcción reportados, que pueden requerir mano de obra adicional. Entidades exportados para este intercambio
se incluyen los siguientes:

• IfcActionRequest: cuestiones informe relacionado con la construcción.
4.2.6.2.1.18 Construcción etapa - partes de tipo de producto
Este intercambio incluye información de la pieza de producto, que se puede usar para abordar los componentes para la conectividad o reemplazo. IFC4
permite tipos de productos para han asignado los tipos de procesos y tipos de recursos, lo que puede indicar los procesos estándar (es decir, definidos por
el fabricante-) para mantenimiento o sustitución de piezas. Entidades exportados para este intercambio se incluyen los siguientes:
• IfcTaskType: Indicar procesos parte producto de reemplazo.
• IfcConstructionProductResourceType: Indicar los recursos disponibles y los costes para la parte

reemplazo.
4.2.6.2.1.19 de construcción de escenarios - garantía de tipo de producto
Este intercambio incluye información sobre la garantía de productos de piezas y mano de obra. Entidades exportados para este intercambio se incluyen los
siguientes:
• IfcTaskType: Indicar los períodos de garantía.
• IfcSubContractResourceType: Indicar contratos de garantía.
• IfcRelAssociatesDocument: Indicar documentos externos para garantías.
4.2.6.2.1.20 de construcción de escenarios - Tipo de producto de mantenimiento
Este intercambio de información incluye el mantenimiento del producto, incluidas las tareas de mantenimiento y procedimientos previstos. Entidades
• los procesos de mantenimiento de productos Horario: IfcTask.
• IfcConstructionResource: Programar recursos de mantenimiento del producto.
• IfcRelAssociatesDocument: Indicar documentos externos para el mantenimiento.
el funcionamiento del sistema - etapa 4.2.6.2.1.21 Cconstruction
Este intercambio de información incluye la operación del sistema, incluyendo los procedimientos de operación del sistema y eventos. Entidades exportados para este
intercambio se incluyen los siguientes:
• IfcTask: procesos de operación del sistema de programación.
• IfcConstructionResource: Programar recursos de funcionamiento del sistema.
• Operaciones y Mantenimiento
4.2.6.2.1.22 O & M etapa - condición espacio
Este intercambio incluye la presentación de informes sobre el estado de los espacios en el tiempo. En IFC4, todas de fase temporal
información es capturada utilizando las propiedades basadas en el rendimiento en IfcPerformanceHistory. Esto permite que los datos se registran para varios
períodos de tiempo (evitando la restricción conjunto sola propiedad), y para proporcionar una

manera uniforme de acceso y la prestación de datos de fase de tal manera que las aplicaciones de software no tienen que ser conscientes de propiedades particulares. Un
conjunto de propiedades se debe definir para el registro de las condiciones del espacio a través del tiempo. Entidades exportados para este intercambio se incluyen los
siguientes:
• IfcPropertySet: Las propiedades pueden ser especificados para indicar detalles de condición.
sustitución de piezas de productos - 4.2.6.2.1.23 O & M etapa
Este intercambio incluye la presentación de informes sobre la sustitución de las piezas del producto en el tiempo. En IFC4, el modelo de proceso y de los
recursos se ha formalizado, de manera que la sustitución de piezas puede ser considerado como una tarea de mantenimiento con los recursos asignados
para los materiales, mano de obra, equipos, productos, tripulaciones, subcontratos. Entidades exportados para este intercambio se incluyen los siguientes:
• IfcTask: sustitución de piezas de informe con el tiempo.
• IfcConstructionResource: Informe de recursos piezas de repuesto.
• IfcPropertySet: Las propiedades pueden ser especificados para indicar detalles.
4.2.6.2.1.24 O & etapa M - ocupación del espacio
Este intercambio incluye la ocupación de los espacios de programación en el tiempo. Entidades exportados para este intercambio se incluyen los siguientes:
• IfcOccupant: Indicar ocupantes.
• IfcTask: indicar programado periodos de ocupación.
• IfcSubContractResource: Indicar contratos de arrendamiento de ocupación del espacio.
• IfcRelAssignsToActor: Indicar actual propietario (s) y / u ocupante (s) de un espacio.
• IfcRelAssignsToProduct: Indicar los períodos de ocupación de los espacios.
• IfcRelAssignsToProcess: Indicar los recursos asignados a los períodos de ocupación de espacio.
4.2.6.2.1.25 O & M etapa - espacio de la actividad de remodelación
Este intercambio incluye la programación de la reconfiguración de los espacios en el tiempo. Entidades exportados para este intercambio se incluyen los
siguientes:
• IfcTask: Indicar las tareas de renovación.
• IfcConstructionResource: Indicar los recursos de renovación.
• IfcRelAssignsToProduct: Indicar elementos a ser renovadas.
• IfcRelAssignsToProcess: Indicar los recursos asignados a las tareas.
4.2.6.2.1.26 reciclaje etapa - remodelación
Este cambio incluye cambiar el diseño de la construcción de una estructura existente. Entidades exportados para este intercambio se incluyen los
siguientes:

4.2.6.2.1.27 (no se utiliza)
4.2.6.2.1.28 reciclaje etapa - ampliar
este intercambio incluye la ampliación de la distribución del edificio de una estructura existente. entidades exportados para este intercambio se incluyen los
siguientes:
4.2.6.2.1.29 reciclaje etapa - demoler
Este intercambio incluye la demolición de una estructura existente parcialmente o en su totalidad. Entidades exportados para este intercambio se incluyen los
siguientes:
4.2.6.2.1.30 Uuse de conjuntos dentro de COBIE
Para simplificar la interoperabilidad, la composición de la Parte se excluye en este MVD. Los trabajos relacionados con la inclusión de conjuntos Sin
embargo, ha sido localizado en el apoyo de MVD relacionados para HVAC, el agua y los sistemas eléctricos. El uso de la información para la Asamblea
NBIMS-estadounidense ™ V3 se debe especificar como un acuerdo suplementarios ejecutores, de ser requerido por el contrato.
4.2.6.2.1.31 El uso de conexiones dentro de Cobie
Para simplificar la interoperabilidad, la conectividad y el puerto elemento fue excluido en este MVD. Los trabajos relacionados con la inclusión de puertos
Sin embargo, ha sido localizado en el apoyo de MVD relacionados para HVAC, el agua y los sistemas eléctricos. Uso de la información de conexión para
NBIMS-estadounidense ™ V3 se debe especificar como un acuerdo suplementarios ejecutores, de ser requerido por el contrato.
4.2.6.2.1.32 El uso de impactos dentro COBIE

Propuestos IFC 4 extensiones TC1 pueden incluir PSet_EnvironmentalImpact. Una vez que la extensión se ha desarrollado, y mapeo de
nuevo a la IFC 2x3 haberse logrado, los acuerdos de ejecutores de programas pueden apoyar el uso de la información de impacto.
4.2.6.2.1.33 El uso de coordenadas dentro COBIE
requisitos de intercambio que rigen COBIE describe en esta norma identificar la relación entre la información de activos y la geometría
espacial simplemente la de “contención espacial.” contención espacial significa que cada activo llamado individualmente se identifica
como “en” un espacio. Cuando el equipo está en un solo espacio, como es el caso de la inmensa mayoría de los equipos con una
instalación, este requisito no requiere de aclaración. Para el caso especial de los grandes equipos colocados en el techo, que abarca
varios espacios, el espacio asociado con el equipo de aquella de la que el equipo se mantenga lo más típicamente. sin embargo, hay
otras situaciones, como el equipo se encuentra en un sitio geográfico grande que alguna información colocación geométrica puede ser
útil.
Dada la capacidad muy limitada de COBIE, en vista de hoja de cálculo, para representar únicos puntos, líneas y cajas, COBIE no es capaz de
proporcionar cualquier representación geométrica significativo. Cobie puede, en casos especiales, sin embargo, ayudar a identificar la localización del
equipo. Para apoyar estos casos especiales, las siguientes entidades pueden, opcionalmente, tienen las siguientes coordenadas representaciones en
COBIE.
Tabla 35 Uso de las coordenadas con Cobie

Entidad Coordinar Tipo Valor requerido
Instalaciones Esquina inferior izquierda Típicamente se establece en 0,0,0
Piso Esquina inferior izquierda En relación con Facilidad
Espacio Inferior izquierda y superior-derecha de la esquina En relación con piso

Componente Inferior izquierda y superior-derecha de la esquina En relación con piso
Montaje Inferior izquierda y superior-derecha de la esquina En relación con piso
El uso de información de coordenadas para NBIMS-estadounidense ™ V3 se debe especificar como un acuerdo suplementarios ejecutores, de ser requerido
por el contrato.
4.2.6.2.1.34 El uso de atributos dentro de Cobie - mapeo entre la CFI y SpreadsheetML
acuerdos ejecutores documentados en buildingSMART Alliance® eventos reto tienen separado documentan los cambios necesarios para conjuntos de
propiedades personalizadas que se proporcionan por separado de las normas obligatorias. Estos acuerdos ejecutores, que se encuentran en la matriz de la
responsabilidad, Cobie han resuelto los problemas de implementación para asegurar que los datos COBIE calidad se pueden demostrar para que coincida
con los mismos datos que se encuentran en los horarios de dibujo de diseño y los fabricantes de hojas de datos. La estandarización de los conjuntos de
propiedades específicas está fuera del alcance del esfuerzo de Cobie.
4.2.6.2.1.35 El uso de atributos dentro de Cobie - datos del producto
Atributos de los conjuntos de tipos de equipos estándar no se han presentado para su revisión durante consencus NBIMS-estadounidense ™ V3. En ausencia de
norma NBIMS-estadounidense ™ la Guía COBIE, un comentario publicado, establece que los atributos que se encuentran en un archivo COBIE deben coincidir
con las propiedades técnicas de los productos que se encuentran en las entregas contractuales asociados.
4.2.6.2.2 lista de reglas de negocios
Las reglas de negocio verifican que el intercambio de datos COBIE se ajustan a la especificación de datos requerida puede generalizarse en clases
de reglas. Aplicación de estas normas resultados en la verificación de que la integridad interna de un conjunto de datos COBIE es correcta. Estas
reglas no se validan la entrega COBIE frente a los requisitos específicos contrato-. La lista de clases de reglas COBIE se proporciona en la siguiente
lista.

• Clasificación • Typing objeto
• Unidades de conversión • Declaración proyecto
• Cobie metadatos • Los conjuntos de propiedades
• Cobie Contacto • Las cantidades de Ocurrencias
• Asignación de Control • Conectividad secuencial
• Restricciones de datos externas • Composición espacial
• Asignación grupal • La contención espacial
Mientras que el contenido específico de los intercambios de información relacionada con los activos espaciales y de producto se diferencia como un proyecto progresa, las
reglas de negocio que se utilizan para verificar la integridad de la información son exactamente los mismos para todos estos intercambios. Los siguientes intercambios de
información comparten las reglas de negocio anotados en la tabla a continuación:
• Criterios servicio de cambio • diseño esquemático
• Programa espacial • diseño Coordinado
• Programa de productos • Disposición del sistema
• Diseño temprana
Tabla 36 Reglas de Negocio - Intercambios de diseño relacionados

Las cantidades de Ocurrencias
Restricciones de datos externas
Los conjuntos de propiedades
La contención espacial
Composición espacial
Unidades de conversión
Declaración proyecto
Asignación grupal
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
entidad
IfcSpace X X X X X X
IfcBuildingStorey X X X X
IfcBuilding X X X X
IfcSite X X
IfcProject X X X X
IfcZone X X X X X
IfcSystem X X X X
IfcElement X X X X X X
IfcElementType X X X X
IfcActor X X X

Las reglas de negocio asociadas con la disciplina Especificaciones intercambios difieren de los que se enumeran en la tabla anterior, ya que estos
intercambios específicos de la disciplina tienen que ver con las especificaciones técnicas de los activos de productos orientados. Tenga en cuenta que el
requisito de especificaciones de disciplina para tener entidades ifcBuilding, ifcSite, ifcProject es un artefacto de la modelización de dicha información
utilizando únicamente la Fundación Clase Modelo de Industria.
Tabla 37 Reglas de Negocio - Especificaciones de disciplina

Asignación grupal
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
entidad
IfcBuilding X X X X
IfcSite X X
IfcProject X X X X
IfcZone X X X X X
IfcSystem X X X
IfcActor X X X
Las reglas de negocio asociadas con la definición del producto son un subconjunto de las que se requieren para definir los requisitos para el
programa, y el diseño que se propone para satisfacer esas necesidades. Las reglas de negocio asociadas con los archivos de Cobie presentados en
la fase de definición del proyecto se indican en la siguiente tabla.
Tabla 38 Reglas de Negocio - Definición del proyecto


Asignación grupal
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
entidad
IfcSpace X X X X X
IfcBuilding X X X X
IfcSite X X
IfcProject X X X X
IfcZone X X X X X
IfcSystem X X X


Asignación grupal
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
entidad
IfcElement X X X X
IfcActor X X X
Hay intercambios relacionados con la identificación y resolución de problemas en el proyecto. Mientras que el contenido y el momento de estos
intercambios se diferencian los siguientes intercambios todos comparten un conjunto común de reglas usadas para verificar la consistencia interna del
intercambio de información:
• Problema de diseño
• Edición de la subasta
• inspección del producto
• Emisión de construcción
Tabla 39 Reglas de Negocio - Intercambios tipo de problema

Asignación de Control
Asignación grupal
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
entidad
IfcBuildingStorey X X X
IfcBuilding X X X
IfcSite X X
IfcProject X X X X
IfcZone X X X X X
IfcSystem X X X
ifcElementType X X X X
IfcActor X X X
IfcActionRequest X

Muchos intercambios de información que se acumulan para crear datos COBIE se refieren a los intercambios sobre los tipos de productos. Esto comienza con
una configuración inicial de un producto genérico, a la identificación de tipos de productos explícitas, a la selección de posibles candidatos para esa
especificación, y luego a través de la construcción durante el proceso de presentación. Los siguientes intercambios de tipo de producto comparten las reglas de
negocio que se encuentran en la siguiente tabla:
• Tipo de Producto Selección
• Tipo de Producto Garantía
• Piezas tipo de producto
IfcActor se aplica a todos los intercambios, excepto el intercambio del producto inicial tipo de plantilla.
ifcConstructionResourceType sólo se aplica a las piezas Tipo de producto, cambio.
Tabla 40 Reglas de Negocio - Intercambios Tipo de producto


Cobie metadatos
Cobie Contacto
Clasificación
Entidad
IfcBuilding * X X X
IfcSite * X X
IfcProject * X X X X
ifcElementType X X X X X
IfcActor X X X
IfcConstruction
X X X
TipoRecurso
* NOTA: La inclusión de esta entidad es necesario para la especificación completa de intercambio de archivos basado en la CFI; sin embargo, dicha
información no está directamente requerido por el intercambio mismo si se proporciona la información a través de un intercambio transaccional o de
servicios web. La especificación transaccional de Intercambios Tipo de producto se puede encontrar en la norma NBIMS-estadounidense ™ V3 LCIE.
Los detalles de los casos de productos individuales, como se define por las entidades ifcElement se añaden para:
• del producto
• Instalación del producto

Tabla 41 Reglas de Negocio - Instalación del producto
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
Entidad
IfcSpace * X X X X
IfcBuildingStorey * X X X
IfcBuilding * X X X
IfcSite * X X
IfcSystem * X
ifcElementType * X X X
IfcActor X X X
información no está directamente requerido por el intercambio mismo si se proporciona la información a través de un intercambio transaccional o
servicio web, frente a un cambio basado en archivos COBIE. los
especificación transaccional de Intercambios Tipo de producto se puede encontrar en la norma NBIMS-estadounidense ™ V3 LCIE.
Información sobre las operaciones y actividades de mantenimiento introduce la entidad de un ifcTask a la necesidad de cambio. Las reglas de
negocio que pertenecen a esas tareas garantizan la conexión adecuada de las tareas a sus objetos de tipo asociadas y permitir la secuenciación de
las operaciones dentro de las tareas. Los siguientes intercambios comparten las reglas de negocio que figuran en la siguiente tabla:
• Tipo de Producto de mantenimiento
• Operaciones del sistema
Tabla 42 Reglas de Negocio - O & M intercambios de información de tipo

Conectividad secuencial
Asignación grupal
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
entidad
IfcSpace X X X X X

IfcBuilding * X X X
IfcSite * X X
IfcZone X X X X
IfcSystem X X
ifcElementType X X X
IfcTask X X
IfcActor X X X
recursos
X X X
IfcConstruction
especificación transaccional de Intercambios Tipo de producto se puede encontrar en la norma NBIMS-estadounidense ™ V3 LCIE. Al comienzo de
la operación de la instalación de la información sobre las órdenes de servicio que se utilizan para reparar o reemplazar las piezas individuales de
los activos fijos se pueden capturar en el siguiente intercambio. Si bien la información en los datos de COBIE subyacente no se cambia, la
información sobre los filtros, lubricantes, o piezas de repuesto se intercambian en la entidad ifcConstructionResouce.
Tabla 43 Reglas de Negocio - Producto piezas de repuesto

Asignación grupal
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
Entidad
IfcSpace * X X X X X
IfcBuildingStorey * X X X
IfcBuilding * X X X
IfcSite * X X
IfcZone * X X X X
IfcSystem * X X
ifcElementType * X X X
IfcActor X X X
recursos
X X X
IfcConstruction

especificación transaccional de Intercambios Tipo de producto se puede encontrar en la norma NBIMS-estadounidense ™ V3 LCIE.
Las encuestas de condiciones de espacio y cuota de ocupación de un conjunto de datos común. Los intercambios utilizando los siguientes intercambios espaciales
post-ocupación se definen en la tabla siguiente:
• Condición del espacio
• el espacio de ocupación
Tabla 44 Reglas de Negocio - Intercambios espacio post-ocupación


Asignación grupal
Cobie metadatos
Cobie Contacto
Clasificación
entidad
IfcBuilding X X X X
IfcSite X X X
IfcProject X X X X X
IfcZone X X X X X
IfcActor X X X
Tenga en cuenta que esta definición de una encuesta de ocupación espacial puede ser demasiado estrecha para algunos administradores de instalaciones. Si un pesebre
instalación determinada además contiene información acerca de los activos basados en el producto durante sus estudios, entonces la tabla “post-ocupación intercambios de
tipo” puede ser utilizado.
intercambios post-ocupación permiten una información entregada instalaciones que se mantiene hasta la fecha. Información
intercambios relacionados con las órdenes de trabajo específicas deben mantenerse dentro de los sistemas CMMS / CAFM como parte del procesamiento de
orden de trabajo y están fuera del alcance más amplio del ciclo de vida del proyecto identificado en esta norma. COBIE define varios intercambios en los que la
información sobre una parte de una instalación, o una instalación completa, pueden ser actualizadas. La siguiente tabla identifica las reglas de negocio asociadas
con el intercambio de los siguientes intercambios de información posterior a la ocupación:
• El producto de reemplazo de piezas
• Renovación Actividad Espacial
• Remodelar

• Expandir
• Demoler
Tabla 45 Reglas de Negocio - Post-ocupación del espacio y de los intercambios de productos

Asignación grupal
Cobie metadatos
Cobie Contacto
Typing objeto
Clasificación
entidad
IfcBuilding X X X
IfcSite X X
IfcProject X X X X
IfcZone X X X X
IfcSystem X X X
ifcElementType X X X X
IfcActor X X X
recursos
X X
IfcConstruction
Además de estas reglas de negocio se espera que el siguiente conjunto esperado de categorización para ser proporcionada en los archivos de datos
COBIE. Para los datos extraídos de Cobie reglas de transformación CFI modelos COBIE, definidos en los anexos a estos documentos proporcionan la
configuración predeterminada. Mientras que algunas clasificaciones se han desarrollado sobre la base de las enumeraciones de tipo CFI, estas
clasificaciones representan la práctica general dentro de los Estados Unidos. Como tales, estos se proporcionan únicamente a título informativo como de
determinadas regiones, los propietarios y los contratos pueden requerir valores alternativos para dicha información. debajo de la lista se presenta en un
formato que se corresponde con el orden en que se encuentran estos campos dentro de la versión de hoja de cálculo COBIE.
Contact.Category - i f valores permitidos no se especifican por contrato, el valor predeterminado de esta información es la corriente OmniClass
Tabla 34.
Facility.Category - Si los valores permitidos no están especificados en el contrato, el valor por defecto de esta información es la corriente OmniClass
Tabla 11.
Floor.Category - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “piso”, “Techo”, y “Sitio”.
Space.Category - Si los valores permitidos no están especificados en el contrato, el valor por defecto de esta información es la corriente OmniClass
Tabla 13.

Zone.Category - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “zona de circulación”, “Zona de
Iluminación”, “Zona de alarma de incendio”, “Zona de Preservación Histórica”, “Zona de ocupación”, y “zona de ventilación”.
Type.Category - Si los valores permitidos no están especificados en el contrato, el valor por defecto de esta información es la corriente OmniClass
Tabla 23.
Type.AssetType - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “fijo” y “móvil”.
Type.WarrantyDurationUnit - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “mes” y “años”.
Type.DurationUnit - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “mes” y “años”.
System.Category - Si los valores permitidos no están especificados en el contrato, el valor por defecto de esta información es la corriente OmniClass
Tabla 21.
Assembly.AssemblyType - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “fijo”, “opcional”,
“incluido”, “Excluidos”, “Capa”, “Patch”, y “Mix”.
Connection.ConnectionType - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Control”, “flujo”,
“Volver”, “suministro”, y “estructural”.
Spare.Category - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Parte”, “PartSet”, “lubricante”,
“Otros”, “repuesto”, y “SpareSet”.
Resource.Category - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Herramientas” “Trabajo”, “Material”, y
“Formación”.
Categoría de Trabajo - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Inspección”, “Funcionamiento”,
“PM”, “seguridad”, “parada” “ajuste”, “Calibración”, “Emergencia”, “Puesta en marcha”, El “control” y “Trouble”
Job.Status - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “no ha comenzado”, “Iniciado”, y “Completado”.
Impact.ImpactType - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Costo”, “climatechange”, y
“PrimaryEnergyConsumption”.
Impact.ImpactStage - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Producción”,
“Instalación”, “Mantenimiento”, “Reserva”, “uso”, y “reutilización”.
Impact.ImpactStage - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Producción”,
“Instalación”, “Mantenimiento”, “Reserva”, “uso”, y “reutilización”.
Impact.ImpactUnit - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “moneda”, “kgCO2e”, “MJ”, “sí”, o
“n / a”.

Document.Category - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Preconstruction
Presentaciones”, “Taller Dibujos”, “modelos” “Datos del producto”, “Diseño de Datos”, “informes de ensayo”, “Certificados”, “las instrucciones
del fabricante ”,‘informes de campo del fabricante’,‘Operación y Mantenimiento’,‘liquidación Presentaciones’,‘contrato Dibujos’,‘Design Review
comentario’,‘Especificaciones’,‘Solicitud de Información’,‘Requisitos del cliente’,‘Especificaciones del Contrato’, “Planos del Contrato”,
“solicitudes de Información”, “Modificaciones del Contrato” y “lista de verificación Items”.
Document.ApprovalBy - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “la aprobación del propietario”,
“contratista certificado”, y “sólo información”.
Document.Stage - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “As Built”, “Enviado”,
“Aprobado”, “requisito exacto”, “exigencia máxima”, “requisito mínimo” y “requisito”.
Attribute.Category - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “As Built”,
“Enviado”, “Aprobado”, “requisito exacto”, “exigencia máxima”, “requisito mínimo” y “requisito”.
Coordinate.Category - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “punto”, “línea de extremo uno”, “fin de línea y dos”,
“caja inferior izquierda”, y “caja superior derecha”.
Tipo de problema - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Cambio”, “Demanda”,
“Coordinación”, “ambiental”, “Función”, “IndoorAirQuality”, “Instalación”, “RFI”, “seguridad”, y “Specification”.
Issue.Risk - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Muy Alto”, “Alto”, “moderado”, “Bajo”, y
“Desconocido”.
Issue.Chance - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Se ha producido”, “Alto”, “moderado”,
“Bajo”, y “Desconocido”.
Issue.Impact - Si los valores permitidos no están especificados en el contrato, los valores por defecto son: “Muy Alto”, “Alto”, “moderado”, “Bajo”,
y “Desconocido”.
4.2.6.2.3 Definición de reglas de negocios
clasificación - Verificar presencia de un sistema de clasificación compuesto de un número de pieza y una parte de nombre están presentes.
Unidades de conversión - Verificar que las unidades comunes para COBIE propiedades del objeto requerido han sido identificados.
Cobie Metadatos - Verificar la denominación de objetos único de acuerdo a las reglas de negocio COBIE.
Cobie Contacto - Verificar la identificación de la autoría o la parte responsable.
Asignación de Control - Compruebe que la parte responsable de la resolución de los problemas específicos es una válida COBIE de contacto.
Restricciones de datos externas - Verificar las relaciones entre los objetos. Verificar las claves compuestas requeridos en base a las reglas de negocio COBIE.
Verificar forma de cualquier documento relacionado.
Asignación grupal - Verificar que las asignaciones de grupo son internamente consistentes.

Typing objeto - Verificar que el producto activos tienen un tipo válido asociado con ellos.
Declaración del proyecto - Verificar que los valores están presentes en los campos de información de proyectos requeridos.
Los conjuntos de propiedades - Verificar la estructura adecuada de los conjuntos de propiedad asociados con ningún objeto. De particular interés es que todas las
propiedades numéricas tienen unidades definidas de forma explícita.
Las cantidades de Ocurrencias - Verificar que los valores son identificados para propiedades se han proporcionado ya sea a través de propiedades de objetos
específicos o conjuntos de propiedades.
Secuencial de conectividad - Verificar que las tareas identificadas están adecuadamente vinculados a entidades relacionadas y que las operaciones individuales, si se
especifica, se proporcionan de forma secuencial.
Composición espacial - Verificar las relaciones entre los objetos espaciales existir según las reglas de negocio COBIE. Por componentes, compruebe
que todos los componentes están asignados a un espacio específico.
La contención espacial - Compruebe que cada activo administrado se asocia con un espacio.
4.2.6.3 requisitos de intercambio de reutilización
4.2.6.3.1 lista de procesos de negocio relacionado
Los procesos de negocio que ofrecen información sobre una amplia variedad de activos se pueden encontrar en el NBIMS- estadounidense ™ V3
BPie y normas LCIE. Los activos específicos de los sistemas individuales, representados por otras normas de EE.UU. NBIMS- ™ V3 (HVACie,
Sparkie, WSIE y BAMie) requieren el intercambio de información sobre un subconjunto limitado de toda la lista de activos de construcción. Cobie
procesos sirven como plantilla para el intercambio de información de activos instalación (espacios y equipamientos) en cada una de estas normas.
La siguiente tabla identifica las categorías generales de COBIE por fase del proyecto, utilizando OmniClass Tabla
31, y compara estos procesos a los procesos identificados en presentaciones de intercambio de información relacionados NBIMS-estadounidense ™ V3.
Tabla 46 Lista de procesos de negocios relacionada

Diseño mecánico del sistema (HVACie) Diseño del
Sistema Eléctrico (Sparkie) Fontanería Diseño de

Programación edificio (BPie) Cobie
Sistemas (WSIE)
Fase del Proyecto
31-10 00 00 Fase de Inicio X
31-20 00 00 Conceptualización Fase XX 31-30 00
00 Criterios Definición Fase XX XX

31-40 00 00 Fase de Diseño XXXX
Fase 31-60 00 00 Implementación X
31-80 00 00 Fase de Operaciones X
Fase 31-90 00 00 Cierre X
4.2.6.3.2 lista de requisitos de intercambio Relacionados
Dado que COBIE define relacionados con los activos los procesos definidos genéricamente (en BPie y LCIE), o en el contexto de un diseño
específico y la disciplina de la construcción (HVACie, Sparkie, WSIE, BAMie) como se ha indicado en la sección anterior, es el caso de que Cobie
también define los requisitos genéricos para el intercambio de información acerca de estos mismos activos espaciales y equipos. A continuación se
enumeran los requisitos de intercambio COBIE que pueden ser relevantes para otros proyectos.
• Criterios de instalaciones • Instalación del producto
• Especificaciones de disciplina • inspección del producto
• Definición del proyecto • Emisión de construcción
• Programa espacial • Piezas tipo de producto
• Programa de productos • Tipo de Producto Garantía
• diseño temprano • Tipo de Producto de mantenimiento
• diseño esquemático • Operación del sistema
• diseño Coordinado • Condición del espacio
• Problema de diseño • El producto de reemplazo de piezas
• Plantilla Tipo de Producto • el espacio de ocupación
• del producto • Renovación Actividad Espacial
• Edición de la subasta • Remodelar
• Tipo de Producto Selección • Expandir
• Disposición del sistema • Demoler
Análisis de requisitos de reutilización 4.2.6.3.3 intercambio Relacionados
Se realizó un análisis detallado reutilización entre el COBIE, una especificación de ciclo de vida y los siguientes proyectos del lado del diseño y
estándares propuestos:
• BPie
• BAMie
• HVACie
• Sparkie
• WSIE
El análisis llevado a cabo reconoció que los proyectos identificados anteriormente versión de la especificación 1.0 que no se centra en la naturaleza
del ciclo de vida de los intercambios, pero se centró en la definición de la parte de diseño

intercambios. Este enfoque era necesario con el fin de establecer que la información que se debe proporcionar por diseñadores en cada contexto. futuras
ampliaciones de estos proyectos pueden completar aún más la tabla de abajo desde actualizada durante la construcción y operaciones también
compartirían muchos de los mismos requisitos de intercambio. La siguiente tabla demuestra el potencial de reutilización de la información
contenida en COBIE, con proyectos de intercambio de información distinta buildingSMART Alliance®.
Tabla 47 Exchange requieren metro ent reutilización Análisis
Intercambiar Cobie BPie BAMie HVACie Sparkie WSIE

Criterios de instalaciones X X X X
Especificaciones de disciplina X X X
Definición del proyecto X X X
Programa espacial X X X X X
Programa de productos X X X X X
diseño temprano X X X
diseño esquemático X X X
diseño Coordinado X X X
Problema de diseño X X X
ProductTypeTemplate X X X X X
del producto X X X X X
Edición de la subasta X
ProductTypeSelection X
Disposición del sistema X X X X X
Instalación del producto X
inspección del producto X
Emisión de construcción X
Piezas tipo de producto X
ProductTypeWarranty X
ProductTypeMaintenance X
Operación del sistema X X X
Condición del espacio X
ProductPartsReplacement X
el espacio de ocupación X X
espacio ActivityRenovation X
Remodelar X
Expandir X
Demoler X
4.2.7 Modelo documentación de definición de la vista
Comentario del autor Editorial: El estándar ™ V2 NBIMS por Estados Unidos no incluye el contenido de la MVD asociado. NBIMS-estadounidense
™ V2 hace referencia a la página web buildingSMART Internacional de Facility Management Entrega Modelo de definición de vista (MVD) como la
fuente para el Cobie MVD. Esta norma NBIMS-estadounidense ™ V3 sustituye a la MVD referenciado originalmente con la documentación MVD se
encuentra en esta sección. La documentación MVD proporcionada en este capítulo reproduce la información necesaria para la COBIE MVD de la
CFI

estándar de referencia. Un conjunto basado en la web de información utilizando el esquema XML ifcDocs internacionales buildingSMART se publicará para
permitir a los usuarios la capacidad familiarizado esquema de navegación CFI. Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de
Evaluación Subcomité para la presentación de Intercambio de Información revisados, la información proporcionada en esta sección debe considerarse como
un cambio moderado.
4.2.7.1 lista de las definiciones de datos
A continuación se muestra la lista de entidades IFC contenidas en este MVD:
• IfcSpace • IfcActionRequest
• IfcBuildingStory • IfcProcess
• IfcBuilding • IfcGroup
• IfcSite • IfcPropertySet
• IfcProject • IfcAnnotation
• IfcZone • IfcRelConnectsPorts
• IfcSystem • IfcWorkSchedule
• IfcElement • IfcRelAssociatesDocument
• IfcElementType • IfcRelConnectsWithRealizingElement s
• IfcTask
• IfcConstructionProductResource
• IfcActor
• IfcConstructionProductResourceType
4.2.7.2 Las definiciones de datos
Cada definición de datos está en la lista por su nombre, junto con la descripción y especificaciones en la definición de esquema EXPRESS (ISO-10303-11)
y la definición de esquemas XML (XSD). La representación XSD pueda consumir directamente herramientas de software para el intercambio de datos XML
de edición, mientras que la representación Express proporciona metadatos enriquecidos adecuados para la traducción a lenguajes de programación y
esquemas de bases. Las definiciones de datos son una adaptación de Industry Foundation Classes, donde cualquier atributo que no se utilizan se eliminan
o se omite; En Expreso, tales atributos despojados utilizan el tipo de “IfcStrippedOptional”, conservando el orden de los atributos para la compatibilidad de
formato de archivo; en XSD, tales atributos pelados son simplemente omiten como el uso de formatos XML etiquetas con nombre y sin ninguna
dependencia orden.
4.2.7.2.1 definición IfcSpace
Un espacio representa un área o volumen delimitado realmente o teóricamente. Los espacios son áreas o volúmenes que proporcionan ciertas
funciones dentro de un edificio.
Un espacio está asociado a una historia edificio (o en el caso de los espacios exteriores a un sitio). Un espacio puede abarcar lo largo de varios
espacios conectados. Por lo tanto, un grupo espacial prevé un conjunto de espacios incluidos en una historia. Un espacio también se puede
descomponer en partes, donde cada parte define un espacio parcial. Esto se define por el atributo CompositionType de la
IfcSpatialStructureElement supertipo que se interpreta como sigue:
• COMPLEX = grupo espacial
• ELEMENT = espacio

• Parcial = espacio parcial
NOTA: Ver las definiciones y acuerdos de implementación puede restringir con espacios
CompositionType = elemento a que no se solapan.
El IfcSpace se utiliza para construir la estructura espacial de un edificio (que sirve como el desglose del proyecto principal y se requiere para ser
jerárquica). Los elementos de estructura espacial están unidos entre sí mediante el uso de los IfcRelAggregates relación objetivados. La siguiente
figura muestra la IfcSpace como parte de la estructura espacial. También sirve como el contenedor espacial para los elementos relacionados con el
espacio.
NOTA: requisitos detallados sobre las relaciones de contención elemento y estructura de colocación obligatoria se dan en definiciones de
vista y acuerdos implementador.
Figura 31 ifcSpace - estructura espacial
Las siguientes directrices serán aplicables para el uso del nombre, descripción, LongName y ObjectType atributos.
• Nombre contiene el nombre único (o el número de espacio) del plan.
• Descripción tiene ningún campo de información adicional que el usuario puede haber especificado, no hay recomendaciones
adicionales.
• LongName contiene el nombre completo del espacio, a menudo se utiliza además del nombre, si se asigna un número a la habitación, a
continuación, el nombre descriptivo se intercambia como LongName.
• ObjectType mantiene el tipo de espacio, es decir, por lo general la categoría funcional del espacio.
NOTA: En caso de incompatibilidad entre la representación geométrica de la IfcSpace y las representaciones geométricas combinadas de
la IfcRelSpaceBoundary circundante, la representación geométrica del espacio debe tener prioridad sobre la representación geométrica
de los contornos de los espacios circundantes. La figura a continuación describe las alturas y las elevaciones de la IfcSpace.

Figura 32 ifcSpace - Heights
HISTORIA nueva entidad en IFC1.0
Atributo Definición del uso previsto
• elevación del espacio (parte superior de la losa de la construcción) es igual a la elevación de la historia: proporcionado por
IfcBuildingStory.Elevation relación a IfcBuilding.ElevationOfRefHeight
• elevación del suelo de espacio (parte superior del suelo en la parte superior de la losa): proporcionado por
IfcSpace.ElevationWithFlooring relación a IfcBuilding.ElevationOfRefHeight
• altura del espacio (parte superior de la losa debajo a la parte inferior de la losa arriba): proporcionado por BaseQuantity con Name = "altura"
• la altura del suelo del espacio (parte superior de la losa de abajo para la parte superior de suelo): proporcionado por BaseQuantity con Name =
"FinishFloorHeight"
• altura de la red del espacio (parte superior del piso hasta la parte inferior del techo suspendido): proporcionada por BaseQuantity con nombre =
"FinishCeilingHeight"
Especificación EXPRESS:
ENTIDAD IfcBuildingStorey
Subtipo de ( IfcSpatialStructureElement);

Elevación : OPCIONAL IfcStrippedOptional;

END_ENTITY;
Definiciones de atributos:
Elevación : Elevación de la base de este suelo, con relación a la altura de referencia interno 0,00 del edificio. El nivel 0.00 se
da por la absoluta encima de la altura del nivel del mar por el atributo ElevationOfRefHeight dada en IfcBuilding.
Gráfico herencia:
ENTIDAD IfcRoot
GlobalID : IfcGloballyUniqueId;
OwnerHistory : OPCIONAL IfcOwnerHistory;
Nombre : OPCIONAL IfcLabel;
Descripción : OPCIONAL IfcText;
ENTIDAD IfcObjectDefinition
INVERSO
HasAssignments : CONJUNTO DE IfcRelAssigns PARA RelatedObjects;
hasContext : SET [ 0: 1] DE IfcRelDeclares PARA RelatedDefinitions;

IsDecomposedBy : CONJUNTO DE IfcRelAggregates PARA RelatingObject;
Se descompone : SET [ 0: 1] DE IfcRelAggregates PARA RelatedObjects;

HasAssociations : CONJUNTO DE IfcRelAssociates PARA RelatedObjects;
ENTIDAD IfcObject
ObjectType : OPCIONAL IfcStrippedOptional;
INVERSO
IsTypedBy : SET [ 0: 1] DE IfcRelDefinesByType PARA RelatedObjects;

Es definido por : CONJUNTO DE IfcRelDefinesByProperties PARA RelatedObjects;
ENTIDAD IfcProduct
ObjectPlacement : OPCIONAL IfcStrippedOptional;
Representación : OPCIONAL IfcStrippedOptional;
ENTIDAD INVERSA IfcSpatialElement
LongName
: OPCIONAL IfcStrippedOptional;
INVERSO
ContainsElements : CONJUNTO DE IfcRelContainedInSpatialStructure PARA RelatingStructure;
ENTIDAD IfcSpatialStructureElement
CompositionType : OPCIONAL IfcStrippedOptional;
END_ENTITY;
<Xs: element name = tipo "IfcBuildingStorey" = "IFC: IfcBuildingStorey" substitutionGroup = "IFC: IfcSpatialStructureElement" nillable = "true" />
<Xs: complexType name = "IfcBuildingStorey"> <xs:
complexContent>
<Xs: extensión de la base = "IFC: IfcSpatialStructureElement" /> </ xs:
complexContent> </ xs: complexType>

4.2.7.2.2 Definición IfcBuildingStory
La historia edificio tiene una elevación y típicamente representa un (casi) la agregación horizontal de los espacios que están unidas verticalmente.
Se cuenta una historia (si se especifica) asociado a un edificio. Una historia puede abarcar lo largo de varios storys conectadas. Por lo tanto
compleja historia proporciona una colección de storys incluidos en un edificio. Una historia también se puede descomponer en partes
(horizontical), donde cada parte define una historia parcial. Esto se define por el atributo de tipo de composición de los
IfcSpatialStructureElements supertipo que se interpreta como sigue:
• COMPLEJO: compleja historia de la construcción
• ELEMENTO: historia de la construcción
• PARCIAL: historia de la construcción parcial
Ejemplo En las casas de niveles, una historia se divide en dos o más storys parciales, cada uno con una elevación diferente. Puede ser manejado
mediante la definición de una historia, que incluye dos o más storys parciales con las elevaciones individuales.
El IfcBuildingStory se utiliza para construir la estructura espacial de un edificio (que sirve como el desglose del proyecto principal y se requiere para
ser jerárquica). Los elementos de estructura espacial están unidos entre sí mediante el uso de los IfcRelAggregates relación objetivados. La
siguiente figura muestra la IfcBuildingStory como parte de la estructura s patial. También sirve como el contenedor espacial para la construcción y
otros elementos.

Figura 33 ifcBuildingStory - estructura espacial
La figura a continuación describe las alturas y las elevaciones de la IfcBuildingStory.

• elevación de la historia proporcionada por: IfcBuildingStory.Elevation como un valor de altura local en relación con
IfcBuilding.ElevationOfRefHeight, por lo general es la parte superior de la losa de construcción
• altura de la red de la historia, también denominado en altura o altura del sistema como el total (parte superior de la losa de construcción al principio de la losa de
construcción anterior): proporcionado por BaseQuantity con Name = "GrossHeight"
• altura de la red de la historia (parte superior de la losa de la construcción hasta la parte inferior de la losa de construcción anterior): proporcionada por
BaseQuantity con nombre = "NetHeight"
Figura 34 ifcBuildingStory - Heights
Subtipo de ( IfcSpatialStructureElement); Elevación

END_ENTITY;
Elevación : Elevación de la base de este suelo, con relación a la altura de referencia interno 0,00 del edificio. El nivel 0.00 se
da por la absoluta encima de la altura del nivel del mar por el atributo ElevationOfRefHeight dada en IfcBuilding.
Gráfico herencia:
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcObject
INVERSO

ENTIDAD IfcProduct
LongName
INVERSO
END_ENTITY;
<Xs: element name = tipo "IfcBuildingStorey" = "IFC: IfcBuildingStorey" substitutionGroup = "IFC: IfcSpatialStructureElement" nillable = "true" />
<Xs: complexType name = "IfcBuildingStorey"> <xs:
complexContent>

4.2.7.2.3 definición IfcBuilding
Un edificio representa una estructura que proporciona refugio para sus ocupantes o de los contenidos y se encuentra en un solo lugar. El edificio
también se utiliza para proporcionar un elemento básico dentro de la jerarquía de la estructura espacial de los componentes de un proyecto de
construcción (junto con el sitio, la historia, y en el espacio).
NOTA Definición de la norma ISO 6707-1:
Los trabajos de construcción que tiene la provisión de refugio para sus ocupantes o contenidos como uno de sus objetivos principales y normalmente está
diseñado para soportar de forma permanente en un solo lugar.
Un edificio está (si se especifica) asociado a un sitio. Un edificio puede abarcar lo largo de varios edificios conectados o desconectados.
Por lo tanto la construcción de complejo prevé un conjunto de edificios incluidos en un sitio. Un edificio también se puede descomponer
en partes (verticales), donde cada parte define una sección edificio. Esta
es definido por la composición tipo de atributo de supertipo
IfcSpatialStructureElements que se interpreta como siguen:
• COMPLEJO: edificio complejo
• ELEMENTO: edificio
• PARCIAL: sección del edificio
El IfcBuilding se utiliza para construir la estructura espacial de un edificio (que sirve como el desglose del proyecto principal y se requiere para ser
jerárquica). Los elementos de estructura espacial están unidos entre sí mediante el uso de los IfcRelAggregates relación objetivados. La siguiente figura
muestra la IfcBuilding como parte de la estructura espacial. También sirve como contenedor espacial para la construcción y otros elementos.
Figura 35 ifcBuilding - estructura espacial

HISTORIA nueva entidad en IFC1.0.
Sistemas, como por ejemplo servicio de construcción o sistemas de distribución eléctrica, sistemas zonales, o sistemas de análisis estructurales, se refieren a
IfcBuilding mediante el uso de los IfcRelServicesBuildings relación objetivados.
La figura a continuación describe las alturas y las elevaciones de la IfcBuilding. Se utiliza para proporcionar la altura sobre el nivel del mar del
proyecto altura del punto para este edificio, es decir, la altura interior de 0.00. La altura
0,00 se utiliza a menudo como una altura de referencia interna de construcción y igual al nivel de acabado del piso de la planta baja.
• elevación de la base de edificio proporcionada por: IfcBuilding.ElevationOfRefHeight, por lo general es la parte superior de la losa de construcción
• elevación de la base de terreno en el perimetro de el edificio proporcionada por:

IfcBuilding.ElevationOfTerrain terreno, por lo general es la elevación mínima está inclinado
• altura total del edificio, también se conoce como altura de la cresta (parte superior de la estructura del techo, por ejemplo, la cresta contra terreno):
proporcionado por BaseQuantity con Name = "totalheight"
• aleros altura del edificio (base de estructura de techo, por ejemplo, los aleros contra terreno): proporcionado por BaseQuantity con
Name = "EavesHeight"
Figura 36 ifcBuilding - Heights

ENTIDAD IfcBuilding
ElevationOfRefHeight : OPCIONAL IfcStrippedOptional;
ElevationOfTerrain : OPCIONAL IfcStrippedOptional;
BuildingAddress : OPCIONAL IfcStrippedOptional;
END_ENTITY;
ElevationOfRefHeight : Altura sobre el nivel del mar de la altura de referencia utilizado para todas las medidas de elevación del suelo, es igual a la altura 0.0. Por lo
general, el nivel de planta baja.
ElevationOfTerrain : Altura sobre el nivel del terreno mínimo alrededor de la huella del edificio, dada en la elevación sobre el nivel del
mar.
BuildingAddress : Dirección dada al edificio a efectos postales.
Gráfico herencia:
ENTIDAD IfcBuilding
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcObject
INVERSO

ENTIDAD IfcProduct
LongName
INVERSO
ENTIDAD IfcBuilding
ElevationOfRefHeight : OPCIONAL IfcStrippedOptional;
ElevationOfTerrain : OPCIONAL IfcStrippedOptional;
BuildingAddress : OPCIONAL IfcStrippedOptional;
END_ENTITY;

<Xs: element name = tipo "IfcBuilding" = "IFC: IfcBuilding" substitutionGroup = "IFC: IfcSpatialStructureElement" nillable = "true" />
<Xs: complexType name = "IfcBuilding"> <xs:

complexContent>
4.2.7.2.4 Definición IfcSite
Un sitio es un área definida de tierra, posiblemente cubierto con agua, en el que la construcción del proyecto es para ser completado. Un sitio puede
ser utilizada para erigir, reequipar o baje edificio (s), o para otros desarrollos relacionados con la construcción.
NOTA Plazo según el "área de tierra o agua donde se realice el trabajo de construcción o el desarrollo de otros" ISO6707-1
vocabulario.
Un sitio puede incluir una definición de la único punto de referencia geográfica para este sitio (posición global utilizando WGS84 con longitud,
latitud y elevación). La precisión se proporciona hasta millonésima parte de un segundo y proporciona una colocación absoluta en relación con
el mundo real tal como se utiliza en el intercambio con los sistemas de información geospational. Si afirmado, la longitud, latitud y elevación
establecer el punto en WGS84, donde el punto 0., 0., 0. de está situado el LocalPlacement de IfcSite.
La colocación geométrica del sitio, definido por la IfcLocalPlacement, será siempre relativa al elemento de estructura espacial, en el
que se incluye este sitio, o absoluta, es decir, al sistema de coordenadas, según lo establecido por el contexto representación
geométrica del proyecto. El sistema de coordenadas mundo, establecida en los IfcProject.RepresentationContexts, puede incluir una
definición del norte verdadero en el plano XY
el sistema de coordenadas, Si previsto, eso pueden obtenerse en
IfcGeometricRepresentationContext.TrueNorth.
Un proyecto puede abarcar lo largo de varios sitios conectados o desconectados. Por lo tanto compleja sitio proporciona para una colección de sitios
incluidos en un proyecto. Un sitio también se puede descomponer en partes, donde cada parte define una sección de sitio. Esta
es definido por el atributo de tipo composición de supertipo
IfcSpatialStructureElements que se interpreta como siguen:
• COMPLEX = complejo sitio

• ELEMENTO = sitio
• PARCIAL sección del sitio =
El IfcSite se utiliza para construir la estructura espacial de un edificio (que sirve como el desglose del proyecto principal y se requiere para
ser jerárquica). La siguiente figura muestra la IfcSite como parte de la estructura espacial. Además de la estructura espacial lógico,
también se muestra la jerarquía de la colocación. En este ejemplo, la jerarquía de la estructura espacial y la jerarquía de colocación son
idénticos.

Figura 37 ifcSite - estructura espacial
La figura a continuación describe las alturas y las elevaciones de la IfcSite. Se utiliza para proporcionar la geográfica longitud, latitud y
altura sobre el nivel del mar para el origen del sitio. El origen del sitio es la colocación local.
La provisión de longitud, latitud, altura a la IfcSite para georreferenciación se proporciona por motivos de compatibilidad hacia arriba. Se requiere
una única instancia de IfcSite y WGS84 como sistema de coordenadas de referencia.
Para georeferenciación exacta (o hacer referencia a cualquier otro sistema de coordenadas geográficas que no sea WSG84) las entidades
IfcCoordinateReferenceSystem y IfcMapConversion tienen que ser usado para definir un mapeo exacto de la ingeniería del proyecto sistema de
coordenadas a la geográfica (o mapa) sistema de coordenadas.
• altura de referencia de sitio se proporciona por: IfcSite.RefElevation, se le da de acuerdo con la referencia de altura utilizado en esta
ubicación.
• la altura de referencia de cada edificio situado en el lugar se da Againt la misma referencia de altura utilizado en este lugar.
• las elevaciones de cada historia que pertenece a cada edificio se dan como altura local en relación con la altura de referencia del
edificio.

Figura 38 ifcBuilding - Heights
ENTIDAD IfcSite
RefLatitude : OPCIONAL IfcStrippedOptional;
RefLongitude : OPCIONAL IfcStrippedOptional;
RefElevation : OPCIONAL IfcStrippedOptional;
LandTitleNumber : OPCIONAL IfcStrippedOptional;
Dirección del sitio : OPCIONAL IfcStrippedOptional;
END_ENTITY;
RefElevation : Datum elevación respecto al nivel del mar.

LandTitleNumber : El número de títulos de propiedad (designación de la página dentro de un sistema regional).
Dirección del sitio : Dirección dada al sitio con fines postales.
Gráfico herencia:
ENTIDAD IfcSite
ENTIDAD IfcRoot


INVERSO


ENTIDAD IfcObject
INVERSO

ENTIDAD IfcProduct
LongName
INVERSO
ENTIDAD IfcSite
RefLatitude : OPCIONAL IfcStrippedOptional;
RefLongitude : OPCIONAL IfcStrippedOptional;
RefElevation : OPCIONAL IfcStrippedOptional;
LandTitleNumber : OPCIONAL IfcStrippedOptional;
Dirección del sitio : OPCIONAL IfcStrippedOptional;
END_ENTITY;
<Xs: element name = tipo "IfcSite" = "IFC: IfcSite" substitutionGroup = "IFC: IfcSpatialStructureElement" nillable = "true" /> <xs: complexType name =
"IfcSite"> <xs: complexContent>
4.2.7.2.5 Definición IfcProject
IfcProject indica la realización de algunos de diseño, ingeniería, construcción, mantenimiento o actividades que conducen hacia un producto. El proyecto
establece el contexto para la información a intercambiar o compartir, y puede representar un proyecto de construcción, pero no tiene que hacerlo. El principal
propósito de IfcProject en una estructura de intercambio es proporcionar la instancia de la raíz y el contexto para todos los demás elementos de información
incluidos.
El contexto proporcionado por el IfcProject incluye:

• las unidades por defecto
• el contexto representación geométrica para estructuras de intercambio incluyendo representaciones de la forma

• el sistema de coordenadas mundo
• la dimensión espacio de coordenadas

• la precisión utilizada dentro de las representaciones geométricas, y

• opcionalmente la indicación del norte verdadero con respecto al sistema de coordenadas
IFC4 cambiar los atributos RepresentationContexts y UnitsInContext se hizo opcional y se promueven a supertipo IfcContext.
Proposiciones informales:
Sólo será un proyecto dentro del contexto de cambio. Esto se hace cumplir por el IfcSingleProjectInstance regla global.
ENTIDAD IfcProject
Subtipo de ( IfcContext);
DÓNDE
HasName : EXISTE (AUTO \ IfcRoot.Name);
CorrectContext : NO (existe (AUTO \ IfcContext.RepresentationContexts)) OR (sizeof (query (Temp <* Auto \
IfcContext.RepresentationContexts |
'IFCREPRESENTATIONRESOURCE.IFCGEOMETRICREPRESENTATIONSUBCONTEXT' IN TypeOf (Temp))) =
0);
NoDecomposition : Sizeof (SELF \ IfcObjectDefinition.Decomposes) = 0;
HasOwnerHistory : EXISTE (AUTO \ IfcRoot.OwnerHistory);
END_ENTITY;
Las proposiciones formales:
HasName : Los Nombre atributo tiene que ser prevista IfcProject. Es el nombre corto para el proyecto.
CorrectContext : Si una RepresentationContexts relación se proporciona a continuación, no habrá instancia de
IfcGeometricRepresentationSubContext directamente incluida en el conjunto de RepresentationContexts.
NoDecomposition : El IfcProject representa la raíz del árbol de cualquier descomposición. Será, por tanto, no se puede utilizar para descomponer cualquier otra
definición del objeto.
HasOwnerHistory : Los OwnerHistory atributo tiene que ser prevista IfcProject. Proporciona el mínimo de la información del propietario de los datos
del proyecto conjunto y la última acción de cambio, que se aplica a todo el conjunto de datos.
NOTA Cada dato individual, que se deriva de IfcRoot puede tener un individuo
OwnerHistory. A continuación, anula la información de propiedad y la acción común prevista oportunidad en la única
instancia IfcProject en un conjunto de datos IFC. IFC4 CAMBIO Nuevo en regla.
Gráfico herencia:
ENTIDAD IfcProject
ENTIDAD IfcRoot


INVERSO


ENTIDAD IfcContext
Nombre largo : OPCIONAL IfcStrippedOptional;
Fase : OPCIONAL IfcStrippedOptional;
RepresentationContexts: OPCIONAL SET [ 1 :?] DE IfcStrippedOptional; UnitsInContext
: OPCIONAL IfcUnitAssignment;
INVERSO
Es definido por : SET [ 0 :?] DE IfcRelDefinesByProperties PARA RelatedObjects;

declara : CONJUNTO DE IfcRelDeclares PARA RelatingContext;
ENTIDAD IfcProject
END_ENTITY;
<Xs: element name = tipo "IfcProject" = "IFC: IfcProject" substitutionGroup = "IFC: IfcContext" nillable = "true" /> <xs: complexType name =
"IfcProject"> <xs: complexContent>
<Xs: extensión de la base = "IFC: IfcContext" /> </ xs:
4.2.7.2.6 Definición IfcZone
Una zona es un grupo de espacios, espacios parciales u otras zonas. estructuras de zona no pueden ser jerárquica (en contra de la
estructura espacial de un proyecto - ver IfcSpatialStructureElement), es decir, uno IfcSpace individuo puede estar asociada con cero, uno, o
varios IfcZone de. IfcSpace de se agrupan en un IfcZone utilizando el IfcRelAssignsToGroup relación objetivada como se especifica en el
IfcGroup supertipo.
NOTA Algunos casos de uso pueden restringir la libertad de relaciones no jerárquicas. En algunos casos de uso de servicio de edificios de la
zona indica un volumen delimitado basado vista con el propósito de análisis y cálculo. Este tipo de zona no puede superponerse con respecto a
ese análisis, pero puede superponerse otra manera.
IFC4 cambiar la entidad que ahora se subtipificados de IfcSystem (no su IfcGroup supertipo) con compatibilidad ascendente para el intercambio de archivos basado.
ENTIDAD IfcZone
Subtipo de ( IfcSystem); Nombre

largo : OPCIONAL IfcStrippedOptional;
DÓNDE

WR1 : (Sizeof (AUTO \ IfcGroup.IsGroupedBy) = 0) o (sizeof (Query (temp <* AUTO \ IfcGroup.IsGroupedBy [1] .RelatedObjects |
NOT (( 'IFCPRODUCTEXTENSION.IFCZONE' IN TypeOf (temp)) OR (' IFCPRODUCTEXTENSION.IFCSPACE' IN typeOf
(temp)) OR ( 'IFCPRODUCTEXTENSION.IFCSPATIALZONE' IN typeOf (temp))))) = 0);
END_ENTITY;
Nombre largo : Nombre largo para una zona, que se utiliza para los propósitos informales. Se debe utilizar, si está disponible, en conjunción con el
heredado Nombre atributo. NOTA En muchos escenarios de la Nombre atributo se refiere al nombre corto o el número de una zona, y el Nombre
largo se refiere al nombre completo.
IFC4 cambiar el atributo se ha agregado al final de la definición de la entidad.
WR1 : Un IfcZone se agrupa por la IfcRelAssignsToGroup relación objetivado. Sólo los objetos de tipo IfcSpace, y IfcZone IfcSpatialZone
se permiten como RelatedObjects.
Gráfico herencia:
ENTIDAD IfcZone
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcObject
INVERSO

ENTIDAD IfcGroup
INVERSO
IsGroupedBy : CONJUNTO DE IfcRelAssignsToGroup PARA RelatingGroup;
ENTIDAD IfcSystem
ENTIDAD INVERSA IfcZone

LongName
END_ENTITY;
<Xs: element name = tipo "IfcZone" = "IFC: IfcZone" substitutionGroup = "IFC: IfcSystem" nillable = "true" /> <xs: complexType name =
"IfcZone"> <xs: complexContent>
<Xs: extensión de la base = "IFC: IfcSystem" />

</ Xs: complexContent> </ xs:
complexType>
4.2.7.2.7 Definición IfcSystem
Un sistema es una combinación organizada de partes relacionadas dentro de un producto de AEC, compuesto para un propósito común o función o
para proporcionar un servicio. Un sistema es esencialmente una agregación funcionalmente relacionados de productos. La relación de agrupación a
uno o varios casos de IfcProduct (los miembros del sistema) es manejado por IfcRelAssignsToGroup.
Nótese el uso de IfcSystem a menudo se aplica a la representación de servicios de construcción de sistemas relacionados, tales como el sistema de tuberías,
sistema de agua fría, etc. Los miembros dentro de un sistema de este tipo pueden o no pueden estar conectados utilizando las entidades de conectividad
relacionados (a través de IfcDistributionPort).
ENTIDAD IfcSystem
Supertipo ( IfcZone)
Subtipo de ( IfcGroup);
END_ENTITY
INVERSA;
Gráfico herencia:
ENTIDAD IfcSystem
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcObject
INVERSO

ENTIDAD IfcGroup
INVERSO
ENTIDAD IfcSystem
END_ENTITY
INVERSA;

<Xs: element name = tipo "IfcSystem" = "IFC: IfcSystem" substitutionGroup = "IFC: IfcGroup" nillable = "true" /> <xs: complexType name =
"IfcSystem"> <xs: complexContent>
<Xs: extensión de la base = "IFC: IfcGroup" /> </ xs:
4.2.7.2.8 definición IfcElement
Un elemento es una generalización de todos los componentes que conforman un producto AEC. Esos elementos pueden ser lógicamente contenidas por
un elemento de estructura espacial que constituye un cierto nivel dentro de una jerarquía estructura del proyecto (sitio, construcción, historia o espacio).
Esto se hace mediante el uso de la relación IfcRelContainedInSpatialStructure.
Los elementos son objetos físicamente existentes, aunque podrían ser elementos vacíos, tales como los agujeros. Elementos, ya sea de modo
permanente el producto AEC, o sólo de forma temporal, como encofrado hace. Los elementos pueden ser o bien montados en el sitio o pre-fabricado y
construidos en el sitio.
Ejemplo Los ejemplos de elementos en un contexto de construcción de edificios son paredes, suelos, ventanas y rebajes.
Un elemento puede tener información relevante y la cantidad asignada a través de la relación IfcRelAssociatesMaterial y
IfcRelDefinesByProperties.
Además un elemento puede ser declarada a ser una ocurrencia específica de un tipo de elemento (y de ese modo ser definido por las
propiedades del tipo elemento) usando la relación IfcRelDefinesByType.
Un elemento puede también ser definido como un conjunto de elemento que es un grupo de elementos relacionados semánticamente y
topológicamente que forman una parte mayor nivel de producto AEC. Esos conjuntos de elementos se definen en virtud de la relación
IfcRelAggregates.
Ejemplos Ejemplo de conjunto de elemento son estructuras de techo completos, hechos por varias áreas del techo, o una escalera, compuesto por
los vuelos y aterrizajes.
Elementos que realiza la misma función se pueden agrupar por un "grupo de elementos Por Function". Se realiza por una instancia
de IfcGroup con el ObjectType = 'ElementGroupByFunction".
Cantidad Uso Definición
Las cantidades relativas a la IfcElement se definen por la IfcElementQuantity y unidos por los IfcRelDefinesByProperties. Una
especificación detallada para cantidades individuales se introduce en el nivel de los subtipos de IfcElement.
Geometría utilizar definiciones
La representación geométrica de cualquier IfcElement está dada por la IfcProductDefinitionShape y IfcLocalPlacement permitiendo
múltiples representaciones geométricas. Una especificación detallada para la colocación y la forma REPRESENTACIÓN locales se
introduce a nivel de los subtipos de IfcElement.

ENTIDAD IfcElement
Subtipo de ( IfcProduct); Etiqueta
INVERSO
Conectado a : CONJUNTO DE IfcRelConnectsElements PARA RelatingElement;
IsConnectionRealization: CONJUNTO DE IfcRelConnectsWithRealizingElements PARA RealizingElements; ConnectedFrom

: CONJUNTO DE IfcRelConnectsElements PARA RelatedElement;
ContainedInStructure: SET [ 0: 1] DE IfcRelContainedInSpatialStructure PARA RelatedElements;

END_ENTITY;
Etiqueta : La etiqueta (o etiqueta) identificador en el caso particular de un producto, por ejemplo, el número de serie, o el número de
posición. Es el identificador en el nivel de ocurrencia.
Conectado a : Referencia a la relación de conexión del elemento. La relación se refiere entonces al otro elemento a la que este
elemento está conectado.
IsConnectionRealization: La referencia a la relación de conexión con el elemento de darse cuenta. La relación, si se proporciona,
asigna este elemento como el elemento de la realización de la conexión, que proporciona la manifestación física de la
relación de conexión.
ConnectedFrom : Referencia a la relación de conexión del elemento. La relación se refiere entonces al otro elemento que está
conectado a este elemento.
ContainedInStructure : Relación de contención con el elemento de estructura espacial, a la que el elemento se asocia principalmente. Esta relación de
contención tiene que ser jerárquica, es decir, un elemento solamente se puede asignar directamente a la estructura espacial cero o
uno.
Gráfico herencia:
ENTIDAD IfcElement
ENTIDAD IfcRoot
GlobalID : IfcGloballyUniqueId ;
OwnerHistory : OPCIONAL IfcOwnerHistory ;
Nombre : OPCIONAL IfcLabel ;
Descripción : OPCIONAL IfcText ;
INVERSO


ENTIDAD IfcObject
Tipo de objeto : OPCIONAL IfcStrippedOptional ;

INVERSO

ENTIDAD IfcProduct
ObjectPlacement : OPCIONAL IfcStrippedOptional ;

Representación : OPCIONAL IfcStrippedOptional ;
ENTIDAD INVERSA IfcElement

Etiqueta : OPCIONAL IfcStrippedOptional ;

INVERSO
Conectado a : CONJUNTO DE IfcRelConnectsElements PARA RelatingElement;
IsConnectionRealization: CONJUNTO DE IfcRelConnectsWithRealizingElements PARA RealizingElements; ConnectedFrom

: CONJUNTO DE IfcRelConnectsElements PARA RelatedElement;

END_ENTITY;
<Xs: element name = tipo "IfcElement" = "IFC: IfcElement "Abstracto =" true "substitutionGroup =" IFC: IfcProduct "Nillable =" true "/>
<Xs: complexType name = "IfcElement" abstracto = "true"> <xs:
complexContent> <xs: base de extensión = "IFC: IfcProduct "/> </ Xs:
4.2.7.2.9 definición IfcElementType
IfcElementType define una lista de compartidos en común las definiciones de conjuntos de propiedades de un elemento y un conjunto opcional de representaciones
de productos. Se utiliza para definir una especificación del elemento (es decir, la información específica del producto, que es común a todas las apariciones de ese
tipo de producto).
NOTA El producto representaciones se definen como mapas de representación (a nivel de la IfcTypeProduct supertipo, que se
asigna por una instancia elemento a través de la IfcShapeRepresentation.Item [1] ser un IfcMappedItem.
Un tipo de elemento se utiliza para definir las propiedades comunes de un determinado tipo o estilo de un elemento que puede aplicarse a los
casos de que tipo de elemento para asignar un estilo específico. tipos de elementos (los subtipos instanciables) pueden ser intercambiados sin
ser ya asignado a ocurrencias.
HISTORIA nueva entidad en IFC2x2
ENTIDAD IfcElementType
Subtipo de ( IfcTypeProduct); Tipo de
elemento : OPCIONAL IfcStrippedOptional;
END_ENTITY;
Tipo de elemento : El tipo denota un tipo particular que indica el objeto adicional. El uso tiene que ser establecido a nivel de los subtipos
instanciables. En particular, se considera el tipo definido por el usuario, si la enumeración del atributo 'PredefinedType' se
establece en UserDefined.
Gráfico herencia:
ENTIDAD IfcElementType
ENTIDAD IfcRoot


INVERSO


ENTIDAD IfcTypeObject ApplicableOccurrence: OPCIONAL IfcStrippedOptional;

HasPropertySets
: OPCIONAL SET [ 1 :?] DE IfcPropertySetDefinition;
INVERSO
tipos : SET [ 0: 1] DE IfcRelDefinesByType PARA RelatingType;

ENTIDAD IfcTypeProduct
RepresentationMaps : OPCIONAL LISTA [ 1 :?] de Unique IfcStrippedOptional;
Etiqueta : OPCIONAL IfcStrippedOptional;
ENTIDAD INVERSA IfcElementType
ElementType
END_ENTITY;
<Xs: element name = tipo "IfcElementType" = "IFC: IfcElementType" abstracto = "true" substitutionGroup = "IFC: IfcTypeProduct" nillable = "true" />
<Xs: complexType name = "IfcElementType" abstracto = "true"> <xs:

complexContent>
<Xs: extensión de la base = "IFC: IfcTypeProduct" /> </ xs:
4.2.7.2.10 definición IfcTask
Un IfcTask es una unidad identificable de trabajo que se lleva a cabo en un proyecto de construcción.
Una tarea se suele utilizar para describir una actividad para la construcción o instalación de los productos, pero no se limita a estos tipos. Por
ejemplo, podría ser utilizado para describir procesos de diseño, mueva operaciones y otras actividades de diseño, construcción y operación
relacionadas.
Las cantidades de recursos consumidos por la tarea se tratan mediante la definición de la IfcElementQuantity para el recurso y no en la
instancia de IfcTask.
HISTORIA nueva entidad en IFC1.0. El nuevo nombre de IfcWorkTask en IFC2x.
IFC4 cambiar los atributos TaskTime y PredefinedType añaden. IfcMove y IfcOrderRequest se ha eliminado en IFC4 y ahora están
representados por IfcTask. IfcRelAssignsTasks relación se ha eliminado también.
Atributo de usar la definición
Cada aparición de IfcTask se le da un nombre que es indicativo de su contenido (IfcRoot.Name). Una descripción textual de la tarea puede ser
proporcionado y esto puede ser elaborado más de una descripción narrativa de largo

(IfcProcess.LongDescription). Un método de trabajo puede ser declarado por el método de trabajo utilizado en la realización de una tarea. Una tarea
se identifica como siendo una tarea hito o no. Una tarea hito se define por la IsMilestone marcador. y no tiene duración. Un estado y la prioridad para
cada tarea también se pueden establecer.
El tiempo y la utilización de duración definición
En comparación con el anterior CFI libera, información en tiempo tarea básica (hora de inicio programada, prevista hora de finalización,
duración) está unido directamente a través del atributo IfcTask TaskTime. tareas regulares se definen a través IfcTaskTime. Las tareas
recurrentes se definen a través IfcTaskTimeRecurring. En el caso de una tarea periódica se deriva de una tarea periódica ambas tareas deben
ser unidos entre sí a través de una relación IfcRelNests, donde los puntos IfcRelNests.IsNestedBy a la tarea repetitiva y puntos
IfcRelNests.Nests a todas las tareas regulares que han sido derivados de la tarea repetitiva.
Representación de otras actividades
Las definiciones de uso para IfcTask se han generalizado para representar otras actividades también, incluidas las actividades que habían sido
definidos por las entidades propias de la CFI anterior Releases. Esto incluye
• acciones de orden
• Las operaciones de movimiento
IfcTask representa una orden que podrían ser llevada a cabo por un servicio de asistencia actuando el papel de interfaz para la organización entre el
usuario de una instalación y el requisito funcional de cumplir con sus necesidades. La tarea real representado por la entidad IfcTask se está convirtiendo
en una solicitud de una orden y el inicio de la acción que permitirá a la orden para ser completado. El IfcProjectOrder o uno de sus subtipos que incluyen
órdenes de trabajo de mantenimiento, está relacionada con el uso de IfcTask IfcRelAssignsToControl.
IfcTask también se puede utilizar para describir una actividad que mueve a las personas, grupos dentro de una organización u
organizaciones completas junto con sus muebles y equipos asociados de un lugar a otro. Por lo tanto, sustituye a la anterior entidad IFC
IfcMove. La funcionalidad está representado en IfcTask como sigue:
Pasar de: El lugar desde el que actores y su equipo asociado se están moviendo. Uso IfcRelAssignsToProcess donde
RelatingProcess puntos a la tarea y RelatedObjects fija la ubicación (s) a partir de la cual moverse.
Mover a: El lugar en que los actores y su equipo asociado se están moviendo. Uso IfcRelAssignsToProduct donde RelatedObjects
puntos a la tarea (s) y los puntos RelatingProduct a la ubicación en la que se mueven.
lista de verificación: Una lista de los puntos relativos a un movimiento que requieren atención. Utilice longdescription o bien identificar sub-tareas a realizar un seguimiento de
los elementos de lista punzón de forma individual a través de IfcRelNests.
ENTIDAD IfcTask
Subtipo de ( IfcProcess); Estado

WorkMethod : OPCIONAL IfcStrippedOptional;
IsMilestone : IfcStrippedOptional;
Prioridad : OPCIONAL IfcStrippedOptional;
TaskTime : OPCIONAL IfcTaskTime;

PredefinedType : OPCIONAL IfcStrippedOptional;

DÓNDE
HasName : EXISTE (AUTO \ IfcRoot.Name);
CorrectPredefinedType: NO (EXISTE (PredefinedType)) OR (PredefinedType <> IfcTaskTypeEnum.USERDEFINED) OR
((PredefinedType = IfcTaskTypeEnum.USERDEFINED) y existe (auto \ IfcObject.ObjectType));
END_ENTITY;
Estado : Estado actual de la tarea.

NOTA Los valores particulares para el estado no se especifican, estos deben ser determinados y acordados por el uso local. Ejemplos
de posibles valores de estado incluyen 'no ha comenzado', 'Started', 'Completado'.
WorkMethod : El método de trabajo utilizado en la realización de una tarea.
NOTA Este atributo no se debe utilizar si se especifica el método de trabajo para el IfcTaskType
IsMilestone : Identifica si una tarea es una tarea hito (= TRUE) o no (= FALSE). NOTA En las aplicaciones de planificación de proyectos pequeños,
una tarea hito puede ser entendida como una tarea que no tiene duración. Como tal, representa un punto singular en el tiempo.
Prioridad : Un valor que indica la prioridad relativa de la tarea (en comparación con las prioridades de otras tareas).
TaskTime : Información de tiempo para la tarea. IFC4

cambio de atributo añadido
HasName : El atributo de nombre debe ser insertado para describir el nombre de la tarea.
CorrectPredefinedType: El ObjectType atributo debe afirmarse cuando el valor de PredefinedType se establece en

USUARIO DEFINIDO.
Gráfico herencia:
ENTIDAD IfcTask
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcObject
INVERSO

ENTIDAD identificación
IfcProcess : OPCIONAL IfcStrippedOptional;
Descripción larga : OPCIONAL IfcStrippedOptional;
INVERSO

IsPredecessorTo : CONJUNTO DE IfcRelSequence PARA RelatingProcess;
IsSuccessorFrom : CONJUNTO DE IfcRelSequence PARA RelatedProcess;
ENTIDAD IfcTask
Estado : OPCIONAL IfcStrippedOptional;

WorkMethod : OPCIONAL IfcStrippedOptional;
IsMilestone : IfcStrippedOptional;
Prioridad : OPCIONAL IfcStrippedOptional;
TaskTime : OPCIONAL IfcTaskTime;
END_ENTITY;
<Xs: element name = tipo "IfcTask" = "IFC: IfcTask" substitutionGroup = "IFC: IfcProcess" nillable = "true" /> <xs: complexType name =
"IfcTask"> <xs: complexContent>
<Xs: base de extensión = "IFC: IfcProcess"> <xs:

secuencia>
<Xs: element name = tipo "TaskTime" = "IFC: IfcTaskTime" nillable = "true" minOccurs = "0" /> </ xs: secuencia> </ xs:
extension> </ xs: complexContent> </ xs: complexType>
4.2.7.2.11 IfcActor Definición
El IfcActor define todos los actores o agentes que participen en un proyecto durante su ciclo de vida completo. Se facilita el uso de de personas y
organizaciones las definiciones en la parte de recursos del modelo de objeto IFC. Esto incluye el nombre, la dirección, las direcciones de
telecomunicaciones, y los roles.
ENTIDAD IfcActor
Subtipo de ( IfcObject); El
actor : IfcActorSelect;
END_ENTITY
INVERSA;
El actor : Información sobre el actor.
Gráfico herencia:
ENTIDAD IfcActor
ENTIDAD IfcRoot
INVERSO



ENTIDAD IfcObject
INVERSO

ENTIDAD IfcActor
TheActor : IfcActorSelect;
INVERSO
END_ENTITY;
<Xs: element name = tipo "IfcActor" = "IFC: IfcActor" substitutionGroup = "IFC: IfcObject" nillable = "true" /> <xs: complexType name =
"IfcActor"> <xs: complexContent>
<Xs: base de extensión = "IFC: IfcObject"> <xs:

secuencia>
<Xs: element name = "TheActor"> <xs:
complexType>
<Xs: grupo ref = "IFC: IfcActorSelect" /> </ xs:
complexType> </ xs: element> </ xs: secuencia> </
xs: extension> </ xs: complexContent> </ xs:
complexType>
4.2.7.2.12 IfcActionRequest Definición
Una solicitud es el acto o instancia de pedir algo, como una solicitud de información, la presentación de ofertas, o el rendimiento del
trabajo.
Las solicitudes pueden tomar muchas formas dependiendo de la necesidad que incluye informes de falta de mantenimiento, las solicitudes de obras pequeñas, y las
solicitudes de compra (donde vayan a realizarse a través de un servicio de asistencia o la función de compra).
HISTORIA nueva entidad en IFC2x2.

IFC4 CAMBIO atributo RequestID renombrado a Identificación y ascendido a supertipo IfcControl, atributos
PredefinedType, Estado, y Descripción larga adicional.
ENTIDAD IfcActionRequest
Subtipo de ( IfcControl);
END_ENTITY;

Estado : El estado actualmente asignado a la solicitud. Los valores posibles son: Retención: esperar a ver si se
pide además que se reciban antes de decidir noaction acción: se requiere ninguna acción de esta
solicitud
Horario: plan de acción se lleve a cabo como parte del mantenimiento u otra tarea de planificación / programación Urgente: tomar
medidas de inmediato IFC4 cambiar el atributo se ha agregado.
Descripción larga : Descripción detallada del permiso. IFC4 cambiar el

atributo se ha añadido.
Gráfico herencia:
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcObject
INVERSO

IfcControl : OPCIONAL IfcStrippedOptional;
INVERSO
controles : CONJUNTO DE IfcRelAssignsToControl PARA RelatingControl;
END_ENTITY;
<Xs: element name = tipo "IfcActionRequest" = "IFC: IfcActionRequest" substitutionGroup = "IFC: IfcControl" nillable = "true" /> <xs: complexType name =
"IfcActionRequest"> <xs: complexContent>
<Xs: extensión de la base = "IFC: IfcControl" /> </ xs:

4.2.7.2.13 IfcProcess Definición

IfcProcess se define como una actividad individual o evento, que se ordena en el tiempo, que tiene relaciones de secuencia con otros procesos,
que transforma de entrada en la salida, y puede conectarse a otros otros procesos a través de relaciones de salida de entrada. Un IfcProcess
puede ser una actividad (o tarea), o un evento. Se toma generalmente lugar en la construcción de edificios con la intención de diseño, cálculo de
costos, adquisición, construcción o mantenimiento de los productos u otros similares y tareas o procedimientos. La figura a continuación ilustra las
relaciones de proceso.
Figura 39 ifcProcess
NOTA Definición de acuerdo con ISO9000: Un proceso es un conjunto de actividades que están interrelacionados o que interactúan entre sí. Procesos
utilizan recursos para transformar entradas en salidas.
Procesos están interconectados debido a que la salida de un proceso se convierte en la entrada para otro proceso. En efecto, los procesos
se "pegan" juntos por medio de dichas relaciones de salida de entrada.
IFC2x cambiar el atributo de la productividad ha sido retirado.
IFC4 cambiar el atributo de identificación ha sido promovido de subtipos IfcTask y otros.
uso Relación definición
información del proceso se relaciona con otros objetos mediante el establecimiento de las relaciones siguientes:
• Anidación de procesos: IfcRelNests - Un proceso puede contener sub procesos y por lo tanto pueden anidar.
• La secuenciación de los procesos: IfcRelSequence - Los procesos pueden ser colocados en secuencia (incluyendo la superposición de
tareas en paralelo), y tienen predecesores y sucesores.

• proceso de asignación de horarios: a IfcRelAssignsToControl - Actividades tales como las tareas y las tareas de resumen
predominantemente, son asignados a un horario de trabajo.
• Tener un producto asignado al proceso como entrada: IfcRelAssignsToProcess - Los productos pueden ser asignados como entrada a un
proceso, como para la planificación del proceso de construcción.
• Tener un producto asignado al proceso como salida: IfcRelAssignsToProduct - los productos se pueden asignar como salida a un
proceso, como para la planificación del proceso de construcción.
• Tener un control asignado al proceso de control de procesos como: IfcRelAssignsToProcess - Los elementos que actúan como control en el
proceso se puede asignar a un proceso, como por la gestión de costes (un elemento de coste asignado a una tarea de trabajo).
• Después de asignar un recurso a el proceso como consumido por el proceso:

IfcRelAssignsToProcess - Los elementos que actúan como un mecanismo para un proceso, tales como la mano de obra, materiales y equipos en los
cálculos de costes.
ENTIDAD IfcProcess
ABSTRACTO Supertipo ( IfcTask)

Subtipo de ( IfcObject);
Identificación : OPCIONAL IfcStrippedOptional;
INVERSO
END_ENTITY;
Identificación : Una designación de identificación dado a un proceso o actividad. Es el identificador en el nivel de ocurrencia.
IFC4 cambio de atributo promovido de subtipos.

Descripción larga : Una descripción extendida o narrativa que puede ser proporcionada. IFC4 CAMBIAR
nuevo atributo.
IsPredecessorTo : Dependencia entre dos actividades, se refiere a la actividad subsiguiente para que esta actividad es el predecesor. El enlace entre
dos actividades puede incluir un tipo de enlace y un tiempo de retraso.
IsSuccessorFrom : Dependencia entre dos actividades, se refiere a la actividad anterior para el que esta actividad es el sucesor. El enlace entre dos
actividades puede incluir un tipo de enlace y un tiempo de retraso.
Gráfico herencia:
ENTIDAD IfcProcess
ENTIDAD IfcRoot
INVERSO



ENTIDAD IfcObject
INVERSO

ENTIDAD IfcProcess
Identificación : OPCIONAL IfcStrippedOptional;

INVERSO
END_ENTITY;
<Xs: element name = tipo "IfcProcess" = "IFC: IfcProcess" abstracto = "true" substitutionGroup = "IFC: IfcObject" nillable = "true" /> <xs: complexType name =
"IfcProcess" abstracto = "true"> <xs: complexContent>
<Xs: extensión de la base = "IFC: IfcObject" /> </ xs:

4.2.7.2.14 ifcGroup Definición
IfcGroup es una generalización de cualquier grupo arbitrario. Un grupo es una colección lógica de objetos. No tiene su propia posición, ni puede
mantener su propia representación de forma. Por lo tanto un grupo es una agregación bajo algunos aspectos no geométricas / topológicos de
agrupación.
Nota El uso IfcRelDecomposes junto con los subtipos apropiados de IfcProduct para definir una agregación de productos que pueden
tener su propia posición y la forma de representación.
Ejemplo Un ejemplo de un grupo es un sistema, ya que los elementos agrupa bajo el aspecto de su papel, independientemente de su posición
en un edificio.
Un grupo puede contener cualquier colección de objetos (el ser productos, procesos, controles, recursos, actores o otros grupos). Por lo tanto los
grupos se pueden anidar. Un objeto puede ser parte de cero, uno, o muchos grupos. las relaciones de agrupación no están obligados a ser
jerárquica ni implican una dependencia.
Nota El uso IfcRelDecomposes junto con los subtipos apropiados de IfcProduct para definir una agregación jerárquica de productos.
Un grupo puede ser intercambiado sin tener ya los objetos dentro de la colección grupo.
IFC4 cambiar la relación inversa IsGroupedBy se establece en 0..n

Los grupos se asignan a otros objetos (tales como un proceso o un recurso) por el objeto relación que se refiere al objeto
correspondiente:
• Proceso: asignado usando IfcRelAssignsToProcess
• De recursos: asignado usando IfcRelAssignsToResource
• Los grupos pueden ser sometidos a un control. Se asignará la información de control:
• Controles: que afecta al grupo utilizando IfcRelAssignsToControl
ENTIDAD IfcGroup
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcObject
INVERSO

ENTIDAD IfcGroup
INVERSO
END_ENTITY;
<Xs: element name = tipo "IfcGroup" = "IFC: IfcGroup" substitutionGroup = "IFC: IfcObject" nillable = "true" /> <xs: complexType name =
"IfcGroup"> <xs: complexContent>
<Xs: extensión de la base = "IFC: IfcObject" /> </ xs:

complexContent> </ xs: complexType
4.2.7.2.15 IfcPropertySet Definición
IfcPropertySet define todas las propiedades dinámicamente extensibles. El conjunto de propiedades es una clase de contenedor que contiene propiedades dentro de
un árbol de propiedad. Estas propiedades son interpretados de acuerdo con su atributo de nombre.
El mismo IfcPropertySet puede asignarse a múltiples ocurrencias de objeto; debe entonces ser asignado por un solo caso de IfcRelDefinedByProperties a
un conjunto de objetos relacionados. Esos conjuntos de propiedades se denominan conjuntos de propiedades compartidas. También se puede asignar a
un tipo de objeto.

Un IfcPropertySetTemplate puede definir la estructura subyacente, es decir, el nombre requerido, tipos de objeto o de objetos aplicable a la que
el conjunto de propiedades puede ser unidos, y las propiedades individuales que tal vez incluidos.
NOTA Véase IfcRelDefinesByType de cómo reemplazar los conjuntos de propiedades asignadas a un tipo de objeto dentro de la ocurrencia objeto.
IFC4 cambiar todas las entidades de conjuntos de propiedades definida estáticamente ya no son subtipos de IfcPropertySet.
Los conjuntos de propiedades están relacionadas con otros objetos mediante el objeto relación que se refiere al objeto correspondiente:
• Objeto ocurrencia: IfcRelDefinesByProperties utilizando el inverso atribuyen DefinesOccurrence.
• Tipo de objeto: utilizando un enlace directo por atributos inversa DefinesType.
• plantilla subyacente: IfcRelDefinesByTemplate usando el atributo inversa isDefinedBy.
• La referencia externa: subtipos de IfcRelAssociates se utilizan para proporcionar un enlace a un sistema de clasificación, o una biblioteca
externa que proporcione referencia adicional al conjunto de propiedades. Accesible por HasAssociations atributos inversos.
Las instancias de IfcPropertySet se utilizan para asignar conjuntos con nombre de propiedades individuales (complejo o propiedades individuales). Cada
propiedad individual tiene una cadena de nombre significativo. Algunos conjuntos de propiedades se incluyen en la especificación de la CFI y tienen un
conjunto predefinido de propiedades indicadas mediante la asignación de un nombre significativo. Estos conjuntos de propiedades se enumeran en "conjuntos
de propiedades" elemento del menú principal dentro de esta memoria y de la hoja de la documentación objeto para los objetos a los que son aplicables. La
convención de nomenclatura "Pset_Xxx" se aplica a todos los conjuntos de propiedades que se definen como parte de la especificación de la CFI y se utilizará
como el valor del atributo Name.
Además, cualquier conjunto de propiedades definido por el usuario puede ser capturado. Los conjuntos de propiedades que no están declarados como parte de la
especificación CFI tendrán un valor de nombre sin incluir el prefijo "Pset_".
ENTIDAD IfcPropertySet
Subtipo de ( IfcPropertySetDefinition);
HasProperties : SET [ 1 :?] DE IfcProperty;
DÓNDE
ExistsName : EXISTE (AUTO \ IfcRoot.Name);
UniquePropertyNames: IfcUniquePropertyName (HasProperties);
END_ENTITY;
HasProperties : Contenido conjunto de propiedades. Para conjuntos de propiedades definidas como parte del modelo de objeto IFC, los objetos de propiedad
dentro de un conjunto de propiedades se definen como parte de la norma. Si una propiedad no es

contenida dentro del conjunto de propiedades predefinidas, su valor no se ha establecido en este momento.
ExistsName : Los Nombre atributo tiene que ser proporcionada. El atributo se utiliza para especificar el significante del conjunto de propiedades. Las
propiedades que se les permite ser fijado a un conjunto de propiedades particular, se pueden administrar dentro del conjunto propiedad parte
de definición de la especificación de IFC. Esas definiciones de propiedades de establecer referencias en la sección de definición semántica
de los subtipos de individal IfcObjectDefinition.
UniquePropertyNames: Cada subtipo individual de IfcProperty dentro del conjunto de propiedades tendrá un único Nombre
valor de atributo.
Gráfico herencia:
ENTIDAD IfcRoot
ENTIDAD IfcPropertyDefinition
INVERSO

ENTIDAD IfcPropertySetDefinition
INVERSO
DefinesType : CONJUNTO DE IfcTypeObject PARA HasPropertySets;
DefinesOccurrence : SET [ 0: 1] DE IfcRelDefinesByProperties PARA RelatingPropertyDefinition;

HasProperties : SET [ 1 :?] DE IfcProperty;
END_ENTITY;
<Xs: element name = tipo "IfcPropertySet" = "IFC: IfcPropertySet" substitutionGroup = "IFC: IfcPropertySetDefinition" nillable = "true" />
<Xs: complexType name = "IfcPropertySet"> <xs:

complexContent>
<Xs: base de extensión = "IFC: IfcPropertySetDefinition"> <xs:
secuencia>
<Xs: element name = "HasProperties"> <xs:
complexType> <xs: secuencia>
<Xs: element ref =: maxOccurs "IFC IfcProperty" = "sin límites" /> </ xs: secuencia>
<Xs: atributo ref = "IFC: tipoElemento" fijo = "IFC: IfcProperty" /> <xs: atributo
ref = "IFC: cType" fijo = "set" /> <xs: atributo ref = "IFC: arraysize" uso =
"opcional" /> </ xs: complexType> </ xs: element> </ xs: secuencia> </ xs:

4.2.7.2.16 IfcAnnotation Definición
Una anotación es una representación gráfica en el contexto geométrico (y espacial) de un proyecto, que añade una nota o significado a los objetos
que constituyen el modelo del proyecto. Anotaciones incluyen puntos adicionales, curvas, texto, dimensionamiento, la eclosión y otras formas de
notas gráficas. También incluye representaciones simbólicas de los componentes del modelo adicionales, productos que no representan o
estructuras espaciales, tales como puntos de topografía, líneas de contorno o similar.
NOTA información de presentación adicional (a menudo 2D) como el número de la etiqueta o de la eclosión, que está directamente relacionado
con una representación particular del producto incluido en el IfcProductDefinitionShape que tienen diversas IfcShapeRepresentation de de la
IfcElement (y sus subtipos). Sólo aquellos información de presentación, que no puede ser directamente relacionado con un solo producto, tiene
que ser envuelto dentro de la IfcAnnotation.
Si está disponible, la anotación debe estar relacionado con el contexto espacial del proyecto, al contener la anotación en el nivel
apropiado de la estructura del edificio (sitio, construcción, historia, o espacio). Esto es manejado por la relación
IfcRelContainedInSpatialStructure.
El IfcAnnotation puede proporcionar artículos específicos 0D, 1D y 2D geométricas como representación de la anotación, ofreciendo punto
de anotación, curvas, y las superficies. Los siguientes valores se utilizarán para la ObjectType.
• 'Punto de anotación' es una anotación proporcionada por un punto que tiene semántica adicional. El ObjectType atributo
heredado se debe utilizar para capturar el tipo de punto de anotación, algunos valores predefinidos son:
• '-Topográfico': Un punto de levantamiento único representado por un punto cartesiano. Un conjunto de propiedades puede añadir las condiciones (método,
accurracy, etc., para el punto de medición).
• 'SurveyArea': Un conjunto de puntos de medición representada por el punto cartesiano. Estas coordenadas se determinan con relación a las
coordenadas de un punto de referencia, que actúa como el punto de referencia para la encuesta. Propiedades adjuntas se aplican por igual a
todos los puntos. La diferencia de altura de los puntos de medición permite terreno que se determine.
• 'Curva de anotación' es una anotación proporcionada por una curva que tiene semántica adicional. El ObjectType atributo
heredado debe ser utilizado para capturar el tipo de curva de la anotación, algunos valores predefinidos son:
• 'Línea de contorno': Una línea de elevación constante utiliza normalmente en los mapas geográficos donde el espaciamiento de líneas en intervalos
constantes de elevación se puede utilizar como una indicación de la pendiente.
• 'Isobara': Una línea de presión constante utiliza normalmente en los mapas del tiempo o para mostrar gradiente de presión en los espacios,
cámaras o externamente.
• 'Isolux': Una línea de iluminación constante normalmente se utiliza para mostrar la distribución de los niveles de iluminación y / o la luz del día en
un espacio o externamente.
• 'Isoterma': Una línea de temperatura constante normalmente se utiliza para mostrar la distribución y el efecto de calentamiento o enfriamiento dentro de
un espacio o para mostrar la distribución de temperatura en un mapa geográfico.
• 'Superficie de anotación' es una anotación proporcionada por una superficie que tiene semántica adicional. El ObjectType atributo
heredado se debe utilizar para capturar el tipo de anotación superficie, algunos valores predefinidos son:

• 'SurveyArea': Un parche de superficie basado en puntos de la encuesta.
ENTIDAD IfcAnnotation
Subtipo de ( IfcProduct);
INVERSO

END_ENTITY;
ContainedInStructure : Relación con un elemento de estructura espacial, a la que el asociado se asocia principalmente.
Gráfico herencia:
ENTIDAD IfcAnnotation
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcObject
INVERSO

ENTIDAD IfcProduct
ENTIDAD INVERSA IfcAnnotation
INVERSO

END_ENTITY;
<Xs: element name = tipo "IfcAnnotation" = "IFC: IfcAnnotation" substitutionGroup = "IFC: IfcProduct" nillable = "true" /> <xs: complexType name =
"IfcAnnotation"> <xs: complexContent>
<Xs: extensión de la base = "IFC: IfcProduct" /> </ xs:

4.2.7.2.17 IfcRelConnectsPorts Definición
Una relación IfcRelConnectsPorts define la relación que se hace entre dos puertos en su punto de conexión. Se puede incluir la
geometría de conexión entre dos puertos.
Los IfcRelConnectsPorts relación objetivados se requiere para definir cómo dos casos de IfcPort se conectan entre sí. Cada uno de los
puertos está contenido dentro de la lógica IfcDistributionElement mediante el uso de las IfcRelNests colección ordenada.
HISTORIA nueva entidad en IFC2.0, modificado en IFC2x.
IFC4 CAMBIO Anteriormente la contención de la IfcPort dentro de la IfcDistributionElement había sido realizado utilizando la relación
IfcRelConnectsPortToElement.
ENTIDAD IfcRelConnectsPorts
Subtipo de ( IfcRelConnects);
RelatingPort : IfcPort;
RelatedPort : IfcPort;
RealizingElement : OPCIONAL IfcStrippedOptional;
DÓNDE
NoSelfReference : RelatingPort: <>: RelatedPort;
END_ENTITY;
RelatingPort : Referencia al primer puerto que está conectado por la relación objetivado.
RelatedPort : Referencia al segundo puerto que está conectado por la relación objetivado.
RealizingElement : Define el elemento que da cuenta de una relación de conexión de puerto.
NoSelfReference : La instancia de la RelatingPort no será la misma instancia que el RelatedPort.
Gráfico herencia:
ENTIDAD IfcRoot
ENTIDAD IfcRelationship
ENTIDAD IfcRelConnects
RelatingPort : IfcPort;
RelatedPort : IfcPort;
RealizingElement : OPCIONAL IfcStrippedOptional;
END_ENTITY;
<xs: element name = tipo "IfcRelConnectsPorts" = "IFC: IfcRelConnectsPorts" substitutionGroup = "IFC: IfcRelConnects"

nillable = "true" />

<Xs: complexType name = "IfcRelConnectsPorts"> <xs:
complexContent>
<Xs: base de extensión = "IFC: IfcRelConnects"> <xs:
secuencia>
<Xs: element name = tipo "RelatingPort" = "IFC: IfcPort" nillable = "true" /> <xs: element name
= tipo "RelatedPort" = "IFC: IfcPort" nillable = "true" /> </ xs: secuencia> </ xs: extension> </ xs:
4.2.7.2.18 IfcWorkSchedule Definición
Un IfcWorkSchedule representa una planificación de la tarea de un plan de trabajo, que a su vez puede contener un conjunto de programas para
diferentes propósitos. La siguiente figura muestra la estructura de cadena principal de un programa de trabajo que define (1) un contexto a través de
IfcRelDeclares (no necesariamente el proyecto) y (2) controla las tareas (normalmente la tarea de resumen horario) y los recursos. Tenga en cuenta que
un calendario de trabajo será asignado a la tarea de resumen y no el horario de trabajo.
Declaración de uso Definición
IfcWorkSchedule puede hacer referencia a un proyecto (la única instancia IfcProject) a través de IfcRelDeclares.
ENTIDAD IfcWorkSchedule
Subtipo de ( IfcWorkControl);
DÓNDE
CorrectPredefinedType: NO (EXISTE (PredefinedType)) OR (PredefinedType <>
IfcWorkScheduleTypeEnum.USERDEFINED) OR ((PredefinedType =
IfcWorkScheduleTypeEnum.USERDEFINED) y existe (auto \ IfcObject.ObjectType));
END_ENTITY;
CorrectPredefinedType: El atributo ObjectType debe afirmarse cuando el valor de la IfcWorkScheduleTypeEnum

se establece en UserDefined.

Figura 40 IfcWorkSchedule
Gráfico herencia:
ENTIDAD IfcRoot


INVERSO


ENTIDAD IfcObject
INVERSO

IfcControl : OPCIONAL IfcStrippedOptional;
INVERSO
controles : CONJUNTO DE IfcRelAssignsToControl PARA RelatingControl;
ENTIDAD IfcWorkControl
CreationDate : IfcDateTime;
creadores : OPCIONAL SET [ 1 :?] DE IfcStrippedOptional;
Propósito : OPCIONAL IfcStrippedOptional;
Duración : OPCIONAL IfcStrippedOptional;
TotalFloat : OPCIONAL IfcStrippedOptional;
Hora de inicio : IfcDateTime;
Tiempo de finalización : OPCIONAL IfcStrippedOptional;
END_ENTITY;
<Xs: element name = tipo "IfcWorkSchedule" = "IFC: IfcWorkSchedule" substitutionGroup = "IFC: IfcWorkControl" nillable = "true" />
<Xs: complexType name = "IfcWorkSchedule"> <xs:
complexContent>
<Xs: extensión de la base = "IFC: IfcWorkControl" /> </ xs:
4.2.7.2.19 IfcRelAssociatesDocument Definición
La relación objetivado (IfcRelAssociatesDocument) se encarga de la asignación de un documento de información (artículos de la

selecta IfcDocumentSelect) a los objetos ocurrencias (subtipos de IfcObject) o tipos de objetos (subtipos de IfcTypeObject).
La relación se utiliza para asignar una referencia de documento o una información más detallada de documentos a los objetos. Una referencia de
documento solo se puede aplicar a varios objetos.

Los RelatedObjects atributo heredado definen los objetos a los que se aplica la asociación documento. El RelatingDocument atributo
es la referencia a una referencia de documento, aplicada al objeto (s).
HISTORIA nueva entidad en IFC2x.
ENTIDAD IfcRelAssociatesDocument
Subtipo de ( IfcRelAssociates);
RelatingDocument : IfcDocumentSelect;
END_ENTITY;
RelatingDocument : Información del documento o referencia que se aplica a los objetos.
Gráfico herencia:
ENTIDAD IfcRoot
ENTIDAD IfcRelAssociates
RelatedObjects : SET [ 1 :?] DE IfcDefinitionSelect;
RelatingDocument : IfcDocumentSelect;
END_ENTITY;
<Xs: element name = tipo "IfcRelAssociatesDocument" = "IFC: IfcRelAssociatesDocument" substitutionGroup =

"IFC: IfcRelAssociates" nillable = "true" /> <xs: complexType name = "IfcRelAssociatesDocument"> <xs:
complexContent>
<Xs: base de extensión = "IFC: IfcRelAssociates"> <xs:

secuencia>
<Xs: element name = "RelatingDocument"> <xs:
complexType>
<Xs: grupo ref = "IFC: IfcDocumentSelect" /> </ xs:
complexType> </ xs: element> </ xs: secuencia> </ xs:
4.2.7.2.20 IfcRelConnectsWithRealizingElements Definición
IfcRelConnectsWithRealizingElements define una relación genérica que se hace entre dos elementos que requieren la realización de
esa relación por medio de elementos realizando más.

Un IfcRelConnectsWithRealizingElements es una especialización de IfcRelConnectsElement donde la operación de conexión tiene el

atributo adicional de (uno o varios) elementos que pueden ser utilizados para realizar o calificar aún más la relación darse cuenta. Se
define como una relación ternaria.
Ejemplo Se puede utilizar para describir la unión de un elemento a otro, donde la unión se realiza por un elemento de 'fijación' tal como
un soporte. También puede ser usado para describir el montaje de un elemento a otro, como el requisito de los principales elementos
de la planta de montaje en constructores trabajan bases y / o aisladores de anti-vibración.
ENTIDAD IfcRelConnectsWithRealizingElements
Subtipo de ( IfcRelConnectsElements);
RealizingElements : SET [ 1 :?] DE IfcElement;
Tipo de conección : OPCIONAL IfcStrippedOptional;
END_ENTITY;
RealizingElements : Define los elementos que dan cuenta de una relación de conexión.
Tipo de conección : El tipo de la conexión dada para los propósitos informales, puede incluir etiquetas, como 'conjunta', 'unión rígida', 'junta flexible',
etc.
Gráfico herencia:
ENTIDAD IfcRoot
ENTIDAD IfcRelConnects
ENTIDAD IfcRelConnectsElements ConnectionGeometry: OPCIONAL IfcStrippedOptional;
RelatingElement
: IfcElement;
RelatedElement : IfcElement;
RealizingElements : SET [ 1 :?] DE IfcElement;
Tipo de conección : OPCIONAL IfcStrippedOptional;
END_ENTITY;
<Xs: element name = tipo "IfcRelConnectsWithRealizingElements" = "IFC: IfcRelConnectsWithRealizingElements" substitutionGroup = "IFC:

IfcRelConnectsElements" nillable = "true" /> <xs: complexType name = "IfcRelConnectsWithRealizingElements"> <xs: complexContent>
<Xs: base de extensión = "IFC: IfcRelConnectsElements"> <xs:

secuencia>
<Xs: element name = "RealizingElements">

<Xs: complexType> <xs:

secuencia>
<Xs: element ref =: maxOccurs "IFC IfcElement" = "sin límites" /> </ xs: secuencia>
<Xs: atributo ref = "IFC: tipoElemento" fijo = "IFC: IfcElement" /> <xs: atributo
ref = "IFC: cType" fijo = "set" /> <xs: atributo ref = "IFC: arraysize" uso =
"opcional" /> </ xs: complexType> </ xs: element> </ xs: secuencia> </ xs:
4.2.7.2.21 IfcConstructionProductResource Definición
IfcConstructionProductResource define el papel de un producto que se consume (total o parcialmente), o ocupado en el desempeño
de la construcción.
HISTORIA nueva entidad en IFC2.0. El nuevo nombre de IfcProductResource en IFC2x.
Ocurrencias de IfcConstructionProductResource son el uso de productos para ayudar al proceso de construcción. Más específicamente, son el
uso de los productos que resultan de algunos procesos de construcción y que se utilizan a continuación como recursos para facilitar aún más la
construcción. Por ejemplo, encofrados pueden ser instanciados como productos resultantes del proceso de 'construcción de encofrado'. Sin
embargo, se utilizan como recursos en el proceso de 'vaciar el concreto' en una etapa posterior del proyecto.
ENTIDAD IfcConstructionProductResource
Subtipo de ( IfcConstructionResource);
DÓNDE
CorrectPredefinedType: NO (EXISTE (PredefinedType)) OR (PredefinedType <>
IfcConstructionProductResourceTypeEnum.USERDEFINED) OR ((PredefinedType =
IfcConstructionProductResourceTypeEnum.USERDEFINED) y existe (auto \ IfcObject.ObjectType));
END_ENTITY;
PredefinedType : Define tipos de recursos de productos de construcción. IFC4 nuevo

atributo.
Gráfico herencia:
ENTIDAD IfcRoot

INVERSO


ENTIDAD IfcObject
INVERSO

IfcResource : OPCIONAL IfcStrippedOptional;
INVERSO
ENTIDAD Uso IfcConstructionResource

BaseCosts : OPCIONAL LISTA [ 1 :?] DE IfcStrippedOptional;
Cantidad base : OPCIONAL IfcStrippedOptional;
END_ENTITY;
<Xs: element name = tipo "IfcConstructionProductResource" = "IFC: IfcConstructionProductResource" substitutionGroup = "IFC:

IfcConstructionResource" nillable = "true" /> <xs: complexType name = "IfcConstructionProductResource"> <xs:
complexContent>
<Xs: extensión de la base = "IFC: IfcConstructionResource" /> </ xs:

4.2.7.2.22 IfcConstructionProductResourceType Definición
El tipo de recurso IfcConstructionProductType define información común compartida por las ocurrencias de los recursos de productos de
construcción. El conjunto de información compartida puede incluir:
• productividades comunes
• las tasas de costos comunes
• propiedades comunes dentro de los conjuntos de propiedades compartidas
Se utiliza para definir una especificación de recursos producto de construcción (es decir, la información de recursos específica que es común a todas
las apariciones de ese recurso). Los tipos de recursos pueden ser intercambiados sin ser ya asignado a ocurrencias.
ocurrencias de la IfcConstructionProductResourceType están representados por instancias de

IfcConstructionProductResource.
HISTORIA nueva entidad en IFC4.

Asignación uso definición
Además de las tareas especificadas en el IfcConstructionResourceType clase base, un tipo de recurso producto de construcción puede
tener asignaciones de su propio uso de IfcRelAssignsToResource donde RelatingResource se refiere a la
IfcConstructionProductResourceType y RelatedObjects contiene uno o más subtipos IfcTypeProduct. Tal relación indica el tipo de
producto que se utiliza como entrada, que se instancia como una ocurrencia asignado para cada ocurrencia de recursos. Puede haber
múltiples cadenas de producción en el que este tipo de productos puede tener sus propios tipos de tareas y recursos asignados.
ENTIDAD IfcConstructionProductResourceType
Subtipo de ( IfcConstructionResourceType);
PredefinedType : IfcConstructionProductResourceTypeEnum;
DÓNDE
CorrectPredefinedType: (PredefinedType <> IfcConstructionProductResourceTypeEnum.USERDEFINED) OR
((PredefinedType = IfcConstructionProductResourceTypeEnum.USERDEFINED) y existe (auto \
IfcTypeResource.ResourceType));
END_ENTITY;
PredefinedType : Define tipos de recursos de productos de construcción.
Gráfico herencia:
ENTIDAD IfcRoot
INVERSO


ENTIDAD IfcTypeObject ApplicableOccurrence: OPCIONAL IfcStrippedOptional;

HasPropertySets
: OPCIONAL SET [ 1 :?] DE IfcPropertySetDefinition;
INVERSO
tipos : SET [ 0: 1] DE IfcRelDefinesByType PARA RelatingType;
IfcTypeResource : OPCIONAL IfcStrippedOptional;
Tipo de recurso : OPCIONAL IfcStrippedOptional;
INVERSO

ENTIDAD BaseCosts IfcConstructionResourceType

: OPCIONAL LISTA [ 1 :?] DE IfcStrippedOptional;
Cantidad base : OPCIONAL IfcStrippedOptional;
PredefinedType : IfcConstructionProductResourceTypeEnum;
END_ENTITY;
<Xs: element name = tipo "IfcConstructionProductResourceType" = "IFC: IfcConstructionProductResourceType" substitutionGroup = "IFC:

IfcConstructionResourceType" nillable = "true" /> <xs: complexType name = "IfcConstructionProductResourceType"> <xs: complexContent>
<Xs: extensión de la base = "IFC: IfcConstructionResourceType">

<Xs: atributo name = tipo "PredefinedType" = "IFC: IfcConstructionProductResourceTypeEnum" use = "opcional" /> </ xs: extension> </ xs:
4.2.7.3 Lista de datos de referencia del esquema definición
ISO 16739: 2013, “Industry Foundation Classes (IFC) para el intercambio de datos en las industrias de la construcción y gestión de instalaciones,”
comúnmente llamados IFC4, es el esquema estándar de referencia para definiciones de datos en este MVD. El uso de IFC4 en este MVD es opcional.
La compatibilidad hacia atrás a IFC 2x3 se mantiene durante todo el uso de COBIE y todos los ensayos descritos en esta norma.
4.2.7.4 Concepto lista
Los conceptos utilizados en este MVD son los siguientes:
• Identidad • Typing objeto
• Control de revisión • La contención espacial
• Restricciones de datos externas • Los conjuntos de propiedades para Ocurrencias
• Clasificación • Los conjuntos de propiedades para los tipos
• Composición espacial • programación de tareas
• Las cantidades de Ocurrencias • Conectividad secuencial
• Unidades de conversión • Contacto
• Declaración proyecto • Asignación de Control
• Asignación grupal
4.2.7.5 Conceptos definición
Cada entidad está en la lista con los correspondientes conceptos y un gráfico de atributos y objetos que representan la combinación de todos
los conceptos aplicados a instancias de la entidad. Cada bloque en el diagrama representa una entidad, donde se muestra el nombre de la
entidad en la parte superior del bloque con el fondo en negro. Cada atributo dentro de la entidad se muestra en la orden, en donde se utiliza
negro para indicar un atributo directa y gris se utiliza para indicar un atributo inversa. Notación a la derecha de cada atributo indica la
agregación, donde S indica un SET (objetos únicos no ordenadas) y L indica una lista (objetos ordenados), el primer número entre paréntesis
indica el número mínimo y el segundo número entre paréntesis indica el número máximo de

o “?” para un número ilimitado. Las líneas que conectan los bloques indican atributos que apuntan a objetos de otras definiciones de datos.
4.2.7.5.1 conceptos ifcSpace definición
Un espacio representa un área o volumen delimitado realmente o teóricamente. Los espacios son áreas o volúmenes que proporcionan ciertas
funciones dentro de un edificio.
El volumen de un espacio excluye revestimientos; las dimensiones verticales empiezan desde la parte superior de la losa debajo de y se extienden a la
parte inferior de la losa de arriba (excluyendo revestimientos para el suelo o falsos techos), y las dimensiones horizontales están delimitadas por las
extensiones de las paredes y columnas (con exclusión de los revestimientos, tales como paneles de yeso). El volumen de una habitación, sin embargo,
está limitada por tales cubiertas, y puede ser derivada restando tales dimensiones y se indica como la cantidad NetVolume.
El siguiente diagrama ilustra las entidades relacionadas, su cardinalidad de esperar, y propiedades.
Figura 41 Conceptos ifcSpace


4.2.7.5.2 conceptos ifcBuildingStory definición
Una historia edificio tiene una elevación y típicamente representa un (casi) la agregación horizontal de los espacios que están unidas
verticalmente. El siguiente diagrama ilustra las entidades relacionadas, su cardinalidad de esperar, y propiedades.
Figura 42 Conceptos ifcBuildingStory

4.2.7.5.3 conceptos ifcBuilding definición
Un edificio representa una estructura que proporciona refugio para sus ocupantes o de los contenidos y se encuentra en un solo lugar. El edificio también se
utiliza para proporcionar un elemento básico dentro de la jerarquía de la estructura espacial de los componentes de un proyecto de construcción (junto con el
sitio, la historia, y en el espacio). El siguiente diagrama ilustra las entidades relacionadas, su cardinalidad de esperar, y propiedades.
Figura 43 Conceptos ifcBuilding

4.2 7.5.4 conceptos ifcSite definición
Un sitio es un área definida de tierra, posiblemente cubierto con agua, en el que la construcción del proyecto es para ser completado. Un sitio puede
ser utilizado para erigir edificio (s) u otros productos de AEC. El siguiente diagrama ilustra las entidades relacionadas, su cardinalidad de esperar, y
propiedades.
Figura 44 Conceptos ifcSite
4.2.7.5.5 conceptos ifcProject definición
Todos los archivos IFC deben contener una sola instancia IfcProject que proporciona información de contexto global, incluyendo unidades por defecto, y
proporciona un directorio de objetos organizados dentro del proyecto.
Unidades de conversión:
Unidades de proyectos definen las unidades utilizadas en el intercambio de datos. Las unidades pueden ser traducidos durante la exportación e importación; es decir, el modelo
de origen, el intercambio de datos y el modelo resultante pueden todos tener diferentes unidades.
Las siguientes unidades deben estar apoyadas en todos los escenarios de cambio:
• Longitud
• Zona
• Volumen
• Ángulo
• Moneda

unidades adicionales deben ser compatibles si son necesarios en el contexto de un escenario de cambio. Cada valor de medida del mismo tipo en el
intercambio de datos utiliza la misma unidad. Cuando un importa datos de aplicación, se deja que el siguiente comportamiento en materia de
unidades:
unidades de Importación, ya que son, proporcionando las unidades se ajustan a las unidades utilizadas por la aplicación de importación.
Traduciendo a unidades del mismo sistema de la unidad, por ejemplo, milímetros a metros.
Traducción entre sistemas de unidades, por ejemplo, de milímetro a pulgadas. El usuario debe pedirá que acepte la traducción o cancelar la
importación.
Informar al usuario acerca de las unidades no soportados y la cancelación de la importación.
No se permite el siguiente comportamiento:
Importación de unidades de un sistema unidad apoyada sin traducción, si no se establecen las unidades en la aplicación receptora para que coincida con las unidades
utilizadas en el intercambio, por ejemplo importadores milímetros como metros.
Importación de unidades de un sistema de unidades no soportado sin traducción, por ejemplo, la importación de milímetros como pulgadas sin traducción.
No se permite unidades de mezcla de diferentes sistemas de unidades. Se requieren aplicaciones importadores para detectar configuraciones de unidades no válidas, y
notificar al usuario cancelar la importación.
Las restricciones adicionales han sido impuestas a las unidades, con el requisito de que los ángulos deben medirse en grados (en contraposición a
radianes).

Figura 45 Conceptos ifcProject
4.2.7.5.6 Definición Conceptos ifcZone
Una zona es un grupo de espacios, espacios parciales u otras zonas. estructuras de zona no pueden ser jerárquica (en contra de la
estructura espacial de un proyecto - ver IfcSpatialStructureElement), es decir, uno IfcSpace individuo puede ser asignado a cero, uno, o
varios IfcZone de. IfcSpace de se agrupan en un IfcZone utilizando el IfcRelAssignsToGroup relación objetivada como se especifica en el
IfcGroup supertipo.
4.2.7.5.7 conceptos ifcSystem definición
Un sistema es una combinación organizada de partes relacionadas dentro de un producto de AEC, compuesto para un propósito común o función o para
proporcionar un servicio. Un sistema es esencialmente una agregación funcionalmente relacionados de productos.
Los siguientes subtipos de IfcSystem están dentro del alcance de esta MVD (aunque los esquemas correspondientes no se incorporan dentro
de):
IfcBuildingSystem: Un conjunto de elementos de construcción diseñados para soportar, encerrar, sombra, aislar, o de otra manera realizar una función
común.
IfcDistributionSystem: Un conjunto de elementos de distribución diseñados para recibir, almacenar, mantener, distribuir, o controlar el flujo de un medio
de distribución.

Figura 46 ifcSystemConcepts

2.7.5.8 conceptos ifcElement definición
Un elemento representa un componente de construcción física. Todos los subtipos de IfcElement se encuentran dentro de alcance de este MVD (por
ejemplo, IfcBoiler), subtipos sin embargo instanciables no se incorporan dentro de esta documentación, por razones de brevedad.
Figura 47 Conceptos ifcElement

4.2.7.5.9 conceptos ifcElementType definición
Figura 48 Conceptos ifcElementType

4.2.7.5.10 conceptos ifcTask definición
Figura 49 Conceptos ifcTask

4.2.7.5.11 conceptos ifcActor definición
Para COBIE, esta entidad se utiliza para almacenar la información de contacto. Mientras COBIE no entra en detalles relaciones específicas
entre las personas y otros objetos (como una persona que ocupa un espacio), el usuario que posee en la actualidad un objeto se indique
mediante IfcOwnerHistory, donde dicha información de contacto puede ser localizado por la búsqueda de la IfcActor correspondiente. El
siguiente diagrama ilustra las entidades relacionadas, su cardinalidad de esperar, y propiedades.
Figura 50 Conceptos ifcActor

4.2.7.5.12 conceptos ifcActionRequest definición
Figura 51 Conceptos ifcActionRequest

4.2.7.5.13 conceptos ifcProcess definición
Un proceso es un conjunto de actividades que están relacionadas entre sí o que interactúan entre sí. Procesos utilizan recursos para
transformar entradas en salidas. Procesos están interconectados debido a que la salida de un proceso se convierte en la entrada para
otro proceso. En efecto, los procesos se "pegan" juntos por medio de dichas relaciones de entrada-salida.
El siguiente diagrama ilustra la entidad relacionada.
Figura 52 Conceptos ifcProcess
4.2.7.5.14
ifcGroup conceptos definición
Un grupo es una organización de elementos relacionados para un propósito funcional. subtipos específicos se utilizan para los escenarios particulares.

Figura 53 Conceptos ifcGroup
4.2.7.5.15 conceptos ifcPropertySet definición
Figura 54 ifcPropertySetConcepts
4.2.7.5.16 conceptos ifcAnnotation definición
Figura 55 ifcAnnotationConcepts

4.2.7.5.17 ifcRelConnectsPorts conceptos definición
Figura 56 Concepto ifcRelConnectsPort
4.2.7.5.18 conceptos ifcWorkSchedule definición
Figura 57 ifcWorkScheduleConcepts
4.2.7.5.19 conceptos ifcRelAssociatesDocument definición
Figura 58 ifcRelAssociates Documento
4.2.7.5.20 conceptos ifcRelConnectsWithRealizingElement definición

Figura 59 Conceptos ifcRelConnectsWithRealizingElement
4.2.7.5.21 conceptos ifcConstructionProductResource definición
Figura 60 Concepto ifcConstructionProductResource
4.2.7.5.22 Conceptos Definición ifcConstructionProductResourceType
Figura 61 Concepto ifcConstructionproductResourceType

4.2.7.6 Concepto lista de atributos
También se requiere que los conceptos a tener parámetros, propiedades o atributos que especifican los valores aplicables. Por ejemplo, los objetos de
plomería pueden hacer uso de puertos para permitir la conectividad a otros objetos para la distribución de agua, y una entidad específica tal como un
calentador de agua caliente puede tener puertos específicos tales como “ColdWaterIn” y “HotWaterOut”. Definición de atributos bajo conceptos permite la
reutilización de los conceptos en que las estructuras de datos son los mismos, pero los valores aplicables pueden ser diferentes.
4.2.7.6.1 limitaciones de los datos externos
Para aplicar COBIE en contextos fuera de aquellos en los que se podrían utilizar archivos STEP, esta norma proporciona transformaciones
opcionales entre las especificaciones estándar IFC subyacentes a los esquemas desarrollados usando SpreasheetML (Cobie hoja de cálculo) y
NIEM (COBieLite). Los detalles de estas alternativas, esquemas opcionales se encuentran en el Apéndice A.
Transformación de software, llamado el Cobie Toolkit, se proporciona como software de código abierto. Prueba de uso de ese COBIE ToolKit ha
verificado transformación pérdida-menos entre STEP, COBieSpreadsheet, y formatos COBieLite (para las entidades COBIE en el estudio).
4.2.7.6.2 Clasificación limitaciones
Las siguientes clasificaciones se proporcionan como valores por defecto en Cobie. clasificaciones regionales o específicos del cliente pueden
reemplazar estas clasificaciones.
Tabla 48 Restricciones de clasificación
Entidad Fuente Nombre fichas
IfcSpace Especificaciones de Construcción Instituto OmniClass Tabla 13 13-00 00 00
IfcBuilding Especificaciones de Construcción Instituto OmniClass Tabla 11 11-00 00 00
IfcZone Especificaciones de Construcción Instituto OmniClass Tabla 14 14-00 00 00
IfcSystem Especificaciones de Construcción Instituto OmniClass Tabla 21 21-00 00 00
IfcElement Especificaciones de Construcción Instituto OmniClass Tabla 22 22-00 00 00
IfcElementType construcción Especificaciones Instituto Tabla OmniClass 23 23-00 00 00 IfcTask
Especificaciones de Construcción Instituto OmniClass Tabla 31 31-00 00 00
IfcActor Especificaciones de Construcción Instituto OmniClass Tabla 34 34-00 00 00
IfcPropertySet construcción Especificaciones Instituto Tabla OmniClass 49 49-00 00 00
4.2.7.6.3 limitaciones composición espacial
Las siguientes entidades están obligados a estar presentes para cumplir con las reglas de negocio Cobie con respecto a las limitaciones espaciales:
• IfcSpace

• IfcBuildingStory
• IfcBuilding
• IfcSite
4.2.7.6.4 Las cantidades sobre las restricciones de eso ocurre se
Las siguientes cantidades IFC están obligados a estar presentes en cualquier caso de ifcSpace:
• IfcQuantityLength
• IfcQuantityArea (neto)
• IfcQuantityArea (Gross)
La siguiente cantidad IFC se requiere estar presente para cualquier caso de ifcSpace:
• IfcQuantityLength
4.2.7.6.5 limitaciones unidad de conversión
Se requieren las siguientes unidades de conversión de IFC para ser asociado con la entidad ifcProject:
• LENGTHUNIT
• AREAUNIT
• VOLUMEUNIT
• UNIDAD MONETARIA
4.2.7.6.6 limitaciones declaración de proyecto
Se requieren las siguientes entidades IFC para Declaraitions del proyecto:
• IfcActor
• IfcActionRequest
• IfcSystem
• IfcZone
• IfcTask
• IfcConstructionResource
• IfcTypeProduct
• IfcConstructionResourceType
4.2.7.6.7 limitaciones de la asignación de grupos
Los siguientes asignaciones de grupo están permitidos en Cobie:
• ifcZone - compuesto por clases de grupos de entidades ifcSpace
• ifcSystem - compuesto por clases de gropus de entidades ifcElement

4.2.7.6.8 limitaciones de escritura de objetos
Se requiere la siguiente tipificación objeto en COBIE:
• Se requieren ifcElements que ser escrito de acuerdo a los objetos ifcElementType
4.2.7.6.9 limitaciones espaciales de contención
El uso de la geometría es limitada dentro de Cobie para reflejar el requisito de que ubique activos administrados específicos dentro de los espacios. Como resultado de
ello se requiere la siguiente contención espacial en COBIE:
• Se requieren ifcElements que se encuentra dentro de los objetos uno ifcSpace
4.2.7.6.10 propiedades establece para las restricciones de ocurrencias
Los siguientes conjuntos de propiedades se utilizarán para todos los conjuntos de propiedades de ocurrencias:
Tabla 49 conjuntos de propiedades para las restricciones de Ocurrencias
Entidad Nombre
IfcElement Pset_ManufacturerOccurrence
IfcTask COBie_Task
IfcActionRequest Pset_ActionRequest
COBie_ActionRequest
IfcConstructionProductResource COBie_ConstructionProductResource
Conjuntos para 4.2.7.6.11Property restricciones de tipo
Los siguientes conjuntos de propiedades se utilizan para todos los tipos de conjuntos de propiedades:
Tabla 50 propiedad establece para este tipo de restricciones
Entidad Nombre
IfcElementType COBie_ElementType
Pset_ManufacturerTypeInformation
IfcConstructionProductResourceType COBie_ConstructionProductResourceType
4.2.7.6.12 Restricciones Asignación de Control
Se requiere la siguiente asignación de control en COBIE:
• ifcActionRequest objetos deben ser asignados a los objetos ifcElement

4.2.7.7 Concepto del lazo Descripción
Los conceptos pueden heredar de otros conceptos tales que las reglas más generales se pueden definir en un nivel superior y normas más
específicas a un nivel inferior. Por ejemplo, la geometría se puede definir para un segmento de distribución (por ejemplo, conductos,
tuberías, cables) que indican uso permitido de un área extruido sólido (IfcExtrudedAreaSolid) que define una sección transversal 2D
extruido a lo largo de un segmento lineal 3D. Tal regla puede ser adicionalmente refinado para conductos para indicar que las secciones
transversales están restringidos además a formas tales como rectángulos huecos (IfcRectangleHollowProfileDef) o círculos huecos
(IfcCircleHollowProfileDef).
• Proyecto • Restricción
• Declaración proyecto • Restricciones de datos externas
• Unidades de proyectos • Asignación
• Unidades de conversión • Asignación de Control
• raíces • Asignación grupal
• Identidad • Composición
• Control de revisión • Agregación
• Definición • Composición espacial
• Typing objeto • conectividad
• Los conjuntos de propiedades • Estructura espacial
• Los conjuntos de propiedades para Ocurrencias • La contención espacial
• Los conjuntos de propiedades para los tipos • Conectividad secuencial
• Conjuntos cantidad • Actor
• Las cantidades de Ocurrencias • Contacto
• Asociación • Proceso
• Clasificación • programación de tareas
• clasificación esperada
4.2.7.8 requisitos de aplicabilidad del concepto
La lista permite a los desarrolladores de software a entender con mayor claridad los conceptos de modelo que se requieren para
ba aplicado, por una entidad determinada, en cada etapa del proceso de entrega COBIE. En estas mesas de la letra “R” indica
que se requiere el concepto para un cambio dado. La letra “O” significa que se requiere el concepto si (1) la información es
requerida por contrato o (2) la información está presente en el modelo de datos COBIE.

revisión
revisión
Espacial
externas
externas
Concepto
Concepto
Identidad
Identidad
Control de
Control de
Ocurrencias
Ocurrencias
Composición
Composición
Las cantidades de
Las cantidades de
Restricciones de datos
Programa espacial Criterios de Programa espacial Criterios de
instalaciones disciplina especificaciones instalaciones disciplina especificaciones
del proyecto Definición del producto del proyecto Definición del producto
Diseño del Programa Diseño principios Diseño del Programa Diseño principios
del diseño esquemático Coordinado del diseño esquemático Coordinado
Edición ProductType del producto Edición ProductType del producto

Tabla 51 IfcSpace - Concepto Aplicabilidad
ooooooooooooooooooooo OOOOOOO
Plantilla de la subasta Edición ooooooooooooooooooooo OOOOOOO Plantilla de la subasta Edición
Clasificación OOOORRRRRRRRRRRRRRRRR RRRRRRR espacial
OORRRRRRRRRRRRRRRRRRR RRRRRRR
OOORRRRRRRRRRRRRRRRRR RRRRRRR
OOOORRRRRRRRRRRRRRRRR RRRRRRR
OOOORRRRRRRRRRRRRRRRR RRRRRRR
OOOOORRRRRRRRRRRRRRRR RRRRRRR
Tabla 52 IfcBuildingStory - Concepto Aplicabilidad

disposición del sistema disposición del sistema
ProductTypeSelection de instalación del ProductTypeSelection de instalación del

producto de inspección de productos de producto de inspección de productos de
construcción Tipo de producto Sistema construcción Tipo de producto Sistema
de piezas ProductTypeWarranty de piezas ProductTypeWarranty
ProductTypeMaintenance Emisión ProductTypeMaintenance Emisión
Condición de la operación espacial Condición de la operación espacial
ProductPartsReplacement espacio de ProductPartsReplacement espacio de
ocupación SpaceActivityRenovation ocupación SpaceActivityRenovation

remodelación Expandir Demolish remodelación Expandir Demolish
revisión
revisión
revisión
Espacial
proyecto
externas
Concepto
Concepto
Concepto
Identidad
Identidad
Identidad
conversión
Control de
Control de
Control de
Unidades de
Declaración
Composición
Composición
Emisión Criterios de instalaciones Programa espacial Criterios de Programa espacial Criterios de
disciplina Especificaciones Definición instalaciones disciplina especificaciones instalaciones disciplina especificaciones
del Proyecto Programa espacial del proyecto Definición del producto del proyecto Definición del producto
Producto Diseño Programa de Diseño del Programa Diseño principios Diseño del Programa Diseño principios
Diseño diseño esquemático del diseño esquemático Coordinado del diseño esquemático Coordinado
Tabla 54 IfcSite - Concepto Aplicabilidad

Clasificación ooooooooooooooooooooo OOOOOOO espacial
principios del Coordinado Edición Edición ProductType del producto Edición ProductType del producto
Tabla 55 IfcProject - Concepto Aplicabilidad

Tabla 53 IfcBuilding - Concepto Aplicabilidad
ProductType del producto Plantilla Plantilla de la subasta Edición Plantilla de la subasta Edición
RRRRRRRRRRRRRRRRRRRRR RRRRRRR
de la subasta disposición del sistema disposición del sistema

Condición de operaciones espaciales ProductTypeMaintenance Emisión ProductTypeMaintenance Emisión
disposición del sistema Condición de la operación espacial Condición de la operación espacial
ProductTypeSelection de instalación ProductPartsReplacement espacio de ProductPartsReplacemen espacio de
del producto de Emisión de ocupación SpaceActivityRenovation ocupación SpaceActivityRenovation

construcción Inspección Tipo de remodelación Expandir Demolish remodelación Expandir Demolish
producto piezas del sistema
ProductTypeMaintenance
ProductTypeWarranty
ProductPartsReplacement espacio de
ocupación SpaceActivityRenovation
remodelación Expandir Demolish

Grupo
revisión
revisión
externas
externas
Concepto
Concepto
Identidad
Identidad
Control de
Control de
Asignación
Asignación
Clasificación ooooooooooooooooooooo OOOOOOO

Clasificación ooooooooooooooooooooo Grupo OOOOOOO

Tabla 56 IfcZone - Concepto Aplicabilidad
Tabla 57 IfcSystem - Concepto Aplicabilidad

Plantilla de la subasta Edición Plantilla de la subasta Edición


revisión
revisión
externas
externas
Espacial
Concepto
Concepto
Identidad
Identidad
Control de
Control de
Contención
ocurrencias
Clasificación
Clasificación
Los conjuntos de
Los conjuntos de
propiedades para
Typing objeto
propiedades para los tipos


Tabla 58 IfcElement - Concepto Aplicabilidad
Tabla 59 IfcElementType - Concepto Aplicabilidad

ooooooooooooooooooooo OOO
OOOOORRRRRRRRRRRRRRRR RRR
OOOOORRRRRRRRRRRRRRRR RRR

para
Tarea
revisión
revisión
externas
externas
Concepto
Concepto
Contacto
Identidad
Identidad
Control de
Control de
secuencial
ocurrencias
Clasificación
Conectividad
programación
Clasificación RRRRRRRRRRRRRRRRRRRRR RRRRRRR

Tabla 60 IfcTask - Concepto Aplicabilidad
Tabla 61 IfcActor - Concepto Aplicabilidad

ooooooooooooooooo
ooooooooooooooooo
ooooooooooooooooo
ooooooooooooooooo
ooooooooooooooooo

RRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRR

para
Control
revisión
revisión
revisión
externas
externas
externas
Concepto
Concepto
Concepto
Identidad
Identidad
Identidad
Control de
Control de
Control de
ocurrencias
Asignación de
Criterios de instalaciones Programa espacial Criterios de Programa espacial Criterios de
Especificaciones de disciplina instalaciones disciplina especificaciones instalaciones disciplina especificaciones
Definición del Proyecto Programa del proyecto Definición del producto del proyecto Definición del producto
espacial Producto Diseño Programa Diseño del Programa Diseño principios Diseño del Programa Diseño principios
Clasificación ooooooooooooooooooooo OOOOOOO

principios del diseño esquemático del diseño esquemático Coordinado del diseño esquemático Coordinado
Coordinado problema de diseño Edición ProductType del producto Edición ProductType del producto
OOOO
OOOO
OOOO
Tabla 64 IfcAnnotation - Concepto Aplicabilidad

Tabla 63 IfcPropertySet - Concepto Aplicabilidad
Tabla 62 IfcActionRequest - Concepto Aplicabilidad
R
R
O
O
O

Problema Plantilla ProductType producto de inspección de productos de producto de inspección de productos de
Producto Plantilla de la subasta construcción Tipo de producto Sistema construcción Tipo de producto Sistema
R
R
O
O
O
Operación disposición del sistema ProductTypeMaintenance Emisión ProductTypeMaintenance Emisión
ProductTypeSelection de instalación Condición de la operación espacial Condición de la operación espacial
del producto de Emisión de ProductPartsReplacement espacio de ProductPartsReplacement espacio de

RR
RR
OO
OO
OO
construcción Inspección Tipo de ocupación SpaceActivityRenovation ocupación SpaceActivityRenovation

producto piezas del sistema remodelación Expandir Demolish remodelación Expandir Demolish
ProductTypeWarranty Condición
Espacial

revisión
revisión
externas
externas
Concepto
Concepto
identidad
Identidad
Identidad
Control de
Control de
Emisión Criterios de instalaciones Programa espacial Criterios de Programa espacial Criterios de
disciplina Especificaciones Definición instalaciones disciplina especificaciones instalaciones disciplina especificaciones
del Proyecto Programa espacial del proyecto Definición del producto del proyecto Definición del producto
Producto Diseño Programa de Diseño del Programa Diseño principios Diseño del Programa Diseño principios
Diseño diseño esquemático del diseño esquemático Coordinado del diseño esquemático Coordinado
principios del Coordinado Edición Edición ProductType del producto Edición ProductType del producto
ProductType del producto Plantilla Plantilla de la subasta Edición Plantilla de la subasta Edición
de la subasta disposición del sistema disposición del sistema
Tabla 66 IfcWorkSchedule - Concepto Aplicabilidad

Tabla 65 IfcRelConnectsPorts - Concepto de aplicabilidad

Tabla 67 IfcRelAssociatesDocument - Concepto Aplicabilidad

Las restricciones de control de revisiones ooooooooooooooooooooo OOOOOOO datos externos


O
O
O
ProductTypeSelection de instalación ProductPartsReplacement espacio de ProductPartsReplacement espacio de

O
O
O
ProductTypeWarranty

Setsfor
revisión
revisión
revisión
Setsfor
Tipos de
Externo
Externo
Externo
propiedad
identidad
identidad
identidad
Control de
Control de
Control de
Propiedad
restricciones
restricciones
restricciones
Ocurrencias
Datos
Datos
Datos
Criterios de instalaciones disciplina Programa espacial Criterios de Programa espacial Criterios de
Especificaciones Definición del instalaciones disciplina especificaciones instalaciones disciplina especificaciones
Proyecto Programa espacial Producto del proyecto Definición del producto del proyecto Definición del producto
Diseño Programa principios del Diseño del Programa Diseño principios Diseño del Programa Diseño principios
diseño esquemático Coordinado del diseño esquemático Coordinado del diseño esquemático Coordinado
problema de diseño Edición ProductType del producto Edición ProductType del producto
O
O
O

Problema Plantilla ProductType producto de inspección de productos de producto de inspección de productos de
Producto Plantilla de la subasta construcción Tipo de producto Sistema Tabla 69 ifcConstructionProductResource - Concepto Aplicabilidad construcción Tipo de producto Sistema
Tabla 70 ifcConstructionProductResourceType - Concepto Aplicabilidad

Tabla 68 IfcRelConnectsWithRealizingElements - Concepto de aplicabilidad

O
O
O
ProductTypeSelection de instalación ProductPartsReplacement espacio de ProductPartsReplacement espacio de

R
R
R
O
ProductTypeWarranty
OOOOOOOOO
OOOOOOOOO
OOOOOOOOO
OOOOOOOOO

4.2.7.9 lista relacionados con el concepto existente
La siguiente tabla demuestra la reutilización de los conceptos COBIE MVD en las normas NBIMS-estadounidense ™ V3 relacionados, y otra
buildingSMART Alliance® proyectos. En la tabla, cada fila corresponde a un concepto utilizado
dentro de esta vista de modelo, cada columna corresponde a otra vista del modelo, y cada célula indica el uso del concepto dentro de la vista de
modelo correspondiente.
Análisis reutilización Tabla 71 de necesidad de cambio
Intercambiar Cobie BPie BAMie HVACie Sparkie WSIE
Identidad X X X X X
Control de revisión X X X X
Restricciones de datos externas X X
Clasificación X X X X X
Composición espacial X X
QuantitiesonOccurrences X
Unidades de conversión X X X X
Declaración proyecto X X X X X
Asignación grupal X X X X
Typing objeto X X X X X X
La contención espacial X X X X
PropertySetsforOccurrences X X X X X
Los conjuntos de propiedades para los tipos X X X X X
programación de tareas X X
Conectividad secuencial X
Contacto X
Asignación de Control X X X X X
Lista de reglas de negocio 4.2.7.10 Cconcept

Las siguientes tablas identifican la aplicación de cada concepto de reglas de negocio a la entidad o parámetros específicos de IFC a la que se
aplica la regla. Los valores para los parámetros aplicables son o bien “As-definido” lo que significa que las reglas contenidas en el modelo IFC
subyacente se aplican o como se indica en la tabla.
Tabla Lista Regla 72 Identidad concepto de negocio
Referencia Parámetro
\ IfcRoot.GlobalId Como se especificó
\ IfcRoot.GlobalId \ IfcGloballyUniqueId Como se especificó
\ IfcRoot.Name Como se especificó
\ IfcRoot.Name \ IfcLabel Como se especificó
\ IfcRoot.Description Como se especificó
\ IfcRoot.Description \ IfcText Como se especificó

Tabla Lista Regla 73 Revisión conceptual de control de negocios
\ IfcRoot.OwnerHistory Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningUser Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningUser \ IfcPersonAndOrganization Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningUser \ IfcPersonAndOrganization.ThePerson Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningUser \ IfcPersonAndOrganization.ThePerson \ IfcPerson Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningUser \ IfcPersonAndOrganization.TheOrganization Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningUser \ IfcPersonAndOrganization.TheOrganization \ IfcOrganization Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningApplication Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningApplication \ IfcApplication Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningApplication \ IfcApplication.ApplicationDeveloper Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.OwningApplication \ IfcApplication.ApplicationDeveloper \ IfcOrganization Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.State Como se especificó
Tabla 74 Revisión del concepto de control para empresas Lista de reglas (cont.)
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.State \ IfcStateEnum Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.ChangeAction Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.ChangeAction \ IfcChangeActionEnum Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.CreationDate Como se especificó
\ IfcRoot.OwnerHistory \ IfcOwnerHistory.CreationDate \ IfcTimeStamp Como se especificó
Tabla 75 Restricciones de datos externas Lista de reglas de negocios Concepto
\ IfcObjectDefinition.HasAssociations Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint Como se especificó

\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues Como especificado
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMetric Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMetric.DataValue Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMetric.DataValue \ IfcTable Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMetric.DataValue \ IfcTable.Name Mesa
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMetric.DataValue \ IfcTable.Name \ Como se especificó
IfcLabel
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMetric.DataValue \ IfcTable.Columns Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMetric.DataValue \ IfcTable.Columns \ Como se especificó
IfcTableColumn
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMetric.DataValue \ IfcTable.Columns \ Nombre
IfcTableColumn.Name
Tabla 76 Restricciones de datos externas concepto de negocio lista de reglas (cont.)
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMet ric.DataValue \ IfcTable.Columns \ Como se especificó
IfcTableColumn.Name \ IfcLabel
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMet ric.DataValue \ IfcTable.Columns \ Referencia
IfcTableColumn.ReferencePath
IfcTableColumn.ReferencePath \ IfcReference
IfcTableColumn.Unit
IfcTableColumn.Unit \ IfcContextDependentUnit

\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMet ric.DataValue \ IfcTable.Columns \ Formato
IfcTableColumn.Unit \ IfcContextDependentUnit.Name
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.BenchmarkValues \ IfcMet ric.DataValue \ IfcTable.Columns \ Color
IfcTableColumn.Description
IfcTableColumn.Description \ IfcText
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.ObjectiveQualifier Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.ObjectiveQualifier \ IfcObj ectiveEnum Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.RelatingConstraint \ IfcObjective.ObjectiveQualifier \ IfcObj ectiveEnum.Value = EXTERNO Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.Name Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesConstraint.Name \ IfcLabel Como se especificó
Tabla 77 Clasificación Lista de reglas de negocios Concepto
\ IfcObjectDefinition.HasAssociations Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Ident ification Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Ident ification \ IfcIdentifier Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Refe rencedSource Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Refe rencedSource \ IfcClassification Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Refe rencedSource \ IfcClassification.Source Fuente
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Refe rencedSource \ IfcClassification.Source \ Como se especificó
IfcLabel

\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Refe rencedSource \ IfcClassification.Name Nombre
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Refe rencedSource \ IfcClassification.Name \ IfcLabel Como se especificó
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Refe rencedSource \ fichas
IfcClassification.ReferenceTokens
\ IfcObjectDefinition.HasAssociations \ IfcRelAssociatesClassification.RelatingClassification \ IfcClassificationReference.Refe rencedSource \ Como se especificó
IfcClassification.ReferenceTokens \ IfcIdentifier
Tabla 78 Composición espacial Concepto Lista de reglas de negocios
\ IfcSpatialElement.Decomposes Como se especificó
\ IfcSpatialElement.Decomposes \ IfcRelAggregates Como se especificó
\ IfcSpatialElement.Decomposes \ IfcRelAggregates.RelatingObject Compuesto
espacial
\ IfcSpatialElement.Decomposes \ IfcRelAggregates.RelatingObject \ IfcSpatialElement Como se especificó
Tabla 74 Cantidades en Ocurrencias concepto de negocio Lista de reglas
\ IfcObject.IsDefinedBy Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcElementQuantity Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcElementQuantity.Name Qset
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcElementQuantity.Name \ IfcLabel Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcElementQuantity.Quantities Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcElementQuantity.Quantities \ IfcPhysicalSi mpleQuantity Tipo
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcElementQuantity.Quantities \ IfcPhysicalSi mpleQuantity.Name Cantidad
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcElementQuantity.Quantities \ IfcPhysicalSi mpleQuantity.Name \ IfcLabel Como se especificó

Tabla 75 Lista de reglas de conversión de unidades concepto de negocio
\ IfcContext.UnitsInContext Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.UnitType Tipo de unidad
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.UnitType \ IfcUnitEnum Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.Name Nombre
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.Name \ IfcLabel Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unidad Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unit.ValueComponent conversionType
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unit.ValueComponent \ IfcReal Factor de conversión
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unit.UnitComponent Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unit.UnitComponent \ IfcSIUnit Como se especificó
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unit.UnitComponent \ IfcSIUnit.Prefix BaseUnitPrefix
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unit.UnitComponent \ IfcSIUnit.Prefix \ Como se especificó
IfcSIPrefix
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unit.UnitComponent \ IfcSIUnit.Name BaseUnitName
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionFactor \ IfcMeasureWith Unit.UnitComponent \ IfcSIUnit.Name \ Como se especificó
IfcSIUnitName
\ IfcContext.UnitsInContext \ IfcUnitAssignment.Units \ IfcConversionBasedUnitWithOffset.ConversionOffset ConversionOffset

Tabla 81 Lista de Proyectos Regla Declaración concepto de negocio
\ IfcContext.Declares Como se especificó
\ IfcContext.Declares \ IfcRelDeclares Como se especificó
\ IfcContext.Declares \ IfcRelDeclares.RelatedDefinitions Tipo
\ IfcContext.Declares \ IfcRelDeclares.RelatedDefinitions \ IfcObjectDefinition Como se especificó
Tabla 762 Asignación de grupo Lista de reglas de negocios Concepto
\ IfcGroup.IsGroupedBy Como se especificó
\ IfcGroup.IsGroupedBy \ IfcRelAssignsToGroup Como se especificó
\ IfcGroup.IsGroupedBy \ IfcRelAssignsToGroup.RelatedObjects Tipo
\ IfcGroup.IsGroupedBy \ IfcRelAssignsToGroup.RelatedObjects \ IfcProduct Como se especificó
Tabla 77 Objeto Lista de reglas Typing concepto de negocio
\ IfcObject.IsTypedBy Como se especificó
\ IfcObject.IsTypedBy \ IfcRelDefinesByType Como se especificó
\ IfcObject.IsTypedBy \ IfcRelDefinesByType.RelatingType Tipo
\ IfcObject.IsTypedBy \ IfcRelDefinesByType.RelatingType \ IfcTypeObject Como se especificó
Tabla Lista Regla 784 del espacio de contención concepto de negocio
\ IfcElement.ContainedInStructure Como se especificó
\ IfcElement.ContainedInStructure \ IfcRelContainedInSpatialStructure Como se especificó
\ IfcElement.ContainedInStructure \ IfcRelContainedInSpatialStructure.RelatingStructure Estructura
\ IfcElement.ContainedInStructure \ IfcRelContainedInSpatialStructure.RelatingStructure \ IfcSpatialStructureElement Como especificado

Tabla 85 complejos de propiedad de Ocurrencias concepto de negocio Lista de reglas
\ IfcObject.PredefinedType PredefinedType
\ IfcObject.IsDefinedBy Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcPropertySet Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcPropertySet.Name Nombre
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcPropertySet.HasProperties Como se especificó
\ IfcObject.IsDefinedBy \ IfcRelDefinesByProperties.RelatingPropertyDefinition \ IfcPropertySet.HasProperties \ IfcProperty Como especificado
Tabla 86 conjuntos de propiedades para los tipos de concepto de negocio Lista de reglas
\ IfcTypeObject.HasPropertySets Como se especificó
\ IfcTypeObject.HasPropertySets \ IfcPropertySet Como se especificó
\ IfcTypeObject.HasPropertySets \ IfcPropertySet.Name Nombre
\ IfcTypeObject.HasPropertySets \ IfcPropertySet.Name \ IfcLabel Como se especificó
\ IfcTypeObject.HasPropertySets \ IfcPropertySet.HasProperties Como se especificó
\ IfcTypeObject.HasPropertySets \ IfcPropertySet.HasProperties \ IfcProperty Como se especificó

Tabla Lista Regla 797 Programación de tareas concepto de negocio
\ IfcTask.TaskTime Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.ScheduleStart Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.ScheduleStart \ IfcDateTime Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.ScheduleFinish Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.ScheduleFinish \ IfcDateTime Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.ScheduleDuration Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.ScheduleDuration Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.ScheduleDuration \ IfcDuration Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.RecurrenceType Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.RecurrenceType \ Enum IfcRecurrenceType Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.DayComponent Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.DayComponent \ er IfcDayInMonthNumb Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.WeekdayComponent Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.WeekdayComponent \ IfcDayInWeekN ocre Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.MonthComponent Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.MonthComponent \ IfcMonthInYearNu mber Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.Position Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.Position \ IfcInteger Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.Interval Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.Interval \ IfcInteger Como se especificó

Tabla 88 Programación de tareas Concepto Lista de reglas de negocio (cont.)
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.Occurrences Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.Occurrences \ IfcInteger Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.TimePeriods Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.TimePeriods \ IfcTimePeriod Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.TimePeriods \ IfcTimePeriod.StartTime Como especificado
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.TimePeriods \ IfcTimePeriod.StartTime \ IfcTime Como se especificó
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.TimePeriods \ IfcTimePeriod.EndTime Como especificado
\ IfcTask.TaskTime \ IfcTaskTimeRecurring.Recurrance \ IfcRecurrencePattern.TimePeriods \ IfcTimePeriod.EndTime \ I fcTime Como se especificó
Tabla Lista Regla 89 secuencial de conectividad concepto de negocio
\ IfcProcess.IsPredecessorTo Como se especificó
\ IfcProcess.IsPredecessorTo \ IfcRelSequence Como se especificó
\ IfcProcess.IsPredecessorTo \ IfcRelSequence.RelatedProcess Como se especificó
\ IfcProcess.IsPredecessorTo \ IfcRelSequence.RelatedProcess \ IfcProcess Como se especificó
\ IfcProcess.IsSuccessorFrom Como se especificó
\ IfcProcess.IsSuccessorFrom \ IfcRelSequence Como se especificó
\ IfcProcess.IsSuccessorFrom \ IfcRelSequence.RelatingProcess Como se especificó
\ IfcProcess.IsSuccessorFrom \ IfcRelSequence.RelatingProcess \ IfcProcess Como se especificó

Tabla Lista Regla 90 Contacto Concepto de negocio
\ IfcActor.TheActor Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.AddressLines Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.AddressLines \ Ifc etiqueta Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.PostalBox Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.PostalBox \ IfcLab EL Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.Town Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.Town \ IfcLabel Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.Region Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.Region \ IfcLabel Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.PostalCode Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.PostalCode \ iFCL Abel Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.Country Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcPostalAddress.Country \ IfcLabel Como especificado

Tabla 91 Contacto Concepto de negocio Lista de reglas (cont.)
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcTelecomAddress Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcTelecomAddress.TelephoneNu mbers Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.ThePerson \ IfcPerson.Addresses \ IfcTelecomAddress.TelephoneNu mbers \ IfcLabel Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.TheOrganization Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.TheOrganization \ IfcOrganization Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.TheOrganization \ IfcOrganization.Name Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.TheOrganization \ IfcOrganization.Name \ IfcLabel Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.TheOrganization \ IfcOrganization.Description Como se especificó
\ IfcActor.TheActor \ IfcPersonAndOrganization.TheOrganization \ IfcOrganization.Description \ IfcText Como se especificó
Tabla 80 Asignación de Control Lista de reglas de negocios Concepto
\ IfcControl.Controls Como se especificó
\ IfcControl.Controls \ IfcRelAssignsToControl Como se especificó
\ IfcControl.Controls \ IfcRelAssignsToControl.RelatedObjects Tipo
\ IfcControl.Controls \ IfcRelAssignsToControl.RelatedObjects \ IfcObject Como se especificó
4.2.7.11 Concepto Definición de reglas de negocios
Regla 4.2.7.11.1 Identidad concepto de negocio
Un objeto tiene que ser identificable para un procesamiento preciso por ambos procesos humanos y automatizados. La identificación puede ser a través de varios
atributos, tales como la identificación, nombre o GUID. El GUID se comprime con el fin de ser intercambiada dentro de un conjunto de datos IFC - el GUID comprimido
es referido como "IFC-GUID". Mientras que la CFI-GUID normalmente se genera automáticamente y tiene que ser persistente, la identificación puede relacionarse con
los demás registros informales, pero debe ser único en el conjunto de objetos del mismo tipo. El nombre y la descripción deben permitir que cualquier objeto a ser
identificado en el contexto del proyecto o instalación que se está modelando.
Diversos objetos pueden tener identificaciones adicionales que pueden ser legible por humanos y / o puede ser estructurada a través de asociación de clasificación.
Varios formatos de archivo pueden utilizar identificaciones adicionales de casos con fines de serialización; Sin embargo no hay ningún requisito o garantía para este tipo de
identificaciones a siguen siendo los mismos entre revisiones o en todas las aplicaciones. Por ejemplo, el formato de archivo IFC-SPF enumera cada ejemplo con un número
entero de 64 bits que es único dentro del archivo en particular.

Figura 62 Concepto Identidad - Reglas de Negocio
Para obtener información específica entidades del nombre de la entidad debe ser único. Otras entidades deben identificar de forma única por una
combinación de nombre y otra información requerida. Limitaciones relacionadas con las claves compuestas no se describen en este párrafo.
Regla 4.2.7.11.2 Revisión del concepto de control para empresas
Mientras que los objetos pueden reflejar un estado final, sino que también pueden ser revisadas continuamente a lo largo de un ciclo de vida del proyecto y reflejan
estado transitorio. Para los escenarios de múltiples usuarios hacer cambios a la misma información, hay un concepto de copias locales de información basados en
un repositorio compartido soporte a múltiples usuarios. Tal repositorio compartido se refiere a menudo como un servidor de modelo. Un servidor de modelo es
similar en concepto a un servidor de la revisión de documentos, pero es capaz de identificar los cambios declarados en función de cada objeto en lugar de inferir
cambios con respecto a las diferencias en el texto. Un servidor de modelo tiene un concepto de revisiones en base a proyectos per-, donde cada revisión se
compone de un conjunto de cambios en los objetos contenidos por parte de un usuario en particular en un momento determinado.
Para apoyar un escenario de servidor de modelo, cada objeto puede ser marcada con una acción de cambio que indica se añadió el objeto, modificado,
eliminado o tiene ningún cambio desde el proyecto fue recuperado desde el servidor a una secuencia de revisión en particular. Teniendo en cuenta la
identidad de un objeto (CFI-GUID) y la acción de cambio, el estado del objeto podrá fusionarse cuando se somete a un servidor de modelo. Se considera que
un objeto modificado cuando cualquiera de sus atributos directos cambiar, los atributos en una definición recurso referenciado (cualquier entidad no se deriva
de IfcRoot) cambio, se añaden los elementos o se quitan de los conjuntos, o se añaden elementos, eliminar o reordenan dentro de las listas.
Para los casos en que varios usuarios hacen cambios conflictivos a los mismos objetos, los usuarios pueden optar por mantener sus propios cambios,
aceptar los cambios de otros, combinar ambos cambios, y una combinación de los mismos al presentar a un servidor. Por otra parte, para evitar tal
escenario de combinación y coordinar el trabajo, los objetos pueden ser bloqueado de tal manera que un usuario particular tiene acceso exclusivo para leer
y / o escribir un objeto en particular en el momento actual.

Figura 63 Concepto de Control de Revisión - Reglas de Negocio
bibliotecas de proyecto también pueden ser recuperados de los servidores de modelo que tienen en particular la revisión, y potencialmente diferente del
servidor URI que el Proyecto de referencia. Como proyecto puede incluir múltiples revisiones de la misma librería del proyecto (un escenario común cuando
varios usuarios están involucrados usando bibliotecas revisados por otros), la IfcRoot.ObjectIdentifier IFC-GUID sólo es válida dentro del alcance del proyecto
de referencia, y una biblioteca independiente referencia identifica un objeto basado biblioteca proyecto dentro de su servidor de modelo de origen.
Por último, los objetos también pueden llevar informativo atributos que indica cuándo se crea un objeto, quién, cuándo, y qué aplicación se utilizó
para durar modificar un objeto, y que posee actualmente el objeto, lo que podría tener el uso exclusivo de acuerdo a su estado de bloqueo.
4.2.7.11.3 limitaciones de los datos concepto de negocio regla externa
El modelo de restricción puede ser usado para indicar asignaciones entre los datos en el modelo de IFC y documentos externos. Esta plantilla concepto
también puede ser utilizada por aplicaciones de software para traducir los datos a / desde hojas de cálculo sin crear instancias necesariamente relaciones
de restricción dentro de un conjunto de datos IFC.
Para indicar una asignación explícita a un archivo o base de datos en particular, las clases IFC pueden correlacionarse con los formatos de datos tabulares
utilizando IfcResourceConstraintRelationship unido a IfcDocumentInformation.
asignaciones predeterminadas pueden ser indicadas usando el IfcRelAssociatesConstraint una relación con
RelatingConstraint señalando IfcObjective.
Un IfcObjective de tipo externo tiene ConstraintSource establece en el nombre de la entidad IFC (por ejemplo 'IfcSpace') con puntos de referencia
que contiene un único IfcMetric con DataValue establece en un IfcTable. En IfcTable, el nombre se establece en el nombre de la tabla de base de
datos externa o de hoja de cálculo y de atributos de las columnas indica las columnas de las tablas externas en orden como IfcTableColumn.
Para cada IfcTableColumn, del nombre indica el nombre de campo o columna de cabecera, y la ReferencePath identifica el atributo de objeto
correspondiente, para los que se indican asignaciones estándar.
Dentro de este documento, atribuir caminos (como se usa para IfcReference) se codifican utilizando la sintaxis en la forma 'IfcSpace.OwnerHistory
\ IfcOwnerHistory.CreationDate' con las siguientes convenciones:

• El carácter de punto elimina referencia a un atributo de una entidad.
• El carácter de barra invertida arroja una entidad en un subtipo, donde una barra invertida y sin un mapeo indicatings subtipo
del tipo en sí.
• Una secuencia de soporte con un asterisco ( "[*]") elimina referencia a una colección en cada miembro.
• Una secuencia de soporte con una cadena codificada (por ejemplo, "[ 'SerialNumber']" elimina referencia a una colección en un miembro específico por su
nombre.
Sobre la importación de una hoja de cálculo, tablas deberán ser identificados por su nombre de hoja de cálculo sin importar el orden, y las columnas se
identifican por el nombre de cabecera sin importar el orden. Para la exportación a una nueva hoja de cálculo, hojas de trabajo deberán estar provistos de la
identificación de nombre para cada entidad y se secuencian en el orden especificado, y dentro de cada hoja de una fila de cabecera deberán estar provistos
con cada columna tiene un nombre de identificación y secuenciado en el orden especificado.
Los atributos se asignan a las células de hoja de cálculo, en donde ya sea NULL, una cadena vacía, o el valor reservado 'n / a' indica un valor
nulo. tipos base específicos se asignan como sigue:
• CADENA: tipos de cadena se representan como cadenas.
• Real: tipos de números reales se representan como números reales.
• Las referencias de entidad Entity se representan como cadenas que identifican por su nombre (IfcRoot.Name).
• colecciones SET basado Set-se representan como cadenas que identifican cada objeto por su nombre y separados por una coma.
• asignaciones específicas se definen en las entidades correspondientes, donde se utilizan los siguientes nombres de columna estándar:
• Nombre: indica el nombre del objeto, lo que corresponde a IfcRoot.Name.
• ExtObject: Indica el tipo IFC del objeto mediante la identificación de la entidad IFC por nombre (por ejemplo, 'IfcBoiler'). Si se omite
sobre la importación, la entidad CFI será el tipo base, donde se indica el concepto (si no abstracta); de lo contrario deberá ser
importado ninguna entidad.
• ExtSystem: Indica la aplicación que actualmente posee el objeto, la cartografía de

IfcApplication.ApplicationIdentifier.
• ExtIdentifier: Indica el GUID del objeto codificado en el mismo formato descrito en IfcGloballyUniqueId, mapeo a
IfcRoot.GlobalId. Si se omite la importación, tales GUID se construye dinámicamente. Si la fusión de cambios sobre la
importación, tales identificador se utiliza para identificar un objeto existente (es decir, esto mantiene la identidad, si se cambia
el nombre de un objeto (el atributo Nombre cambiante).
Figura 64 datos externos Limitaciones del concepto - Reglas de Negocio

4.2.7.11.4 reglas de negocio concepto de Clasificación
Los objetos, los objetos de texto, propiedades y algunas entidades del esquema de recursos pueden ser descritos mediante la asociación de referencias
a las fuentes de información externas. La fuente de información puede ser:
• un sistema de clasificación;
• un servidor de diccionario;
• cualquier catálogo externo que clasifica el objeto adicional;
• un servicio que combina las características anteriores.
Un elemento individual dentro de la fuente externa de información puede ser seleccionado. A continuación, aplica el sentido propio de la cosa al
objeto o propiedad.
Figura 65 Clasificación Concepto - Reglas de Negocio
regla concepto de negocio 4.2.7.11.5 composición espacial
La estructura espacial es un árbol jerárquico de elementos espaciales estructura (sitio, construcción, historia, espacio) en última instancia
asignados al proyecto. Composición se refiere a la relación a un elemento de nivel superior (por ejemplo, este artículo es parte de un edificio). El
orden de los elementos estructura espacial está incluido en el concepto son de alto a bajo nivel: IfcProject, IfcSite, IfcBuilding, IfcBuildingStory,
IfcSpace. Por lo tanto un elemento estructura espacial sólo puede ser parte de un elemento al mismo o más alto nivel.
Figura 66 Concepto composición espacial - Reglas de Negocio

4.2.7.11.6 Las cantidades en concepto de reglas de negocio ocurrencias
Cualquier especialización de objeto puede estar relacionado con varias apariciones en cantidades determinadas. Un conjunto cantidad contiene múltiples
ocurrencias de cantidad. El tipo de datos de ocurrencia cantidad se cuenta, longitud, área, volumen, peso, tiempo, y la combinación de las ocurrencias de
cantidad.
Figura 67 Las cantidades en concepto Ocurrencias - Reglas de Negocio
4.2.7.11.7 unidades de conversión de reglas de negocio concepto
unidades de conversión se definen de acuerdo con un factor de conversión (y la conversión de desplazamiento de temperatura) con respecto a una unidad de SI base
especificada.
Figura 68 Conversión de Unidades Concepto - Reglas de Negocio
regla de negocio concepto de declaración 4.2.7.11.8 Proyecto
El proyecto proporciona un directorio de objetos contenidos en el uso de las relaciones de declaración.
Figura 69 Proyecto de Declaración Concepto - Reglas de Negocio

regla de negocio concepto de asignación 4.2.7.11.9 Grupo
Los grupos pueden tener asignaciones que indican los productos que son miembros del grupo. Un ejemplo de tal asignación es un controlador de aire
perteneciente a un sistema de aire acondicionado.
Figura 70 Concepto Asignación de Grupo - Reglas de Negocio
regla de negocio concepto de escribir 4.2.7.11.10 Objeto
Ocurrencias de objetos pueden ser definidos por un tipo de objeto particular, cuando tal tipo se describen características comunes. Tales
características incluyen propiedades comunes, formas, materiales, composición, y otros conceptos descritos en entidades particulares. Una
ocurrencia objeto puede tener estado similar como su tipo de objeto, el estado se reemplaza por características particulares, o no tienen ningún
objeto de tipo definido.
Un par de entidades se definen por varias ocurrencias de objeto y los tipos de objetos, en los que tal entidad objeto ocurrencia solamente puede
definirse usando una entidad de tipo de objeto particular. Por ejemplo, la entidad objeto ocurrencia IfcTank tiene una entidad objeto de tipo
IfcTankType correspondiente.
Muchas entidades ocurrencia objeto y de tipo de objeto tienen un atributo llamado PredefinedType que consiste en una enumeración específica. Tal
tipo predefinido esencialmente proporciona otro nivel de herencia para diferenciar aún más objetos sin la necesidad de entidades adicionales. tipos
predefinidos no son sólo informativos; diversas reglas se aplican tales como conjuntos de propiedades aplicable, la composición parte, y los puertos
de distribución.
Para los escenarios de tipos de objetos que tienen composiciones parciales, tales partes pueden ser reflejados en las apariciones de objetos que tienen estado
separado. Por ejemplo, un tipo de pared puede definir una disposición particular de los pernos prisioneros, una ocurrencia de pared puede reflejar la misma
disposición de los tacos, y los pernos prisioneros dentro de la ocurrencia de pared puede participar en relaciones específicas que no existen en el tipo tales
como ser conectado a un eléctrica caja de conexiones.

Figura 71 Objeto Typing Concepto - Reglas de Negocio
regla concepto de negocio 4.2.7.11.11 contención espacial
estruc espacial t Ures pueden contener elementos físicos, incluyendo elementos de construcción, elementos de distribución, y los elementos de decoración.
Figura Regla 72 del espacio de contención Concepto-Negocio

4.2.7.11.12
conjuntos de propiedades de reglas de negocio ocurrencias concepto
Cualquier especialización de objeto puede estar relacionado con múltiples ocurrencias de conjuntos de propiedades. Un conjunto de propiedades contiene múltiples
ocurrencias de propiedad. Los tipos de datos de ocurrencias de propiedad son solo valor, el valor enumerado, el valor delimitada, valor de la tabla, el valor de referencia,
el valor de la lista, y la combinación de las ocurrencias de propiedad.
Figura 73 conjuntos de propiedades de la regla Ocurrencias Concepto-Negocio
4.2.7.11.13 propiedades establece para este tipo de reglas de negocio concepto
Para los tipos de objetos, conjuntos de propiedades se definen directamente.
Figura 74 complejos de propiedad sobre el estándar de Tipos - Reglas de Negocio

regla de negocio concepto de programación de tareas 4.2.7.11.14
Las tareas pueden ser programados para funcionar de forma continua, en un solo periodo de tiempo, o múltiples periodos recurrentes en el tiempo.
Figura 75 Programación de tareas Concepto - Reglas de Negocio
regla concepto de negocio 4.2.7.11.15 conectividad secuencial
Procesos que ocurren en el tiempo utilizan esta relación para indicar el orden de aparición, como por tareas, procedimientos y eventos.
Figura 76 Concepto secuencial de conectividad - Reglas de Negocio

Regla 4.2.7.11.16 Contacto Concepto de negocio
Los participantes del proyecto se indica mediante IfcActor. El nombre debe indicar un identificador único legible por humanos del actor, como su dirección
de correo electrónico, que permite la asociación automática de la información de creación basada sobre las credenciales de inicio de sesión.
Figura 77 Concepto Contacto - Reglas de Negocio
regla de negocio concepto de asignación de control 4.2.7.11.17
Los controles pueden tener asignaciones que indican los objetos que deben observar los requisitos establecidos. Un ejemplo de dicha cesión es un recurso de
trabajo asignado a un calendario.
Figura 78 Concepto de Control Asignación - Reglas de Negocio
4.2.7.12 MVD lista de esquema
El esquema de encapsulación de las definiciones de datos para esta vista modelo se publica en múltiples representaciones como se muestra en la siguiente lista:
• COBie.exp - definición de esquema EXPRESS
• COBie.xsd - definición de esquema XML (XSD)

• COBie.mvdxml - esquema MVDXML transformar
• COBie.ifc - IFC definición de esquema dinámico
Un archivo MVDXML define las entidades y las normas referenciadas para esta vista del modelo. Este archivo se puede utilizar para validar datos de
instancia (en IFC-SPF o archivos IFC-XML), filtrar datos de instancia para incluir entidades y atributos dentro de alcance de esta vista del modelo, o
generar sub-esquemas (incluyendo las representaciones EXP y XSD).
Un archivo CAD representa el esquema en formato EXPRESS (ISO 10303-11) que adapta la Fundación de la Industria clases de esquema de referencia (ISO 16739)
mediante la inclusión de un subconjunto de las definiciones de datos y un subconjunto de atributos dentro de cada definición de datos. El archivo CAD puede ser utilizada
por las herramientas de desarrollo de software para la generación de lenguajes de programación esquemas (por ejemplo, C ++, C #, Java) las definiciones, las
definiciones de base de datos (por ejemplo, SQL DDL), y el transporte de datos de esquema (por ejemplo XSD).
Un archivo XSD representa el esquema en lenguaje XML de definición de datos (XSD) que adapta el subconjunto de referencia de las definiciones de datos. El
archivo XSD puede ser utilizada por las herramientas de desarrollo de software (por ejemplo, Eclipse, Microsoft Visual Studio) para validar los archivos XML y
generar clases específicas del idioma.
Un archivo IFC representa las porciones dinámicas del esquema en forma de conjuntos de propiedades dentro de un SPF archivo de instancia (10303-21 ISO).
El fundamento para la publicación de múltiples representaciones es proporcionar el nivel más rico de integración para diferentes implementaciones; mientras XSD se
utiliza a menudo en la definición de los estándares web sustitución de intercambios basados en documentos (por ejemplo, facturas), que carece de la información del
modelo de datos necesaria para la seguridad de tipos, integridad de datos, indexación y optimización; todos los cuales pueden derivarse de la representación
EXPRESS.
4.2.7.13 MVD descripción de formato
Cada formato compatible aparece por su nombre, con la extensión que indica la extensión de archivo por defecto a utilizar en plataformas aplicables (por
ejemplo, Windows), tipo MIME para indicar la cabecera HTTP cuando se transmiten a través de Internet, y el estándar de referencia que indica el formato
de codificación de la capa de presentación. Esta norma contiene toda la información necesaria para la transformación entre estos formatos. Estas
transformaciones se han demostrado para mantener plenamente toda la información que se encuentra dentro del alcance de esta MVD
Tabla 81 admisibles COBIE MVD Formatos
Formato MIME extensión Referencia
SpreadsheetML .xml application / xmlspreadsheet Microsoft Office 2003
COBieLite . xml application / xml Departamento de Seguridad Nacional de EE.UU.
IFC-SPF . IFC application / paso ISO 10303-21
CFI en XML . ifcxml application / xml ISO 10303-28
SpreadsheetML es un formato XML que presenta datos COBIE en un formato fácil de entender y digerir formato para los miembros de la comunidad
de usuarios COBIE que no son programadores informáticos.
COBieLite es un Estados Unidos Nacional de Intercambio de Información Modelo (NIEM) esquema que cumpla en XML. Se espera que el uso de este
formato de intercambio de sistema a sistema de datos COBIE en dominios distintos de diseño arquitectónico y de ingeniería. Esto se debe a que los
intercambios que necesita el software de diseño no-arquitectónico y de ingeniería no es necesario llevar el tamaño de los gastos generales y archivo
asociado con el paso (o) ifcXML formatos de datos.

IFC-SPF (ISO 10303-21) es un formato de texto optimizado para transportar datos con relaciones complejas, el apoyo a la legibilidad humana sin embargo, la
representación más compacta (por lo general alrededor del 10% del tamaño de XML equivalente).
IFC-HDF (ISO 10303-26) es un formato de archivo binario que encapsula datos en una codificación compacta, indexable optimizado para la recuperación
rápida y el uso de memoria mínima. NOTA Como este tipo de archivo no se ha implementado ampliamente, no es oficialmente parte de este modelo de
vista, sin embargo, las implementaciones pueden preferir tal formato para uso interno.
CFI en XML (ISO 10303-28) es un formato de marcado jerárquica con un amplio apoyo de herramientas y plataformas de desarrollo de software, el apoyo a
una mayor legibilidad humana a expensas de una mayor representación. NOTA Como los edificios típicos contienen millones de elementos con gráficos de
las relaciones resultantes de gigabytes de datos, XML aún no es adecuado para la representación de edificios completos desde un punto de vista pragmático
del tamaño de los datos, el costo de transmisión, y el tiempo de carga. Sin embargo, el uso de formatos derivados, junto con MVDXML para filtrar los
conjuntos de datos puede permitir intercambios más eficientes a tener lugar.
IFC-ZIP (ISO 21320-1) es un formato de archivo comprimido encapsular uno de los formatos anteriores para minimizar el tamaño de datos. NOTA Como esta
vista de modelo está destinado principalmente para el intercambio basado en la web, la compresión ZIP puede ser seleccionado por otros medios según el
cliente y el servidor; Por lo tanto, el formato IFC-ZIP no es oficialmente parte de esta vista del modelo.
4.2.7.14 MVD análisis esquema dinámico
Las porciones de las definiciones de datos se definen de forma dinámica, para permitir que las aplicaciones de software para apoyar las definiciones extensibles al tiempo
que minimiza overhead aplicación. Cada conjunto de propiedades se muestra dentro de una subsección de la siguiente manera, con filas correspondiente a las
propiedades. Ver IfcPropertySet de información de uso.
Tabla 82 COBie_Task dinámico de definición de esquemas
Propiedad tipo de propiedad Tipo de datos
Categoría P_ENUMERATEDV ALOR / PEnum_TaskCategory: Ajuste, Calibración, emergencia, inspección, gestión, PM, S eguridad, apagado, inicio de pruebas,
Problema
Estado P_ENUMERATEDV ALOR / PEnum_TaskStatus: notyet empezar, empezar, Completado

Tabla 83 COBie_ElementType dinámico de definición de esquemas
Propiedad tipo de propiedad Tipo de datos Descripción
Tipo de activo P_ENUMERATEDV ALOR / PEnum_AssetTyp

e: fijo, movible Una clasificación
Los
delvalores
activo contenido
no se especifican
dentro de
enuna
el contrato,
fila. Si permisible
los valores por defecto son: “fijo” y “móvil”.
Costo de remplazo P_SINGLEVALUE IfcMonetaryMeasur correo Durante la fase de construcción y entrega: Precio de venta sugerido por el fabricante para
este tipo. Durante la planificación y la fase de diseño: no aplicable.
NominalLength P_SINGLEVALUE edida IfcPositiveLengthM una medida aproximada de la caja delimitadora que rodea el tipo de producto.
Ancho nominal P_SINGLEVALUE edida IfcPositiveLengthM una medida aproximada de la caja delimitadora que rodea el tipo de producto.
NominalHeight P_SINGLEVALUE edida IfcPositiveLengthM una medida aproximada de la caja delimitadora que rodea el tipo de producto.
Forma P_SINGLEVALUE Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
considerados durante el proceso de especificación. Durante la fase de construcción y de traspaso:
la descripción de texto de la información asociada encontrado en una hoja de datos de producto
del producto.
tamaño P_SINGLEVALUE Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
del producto.
Color P_SINGLEVALUE Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
del producto.
Terminar P_SINGLEVALUE Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
del producto.
Caracteristicas P_SINGLEVALUE IfcText Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
del producto.
AccessibilityPerform Ance P_SINGLEVALUE IfcLabel Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
del producto.
CodePerformance P_SINGLEVALUE IfcLabel Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
del producto.
SustainabilityPerfor Mance P_SINGLEVALUE IfcLabel Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
del producto.
Grado P_SINGLEVALUE IfcLabel Durante la planificación y la fase de diseño: las limitaciones específicas que deben estar / han sido
del producto.
Material P_SINGLEVALUE
constituyentes P_SINGLEVALUE
P_SINGLEVALUE IfcText

Tabla 84 Pset_ManufacturerOccurrence dinámico de definición de esquemas
Fecha de Adquisición P_SINGLEVALUE IfcDate La fecha en que se compró el artículo manufacturado.
Código de barras P_SINGLEVALUE IfcIdentifier La identidad del código de barras dado a una ocurrencia del producto.
Número de serie P_SINGLEVALUE IfcIdentifier El número de serie asignado a una ocurrencia de un producto.
BatchReference P_SINGLEVALUE IfcIdentifier La identidad de la referencia del lote de donde se toma una ocurrencia de un producto.
AssemblyPlace P_ENUMERATEDV ALOR IfcLabel / PEnum_As La enumeración que define que el conjunto está destinado a tener lugar, ya sea en una
semblyPlace: ORY HECHO, fábrica, otra ubicación fuera del sitio o en el sitio de construcción.
fuera del sitio, SIT
E, OTRAS, NOTKN propios,
DESACTIVADO
Tabla 85 Pset_ManufacturerTypeInformation dinámico de definición de esquemas
GlobalTradeItemNu mber P_SINGLEVALUE IfcIdentifier El Número Mundial de Artículo Comercial (GTIN) es un identificador para artículos comerciales
desarrollado por GS1 (www.gs1.org).
Número de artículo P_SINGLEVALUE IfcIdentifier número de artículo o referencia que se puede aplicar a un producto configurado de
acuerdo con un esquema estándar para el número de artículo definición según lo definido
por el fabricante. Se utiliza a menudo como el número de compra.
ModelReference P_SINGLEVALUE IfcLabel El número de modelo o designador del modelo del producto (línea o producto)
como asignado por el fabricante del artículo manufacturado.
ModelLabel P_SINGLEVALUE IfcLabel El nombre del modelo descriptivo del modelo del producto (línea o producto) como
asignado por el fabricante del artículo manufacturado.
Fabricante P_SINGLEVALUE IfcLabel La organización que fabrica y / o ensamblado el elemento.
Año productivo P_SINGLEVALUE IfcLabel El año de la producción de la pieza de manufactura.
AssemblyPlace P_ENUMERATEDV ALOR IfcLabel / PEnum_As La enumeración que define que el conjunto está destinado a tener lugar, ya sea en una
semblyPlace: ORY HECHO, fábrica o en la obra.
fuera del sitio, SIT
E, OTRAS, NOTKN propios,
DESACTIVADO
Tabla 86 Pset_ActionRequest dinámico de definición de esquemas
RequestSourceLabel P_SINGLEVALUE IfcLabel Un nombre específico o etiqueta que califica aún más la identidad de una fuente de solicitud. En el caso
de un correo electrónico, esta puede ser la dirección de correo electrónico.
RequestSourceName P_REFERENCEVAL IfcPerson La persona que realiza la solicitud, cuando sea conocido.
UE
RequestComments P_SINGLEVALUE IfcText Los comentarios que se pueden hacer en la petición.

Tabla 87 COBie_ActionRequest dinámico de definición de esquemas
Tipo P_ENUMERATEDV ALOR / PEnum_ActionRequestType: Cambio, Reclamación, Coordinación, Medio Ambiente, función, En doorAirQuality,
Instalación, RFI, Seguridad, Especificación
Riesgo P_ENUMERATEDV ALOR / PEnum_ActionRequestRisk: muy alta, alta, moderada, baja, Desconocido
Oportunidad P_ENUMERATEDV ALOR / PEnum_ActionRequestChance: Se ha producido, alto, moderado, bajo Desconocido
Impacto P_ENUMERATEDV ALOR / PEnum_ActionRequestImpact: muy alta, alta, moderada, baja, Desconocido
Tabla 100 COBie_ConstructionProductResourceType dinámico de definición de esquemas
Categoría P_ENUMERATEDV ALOR / PEnum_ConstructionProductResourceTypeCategory: Parte, PartSet, lubricante, Otros, repuesto, SpareSet
NúmeroConjunto P_SINGLEVALUE
PartNumber P_SINGLEVALUE
Tabla 88 COBie_ConstructionProductResource dinámico de definición de esquemas
Categoría P_ENUMERATEDV ALOR / PEnum_ConstructionProductResourceCategory: Trabajo, materiales, herramientas, formación
4.2.7.15 conjunto exclusión Entidad
A medida que el número de establecido Ministerio de Asuntos Interiores crece, se requiere que las compañías de software para implementar las exportaciones a
cada uno de estos de MVD. Además, el contenido de información de este tipo de MVD en un contexto contractual específica requerirá también las compañías de
software para filtrar la información exportada dentro de ese MVD. Hasta la fecha, las compañías de software que haya facilitado datos COBIE en formato IFC lo
han hecho mediante la extensión de la especificación de Coordinación MVD. Como resultado, el contenido de la información, y el tamaño de estos archivos es
significativamente mayor que la requerida para Cobie.
Para ayudar a las empresas de software para responder a la NBIMS-estadounidense ™ COBIE MVD, las tablas siguientes entidades lista de IFC que se
pueden filtrar al producir los conjuntos de datos genéricos COBIE para su uso en los Estados Unidos. Las listas de exclusión se expresan como entidades
excluidas del formato de aplicación de hoja de cálculo COBIE.
El Apéndice de esta norma proporciona una visión alternativa de las listas de exclusión de entidades, que muestra los gráficos de herencia de la CFI. Estos
gráficos también pueden ser útiles para comprender completamente el contexto de estas listas de exclusión.
Dentro de los Estados Unidos, los propietarios específicos también pueden extender la especificación de Cobie a activos no gestionados instalaciones.
Como resultado proveedores de software deben considerar la implementación de listas de exclusión flexibles que admiten el estándar genérico y listas de
exclusión específicos del contrato. Además, como COBIE es
proveedores de software a nivel internacional normalizado adoptado también pueden desear implementar listas de exclusión en base a los requerimientos regionales que
están fuera del alcance de NBIMS-estadounidense ™.

Tabla 101 Entidades Excluidos del tipo y de componentes
IfcAnnotation IfcJunctionBox IfcJunctionBoxType IfcFlowSegment IfcFlowSegmentType
IfcBeam IfcMechanicalFastener IfcMember IfcSpatialZone IfcStair IfcStairFlight
IfcBeamStandardCase IfcMemberStandardCase IfcMemberType IfcStairFlightType IfcStairType IfcStructuralAction
IfcBeamType IfcBuilding IfcOpeningElement IfcOpeningStandardCase IfcStructuralActivity IfcStructuralConnection
IfcPile IfcPipeFitting IfcPipeFittingType IfcStructuralCurveAction
IfcBuildingElementPart IfcBuildingStory IfcPipeSegment IfcPipeSegmentType IfcPlate IfcStructuralCurveConnection
IfcCableCarrierFitting IfcPlateStandardCase IfcPlateType IfcStructuralCurveMember
IfcCableCarrierFittingType IfcProcedureType IfcProjectionElement IfcStructuralCurveMemberVarying
IfcCableCarrierSegment IfcRailing IfcRailingType IfcRamp IfcStructuralCurveReaction IfcStructuralItem
IfcCableCarrierSegmentType IfcRampFlight IfcRampFlightType IfcStructuralLinearAction IfcStructuralMember
IfcCableFitting IfcCableFittingType IfcRampType IfcReinforcingBar IfcStructuralPlanarAction IfcStructuralPointAction
IfcCableSegment IfcCableSegmentType IfcReinforcingMesh IfcRoof IfcSite IfcSlab IfcStructuralPointConnection
IfcColumn IfcSlabElementedCase IfcSlabStandardCase IfcStructuralPointReaction IfcStructuralReaction
IfcSlabType IfcSpace IfcSpaceType IfcStructuralSurfaceAction
IfcSpatialElement IfcSpatialElementType IfcStructuralSurfaceConnection
IfcSpatialStructureElement IfcStructuralSurfaceMember
IfcColumnStandardCase IfcSpatialStructureElementType IfcStructuralSurfaceMemberVarying
IfcColumnType IfcCurtainWall IfcStructuralSurfaceReaction IfcSurfaceFeature
IfcCurtainWallType IfcTaskType IfcTypeObject IfcTypeProcess
IfcDistributionPort IfcDuctFitting IfcTypeProduct IfcVirtualElement IfcVoidingFeature
IfcDuctFittingType IfcDuctSegment IfcWall IfcWallElementedCase IfcWallStandardCase
IfcDuctSegmentType IfcWallType
IfcElementAssembly
IfcElementType IfcEventType
IfcExternalSpatialElement
IfcExternalSpatialStructureElement IfcFastener
IfcFastenerType IfcFeatureElement
IfcFeatureElementAddition
IfcFeatureElementSubtraction IfcFlowFitting
IfcFlowFittingType IfcFooting

Tabla 102 Entidades excluidos de todas las hojas
IfcAnnotation IfcJunctionBox IfcJunctionBoxType IfcStair IfcStairFlight IfcStairFlightType IfcStairType
IfcBeam IfcMechanicalFastener IfcMember IfcStructuralAction IfcStructuralActivity
IfcBeamStandardCase IfcMemberStandardCase IfcMemberType IfcStructuralConnection IfcStructuralCurveAction
IfcBeamType IfcOpeningElement IfcOpeningStandardCase IfcStructuralCurveConnection
IfcBuildingElementPart IfcPile IfcPipeFitting IfcPipeFittingType IfcStructuralCurveMember
IfcCableCarrierFitting IfcPipeSegment IfcPipeSegmentType IfcPlate IfcStructuralCurveMemberVarying
IfcCableCarrierFittingType IfcPlateStandardCase IfcPlateType IfcStructuralCurveReaction IfcStructuralItem
IfcCableCarrierSegment IfcProcedureType IfcProjectionElement IfcStructuralLinearAction IfcStructuralMember
IfcCableCarrierSegmentType IfcRailing IfcRailingType IfcRamp IfcStructuralPlanarAction IfcStructuralPointAction
IfcCableFitting IfcCableFittingType IfcRampFlight IfcRampFlightType IfcStructuralPointConnection
IfcCableSegment IfcCableSegmentType IfcRampType IfcReinforcingBar IfcStructuralPointReaction IfcStructuralReaction
IfcColumn IfcReinforcingMesh IfcRoof IfcSite IfcSlab IfcStructuralSurfaceAction
IfcSlabElementedCase IfcSlabStandardCase IfcStructuralSurfaceConnection
IfcSlabType IfcSpaceType IfcSpatialElement IfcStructuralSurfaceMember
IfcColumnStandardCase IfcSpatialElementType IfcStructuralSurfaceMemberVarying
IfcColumnType IfcCurtainWall IfcSpatialStructureElement IfcStructuralSurfaceReaction IfcSurfaceFeature
IfcCurtainWallType IfcSpatialStructureElementType IfcSpatialZone IfcTaskType IfcTypeObject IfcTypeProcess
IfcDistributionPort IfcDuctFitting IfcTypeProduct IfcVirtualElement IfcVoidingFeature
IfcDuctFittingType IfcDuctSegment IfcWall IfcWallElementedCase IfcWallStandardCase
IfcDuctSegmentType IfcWallType
IfcElementAssembly
IfcElementType IfcEventType
IfcExternalSpatialElement
IfcExternalSpatialStructureElement IfcFastener
IfcFastenerType IfcFeatureElement
IfcFeatureElementAddition
IfcFeatureElementSubtraction IfcFlowFitting
IfcFlowFittingType IfcFlowSegment
IfcFlowSegmentType IfcFooting

4.2.8 procedimientos de pruebas de conformidad
Comentario del autor Editorial: El NBIMS-estadounidense ™ V2 COBIE estándar de la Parte D proporciona información general relativa a las pruebas de
conformidad COBIE llevado a cabo en el período 2007-2008. Esta norma actualizaciones que
información basada en la experiencia de más de una docena de eventos públicos, incluyendo treinta proveedores de software. La conclusión alcanzada
durante estas sesiones es que para el estándar estadounidense NBIMS ™ para ser utilizado en los contratos, las pruebas deben evaluar el formato,
contenido y flujos de trabajo asociados. Como resultado, las pruebas buildingSMART Alliance® se lleva a cabo como un “desafío” y no un evento
“Certificación”. Dos tipos de pruebas se han desarrollado como parte de la Alliance® Desafío buildingSMART. La “prueba de control de calidad” se utiliza en
archivos COBIE producidos en fases específicas del ciclo de vida del proyecto. La “Prueba de Aseguramiento de la Calidad” se aplica para el software que
consumen los archivos de datos COBIE.
Pruebas de Control de Calidad buildingSMART Alliance® comienza con las pruebas de “verificación”. las pruebas de verificación automatizada
demuestra que el archivo de datos proporcionada es técnicamente correcto. archivos no válidos no se les permite participar en la segunda etapa de
pruebas. La segunda etapa de la prueba es una prueba de “validación” para ver si la información proporcionada en el archivo podría ser utilizado, en
última instancia, para reemplazar el entregable contrato basado en el documento equivalente. Los criterios utilizados para validar la información
proporcionada es para determinar si la información proporcionada sería aceptable en lugar de la entregable contrato correspondiente. Una medida
objetiva de tiempo para corregir manualmente los archivos de datos es la métrica objetiva que se puede informar en base a pruebas de control de
calidad.
buildingSMART Alliance® pruebas de control de calidad comienza con la verificación de la importación de datos de Cobie en un sistema de
software determinado. La validación de que la información es evaluada, en el contexto de los flujos de trabajo de un sistema de software dado,
para determinar si la información se aplica consistentemente en todos los lugares apropiados dentro de ese software específico. La salida de
las pruebas de control de calidad es la identificación de la información que se importó correctamente en el software de prueba, y qué
información no se importó correctamente.
El Alliance® buildingSMART no puede predecir el impacto final de sus normas a través de una industria de la construcción de Estados
Unidos que comprende un porcentaje notable del Producto Interno Bruto del país.
El objetivo de la entrega de datos precisos y oportunos COBIE al menor costo posible en el mayor número posible de proyectos es el objetivo del
proyecto COBIE. Si bien las normas de la alianza buildingSMART deben tener sus raíces en la CFI para asegurar que todos los de MVD tienen una
ascendencia común y la cartografía sin ambigüedades, el formato de aplicación definitiva para los datos COBIE, en todos los casos de uso, puede
no ser la CFI. Con este fin, cualquier asignación aprobada COBIE: CFI, ifcXML, SpreadsheetML y COBieLite se les permite ser presentado como
parte de las pruebas de Cobie. La selección del formato de aplicación se deja al proveedor del software.
Para asegurar la imparcialidad en los modelos de prueba prueba y se espera la salida están a disposición del público (2012a Este). El Modelo de
Clínica Médica en los documentos de construcción y diseño arquitectónico etapa se ha utilizado como base para el desafío. controles puntuales
específicos de contenido del modelo son identificados como parte del proceso de comprobación y luego verifican durante el proceso de Challenge.
Sobre la base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación Subcomité para los estándares de intercambio de información revisados,
la información proporcionada en esta sección debe considerarse como una Cambio moderada .]
4.2.8.1 Los requisitos de formato y contenido
lista de reglas de prueba 4.2.8.1.1 Control de calidad
Para el software que produce archivos COBIE, un procedimiento de prueba de control de calidad automatizado ha sido adoptado y utilizado en cada uno
de los eventos reto para evaluar el formato y el contenido de ese archivo COBIE. Las reglas se utilizan para evaluar la integridad del formato y la
cardinalidad de un archivo de prueba COBIE.

• No nulo • Número válido
• No vacío • ValidNumberOrNA
• Único • AtLeastOneRowPresent
• Referencia cruzada • ZeroOrGreaterOrNA
• OneAndOnlyOneFacilityFound
De acuerdo con la publicación Guía COBIE, los criterios para la evaluación del contenido de un entregable Cobie es que la información
proporcionada en un archivo COBIE coincide con la información que se encuentra en el conjunto de dibujos o documento equivalente.
4.2.8.1.2 Control de calidad de definición de reglas de prueba
Las siguientes reglas generales se aplican para las pruebas de control de calidad de los archivos de Cobie presentadas:
No nulo - Debe tener un valor de texto que no es n / a o vacío
No vacío - Debe tener un valor de texto (n / a es aceptable)
único - Debe ser único dentro del ámbito de la hoja de trabajo
Referencia cruzada - Debe coincidir con una columna Nombre de referencia en otra hoja de cálculo
OneAndOnlyOneFacilityFound - Sólo se permite una instalación
Número válido - Debe representar un número válido - n / a no es aceptable
ValidNumberOrNA - Si se proporciona el texto que debe representar número válido o 'n / a'
AtLeastOneRowPresent - Hoja de trabajo debe tener por lo menos una fila
ZeroOrGreaterOrNA - Si se proporciona el texto que debe representar un número válido mayor que cero o n / a
Las siguientes secciones describen la plena aplicación de estas reglas a un archivo COBIE dado que se prueba. Esta descripción se organiza en un
formato específico para ayudar al lector de esta norma para comprender y evaluar estas reglas. En primer lugar las reglas se basan en la
representación de los datos COBIE SpreadsheetML COBIE. La primera de las reglas de cada juego se aplica a número de filas de una entidad COBIE
dado. Siguientes reglas en cada conjunto se aplican a campos específicos dentro de esa hoja de cálculo. Estas pruebas se aplican
independientemente del formato del archivo de prueba COBIE probado (IFC, ifcXML, SpreadsheetML, COBieLite).
la aplicación de reglas de prueba 4.2.8.1.3 Control de calidad
Las reglas aplicadas a COBie.Contacts:
• Contact.AtLeastOneRowPresent • Contact.CreatedBy.CrossReference
• Contact.Email.Unique • Contact.CreatedBy.NotNull
• Contact.Email.NotNull • Contact.CreatedOn.NotNull
• Contact.Email.Format • Contact.ExternalSystem.NotEmpty

• Contact.ExternalObject.NotEmpty • Contact.FamilyName.NotEmpty
• Contact.ExternalIdentifier.NotEmpty • Contact.Street.NotEmpty
• Contact.Category.NotNull • Contact.PostalBox.NotEmpty
• Contact.Company.NotNull • Contact.Town.NotEmpty
• Contact.Phone.NotNull • Contact.StateRegion.NotEmpty
• Contact.Department.NotEmpty • Contact.PostalCode.NotEmpty
• Contact.OrganizationCode.NotEmpty • Contact.Country.NotEmpty
• Contact.GivenName.NotEmpty
Las reglas aplicadas a COBie.Facility:
• Facility.OneAndOnlyOneFacilityFound • Facility.LinearUnits.NotNull
• Facility.Name.NotNull • Facility.AreaUnits.NotNull
• Facility.Name.Unique • Facility.VolumeUnits.NotNull
• Facility.CreatedBy.CrossReference (al • Facility.Currency.NotNull

contacto)
• Facility.AreaMeasurement.NotNull
• Facility.CreatedBy.NotNull
• Facility.ExternalSystem.NotEmpty
• Facility.CreatedOn.NotNull
• Facility.ExternalProjectObject.NotEmpty
• Facility.CreatedOn.Valid (Válido dirección de correo
• Facility.ExternalProjectIdentifier.NotEmpty
electrónico)
• Facility.ExternalSiteObject.NotEmpty
• Facility.Category.NotNull
• Facility.ExternalSiteIdentifier.NotEmpty
• Facility.Description.NotEmpty
• Facility.ExternalFacilityObject.NotEmpty
• Facility.ProjectName.NotNull
• Facility.SiteName.NotNull • Facility.ExternalFacilityIdentifier.NotEmpt
Las reglas aplicadas a COBie.Floor:
• Floor.AtLeastOneRowPresent
• Floor.Name.NotNotNull
• Floor.Name.Unique
• Floor.CreatedBy.CrossReference (al contacto)
• Floor.CreatedBy.NotNull
• Floor.CreatedOn.Valid (Válido dirección de correo electrónico)
• Floor.CreatedOn.NotNull
• Floor.ExternalSystem.NotEmpty
• Floor.ExternalObject.NotEmpty
• Floor.ExtIdentifier.NotEmpty
• Floor.Category.NotNull

• Floor.Elevation.ValidNumberOrNA
Floor.Height.ZeroOrGreaterOrNARules aplica a COBie.Space:
• Space.AtLeastOneRowPresent
• Space.CreatedBy.CrossReference (al contacto)
• Space.CreatedBy.NotNull
• Space.CreatedOn.NotNull
• Space.CreatedOn.Valid (Válido dirección de correo electrónico)
• Space.ExternalSystem.NotEmpty
• Space.ExternalObject.NotEmpty
• Space.ExtIdentifier.NotEmpty
• Space.Category.NotNull
• Space.Name.NotNull
• Space.PrimaryKey.Unique.Warning (Nombre)
• Space.PrimaryKey.Unique.Error (Nombre, FloorName)
• Space.FloorName.NotNull, FloorName.CrossReference
• Space.Description.NotNull
• Space.RoomTag.NotEmpty
• Space.UsableHeight.ZeroOrGreaterOrNA
• Space.GrossArea.ZeroOrGreaterOrNA
Space.NetArea.ZeroOrGreaterOrNARules aplicadas a COBie.Zone:
• Zone.CreatedBy.CrossReference (al contacto)
• Zone.CreatedBy.NotNull
• Zone.CreatedOn.NotNull
• Zone.CreatedOn.Valid (Válido dirección de correo electrónico)
• Zone.Category.NotNull
• Zone.Description.NotEmpty
• Zone.ExternalSystem.NotEmpty
• Zone.ExternalObject.NotEmpty
• Zone.ExtIdentifier.NotEmpty
• Zone.Name.NotNull
• Zone.PrimaryKey.Unique (nombre, categoría, SpaceNames)
• Zone.SpaceNames.NotNull, SpaceNames.CrossReference

Las reglas aplicadas a COBie.Type:
• Type.AtLeastOneRowPresent • Type.WarrantyDurationLabor.ZeroOrGr
eaterOrNA
• Type.Name.NotNotNull
• Type.WarrantyDurationUnit.NotNull
• Type.Name.Unique
• Type.ReplacementCost.ZeroOrGreater ORNA
• Type.CreatedBy.CrossReference (al
contacto)
• Un Type.ExpectedLife.ZeroOrGreaterOrN
• Type.CreatedBy.NotNull
• Type.CreatedOn.NotNull
• Type.DurationUnit.NotNull
• Type.CreatedOn.Valid (Válido dirección de correo electrónico)
• Type.WarrantyDescription.NotEmpty
• Type.NominalLength.ZeroOrGreaterOr NA
• Type.Category.NotNull
• Type.ExternalSystem.NotEmpty
• Un Type.NominalWidth.ZeroOrGreaterOrN
• Type.ExternalObject.NotEmpty
• Type.ExtIdentifier.NotEmpty • Type.NominalHeight.ZeroOrGreater
• Type.Type.Component.AComponentFo • Type.ModelReference.NotEmpty
rEachType
• Type.Shape.NotEmpty
• Type.AssetType.NotNull
• Type.Size.NotEmpty
• Type.Manufacturer.NotNull
• Type.Color.NotEmpty
• Type.Manufacturer.CrossReference (hoja de
• Type.Finish.NotEmpty
contactos)
• Type.Grade.NotEmpty
• Type.ModelNumber.NotNull
• Type.Material.NotEmpty
• Type.WarrantyGuarantorParts.NotNull
• Type.Constituents.NotEmpty
• Type.WarrantyGuarantorParts.CrossR eferencia
(hoja de contactos) • Type.Features.NotEmpty
• Type.WarrantyDurationParts.validNum • Type.AccessibilityPerformance.NotEm Pty

berZeroOrGreaterOrNA
• Type.WarrantyGuarantorLabor.NotNull • Type.CodePerformance.NotEmpty
• Type.WarrantyGuarantorLabor.CrossR eferencia • Type.SustainabilityPerformance.Not vacía

(hoja de contactos)
Las reglas aplicadas a COBie.Component:
• Component.AtLeastOneRowPresent • Component.ExternalObject.NotEmpty
• Component.CreatedBy.CrossReferenc e (al • Component.ExtIdentifier.NotEmpty

contacto)
• Component.Name.NotNull
• Component.CreatedBy.NotNull
• Component.PrimaryKey.Unique.Warnin g (Nombre)
• Component.CreatedOn.NotNull
• Component.CreatedOn.Valid (Válido • Component.PrimaryKey.Unique.Error (Nombre,

Dirección de correo electrónico) Espacio)
• Component.ExternalSystem.NotEmpty • Component.TypeName.NotNull

• Component.TypeName.CrossReferenc e (Tipo Hoja • Component.SerialNumber.NotNull

de trabajo)
• Component.InstallationDate.NotNull
• Component.Space.NotNull
• Component.WarrantyStartDate.NotNull
• Component.Space.CrossReference (Hoja de
• Component.TagNumber.NotEmpty
trabajo Componente)
• Component.BarCode.NotEmpty
• Component.Description.NotNull
• Component.AssetIdentifier.NotEmpty
Las reglas aplicadas a COBie.System:
• System.CreatedBy.CrossReference (al contacto)
• System.CreatedBy.NotNull
• System.CreatedOn.NotNull
• System.CreatedOn.Valid (Válido dirección de correo electrónico)
• System.Category.NotNull
• System.ExternalSystem.NotEmpty
• System.ExternalObject.NotEmpty
• System.ExtIdentifier.NotEmpty
• System.Description.NotEmpty
• System.PrimaryKey.Unique (nombre, categoría, ComponentNames)
• System.Name.NotNull
• System.ComponentNames.NotNull
• System.ComponentNames.CrossReference
Reglas disponibles para COBie.Assembly, si la información está presente:
• Assembly.CreatedBy.CrossReference (al • Assembly.PrimarkyKey.Unique

contacto)
• Assembly.Name.NotNull
• Assembly.CreatedBy.NotNull
• Assembly.SheetName.NotNull
• Assembly.CreatedOn.NotNull
• Assembly.SheetName.CrossReference
• Assembly.CreatedOn.Valid (Válido dirección de correo
• Assembly.ParentName.NotNull
electrónico)
• Assembly.ParentName.Reference
• Assembly.ExternalSystem.NotEmpty
• Assembly.ChildNames.NotNull
• Assembly.ExternalObject.NotEmpty
• Assembly.ChildNames.CrossReferenc correo
• Assembly.ExtIdentifier.NotEmpty
• Assembly.Description.NotEmpty
• Assembly.AssemblyType.NotNull
Reglas para COBie.Connection, si la información está presente:

• Connection.CreatedBy.CrossReferenc e (al • Connection.ConnectionType.NotNull
contacto)
• Connection.SheetName.NotNull
• Connection.CreatedBy.NotNull
• ce Connection.SheetName.CrossReferen
• Connection.CreatedOn.NotNull
• Connection.CreatedOn.Valid (Válido • Connection.RowName1.NotNull

Dirección de correo electrónico)
• Connection.RowName1.CrossReferenc correo
• Connection.ExternalSystem.NotEmpty
• Connection.ExternalObject.NotEmpty • Connection.RowName2.NotNull
• Connection.ExtIdentifier.NotEmpty • Connection.RowName2.CrossReferenc correo
• Connection.Description.NotEmpty
• Connection.RealizingElement.NotNull
• Connection.PrimarkyKey.Unique
• Connection.PortName1.NotNull
• Connection.Name.NotNull
• Connection.PortName2.NotNull
Las reglas aplicadas a COBie.Spare:
• Spare.CreatedBy.CrossReference (al • Spare.Name.NotNotNull

contacto)
• Spare.Name.Unique
• Spare.CreatedBy.NotNull
• Spare.Category.NotNull
• Spare.CreatedOn.NotNull
• Spare.TypeName.NotNull
• Spare.CreatedOn.Valid (Válido dirección de correo electrónico)
• Spare.TypeName.CrossReference
• Spare.Suppliers.NotNull
• Spare.ExternalSystem.NotEmpty
• Spare.Suppliers.CrossReference (hoja de
• Spare.ExternalObject.NotEmpty
contactos)
• Spare.ExtIdentifier.NotEmpty
• Spare.SetNumber.NotEmpty
• Spare.Description.NotEmpty
• Spare.PartNumber.NotEmpty
Las reglas aplicadas a COBie.Resource:
• Resource.Name.NotNotNull
• Resource.Name.Unique
• Resource.CreatedBy.CrossReference (al contacto)
• Resource.CreatedBy.NotNull
• Resource.CreatedOn.NotNull
• Resource.CreatedOn.Valid (Válido dirección de correo electrónico)
• Resource.ExternalSystem.NotEmpty
• Resource.ExternalObject.NotEmpty
• Resource.ExtIdentifier.NotEmpty
• Resource.Description.NotEmpty

Resource.Category.NotNullRules aplica a COBie.Job:
• Job.CreatedBy.CrossReference (al • Job.Status.NotNull

contacto)
• Job.TypeName.NotNull
• Job.CreatedBy.NotNull
• Job.TypeName.CrossReference
• Job.CreatedOn.NotNull
• Job.Duration.NotEmpty
• Job.CreatedOn.Valid (Email valido
• Job.DurationUnit.NotEmpty
Dirección)
• Job.Start.NotEmpty
• Job.ExternalSystem.NotEmpty
• Job.TaskStartUnit.NotEmpty
• Job.ExternalObject.NotEmpty
• Job.Frequency.NotEmpty
• Job.ExtIdentifier.NotEmpty
• Job.FrequencyUnit.NotEmpty
• Job.Description.NotEmpty
• Job.TaskNumber.NotEmpty
• Job.Category.NotNull
• Job.Priors.NotEmpty
• Job.Name.NotNull
• Job.ResourceNames.NotEmpty
• Job.PrimaryKey.Unique (Nombre,
TypeName, TaskNumber)
Las reglas aplicadas a COBie.Document:
• Document.CreatedBy.CrossReference (al • Document.PrimaryKey.Unique (Nombre, Escenario,

contacto) SheetName, RowName)
• Document.CreatedBy.NotNull • Document.Name.NotNull
• Document.CreatedOn.NotNull • Document.ApprovalBy.NotEmpty
• Document.CreatedOn.Valid (Válido • Document.Stage.NotNull

Dirección de correo electrónico)
• Document.SheetName.NotNull
• Document.ExternalSystem.NotEmpty
• Document.SheetNameRowName.Cros
• Document.ExternalObject.NotEmpty sReference
• Document.ExtIdentifier.NotEmpty • Document.RowName.NotNull
• Document.Description.NotEmpty • Document.Directory.NotNull
• Document.Category.NotNull • Document.File.NotNull
Reference.NotEmpty
Las reglas aplicadas a COBie.Attribute:
• Attribute.CreatedBy.NotNull • Attribute.PrimaryKey.Unique (Nombre,

SheetName, RowName)
• Attribute.CreatedOn.NotNull
• Attribute.Name.NotNull
• Attribute.CreatedOn.Valid (Válido dirección de correo electrónico)
• Referencia
Attribute.SheetNameRowName.Cross
• Attribute.ExternalSystem.NotEmpty
• Attribute.Value.NotEmpty
• Attribute.ExternalObject.NotEmpty
• Attribute.Unit.NotEmpty
• Attribute.ExtIdentifier.NotEmpty
• Attribute.AllowedValues.NotEmpty
• Attribute.Description.NotEmpty
• Attribute.Category.NotNull

formateo regla 4.2.8.1.4 Prueba
normas de pruebas de control de calidad, Cobie descritos anteriormente, se han implementado en una variedad de formatos de diferentes
organizaciones y empresas. La herramienta de control de registro de eventos anteriores COBIE reto, el Kit de herramientas COBIE ha puesto en
práctica estas reglas en un formato de regla de verificación ISO llamada Schematron. El uso extendido de estas reglas ha sido posible gracias a la
simplicidad de la descripción de las reglas y la distribución de estas reglas como un proyecto de código abierto
El Kit de herramientas de Cobie es un proceso abierto
producto de código optimizado para soportar tanto la verificación del contenido de los datos COBIE y la validación de que la información en
contra del entregable esperado contrato.
4.2.8.1.5 cobertura de las pruebas entregable
El Kit de herramientas de Cobie implementa a informes de pruebas para evaluar los intercambios COBIE en dos puntos durante el proyecto:
diseño y construcción. La siguiente tabla identifica la información necesaria para la fase de diseño envíos de archivos COBIE. La información que
se proporciona en base al formato COBIE SpreadsheetML para simplificar la comprensión de los requisitos, aunque la aplicación es coherente,
independientemente del formato de archivo de prueba.
Bajo el buildingSMART Alliance® eventos reto llevaron a cabo hasta la fecha el COBie.Assembly, COBie.Connection, COBie.Coordinate, y no
se requiere hojas de trabajo COBie.Issue ya que estas hojas de trabajo contienen información que se encuentra actualmente fuera del ámbito
de la captura y el intercambio de información requerida para la instalación y gestión de activos dentro de los Estados Unidos. El uso de estas
hojas de trabajo para otros fines es posible, pero está fuera del alcance de esta norma. Como resultado, las pruebas de estas hojas de
trabajo solamente se logra si no se proporciona información como parte de la prueba.
El Kit de herramientas de Cobie implementa a informes de pruebas para evaluar los intercambios COBIE en dos puntos durante el proyecto:
diseño y construcción. La siguiente tabla identifica la información requerida para la fase handover- envíos de archivos COBIE.
Al igual que antes, la información se ofrecen basándose en el Cobie
SpreadsheetML formato para simplificar la comprensión de los requisitos, aunque la aplicación es coherente, independientemente del formato
de archivo de prueba.
Tabla 89 Prueba de control de calidad - Cobertura Regla de diseño
Contenido de informacion exigida Opcional N/A
COBie.Contacts X
COBie.Facility X
COBie.Floor X
COBie.Space X
COBie.Zone X
COBie.Type X
COBie.Component X
COBie.System X
COBie.Spare X
COBie.Resource X
COBie.Job X
COBie.Document X
COBie.Attribute X

Tabla 90 Prueba de control de calidad - Construcción Cobertura Traspaso
Contenido de informacion Necesario Opcional N/A
COBie.Contacts X
COBie.Facility X
COBie.Floor X
COBie.Space X
COBie.Zone X
COBie.Type X
COBie.Component X
COBie.System X
COBie.Spare X
COBie.Resource X
COBie.Job X
COBie.Document X
COBie.Attribute X
4.2.8.2 Ejemplos y asignaciones
4.2.8.2.1 lista de archivos Eexample
Los siguientes ejemplos se proporcionan a BIM Común del buildingSMART Alliance® repositorio de archivos (Medio 2012a).
Duplex
• Planificación - Programación Espacio
• - Diseño Coordinado
• Construcción - Traspaso
Edificio de oficinas
Clinica Medica
• Planificación - Programación Espacio
• Construcción - Traspaso
En el verano de 2013, un modelo adicional titulado “cuartel 101” también se ha añadido al conjunto de archivos BIM Común.

4.2.8.2.2 Ejemplo de descripción del archivo
Apartamento dúplex. El modelo dúplex fue creado originalmente por un estudiante que desarrolló este edificio como parte de un concurso
de diseño. Este modelo fue utilizado en el evento COBIE Desafío Dic de 2009.
Edificio de oficinas. El modelo de edificio de oficinas de dos pisos fue desarrollado en base a los planos de planta de muestra publicadas para un tipo específico de edificio
de oficinas de tamaño medio construido en los Estados Unidos.
Clinica Medica. El proyecto Clínica Modelo se basa en un edificio médico y dental clínica en un lugar en el sur-oeste de Estados
Unidos. El modelo también viene con un juego de planos redactados los documentos de construcción etapa de diseño y manuales de
operación y mantenimiento. Este modelo fue utilizado en
buildingSMART Alliance® eventos reto a partir de 2011.
101 cuarteles. El proyecto cuartel 101 se basa en un edificio del cuartel estándar. Se han proporcionado dibujos estándar en formato PDF y
archivos de la etapa de diseño COBIE asociados. CADD archivos están siendo redactados para ser hecha pública a partir de la fecha de
preparación de esta norma.
4.2.8.2.3 BIM común de archivos de reutilización
La alianza buildlingSMART archivos BIM Común se utilizan para todas las pruebas COBIE.
Los archivos utilizados para la prueba en eventos reto buildingSMART Alliance® desde 2011 se han basado en el proyecto de clínica médica. Este
proyecto fue seleccionado por varias razones: (1) es un proyecto real que ha sido diseñado y construido, (2) un conjunto completo de dibujos y las
operaciones de construcción redactados y manuales de mantenimiento se han proporcionado, y (3) es de significativa tamaño y alcance para hacer
frente a la mayoría de los problemas prácticos de aplicación probable que aparezca en la práctica.
4.2.8.2.4 acuerdos ejecutores
Como parte de los acuerdos COBIE reto eventos ejecutores de programas se han desarrollado y documentado en un documento de referencia
suplementario llamado el ‘Cobie Responsabilidad Matrix’. Este documento se proporciona para el uso público y describe todos los ejecutores de los
acuerdos necesarios e incluye proveedores específicos de los acuerdos. Se requiere que estos acuerdos para apoyar a los vendedores con
implementaciones alternativas legales de la CFI SPFF. Estos acuerdos están dirigidos a tener más uso de Cobie con los datos proporcionados por
los proveedores de la CFI.
El enlace a la Matriz de Responsabilidad COBIE se puede encontrar a través de los medios y Cobie
Métodos sitio web.
No se requieren acuerdos sido ejecutores de programas para la presentación de formatos SpreadsheetML y COBieLite ya que dichos
formatos se especifican de manera que no permiten que múltiples implementaciones alternativas válidas.
4.2.8.2.5 SpreadsheetML transformar
información técnica detallada necesaria para transformar los datos entre los formatos de Cobie IFC y SpreadsheetML se proporcionan en el
Anexo A.
El uso del formato para los datos SpreadsheetML Cobie es opcional en esta especificación. Es el requisito de las compañías de
software de aplicación para determinar el uso más apropiado de su software y los recursos en el contexto de sus mercados
específicos.
4.2.8.2.6 COBieLite transformar

información técnica detallada necesaria para transformar los datos de Cobie SpreadsheetML y el esquema COBieLite se proporcionan en el
Anexo A.
El uso de COBieLite es opcional en esta especificación. Es el requisito de las compañías de software de aplicación para determinar
el uso más apropiado de su software y los recursos en el contexto de sus mercados específicos.
4.2.8.3 herramientas y procedimientos de prueba
4.2.8.3.1 Lista de herramienta de prueba
Las siguientes herramientas están disponibles para probar archivos COBIE. Información sobre el uso de estas herramientas y su disponibilidad de estas herramientas se
encuentra en una sub-sección posterior de este estándar.
• ToolKit COBIE
• bimServer.org
• bimServices
• EcoDomus PM
• Sistema Onuma
• google Docs
Cobie datos presentados en formato COBieLite también pueden ser validados por cualquier número de programas de comprobación de esquema XML
libres y comerciales. El hecho de que COBieLite puede ser validado por una amplia gama de herramientas orientadas por el programador refleja el
objetivo general de COBieLite para abrir el uso de datos fuera de la comunidad COBIE la tradicional buildingSMART Alliance®. Estos programas de
comprobación XML incluyen, pero no se limitan a, los siguientes:
• Mecanismo de montaje de componentes (CAM) Comprobador
• XMLSpy
• Saxson Analizador XML
• Código Java NetBeans
• MS Visual Studio
4.2.8.3.2 algoritmo de prueba
La prueba de los intercambios de información debe incluir tanto la prueba de la exportación de archivos COBIE, en los principales hitos identificados de los
proyectos, y la importación de archivos COBIE por aquellos que utilizan datos de Cobie en sus productos. Las pruebas de control de calidad describen las
pruebas de los archivos COBIE exportados. Pruebas de Calidad Aseguramiento describe el proceso de comprobar manualmente que los datos importados
Cobie es exacta y se ha utilizado correctamente dentro del contexto del sistema de importación. Los algoritmos para el control de calidad y pruebas de
aseguramiento de la calidad se proporcionan en esta sección.
4.2.8.3.2.1 algoritmo de pruebas de control de calidad
pruebas de control de calidad comienza con la especificación de los ficheros BIM Común específica necesaria para poner a prueba un cambio dado. Pruebas
recientes se ha centrado en los archivos de modelo de clínica médica. Durante una serie de reuniones mensuales del equipo de empresas de software son
capaces de hacer preguntas relacionadas con los archivos especificados y el mapeo de información entre los archivos de prueba y las estructuras de datos y
flujos de trabajo específicos dentro de sus productos. Después de las reuniones de cada compañía de software produce el archivo basado en el software que
es

disponible para su uso en producción a partir de la fecha de la Challenge. Sólo se puede probar de software beta, por única excepción.
Los siguientes componentes comprenden el algoritmo Tool Kit COBIE para probar COBIE 2.4 archivos con formato:
• Transformaciones necesarias para normalizar la CFI, SpreadsheetML y archivos con formato COBieLite
• Un conjunto de reglas para los archivos de la fase de diseño de pruebas COBIE
• Un conjunto de reglas para la prueba archivos fase de construcción / de traspaso COBIE
reglas de transformación se describen en el Anexo A. La regla establece a sí mismos se han desarrollado sobre la base de la norma de referencia
basado en la norma ISO Schematron: ISO / IEC 19757-3: 2006 “Tecnología de la información - documento de esquema de lenguaje de definición
(dsdl) - Parte 3: basado en reglas de validación - Schematron”. La plena aplicación de las normas COBIE, descrito anteriormente en esta norma, en
Schematron y el código de la aplicación asociada (según sea necesario) está disponible para su inspección ya que el Cobie Toolkit es un proyecto de
código abierto.
Las pruebas automatizadas de archivos COBIE verifica que se proporcionan los campos requeridos, las reglas de negocio se encontraron, y se encuentra
cardinalidad datos adecuados. Tal prueba no significa, sin embargo, validar que los datos son de cualquier valor para el usuario. Para las pruebas de
validación de la información proporcionada en el archivo COBIE debe coincidir con el previsto en el dibujo o la presentación equivalente. El uso del edificio
clínica médica es importante para que el redactado información real, el diseño y la entrega de la construcción en el proyecto real está disponible para este
propósito.
Para validar la calidad del contenido de un archivo exportado COBIE prueba buildingSMART Alliance® publica las estadísticas globales de los
expedientes presentados esperados para las fases de diseño y construcción. El software
compañías proporcionan esa información a sus diseñadores o personal de entrada de datos y se desarrollan los modelos globales. Además de los
recuentos totales modelo de objetos, un número limitado de espacios específicos dentro de la instalación debe ser modelado en detalle. La recopilación
de información que se encuentra en todas las disciplinas se proporciona a las empresas para proporcionar el conjunto objetivo de objetos detallados y
atributos asociados en espacios específicos.
Si bien el objetivo de Desafíos buildingSMART Alliance® es no tener las compañías de software de re-diseñar la instalación de ensayo, es importante
que se probaron algunos aspectos de un modelo totalmente diseñado. Este tipo de pruebas asegura que la compañía de software de producción de los
dibujos de diseño de software de flujo de trabajo se ocupa de cuestiones individuales en la documentación apropiada.
Cuando se ha contabilizado el número de desviaciones entre los recuentos de objetos globales y las necesidades específicas de modelado espacio las pruebas
de control de calidad calcula la cantidad de tiempo necesario para que un usuario profesional COBie- para actualizar manualmente una hoja de cálculo COBIE
para corregir estas desviaciones. Todos los modelos, pruebas, instrucciones de software y materiales relacionados se hace público para que los usuarios de
software de prueba para reproducir las pruebas resultantes en cualquier momento.
4.2.8.3.2.2 pruebas de control de calidad
A diferencia de las pruebas exportado archivos COBIE, la prueba de la importación de archivos Cobie es altamente dependiente de los flujos de trabajo y los
mercados específicos en los que el software es utilizar la importación. Por ejemplo, el software
ayuda a un gestor de mantenimiento de las instalaciones tendrá que importar los programas de mantenimiento preventivo a partir del archivo COBIE
tener un completo conjunto de la información. Un tipo diferente de software, por ejemplo uno que sólo es compatible con la gestión de los inquilinos
dentro de una instalación completa no necesitará los datos COBIE relacionados con la gestión de mantenimiento.
Otra diferencia entre las pruebas de archivos exportados e importados, es que la capacidad de asegurar que las relaciones contenidas en el
COBIE, así como los datos necesarios, estén debidamente representados. Un ejemplo de una prueba tal es asegurar que los componentes
COBIE importados se colocan dentro de los espacios. Dado

que algunos software de gestión de mantenimiento tiene una estructura de datos que representa explícitamente el espacio, y otros no, se necesita una
cuidadosa consideración de la utilización de los datos COBIE dentro del contexto de cada producto de software correspondiente.
La conducta de las pruebas de control de calidad comienza con la publicación de los archivos de ejemplo por el organizador del evento buildingSMART Alliance®
Challenge. Normalmente, los archivos utilizados se basan en el archivo de ejemplo del archivo Clínica Médica Común BIM en el diseño y la construcción de
traspaso. A continuación, el proveedor de software identifica aquellos aspectos del modelo de datos COBIE que son relevantes para su producto específico.
Cuando esté listo el proveedor de software demuestra la importancia de ese conjunto de datos COBIE. La persona que realiza la prueba de control de calidad puede
pedir que la información específica en el archivo puede cambiar para verificar que esta nueva información es importado. Todas las pantallas de software relevantes
son revisados para detectar la presencia y cantidad de datos que se encuentran en el conjunto de datos COBIE importado. Cualquier desviación se identifican por la
cantidad de tiempo necesario para volver a introducir manualmente los datos que se encuentran en los datos COBIE establecidos.
4.2.8.3.2.3 Ssupport de los ciclos de desarrollo de software
El Alliance® buildingSMART es de apoyo de proveedores de software de usarlo normas dentro de los ciclos de desarrollo de software de proveedores. Como
resultado, grandes esfuerzos se han dedicado a trabajar con los proveedores para proporcionar los enfoques progresivos para la aplicación parcial de Cobie
que permite la compañía de software para adaptarse a este trabajo dentro de sus otras prioridades. Esto significa que los diferentes vendedores en el mismo
tipo de negocio no se pueden exportar o importar el mismo conjunto de datos COBIE. Independientemente de la etapa de implementación de Cobie, todos
los resultados de las pruebas se hacen públicamente.
4.2.8.3.2.4 formato de resultado de la prueba
Para reflejar la variabilidad en los resultados de las pruebas de diversos proveedores y la variación en el nivel de aplicación de cada vendedor
los resultados de un Alliance® Desafío buildingSMART se publican a través de la buildingSMART Alliance® Medios y métodos de página. Cada
vendedor tiene el mismo conjunto de información para proporcionar y se evalúa el mismo que cualquier otro proveedor, dentro de esa clase de
software. productos de software no se les permite competir en sectores en los que no se utilizan normalmente. Por ejemplo, el software para el
diseño arquitectónico y coordinada también debe ser capaz de producir los entregables de contacto que documentan la realización de esas
fases del proyecto.
Dentro de una determinada clase de software, página de resultados de una lista de aquellos aspectos de Cobie correspondientes a ese sector y también
aquellas que el vendedor tiene, o no se ha implementado como parte de un evento de desafío dado. La primera buildingSMART Alliance® página Medios y
métodos proporciona resultados más recientes de un vendedor. las pruebas anteriores pueden encontrarse accediendo a ver los resultados detallados de las
pruebas. La información sobre cada una de las páginas de resultados detallados de los vendedores se formatea para que los miembros Alliance®
buildingSMART a distinguir entre aquellos proveedores con implementaciones completas, o menos completa, de Cobie.
Teniendo en cuenta que un vendedor ha identificado un conjunto específico de datos COBIE relevantes a los usuarios de su producto, el número de
diferencias individuales entre el archivo de datos COBIE esperado (o importar datos) y lo que se presenta en el archivo de exportación del proveedor o
software se identifican . Estas diferencias representan transcripción o errores de modelado por la programación de software en el sistema del proveedor.
Si los datos Cobie es ser
corregido en el lugar de trabajo, se requiere la entrada manual de datos. Esta entrada de datos manual, para el propósito de un Challenge COBIE
se evalúa en un minuto por cada fila de archivo de datos COBIE que contiene un error. Si hay varios errores en una fila de datos COBIE dado, que
está todavía cuentan como un solo error. El nivel de calidad se informó en el número de minutos u horas, requerido para un experto en la materia
para corregir el archivo COBIE manualmente.
4.2.8.3.3 Los archivos de prueba
El buildingSMART Alliance® página web archivos de información de construcción Modelo común (Este 2012a) es el repositorio para todos los archivos de
modelo para las pruebas de Cobie Challenge. Cobie archivos de ejemplo para edificios (una unidad de vivienda dúplex, un edificio de oficinas de dos pisos, y
una clínica médica / dental) están disponibles para la prueba. Estas

archivos de ejemplo se proporcionan de forma gratuita por el buildingSMART Alliance® bajo una licencia Creative común. La forma de esa
licencia, que no está afectado por la referencia en este documento, permite el uso ilimitado de éstos para cualquier propósito.
El uso de los archivos debe ser citado de nuevo a la buildingSMART
Alliance®. Los usuarios pueden cambiar cualquiera de estos archivos; Sin embargo, si se cambian los archivos que ya no pueden ser referidos como uno de los
conjuntos de archivos BIM Común.
4.2.8.3.4 Prueba de la disponibilidad de herramientas de software
La siguiente tabla muestra la lista de herramientas y sus sitios web asociados. buildingSMART Alliance® eventos reto usados en los Estados Unidos
para probar la conformidad de los archivos COBIE a las normas NBIMS-estadounidense ™ es el Kit de herramientas de Cobie. bimServer.org se
proporciona en la lista de abajo ya que el código COBIE Toolkit está disponible ya sea a través de la Alliance® buildingSMART o a través del proyecto
bimServer.org de código abierto. La fuente autorizada para la COBIE ToolKit es el enlace proporcionado a través de la buildingSMART proporcionado
Alliance® más adelante en este estándar.
Tabla 105 Herramientas NBIMS por Estados Unidos Testing ™ COBIE
Producto Tipo Descripción / Localización
ToolKit COBIE Fuente abierta transformación de modelos, comprobación y presentación de informes de un encargo de la estructura
del producto bimserver.org utilizado en eventos COBIE reto.
http://www.projects.buildingsmartalliance.org/files/?artifact_id=5466
bimServer.org Fuente abierta Un servidor de modelo basado en la CFI para la aplicación BIM ciclo de vida
http://www.bimserver.org/
Las herramientas adicionales también se enumeran en la tabla a continuación. Estas herramientas pueden ser aplicables en regiones distintas de los
Estados Unidos y también por los usuarios de los productos de la empresa específica. Por ejemplo, bimServices pueden ser necesarios para su uso en
otras regiones, como el Reino Unido. Como tal, una discusión bimServices está fuera del alcance de esta norma.
Eventualmente herramientas de verificación COBIE estarán incorporados directamente en el software comercial. Estas herramientas permitirían a esos datos
COBIE crean o consumen identificar y corregir los errores que puedan estar presentes en sus datos antes de enviar un archivo determinado. Dos herramientas
(EcoDomusPM, Sistema Onuma) son proporcionados por las compañías de software para pre-check entregables COBIE. Otro ejemplo de una herramienta de
este tipo es uno que se integra directamente la recogida de datos COBIE correctas utilizando el marco de Google-docs basado en la nube. Dado que las
herramientas basadas en productos no se utilizan como la fuente oficial de buildingSMART Alliance® la prueba de provocación, este tipo de herramientas a
nuestra fuera del alcance de esta norma.
Tabla 91 regionales y proveedores Herramientas COBIE
bimServices Comercial - versión la transformación del modelo, verificación y presentación de informes.
gratuita disponible
http://www.aec3.com/en/6/6_04.htm
EcoDomus PM Comercial - Verifica libre COBIE diseño para ofrecer información sobre la construcción de traspaso
http://www.ecodomus.com/index.php/ecodomus-pm/
Sistema Onuma Comercial - Cobie libre archivo corrector
http://www.onuma.com/products/OpsAndCOBieValidate.php

google Docs Comercial - libre de la hoja de cálculo basada en Web para la actualización de datos COBIE
4.2.9 Recursos de implementación
Comentario del autor Editorial: Criterios de recursos de implementación no fueron incluidos en los criterios NBIMS-estadounidense ™ V2. La
información aquí proporcionada es una actualización de lo que se habría presentado tenido esta parte requisito estado de la norma anterior. Sobre la
base de las reglas Criterios NBIMS-estadounidense ™ V3 Técnica de Evaluación Subcomité para los estándares de intercambio de información
revisados, la información proporcionada en esta sección debe considerarse como un cambio moderado.
Lista 4.2.9.1 Recursos de implementación
4.2.9.1.1 guía COBIE
La Guía COBIE (2012c Este) es un marco para los propietarios y los equipos de proyecto para desarrollar una estrategia de aplicación
práctica hacia COBIE. Su función es similar a la de un “comentario” que acompaña a una norma técnica.
Instrucciones proporcionadas en los propietarios Guía de plomo para identificar su específica
requisitos y incluyen tales requisitos directamente en las especificaciones de diseño y construcción.
Cuatro entregables COBIE identificados en la Guía de Cobie. Se requieren dos durante el diseño y dos durante la construcción. Se
requieren prestaciones de diseño en la etapa de 35% y el Proyecto de Ejecución de diseño. Se requieren entregables de construcción en
el Beneficioso de ocupación y de consumación fiscal.
entregables diseño COBIE deben reflejar datos sobre activos programadas identificados en las entregas de diseño asociados. Dado que los activos
programadas aparecen en los dibujos, en los horarios de diseño, la guía COBIE ofrece un requisito mínimo sugerido para los encabezados de tabla
de programación. Los propietarios pueden adoptar estos encabezados de tabla o salir de la definición de las propiedades del producto al equipo de
diseño a su discreción. El único negociable estándar de calidad de datos no COBIE para el diseño archivos Cobie es que los datos de los dibujos
deben coincidir con los datos en el archivo COBIE. entregables construcción COBIE deben reflejar cambios a los activos diseñados e incluyen la
construcción y puesta en servicio de información consistente con la de los planos que el contratista ya que se requiere para producir en formatos
basados en documentos.
Información recibida de muchos equipos ha sido que los propietarios no pueden articular requisitos COBIE lo que la información que se proporciona a los
propietarios de estos es incompleta. Cobie está diseñado para la personalización y es completamente extensible a través de la utilización de las
clasificaciones-propietario específico, conjuntos de propiedades comúnmente requeridas y los requisitos específicos para el espacio y las propiedades
del producto. La Guía COBIE Apéndice A le dice al propietario lo que se debe personalizar en Cobie y les permite documentar sus requisitos.
4.2.9.1.2 Matriz de Responsabilidades COBIE
La Matriz de Responsabilidad COBIE (East 2013) ofrece varios conjuntos de información para ayudar a equipo de proyecto para definir:
• ¿Qué miembros del equipo se requieren para producir datos COBIE?
• ¿Qué información debería hallarse en un archivo COBIE?
• ¿Cómo debe ser formateado esa información?
Específicamente, las secciones de la Matrix COBIE Responsabilidad incluyen:

La responsabilidad del equipo. Puede ser utilizado por equipos de proyecto para asignar la responsabilidad de los diferentes elementos de los datos COBIE
establecidos a diferentes grupos de interés. Sería de esperar que una matriz de este tipo sería útil para aquellos equipos peparaing un plan de implementación
COBIE.
Requisitos entregable. Proporciona una visión del ciclo de vida muy detallado, de qué información se debe entregar COBIE cuando. Esta lista puede
ser utilizada por los equipos y los propietarios del proyecto para determinar el contenido esperado de archivos COBIE en diferentes etapas del proyecto.
Como tal, es una sinopsis de gran parte de la información sobre los requisitos de cambio identificadas previamente en esta norma.
Esquema de hoja de cálculo. Proporciona el esquema para las versiones de hojas de cálculo y IFC 2x3 de los mismos datos COBIE
permitiendo el mapeo entre estos formatos. Esta lista es una sinopsis de la información COBIE hoja de cálculo y requisitos de
asignación IFC fould otra parte de este estándar.
Tipo activos. Identifica aquellas entidades IFC "tipo" que, con el propósito de Cobie no se consideran "activos administrados". Esto permite el filtrado de
archivos IFC cuando las compañías de software no pueden proporcionar sus propios filtros. Esta lista es una sinopsis de las listas de exclusión MVD
identificados en las secciones anteriores de esta norma.
Los activos de componentes. Identifica aquellas entidades IFC "componentes" que, con el propósito de Cobie no se consideran "activos administrados".
Esto permite el filtrado de archivos IFC cuando las compañías de software no pueden proporcionar sus propios filtros. Esta lista es una sinopsis de las
listas de exclusión MVD identificados en las secciones anteriores de esta norma.
Los conjuntos de propiedades. Identifica la CFI conjuntos de propiedades que deben ser proporcionados como parte del conjunto de datos COBIE. Esto permite el filtrado de
archivos IFC cuando las compañías de software no pueden proporcionar sus propios filtros. Esta lista es una sinopsis de las listas de exclusión MVD identificados en las
secciones anteriores de esta norma.
4.2.9.1.3 Modelo guía fusión
Durante las etapas de diseño que requieren la coordinación de la información de múltiples disciplinas, las decisiones con respecto a la fusión de los datos del
modelo BIM son más complejos que simplemente asegurar que los dibujos hojas están en el orden correcto. Esto se debe a que los archivos de modelo BIM
pueden tener datos similares o coincidentes en muchos archivos diferentes. Ingenuamente la fusión de todos los datos de todos los modelos en un conjunto de
datos COBIE consolidado puede ser problemático ya que los números duplicados de las habitaciones, lámparas, accesorios de plomería y otra información podría
ocurrir.
A petición de los desarrolladores de software que participan en el enero de 2013 buildingSMART Alliance® Desafía a un conjunto completo de reglas
de combinación para todos los objetos, tanto para 2x3 IFC IFC y 4 fueron desarrollados (2012D Este). Según los informes, esta guía fusión modelo fue
utilizado por varios fabricantes de software que participaron en el período enero 2013 buildingSMART Alliance® Challenge.
La filosofía detrás de las reglas de combinación sigue la regla de interpretación de contrato de “la información más detallada es probable que sea más
correcto.” Un ejemplo común de las consecuencias prácticas de esta norma es que el programa de instalación sanitaria que en el modelo de un arquitecto,
desarrolló antes la contratación de un ingeniero de fontanería, muchos no coincida con el diseño más detallado proporcionado por esa consultora fontanería.
Como resultado, los triunfos de datos de modelos de fontanería (para tipos específicos de objetos) se han encontrado datos en el modelo del arquitecto.
4.2.9.1.4 Publicación de los resultados de desafío
La entrega y el uso de estándares de intercambio de información buildingSMART Alliance® puede llevarse a cabo con el software existente que se
utiliza para las actividades de planificación, diseño, construcción y gestión y operaciones de la instalación. El software incluido en el Cobie Medios
y métodos sitio web (Medio 2012a) han trabajado directamente con la buildingSMART Alliance®, a través de un proceso público para probar y
demostrar sus capacidades.
El proporcionada a través de la página que proporcionan al usuario la evaluación más reciente de cada actuación productos. También se
proporcionan guías de configuración y manuales de usuario, basado en el software en el

el tiempo de la prueba. Las páginas de resultados de los sistemas de software también pueden ser comparados directamente mediante la visualización de las pestañas del
navegador por separado.
4.2.9.1.5 formación COBIE
Una variedad de videos gratuitos de formación se proporcionan actualmente para los usuarios potenciales COBIE. Esta formación está disponible en el sitio web principal
COBIE bajo “Cobie Videos.” Entrenamiento adicional es proporcionado directamente por los proveedores de software.
La capacitación también puede estar disponible a través de la Alliance® buildingSMART.
4.2.9.1.6 herramientas de transformación COBIE
Puesto que los datos COBIE se pueden encontrar en una variedad de diferentes formatos, herramientas de transformación se pueden emplear para transformar la
información en un formato dado a la información en un formato que se necesita. La siguiente tabla identifica dos herramientas de transformación. La primera
herramienta, el COBIE ToolKit, está autorizado para su uso en el contexto de NBIMS-estadounidense ™. El COBIE TookKit ha sido probado para reproducir
plenamente toda la información requerida en el Cobie MVD independientemente del formato.
Otro kit de herramientas, bimServices, se ha utilizado en el Reino Unido para apoyar su aplicación a nivel nacional COBIE. Dado que este juego de
herramientas no ha sido probado de usuario o como parte de acontecimientos reto alianza buldingSMART, la discusión de esta herramienta se encuentra
fuera del alcance de esta norma.
Tabla 92 COBIE Herramientas de Transformación
ToolKit COBIE Fuente abierta transformación de modelos, comprobación y presentación de informes de un encargo de la estructura del
producto bimserver.org utilizado en eventos COBIE reto.
bimServices Comercial - versión la transformación del modelo, verificación y presentación de informes.
gratuita disponible
http://www.aec3.com/en/6/6_04.htm
4.2.9.1.7 especificaciones de los contratos de la muestra COBIE
El término “intercambio de información” como el término que se utiliza para proyectos tales como Cobie originó a partir de la frase “se contrajo el intercambio de
información” dentro de la comunidad CFI. Con el fin de garantizar que las dos partes se
intercambiar la información correcta que tiene que haber algún tipo de contrato, ya sea formal o informal, que establece las expectativas e indica quién es
responsable en caso de que algo necesita ser arreglado. Para apoyar la implementación de Cobie una especificación contrato fue creado y ha sido puesto
a disposición a través de un enlace que se encuentra en el sitio web COBIE primaria: http://www.wbdg.org/resources/COBie.php.
En el momento de la presentación de esta norma con las características enunciadas, Guía Fondo Unificado Especificación 01
79 00, “Construcción-Operaciones de intercambio de información de edificios,” se espera que sea ejecutado por el Ejército de los EE.UU., Cuerpo de Ingenieros de los
contratos que comienza el 01-oct-14.
4.2.9.1.8 grupo de LinkedIn
Los medios sociales está siendo contratado como una de las primeras líneas de apoyo para los formatos de intercambio de información buildingSMART
Alliance®. El primer lugar para ir de retroalimentación técnica sobre Cobie es el Grupo COBIE Linked-In

(Http://www.linkedin.com/groups/COBie-2638637/about). Este grupo fuertemente moderado puede ser capaz de ayudar a responder algunas de las preguntas más cortos.
Los miembros de varias compañías han contribuido las actividades de pruebas relacionadas con el tiempo y el apoyo de los proyectos de intercambio de información
buildingSMART Alliance®, y. Estas empresas, que figuran a continuación, también pueden ser capaces de ayudar directamente en sus esfuerzos.
Modelo 4.2.9.1.9 Nacional de Intercambio de Información
El Modelo Nacional de Intercambio de Información (NIEM) es una red de colaboración de las entidades del Gobierno de los Estados a nivel federal, estatal,
tribal y local. punto particular de NIEM de vista es apoyar el gobierno y público para compartir información sobre el mundo para planificar, evaluar y
responder a los desastres artificiales y naturales. La adición de un esquema de intercambio de información NIEM compatible con el conjunto de formatos
para la implementación COBIE proporciona la base para permitir que los de la planificación de desastres, mitigación y respuesta de negocio para acceder a
datos críticos COBIE a su empresa.
análisis de cobertura 4.2.9.2 proceso de negocio
Los procesos de negocio relacionados con la implementación de Cobie cubierto en esta norma se refieren al intercambio de presentaciones completas de
archivos COBIE a la conclusión de los principales hitos del proyecto. Otros flujos de trabajo que no se abordan en esta presentación estándar están contenidas en
la sección de análisis de cobertura de flujo de trabajo.
4.2.9.2.1 cobertura programación arquitectónica
Los requisitos para el uso de Cobie para la programación arquitectónica han sido tan aceptado que una aplicación más específica de Cobie, llamado el
Proyecto de construcción de intercambio de información de programación (BPie), se inició a mediados de 2012 (este 2012b).
El proyecto BPie subsume muchos propietaria anterior y no propietaria
enfoques para capturar e intercambiar información de programación arquitectónica.
4.2.9.2.2 cobertura de diseño arquitectónico
Los interesados producir datos COBIE, de la primera etapa de un diseño que incluye el Arquitecto solamente, en un formato que contiene tanto los activos
programadas y geometría asociada han utilizado extensiones a la definición Fundación de la Industria de Coordinación Clase Modelo Vista, así como Cobie
SpreadsheetML o COBieLite formatos. Las personas interesadas en la producción de la información de los activos COBIE solamente, puede utilizar cualquiera
de los formatos de intercambio de datos COBIE aprobados.
El Alliance® buildingSMART ha proporcionado archivos BIM Común mostrando ejemplos del contenido de los archivos COBIE esperados en esta etapa de un
proyecto (2012a Este).
Mientras que el formato Cobie es fijo para todos los intercambios, el conjunto completo de información que se necesita para ser producido en cualquier
entregable dado debe ser especificada para la que se obtengan. La lista de objetos que se espera sean incluidos en la entrega de arquitectura de diseño,
y los criterios de calidad en la que una prestación de este tipo es para ser juzgado, se proporciona en la Matriz de Responsabilidad y Cobie COBIE guías.
A medida que estos documentos son considerados comentario sobre el uso de Cobie, y no directamente parte de la especificación del formato COBIE sí,
estos documentos no están incluidos en esta norma.
4.2.9.2.3 cobertura diseño coordinado
Las personas interesadas en la producción de datos COBIE, durante cualquier etapa de diseño que incluye tanto los arquitectos e ingenieros consultores, en un
formato que contiene tanto los activos programadas y geometría asociada puede utilizar extensiones a la Fundación de la Industria de Coordinación Clase Modelo de
definición de vista, así como Cobie SpreadsheetML o COBieLite formatos. Las personas interesadas en la producción de la información de los activos COBIE
solamente, puede utilizar cualquiera de los formatos de intercambio de datos COBIE aprobados.

El Alliance® buildingSMART ha proporcionado archivos BIM Común mostrando ejemplos del contenido de los archivos COBIE era de esperar, en la próxima
etapa del proyecto - la etapa de Proyecto de Ejecución (2012a Este). Estos archivos de ejemplo son técnicamente equivalentes a los archivos de datos COBIE
producidos en esta etapa de diseño.
Mientras que el formato Cobie es fijo para todos los intercambios, el conjunto completo de información que se necesita para ser producido en cualquier
entregable dado debe ser especificada para la que se obtengan. La lista de objetos que se espera sean incluidos en la entrega de arquitectura de diseño,
y los criterios de calidad en la que una prestación de este tipo es para ser juzgado, se proporciona en la Matriz de Responsabilidad y Cobie COBIE guías.
A medida que estos documentos son considerados comentario sobre el uso de Cobie, y no directamente parte de la especificación del formato COBIE sí,
estos documentos no están incluidos en esta norma.
Otra importante guía para respaldar los proveedores de software en el período enero 2013 buildingSMART Alliance® Desafío evento fue un
documento que identifica el orden de precedencia de objetos en distintos modelos de diseño y consultoría. Esta guía ha sido creada a petición
directa de los proveedores de software. Como este documento debe considerarse como un comentario sobre el uso de Cobie, dentro de un modelo
de servidor o software modelo de fusión, y no directamente parte de la especificación del formato COBIE sí mismo, este documento no se incluyó en
esta norma.
La información proporcionada por el software de los propios proveedores, para el uso de sus propios clientes, ha comenzado a abordar la variedad de
flujos de trabajo que existen en el diseño y consultorías. Además del “problema de fusiones”
observado una sección anterior, el problema del desarrollo de la programación de equipos se ha enviado directamente por los proveedores de software.
Este problema se produce cuando los horarios de productos y equipos que se encuentran en planos del contrato
no fueron creados a partir de datos sobre los objetos BIM, pero pegado a partir de otra fuente. Como tales documentos pueden contener información
propietaria que es de interés sólo para los usuarios de software específico, y no directamente parte de la especificación del formato COBIE sí mismo,
este documento no se incluyó en esta norma.
4.2.9.2.4 Documentos de Construcción Cobertura
Las personas interesadas en la producción de datos COBIE, durante cualquier etapa de diseño que incluye tanto los arquitectos e ingenieros consultores, en un
formato que contiene tanto los activos programadas y geometría asociada puede utilizar extensiones a la Fundación de la Industria de Coordinación Clase Modelo de
definición de vista, así como Cobie SpreadsheetML o COBieLite formatos. Las personas interesadas en la producción de la información de los activos COBIE
solamente, puede utilizar cualquiera de los formatos de intercambio de datos COBIE aprobados.
El entregable de la construcción documentos- datos etapa COBIE sigue el mismo procedimiento utilizado para cualquier Coordinado Diseño
Deliverable.
El Alliance® buildingSMART ha proporcionado archivos BIM común que muestran ejemplos del contenido de los archivos COBIE en esta etapa de un proyecto
(2012a Este).
4.2.9.2.5 cobertura de la puesta en marcha de la construcción
Los que producen los datos COBIE, durante la etapa de puesta en marcha tienen, los datos de los documentos de construcción de escenarios COBIE importados, en el
formato SpreadsheetML, y luego se exportan los datos actualizados COBIE, de nuevo en formato COBieLite SpreadsheetML o. Dado que este es provisional, y es probable
que un contratista puede entregar interna, los criterios de calidad específicos para este tipo de software se desarrolla sobre la base de entrevistas con la puesta en marcha
proveedores de software que operan en este nicho de mercado.
El Alliance® buildingSMART ha proporcionado archivos BIM común en la etapa de documentos de construcción que se utilizan como el archivo de importación
muestra (2012a Este).
4.2.9.2.6 cobertura de traspaso de construcción

Los que producen los datos COBIE, en la fase de entrega tienen, los datos de los documentos de construcción de escenarios COBIE importados, en el
formato SpreadsheetML o COBieLite, y luego se exportan los datos actualizados COBIE, de nuevo en formato COBieLite SpreadsheetML o. Flujos de
trabajo para los procesos de construcción incluidos en estos sistemas de software propietario no se evalúan durante el proceso Alliance® Desafío
buildingSMART.
El Alliance® buildingSMART ha proporcionado archivos BIM común en la etapa de documentos de construcción que se utilizan como el archivo de importación
muestra (2012a Este). Además, los archivos de muestra son ejemplo de construcción de traspaso
proporcionado para ayudar en la evaluación de la integridad y calidad del conjunto de datos de construcción de traspaso.
4.2.9.2.7 Fondo para la cobertura de la puesta en marcha
Esos datos COBIE consumen con fines de gestión de activos no necesita mantenimiento o ha sido realizada a partir de datos en formatos COBIE
SpreadseheetML, COBieLite, y de la CFI. Debido a las diferencias en los sistemas sin mantenimiento instalaciones y de gestión de activos de software
específicos, los criterios de calidad específicos para este tipo de software se desarrolla en base a entrevistas con los proveedores de sistemas de software que
operan en este mercado.
El Alliance® buildingSMART ha proporcionado archivos BIM común en la etapa de construcción de traspaso que se utiliza como el archivo de importación
muestra (2012a Este).
4.2.9.2.8 Captura de la cobertura de la información como una función de
La creación de información conforme a obra la construcción de utilizar COBIE como plantilla de entrada de datos es también un flujo de trabajo que se ha demostrado.
En este flujo de trabajo de un despegue manual de espacios y horarios de equipos principales es
logrado antes de la visita in situ. Durante una visita in situ placa de características específicas y datos espaciales requeridos se pueden recoger directamente en
la versión de hoja de cálculo de Cobie. En lugar de depender de los sistemas de datos en toda la empresa se fusionan información recogida se puede lograr
simplemente mediante un corte y pegado de la información recogida de cada encuesta utilizando el formato COBIE SpreadsheetML.
4.2.9.3 análisis de cobertura de flujo de trabajo relacionada
Los flujos de trabajo apoyados por el intercambio de archivos enteros COBIE son sólo una parte de todo el conjunto de flujos de trabajo que se refieren a la información de
activos instalación. El conjunto completo de los flujos de trabajo se puede encontrar en la sección Modelo de Procesos de Negocio de esta presentación estándar. Los flujos
de trabajo que han sido incluidos y probados con respecto a COBIE
2.4 son los flujos de trabajo mínimos esenciales para incluir como prestaciones contractuales en los contratos de diseño y construcción. Esto se
debe a que estos flujos de trabajo representan resultados específicos hito contrato pagados. Por lo tanto, el uso de Cobie para estos entregables
hito refleja la práctica actual, y el marco contractual, en los contratos de diseño y construcción.
Los párrafos siguientes describen los flujos de trabajo que utilizan la totalidad o parte de los datos COBIE para diferentes fines distintos de la captura de
información de edificios activo en los principales hitos del proyecto. Si bien estos flujos de trabajo comparten conjuntos significativos de la misma información
que COBIE, que no son compatibles únicamente por el formato COBIE 2.4 debido a dos razones principales. La primera razón es que existen diferencias entre
los intercambios de información y Cobie los observados en estos procesos. Algunos de estos flujos de trabajo requieren especificación adicional de Cobie datos
de atributos, otros de estos flujos de trabajo utilizan datos COBIE en contextos distintos de las operaciones de diseño, la construcción y las instalaciones. La
segunda razón es que muchos de estos procesos requieren datos COBIE persistentes que podrían ser una función de un modelo de servidor o base de datos.
Como Cobie es un formato de intercambio de información, y no un sistema de software o una base de datos, estos flujos de trabajo pueden ser soportadas por,
pero no se incluyen como requisitos para esta presentación estándar.
Algunos de estos flujos de trabajo tienen sus propios proyectos Alliance® buildingSMART, otros no. Eventualmente, se esperaría que cada uno de estos
proyectos tiene una especificación de intercambio de información de su cuenta.

4.2.9.3.1 Características del producto
Muchos flujos de trabajo requieren información específica acerca de las propiedades del producto y equipo. Mientras COBIE tiene un lugar para tal
información, COBie.Type, COBie.Component y COBie.Attribute, Cobie La especificación, en sí, no obliga a propiedades específicas para los diferentes
tipos de productos. La especificación de las propiedades del producto se ha creado como un proyecto separado llamado el intercambio de información
Propiedades especificadores (SPIE, pronunciado Spy) proyecto. La razón de que Cobie y SPIE se dividieron en dos proyectos es que el esfuerzo SPIE en
última instancia, requiere la participación de muchas empresas, asociaciones y fabricantes que no son actualmente miembros de la Alliance®
buildingSMART. Cuando esas firmas están listos con los conjuntos de datos SPIE, su información puede ser intercambiada de seguridad utilizando el
formato de datos COBIE que ya existe.
4.2.9.3.2 Los datos de transacciones
Los esfuerzos en Cobie anteriores a esta presentación estándar han interesado los intercambios de grupos completos de información de
instalación en un archivo con formato completo COBIE. Hay muchos tipos de intercambios, sin embargo, donde el intercambio de todo el
intercambio de archivos COBIE no sería útil. Un ejemplo de este tipo de intercambio es la identificación de un diseñador de propiedades de
tipo Producto a base de un producto utilizado como una “base de diseño.” Un ejemplo de tal intercambio, durante la construcción, es la
captura de información de instalación del equipo usando un dispositivo móvil. En ambos ejemplos no sería eficaz para el intercambio de todo
el conjunto de datos COBIE, cuando sólo una parte de los datos COBIE debería ser suficiente.
4.2.9.3.3 existentes encuestas de inventario instalación
A menudo se requieren los administradores de instalaciones estudio sobre sus instalaciones para identificar alguna una clase específica de activo o identificar las
propiedades asociadas con los activos de las instalaciones. Cobie puede ser utilizado como un formato coherente para capturar dicha información. los activos existentes y
las propiedades asociadas podrían ser exportados para los que realizan la encuesta. El personal que realice la encuesta podrían añadir, actualizar o borrar la información
necesaria para hacer que el conjunto de datos actual. Este conjunto de datos actualizada podría entonces ser unido desde todos los inspectores y también incluido de nuevo
en el repositorio central de gestión de activos.
4.2.9.3.4 Operaciones y el historial de mantenimiento
Un interés expresado por las compañías de software que proporcionan las herramientas de mantenimiento y gestión de activos es el uso potencial de Cobie para las operaciones de
las instalaciones y el historial de mantenimiento. Cobie ayuda en la instalación de puesta en marcha, proporcionando una instantánea de la información correcta instalación como
incorporado. Cobie no se ocupa de los flujos de trabajo necesarios para hospitalaria de activos y por los administradores para intercambiar información histórica después de años de
funcionamiento de las instalaciones. Es posible que las ampliaciones de la hoja de trabajo de empleo de Cobie y estructuras de datos equivalentes, se podrían crear para apoyar
estas extensiones.
4.2.9.3.5 El mantenimiento de los datos COBIE operado como-
La cuestión de cómo actualizar los datos COBIE durante la fase de operación y mantenimiento de un proyecto es una pregunta que surge con
frecuencia en la discusión de Cobie. El objetivo en el desarrollo de Cobie era crear un sustituto eficiente para entregar la construcción de papel de
traspaso. Los casos de negocio asociados con el mantenimiento de la información una vez entregados al mantenimiento de las instalaciones,
operaciones y oficinas de gestión de activos se considera que están en manos de los sistemas de software comerciales que se utilizan para estos fines.
Si un proyecto buildingSMART Alliance® considerara el futuro desarrollo de un estándar abierto para el intercambio de dicha información a
continuación, hay tres flujos de trabajo donde los datos COBIE deben ser leídas, actualizado o cambiado durante la fase de explotación de una
instalación. Cada uno de estos casos se describe a continuación.

El primer caso se refiere a menudo como una llamada de servicio. Estas llamadas no cambian la información en absoluto, sino solamente usan la información
proporcionada. Un ejemplo de una llamada de este tipo sería cambiar un filtro. Puesto que el equipo gestionado más importante se debe tocar al menos una
vez al año, la captura de datos COBIE como parte de esa llamada de servicio podría dar, dentro de un año o año y medio, de la captura de todo el equipo
principal en una instalación.
El segundo caso se refiere a menudo como una orden de trabajo. Estos trabajos reemplazar una pieza de equipo con otro. La localización del
equipo no cambia sólo los atributos tales como fabricante, modelo, número de serie, y el cambio de atributos de datos.
En este caso la captura de datos COBIE podría ser un requisito necesario antes de la
finalización de la orden de trabajo.
El tercer caso se refiere a menudo como una renovación de las instalaciones. En esta situación, alguien tiene que hacer un dibujo en cuyo caso COBIE datos
que se retira de una base de datos subyacente puede ser marcado, y los nuevos datos proporcionados COBIE.
4.2.9.3.6 gestión de energía
Un área emergente de interés en los datos COBIE por varias organizaciones y personas fuera de la Alliance® buildingSMART se refiere al área de la gestión de
la energía. flujos de trabajo relacionadas con la gestión de la energía no se incluyeron en Cobie. La capacidad de Cobie para proporcionar información
compartida estructurado que puede ser utilizado por los administradores de energía sin recordando que la información ha sido objeto de muchas
conversaciones con las personas que trabajan en ese espacio. El desarrollo que parece haber participado muchos en que la comunidad es el desarrollo del
esquema COBieLite. COBieLite permite a los programadores interesados en la determinación de la información sobre los edificios que no tenga que participar
una representación geométrica detallada, pero el tratamiento de los datos COBIE como otro tipo de datos necesarios por los programadores de software.
4.2.10 planes de revisión
Comentario del autor Editorial: Criterios para la planificación de revisión no se incluyeron en criterios NBIMS-estadounidense ™ V2. La información aquí
proporcionada es una actualización de lo que se habría presentado tenido esta parte requisito estado de la norma anterior. Sobre la base de las reglas Criterios
NBIMS-estadounidense ™ V3 Técnica de Evaluación Subcomité para los estándares de intercambio de información revisados, la información proporcionada en
esta sección debe considerarse como un cambio moderado.
4.2.10.1 lista de planes de revisión
4.2.10.1.1 proceso de gestión de Revisión
Desde su comienzo, COBIE se ha desarrollado el uso de “modelo de desarrollo en espiral.” El modelo de desarrollo en espiral se caracteriza por un
proceso de creación rápida de prototipos y la retroalimentación. Durante cada ciclo de desarrollo, se introducen mejoras e implementados en el software.
Desde la primera versión de Cobie v1.0 en 2007, este modelo de desarrollo en espiral se encuentra ahora en la versión de Cobie, 2.4, que está
representado en esta norma.
Reciente iteraciones de Cobie comenzó con la discusión de la evolución técnica durante las reuniones con los participantes reto
buildingSMART Alliance®. Durante esta reunión los cambios solicitados por el usuario
comunidad, a través de solicitud directa al buildingSMART Alliance® oa través de LinkedIn, se consideran. En
Además, los cambios solicitados por los desarrolladores de software a sí mismos se discuten. Todos los cambios son
documentada en cuestión de minutos de reuniones Challenge y se utiliza para proponer cambios para futuras versiones COBIE. Durante los acontecimientos reto
proveedores de software pueden, a su discreción, probar los cambios acordados. Si el consenso de los desarrolladores de software de acuerdo con estos cambios,
entonces la próxima versión de la norma se actualiza y documentado para la siguiente ronda de revisiones NBIMS-estadounidense ™.
Se espera que las “manos a la obra” proceso de gestión de la revisión descrita anteriormente a ser necesario en el inicio de prácticamente todas las normas de intercambio
de información NBIMS-estadounidense ™. Una vez que la norma sea bien establecido, sin embargo, el

nivel de intensidad del trabajo requerido para un “manos a la obra” proceso de gestión de este tipo de revisión no se espera que sea requerido. A tal fin, los
Comités de Proyecto COBIE se puede formar a sistematizar la gestión de revisión COBIE.
El CMMS / CAFM Grupo de Proyecto COBIE se formó en agosto de 2013 para ayudar a los proveedores de CMMS / CAFM ampliar y desarrollar el modelo
COBIE de zonas situadas fuera de diseño y construcción adicional. La importación de datos COBIE construcción de traspaso establece en el software CMMS /
CAFM está bien establecida.
La construcción Grupo de Proyecto COBIE se formará el primer trimestre de 2014 para ayudar a los proveedores de la etapa de construcción y puesta en
marcha (C & C) además extender y desarrollar el modelo COBIE para flujos de trabajo más detalladas de la construcción. software de C & C se utiliza para
importar datos de diseño COBIE, actualizar esos datos con la información recopilada durante la construcción, y exportar esos datos en Cobie conjuntos de datos
de construcción de traspaso. Este proceso de importación, actualización y exportar datos COBIE para C & C está bien establecida.
se están formando los grupos de proyecto COBIE para apoyar las funciones siguientes:
• Identificación de Lugares para presentaciones COBIE
• Lugar coordinación con los organizadores y oradores
• Desarrollo de Cobie Actualizaciones estándar basado en el consenso
• La coordinación de la verificación COBIE y pruebas de validación, por ejemplo, Cobie Desafíos
Las cartas de cada uno de los grupos de proyecto COBIE cubrirán los aspectos específicos de la gestión de la revisión de su comunidad, y otros que
proporcionan datos o Cobie entrega durante la vida del proyecto.
4.2.10.1.2 notificación de gestión de revisión
Hasta la fecha, las notificaciones de cambios públicas se han publicado en la COBIE Grupo LinkedIn y página de notificación de revisión COBIE
buildingSMART Alliance®. Un ejemplo de las notificaciones de revisión entre la versión NBIMS-estadounidense ™ V2 COBIE 2.26 y la versión
NBIMS-estadounidense ™ V3 COBIE 2.4 se puede encontrar la página de actualización 2.4 Versión COBIE (Nisbet 2012).
4.2.10.2 métodos de implementación propuesta de revisión
4.2.10.2.1 proceso de implementación de revisiones
El despliegue de las revisiones a COBIE se produce a través de varios mecanismos. En primer lugar, a través del software que implementa las revisiones. Este
software ha sido probado a continuación, como parte de los procesos reto buildingSMART un oficial Alliance®. Los resultados de rendimiento del software en
contra de la línea de base a cualquier nuevas revisiones se documentan a través de la buildingSMART Alliance® Medios y métodos Página (East 2013).
Paralelamente a la implementación de software es la documentación de los cambios exactos a la norma que se han desplegado. Los cambios de
línea de base a la norma se documentan y se distribuyen a todos los sistemas de software que participan en el Desafío Alliance® buildingSMART.
Puesto que tales cambios pueden tener leve, pero importante, las variaciones en los sistemas de software individuales documentación adicional,
llamada la Matriz de Responsabilidades COBIE, se publica también como parte del reto. Una vez que el reto ha sido completa, se libera la Matriz de
Responsabilidad COBIE actualizada a través de la página web COBIE.
Paralelamente a las actividades anteriores software de detección de Cobie, llamado el Kit de herramientas COBIE, se actualiza para permitir que los resultados de la
Challenge COBIE a ensayar. Una vez que el reto ha sido completa, se libera el Kit de herramientas COBIE actualizada a través de la página web COBIE.

Para apoyar el ensayo de los nuevos archivos de pruebas de revisiones, en base a la buildingSMART Alliance® archivos BIM Común, se crean.
Estos archivos muestran los cambios con el proyecto se utiliza como base para las pruebas durante el evento Reto.
4.2.10.2.2 notificación despliegue de revisión
Hasta la fecha, todas las actualizaciones COBIE se han presentado en el evento buildingSMART Alliance® Challenge. UN
presentación que incluye la discusión de estos cambios se incluye en las actas del congreso. La presentación está disponible después de la
reunión como parte de los procedimientos. guía de software sobre los efectos del cambio puede tener sobre el uso de software comercial
específico es la responsabilidad del proveedor de software. La información relativa a la aplicación de proveedor de Cobie está catalogado en
los medios y métodos página COBIE (East 2013).
Bibliografía
CSS-1, Cascading Style Sheets, nivel 1 - Recomendación del W3C
Este, E (2007) “el intercambio de información de construcción Edificio de Operaciones (Cobie): Requisitos y Definición Estándar Centro piloto,”
Ejército de los EE.UU., Ingeniero Centro de Investigación y Desarrollo, Laboratorio de Investigación de Ingeniería de la Construcción, Informe
Técnico TR-07-30. http://www.wbdg.org/pdfs/erdc_cerl_tr0730.pdf (citado 17-Jun-13)
Medio., E, Amor, D., Nisbet, N. (2010) “intercambio de información del ciclo de vida,” Actas de la 27ª Conferencia Internacional de GT
078, CIB. http://projects.buildingsmartalliance.org/files/?artifact_id=3448 (citado 17-Jun-13)
Este, E., Amor, D. (2011) “Análisis de valor añadido del proceso de construcción de Presentación,” Automatización en construcción, Elsevier,
20 (2011), pp. 1070-1078.
http://www.sciencedirect.com/science/article/pii/S0926580511000574 (citado 17-Jun-13)
Este, E. (2012) (2012a) “Datos de la construcción Modelo común de archivos y herramientas”, Instituto Nacional de Ciencias de la Construcción,
buildingSMART Alliance®, http://www.nibs.org/?page=bsa_commonbimfiles (citada 17- Jun- 13)
Este, E. (2012b) “Edificio Programación intercambio de información”, Instituto Nacional de Ciencias de la Construcción, buildingSMART
Alliance®, http://www.nibs.org/?page=bsa_bpie (citado 17-Jun-13)
Este, E (2012c) “La Guía de Cobie: Un Comentario al COBIE ™ estándar NBIMS por Estados Unidos,”
http://projects.buildingsmartalliance.org/files/?artifact_id=5879 (citado 18-Jun-13)
Medio (2012D) “Cobie Modelo lógica de las normas”

http://projects.buildingsmartalliance.org/files/?artifact_id=4705 (citado 23-Sep-13)
Este, E. (2013) “buildingSMART Alliance® intercambios de información: Medios y métodos,”

http://www.nibs.org/?page=bsa_COBiemm (citados 18-Jun-13)
Este, E., et al. (2013b) “Responsabilidad Matrix COBIE”,

http://projects.buildingsmartalliance.org/files/?artifact_id=4093 (citado 23-Sep-13)
Fallon, K., Fadojutimi, O., Williams, G., Crawford, N., Gran, D., (2013) “Evaluación del Ciclo de Vida Intercambios de Información (LCIE): La comprensión
de los beneficios de valor añadido de un proceso COBIE ”Ejército de los EE.UU., Ingeniero Centro de Investigación y Desarrollo, Laboratorio de
Investigación de Ingeniería de la Construcción, Proyecto de Informe Técnico, ERDC / CERL TR-11-PROYECTO.

ISO 639-1, Códigos para la representación de nombres de lenguas - Parte 1: Alfa-2 código
ISO 639-2, Códigos para la representación de nombres de lenguas - Parte 2: Código alfa-3
ISO 639-3, Códigos para la representación de nombres de lenguas - Parte 3: Código Alfa-3 para la amplia
cobertura de idiomas
ISO 6707-1, de construcción y de ingeniería civil - Vocabulario - Parte 1: Condiciones generales
ISO 8601, Elementos de datos y formatos de intercambio - Intercambio de información - Representación de fechas y horas.
ISO 10303-11: 1994, sistemas de integración y automatización industrial - la representación de datos y el intercambio de productos - Parte 1:
Información general y principios fundamentales
ISO 10303-11, Sistemas de automatización industrial e integración - Representación de productos e intercambio de datos - Parte 11:
Métodos Descripción: El Manual de Referencia del lenguaje EXPRESS
ISO 10303-21, Sistemas de automatización industrial e integración - la representación de datos y el intercambio de productos - Parte 21:
Métodos de ejecución: Borrar texto de codificación de la estructura de intercambio
ISO 10303-28, Sistemas de automatización industrial e integración - representación de datos del producto y de cambio - Parte 28:
Métodos de ejecución: representaciones XML de esquemas y datos EXPRESS, utilizando esquemas XML
ISO 10303-41, la representación de datos y el intercambio de productos - integrada de los recursos genéricos - Fundamentos de la
descripción del producto y el apoyo
ISO 10303-42, la representación de datos y el intercambio de productos - Integrado recurso genérico - Representación
geométrica y topológica
ISO 10303-43, la representación de datos y el intercambio de productos - Integrado recurso genérico - estructuras de
representación
ISO 10303-46, la representación de datos y el intercambio de productos - Integrado recurso genérico - Presentación visual
ISO 10303-514, la representación de datos y el intercambio de productos - Aplicación interpretarse construcción - Representación
límite avanzada
ISO 12006-3, la construcción del edificio - Organización de la información acerca de las obras de construcción - Parte 3: Marco de la
información orientada a objetos
ISO / IEC 8824-1, Tecnología de la información - Notación de sintaxis abstracta uno (ASN.1) - Parte 1: Especificación de la notación
básica.
ISO / IEC 14772-1, Tecnología de la información - Gráficos por ordenador y procesamiento de imágenes - La Realidad Virtual
Modeling Language - Parte 1: Especificación funcional y codificación UTF-8
ISO / IEC 19775-1, Tecnología de la información - gráficos por ordenador y procesamiento de imágenes - Extensible 3D (X3D) -
Parte 1: Arquitectura y base componentes

ISO / IEC 81346-12, sistemas industriales, instalaciones y equipos y productos industriales - principios de estructuración y de las
denominaciones de referencia - Parte 12: Edificios y servicios de construcción
ISO / IEC 19757-3: 2006 Tecnología de la información - documento de esquema de lenguaje de definición (dsdl) -
- Parte 3: validación basada en reglas - Schematron
. Nisbet, N., Este, E. (2012) “el intercambio de información de construcción Edificio de Operaciones (Cobie): Versión 2.40 Update,”
buildingSMART Alliance®, http://www.nibs.org/?page=bsa_COBiev24 (citado 18- junio-13)
Parte 2 de esquemas XML, XML Schema Parte 2: Tipos de datos - Recomendación del W3C
RFC 3986, Uniform Resource Identifier (URI): Sintaxis Genérica - Grupo de Trabajo de la Red GTN Estándar
RFC 5646, las etiquetas de identificación de Idiomas - Internet Engineering Task Force IETF Mejores Prácticas actuales 47

Tabla de Figuras
Figura 1 Estudio / Definir las necesidades del proceso Modelo .......................................... .................................................. ........... 53
Figura 2 Desarrollar Diseño Modelo criterios de proceso ........................................... .................................................. .... 54
Figura 3 Estudio de viabilidad técnica Modelo de proceso ........................................... ................................................. 55
Figura 4 comunicar los resultados de decisiones Modelo de proceso ........................................... ........................................ 56
Figura 5 Desarrollo de Programa - ......................................... espacio de proceso Programa Modelo ..................................... 57
Figura 6 Desarrollar Programa - ......................................... Producto Proceso Programa Modelo ................................... 58
Figura 7 Prepare la invitación a hacer una oferta y recibir propuestas (Pre-Diseño) Modelo de proceso .................................. 59 ..
Figura 8 Explora Conceptos - ......................................... Diseño del proceso temprano ......................................... 60
Figura 9 Desarrollar - Diseño Esquema modelo de proceso ......................................... .................................... 61
Figura 10 Desarrollar - Diseño Coordinado modelo de proceso ......................................... ............................... 62
Figura 11 Plantilla del producto Tipo de proceso Modelo ........................................... .................................................. 63 ..
Figura 12 Desarrollo de Diseño - Tipo de producto Proceso Candidato Modelo ........................................ ........................ 64
......................................... diseño del proceso final de modelo - la figura 13 Finalizar Diseño ............................................ sesenta y cinco
Figura 14 Finalizar Diseño - Tipo de producto Proceso Candidato Modelo ........................................ ......................... 66
Figura 15 Prepare la invitación a hacer una oferta y recibir propuestas (Post-Diseño) Modelo de proceso ................................. 67
Figura 16 Respuesta a propuesta previa Modelo Consult Proceso ........................................ ..................................... 68
Figura 17 Desarrollar planes de pre-construcción Modelo de proceso ......................................... ........................................ 69
Figura 18 identificar las discrepancias Modelo de proceso ............................................ .................................................. ... 70
Figura 19 Preparar la información Presentación del producto Selección del tipo de modelo de proceso de ........................................ ...... 71
Figura 20 Sistema de proceso de disposición de Modelo ............................................ .................................................. ............... 72
Figura 21 Organizar Presentación Modelo de Proceso de Información ........................................... ........................................ 73
Figura 22 Realizar revisión de Presentación - Presentación modelo de proceso de emisión ........................................ ....................... 74
Figura 23 proporcionan recursos Modelo de proceso ............................................ .................................................. ........ 75
Figura 24 Ejecutar Actividades de Construcción Modelo de proceso ........................................... ........................................ 76
Figura 25 Producto Proceso de instalación Modelo ............................................ .................................................. ........ 77
Figura 26 Realizar pruebas Process Equipment Modelo ........................................... .............................................. 78
Figura 27 inspeccionar y aprobar Proceso de Trabajo Modelo .......................................... ................................................ 79
Figura 28 definir, registrar y certificar discrepancias Proceso ....................................... Modelo .......................... 80
Figura 29 Closeout Modelo de proceso ............................................. .................................................. ....................... 81
Figura 30 La cobertura de las partes interesadas .............................................. .................................................. .......................... 82
Figura 31 ifcSpace - estructura espacial ............................................ .................................................. .................. 119
Figura 32 ifcSpace - Heights ............................................. .................................................. ............................... 120
Figura 33 ifcBuildingStory - estructura espacial ............................................ .................................................. ....... 123
Figura 34 ifcBuildingStory - Heights ............................................. .................................................. .................... 123
Figura 35 ifcBuilding - estructura espacial ............................................ .................................................. ............... 125
Figura 36 ifcBuilding - Heights ............................................. .................................................. ............................. 126
Figura 37 ifcSite - estructura espacial ............................................ .................................................. ...................... 129
Figura 38 ifcBuilding - Heights ............................................. .................................................. ............................. 130
Figura 39 ifcProcess ............................................... .................................................. .......................................... 145
Figura 40 IfcWorkSchedule ............................................... .................................................. ............................... 155
Figura 41 Conceptos ifcSpace .............................................. .................................................. .............................. 163
Figura 42 Conceptos ifcBuildingStory .............................................. .................................................. .................. 165
Figura 43 Conceptos ifcBuilding .............................................. .................................................. ........................... 166
Figura 44 Conceptos ifcSite .............................................. .................................................. .................................. 167
Figura 45 Conceptos ifcProject .............................................. .................................................. ............................. 169
Figura 46 ifcSystemConcepts ............................................... .................................................. ............................ 170
Figura 47 Conceptos ifcElement .............................................. .................................................. ........................... 171
Figura 48 Conceptos ifcElementType .............................................. .................................................. .................. 172
Figura 49 Conceptos ifcTask .............................................. .................................................. ................................ 173
Figura 50 Conceptos ifcActor .............................................. .................................................. ............................... 174
Figura 51 Conceptos ifcActionRequest .............................................. .................................................. ................ 175
Figura 52 Conceptos ifcProcess .............................................. .................................................. ........................... 176
Figura 53 Conceptos ifcGroup .............................................. .................................................. .............................. 177
Figura 54 ifcPropertySetConcepts ............................................... .................................................. ..................... 177

Figura 55 ifcAnnotationConcepts ............................................... .................................................. ...................... 177

Figura 56 Concepto ifcRelConnectsPort .............................................. .................................................. .............. 178
Figura 57 ifcWorkScheduleConcepts ............................................... .................................................. ................ 178
Figura 58 ifcRelAssociates Documento .............................................. .................................................. ................ 178
Figura 59 Conceptos ifcRelConnectsWithRealizingElement .............................................. .................................. 179
Figura 60 Concepto ifcConstructionProductResource .............................................. ........................................... 179
Figura 61 Concepto ifcConstructionproductResourceType .............................................. .................................... 179
Figura 62 Concepto Identidad - Reglas de Negocio ........................................... .................................................. .......... 204
Figura 63 Concepto de Control de Revisión - Reglas de Negocio .......................................... .............................................. 205
Figura 64 Restricciones de datos externas Concepto - Reglas de Negocio ......................................... ................................. 206
Figura 65 Clasificación Concepto - Reglas de Negocio ........................................... .................................................. . 207
Figura 66 Concepto Espacial Composición - Reglas de Negocio .......................................... ......................................... 207
Figura 67 Las cantidades en concepto Ocurrencias - Reglas de Negocio ......................................... ............................... 208
Figura 68 Conversión de Unidades Concepto - Reglas de Negocio .......................................... ............................................. 208
Figura 69 Proyecto de Declaración Concepto - Reglas de Negocio .......................................... .......................................... 208
Figura 70 Concepto Asignación de grupo - de reglas de negocios .......................................... ........................................... 209
Figura 71 Objeto Typing Concepto - Reglas de Negocio .......................................... .................................................. 210
Figura 72 Concepto-espacial de contención de reglas de negocios .......................................... ......................................... 210
Figura 73 complejos de propiedad de Ocurrencias de reglas de negocios Concepto-........................................ ........................... 211
Figura 74 complejos de propiedad sobre el estándar de Tipos - Reglas de Negocio ........................................ ..................................... 211
Figura 75 Programación de tareas Concepto - Reglas de Negocio .......................................... .............................................. 212
Figura 76 Concepto secuencial de conectividad - Reglas de Negocio .......................................... ................................... 212
Figura 77 Concepto Contacto - Reglas de Negocio ........................................... .................................................. ......... 213
Figura 78 Concepto de Control Asignación - Reglas de Negocio .......................................... ......................................... 213
Tabla de las Tablas
Tabla 1 Caso de Negocio - Office Project ........................................... .................................................. ................... 13

Tabla 2 Business Case - Clínica Médica ........................................... .................................................. .................. 13
Tabla 3 - Negocios Autoridad de Tránsito de la caja ........................................... .................................................. .............. 14
Tabla 4 Análisis de cobertura de las partes interesadas ............................................. .................................................. ............... dieciséis
Tabla 5 Estudio y definir las necesidades Lista de documentos .......................................... .................................................. ...... 82
Tabla 6 Desarrollar criterios de diseño Lista de documentos ........................................... .................................................. ...... 83
Tabla 7 Estudio de Viabilidad Técnica Lista de documentos ........................................... .................................................. . 83
Tabla 8 comunicar los resultados de la Decisión Lista de documentos ........................................... ........................................... 83
Tabla 9 Desarrollar Programa - Programa Espacial Lista de documentos ......................................... ...................................... 83
Tabla 10 Desarrollar Programa - Programa de productos Lista de documentos ......................................... .................................. 83
Tabla 11 Preparar la invitación a hacer una oferta y recepción de propuestas (Pre-Diseño) Lista de documentos .................................. .... 83
Tabla 12 Explorar Conceptos - Diseño Temprano Lista de documentos ......................................... ......................................... 83
Tabla 13 Desarrollar - Diseño esquemático Lista de documentos ......................................... ................................... 83
Tabla 14 Desarrollar - Diseño Coordinado Lista de documentos ......................................... ................................ 84
Tabla 15 Finalizar - Diseño Final de Lista de documentos ......................................... ............................................. 84
Tabla 16 Preparar la invitación a hacer una oferta y recibir propuestas (post Diseño) Lista de documentos ................................... 84
Tabla 17 Respond consultas a propuesta previa lista de documentos ........................................ ....................................... 84
Tabla 18 Desarrollar Pre-Construcción del Plan Lista de documentos ......................................... ............................................ 84
Tabla 19 Lista de documentos identificar las discrepancias ............................................ .................................................. ..... 85
Tabla 20 Preparar la información de Presentación - Tipo de Producto de Selección de Documentos Lista ....................................... ...... 85
Tabla 21 Preparar la información de Presentación - Sistema de Distribución Lista de documentos ........................................ ................... 85
Tabla 22 Organizar envío de información Lista de documentos ........................................... .......................................... 85
Tabla 23 Realizar revisión de Presentación - Edición Presentación Lista de documentos ........................................ ........................ 85
Tabla 24 proporcionan recursos Lista de documentos ............................................ .................................................. .......... 86
Tabla 25 Ejecutar las actividades de construcción Lista de documentos ........................................... .......................................... 86
Tabla 26 Realizar Testing Equipment Lista de documentos ........................................... ................................................ 86
Tabla 27 inspeccionar y aprobar el Trabajo Lista de documentos .......................................... .................................................. 86
Tabla 28 definir, registrar y certificar discrepancias lista de documentos ........................................ ............................ 86
Tabla 29 Lista de documentos de liquidación ............................................. .................................................. ......................... 86

Tabla 30 Clasificación de los intercambios de iniciación ............................................ .................................................. ...... 93

Tabla 31 Clasificación de las Bolsas de Diseño ............................................ .................................................. ........ 94
Tabla 32 Clasificación de las Bolsas de construcción ............................................ ................................................. 94
Tabla 33 Clasificación de los intercambios operativos ............................................ .................................................. . 95
Tabla 34 Cambio de los requisitos de cobertura ............................................. .................................................. ........ 95
Tabla 35 Uso de las coordenadas con Cobie ........................................... .................................................. .............. 104
Tabla 36 Reglas de Negocio - Intercambios de diseño relacionados con ......................................... ........................................... 105
Tabla 37 Reglas de Negocio - Especificaciones de disciplina ........................................... .............................................. 106
Tabla 38 Reglas de Negocio - Definición del proyecto ........................................... .................................................. ........ 106
Tabla 39 Reglas de Negocio - Intercambios tipo de problema .......................................... ................................................. 107
Tabla 40 Reglas de Negocio - Intercambios Tipo de producto .......................................... ............................................. 108
Tabla 41 Reglas de Negocio - Instalación del producto ........................................... .................................................. .... 109
Tabla 42 Reglas de Negocio - O & M Tipo intercambia información ......................................... ................................ 109
Tabla 43 Reglas de Negocio - Producto piezas de repuesto .......................................... .......................................... 110
Tabla 44 Reglas de Negocio - Intercambios espacio post-ocupación ........................................ ................................. 111
Tabla 45 - Mensaje de reglas de negocios ocupación de espacio y intercambios de productos ...................................... ................. 112
Tabla 46 Empresas relacionadas lista de procesos ............................................ .................................................. .............. 115
Tabla 47 Requisito Cambio de reutilización Análisis ............................................ ................................................. 117
Tabla 48 Restricciones de clasificación .............................................. .................................................. .................... 180
Tabla 49 para las restricciones de propiedad establece Ocurrencias ........................................... .............................................. 182
Tabla 50 propiedad establece para este tipo de restricciones ........................................... .................................................. ....... 182
Tabla 51 IfcSpace - Concepto Aplicabilidad ............................................ .................................................. ............ 184
Tabla 52 IfcBuildingStory - Concepto Aplicabilidad ............................................ .................................................. . 184
Tabla 53 IfcBuilding - Concepto Aplicabilidad ............................................ .................................................. ......... 185
Tabla 54 IfcSite - Concepto Aplicabilidad ............................................ .................................................. ................ 185
Tabla 55 IfcProject - Concepto Aplicabilidad ............................................ .................................................. ........... 185
Tabla 56 IfcZone - Concepto Aplicabilidad ............................................ .................................................. .............. 186
Tabla 57 IfcSystem - Concepto Aplicabilidad ............................................ .................................................. .......... 186
Tabla 58 IfcElement - Concepto Aplicabilidad ............................................ .................................................. ......... 187
Tabla 59 IfcElementType - Concepto Aplicabilidad ............................................ .................................................. . 187
Tabla 60 IfcTask - Concepto Aplicabilidad ............................................ .................................................. .............. 188
Tabla 61 IfcActor - Concepto Aplicabilidad ............................................ .................................................. .............. 188
Tabla 62 IfcActionRequest - Concepto Aplicabilidad ............................................ ................................................. 189
Tabla 63 IfcPropertySet - Concepto Aplicabilidad ............................................ .................................................. ... 189
Tabla 64 IfcAnnotation - Concepto Aplicabilidad ............................................ .................................................. ..... 189
Tabla 65 IfcRelConnectsPorts - Concepto Aplicabilidad ............................................ ........................................... 190
Tabla 66 IfcWorkSchedule - Concepto Aplicabilidad ............................................ ................................................. 190
Tabla 67 IfcRelAssociatesDocument - Concepto Aplicabilidad ............................................ ................................. 190
Tabla 68 IfcRelConnectsWithRealizingElements - Concepto Aplicabilidad ............................................ .............. 191
Tabla 69 ifcConstructionProductResource - Concepto Aplicabilidad ............................................ ....................... 191
Tabla 70 ifcConstructionProductResourceType - Concepto Aplicabilidad ............................................ ............... 191
Tabla 71 de necesidad de cambio reutilización Análisis ............................................ ................................................. 192
Tabla 72 Identidad Concepto Lista de reglas de negocios ........................................... .................................................. ....... 192
Tabla 73 Concepto Control de Revisiones Listado de reglas de negocio .......................................... ........................................... 193
Tabla 79 Cantidades de Ocurrencias concepto de negocio Lista de reglas ......................................... ............................ 196
Tabla 80 Conversión de Unidades concepto de negocio Lista de reglas .......................................... .......................................... 197
Tabla 82 Asignación de Grupo Concepto de negocio Lista de reglas .......................................... ........................................ 198
Tabla 83 Objeto Typing concepto de negocio Lista de reglas .......................................... ............................................... 198
Tabla 84 espacial contención Concepto Lista de reglas de negocios .......................................... ..................................... 198
Tabla 87 Programación de tareas Concepto Lista de reglas de negocios .......................................... ........................................... 200
Tabla 92 Asignación de Control concepto de negocio Lista de reglas .......................................... ...................................... 203
Tabla 93 admisibles COBIE MVD Formatos ............................................ .................................................. ............ 214
Tabla 94 COBie_Task dinámico de definición de esquemas ............................................ ............................................... 215
Tabla 95 COBie_ElementType dinámico de definición de esquemas ............................................ ................................. 216
Tabla 96 Pset_ManufacturerOccurrence dinámico de definición de esquemas ............................................ .................. 217
Tabla 97 Pset_ManufacturerTypeInformation dinámico de definición de esquemas ............................................ ........... 217

Tabla 98 Pset_ActionRequest dinámico de definición de esquemas ............................................ ................................... 217

Tabla 99 COBie_ActionRequest dinámico de definición de esquemas ............................................ ............................... 218
Tabla 97 COBie_ConstructionProductResource dinámico de definición de esquemas ............................................ ...... 218
Tabla 103 QC Pruebas - Diseño Cobertura Regla .......................................... .................................................. ..... 229
Tabla 104 de control de calidad de pruebas - Construcción Cobertura Entrega .......................................... ...................................... 230
Herramientas Tabla 106 regionales y Vendor COBIE ........................................... .................................................. ...... 235
Tabla 107 Herramientas COBIE de transformación ............................................. .................................................. .............. 238

Anexo A - Cobie reglas de asignación
Anexo B - el intercambio de información de Ciclo de Vida (LCIE) para el producto y tipo de producto intercambios de datos, un anexo técnico a
Cobie - Verion 2.4


Nbims-Us v3 4.2 Cobie - En.es

Cargado por

Copyright:

Formatos disponibles

Nbims-Us v3 4.2 Cobie - En.es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Nbims-Us v3 4.2 Cobie - En.es

Cargado por

Copyright:

Formatos disponibles

Norma Nacional BIM - Estados Unidos ® La versión 3

4 Las normas de intercambio de información

4.2.1 Alcance .................................................. .................................................. .................................................. ..... 2

4.2.2. Referencias normativas .................................................. .................................................. ....................... 17

4.2.3 Términos y definiciones .................................................. .................................................. .......................... 22

4.2.4 Símbolos y términos abreviados .................................................. .................................................. ........ 45

4.2.5 documentación de procesos de negocios .................................................. .................................................. ...... 47

4.2.6. documentación de necesidad de cambio .................................................. .............................................. 92

4.2.8 procedimientos de pruebas de conformidad .................................................. .................................................. .... 221

4.2.9 Recursos de implementación .................................................. .................................................. ................ 236

4.2.10 planes de revisión .................................................. .................................................. .................................. 243

Bibliografía .................................................. .................................................. .................................................. 245

Tabla de Figuras .................................................. .................................................. ........................................... 248

Anexo A - Cobie reglas de asignación .................................................. .................................................. ............. 252

Cobie - Verion 2.4 .................................................. .................................................. .... 252

Norma Nacional BIM - Estados States® versión 3

4.2.1.1 Caso Descripción de actividad

Lista Fase 4.2.1.1.1 del ciclo de vida

• Estudiar y definir las necesidades

• Desarrollar criterios de diseño

• Estudio de viabilidad técnico

• Comunicar los resultados de la Decisión

• Desarrollar Programa - Programa Espacial

• Desarrollar Programa - Programa de Producto

• Preparar la invitación a hacer una oferta y recepción de propuestas (Pre-Diseño)

• Explora Conceptos - Diseño Temprano

• Desarrollar - Diseño esquemático

• Desarrollar - Diseño Coordinado

• Finalizar Diseño - Diseño Final

• Preparar la invitación a hacer una oferta y recibir propuestas (post Diseño)

• Responder a consultas de propuesta

• Desarrollar el Plan de Pre-Construcción

• identificar las discrepancias

• Preparar información de Presentación - Tipo de producto Selección

• Preparar información de Presentación - Disposición del sistema

• Organizar la información de Presentación

• Realizar revisión de Presentación - Edición Presentación

• Ejecutar las Actividades de Construcción

• Realizar pruebas de Equipo

Norma Nacional BIM - Estados States® versión 3

• Inspeccionar y aprobar el Trabajo

• Definir, registrar y certificar discrepancias

4.2.1.1.1.1 Estudiar y definir las necesidades

• ahorro de reproducción de dependencia de los documentos electrónicos y la eliminación del papel.

Norma Nacional BIM - Estados States® versión 3

4.2.1.1.1.2 Desarrollar criterios de diseño

• ahorro de reproducción de dependencia de los documentos electrónicos y la eliminación del papel.

4.2.1.1.1.3 viabilidad técnica Estudio

• ahorros de reproducción de la dependencia de los documentos electrónicos y la eliminación de papel

4.2.1.1.1.4 comunicar los resultados de las decisiones

• ahorro de reproducción de dependencia de los documentos electrónicos y la eliminación del papel.

4.2.1.1.1.5 Desarrollar un programa - programa espacial

Norma Nacional BIM - Estados States® versión 3

• ahorros de reproducción de la dependencia de los documentos electrónicos y la eliminación de papel

4.2.1.1.1.6 Desarrollar un programa - programa de productos

• ahorros de reproducción de la dependencia de los documentos electrónicos y la eliminación de papel

4.2.1.1.1.7 Preparar llamado a licitación y recibir propuestas (pre-diseño)

4.2.1.1.1.8 Explora conceptos - inicial de diseño

Norma Nacional BIM - Estados States® versión 3