Framework for (semi) automatised construction specification and quantity takeoff in the context of small and medium architectural design offices

BIM-based construction specification and quantity takeoff (QTO) processes have proven faster and more reliable than traditional methods. However, their execution and integration still rely on time-consuming and error-prone manual or semi-automatic interventions to deal with the lack of completeness, suitability and granularity of produced BIM models in design practice, mostly related to elements and activities not digitally represented in these models. In addition, besides the BIM authoring tool, they demand other proprietary platforms to obtain the expected outcomes, leading to interoperability issues and representing an obstacle to small and medium architectural design offices in terms of needed investment and customisations inherent to their business model. This work addresses the problem by proposing a BIM-based framework for automatised coordinated construction specification and quantity takeoff. It encompasses information modelling requirements, establishing a construction specification database and an add-in on the authoring tool that automatically produces joint construction specifications and quantity QTO documentation. The proposed system improves current BIM-based practices by mitigating the number of non-automatised intermediary steps, not requiring any other proprietary BIM platform rather than the authoring tool. Besides, it structures alternative ways of digitally representing elements and activities not graphically expressed in the model, allowing automated, more efficient, faster and cheaper production of coordinated reports of quantities and construction specifications. Two real projects validated the implementation of the framework, as well as the capabilities of the add-in, demonstrating its applicability in practical cases.


Introduction
Typically developed in the design stage, construction specification communicates the expected quality of an element by defining its materials, methods of installation, manufacturing or in-situ execution procedures. Besides, it also details activities demanded by the proposed design encompassing site preparation, demolitions, and existing elements reusing and restoring [1][2][3]. On the other hand, quantity takeoff (QTO) measures the specified construction elements and activities [4][5][6]. Both Specification and QTO in the Architectural, Engineering and Construction (AEC) industry are essential to establish a shared understanding among clients, designers, contractors, and manufacturers about a project. They create a common ground for the project stakeholders regarding what will be built, how, and the costs involved in a particular enterprise during its lifecycle [7,8]. Besides, they are essential for planning and pricing, determining the needed resources for each construction element, system and activity applied in a particular enterprise [4,9].
Building Information Modelling (BIM) has made construction specifications and QTO evolve toward digital processes, proving faster and more accurate than traditional methods [5,10,11]. However, these two BIM uses [12,13] 1 3 lack mutual integration and still require error-prone and time-consuming manual efforts [11] to drive data through a set of activities and processes involving different software applications and formats. These processes are needed to estimate and represent elements or activities that were not modelled or that were modelled under simplifications that do not allow reliable quantity extraction and coordination with the correspondent specification information. They lack standardisation and demand integration subprocesses [14], which treat and cast the outcome data from a previous step to be usable in the next one. Moreover, QTO generated by common BIM software applications cannot be directly manipulated [15], requiring final treatment on complementary applications. Finally, proprietary BIM platforms for specification and QTO require a high initial investment for small and medium-sized project design enterprises (SMEs) [16,17] and are not compliant with the particular needs for customisations inherent to these business models.
The accuracy of the quantities and the scope of measured elements and activities depend entirely on the model's completeness, suitability, and granularity. However, modelling some elements, due to their small physical dimensions, such as a layer of primer, roof fittings, and joint mortar, would require a prohibitive amount of resources. Therefore, the quantities obtained from the BIM model are complemented with elements and activities not represented geometrically in the model in the QTO report. They are estimated manually or semi-automatically by mapping modelled objects' existing parameters into new attributes representing that element or activity within a spreadsheet editor or complementary BIM applications. Besides that, the extracted quantities also need to be coordinated with the construction specification, requiring manual or semi-automatised interventions based on spreadsheet formulas to match a particular element or activity with its corresponding construction specification. Figure 1 provides an overview of existing workflows.
The presented context and consequent issues led to a question: how to re-engineering BIM-based specification and quantity takeoff to increase their integration and degree of automatisation, reducing the number of interactions and platforms involved as well as manual intervention steps to integrate them, resulting in faster and cheaper outcomes in the context of small and medium architectural design offices? This research addresses the problem by proposing an integrated BIM-based framework for automated and coordinated specification and QTO. It mitigates the manual efforts to estimate and specify elements and activities that were not represented in the model, comprising means of assessing and expressing them digitally. Furthermore, it extinguishes the need for data exchange among different platforms and automatically coordinates detailed construction specifications with the quantities extracted from the BIM model. The proposal spun off and relied on the practice of the architectural design office "Marta Campos Atelier de Arquitetura" (MC), based in Porto, Portugal, as an object of study. Even though it is a small-sized company, it already has significant maturity in BIM methodologies and processes, Level 2 according to BIM Maturity Levels Model by Bew and Richards [18].
Besides the state of art surveying, the framework development also leaned on diagnosing and assessing MC's existing workflow for producing BIM-based specifications and QTO. The diagnosis resulted in a detailed mapped process AS-IS (Appendix 1), which comprises intermediary manual efforts to treat and shape data for the sequence of steps processed in Autodesk Revit® and Naviswork® 2020 and Microsoft Excel. In addition, even though Excel is a powerful tool for data analysis, spreadsheets were used as databases, exposing the stored information to corruption risks caused by inappropriate manipulation, to the detriment of using a proper Relational Database Management System (RDMS).

