Pragmatic Design Decision Support for Additive Construction Using Formal Knowledge and Its Prospects for Synergy with a Feedback Mechanism

Abstract

The construction industry has long been labor-intensive, with slow productivity growth and a significant environmental impact. In this regard, the ever-increasing practices of additive manufacturing (AM) in construction have presented a variety of advantages and are deemed one of the critical technologies for the concept of Construction 4.0. Building information modeling (BIM) as an enabler for the digital transformation in the architecture, engineering, and construction (AEC) domain provides a framework for considering novel AM methods during the early stages of architectural design. It is known that decisions during early design stages significantly impact the subsequent planning and construction phases, whereas missing AM knowledge by architects and engineers could in turn impede the adoption of AM technologies when the early determination of appropriate manufacturing methods needs to be made. Meanwhile, the early stages of architectural design are characterized by vagueness, uncertainty, and incompleteness, which have to be clarified iteratively by both architects and domain experts. To this end, this paper introduces a knowledge-driven design decision support that prospectively incorporates an adaptive feedback mechanism under the BIM methodology. As such, architects can be assisted in choosing appropriate construction methods during the early stages of architectural design.

1. Introduction

The building and construction sector accounts for a significant share of the world’s energy consumption and for more than one-third of worldwide greenhouse gas emissions [1]. Furthermore, the construction industry is considered underdeveloped and still in the early stages of digital transformation compared to other industries such as automobile manufacturing. To pursue the goal of decarbonization under the pressure of urbanization and population increase, it is urgent to reform the predominant construction approaches which are material-inefficient and non-productive. Additive manufacturing (AM) technology has promised great opportunities in sustainability [2,3,4], and its recent advancements in construction have presented extended freedom of design [5], sound mechanical performance [6], integration of multiple functions [7], etc. However, established routines and technology stacks in the architecture, engineering, and construction (AEC) domain have to be re-evaluated to realize the integrated capabilities of AM technologies. The work of [8] has identified the need for a shift in the architectural design paradigm, a holistic design process incorporating material science and engineering, and more rational designs which best utilize AM in compliance with existing regulations.

Being one of the critical technologies of Construction 4.0, AM is closely linked to the Building Information Modeling (BIM) methodology to build a seamless digital chain from design to construction [9]. In recent years, BIM has been deemed an enabler for digital transformation in the AEC domain. The work of [10] proposes BIM as a methodology for digital planning and data interoperability. More specifically, the industry foundation classes (IFC) [11] data model covers many essential aspects of the construction sector, thus contributing to data interoperability across heterogeneous software from design to construction. Accordingly, several studies have demonstrated the potential of using the IFC schema for fabricating a BIM-based design with AM technologies [12,13,14]. In addition, collaborative activities involving different participants, including architects, stakeholders, engineers, etc., can be federated by the common data environment (CDE), information exchange management, and cooperative data management [15].

As an integrated collaboration platform, BIM is also used for decision-making in design and construction problems considering multiple criteria [16,17]. It is known that design decisions in the early stages are critical to the functionality, cost, and success of a building project [18]. Regarding AM, this applies to the early determination of appropriate AM methods for the given design, such that timely design adaptations can be made to preserve the benefits of AM technology. However, such an important decision remains elusive due to the uncertainty and vagueness inherent in early-staged architectural design, as well as the unknown boundary conditions and consequences of AM methods when applied. Previous research attempted to address this dilemma from different perspectives. Dealing with uncertain parameters contained in design variants, Rezaee et al. proposed a statistical approach to quantify the uncertainties in how a design variant will evolve [19]. Anchoring to the multi-discipline nature of architectural design, Abualdenien et al. proposed an adaptive detailing strategy collaborating with different practitioners by virtue of a consistent model and machine-readable communication protocol [20]. Meanwhile, demanding domain knowledge was made available by knowledge formalization approaches to advance manufacturing-aware design. Among these, knowledge-based design decision support incorporates ontology and rules have been utilized to verify the manufacturability of prefabricated building components, such that time-consuming iterations between design and manufacturing stages can be reduced [21,22].

While some studies have attempted to address the lack of AM knowledge for the early design phase, few have considered the constraints arising from the construction planning phase, let alone the integration of the more comprehensive knowledge into, and facilitating, the collaborative and communication-intensive decision-making processes. To make up for this deficiency, this paper introduces a knowledge-driven decision support system with a feedback mechanism. We believe this methodology is practical to support the decision-making of suitable AM methods for architectural design as it not only solves the problem of missing AM knowledge by architects and engineers but also provides regulated and traceable communications between them. To date, there has been very little research integrating these two aspects. With the proposed methodology, architects can, in a timely manner, discover inconsistencies between the design and AM methods and communicate with engineers efficiently on the problems found. At the same time, engineers also obtain information about AM methods in order to provide effective assistance to architects. Therefore, this work practically contributes to the decision support of AM methods for BIM-based design, thus advancing the application of AM technologies in the field of AEC.

This paper is structured as follows: Section 2 introduces the related works in early-staged design decision support and the research background; Section 3 elaborates on the formalization processes with a holistic consideration of both manufacturing and regulatory constraints; it then narrates the feedback mechanism with an adaptive detailing strategy; finally, the characteristics and limitations of our approach are discussed and concluded.

2. Background and Related Works

2.1. AM Technologies for Construction

