Title: Design and Implementation of an Integrated Structural Design System

Authors: Chee Kyeong Kim, Professor, Sun Moon UniversitySi Eun Lee, Professor, Baekseok College

Subject: Structural Engineering

Keywords: StructureTechnology

Publication Date: 2004

Original Publication: CTBUH 2004 Seoul Conference

Paper Type: 1. Book chapter/Part chapter2. Journal paper3. Conference proceeding4. Unpublished conference paper5. Magazine article6. Unpublished

© Council on Tall Buildings and Urban Habitat / Chee Kyeong Kim; Si Eun Lee

ctbuh.org/papers

1112 CTBUH 2004 October 10~13, Seoul, Korea

Design and Implementation of an Integrated Structural Design System

Chee Kyeong Kim1, Si Eun Lee2

1 Professor, Sunmoon University 2Professor, Baekseok College

Abstract Rational data modeling is prerequisite to the computerization of design works and the use of design

information in the following works such as cost estimation and construction. Particularly, structural design of buildings consists of a long series of unit steps and it is non-procedural and data-intensive comparing with structural analysis problem which is procedural and computation-intensive. Hence, there is a need to investigate characteristics of the problem and to properly structure design information to effectively manage it in the structural design process. This paper discusses modeling concepts to manage design information efficiently and to support the design process effectively. TLG object modeling is the conceptual backbone of the model of this study and provides a consistent modeling of structural components including not only primitive members such as beams and columns but also composite ones such as floors, frames, and even whole buildings.. An integrated structural design system for buildings has been developed based on these modeling concepts and brief discussion about how the object model works throughout the whole structural design process in the integrated structural design system is given at the end of this paper. Keywords: Structural Design, Data Modeling, Computer-Aided Engineering 1. Introduction

In construction industry, information technology is extending its range toward the integration of all the activities and CIC (computer-integrated construction) or construction CALS are among them. Design information is at the heart of these digital integrations. Digitalized design information is to CIC or CALS what blueprint drawings are to the traditional construction. Therefore, rational digitalization of design information and computerization of design process to generate digitalized design information are prerequisite and essential to higher-level integration.

Structural design is one of the major design activities for buildings. In the structural engineering, it has been long continued to use computer for structural analysis which is procedural and computation-intensive. Recently, there have been many researches for the computerization of design problems. Design problems have their own characteristics which are matters out of consideration in the procedural and computation-intensive problems which have been regarded as suitable ones for computerization. Structural design consists of a long series of unit processes and a large amount and various kinds of data are generated and used throughout the

process. In many cases, they are generated, used and changed non-procedurally and there are more dependencies between them comparing with structural analysis problems. It means that structural design has a data-intensive characteristic. Therefore, rational data management is a key to the successful development of a structural design system.

In this research, an integrated structural design system has been developed. It can assist engineers throughout all the structural design process for buildings from the initial planning to the final detail design of members. This system involves numerous data including not only the final design information but also temporary data used in the process of design. This paper discusses an object-oriented data model which is a part of the system. The model serves both the final design information and temporary data required in each unit process. This paper presents only the overall framework and some important concepts because the whole model is so large to describe the details in a paper

2. Concept of TLG Object Modeling

From the information management aspect, the repetition of same type of structural components should be managed efficiently without information redundancy. This repetition results from the grouping of structural components. The components can be primitive members such as beams and columns, or composite ones such as floors, frames, and column lines. In a building, several girders would be grouped

Contact Author: Chee Kyeong Kim, professor, Dept. of Architectural Engineering, Sunmoon Univ., Asan-si, Chungnam, 336-708, Korea Tel: +82-41-530-2321 Fax: +82-41-530-2839 e-mail: ckkim@sunmoon.ac.kr

CTBUH 2004 October 10~13, Seoul, Korea 1113

as “G1” and it means all the girders have same section properties. It is an example for the primitive member level grouping. In addition, it is possible to group several floors into a floor type named “Typical Floor Plan” if they have same shape and member lay-out. It is an example for the composite component level grouping.