Literature review
BIM-based process efficiency and accuracy for QTO rely on driving the information modelling activities [4,19,20] to ensure a complete, granular and adequate model for the intended purpose. However, in practice, conventional models usually do not meet these requirements. Therefore, BIM-based QTO still depends on manual or semi-automatic efforts to refine the extracted quantities and proceed with downstream analysis and subsequent processes [21]. These non-automated interventions include exchanging data and dealing with elements and activities that were not modelled but needed to be expressed in projects' complementary documentation of quantities and specs [22]. A highly detailed model would minimise these issues. However, it would require potentially unjustifiable resources to model them for designers, representing an obstacle to efficient and accurate QTO [23]. Furthermore, even if the model information presents a high level of detail, some activities that must be measured and specified cannot be represented geometrically. In this sense, it is fundamental to establish alternative ways that allow real practice models to be used as a source for the fully automated process for QTO and construction specifications.
Aware of the limitations regarding the readiness, suitability and granularity of the information contained in the models, Aram et al. [19] proposed a framework for a knowledge-based system to perform model-based QTO and cost estimation. It allowed the inferring of knowledge about different product features, enabling the representation of model information in a compatible format for QTO and cost estimate tasks. Liu et al. [22] tackled conventional model limitations to provide fine-grained information for QTOspecific purposes based on the standard method of measurement (SMM) by proposing a knowledge model-based BIM framework for automatic code-compliant quantity takeoff. Their framework comprises the processing of modelled and non-modelled elements, combining the establishment of modelling requirements and inferring methods for structural elements. Monteiro and Poças [4] surveyed modelling practices that drive the information to perform QTO, demonstrating that even though automatic quantity extraction is a reality through BIM, the process is not straightforward, requiring oriented modelling and takeoff rules. In addition, they concluded that BIM-based workflows for QTO demand other BIM platforms, besides the authoring tools, to manage and process quantity information, leading to interoperability issues. Sampaio et al. point out the lack of BIM-based standards for quantity extraction as a practical obstacle for the QTO [24]. Clark and Alzraiee [25] proposed a framework focused on cost estimation that relies on BIM object parameters to represent non-modelled elements, using the objects that secure them as a source for reading quantities. Furthermore, Zima and Olsen et al. [11,20] demonstrate the importance of driving specification and geometry information modelling procedures to achieve an accurate and reliable Bill of Quantities. Finally, Khosakitchalert et al. [5,6] approach the same topic by focusing on compound elements and develop two methods for improving the accuracy of BIM-based QTO, proposing a framework to deal with object overlaps and a tool that performs the separation of compound elements layers into independent entities automatically.
Software vendors also have developed BIM-based platforms focused on QTO, such as iTWO CostX®, Autodesk Navisworks, ACCA Primus-IFC, Buildsoft Cubit, Cype, Bexel and Vicco Office. These proprietary platforms perform automatised QTO at different levels of coordination with other BIM uses, such as cost estimation and construction planning. However, these solutions are based on assumptions that the design models are suitable and contain adequate information to perform these tasks efficiently and accurately [19], which does not meet the reality in industry practice. As a result, designers and surveyors need to perform cumbersome, manual and error-prone activities to produce the QTO. Furthermore, existing platforms sometimes demand complementary applications to integrate specification processes to 1 3 their core functionalities, such as linking a BIM model to construction specification libraries.
BIM-based workflows for construction specifications are intrinsic to QTO and have the classification system as their backbone [26,27]. They rely on long-term standardised content, continuously managed over time to drive digital specification information for their intended purpose. Besides, they are supposed to directly connect specification information and the BIM model objects, reducing rework and revisions as the project team progress in design [8]. Utiome and Drogemuller [28], based on the assessment of existing digital solutions for construction specification, developed a conceptual approach for linking specification information from a product library to BIM models [29]. They also pointed to the need for further developments towards fully automated construction specifications documentation generation in complete synchronisation with the BIM model.
New recent digital tools tacked the synchronisation issue, considerably improving the degree of automatisation for BIM-based construction specifications. One example is NBS Chorus® for writing construction specification documentation by NBS [30]. NBS Chorus is a cloud-based digital solution that links a specification database structured according to Uniclass 2015 and the BIM model. BSD SpecLink [8] similarly connects the BIM model to a specification database based on the MasterFormat classification system. As cloudbased platforms, both have the advantage of providing up to date specification data. Nevertheless, they focus exclusively on specification and are restricted to a particular classification system.
Another example of development in the topic comes from the Portuguese structural engineering company Ground Motion which developed its own tailor-made digital solution [31], addressing the need for automated integration between specifications and QTO. The developed tool focused on structural elements and was developed through the Application Programming Interface (API) of the Revit authoring tool. The tool enables automatised data extraction from a BIM model that does not involve an external specification database (DB), generating a report consisting of a bill of quantities associated with elements/activities specification description. This report is commonly known in Portugal as "Mapa de Quantidades de Trabalho" (MQT), which constitutes a project deliverable according to the Portuguese national deliberation "Portaria n.º 701-H/2008" [32].
Even though consolidated in the market and extremely useful for performing their core activities, existing BIM platforms need to be combined to integrate construction specifications and QTO, resulting in interoperability issues. Moreover, the need to express elements and activities not represented in the BIM model requires workarounds by the designers and surveyors to produce the QTO and specs documentation. Therefore, workflows to perform and coordinate both BIM uses still rely on non-automatised procedures to drive the information modelling for the intended purposes [5,6,11,20], and manage and process data among different BIM platforms [4].
Based on the previously exposed, the proposed system differs from the existing methods and workflows in the following aspects: (i) it reduces the number of platforms used in the process for detailed specification and quantity take-off, not requiring licences and subscriptions rather than the one reserved for the BIM authoring tool. It facilitates the system implementation in architectural firms, an industry category mostly composed of SMEs, which hardly can afford to acquire licenses for specification and quantity take-off-oriented platforms. (ii) Following the number of platforms, the number of intermediary steps to move information among different systems to obtain specification and quantity-off, which has to do with interoperability issues, is also reduced, resulting in a more straightforward process compared to the other existing systems. (iii) Lastly, part of the manual work involved in the existing workflows has to do with mapping or adding specification and quantity take-off information downstream in the process, some of them without securing any digital representation in the BIM model. The proposed framework and digital solution structure the representation of elements and activities through custom parameters and simplified objects without adding significant modelling effort, enabling the production of specification and quantity take-off detailed documentation, oriented to architectural firms, faster and cheaper.

The proposed framework and a classification system as its backbone
The framework comprised three cross-referenced dimensions: (i) establishing modelling requirements and practices to drive the information for the intended purpose, approaching the definition of Level of Information Need [33] for geometric and non-geometric information to enable the BIM model to be used for the intended purposes (Sections 2 and 3); (ii) structuring of an external specification DB, encompassing its form and content (Section 4); and (iii) a digital solution as a Revit authoring tool add-in, which integrates the BIM model and the proposed DB. The proposed addin automatically generates a QTO report fully coordinated with specification data, setting up a preliminary cost estimation (Section 5). Figure 2 presents a conceptual diagram for the proposed workflow. This workflow is based on the research developed by Vieira [34], which has been improved, expanded and updated by this work. Sections 4 to 6 discuss in detail the framework core domains. The detailed workflow for the proposed framework, comprising the re-engineered TO-BE process, is presented in Appendix 2.

