|
| | Design parts | Collaborative interaction | Filter operation |
|
| Process 1 |  | 
The architect creates the geometry using project-independent products as well as project-dependent ontologies (e.g., <beam>, <column>). After achieving a certain level of design development, he wants the structural engineer to review the design | The architect’s filter translates the design and publishes it. The published data will include 3D geometric information and XML tags connected to its private data model. As additional information, the publication has the following information:
(i) Who: the architect
(ii) When: created date
(iii) What: geometry
(iv) How: XML
(v) Why: design criteria |
|
| Process 2 |  | 
The structural engineer’s task is to verify the architect’s design in terms of structural buildability. In order for the structural engineer to design the structure of the building, he needs the architect’s model as well as structural codes and standards. If he finds something that needs to be modified, the structural engineer redesigns the structure | The structural engineer’s filter retrieves the latest version of the design. Although it encounters the same terminology in the design, the filter is missing some information such as “inertia,” or “moment.” Then, it begins to break the architectural model into structural pieces. It then translates the model into the structural engineer’s own model for design review or modification. When the structural design is ready, the filter gathers necessary information (e.g., 3D geometric data, properties, etc.) and publishes the design with XML tags |
|
| Process 3 |  | 
The architect may decide whether he accepts the proposed design or not. If the design of the structure conforms to the architect’s requirements, the architect may begin to design interior walls as well as exterior compartments. For the interior walls, he may allow further modifications (e.g., tolerance) because of his prior experience with the MEP engineers | The published data created by the structural engineer includes the following information:
(i) Who: the structural engineer
(ii) When: modified date
(iii) What: deometry
(iv) How: XML
(v) Why: structural buildability
When the architect’s filter receives the structural design and represents it with architectural ontology |
|
| Process 4 |  | 
The mechanical engineer’s primary concern is installing the ducts due to their size and inflexibility. In most cases, architectural and structural designs act as constraints for designing ducts and pipes. The size, material, and shape of the ducts and fittings together with the size, material and connection type of the pipes, and the elevation of air terminals should be based on the input data as well as specifications | The first task of the filter is to try to find available spaces where the ducts can fit in using the provided knowledge base and spatial reasoning tools as shown on the suggestion to the left |
|
| Process 5 |  | 
The mechanical engineer tries to fit the ducts in the available space suggested by the filter. However, it appears that fitting in the space requires a special design (e.g., connection type that usually leads to a cost increase). Then, he tries to find out whether modification on the design would be allowed. As soon as he tries to put it there, he can recognize that there is physical interference as shown on the left | The mechanical engineer’s filter displays who is in charge of the proposed design and semantic information (e.g., bearing or nonbearing wall). Here, because the interfering walls are nonbearing walls, the mechanical engineer decides to modify them with additional information (e.g., explanation on his proposed action). His filter will publish the proposed design with the following information:
(i) Who: the mechanical engineer
(ii) When: modified date
(iii) What: geometry
(iv) How: XML
(v) Why: physical interference |
|
| Process 6 |  | 
The architect reviews and confirms the modification proposed by the mechanical engineer | After the mechanical engineer’s filter publishes the proposed design, the architect’s filter takes and processes it. Consider the case that the proposed design is within the range of the tolerance specified by the architect. Still, the filter lets the architect know there is a modification by the mechanical engineer. After obtaining the architect’s confirmation, his filter publishes the accepted design to remain consistent. Likewise, the architect’s published data will be retrieved and processed by the structural engineer and the mechanical engineer’s filter |
|
| Process 7 |  | 
The situation for the plumbing engineer is worse than the mechanical engineer’s. The main constraints imposed on him would be the architectural and structural designs as well as the mechanical designer’s ducts. Therefore, his primary task is to find whether there is enough space to accommodate pipes | When the plumbing engineer’s filter retrieves all the published data, which were contributed by the architect, the structural engineer, and the mechanical engineer, it begins analyzing geometries to find available spaces. Then, it suggests the spaces surrounded by the beams/columns (the structural engineer) and the ducts (the mechanical engineer) including clearance confined by the ceiling (the architect) |
|
| Process 8 |  | 
Once the plumbing engineer is done with the pipe layout by accommodating all pipes in the suggested spaces, he lets his filter publish his design | After the plumbing engineer’s filter publishes the design, the other participants’ filter will be notified with the following information:
(i) Who: the plumbing engineer
(ii) When: created date
(iii) What: geometry
(iv) How: XML |
|
| Process 9 |  | 
All the design contributed by the other participants would be constraints on the electrical engineer’s design. His design has to comply with constraints imposed by the architectural design, clearance required by code, and specification all combined with the layout design of other MEP systems | Like the other MEP engineers’ filter, the electrical engineer’s filter suggests available space so that the engineer can design the electrical systems |
|
| Process 10 |  | 
If the electrical engineer is unable to design the electrical systems due to the access floor designed by the architect, the electrical engineer will let his filter publish the design | The design published by the electrical engineer’s filter contains the following information:
(i) Who: the electrical engineer
(ii) When: modified date
(iii) What: geometry
(iv) How: XML
(v) Why: physical interference
Since the access was designed by the architect, the architect’s filter will retrieve the electrical engineer’s published data. If the design is within the range of the architect’s design criteria, the electrical engineer can continue his work. Otherwise, the architect’s filter will let the architect review the above information. This iteration will continue until the specific problem is solved |
|
| Process 11 |  | 
At any particular moment, the entire project can be regarded a snapshot of a compilation of each participant’s contribution. Since there is no centralized control over the compilation, each participant is in charge of authoring his representation and publishing the latest version of it to the central server and retrieving the latest output produced by the other participants | Each filter supports a corresponding participant’s individual design work as well as collaborative interaction with other participants by providing filtered information and representation |
|