To model efficiently these repetitions in structural design information, TLG object modeling and reference domain concept was devised. In TLG modeling, a structural component is defined into three objects. They are type object, local instance object, and global instance object each defined in type, local, and global domain respectively.

Figure 1 (a), (b), (c) show how a column can be defined into three objects. They are SSColumnT type object defined in type domain of figure 1 (a), SSColumnL local instance object defined in local domain of figure 1 (b), and SSColumnG global instance object defined in global domain of figure 1 (c). In the name of objects, the prefix SS means that it is a structural component object. The suffix T, L, G means

type, local instance, and global instance, respectively. The component name is located between the prefix and suffix.

3. Type Objects defined in type domain

Some properties of a structural component can be defined within the scope of the component itself regardless of the whole scope and shared with many other components of the same type. For example, the sectional properties of the column, marked by ① in figure 1 (c), can be described separately apart from other parts of the building as shown in figure 1 (a), and shared with any other 11 columns of the building given in figure 1 (c) because they have same sectional properties. In this case, it is an efficient way of managing information to define the shared properties only once and let all the components refer to it. A type object is what consists of only this kind of attributes and are referred to. A type domain means a space in which the type objects can be described, and it is inside of the component itself regardless of the whole scope.

(A) Type Domain

• Domain Scope : column itself

• Domain where type objects are defined

• Column Object Name : SSColumnT

• Sample Attribute : sectional properties

C1

500

500

Typical Floor

A (B) Local Domain

• Domain Scope : floor plan type

• Domain where local instance objects are defined

• Object Name : SSColumnL

• Sample Attribute : Location in the plan

C1 C1

C1 C1

Roof Floor

Typical Floor

Typical Floor

Typical Floor

(C) Global Domain

• Domain Scope : whole building

• Domain where global instance object are defined

• Object Name : SSColumnG

• Sample Attribute : Member Forces

A

Figure 1. TLG Object Modeling

1114 CTBUH 2004 October 10~13, Seoul, Korea

Figure 1 (b) shows another example for type object. It is a floor type object named “Typical Floor”, and is referred to 3 times by floors from 1st to 3rd. In this case, the detailed shape and member layout is described only once as a type object and all the actual floors of that type refer to it. Like this, type object can be defined not only for primitive components but also composite components such as floors, frames, and even buildings. The type domain for floors may be a horizontal plane in which each member is located shown in figure 1 (b).

4. Local Instance Objects defined in Local domain

A type object of a composite component consists of many primitive components or lower-level composite components. The “Typical Floor” floor type object in figure 1 (b) has 4 columns of type “C1” and a slab. In this case, all 4 columns have same sectional properties, but their location in the floor plan is different from each other. It means that some attributes of a component should be described in the scope of a

higher-level type object. A local instance object is what has only this kind of attributes and is a part of higher-level type object. A column local instance object has the location information in a floor plan type as one of its attributes. In general, a local instance object refers to a type object to keep its type information. All 4 column local instance objects, which are assembled into “Typical Floor” floor type object, refer to “C1” column type object. A local domain means a space in which the attributes of local instance objects can be described. A local domain for local instance objects is the type domain for higher-level type object. The type domain for “Typical Floor” floor type object is the local domain for the columns.

This relationship of lower-level local instance objects and a higher-level type object may exist between composite components recursively. Considering the building in figure 1 (c) as a building type object, it has 4 floor local instance objects. One of them is “Roof Floor” type located on roof floor, and 3

Class Name(from PackageName) Multiplicity

AggregationAssociation

LEGEND

Class

+Role

UnidirectionalAssociation

+Role

Multiplicity

Class Name(from PackageName) Multiplicity

AggregationAssociation

LEGEND

Class

+Role

UnidirectionalAssociation

+Role

Multiplicity

SSBeamT(from SCFM)

SSColumnT(from SCFM)

SSWallT(from SCFM)

SSFloorT(from SCFM)

SSSlabT(f ro m SCF M)

SSBuildingT(from SCFM)

SSBuildingL(from SCFM)

1..*1 1..*

+m_CompoT

1

SSBuildingG(from SCFM)

+m_CompoL

1..*11 1..*

SSFloorG(from SCFM)