3
Even though established based on MC practice, the proposed system is comprehensive, scalable and transversal to other architectural firms, assimilating different internal workflows, types of clients, project scales, uses and typologies. The proposed system mapped 116 categories of construction elements and activities of the architectural lexicon as shown in Appendix Table 7. However, this number can be expanded according to the specification repertoire of other architectural practices. The modelling requirements presented in Section 4 and Appendix Table 7 map the elements and activities associating them with the physical quantity that is expected to be measured (in some cases more than one) within the context of the architectural practice. Based on that, it defines the most suitable classes of objects within the BIM authoring tool for a certain element or activity or proposed means to represent them digitally in the BIM model through parameters or simplified objects when modelling is not tangible or detailed modelling is not justifiable. Elements or activities yet not predicted in this framework, that might occur in other practices can match classes of objects already assigned for similar items and their respective modelling procedures, or can be expressed by incorporating new parameters and new simplified objects following the logic established in Section 4. As long as the correlation among these elements and activities, their expected physical quantity and the most suitable class of object for a certain element or activity or their representation through custom parameters or simplified objects are defined, the previously mapped elements can be updated to respond better to the needs of a particular practice. Therefore, this structure allows the standardisation of the modelling procedures which enables the desired automatisation, not constraining the possibility to adapt to different practices. The database construction (Section 5) similarly assures the expansibility of the architectural specification repertoire, by standardising the input of new information. The database arrangement relies on indexing the elements and activities by a classification code that has added a structured suffix further discussed in this section. It allows the addition of elements and activities yet not covered or editing the existing ones, expressing them with a high level of detail, under a structured format. Furthermore, the framework is technologically adaptable with minor changes (mainly in coding) to different BIM modelling tools, including their respective Application Programming Interfaces (API), and compatible database management systems.
The use of a classification system is the primary information requirement of the proposed framework. The  [34] classification codes index and define construction elements and activities, creating a common ground for establishing communication among humans, machines, and software [35,36]. Furthermore, it is responsible for setting the link between the BIM model and an external DB, allowing the coordination of the information stored in both. Therefore, objects and activities intended to be specified and quantified must be assigned with a classification code. BIM authoring tools usually have native attributes suitable to secure this information. Autodesk Revit®, for example, the one used at MC, has the "Assembly Codes" attribute intended to store Uniformat classification codes. However, the "Keynote" native attribute, designed for tagging objects, also serves to classify objects, adapting to any classification system. These attributes can hold a classification code for a particular object type or material loaded from an external source (a tabulated .txt file), which structures and presents all available classification codes in a hierarchical tree. The implemented standardised classification system was Uniclass 2015 by NBS [37,38], which encompasses complexes, entities, spaces, activities, elements, products and systems. Uniclass 2015 was adopted once MC had already used it in their BIM workflows, assigning its codes to the "Keynote" Revit® native attribute. Besides, the decision also considers the regional context once Portugal will shortly release its national classification system based on Uniclass 2015, in development by the Technical Commission for BIM Standardisation (CT197) [39] within the project Sustainability Enhanced Construction Classification System SECClasS [40].

BIM model
Despite the broader coverage of standardised classification systems, construction specification documentation demands more information than what is expressed in their classification codes and other properties. Sometimes, it is also necessary to appoint specific manufacturers or service providers, specify functions, purpose (restoration or reuse), or define physical characteristics like thickness, colours, and density (usually not covered by the classification systems). This kind of information represents a set of properties that are unique to a particular type of object. For this reason, MC had already structured a suffix to the extent of the classification codes allowing the organisation to differentiate entities by the referred properties directly in the classification code. Nevertheless, it had consistency issues addressed in this framework by configuring a more standardised and robust suffix based on previous developments [34], as presented further in this section.
Some add-ins facilitate the work of assigning classification codes to objects contained in a model. For example, the Classification Manager by Autodesk for Revit allows mapping a category or type of object to the correspondent classification code. However, automatic mapping is only possible when using classification systems based on the function of the elements such as UniFormart, Master-Format and OmniClass, which can be related to the modelling tool categories, leading to generic classifications. Uniclass2015, besides elements/function, also comprises products, systems, entities, complexes, activities, tools and equipment. In this case, mapping correspondent codes cannot be performed automatically and still depends on human interpretation. Therefore, more comprehensive and granular classification systems require manual assignment of classification codes, even when assisted by available tools oriented to facilitate this process. However, this work must be performed only once when establishing/managing an object in an object library. In the everyday practice of a design office, the indexed object just needs to be loaded within the project model to integrate complex BIM processes. The adopted classification system, Uniclass 2015, works as the core of the assembled classification code. However, it is followed by a re-designed suffix that enables a higher degree of information granularity, embedding four (4) further classification levels for a particular element/activity in the case of MC requisites, therefore providing a more specific and detailed definition. Figure 3 illustrates how the classification code comprises the Uniclass 2015 code and the added suffix in two different examples. The assembled classification code indexes the instances in the database and BIM model, making possible information coordination among them. The suffix construction relies on the following rules as ordered below: a Generic or Specific. The first suffix level informs if the element/activity is generic and can be developed by any manufacturer/service provider or if the element/activity should be produced/performed exclusively by one specific manufacturer/service provider. It secures the values "A1" for generic and "A2" and forwards for specific. From the second suffix level on, the expressed information respects the following order of priority; b Exterior or Interior function. Similar product/activity types sometimes require different specifications due to their exterior/interior functionality. For example, two wooden windows that are alike and constituted by the same wood type and components receive specific surface treatment due to their function. Therefore, the current level secures the values "F1" for exterior and "F2" for interior". When functional differentiation is not demanded, no value is assigned, and the following rule should be observed; c Existing objects reuse or restoration. This criterion is applied only to existing objects and informs if they suffered a reuse or restoration intervention. It secures the values "I1" for reuse and "I3" for restoration. New objects observe the following rule directly.
d After checking the applicability of the criteria b and c, from the current suffix level up to the fourth, the elements/activities are classified by their manufacturer, product type, subtype, and colour according to the object, sequentially numbering the remaining suffix levels (01,02,03…10). The only exception relates to physical quantity differentiation, in which its value is expressed in the level code, respecting the limit of two digits. For instance, as shown in Fig. 3, a cementitious grout of 20 mm has assigned the value "20" in the level that does the thickness differentiation The proposed suffix with four extra levels and the implemented codes were specifically driven for MC practice. Nonetheless, this number can be expanded according to the need for a more granular specification of a particular company, project or contractual obligation. Furthermore, regardless of the classification codes that any company or other normative agency might select, the proposed approach is scalable, accepting the reviewing of the proposed criteria or adding new ones for establishing the codes.

Driven information modelling for specification and quantity takeoff
Based on MC practice and its existing modelling approach guidelines by element category, the proposed framework reassessed 116 categories of architectural construction elements and activities and their standard unit of measurement. Table 1 presents a sample of the performed mapping reassessment using mortars and grouts as an example. Appendix Table 7 shows the complete set of MC´s reassessed elements and activities,e providing driven information modelling approaches for each one of them regarding the aim in mind. These elements may be grouped into two categories: a Objects that are graphically expressed in the model. In this group, objects are modelled considering the most suitable authoring tool categories, ensuring access to the correct property sets and the level of information need for precise specification and QTO (See Section 4.1). b Objects, activities and interventions that are not graphically expressed in the BIM model. These objects do not have a graphical representation in the BIM model by  Fig. 3 Example of re-structured classification code by adding a suffix to the original Uniclass 2015 code. Adapted from Vieira [34] purposeful modelling simplifications or their intangible character. This framework addressed the issue by using simplified objects and custom parameters for representing those objects and activities, which assured their computability for specification and QTO outcomes. With both solutions, the BIM model concentrates the information, avoiding creating them in an external platform, which would keep the BIM model unsynchronised with the further subprocess or uses (See Section 4.2)

Geometrical information modelling
The data granularity of the compound object's geometry impacts the accuracy of the QTO. The use of generic objects does not inform its internal layers, which are necessary for precise quantity QTO. Therefore, the objects must be detailed enough to carry a representation of their inner layers. Figure 4 illustrates some examples of compound objects.
The Level of information Need for the compound objects composed of system families, encompassing the geometrical modelling requirements and alphanumeric content, is described below:

Modelling Requirements
• All wall layers must be modelled as independent objects (in the authoring tools, it is possible to transform the layers into parts); • All penetrations with section area above 0,5 m² are modelled at actual rough-opening dimensions, including MEP ducts. The opening area subtracts the wall area. • Precast panels are individually modelled. Connection fittings, if not modelled, are specified by a set of custom properties hosted on the panels, to secure their classification code and quantity. • Modelling finishes such as paint and paint is optional.
However, if not expressed geometrically, these finishes can be represented by custom material parameters. Jointing grounts also can be expressed in custom parameters. Use the developed face-based objects "MC_MagicCubes", whose types indicate which intervention the host object will receive. The script identifies the activities by the cubes present in the model, its classification code in the keynote type parameter, and includes them in the report.

Concrete Repair Mortar
Paving jointing mortars m2 Use the created custom parameter "MC_JointingMortars" (material parameter) to hold a material from the material library.The material must be assigned with a classification code in the keynote parameter. Lightweight masonry mortars Floors, Roofs Assign a classification code in the keynote type parameter. Hydraulic lime mortars Walls, Floors, Roofs, Ceilings Cementitious grouts • The framework proposed attributes according to modelled the element/activity and authoring tool categories as expressed in Table 2.
The use of layered objects that do not allow the geometry adjustment of its layers also leads to inaccuracies [5]. For example, despite behaving as a single object, compound walls, floors, ceilings and roofs are composed of layers that should be measured individually once those layers sometimes occupy different regions. For instance, as shown in Fig. 5, the ceramic tile's finish does not go until the slab above. However, it ends when it encounters the gypsum ceiling. Therefore, basing their quantities on the parental compound object area would lead to inaccuracies. Revit authoring tool, for instance, addresses this issue by allowing the creation of individual "Parts" based on a compounded object initially modelled. This functionality enables the reading of the actual area of the layer, assuring precise quantities once the modeller can adjust the geometry of the layers individually. Similarly, it is possible to edit layers separately by altering the compounded object structure, allowing users to manipulate their geometry manually. However, both alternatives limit the management and use of attributes. For instance, It is not possible to assign a keynote value for the "Parts" or an individual layer within a compounded element, as in the original compounded object. Indexing the parts or the geometrically modified associated layers would require the constituent material to be assigned with a keynote, adding complexity to the information management process. Furthermore, it might affect other intended uses for the model, such as construction drawings representation and IFC exportation and manipulation after exportation.
For this reason, this framework, supported by previous research [6,7], aligned with the ongoing practice at MC, and, considering the aim in mind, opted for avoiding compound elements to ensure easier information management and an accurate QTO, modelling each layer independently.

Use of Custom properties
Some essential elements for specification and QTO do not have a graphical expression in the BIM model. Either because of their geometrical complexity or their inexpressive physical scale, they would require a prohibitive amount of resources to be modelled. However, they must be computed and expressed in the construction specification and QTO documentation. Paintings, primers, floor resins, and tiles jointing grout are examples of these elements. Considering some of the practices already in use at MC when dealing with this kind of element, this investigation proposes the use o custom attributes to secure and express them.

Wall with compound material layers
Ceiling in Gypsum plasterboards Ceramic tiles layer stops when it reaches the ceiling, representing in more detail the reality. It provides more accuracy for BIM-based quantity take-offs. The same happens with the external EPS layer which goes higher than the mansory. 1 3 The proposed attributes are associated with the objects that, in practice, host the elements intended to be represented. A gypsum ceiling, for instance, has to express three different instances for measurement and specification: the ceiling itself, the primer and the paint over it. Primer and paint layers modelling activities can take, in some cases, significant efforts. In these cases and when reasonable, two material custom properties associated with the ceiling secure both elements. A classification code indexes the assigned materials, allowing the developed digital solution to link it to the correspondent specification on the external database. In this case, the quantities presented are obtained from the ceiling object, which hosts the custom properties. If primer and paint were geometrically modelled, there should be no need to assign any value to these custom properties. The framework proposed digital tool would process them as graphically expressed objects. For the Primer and Painting example, the adopted custom parameters, already in use at MC, were respectively "MC_Primer1" / "MC_Primer2" and "MC_Finishing1" /"MC_Finishing2". Their names refer to the author's origin and are preceded by the initials "MC" to quickly identify which parameters are tool native and those which are custom. Table 2 shows the adopted and proposed custom parameters for securing non-modelled elements, assigning which authoring tool categories will contain them. Mapping these elements is a continuous process once other architectural entities may demand such representation, complementing the table.
On the other hand, other elements are not expressed by a material type property but by a set of three properties. The first is a yes/no property, which informs the intention to quantify and specify this non-modelled element. The second directly secures its classification code (Keynote type attribute). The third is a numeric property, which expresses its quantity or quantity formula to be processed by the proposed digital tool (Described in Section 4). One example that can be highlighted pertains to some roof accessories, which, usually, are not modelled for the same reason as the paint and primer. A roof execution comprises other elements than the roof finishing itself, such as slope ventilator tiles, ridge tiles, coatings and cover stripes. Ventilator tiles, for instance, require the referred set of properties to be considered for specifying and QTO. "MC_RoofSlopeVentilatorTiles", a yes/no property to identify if the modeller wants to include this Fig. 6 Example of MagicCubes being used for representing an activity or intervention item in the specs and QTO documentation. The second is "MC_RoofSlopeVentilatorTiles_Keynote", which secures the classification code for this item. The last one is "MC_ VentilatorTile_Percentual", which stores a formula/value to calculate/serve as quantity.

Use of simplified digital representation of activities and/ or interventions
Activities and interventions, as actions, cannot be literally represented as objects since they don´t have a tangible geometric representation. The framework proposes using simplified digital objects to represent an activity or intervention, such as restoring, repairing, cleaning, maintenance and construction site preparation. The proposed objects (the Mag-icCubes) are face-based and can only be placed on another object's surface. The MagicCubes have a classification code that indexes the activity and identifies the object that will suffer the intervention by its placement. Figure 6 exemplifies a steelwork fence in need of repair, indicated by the green MagicCube and a wall cleaning activity represented by the yellow one. The proposed way of expressing these actions is scalable to other activities and interventions according to the needs of the architectural practice and project. They can represent a broad scope, such as restoring a window or a door, cleaning an existing tile, cleaning the construction site, repairing a fireplace, and repairing a waterproof layer. Each of them would convey a different type of Magic Cube indexed by its classification code, having a different colour according to the most suitable pallet within the architectural practice to differentiate them visually in the model.

