A Methodology to
Michael Cook
Department of Mechanical and Civil Engineering
Faculty Advisor: Dr. Al Zeiny
Abstract
The concept of breaking down complex design problems into a hierarchy of simpler and smaller design tasks is commonly used not only to divide and conquer difficult tasks but also to assign different sub-tasks to different engineers. The same concept can also be used to digitally store generated designs by breaking them into a hierarchal decomposition of smaller and simpler design entities. Designs stored this way in a database, called a design repository, are easier to adapt for new design cases and are more supportive to intelligent design support environments. In addition, this technique makes the stored design computable and supportive to the tasks of the inference engine of the intelligent design support environment. In a previous effort, a knowledge based system to store bridge design information was developed for the purpose of providing intelligent design support environment to engineers. Before the system can be of any use, it is required to populate the knowledge base of the system with previous bridge design cases. This is achieved by breaking the bridge into design entities arranged in a containment hierarchical structure and entering every entity and its modular information in the knowledge base. This paper describes the methodology used to break down the bridge into design entities, and the underlying conceptual and data models.
Keywords: Knowledge Based Systems, CADD, Knowledge Engineering
1. Introduction
During the construction of a typical structure, many conflicts arise due to the miscommunications between engineers who are assigned different tasks from the same project. Two different entities may have been designed in the same space of the structure by two different engineers. Engineers often need to work on resolving these tasks once discovered. This redesigning creates more construction delays and additional expenses. Some of these conflicts may cause major design revision that can become very costly. These conflicts happen because members of the design team are using separate tools and storing the design information in different files. The concept of using the same shared space by all members of the design team, as shown in Figure 1, can eliminate many of these conflicts and reduce the cost of fixing them.
In addition, engineers often use various CADD design tools to aid them in generating their designs. These design tools may be described as islands of automation because they do not talk to each other. Each design tool is specialized in performing a detailed design task of a specific structural component of the structure without any communication with either the tools responsible of designing other components or the central design representation. Furthermore, the drafting software normally captures the geometry only and does not capture any rationale or relationships among design entities. This causes conflicts, increases the possibility of errors, causes repeated efforts, and makes it more difficult to make changes when using the trial-and-error design procedure.
Figure 1 The concept of shared work space
2. Methodology
An intelligent design support system is using computer software to assist the engineer in performing design tasks, generate new designs by adapting entities from old designs, and keeps design information accessed by different members of a design team up-to-date. A prototype of the desired system was developed in the Civil Engineering Department at the
3. Conceptual Model
The breakdown of the project to design entities is based on the concept of breaking down large complicated design entities into simpler ones. The design entity could be as big as the entire project or as little as a small element in one of the connections. Each design entity is linked to classifier instances that are used to index the design entities in the database for future retrievals using queries. The classification system was also arranged in a hierarchical decomposition fashion and linked to various types of design entities for possible use as shown in Figure 2. The figure is a view from A2ZCAD where the Design Entity Type decomposition tree is partially expanded to show the arrangement of design entity types that may exist within a bridge structure.
Figure 2 Classification tree from A2ZCAD
4. Illustrative Example
To illustrate the methodology used to store design information, we will consider the single span bridge shown in Figure 3. The structure is a simple truss bridge that is design to carry both gravity and lateral loads. Gravity loads are loads due to bridge traffic and other downward forces, while lateral loads are generated due to wind or seismic events.
Figure 3 Single span bridge
The bridge is broken down into a hierarchical decomposition of entities as shown in Figure 4. Since the nature of design evolution is to start from the top with conceptual entities and then fill more details as the design evolves, entities are normally instantiated into A2ZCAD according to their hierarchical order. The entity name is selected to reflect a major feature that identifies the entity. An example of an entity name is “EP:L0,U1” which would indicate the end post from position L0 to U1. Each entity is assigned a design entity type that appears in parentheses next to the design entity name. Each design entity is entered into the hierarchical tree by a dialog box as shown in Figure 5. The “Entity Name” is the name of design entity, and the “Entity Type” is its linked design entity type.
Figure 4 Hierarchical decomposition of the bridge
Taking a further step into the example project, Stringers is a generic container for beams in the bridge floor. It can be broken down into more specialized design entities such as: exterior and interior stringers. These can then be sorted by panel. Stringer entities are name to reflect the used specialization technique, for example entity name of “IS:1” is assigned to label the interior stringer in panel one.
Each design entity is linked to a set of parameter collections that give information about that member’s details such as its length, orientation, slope, cross section shape, material properties …etc. Some of these parameters are geometric parameters that determine the dimensions of AutoCAD entities and are linked directly to the related AutoCAD geometric object for the purpose of automatic propagation of changes. For example, changing the length of the beam causes the length of the corresponding AutoCAD entity to change automatically resulting in a faster trial-and-error design process. In addition, related design parameters are linked together with a set of quantitative relationships that capture the mathematical relationships between various design parameters as shown in Figure 6. For example, if the depth of the beam is equal to the span measured in the horizontal plane divided by thirty, a quantitative relationship between the depth of the beam and its span is generated as shown in the figure to represent this mathematical relationship between them. In case of changing the beam span, the beam depth will also automatically change by the re-evaluation of the previously established quantitative relationship. This causes automatic propagation of changes in a manner similar to what happens in spreadsheets.
Figure 5 Adding design entities
Figure 6 Dialog box used to add quantitative relationship expressions
5. Storing Bridge Design Information
Each Design Entity object is linked to Entity Parameter Collection objects that stores the design parameter data in a set of parameter-value pairs. These pairs may be assembled into small cohesive subsets organized at two hierarchical levels, the group level and the collection level. At the group level, data are grouped into three subsets, the Capacity Parameter Collection group, the Demand Parameter Collection group, and the Geometric Parameter Collection group.
The Capacity Parameter Collection group defines intended purposes, requirements, and constraints on the entity that have to be satisfied to realize the intended purpose. The Demand Parameter Collection group includes all the physical and spatial characteristics that define the actual design of the entity as well as the behavior of this entity under various loading conditions. In order for the design to be successful, designed demands must not exceed capacities, i.e., D/C ratio is less than 1. Demands are stresses and deflections resulting from the applied loads on a building entity while capacities are the corresponding strength and allowable deflections. This requirement is checked by the D/C Checker objects. The Geometric Parameter Collection group has the geometric parameters linked to the drafting software to ensure that the product drawings change automatically as geometric parameters change. While Qualitative Relationship objects link design entities together with domain specific relationships, the Quantitative Relationship objects link various parameters together to ensure the propagation of any parameter changes accordingly in a fashion similar to what happen in spreadsheets. Such a feature makes the model highly computable and various design alternatives may be explored easily, not to mention the ability of generating similar new designs from old ones by creating templates from old designs.
At the second level of data aggregation, the parameter-value pairs of an entity are combined into small cohesive subsets, each of which is called a parameter collection. A collection is defined as a group of closely related parameters that are found together in a repository (access-cohesive), instantiated at the same time (time-cohesive), and that represent the same concept (concept-cohesive). Cohesion is the only criterion used in grouping entities. It is defined as a measure that shows how closely the parameters of an entity relate to one another. An example of a Parameter Collection is one that collects together the parameters used to describe the section properties of structural members such as depth, width, cross section area, and moment of inertia. Parameter collections allow entities to be refined in staged steps by adding sets of parameter-value pairs to the entity as they are generated in the design process. Hence, there is no need to predict all possible parameter-value pairs needed in a product entity at the outset. Parameter collections also allow the integration of multiple views by multiple design teams in one entity by including collections that are specific to each view and each design team as well as components that are shared among all views and all design teams. Figure 7 shows the dialog box used to enter a design parameter collection.
6. Conclusion
The designed information is stored in a computable format that allows easy propagation of changed parameters related together with quantitative relationship objects. This facilitates the trial and error design methodology by allowing the engineer to generate alternatives and store them in the design entity tree for the purpose of comparisons. In addition, the presented methodology, to break down the bridge into a collection of design entities arranged in a hierarchical decomposition fashion, manipulates the divide and conquer design strategy by dividing larger more complicated design entities into smaller and simpler entities down to the very atomic design detail. Collections of design parameters are then linked to design entities for the purpose of storing all relevant design information that is required for designing, fabricating, and finally constructing the design entity.
Figure 7 Dialog box used to add design parameter collections
7. References
1. Rivard, H. and Fenves, S. (2000). “A Representation for Conceptual Design of Buildings,” Journal of Computing in Civil Engineering, ASCE, July, Vol. 14, No. 3, pp. 151-159.
2. Rosenman, M. A., and Gero, J. S. (1996). “Modeling Multiple Views of Design Objects in a Collaborative CAD Environment.” Comp.-Aided Des.,
3. Zeiny, A. (2004) “Computable Dynamic Design Repository for Product Data Representation.” ASME International 24th Computers and Information in Engineering (CIE) Conference, September 28-