SSFloorL(from SCFM)

11..*

1

+m_WholeObject

1..*

1 0..*

+m_Com poT

1 0..* 1 1..*

+m_CompoL

1 1..*

SSBeamG(from SCFM)

SSBeamL(from SCFM)

0..*0..*

1 0..*

+m_Com poT1 0..*

1 1..*1 1..*+m_CompoL

SSColumnG(from SCFM )

SSColumnL(from SCFM)

1

0..*

+m_WholeObject

1

0..*

1 0..*

+m_CompoT1 0..*

1 1.. *1 1.. *+m_Com poL

SSW allG(from SCFM)

SSW allL(from SCFM)

0..*0..*

1 0.. *+m_Com poT1 0.. * 1 1.. *1 1.. *

+m_CompoL

SSSlabG(from SCFM )

SSSlabL(from SCFM)

0..*0..*

1 0.. *

+m_CompoT1 0.. * 1 1..*1 1..*

+m_CompoL

Type ObjectType ObjectLocal Instance

ObjectGlobal Instance

Object

BuildingObject

FloorObject

MemberObject

Figure 2. TLG Modeling of a Building

CTBUH 2004 October 10~13, Seoul, Korea 1115

of them are “Typical Floor” type from 1st floor to 3rd each. Like this, the relationship of lower-level local instance objects and a higher-level type object can be formed recursively between more complex composite components.

5. Global Instance Objects defined in Global domain

Lastly, some properties of structural components should be defined in the whole building. Considering the 3 columns at the left bottom corner between the 1st floor and the 3rd, they are of same type and share the “C1” column type object. In addition, they are at the same location in the floor plan and share a local instance object defined in “Typical Floor” floor type object. However, the member forces of them are different from each other, and they should be described respectively. It means that some properties of a component should be described in the scope of the whole building. A global instance object is what has only this kind of attributes. A column global instance object has the member force information as one of its attributes. The final structural design information which consists of member layout with their section properties can be represented only by type and local instance objects without global instance objects. More detailed will be given in the next section. However,

global instance objects hold a more important position in the construction and maintenance stage because each component should be treated individually contrary to the design stage. In general, a global instance object refers to a local instance object to keep its additional information which is managed by local instance object and type object. Twelve column global instance objects are assembled into the whole building as shown in figure 1 (c). Global instance objects are same ones that exist in the real world. A global domain means a space in which the attributes of global instance objects can be described. It is exactly the real world space and there is only one global domain contrary to type domain or local domain.

6. Basic Approach to TLG Modeling for a Building

Figure 2 shows how a building object can be modeled based on TLG object modeling concept. It is not the exactly same one of this study because it is simplified to explain the concept of TLG object modeling and relationships between them. Aggregation associations are used to represent that a higher-level type object consists of many lower-level local instance objects of various kinds of components, and unidirectional associations are used to represent that local instance objects and global instance objects refer

SSBuildingT_Samplem_TID = 1m_Name = SSBuildingT_Samplem_DesignCode = ACI02m_NumStories = 3m_Location = Seattle, WAm_Usage = Officem_Analysis = ETABS

SSFloorL_1stm_LID = 1m_Name = 1st Floorm_FloorNum = 1m_Height = 0

SSFloorL_2ndm_LID = 2m_Name = 2nd Floorm_FloorNum = 2m_Height = 4000

SSFloorL_3rdm_LID = 3m_Name = 3rd Floorm_FloorNum = 3m_Height = 7500

SSFloorL_Roofm_LID = 4m_Name = Roof Floorm_FloorNum = 4m_Height = 11000

SSFloorT_Roofm_TID = 2m_Name = Roof Floorm_Width = 8000m_Height = 6000

+m_CompoT = 2

SSColumnT_C1m_TID = 4m_Name = C1m_Width = 500m_Depth = 500m_Rebar = 8-#9

SSColumnL_LBm_LID = 5m_X = 0m_Y = 0

SSColumnL_RBm_LID = 6m_X = 8000m_Y = 0

SSColumnL_LTm_LID = 7m_X = 0m_Y = 6000