In recent years, AM technologies have been increasingly studied as an alternative construction approach, with their maturity improved through accumulated implementations different in scale, material, printing methods, construction procedures, etc. The versatility of AM methods is mainly reflected in the innovations of processes, materials, and machinery.

Buswell et al. [23] proposed a process classification framework for 3D concrete printing (3DCP), classifying the processes as particle-bed binding, material extrusion, and material jetting. Material extrusion methods originating from the well-known Contour Crafting have been realized by many institutes over the past two decades [24]. With unique structural optimization and aesthetic properties, particle-bed binding methods are increasingly recognized and studied by enterprises and academics [25,26]. In addition to concrete, more sustainable construction materials such as earth and wood have also been applied; however, using such materials could require printing larger components to meet the same load requirement or restrict the environment of presence due to limited durability [27,28]. Regarding machine systems, particle-bed binding processes generally use gantry systems mounting special-designed nozzles with jetting or spraying mechanisms, while novel solutions have been explored in material-extrusion processes, such as the mobile robotic system [29], near nozzle mixing system [30], and hybrid system with a robotic arm mounted on the gantry for a higher degree of freedom (DOF) [31]. Using manipulators with a high DOF relaxes the slicing orientation from the horizontal and potentially increases geometry freedom of design, but it requires complex trajectory planning and coordination with the fresh state properties of the printed material.

Furthermore, depending on AM methods’ environmental requirements, the workspace of the machine system, etc., printing processes can be performed on-site or off-site; in this case, the limitation of logistics on the size of the printed object should be taken into account, i.e., large building components would have to be printed in smaller dimensions, milled or cut with an appropriate profile [32], then assembled as a single piece. Layer-wise printed building components are inherently less resistant to flexural loads than cast ones. To overcome this deficiency, a variety of reinforcement strategies have been applied in 3DCP to enhance the inter-layer binding of printed components [33,34]. Another critical research field in additive construction is integrating multiple functions with a rational inner design to save material and energy consumption, thus advocating the adoption of AM for sustainability [35,36].

2.2. Design Decision Support System

Notwithstanding the outstanding achievements of additive construction, challenges do exist. For existing cases of AM construction leveraging material extrusion technology, printed concrete was used uniquely for compression-only load-bearing structures, and the technique’s competency was encumbered by regulatory compliance and a lack of reinforcement strategy [37]. Knowing from past AM practices [37,38,39], construction planning plays a crucial role in guarding the landing of projects and needs to meet the requirement of each aspect, e.g., site context, regulations, design intent, and AM methods’ capabilities. Furthermore, design and planning efforts are stressed at the very early stage of additive construction projects. Early recognition of AM methods’ capabilities, as well as early collaboration from multiple disciplines, are indispensable to the success of an AM construction project.

The TRR277 project, “Additive Manufacturing in Construction (AMC)—the challenge of large scale”, funded by the German Research Foundation (DFG), aims to fundamentally investigate the AM technologies regarding material and process, computational modeling and process control, as well as a digital chain from design to construction [40]. As an integral part, the C04 project envisages a design decision support system (DDSS) that assists architects and engineers in choosing appropriate AM methods for a BIM-based architectural design. Figure 1 illustrates the concept of this DDSS which provides interactive design decision support based on AM knowledge and considerations of multiple design criteria. To this end, Li and Frank proposed two key approaches for the DDSS as AM knowledge formalization and interactive decision-making support, which are enabled by semantic web technology and multi-criteria-decision-making (MCDM) methods, respectively [41]. In the work of [42], they demonstrated a framework for logic-based inference and feedback between this DDSS and a BIM authoring tool. This paper alternatively uses the terms “AM” and “AMC”: AM methods subsume the AMC methods and are used in a neutral sense, while AMC methods are specific to these in the TRR277 project.

2.3. The Importance of Early Design Stages

The early stages of the architectural building design are highly important because the most influential design decisions with a great influence on the performance of the future building are being made [43]. Early availability of design understanding is thus very valuable, as it positively influences design decisions while preserving sufficient flexibility when the time budget is limited [44]. Changes to these early decisions during the precise detailing or construction phase require extra cost and time. Meanwhile, during these early stages, the individual designers’ instincts and experience are frequently their main guiding forces. Other domain experts’ and consultants’ input is often missing due to insufficient detailing of the design model. Any analysis or simulation at these stages requires oversimplifications and design assumptions which may cause misjudgments or overconfidence when the results, even though they appear precise, are in fact uncertain [45].

To address this challenge, Abualdenien and Borrmann incorporated information uncertainties into a meta-model approach and introduced the building development level (BDL) to express the design needs for certain design stages using the levels of development (LODs) of specific families [46]. Soliciting domain experts through simulation and analysis requests, and supporting designers in design decisions by suggesting missing information in the design model and corresponding analysis results is what Zahedi et al. introduced as the adaptive detailing strategies [47]. To support these communications between the architects and other domain experts and consultants, Zahedi et al. introduced the feedback mechanism, in which a BIM-based machine-interpretable communication protocol handles all these requests and feedback input to the design model by empowering an adaptive data schema that leverages the LODs to describe design requirements for various analysis types and at building development levels [48].

2.4. Use of Semantic Web in AEC