Driven project phases information
The proposed framework also encompasses the project phasing once it is reflected on the specifications and QTO. The phases can be used as a filter to decide what objects and activities will be part of the documentation of both BIM uses. For instance, in a renovation, the digital solution will not consider existing elements that will remain in the project phase for measurement. Nonetheless, some existing elements can figure in the specs and quantity QTO documentation as restored, located in the same place, or reused in a different one. For example, an existing door that will remain in the project phase would require some restoration. Not the door itself, but the intervention needs to be computed. Alternatively, the designers will place the same door in a different location in the project, which creates a reusing activity that must figure as an item in the specs and QTO documentation. In this context, the framework integrates an auxiliary custom property already in use at MC to compute the restore and reuse, "MC_GeneralIntervention". In complement with the native properties "phase created" and "phase demolished", the proposed custom property allows the measurement of the interventions even though the object was created in a phase that will not be considered for specifying and extracting quantities. Figure 7 illustrates a pre-existing door in a particular project. The door itself will not be measured once it belongs to the "existing construction" phase, but its reuse, Fig. 7 Phasing attributes and the custom attribute "intervention" to indicate the restoring or reusing of a particular object

Phase created
Existing construction Phase demolished None MC_intervencao(intervention) Reuse the action of moving it to a different place, will be specified and quantified.
Elements or activities without geometrical expression, which were not predicted in this work, can be addressed following the same principles: the use of custom properties to represent elements not modelled (once their physical dimension is despicable or would require prohibitive efforts to model) and the use of simplified geometries, as the magicubes, to represent activities which do not have a tangible representation.

Specification relational database structuring based on a classification system
The proposed framework leans on developing a relational database (RD) to store specification information at the organisational level linking its instances to the BIM model objects and the elements/activities by matching their classification codes. The choice of a relational data model structure allows up to date information management for all related entities in the information flow for all ongoing projects and their BIM models inside an organisation. Besides, it enables data management and querying out of the BIM proprietary interfaces and formats [41]. The DB is centred on the Uniclass 2015 classification system. However, the framework adapts easily to any classification system, allowing the same workflow, requiring only minor adjustments in the specification database structure.

Structuring of a specification relational database to be coordinated with the BIM model
The developed specification RD enables information management by connecting different entities represented by other tables, queries, or databases using the defined primary and foreign keys [42]. When one instance in a particular table is updated, the whole related information chain referring to this instance absorbs this change. Therefore, the indexed objects in the BIM model with a correspondent classification code do not require any modelling intervention to embed the most up to date specification. In addition, the nature of relational databases allows new relations regarding other BIM uses such as cost estimation, planning, environmental analysis and operation.
The chosen Relational Database Management System (RDMS) for structuring and managing the proposed database was Microsoft Access® due to the fact MC atelier, the object of study for implementing this framework, pursuits a suite licence that encompasses the referred RDMS, avoiding extra investments. Furthermore, this RDMS is suitable for the data managing scale demanded by small and mediumsized enterprises, having a high-level approach for coding combined with a friendly graphical user interface (GUI) compared to other solutions.
As illustrated in the Entity-Relationship models in Figs. 8 and 9, the current stage of the DB development is centred on one primary table/entity. It holds the construction elements/ activities specification information, presenting no difference in managing and processing modelled objects, non-modelled objects and activities/interventions within the DB. This table is associated with other complementary entities that secure the sets of relevant related data, such as the classification system information (in this case, Uniclass 2015) and their units and physical quantities for measurement. In addition, each element/activity instance can have comments assigned (represented by the entities Comment and Comment Type in Figs. 8 and 9), allowing the user to inform whether a particular instance has an issue. For example, the need to confirm one specification description with the manufacturer/ service provider, a price that needs to be updated, or any other observation that might be important for the organisation regarding that element/activity. The DB structure is not fixed and allows other associations by creating new tables and queries or connections with other databases, for example, related to cost engineering, environmental impact, or maintenance and operation.
A graphical user interface (GUI) (See Figs. 10 and 11), based on VBA programming language (within Microsoft Access®), was also developed for managing the database, allowing users to check, query, add, edit, and delete instances. The external database, combined with its GUI, confers to users without specific training in BIM modelling the possibility to work with specification data in a BIM-based workflow.
The DB also contains a query that structures the Keynote source mentioned in Section 2 as the authoring tool requires, allowing automatic exportation of the tabulated file. Thus, every time the DB is updated, the RDMS can export a new keynote source list automatically loaded into the BIM authoring tool as a hierarchical classification tree that helps the modeller assign classification codes to the object types.

A digital solution for coordinating BIM-based specification and quantity takeoff information
Developing a digital solution for automating a particular process depends on structured data to achieve its intents successfully. Standardisation, therefore, is a critical digital process enabler. According to Cerovsek [43], the standards confer interoperability, trust, and comparability to digital solutions. This section describes the developed digital solution, which relies on Sections 2, 3 and 4 developments for structuring the needed information to perform BIMbased integrated specification and QTO.  The proposed digital solution works as an add-in for Revit 2020® and is named TIE, an anacronym for Technical Information Exchange. Its development leant on the BIM software API and the open-source tool PyRevit® [44] for interpreting IronPython (the version of Python script language compliant with the .NET framework). Besides, the developed add-in counts on a GUI developed based on the Windows Presentation Foundation (WPF) [45] framework, written on XAML markup language. TIE extracts information from the BIM model coordinating it with the specification stored on the developed database to produce specs and QTO documentation. It identifies the objects/activities digitally represented in the BIM model by their classification codes, matching them to their correspondent instances in the DB.

Elements / Activties
The add-in comprises two modules. The first one performs modelling checking and validation. The second module centralises the core tasks, effectively integrating the BIM model and DB, producing integrated specification and QTO outcomes.

Module 1: information modelling checking and validation
The module for checking and validation (Module 1) assists the modeller in ensuring a compliant BIM model with the minimal information requirements to generate the specification and QTO documentation performed by the second module (Section 6.2). Its outcomes consist of an issue report plus a visualisation filtering. Figure 12, adapted from previous developments [34], provides an overview of Module 1 structure based on four main checking routines.
Initially, The script sets up the libraries and modules necessary to connect and extract information from the BIM Fig. 10 GUI for managing the specification database model and DB (Fig. 12, process 1). The two subsequent processes (Fig. 12, p2 and p3) get the user input to establish filters for analysing the objects based on their types and created phase attributes. The filtering by object types allows the user to deal with the called nested families. This term refers to the objects composed by others or, in Revit®, a family composed of other families. A door object type, for instance, could be composed of a set of independent objects such as a door leaf, door frame, and door handle. When processing this door, the add-in would compute the parental object itself but also the constituent objects, resulting in duplicated instances in the specification and QTO documentation. Filtering the objects by their type allows users to overcome this issue by selecting the nested door or its parts individually to be read by the add-in according to the user's needs. The other filtering option by the "created phase" attribute, on the other hand, is essential once it excludes from the add-in processing the elements assigned as created in project phases that do not need to be specified or quantified. For instance, in a renovation project, existing components, by design decision, will remain in the project without suffering any intervention. Therefore, these elements are not taken into account. In the following steps, the TIE module 1 submits the filtered objects and their related activities to its three main checking routines (Table 3 details Module 1 routines).
Module 1 provides visual checking of the analysed objects. It hides temporally all objects without any appointed issue in the authoring tool active view (Fig. 12,  p7), leaving on-screen only those who demand adjustments according to the checking assessment Fig. 13 demonstrates this functionality by showing the model before and after running the script. Besides the visual checking, it also writes an Excel® spreadsheet listing the issued objects based on their found issue (Fig. 12, p8). Their category, family, type, and id are informed, facilitating to localise them in the BIM model. Both visual checking and the issues list guide the modeller in making the necessary adjustments to achieve accurate specification and QTO outcomes.   Objects not assigned with a classification code (Fig. 12, p4) This routine identifies the objects lacking a classification code. In this case, the script can not match the object with its correspondent instance in the DB. A list with all issued objects (ii) Objects without correspondent instance in the DB (Fig. 12, p5) This routine identifies the objects that, though classified, do not have a correspondence in the DB. In this case, the script can not obtain the needed specification information (iii) Attribute assigned for measuring in the DB not existing in the BIM object (Fig. 12, p6) This routine identifies the objects lacking the attribute for measuring assigned in the DB. For example, suppose the DB indicates the attribute thickness (m) for a cabinet assembly to be read. In that case, the script will look for this attribute in the object and not find it once it does not apply for assemblies.