SSSlabL_TYP1m_LID = 9m_X1 = 0m_X2 = 8000m_Y1 = 0m_Y2 = 6000

SSSlabL_ROOF1m_LID = 10m_X1 = 0m_X2 = 8000m_Y1 = 0m_Y2 = 6000

SSSlabT_S1m_TID = 5m_Name = S1m_Thick = 150m_Rebar = #9@200

+m_CompoT = 5

+m_WholeObject = 1

SSColumnL_RTm_LID = 8m_X = 8000m_Y = 6000

+m_CompoT = 4

SSFloorT_Typicalm_TID = 3m_Name = Typeical Floorm_Width = 8000m_Height = 6000

+m_CompoT = 3

+m_SlabLs

+m_WholeObject = 3

+m_WholeObject = 2

Figure 3. Development Diagram of Type and Local Instance Object

1116 CTBUH 2004 October 10~13, Seoul, Korea

to a type object and a local instance object, respectively. In this model, one building type object (SSBuildingT) consists of floor local instance objects (SSFloorL) located on each floor. This aggregation association is realized by a m_WholeObject attribute of part objects which is SSFloorL in this case. Each floor local instance object has attributes which describe their position within the building type object, and are associated to floor type object (SSFloorT) by m_CompoT attribute.

Each floor type object is composed of several member local instance objects (SSBeamL, SSColumnL, SSWallL, SSSlabL) located within the corresponding floor type object. The association relationship between floor type object and member local instance objects is also realized by m_WholeObject attribute. Each member local instance object has attribute about their position in floor type object, and is associated to the member type object which contains the full detail by m_CompoT attribute.

Type objects and local instance objects of each level including member, floor, and building, are enough to manage the final design information of a whole building. The final design information is mainly about the layout of each member and their section properties. A building type object is exactly the whole building itself. Even though, global instance objects, which have one-to-one correspondence to each real component, are needed yet to manage the information which should belong to each member respectively. Member forces are a good example and they are managed by global instance object in the structural design process. In addition, it is sure that most of information in after-design works such as construction or maintenance should be managed by global instance objects because these kinds of information should be assigned respectively to each real component. Figure 3 shows the development diagram of type and local instance objects for the sample building shown in figure 1 (c).

Conclusively, in TLG modeling, a structural component is defined into a type object in type domain, a local instance object in local domain, and a global instance object in global domain according to the scope required for the description of attributes. This modeling concept is applied not only the primitive members but also the composite components such as floors, flames, and even buildings recursively. Defining recursively higher-level type objects which consist of lower-level local instance objects, the information redundancy resulted from the repetition of same types of components can be managed efficiently in a consistent manner.

7. Implementation and Applications

An integrated structural design system for buildings has been developed based on the object model described in this paper. The system serves all the structural design process from initial planning to the

detail design of member sections. This chapter briefly discusses how the object model works throughout the whole structural design process in the system. The focus of this chapter remains on the information modeling aspects, rather than on system implementation issues. The system provides all the function required to write out a structural design report which is one of the final products of structural design work. The system consists of three parts: (i) integrated database for data management, (ii) class libraries for doing structural engineering works, and (iii) user interface for interaction between the system and engineers. The proposed object model was implemented and included into class library part.

Figure 4 shows a series of user interfaces selected from the system while it is doing the design of a RC building. At the right side, it also describes the generation of objects, the assignment of their attributes, and the brief of information flow throughout all the structural design process focused on building, floors, and some kinds of member. It can be seen that even a structural component is expressed by several kinds of objects including type object, local instance object, and global instance object for its final design information. In addition, some kinds of process dependant objects such as initial modeling objects, load objects, analysis objects, and section design objects are generated and used to perform the design process.

8. Conclusions

Digitalization of design information and computerization of design process to generate digitalized design information are critical for higher-level integration in construction industry. A rational data model of design information should be an integral part of structural design systems and more integrated construction systems because most engineering activities in construction are executed based on design information included in design document such as drawings. This paper has presented some modeling concepts and their application to structural design of buildings. TLG object modeling concept is introduced to formalize the grouping of structural components in structural design of buildings. Concept of core and extended object classification is proposed in order to serve not only the final design information but also process dependent temporary one. Foundation and application object concept is used for the extensibility and the reusability of the model. Building object is designed so that it supports the structural design process effectively and its composition is described in detail.