To date, the ontological transcription of the industry foundation classes (IFC) (data schema in OWL2 DL dialect—ifcOWL is in the same status as EXPRESS and XSD schemas for the IFC [49]. It is known that the complete set of ifcOWL entities is rather bloated and subject to deficiency if naively imported for modeling a new ontology. To overcome this, several initiatives have scratched modular ontologies for the AEC domain while keeping alignment with the ifcOWL. The W3C linked building data working group (LBDWG) has devoted itself to bringing building-related data across the building’s whole life cycle to different practitioners through (semantic) web technologies. The LBDWG has developed modular ontologies for multifactorial aspects of the built environment, including ontologies of building topology (BOT) [50] and building elements (PRODUCT) [51]. The digital construction ontologies (DiCon) [52] aim to compose a comprehensive suite of modular ontologies for information entities, resources, processes, agents and roles, etc. DiCon makes use of basic formal ontology (BFO) [53] as its upper ontology and has aligned itself to other ontologies from this basis.

Pauwels, Zhang, and Lee [54] summarized three expectancies when applying semantic web technologies in AEC: data interoperability, linking across domains, and logical inference and proofs. From this sense, collaboration using ABox of the ifcOWL-complied knowledge base unsurprisingly enables data interoperability through the unified technology stack in terms of serialization, modeling, querying, etc. Cross-domain data linking can be triggered by the alignment of domain ontologies and their accessibility in the web environment, while logical inference and proofs to a large extent demand the co-existence of a full-fledged knowledge base and tailored reasoner with proper inference capability.

3. Knowledge-Driven Decision Support with a Feedback Mechanism

To address the difficulty in choosing the most suitable AM methods for architectural design, we position both formal knowledge and a multi-disciplinary feedback mechanism within the paradigm of design decision support. The underpinning belief for this methodology is that the combinatorial use of formal domain knowledge and machine-understandable communication protocols can effectively reduce the expensive design iterations by proactively considering AM-related constraints and formulating cross-domain communications (see Figure 2). Different research efforts have provided a practically defensible foundation to introduce knowledge formalization, claiming the benefits of fostering manufacturable design and increasing overall productivity for off-site production [22,55]. Additionally, protocol-based, cross-disciplinary communications are deemed contributors to decision-making under multiple design variants [20].

If we apply these to future additive construction projects, the profits will be multi-factorial. A shared knowledge base encoding experts’ knowledge of different AM methods provides a reliable reference for architects, engineers, and contractors during architectural design, numerical simulation and planning stages. Adopting minimized and tailored communication protocols relieves the urgent problem of cross-border collaborations stressed in [37], incorporating different experts from AM material, printers’ mechanics, regulatory approval, etc., into an interoperable framework. The following content in this chapter addresses knowledge-driven decision support with formalized AM knowledge and a tailored feedback mechanism; it then demonstrates a use case integrating the two approaches. To clarify, this paper focuses on explicit knowledge, which is formalizable, rather than its counterpart, tacit knowledge, which is hard to articulate and is usually captured using machine learning techniques [56,57]. Scoped in the TRR277 project, the explicit domain knowledge is formalized and named the AMC knowledge base in the following sections.

3.1. AMC Knowledge Formalization and BIM Integration: Principle and Methodology

In general, three major objectives need to be met to establish a knowledge-driven decision support system for the BIM-based design (Figure 3). As a basis for the system, it is necessary to formalize an AMC knowledge base where ontology and rules are utilized to represent domain knowledge. Next, the knowledge base is integrated and readily used for the BIM-based design—to this, available algorithms and tools are embedded to support geometry analysis and semantics retrieval, as well as an automatic inference from newly given facts. Last but not least, visual and textural feedback should be presented on the BIM-based design to support design adaptations.

Before entering the ontology-building processes, it is indispensable to resolve two questions: “what is the methodology deployed to build the ontology?” and “what is the principle of reuse during the implementation of ontology?”.

Over the decades of research, several ontology-building methodologies have been proposed, while common activities comprise specification, knowledge acquisition, conceptualization, formalization, and validation [58,59,60]. Attributed to the ever-increasing implementations and complex nature of additive construction, domain experts’ knowledge could not be complete or thoroughly comprehended by ontology engineers in a single round. Concluding from that, it is appropriate to follow the lifecycle of an evolving prototype [60]: after each involved activity, if the ontology does satisfy the required evaluation criteria, the previous activity should be repeated to improve the prototype. Furthermore, knowledge acquisition should be performed throughout the whole life cycle in order to capture new or more accurate knowledge to enhance the quality of the ontologies.

To answer the second question, we seek open-accessed ontologies (partially) reusable for additive construction, and best practices can be followed to develop a well-grounded AMC ontology. In the manufacturing domain, many have formalized AM-specific ontologies with the principle of restrictive design for additive manufacturing (DfAM), analyzing the manufacturability of designed parts [61,62,63]. These ontologies provide solid references for the application of a restrictive design for additive manufacturing (DfAM). However, due to the distinctive nature of additive construction, the reuse of these application-level ontologies requires adaptations, including concept re-definition and changes in application scenarios [64]. As to the construction domain, the ifcOWL ontology as an ontological version of the IFC data schema has been adopted for researchers to build up the knowledge bases [55,65]. Meanwhile, Slepicka and Borrmann proposed a set of fabrication information models (FIMs) for material, process, and machinery aspects in additive construction [12]. Nevertheless, ifcOWL falls short in describing resources and capabilities [66], it requires simplifications and clarifications to be properly used for instance graphs and domain ontologies [67,68]. Having a consensus view of ontology interoperability, many have used upper ontologies for domain ontology alignment or as design patterns to create new ontologies. Ocker et al. built an intermediate engineering ontology (IEO) bridging different manufacturing domain ontologies with the upper ontology of DOLCE [69]. The IEEE community makes efforts to align its existing ontologies [70,71] to the DOLCE+DnS Ultralite (DUL). The BFO has been acknowledged in the ISO standard to support information exchange and provide a well-founded computational ground for the development of various domain ontologies, including the industrial ontologies foundry (IOF) ontology [72] for the manufacturing industry and the aforementioned DiCon ontologies for the AEC domain. Currently, both IOF and DiCon still undergo development and lack axioms to support the decision-making of AM-oriented architectural design on which various constraints and requirements may apply.

To conclude, the AMC knowledge base is oriented to early design decision support; it should thus be built from adapting and assimilating feature-based ontologies for manufacturability justification. Practically, it needs to consider legal norms and enforce them as design constraints. Further, the AMC knowledge base should be aligned to an upper ontology in order to organize the heterogeneous knowledge and information over the scope of AMC.

3.2. Ontology Building Processes

To proceed with the building of the AMC knowledge base, the activities mentioned in Section 3.1 are implemented (Figure 4). The following contents in this section will elaborate on each activity in more detail.

3.2.1. Specification

At the very beginning of the specification process, it is necessary to clarify that the knowledge base to be formalized is on the application level for design deci-sion support, hence, it does not aim to provide semantically sound or complete definitions for each of its terms, e.g., regarding the most general concept of the AMC process, it is not able to answer, “what is an additive manufacturing process?”, from the logical point of view. Rather, it should compose groups of operative resources, product categories, essential rules, AM methods’ taxonomies, and descriptive activities such that the following competency questions (CQs) could be answered (

Table 1. Competency questions for AMC ontology.

Index	Competency Question	Reason
CQ1	What is the type of a given AMC process?	Aware of the method type and hierarchy
CQ2	What are the tasks executed for the AMC method?	Descriptive workflow of AMC methods. Potentially used for construction planning.
CQ3	What is the material type that the AMC method can print?	Get the catalog of AMC methods’ printed material types. Match the design intent.
CQ4	What are the constraints for the hardened-state properties of AMC methods’ printed specimens?	Reflect AMC methods’ functions; evaluate AMC methods’ material suitability by comparison.
CQ5	What is the type of machine system used for the AMC method?	Describe the machine system category and link to the determination of the building range; potential used for construction planning.
CQ6	What is the building range of the machine system?	Constrain the building components’ geometry; evaluate AMC methods’ geometry suitability by comparison.
CQ7	What are the manufacturing features important for the AMC method?	Get the catalog for geometry constraints; useful for feature extraction.
CQ8	What are the constraints of the manufacturing feature for the AMC method?	Evaluate building components’ manufacturability by comparison.
CQ9	What is the type of building component?	Describe the type of the building component; basic semantics in BIM.
CQ10	What are the values of the building component’s manufacturing features?	Describe the geometry requirements of the building component to AMC methods.
CQ11	What is the material type of the building component?	Describe the material type of the building component as the requirement for AMC methods.
CQ12	What are the material properties of the building component?	Describe the properties of the building component’s material as the requirement for AMC methods.
CQ13	Except for limitations from AMC methods, is there any constraint that impacts the design of the building components?	Bring AMC methods into actual practice; couple AMC methods with other procedures in construction planning.

).

3.2.2. Knowledge Acquisition

According to Mendonça et al. [73], knowledge acquisition activities involve extraction, elicitation, validation, and refinement. Departing from the Natural Language Processing (NLP)-based term extraction process adopted by [73], the authors have studied a set of peer-reviewed papers for AMC methods, thus elucidating technical terms that are influential to architectural de-sign (e.g., cycle time and open time). An informal questionnaire was drafted as the protocol for semi-structured interviews. Experts in different AMC methods were asked to fill in the questionnaire and complement missing points during the interview session. Eventually, the filled-in questionnaire and relevant bibliography became the basis of the conceptualization process.

3.2.3. Conceptualization

The conceptualization phase figures out the required concepts for AMC and clarifies their relations. To reveal the various constraints imposed by building codes, manufacturing methods, transport regulations, etc., the plan entity was conceptualized (Figure 5). Regarding additive construction, the planning workflow should proactively consider the legal norms (norm entity) and follow suitable manufacturing, assembly, and transport methods. Following the process, product, and resource (PPR) model widely used in the manufacturing domain, AM processes (process entity), building components (product entity), material (resource entity), labor (resource entity), and machine systems (resource entity) are conceptualized and related. To disambiguate the meaning of processes and methods, this work treats process entity as a catchall term without obligation to define involving tasks, agents, or duties, whereas method entity describes a sequence of tasks, required resources, and products as well as a catalog of parameters for quantity, cost, operation time, etc., such that the planning workflow can evaluate, specify and arrange suitable methods for additive construction. The so-called method is more descriptive than precise; hence, it is not mandatory to assign exact values to the defined parameters but these can be deferred to the planning stage. Note that legal norms can be optional in some test projects; this also settles disputes if some flexible and powerful methods easily adapt to and meet the regulatory requirement.

At the component scale, the requirements correspond to the architect’s design intent in terms of the material, geometry, and function of the building components, which are integrated into the BIM-based design. This breakdown facilitates the logic-based evaluation and planning but postulates a well-structured description of the information’s accuracy. To this end, Abualdenien and Borrmann have studied a multi-LOD data model to quantify fuzziness [46]; however, assimilating this concept in the AMC ontology will introduce the fuzzy extension of OWL DL [74] for inferencing capability and is beyond the scope of this work. In the current stage, building components’ semantic and geometry information, once given in the ontology, is deemed certain. Nevertheless, missing information is permissible due to the open-world assumption, and one can resort to the feedback mechanism for adaptive detailing (Section 3.4). To continue, the thermal insulation function of building components can be quantitatively represented as U-values, whereas the load-bearing function is usually binary, contextualized, and tied with both building materials and components’ forms. For simplicity, the AMC ontology parameterizes the load-bearing function with the dichotomy—load-bearing or not, and delegates this function requirement to material properties that are quantifiable.

Although AM methods have brought more geometry freedom, they are constrained to certain kinds of geometry features due to the additive principle. Meanwhile, different AM methods present diverse performances in functional aspects. In this regard, the so-called boundary conditions are special parameters defining the limit of AM methods regarding printed components’ geometry and functions. More specifically, manufacturing features including overhang, cavity, curvature, bounding box, etc., and printed specimens’ mechanical, sound, and thermal properties are quantitatively or qualitatively identified, aggregated to find extremes and set as boundary conditions. Norms also set constraints on the involved methods and might in turn impact the architectural design. With norms considered in the planning stage, disconformities within the design can be informed in the early stages when design adaptations are still cost-effective. For instance, the road freight transport standard defines the item’s maximum transportable dimension, which restricts the size of building components and demands rational decompositions.

Therefore, a requirement-constraint pattern is devised (Figure 6). Requirements are, in general, the material type, material properties, functions, and manufacturing features of a building component. As the counterpart, constraints are inherited from the uptaken norms, and manufacturing and transport methods can be intuitively formulated under the NormParameter and BoundaryConditionParameter entities. Here we arrange the NormParameter in parallel with the BoundaryConditionParameter which is associated with methods; by doing so, constraints can be clearly attributed to either legal norms or methods used for additive construction. During the evaluation processes, these restrictive parameters will be applied to building components through the isManufacturedWith property, such that the parameterized material and functional expectations, manufacturability, as well as norm compliances can be verified by simple rules.

3.2.4. Formalization

Considering the prior determination of description logic (OWL2 DL) for building the ontology, concepts and relations derived from the previous step are encoded as the AMC ontology partially illustrated in Figure 7. The current ontology distinguishes between as-planned and as-printed building components, and the function boundary conditions are elicited from the technical reports conducting tests on the as-printed ones. Such a distinction coincides with the reality that discrepancies do exist between designed and built artifacts, and potentially leaves the space to preserve both in the same data schema for rooting the causes. In Figure 7, the as-planned entities such as BuildingComponent and BuildingMaterial are located in the upper part as requirements; and the as-printed entities of PrintedBuildingComponent and PrintedMaterial are located in the lower part as constraints. The entity regarding material mix design is hidden in the view as it intertwines requirements and constraints.

As illustrated in Figure 8a, the AdditiveManufacturingMethod entity’s intentionality is narrowed by assigning relevant axioms to its superclass. Cardinalities in the conceptual model are transcripted into the property cardinality restrictions in OWL2. In Manchester OWL syntax, “1..*” becomes “some”, and “0,1” becomes “max 1”. The same approach applies to other entities relating to each other with object properties. In Figure 8b, additive construction tasks regarding prefabrication (still in the component scale) are given. With the precedes and hasPart object properties (see Figure 5), these tasks can be sequenced and subdivided. Moreover, each task can be assigned a time period indicating the expected execution time, with resources (resource entity) allocated during the execution. As such, the planning and scheduling of the additive construction can be facilitated.

3.2.5. Validation

In this step, the competency questions listed in Table 1 are analyzed, and subsequently answered with SPARQL queries to prove the correctness of the formalized AMC ontology. CQ1 to CQ8 address the descriptive information about AMC methods including capabilities and constraints, while CQ9 to CQ12 delegate the requirements of designed building components. CQ13 extends the scope of constraints affecting the architectural design. Among these, CQ1 and CQ9 are answered by querying the entities’ direct types. If necessary, the hierarchy of types can also be provided. Q1 shows an example to query the taxonomy of AMC methods from one of its instances, and it can be adapted to answer the CQ9 with substitutions; hence, “METHOD_INST”, “AMC_KB” and “AdditiveManufacturingMethod” should be substituted by specific URIs for method individuals, AMC ontology, and the uppermost class in the hierarchy, respectively:

SELECT DISTINCT ?type

WHERE {<METHOD_INST> rdf:type/rdfs:subClassOf* ?type.

(Q1)

?type rdfs:subClassOf* AMC_KB:AdditiveManufacturingMethod}

If the sequence of executions is interested, CQ2 requires some extra axioms to be answered under the DL profile. Two typical approaches are: introducing a new class to represent ordered collections (elaborated in [49]), or specially creating a subclass to activate the executions. This work opts for the second approach, treats the class SetupTask as the activation task and answers the CQ2 with two queries (Q2 and Q3).

SELECT ?task ?laterTask

WHERE {<METHOD_INST> AMC_KB:sequencesTask ?task.

(Q2)

?task AMC_KB:precedes ?laterTask}

SELECT ?firstTask

WHERE {<METHOD_INST> AMC_KB:sequencesTask ?firstTask.

(Q3)

?firstTask a AMC_KB:SetupTask}

On the other hand, CQ3, CQ5, CQ7, and CQ11 are answered by retrieving the type of entity relating to the given AMC method or building component by following the pattern illustrated in the Q4 which solves the CQ7. Substitutions are required for CQ3, CQ5, and CQ11 with object properties of printMaterial, usesMachineSystem, and hasMaterial.

SELECT DISTINCT ?geometryFeature ?type

WHERE {<METHOD_INST> PREFIX:isLimitedIn ?geometryFeature.

(Q4)

?geometryFeature a ?type.

?type a owl:Class}

The CQ4, CQ6, CQ8, and CQ12 call the data property values regarding parameters for the entities retrieved using Q4; i.e., CQ3, CQ5, CQ7, and CQ11 must be answered beforehand. The common procedure is to obtain the related instance and its object property, then retrieve the data property values from that object property. Here we take CQ8 as an example, assuming the set of manufacturing features important to the AMC methods have already been addressed by Q4. The query Q5 shows the important answer to CQ8—the overhang feature is taken as an example.

SELECT ?FeatureValue

WHERE {<METHOD_INST> AMC_KB:hasBoundaryCondition ?overhangBDC.

(Q5)

?overhangBDC a AMC_KB:OverhangBoundaryCondition.

?overhangBDC AMC_KB:hasDoubleValue ?FeatureValue}

CQ10 is a synthesized question to both the types of manufacturing features and their values that inhere to a building component. As manufacturing features’ parameters differ in data structures, the following query accesses the parameters merely for illustration.

SELECT ?featureParam ?feature

WHERE {<COMPONENT> AMC_KB:hasManufacturingFeature ? feature.

(Q6)

?feature AMC_KB:isParameterizedBy ?featureParam}

CQ13 then considers holistically other types of constraints during construction planning. In the current ontology, there needs to be a planning instance that considers some legal norm, and Q7 shows how to assign the regulatory constraints to the planning instance.

SELECT ?norm ?normParameter

WHERE {<PLAN_INST> AMC_KB:considersNorm ?norm.

(Q7)

?norm AMC_KB:setConstraints ?normParameter}

On top of the ontologies, rules are made using the rule-making language of SWRL. In theory, SWRL extends the expressivity of OWL2 DL [75]; in practice, rules are made to bind manufacturing and planning constraints to design intent such that inferences can be made regarding manufacturability, material conformity, logistics, etc. As Li and Petzold have already addressed this rule-making problem [42,64], this work will not go into detail again.

3.2.6. Alignment to DUL Upper Ontology

Until now, the formalized AMC ontology has been well qualified as an application ontology, but a potential risk is that a thorough understanding of intertwining relations and entities is still missing, thus hindering the ontology‘s extensibility. The DUL upper ontology is simplified from the DOLCE Lite Plus and is enriched with extensions for information objects, plans, systems, legal, and lexical and semiotic domains [76]. It provides a principle to separate a set of assertions (Situation entities) from their interpretations in the non-physical contexts (Description entities); hence, the facts that already exist are treated differently from their conception. Thinking on the formalized AMC ontology, the planning of additive construction, different AMC methods, norms, possibly the material specification, etc., can be well aligned to the subclasses of the Description entity. Meanwhile, the parameters, tasks, and the PPR model (modeled as Role entities) can be categorized as Concept entities. Specific variants under the same AMC method can be observed as individuals of the Situation entity that satisfy (satisfies object property) their uniform Description (Figure 9).

Following the role-based modeling pattern endowed by DUL, the AMC ontology can neatly describe the concrete specification consistently. As shown in Figure 10, the material design as a type of Description defines ingredient roles (aggregates, binder, etc.) which are parameterized with mixing parameters, and the substances (e.g., some sand) take the roles in such a description. The constraint parameters can be assigned to the material specification, while the characteristics of the substances are valued via their attributes.

3.3. BIM Integration and Intuition of Design Adaptation

As proof of concept, we followed the technical framework raised by [42] and implemented a prototype of the knowledge-driven DDSS. As shown in Figure 11, the AMC ontology is made available for the BIM authoring tool (Revit) via a plugin (BIM toolkit), while the inference service is provided by another standard-alone software (DDSS portal). Building components’ geometry and semantic information can be retrieved from a BIM model by relevant APIs and feature extraction algorithms integrated into the BIM toolkit. Afterwards, information about features and semantics is transmitted to the portal through the remote procedure call (RPC). The inference capability of the DDSS portal is enabled by an embedded reasoner working on a local replica of the AMC knowledge base; hence, OWL and SPARQL APIs are responsible for creating, updating, reading, and deleting actions before and after the inference-making.

Figure 12 illustrates the prototype of the DDSS portal. The transmitted information is presented regarding the detected manufacturing features and semantics (Figure 12a). Internally, the information is also created or updated in the local copy of the knowledge base using OWL API. Material properties, machine system information, etc. of AM methods are listed such that the architects are able to compare and filter based on the requirements of building components. The applicability of an AM method is verified by the reasoner according to the SWRL rules and is relayed to the architects (Figure 12b). In case any requirement is not met by the AM method, the architects can set commands to the BIM toolkit for visualization.

Based on the type of requirement and inference results, the BIM toolkit automatically presents suitable visualizations. As illustrated in Figure 13, a parametric Revit “family” representing the bounding box of the machine system’s workspace is aligned to the evaluated building component. As the building component’s oriented bounding box (OBB) has been computed during the feature extraction phase, aligning the Revit family to this freeform geometry turns into trivial positioning and orientation from one cubic box to another via Revit API. It seems that, with these parametric Revit families available during the design stages, architects will be supported to generate a design that adapts to the constraints of manufacturing dimensions. However, this cannot be easily achieved completely by architects; for instance, partitioning a large wall into pieces will require extra structural analysis for the building and an overview of AM methods. Therefore, we conclude that the current knowledge-driven decision support could assist architects in finding potential problems in the early stages, but solving the problems still demands technical expertise in other fields.

3.4. Feedback Mechanism for AMC

Previous sections have elaborated on the knowledge-driven DDSS, especially the AMC knowledge base. The following part will introduce a feedback mechanism for communication between architects and engineers, and subsequently demonstrate a use case in AMC.

3.4.1. Introduction of the Feedback Mechanism

In the early design stages, the BIM model is still immature and could not be qualified for numerical analysis and performance assessment. Based on a CDE where BIM models are stored and collaborated on by architects and domain experts, architects can communicate with the experts and receive their feedback for design detailing and decision support. To improve efficiency and traceability throughout communications, Zahedi and Petzold [48] proposed the use of a ticketing system with a feedback mechanism. Similar to any other ticketing system, this system sets the priority for each ticket and traces the responses from domain experts. The communication can be initiated by sending requests or tasks within a ticket; afterwards, experts’ responses are embedded in the feedback mechanism. This mechanism aims to provide a machine-readable communication protocol to adaptively detail the design and evaluate possible design variants. In general, three types of feedback are provided:

• Missing details in the design model which are critical for analysis
• Suggested options that meet the design requirements or fulfill the shortcomings
• Related results of simulations or analysis

To meet the varying needs under different scenarios, the feedback function is structured with different arguments as follows:

Feedback (actionType, optionGroupID, GUID, schemaX, objectID, propertyID, value)

The first argument as actionType represents a use case for the feedback function. The possible value ranges are: missingObject, missingObjectProperty, createNewObject, deleteObject, and updateObjectProperty. Intuitively, missingObject handles the general use case where some building components are (suspiciously) missing from the engineers’ point of view, such as missing opening(s) on the side of a living room near the balcony—which impacts the analysis result of energy consumption. The missingObjectProperty refers to the incomplete properties or semantic information that needs to be filled out by the architects—a typical example is the strength (class) of the building material. On the other hand, createNewObject means a new component to a newly created building component (possibly as part of options) by a domain expert (consultant), depending on the architect’s acceptance or objection. The newly created component has a unique GUID that will be used to reference the object. Together with the newly created ones, some existing objects may be deleted. DeleteObject could also be assigned when engineers think some objects introduce significant side effects that are hard to deal with. UpdateObjectProperty is used to indicate to the architect of the suggested property value(s) as option(s).

The next argument, optionGroupID, helps to group multiple suggestions and is optional, i.e., advised details can be individually treated or grouped together as batch information. This brings efficiency in accepting or rejecting the modifications in a package. When properly arranged, this will also help to keep the consistency in the BIM model because building components are always topologically and functionally interdependent. The argument of GUID holds the global identification IDs of the building components over the CDE and inheres to them—that is, if the building components cease to exist, their GUID parameters also vanish. If the actionType in the feedback function is missingObject, then this argument (GUID) will be the unique ID of the hosting build component. As to the example where the openings are absent, this GUID might belong to the wall adjacent to the balcony. Similarly, for missingObjectProperty and updateObjectProperty, the GUID applies to the existing building component which lacks specific object properties, while createNewObject action sets a GUID on the temporary newly created object advised by the domain expert to the architect. Finally, when the actionType is deleteObject, this GUID refers to the build component that the domain expert suggests deleting.

For each type of analysis, there is a list of critical information that has to be provided. The schemaX argument then plays as a dictionary for analysis of specific information exchange between architects and domain experts; for instance, life cycle assessment (LCA) requires the input value of window-to-wall ratio, u-value, wall thickness, etc., which are classified as propertyID for different types of building components (objectTypeID). It follows the so-called adaptive LOD model (aLODx) from the work of [48], but relaxes the specification of the multi-LOD data model in the meantime, i.e., this schemaX is less structured and could be adjusted with the advances of AMC. Further details on the feedback mechanism and how to use it are discussed in the works of [48].

3.4.2. Use Case

We continue with the scenario prescribed in Section 3.3: when an architect realizes the problem of oversized building components, he or she could initialize communication with a structural engineer who is responsible for structural analysis and code compliance. At this stage, a ticket will be sent to the engineer, requesting the decomposition of the wall into manufacturable pieces for an AM method. On the basis of some understanding of AM technology, the architects could be inclined to deploy some specific AM method(s) already and embed this information in the ticket.

Upon receiving this request, the structural engineer should have an overview of the design for the building (or a zone with other building components connected), information on AM methods, and applicable standards for regulatory approval. The engineer is able to retrieve the material information from the given AM method noted in the ticket: whether the concrete is reinforced, the density, thermal conductivity, etc.

With adequate information at hand, the engineer proposes two options of decomposition, essentially, a two-way vertical decomposition with one of the parts for load-bearing, or a three-way vertical decomposition with both sides as load-bearing components (Figure 14). The rationale behind this is that the engineer finds out that the AM method is able to integrate reinforcement, and subsequently suggests the two-way option following the code of concrete structure, as well as the three-way option analog to masonry construction. These options are encapsulated in the feedback function as a response to the architect. Finally, the architects will choose one of the options by evaluating practical criteria such as cost, construction time, etc. On this basis, more complex scenarios can be created; for instance: an AM expert knowing the impacts of cycle time on the mechanical performance would stress the minimum dimension of a building component to assure stability during building up. To verify the feasibility of decomposing options, the structural engineer can also initiate a ticket and send it to the AM expert, who will have access to the process parameters stored in the knowledge base for further evaluation.

From the depicted case above, we noticed a smooth design workflow assisted by the knowledge base and feedback mechanism. While the knowledge base enables the early recognition of conflicts between design and manufacturing, the feedback mechanism bridges the subsequent design development and domain-specific expertise. Both techniques are able to address the problems (semi-)automatically. It can be concluded that the methodology of synergizing formal domain knowledge and feedback mechanism is forward-looking, and we look forward to its development in additive construction.

4. Discussion

This paper addresses the explicit dimension of AMC knowledge and brings it to the early decision of proper manufacturing methods. Compared to previous efforts (e.g., [61,62,63]) in formalizing AM knowledge, this work has additionally introduced the terms for planning stages when regulations could further restrict the design and preliminarily align the ontology to DUL, such that the multidisciplinary knowledge in AMC can be modeled with consistency. Integrating the description and situation plugin (see Section 3.2.6) [77,78], DUL ontology with its extensions can represent contexts (e.g., laws, plans, assessments) and their executions which are less formal or missing in other ontologies, even in comprehensive ones such as [52,72] and similar; however, terms of “capability” and “function” useful in the engineering domain are not explicitly formalized in the DUL ontology but in BFO (and its proposal) [79]. The AMC ontology would have to seek appropriate tradeoffs during the alignment and even mapping stages after gaining insights into the differences between DOLCE and BFO ontologies [80]. With this in mind, we are temporarily inclined to DUL but would look into other possibilities in the future.

In the case of manufacturability evaluation, the major limitation of our approach lies in the computational complexity of extracting manufacturing features from any geometry object. This is an inherent problem for knowledge-based manufacturability determination and has also been discussed by Mayerhofer et al. [61]. With the increasing capability of computational resources, machine learning (ML) methods have gained attraction in many domains and are unsurprisingly applied in the AM. For instance, Zhang et al. utilized the convolutional neural network (CNN) method to evaluate the designed parts’ manufacturability and presented acceptable accuracy [81]. Nickchen et al. further evaluated the possibilities of ML in the AM process chain for 3D component recognition and manufacturing cost estimation [82]. While acknowledging the potentials of ML in solving complex problems in AM-oriented design, logic-based reasoning holds its position in areas where human’s knowledge can be explicitly expressed (the counterpart of tacit knowledge [56]) and heterogenous information is organized. As to AMC, explicit design rules can apply to the early-staged design, and multiple aspects of additive construction can be coordinated using the AMC ontology. In fact, researchers have already been investigating the synergy of ontologies and ML methods and predicted it as a promising direction [83,84]. Therefore, we can improve the proposed logic-based method on the one hand and look forward to the integration of ML methods for enhanced decision support on the other hand.

Another contribution of the work is to propose the joint use of formal knowledge and a feedback mechanism for decision support—which, to the authors’ knowledge, has not been well studied for additive construction. The proposed methodology does not much stress the formal knowledge for which the expressiveness and computation complexity are often at odds; further, it complies with the common practice in AEC where different experts cooperate on the same project and has the potential to enhance the negotiations which are usually desultory and inconsistent.

5. Conclusions

AM technology and BIM are considered to be the driving force for the revolution in AEC. To solve the problem of missing knowledge at the early stage of architectural design, this work proposes the use of formal knowledge and communication protocols for BIM-based design decision support. In the scope of AMC, we elaborated on these two factors by describing the knowledge formalization and integration procedures, as well as feedback mechanisms that emphasize the importance of interprofessional negotiation. This work focuses more on the knowledge formalization activities and envisions the alignment to the DUL upper ontology, aiming to provide a solid foundation for the current logic-based reasoning.

Nevertheless, the proposed methodology needs to be strengthened in the future from the following aspects:

• The alignment of the current AMC ontology to DUL needs to proceed and must consider important terms of Function, ManufacturingFeature (even Feature), BoundaryCondition, etc. Some modifications may be made to the current AMC ontology, and DUL will be referenced as a design pattern once inconsistencies are found during the alignment process.
• The aligned ontology could be used to organize heterogeneous information including digital resources, linguistics, robot mechanics, etc.
• Efficient feature extraction algorithms should be explored in order to take the flexible slicing directions and the robot’s high DOF into account.
• Explanation functionality for the inference results would greatly improve the comprehensibility of the DDSS and should be further developed.
• More task-specific communication schemas must be identified with domain experts familiar with conventional construction methods and AM optimization. Last but not least, a framework incorporating the knowledge base and feedback mechanisms should be implemented in the future such that the architects and engineers are engaged in a smooth and productive design workflow.