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: [email protected]
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)