An integrated structural design system for buildings has been developed and the object model takes a part of the system. The resulting model and system demonstrates that the concepts discussed in this paper fit well for the development of structural design system. The successful development of the system also shows that these concepts have the potential to be

CTBUH 2004 October 10~13, Seoul, Korea 1117

applied to a range of applications.

Acknowledgments This research (03R&D C04-01) was financially

supported by the Ministry of Construction & Transportation of South Korea and Korea Institute of Construction and Transportation Technology Evaluation and Planning , and the authors are grateful to the authorities for their support.

References 1) Badrah, M. K., MacLeod, I. A., and Kumar, B. (1998).

“Using object-communication for design standards modeling.” J. Comp. in Civ. Engrg., ASCE, 12(3), 153-161.

2) Booch, G., Rumbaugh, J. and Jacobson, I. (1998). The unified modeling language user guide, Addison-Wesley, Reading, Mass.

3) Froese, T. (1996). “STEP and the building construction core model.” Proc., 3rd Congr. Of Comp. in Civ. Engrg., ASCE, New York, 455-451.

4) IAI. (1996). “Industrial alliance for interoperability.” http://www.interoperability.com

5) Liu, W., Tong, M., Wu, X., and Lee, G. C., (2003). “Object-Oriented Modeling of Structural Analysis and Design with Application to Damping Device Configuration.” ” J. Comp. in Civ. Engrg., ASCE 17(2), 113-122

6) Mokhtar, A., Bedard, C., and Fazio, P. (1998). “Information model for managing design changes in a collaborative environment.” J. Comp. in Civ. Engrg., ASCE 12(2), 82-92.

7) Shen, Y., Bonissone, P. P., and Feeser, L. J. (2001). “ Conceptual Modeling for Design Formulation.” Engrg. with Comp., London, 17(2), 95-111.

8) Shooter, S. B., Keirouz, W. T., Szykman, S., and Fenves, S. J. (2000).“ A Model for the Flow of Design Information in Product Development.” Engrg. with Comp., London, 16(3), 178-194.

1118 CTBUH 2004 October 10~13, Seoul, Korea

Design Process Object generated : Attributes assigned

Building General Information

SSBuildingT : Number of stories, Material,

Applied design code, other general

information

SSFloorL : floor number, height

Master Plan SUMasterGridLine : Name, Location

SSColumnLineT : SSColumnL layout

throughout floors

SSColumnLineL : Master Gridline ID’s on

which they are located

SSColumnT & SSColumnL

PMColumnT : Initial Size

Unit Plan SSFloorT : SSFloorLs associated to this type

object

SSGridLine : Associated MGL, DeltaX,

DeltaY

SSBeamL, SSSlabL : Gridline ID’s on which

they are located

SSBeamT, SSSlabT

PMBeamT, PMSlabT : Initial Size

SSColumnL : Existence on this floor

Loads PLSlabT : Floor dead and live loads

PLBeamL, PLColumnL : Member loads

PLFloorLSeismic, PLFloorLWind : Story

seismic & wind loads

PLBuildingTSeismic, PLBuildingTWind :

Coefficient for seismic & wind loads

Figure 4. Object Flow in Structural Design Process

CTBUH 2004 October 10~13, Seoul, Korea 1119

Design Process Object generated : Attributes assigned

Structural Analysis PABeamG, PAColumnG, … : Analysis info

such as element number, Member forces,

Deformations, and etc for each member

global instance objects

Member Section Design PDColumnT : Design and change the

attributes of SSColumnT type object using

PMColumnT, PLColumnL’s, and

PAColumnG’s, Has design function for the

design code selected by engineers

SSColumnT : Final section info

A Series of Vertical Members SSColumnLineT : Story grouping

Using the information of object model AutoCAD : Draw unit floor plans using the

information provided by the present object

model

Figure 4. Object Flow in Structural Design Process (continued)