Implementation of the Proposed Approach
The implementation of the approach is based on an existing prototype for conceptual structural design which is called StAr (Structure-Architecture). StAr is a prototype system that assists engineers in the inspection of a 3D architectural model (e. g. while searching for continuous load paths to the ground) and the configuration of structural solutions. Assistance is based on geometrical reasoning algorithms (GRA), (Mora et al. 2006B) and an integrated architecture-structure representation model (ASM), (Mora et al. 2006A). The building architecture in the ASM representation model describes architectural entities such as stories, spaces and space aggregations, and space establishing elements such as walls, columns and slabs. Figure 2 illustrates an architectural model in StAr. The structural system is described in StAr as a hierarchy of entities to enable a top-down design approach, as discussed in section 3. Figure 3a illustrates core walls identified by StAr as continuous and selected by the engineer as structural, and Figure 3b presents the structural system generated by StAr. The geometric algorithms in StAr use the geometry and topology of the ASM model to construct new geometry and topology, and to verify the model. The algorithms are enhanced with embedded structural knowledge regarding layout and dimensional thresholds of applicability for structural assemblies made out of cast-in-place concrete. However, this knowledge is not sufficient for assisting engineers during conceptual design. StAr provides the kind of support described in the second column of Table 1, plus limited knowledge-based support (column 3) at levels 1.b and 4. Therefore, StAr is able to generate and verify a physical structure based on information obtained from precedent levels. However, no knowledge-based support is provided by StAr for exploration at levels 2, 3 and 4. This is the subject of this research. In addition, work is currently in progress to provide StAr with a graphical user interface (GUI) for inputs to replace the current interface with alphanumeric interactions with graphical outputs.
A structural design knowledge manager (DKM) is therefore being developed that gets architectural and/or partial structural information from the ASM directly or via GRA to assist the engineer to conceive, elaborate and refine structural solutions interactively. Once the engineer accepts a solution suggested by the DKM, it automatically updates (i. e. elaborates or refines) the partial ASM. Architectural requirements in the form of model constraints (e. g. floor depths, column-free spaces, etc.) from the ASM model are also considered by the DKM for decision-making.
(a) Structural walls selected by the engineer using StAr (b) Structural system generated by StAr Figure 3. Structural system in StAr (after Mora et al. 2006B)
The DKM encapsulates structural design knowledge by means of a set of technology nodes (Gomez 1998, and Fenves S. J., Rivard H., and Gomez N. 2000). The type of knowledge incorporated in the nodes is heuristic and considers available materials, construction technologies, constructability, cost and weight. A technology node represents the knowledge required to implement one design step (in the top-down hierarchy) utilizing a specific construction system or component. Nodes are organized into a hierarchy ranging from nodes dealing with abstract concepts (e. g. a structural subsystem) to those dealing with specific building entities (e. g. a reinforced concrete beam). The application of a technology node to a building entity from the ASM can be interpreted as making one decision about a design solution. Technology nodes support non-monotonic reasoning since they let the engineer retract any decision node and select another path in the technology tree.
Given that the StAr prototype is being enhanced with the design knowledge manager (DKM), the example that follows illustrates the envisioned support for interactive exploration of conceptual structural design solutions. In the example, the support already provided by StAr is indicated as well as the support envisioned by the DKM. DKM-StAr is used to indicate that some basic support is already provided by StAr but enhanced support is required from the DKM.
As explained in section 1, the approach is applicable to most typical buildings, such as office, apartment and institutional buildings of standard (i. e. non-sculptural) shape. However, the example uses a deceptively simple office building with little architectural constraints in order to emphasize the knowledge-based interactive exploration of structural alternatives. Office buildings are characterized by having flexible space layouts which provides more room for structural layout exploration at the subsystem level. The building has a rectangular shape with 12-stories of offices, two parking levels underground. The building is located in an intermediate seismic zone. As shown in Figure 4 the building dimensions in plan are 48 m x 18 m. A 12 m x 6 m vertical circulation core is located at the center of the building. Column-free stories are preferred by the architect, storey heights are limited, and the facade must be as free as possible from structural elements. In Figure 4, space-organizing architectural grids are laid out and tentative column locations are proposed by the architect. However, the functional dimensions from the architecture are multiples of 3 m (e. g. 6 m, 9 m, 12 m, 18 m, etc). These dimensions are suitable to accommodate the parking spaces underground.
Figure 4. Floor plan of example office building (dimensions in meters)
After the inspection of the architectural model, the engineer selects the core walls to become structural. Then engineer defines one independent structural volume for the entire building. For this example no seismic or expansion joints are necessary as confirmed by the DKM. Next, the engineer selects four structural zones and the computer assigns applied loads to them accordingly: one for the parking stories (2.4 kN/m2), a second zone grouping all the spaces in the ground floor (4.8 kN/m2), a third zone grouping the office levels above the ground (2.4 kN/m2), and a fourth zone being the equipment penthouse on top (3.6 kN/m2). The current implementation of StAr assists the engineer in performing these initial tasks.
Next, the engineer explores overall load-transfer solutions (structural subsystems) as follows: vertical gravity loads will be transmitted primarily through column stacks and partly through the central core. Horizontal and lateral load transmission can be accomplished in several ways. For lateral loads the load transfer alternatives can be summarized: (1) rigid frames in one or both directions, (2) braced frames in one or both directions, (3) the central core only acting as a tube, (4) the building perimeter and the core acting as concentric tubes, and (5) a combination of the above. Through simple calculations the engineer verifies that the central core alone does not provide sufficient rigidity for overturning. Therefore, alternative number (3) is eliminated. Alternative number (4) is also eliminated because it involves overcrowding the facade with structural elements. In order to select an overall load transfer solution for the building, the engineer decides to explore three alternative structural layouts that s/he sketches using StAr (see Figure 5).
Figure 5. Alternative structural grids
For each structural layout the engineer proposes suitable load transfer solutions (using his/her own experience), which are validated by the DKM. Alternatively, the engineer may ask the DKM to suggest a feasible structural solution for each layout proposed. The overall load transfer solutions proposed by the engineer and validated by the DKM are described in Table 2. In Table 2, WF means wide flange (i. e. W shape beam). For all cases the engineer specifies that the building core also contributes to lateral support, and that vertical gravity load transfer is provided by column and wall stacks.
Table 2. Overall load transfer alternatives (i. e. at the subsystem level)
For the evaluation of the most suitable structural solution at the subsystem level, each solution should be ranked by the DKM considering several factors including estimated structural system cost and weight and the effect of the structure on the architectural cost, cost of the foundation, soil conditions, constructability, architectural requirements and constraints, and integration with mechanical electrical and plumbing (MEP) systems.
From a structural standpoint, alternatives number 2 and 3 are more stable because they provide more vertical supports for transferring the loads to the ground. However, these are also heavier structural solutions, alternative number 3 being the heaviest one. Alternatives number 2 and 3 are also more intrusive in spaces and facades than alternative one. However, they provide lower floor depths which are beneficial for building cost, constructability, and integration with MEP systems. Nevertheless, open web joists allow the passage of ducts and pipes through the joists. Alternatives number 2 and 3 distribute the load more uniformly over the foundation. However, heavier loads are also transmitted. The evaluation criteria can be customized to associate a weight for each factor and augmented to incorporate experiences from new projects.
With the rankings and data provided by the DKM, the engineer may try to persuade the architect to trade-off two columns inside spaces for lower building costs with shallower floor depths. It is assumed that the alternative number 2 is accepted by the architect with the condition that no braced frames should be placed. A modified alternative 2 is therefore selected with rigid frames instead of braced frames.
Then, the engineer proceeds to select and position each structural assembly individually. The DKM advises the engineer about the convenience of minimizing rigid connections with steel. For the vertical lateral subsystem, in the short direction the engineer specifies two interior rigid frames and in the long direction two rigid frames along the facades covering only the two mid-spans (see Figure 6). The remaining frames or frame sections are simple gravity. For the horizontal subsystem, a partial decision tree is described in Figure 7.
At the assembly level, the floor framing directions are determined by DKM-StAr (see Figure 6) and steel deck sections are identified, along with open web joist and W shape beam types. These are grouped by lengths (from the different bays) and the load that they carry. However, assemblies are yet populated with elements. At the element level, the engineer does not detect any openings or irregularities that may cause structural support problems and therefore no support verifications are required. Then, each floor assembly is populated with structural elements by DKM-StAr. Figure 8 illustrates a floor assembly for a typical floor (i. e. excluding the ground floor, the roof, and the first basement).
A fundamental difference between this approach and the ones proposed in section 2 is that here the architectural model is created by an architect and not by an architecturally constrained AI system, and alternative structural subsystems and layouts are proposed by the engineer and not by the computer. The computer only evaluates alternatives and suggests solutions on demand. Following this approach, the engineer can develop a structural a solution down to the assembly and element levels with knowledge-based assistance that corresponds to the level of detail required by the engineer.
An approach for knowledge-based interactive conceptual structural design has been proposed. The approach simplifies the conceptual design process by enabling the engineer to focus on the essential features only at each abstraction level while enabling quick structural synthesis. It has the following advantages over commercial applications for structural model generation: (1) it facilitates design exploration by proposing feasible design alternatives and enabling non-monotonic reasoning, (2) it constitutes a more efficient method for conceptual structural design because it simplifies the design problem by decomposition/refinement, (3) it enables more integrated design solutions because it uses structural design knowledge to evolve an architecturally constrained building information model, and
(4) it facilitates decision-making and early architect-engineer negotiations by providing quantitative evaluation results. This research is work in progress. A knowledge-base is under development will be integrated to an improved StAr prototype.
The authors wish to acknowledge the financial support for this research from the Natural Science and
Engineering Research Council of Canada (NSERC) and the Canada Research Chair Program (for the
Chair in Computer-Aided Engineering for Sustainable Building Design).
Bailey S. and Smith I. (1994). “Case-based preliminary building design”, ASCE J. of Computing in Civil Engineering, 8(4), 454-467.
Bedard C. and Ravi M. (1991). “Knowledge-based approach to overall configuration of multistory office buildings”, ASCE J. of Computing in Civil Engineering, 5(4), 336-353.
Eisfeld M. and Scherer R. (2003). “Assisting conceptual design of building structures by an interactive description logic based planner”, Advanced Engineering Informatics, 17(1), Elsevier, 41-57.
Fenves S. J., Rivard H., and Gomez N. (2000). “SEED-Config: a tool for conceptual structural design in a collaborative building design environment”, AI in Engineering, 14(1), Elsevier, 233-247.
Gomez N. (1998). Conceptual structural design through knowledge hierarchies. PhD thesis, Department of Civil and Environmental Engineering, Carnegie Mellon University, Pittsburgh.
Grierson D. E. and Khajehpour S. (2002). “Method for Conceptual Design Applied to Office Buildings”, ASCE J. of Computing in Civil Engineering, 16, 83-102.
Jain D., Krawinkler H., Law K. (1991). “Logic-based conceptual structural design of steel office buildings”, Report No 49, Center for Integrated Facility Engineering, Stanford University.
Khemlani L. (2005). AECbytes product review: Autodesk Revit Structure, Internet URL: http ://www. aecbytes. com/review/RevitStructure. htm.
Kumar B. and Raphael B. (1997). “CADREM: A Case-based system for conceptual structural design. Engineering with Computers”; 13(3), 153-164.
Maher M. (1988). “Expert systems for structural design”, J. of Computing in Civil Engineering; 1(4), 270-283.
Meyer S. (1995). “A Description of the structural design of tall buildings through the grammar paradigm”, Ph. D. Thesis, Dept. of Civil Engineering, Carnegie Mellon University, Pittsburgh.
Mora R., Rivard H., Bedard C. (2006A). “A computer representation to support conceptual structural design within a building architectural context”, ASCE J. of Computing in Civil Engineering, to be published in the March issue.
Mora R., Bedard C., Rivard H. (2006B). “Geometric modeling and reasoning for the conceptual design of building structures”, submitted for publication at the Journal of Advanced Engineering Informatics, Elsevier.
Rafiq M., Mathews J., Bullock G. (2003). “Conceptual building design – evolutionary approach”, ASCE J. of Computing in Civil Engineering; 17(3), 150-158.
Rivard H. and Fenves S. J. (2000). “A representation for conceptual design of buildings”, ASCE J. of Computing in Civil Engineering, 14(3), 151-159.
Sacks R., Warszawski A. and Kirsch U. (2000). “Structural Design in an automated building system”, Automation in Construction, 10(3), Elsevier, 181-197.
Shea K. and Cagan J. (1998). “The design of novel roof trusses with shape annealing: assessing the ability of a computational method in aiding structural designers with varying design intent”, Design Studies; 20, 3-23.
Sisk G., Miles J., Moore C. (2003). “Designer centered development of GA-based DSS for conceptual design of buildings”, ASCE J. of Computing in Civil Engineering, 17(3), 159-166.
Soibelman L. and Pena-Mora F. (2000). “Distributed multi-reasoning mechanism to support conceptual structural design” ASCE J. of Computing in Civil Engineering; 126(6), 733-742.
Solibri Inc. (2005). Solibri Model Checker, Internet URL: http://www. solibri. com/services/ public/main/main. php, last visited 6/10/2005.