Fig. 13
Visual checking and validation after executing the script 1 3

Module 2: Automatized coordinated specification and quantity takeoff report
The second module (Module 2) produces the coordinated specification and QTO report. Based on filters set by the user, the Module 2 script extracts information from the BIM model coordinating it with the specification DB. It generates a specification and QTO project deliverable, which combines a bill of quantities with detailed specification information, named in Portugal as "Mapa de Quantidades de Trabalho" (MQT). Figure 14 presents a Module 2 overview through its flowchart. Similarly to Module1, in Module 2, the script begins by setting up the programming modules and libraries, which enable communication with the authoring tool API and DB to obtain information from both (Fig. 14, p1 and p2). Then, in processes p3 and p4 (Fig. 14), the add-in GUI allows the user to filter the objects he wants to include in the processing. Again, the filters rely on the object types and the "phase created" native attribute. Finally, the resulting objects and their identified related activities (represented by the custom attributes or MagicCubes) go one by one to the core routines of Module 2, as presented in Table 4.
Suppose the add-in does not accomplish one of the four routines above when processing a particular element due to missing information. In that case, it adds the issued object or activity in an error list presented as an appendix of the final generated coordinated specification and QTO report. The   (Fig. 14, p5) This routine retrieves the classification code of the objects. Besides the object itself, it also retrieves the classification codes of related non-graphically expressed objects and activities through the custom attributes or MagicCubes. If, by any chance, the script identifies non-classified objects, it stores them in an issues list that will be printed at the end of the final report. (ii) Finding the correspondence in the DB (Fig. 14, p6) Based on the classification code(s) retrieved in the previous step, this routine queries the DB and secures the object correspondent specification information. (iii) Getting objects quantities (Fig. 14, p6) The DB extracted information informs the script of the physical quantity attribute and unit that a specific object instance should be measured. Based on this information, this routine looks for the specified attribute and obtains the quantity for the analysed instance. Besides, the script sums up the quantities for each of the object instances indexed with the same classification code. (Several objects with the same classification code will represent only one element/activity in the specification and QTO documentation. However, it will sum up their quantity if the measurement attributes require). (iv) Coordinating the BIM model X DB (Fig. 14, p6) This routine matches the information extracted from the BIM model to the one extracted from the DB, treating and formating them to be presented in the final specification and QTO report. This routine also computes the cost of the object or related activities based on the extracted quantities and the cost per unit assigned in the database. Module 2 also visually checks the elements with missing or inconsistent data listed in the error schedule, hiding objects processed correctly, and leaving only the issued ones on the screen (Fig. 13) in the active view.
Lastly, the script generates the coordinated specification, QTO report and preliminary cost estimation report in an Excel® spreadsheet (formatted as the Portuguese project deliverable "MQT") following a pré-establish report template. The option for generating an editable file format grants the user flexibility to proceed with minor adjustments. The script also highlights all the encountered errors in yellow, informing the user about the necessary adjustments. After addressing those errors, the user can quickly generate new report versions.
The report structure can follow the hierarchical taxonomy of the adopted classification system used to index the BIM model and DB objects or another structure based on a secondary classification system. The secondary classification is also an attribute of the DB instances, mandatory only if the user wants to present the report following it. For example, in the case of developed work, the object of study organisation (MC) uses a secondary classification to group and order the elements and activities based on the materiality and type of work in specs, QTO report and preliminary cost estimation. Table 5 illustrates a sample of the report information outcomes.

