{"title":"Multi-LOD model for describing uncertainty and checking requirements in different design stages","authors":"J. Abualdenien, A. Borrmann","doi":"10.1201/9780429506215-24","DOIUrl":null,"url":null,"abstract":"The design of a building is a collaborative process between multiple disciplines. Using Building Information Modeling (BIM), a model evolves throughout multiple refinement stages to satisfy various design and engineering requirements. Such refinement of geometric and semantic information is described as levels of development (LOD). So far, there is no method to explicitly define an LOD’s requirements nor any specification of its uncertainty. Furthermore, despite the insufficient information available in early design stages, a BIM model appears precise and certain. This can lead to false assumptions and model evaluations, for example, in the case of energy efficiency calculations or structural analysis. Hence, this paper presents a multi-LOD metamodel to explicitly describe an LOD’s requirements taking into consideration the information uncertainty. This makes it possible to check the consistency of the geometric, semantic, and topologic coherence across the different LODs. The model is implemented as a webserver and user-interface providing a means for managing and checking exchange requirements between disciplines. As part of this research group, we propose the development of a multi-LOD meta-model, which explicitly describes the LOD requirements of each individual building component type taking into consideration the possible uncertainties. The multi-LOD meta-model introduces two layers, data-model level and instance level, which offers high flexibility in defining per-project LOD requirements and facilitates formally checking their validity, such as defining and checking required information to support the Embodied Energy calculations at different design stages. This paper discusses the advantages in representing the uncertainties at early design stages and highlights the benefits of systematically managing and checking exchange requirements between disciplines. In order to ensure the model’s flexibility and applicability, its realization is based on the existing Industry Foundation Classes (IFC). IFC is an ISO standard, which is integrated into a variety of software products (Liebich et al. 2013). The paper is organized as follows: Section 2 discusses the background and related work of our research. Section 3 provides an overview of the multiLOD requirements and describes the design concepts, and Section 4 presents the meta-model design. In order to evaluate the multi-LOD model, Section 5 illustrates how it can be used to define and check the requirements of the Embodied Energy calculations, and a prototype implementation is discussed in Section 6 in terms of usability and possible integration in the design process. Finally, Section 7 summarizes our progress hitherto and presents an outlook for future work. 2 BACKGROUND & RELATED WORK 2.1 Level of Development (LOD) The concept of LOD is employed to manage the model evolvement through the different stages of the building life-cycle. It organizes the iterative nature of the design process which enhances the quality of the decision taken (Hooper 2015). An LOD describes the BIM elements on a particular stage providing definitions and illustrations (BIMForum 2017) which represents their information quality, i.e. certainty and completeness. The LOD scale increases iteratively from a coarse level of development to a finer one. Consequently, the associated characteristics’ quality of the exchanged model elements is increased. The American Institute of Architects (AIA) introduced a definition of the term LOD that comprises six levels, starting from LOD 100 reaching LOD 500. Additionally, it adds more flexibility by defining intermediate stages, like LOD 350 which requires the representation of the interfaces between the different building system (BIMForum 2017). Several guidelines have been proposed in an attempt to define the available information at each LOD. Most popularly, Level of Development Specification follows the AIA definitions, and Level of Definition in the UK (BSI 2017) consists of seven levels and introduces two components: Levels of model detail (LOD) representing the graphical content of the models, and Levels of model information (LOI) representing the semantic information. Recent approaches propagate the terms Level of Information and Level of Geometry to clearly distinguish semantic from geometric detailing grades (Hausknecht, Liebich 2017). In this paper, the abbreviation LOD stands for the Level of Development, which represents the composition of both Level of Geometry (a.k.a. Level of Detail) and Level of Information (semantics). 2.2 Refinement of LODs Multiple efforts have been conducted for describing the LODs refinement through the project life-cycle. The main idea is the attempt to represent and formalize the model maturity. Either by explicitly defining relationships or by controlling the amount of added details within an LOD, which makes it possible to check the model’s consistency. (Biljecki et al. 2016) argue that five LODs are not enough to capture the building model’s development, as the information ambiguity is high. Thus, they restrict the LODs refinement by allowing less specification and modelling freedom using a set of 16 stages. Similarly, (van Berlo, Bomhof 2014) looked into producing a more suitably refined set of LODs for the Dutch’s AEC industry, they developed seven LODs after performing multiple geometric tests and analyzing the industrial practices. From another perspective, (Borrmann et al. 2014) presents a methodology for creating and storing multi-scale geometric models for shield tunnels by explicitly defining the dependencies between the individual levels of detail. For this purpose, a multiscale product model is developed including a geometric-semantic description of five levels; where the levels 1-3 describe the outer shell in terms of boundary representation of the tunnel volume, boundary surface as well as openings, and the fourth level includes the modeling of the tunnel’s interior structure. It is shown how the LOD concept can be integrated into the IFC data model. In order to model the relationship between the different levels and maintain their aggregation, a new relationship class IsRefinedBy, a subclass of Aggregates, is introduced. The proposed multiscale model makes use of the parametric modeling techniques to preserve the consistency among the different levels of detail by interpreting and processing the procedural geometry representations. Consequently, the change of a geometric object is propagated by updating all the dependent representations. In this paper, we adhere the BIMForum’s definition, starting from LOD 100 reaching to LOD 500, while making use of its flexibility by introducing intermediate LODs, including LOD 120 and LOD 250, to capture the refinement relationships of the semantic-geometric information. 2.3 Interoperability The design and construction of a building is a collaborative process between multiple disciplines, each expert, such as architect and structural engineer, uses different authoring tool and requires custom specifications to support a particular type of simulations and analysis. With increasing the projects specialization and heterogeneity, the building industry requires a high level of interoperability. The US national institute of standards and technology confirmed the high annual costs, around $16 billion, resulting from the lack of interoperability between the AEC industry software systems (GCR 2004). Over the last decade, numerous methods of exchanging data in the domain of AEC have been investigated. The aim is to define a common interface for lossless geometric as well as semantic data exchange. Therefore, buildingSMART is promoting the development of the industry standard, Industry Foundation Classes (IFC) which was published as ISO standard in 2003 (Liebich 2013). IFC is a free vendor-neutral standard and includes a large set of building information representations, including a variety of different geometry representations and a large set of semantic objects modeled in a strictly object-oriented manner. To allow for dynamic (schema-invariant) extensions and adaptation to local or national requirements, the IFC data model provides the PropertySet (PSet) mechanism, which relies on dynamically definable name-value pairs. Besides exchanging data using IFC, dealing with different kinds of building information, e.g. property sets and definitions, requires a standardized terminology. Thus, the buildingSmart Data Dictionary (bsDD) (buildingSMART 2016) was developed as a central repository that stores multilingual definitions of the IFC entities and common schema extensions, for instance, an IfcWall entity description and Pset_WallCommon. Additionally, bsDD integrates multiple classification systems, including OMNICLASS (OmniClass 2012) and UNICLASS (Chapman 2013), which are widely adopted for structuring the building information. Each object in the dictionary is identified by a Globally Unique ID (GUID) which makes it computer-readable and independent of the object name and language (Bjorkhaug, Bell 2007). As the IFC data model is too large for authoring tools to handle (Bazjanac 2008), buildingSMART developed the Model View Definition (MVD) mechanism as a standard approach for IFC implementation, which reduce the size of models through filtering. An MVD represents a subset of the IFC schema that specifies the requirements and specifications of the exchanged data between the authoring tools (Hietanen, Final 2006). In order to ensure the exchanged data completeness, the required information for each discipline scenario needs to be documented and defined as computer-executable rules (Yang, Eastman 2007). Hence, MVD and its open standard mvdXML (Chipman et al. 2012) can be used to structure the exchange requirements with specific IFC types, entities, attributes (Karlshøj et al. 2012). So far, the IFC model supports neither the notion of LOD, nor a description of its uncert","PeriodicalId":193683,"journal":{"name":"eWork and eBusiness in Architecture, Engineering and Construction","volume":"1 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2018-09-03","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"12","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"eWork and eBusiness in Architecture, Engineering and Construction","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1201/9780429506215-24","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 12
Abstract
The design of a building is a collaborative process between multiple disciplines. Using Building Information Modeling (BIM), a model evolves throughout multiple refinement stages to satisfy various design and engineering requirements. Such refinement of geometric and semantic information is described as levels of development (LOD). So far, there is no method to explicitly define an LOD’s requirements nor any specification of its uncertainty. Furthermore, despite the insufficient information available in early design stages, a BIM model appears precise and certain. This can lead to false assumptions and model evaluations, for example, in the case of energy efficiency calculations or structural analysis. Hence, this paper presents a multi-LOD metamodel to explicitly describe an LOD’s requirements taking into consideration the information uncertainty. This makes it possible to check the consistency of the geometric, semantic, and topologic coherence across the different LODs. The model is implemented as a webserver and user-interface providing a means for managing and checking exchange requirements between disciplines. As part of this research group, we propose the development of a multi-LOD meta-model, which explicitly describes the LOD requirements of each individual building component type taking into consideration the possible uncertainties. The multi-LOD meta-model introduces two layers, data-model level and instance level, which offers high flexibility in defining per-project LOD requirements and facilitates formally checking their validity, such as defining and checking required information to support the Embodied Energy calculations at different design stages. This paper discusses the advantages in representing the uncertainties at early design stages and highlights the benefits of systematically managing and checking exchange requirements between disciplines. In order to ensure the model’s flexibility and applicability, its realization is based on the existing Industry Foundation Classes (IFC). IFC is an ISO standard, which is integrated into a variety of software products (Liebich et al. 2013). The paper is organized as follows: Section 2 discusses the background and related work of our research. Section 3 provides an overview of the multiLOD requirements and describes the design concepts, and Section 4 presents the meta-model design. In order to evaluate the multi-LOD model, Section 5 illustrates how it can be used to define and check the requirements of the Embodied Energy calculations, and a prototype implementation is discussed in Section 6 in terms of usability and possible integration in the design process. Finally, Section 7 summarizes our progress hitherto and presents an outlook for future work. 2 BACKGROUND & RELATED WORK 2.1 Level of Development (LOD) The concept of LOD is employed to manage the model evolvement through the different stages of the building life-cycle. It organizes the iterative nature of the design process which enhances the quality of the decision taken (Hooper 2015). An LOD describes the BIM elements on a particular stage providing definitions and illustrations (BIMForum 2017) which represents their information quality, i.e. certainty and completeness. The LOD scale increases iteratively from a coarse level of development to a finer one. Consequently, the associated characteristics’ quality of the exchanged model elements is increased. The American Institute of Architects (AIA) introduced a definition of the term LOD that comprises six levels, starting from LOD 100 reaching LOD 500. Additionally, it adds more flexibility by defining intermediate stages, like LOD 350 which requires the representation of the interfaces between the different building system (BIMForum 2017). Several guidelines have been proposed in an attempt to define the available information at each LOD. Most popularly, Level of Development Specification follows the AIA definitions, and Level of Definition in the UK (BSI 2017) consists of seven levels and introduces two components: Levels of model detail (LOD) representing the graphical content of the models, and Levels of model information (LOI) representing the semantic information. Recent approaches propagate the terms Level of Information and Level of Geometry to clearly distinguish semantic from geometric detailing grades (Hausknecht, Liebich 2017). In this paper, the abbreviation LOD stands for the Level of Development, which represents the composition of both Level of Geometry (a.k.a. Level of Detail) and Level of Information (semantics). 2.2 Refinement of LODs Multiple efforts have been conducted for describing the LODs refinement through the project life-cycle. The main idea is the attempt to represent and formalize the model maturity. Either by explicitly defining relationships or by controlling the amount of added details within an LOD, which makes it possible to check the model’s consistency. (Biljecki et al. 2016) argue that five LODs are not enough to capture the building model’s development, as the information ambiguity is high. Thus, they restrict the LODs refinement by allowing less specification and modelling freedom using a set of 16 stages. Similarly, (van Berlo, Bomhof 2014) looked into producing a more suitably refined set of LODs for the Dutch’s AEC industry, they developed seven LODs after performing multiple geometric tests and analyzing the industrial practices. From another perspective, (Borrmann et al. 2014) presents a methodology for creating and storing multi-scale geometric models for shield tunnels by explicitly defining the dependencies between the individual levels of detail. For this purpose, a multiscale product model is developed including a geometric-semantic description of five levels; where the levels 1-3 describe the outer shell in terms of boundary representation of the tunnel volume, boundary surface as well as openings, and the fourth level includes the modeling of the tunnel’s interior structure. It is shown how the LOD concept can be integrated into the IFC data model. In order to model the relationship between the different levels and maintain their aggregation, a new relationship class IsRefinedBy, a subclass of Aggregates, is introduced. The proposed multiscale model makes use of the parametric modeling techniques to preserve the consistency among the different levels of detail by interpreting and processing the procedural geometry representations. Consequently, the change of a geometric object is propagated by updating all the dependent representations. In this paper, we adhere the BIMForum’s definition, starting from LOD 100 reaching to LOD 500, while making use of its flexibility by introducing intermediate LODs, including LOD 120 and LOD 250, to capture the refinement relationships of the semantic-geometric information. 2.3 Interoperability The design and construction of a building is a collaborative process between multiple disciplines, each expert, such as architect and structural engineer, uses different authoring tool and requires custom specifications to support a particular type of simulations and analysis. With increasing the projects specialization and heterogeneity, the building industry requires a high level of interoperability. The US national institute of standards and technology confirmed the high annual costs, around $16 billion, resulting from the lack of interoperability between the AEC industry software systems (GCR 2004). Over the last decade, numerous methods of exchanging data in the domain of AEC have been investigated. The aim is to define a common interface for lossless geometric as well as semantic data exchange. Therefore, buildingSMART is promoting the development of the industry standard, Industry Foundation Classes (IFC) which was published as ISO standard in 2003 (Liebich 2013). IFC is a free vendor-neutral standard and includes a large set of building information representations, including a variety of different geometry representations and a large set of semantic objects modeled in a strictly object-oriented manner. To allow for dynamic (schema-invariant) extensions and adaptation to local or national requirements, the IFC data model provides the PropertySet (PSet) mechanism, which relies on dynamically definable name-value pairs. Besides exchanging data using IFC, dealing with different kinds of building information, e.g. property sets and definitions, requires a standardized terminology. Thus, the buildingSmart Data Dictionary (bsDD) (buildingSMART 2016) was developed as a central repository that stores multilingual definitions of the IFC entities and common schema extensions, for instance, an IfcWall entity description and Pset_WallCommon. Additionally, bsDD integrates multiple classification systems, including OMNICLASS (OmniClass 2012) and UNICLASS (Chapman 2013), which are widely adopted for structuring the building information. Each object in the dictionary is identified by a Globally Unique ID (GUID) which makes it computer-readable and independent of the object name and language (Bjorkhaug, Bell 2007). As the IFC data model is too large for authoring tools to handle (Bazjanac 2008), buildingSMART developed the Model View Definition (MVD) mechanism as a standard approach for IFC implementation, which reduce the size of models through filtering. An MVD represents a subset of the IFC schema that specifies the requirements and specifications of the exchanged data between the authoring tools (Hietanen, Final 2006). In order to ensure the exchanged data completeness, the required information for each discipline scenario needs to be documented and defined as computer-executable rules (Yang, Eastman 2007). Hence, MVD and its open standard mvdXML (Chipman et al. 2012) can be used to structure the exchange requirements with specific IFC types, entities, attributes (Karlshøj et al. 2012). So far, the IFC model supports neither the notion of LOD, nor a description of its uncert