Testing in real case scenarios
The developed framework and digital solution for BIM-based specification and QTO were tested in two ongoing projects at Marta Campos Atelier de Arquitectura. The choice for both cases first aimed to consolidate the framework structure, establishing effective coordination among the information modelling activities, the DB and the digital solution to produce the MQT (the Portuguese coordinated specification and QTO report) with a preliminary cost estimation. Furthermore, testing in real-life scenarios assured the framework's capacity to specify and quantify objects and activities that are usually not modelled or are not possible to be expressed geometrically. Finally, it allowed the framework to face not previously predicted issues once it dealt with models and DB records produced by a third party (MC team), which would lead to errors or impaired functioning of the add-in. As a result, besides proving the framework's applicability, testing in real projects has amplified its coverage.
Project 1 was a one-storey new single-family house in Vila do Conde, Portugal, at the beginning of the Spatial Coordination [46] phase. As new construction, the project would not demand the proposed framework to deal with complexities such as demolitions, restoring and reusing objects. This condition allowed the testing to focus on the core guidelines and functionalities proposed by the framework, assuring accurate and effective coordination among the BIM model, DB and digital solution.
The process of testing and cross-referencing modelling procedures, DB structuring and programming helped refine and adjust the three framework engines. For example, some of the proposed customs attributes representing objects without graphical expression in the BIM model were perceived as necessary during the testing stage, demanding updates in the BIM model and DB, as well as coding adjustments. Similarly, new MagicCubes types allowed the representation of activities not predicted. Furthermore, the testing process relied on constant feedback from the MC team, which provided important insights for improving the framework coverage and complexity.
The exhaustive testing in Project 1 refined the modelling guidelines, database structure and content, and the digital solution, providing the expected outcome, the specification, QTO and preliminary cost estimation report. Purposefully, some issues were left behind after running the checking and validation add-in Module 1 to certify the proper functioning of Module 2 in terms of encountering and informing errors in the final specification and QTO report, highlighting them in yellow. However, the workflow would require executing as many checking interactions as necessary to obtain the final report with no issues found.
Project 1 demanded around 1 min to be processed by the add-in, using a PC, Intel Core i7-7700HQ CPU @2.8 GHz and 16GB RAM. Table 6 presents an overview of the final specification, QTO, and preliminary cost estimation report, presenting the number of analysed objects and resulting specified and quantified elements/activities for Project 1. Table 5 (presented in Section 5.2) illustrates a sample of how the report structures and shows the processed data. Figure 13 exhibits the visual checking outcome of the processed objects, leaving onscreen the issued ones in the active view on the authoring tool.
The second project, Project 2, was a four-storey singlefamily house renovation in Calvelhe, Portugal, in Technical Design Stage [46]. The information required for this phase was already integrated into the model, including specification and QTO report data. In this case, the testing procedures would address issues beyond the framework core guidelines and functionalities already consolidated when testing in Project 1. Project 2, as a renovation, would demand the script to specify and quantify demolitions, restoring and reusing objects. Therefore, a new set of elements and activities not graphically expressed in the model would be addressed. Furthermore, due to the advanced project stage, it would be possible to assess the necessary efforts to drive the BIM model to comply with the established requirements once the model was conceived initially, not following the more up to date framework modelling guidelines.
As established in the expected workflow, Module 1 was executed, informing the necessary adjustments in the checking and validation report and visually in the authoring tool. MC team addressed and solved all pointed out issues, triggering TIE Module 2. The initial version of the generated coordinated specification and QTO report contained problems related to the DB structure and the add-in code, leading to missing elements/activities. For example, elements assigned as demolished in a particular project phase but intended to be reused were not accounted as such. The script did not consider the proposed custom attribute ("MC_Gen-eralIntervention"), which indicates reuse or restoring, not computing the object's placement in a new location. This problem required programming adjustments, and new report versions were processed to confirm the issue was gone.
As an architectural renovation project, the hidden objects in the active view resulted from the script execution are primarily in the house's interior. The construction envelope constituents such as external walls, roofs, windows, and doors remain on the screen once they were filtered out of the specification, QTO and preliminary cost estimation report by the phase filtering before TIE execution.
In the end, the script successfully generated the coordinated specification, QTO and preliminary cost estimation report in compliance with the proposed framework, matching the expectations. The add-in total processing time took approximately 3:30 min using the same hardware referred for Project 1. As part of the architectural project documentation for the Technical Design phase, the produced outcome was delivered to the clients, alongside all construction drawings. The produced MQT by TIE was used for the first time to support the tendering and construction of a real project. Table 6 presents an overview of the final specification, QTO, and preliminary cost estimation report, presenting the number of analysed objects and resulting specified and quantified elements/activities for Project 2. Figure 15 illustrates the visual checking outcome comparing the model view in the authoring tool before and after running the script.
The processing time of one minute for project 1, and 3:30 min for project 2, expresses the efficiency of the proposed system towards an automatised method for producing a coordinated specification and quantity takeoff report. The re-engineered process for BIM-based specification and QTO structured by the proposed framework demanded considerably fewer resources and time than the previous BIM-based workflow used at MC. The number of intermediary manual or semi-automatic steps and proprietary BIM platforms has decreased. Based on the atelier records of similar projects in terms of scale, program and complexity, the proposed framework has reduced the necessary time to produce specification and QTO to 20% of the time that it was needed with the previous workflow of MC (which was already BIM-based). The gains are even more attractive compared to traditional methods, spending 1/10 of the time. It is important to highlight that the presented processing times do not include the time for assigning the classification code to an object when modelling or managing the object in the library. However, this extra time, which is performed only once while creating a new object or adding the classification code for the first time within the authoring tool, took on average 25 s per object, in a sample of 20 objects.
Regarding the framework´s accuracy, during the development of the digital solution, a set of tests was performed comprising all object categories driven to the architectural discipline in the modelling authoring tool, involving a representative group of objects. The tests were based on the studies conducted by Khosakitchalert et al. [5,6], which addressed the lack of accuracy when extracting quantities from compound elements. They were performed by modelling hermetic rooms, placed side by side, with openings, creating several different situations of encounters between compound elements. The same encounters situations were monitored in the real case projects. As a result, it achieved an accuracy of 100% for the performed quantity extractions that followed the proposed modelling requirements.

Conclusion
This research provided an alternative framework for integrated BIM-based specification and quantity takeoff through digital modelling driven to small and medium architectural offices. It embodied the development of a digital tool (an add-in for Revit®) that semi automatically generates coordinated databased specification and quantity takeoff documentation, setting up a preliminary architectural cost estimation. Furthermore, the framework offers means to estimate and represent elements and activities usually not modelled within the architectural universe without requiring errorprone, time-consuming manual and semi-automatic efforts.
The alternative is presented without demanding unjustifiable modelling efforts to ensure efficient construction specifications and QTO documentation. The achievements involved establishing information modelling guidelines and requirements, structuring and managing an external database, and developing a digital solution.
The proposed suffix provided more granular information when indexing activities and elements. Furthermore, even though a standardised structure was kept, it was flexible enough to cope with any activity, elements, or system intended to be specified, aligned to the expansible nature of the construction specifications stored in the database. Therefore, these aspects allow the framework to be comprehensive, transversal, and scalable to different architectural practices.
The work development has stood out the importance of standards and procedures as enablers of digitalisation. The information must be produced, exchanged and consumed in compliance with some requirements, which will allow digital platforms to read and interpret it, mitigating human interventions in the processes and providing the expected outcome. BIM model and DB are driven to provide the desired information for the processing in the digital solution.
The framework requires an initial input push to build and provide content for the specification DB since gathering functional specification and cost information from different sources might take time. However, once the DB is established, its management activities are restricted to adding new elements and activities and updating existing ones.
The extra effort demanded to drive the information modelling to the framework requirements can be an obstacle for large scale models in advanced stages of development, mainly regarding the layered objects. However, companies with a higher degree of BIM maturity may have been driving their models since the earlier stages towards 4D and 5D, which address the mentioned issue by modelling these objects independently, allowing individual computing. In this case, the extra effort is not significant and is mainly reserved for creating and filling the custom attributes, placing the MagicCubes and assigning correct classification codes for the elements/activities intended to be specified and quantified.

Future developments
Further developments could allow the processing of IFC models. The developed digital solution for coordinated specification, QTO, and preliminary cost estimation is restricted to Revit®. It was tested to execute the script importing an Industry Foundation Classes (IFC) model into the authoring tool without successful results. Some adjustments in the code are necessary to enable the add-in to process IFC object classes. Dealing with models in .ifc format, which promotes interoperability among different BIM platforms, would significantly enrich the proposed framework, expanding its approach towards OpenBIM [47].
Additionally, the database could integrate other tables or other external databases, allowing the coordination established by TIE between the BIM model and DB to perform other BIM uses and produce a variety of digitalised outcomes. For instance, external price lists providing accurate and up to date cost data in real-time. Or environmental parameters to automatically provide environmental impact calculations based on elements and activities specifications and quantities. The connection with external databases would empower the proposed framework to deal with other BIM uses.

Declarations
Competing interests The authors have no competing interests to declare that are relevant to the content of this article. Assign an object demolition in an existing project phase by using the authoring tool native parameter "Phase Demolished". The script identifies if there is at least one object assigned as demolished and includes this activity in the report. (It also informs that is necessary to assess the demolition drawings to bid this activity accurately).
Cleaning and repair Masonry / Brickwork vg Activities with no graphic expression in the BIM model. Use the developed face-based objects "MC_MagicCubes", whose types indicate which intervention the host object will receive. The script identifies the activities by the cubes present in the model, its classification code in the keynote type parameter, and includes them in the report.  sion in the BIM model) Roof clay interlocking tiles is measured in "m²". The area is extract from the roof object itself placed in the BIM model; The other elements such as roof slope ventilator tiles, roof ridge ventilator, roof slope walkable tiles, roof connections are measured in "m" or "un". These elements are normally not modelled. If that is the case, their quantities are estimated by a math formula in function of the area or manually. The set of custom parameters below (part of this framework) stores the information of which elements must be considered in the quantity takeoff and their estimated quantities. The modelled elements and the non-modelled elements expressed in the custom parameters are specified and computed by their classification codes. Assign a classification code in the keynote type parameter.

Mortar
Handrail m/ vg Railings (component and "model-in-place" families), Assemblies If the object is developed as a component family, the script will get the length in "m". If it is model-in-place, the object must be categorised as Railing. Assemblies and "model-in-place" objects will be processed as "vg" for the measuring unit. Both cases will rely on drawings for biding besides the obtained quantities. All cases must be assigned with a classification code in the keynote type parameter.
Decorative Elements un Any category (component and "model-in-place" families) Both component families and "model-in-place" objects must have a classification code in the keynote type parameter assigned. Each object will be read individually.
Fixed equipment / Furniture vg Caseworks Create an assembly and assign a classification code in the keynote type parameter.

Furniture vg, un
Furniture Create an assembly and assign a classification code in the keynote type parameter.
Stairs un/ m² Stairs One stair object comprises two measured items in the final report: risers and landings. Risers are measured in "un" and landings are measured in "m²". The stair object must have assigned a classification code in its keynote type parameter, as well as assigned values to the following custom parameters: MC_StairLanding(yes/no), MC_StairLaning_Keynote, MC_StairLanding_Area(m²). Railings m, vg Railings (component and "model-in-place" families), Assemblies If the object is developed as a component family, the script will get the length in "m". If it is model-in-place, the object must be categorised as Railing. Assemblies and "model-in-place" objects will be processed as "vg" for the measuring unit. Both cases will rely on drawings for biding besides the obtained quantities. All cases must be assigned with a classification code in the keynote type parameter.
Openings trim un Doors (component and "model-in-place" families) These elements should be developed preferably as component families, each type with the keynote parameter assigned with a classification code. The elements modelled as "model-in-place" must be categorised as a door and each of them individually must be assigned with a classification code in the keynote type parameter.
Paneling m², m Walls, Wall-Sweeps (component and "model-in-place" families) Assign a classification code in the keynote type parameter. Assign a classification code in the keynote type parameter. Handrail m/ vg Railings (component and "model-in-place" families), Assemblies If the object is developed as a component family, the script will get the length in "m". If it is model-in-place, the object must be categorised as Railing. Assemblies and "model-in-place" objects will be processed as "vg" for the measuring unit. Both cases will rely on drawings for biding besides the obtained quantities. All cases must be assigned with a classification code in the keynote type parameter.

Shutters
Fixed equipment / Furniture vg Caseworks Create an assembly and assign a classification code in the keynote type parameter.

Furniture vg, un
Furniture Create an assembly and assign a classification code in the keynote type parameter.
Stairs un/ m² Stairs One stair object comprises two measured items in the final report: risers and landings. Risers are measured in "un" and landings are measured in "m²". The stair object must have assigned a classification code in its keynote type parameter, as well as assigned values to the following custom parameters: MC_StairLanding(yes/no), MC_StairLaning_Keynote, MC_StairLanding_Area(m²).
Curtain-Walls m² Curtain-Walls Besides the obtained quantity, these elements require drawings assessment for bidding.
Create an assembly and assign a classification code in the keynote type parameter.
Gratings un, vg Curtain-Walls, Generic Model ("model-in-place), Casework ("model-in-place) Besides the obtained quantity, these elements require drawings assessment for bidding.
Assign a classification code in the keynote type parameter.
Floor Gratings Railings m, vg Railings (component and "model-in-place" families), Assemblies If the object is developed as a component family, the script will get the length in "m". If it is model-in-place, the object must be categorised as Railing. Assemblies and "model-in-place" objects will be processed as "vg" for the measuring unit. Both cases will rely on drawings for biding besides the obtained quantities. All cases must be assigned with a classification code in the keynote type parameter.
Roof lanterns vg Windows, Casework ("model-in-place") Besides the obtained quantity, these elements require drawings assessment for bidding.
Assign a classification code in the keynote type parameter.

Shutters un Doors, Windows
Assign a classification code in the keynote type parameter. One stair object comprises two measured items in the final report: risers and landings. Risers are measured in "un" and landings are measured in "m²". The stair object must have assigned a classification code in its keynote type parameter, as well as assigned values to the following custom parameters: MC_StairLanding(yes/no), MC_StairLaning_Keynote, MC_StairLanding_Area(m²).

Doors Doors
Flashing and weathering systems Assign a classification code in the keynote type parameter. When the object is a "model-in-place" is just possible to measure it as "un" or "vg", once this authoring tool categories only allows the volume extraction.  Assign a classification code in the keynote type parameter. When the glasses are associated with a window or door frame, the window/door object hosts the custom parameter. This parameter stores the element material from the material library classified with a classification code in the material keynote. In this case, its quantity is not measured, the parameter is used exclusively to specify the type of glass and appears in the report as "vg" unit measure.

Laminated glass
Simple glass Stainless simple glass Thermally toughened glass Finishes Cleaning agents m², vg Elements usually with no graphic expression in the model.
Elements usually with no graphic expression in the model. When modelled, they are developed as walls, floors, roofs and ceilings.
Assign a classification code in the keynote type parameter if the element is modelled. If it is not, use the custom parameters listed below associated to walls, ceilings and roofs. These parameters stores the element material from the material library classified with a classification code in the material keynote. (When associated with windows and doors, their quantyties are not measured. In this case the parameter is used exclusively to specify the primer or finish). Primers MC_Primario1 MC_Primario2 Acabamentos MC_Acabamento1 MC_Acabamento2 Water-based acrylic primers Solvent-borne wood primers Solvent-borne metal primers Water-based matt and flat finishes Solvent-borne gloss finishes Solvent-borne mid-sheen finishes Semi-transparent timber oils Sealers Acrylic resins Equipments and appliances Activity included in the report as "vg" for measurement unit. The inclusion of this activity in the report is optional and depends on the user selection before running the script.

Construction site
Site and its environment cleaning *The measurement unit "vg" corresponds to a global value. Therefore, the manufacturer or contractor will attribute a global price for executing the referred activity based on the construction documentation