Virtual Prototyping for Engineering Design

Transcription

1 Virtual Prototyping for Engineering Design Walid Tizani University of Nottingham England nottingham.ac.uk Robert A Smith University of Nottingham England robert.smith@ nottingham.ac.uk Darshan Ruikar University of Loughborough England D.Ruikar@ lboro.ac.uk Abstract This paper is concerned with an ongoing research work looking into applying virtual prototyping techniques for the design of buildings. Virtual reality is used for visualisation and to allow for intuitive interaction with designers. Due to the complexity and the multi-disciplinarity of such designs, the building is treated as a single system created and refined from input from designers representing the various disciplines. The virtual prototype is created incrementally and tested using multi-criteria performance analysis tests. Virtual reality simulations of various discipline related views are generated. This paper gives an overview of the software system developed to investigate the efficacy of using virtual prototyping for building and outline a typical design scenario. Keywords Virtual reality, Building Design, virtual prototyping, Multi Discipline, steel structures. 1. INTRODUCTION The engineering design process for a project is carried out collaboratively between a number of organisations. It is primarily concerned with specifying the product that best fulfils the client s brief, and that ensures safety during construction and use. This process requires interactions between the disciplines of architecture, building services, structural engineering and site construction. The outcome of this process has a major bearing on the overall cost and quality of the completed project with knock-on effects on downstream issues spanning all project stages. Supporting the engineering design stage is therefore an important factor in improving the overall life cycle. Improving the efficiency of such a process must involve facilitating the interactions and communications between inter-disciplinary parties. Information technology, although commonly used in the communication between design processes, is not yet fully exploited and is an obvious area to target for delivering such an improvement. This will therefore require the re-engineering of key design practices and the provision of IT tools to facilitate this re-engineering. Virtual reality technologies can assist in bridging the gap between the various discipline-based representations of information by providing a common and an intuitive representation of the end-product. Within virtual reality environments, considerable emphasis is usually placed upon the visual aspect or interface to the buildings design through 3D visualisation tools, and less so upon its underlying behaviour. However, virtual reality, in the context of building design, is based on the idea of virtually producing the appropriate behaviour and visualisation of a building before, during and after the buildings construction. Therefore, virtual reality in its fullest sense cannot be fully realised without also simulating the buildings behaviour through the relevant supporting processes and underlying data structures. This paper reports on an investigation into using virtual reality to allow for the modelling of virtual prototypes that exhibit the necessary behaviours to accommodate the needs of the various disciplines involved in the design of buildings. 2. THE BUILDING SYSTEM The complexity of building designs stems from the interdisciplinary nature of its various aspects (e.g. architectural design, structural design, services engineering, site construction, etc.). Due to this complexity, the building is seldom designed as a single system but, in order to be able to manage its design process, the design task is broken down into several specialist aspects. Each aspect of design has requirements that impose both local and global constraints on the buildings design. The design solution for each of these aspects is normally the responsibility of a specialist. Traditionally, the architect represents the interest of the owner of the building and has the responsibility of ensuring that the design solutions of the various aspects are harmonised and that the end-product (the building) satisfies the intended function within budget.

2 An obvious improvement is to attempt to integrate the design processes of as many aspects as possible so to allow for the simultaneous consideration of their design constraints. Such improvements have been possible using various information technologies. Such attempts at integration have concentrated on closely related disciplines, such as structural design and construction, however, very little has become common practice. The exceptions to this has come as the result of a number of major players in the construction industry who have attempted to integrate aspects of the design process using either integrated software tools (e.g. structural analysis, design and detailing) or through the exchange of design information between specialised design tools using a commonly agreed standard. The design integration of these closely related disciplines does not constitute a radical change as, on the whole, it follows the same boundaries set by a traditional design process. It does, however, facilitate the conduct of the process through better information management. The main benefits resulting from this are to allow the design process to be conducted faster with less repetition, remove re-keying of information, and reduce the risk of errors that lead to re-work. This is a bottom-up approach where the objectives are to satisfy the constraints of each individual aspect and then synthesize to obtain the design solution for the end-product. The logical progression to this approach is to widen the scope through the integration of more aspects of the design and the specification of wider pool of common data structures and standards for the exchange of information. A more fundamental shift can be introduced by looking at a top-down approach to design. That is looking at the end-product as one system, the building system. The compliance of a design solution for this system is judged against a set of global constraints normally elicited from the ultimate required functions of the building. These constraints are not normally well defined but have specified boundaries or intents drawn from the client s brief and the architectural concept. A simplified scheme of the building system is shown in Figure 1 [Tizani03]. In this scheme the system is made up of a number of major components (shown by the horizontal bars). These components cut across a number of specialist disciplines (shown by the vertical bars). This scheme is illustrative and is by no means comprehensive. It shows the building system consisting, amongst other, of a spatial specification and area usage, a set of floors including the structural and services aspects, a roof, cladding and building services cores. Ideally, a design solution for the building system can be represented in a prototype composed of these components where the success of this solution is established from its compliance with a set of global constraints and its performance judged against pre-determined measures such as quality, cost, lead construction time, sustainability, etc. The specialist aspects of the building can be synthesized from these components by assembling together relevant parts of these components. For example, the structural frame aspect can be assembled from parts of the flooring, roof and special layout and its loading from the area usage; the fire regulation aspect from the spatial layout and area usage; etc. The specialist aspect can form a particular design view of the building system. The design solution for an aspect will impose its own specialist constraints and performance measures which are additional to the global ones. The specialist constraints tend to be transient and dynamically generated for the particular solution and can differ from one proposal to another. For example, a braced steel frame might have different constraints and performance measures to that of a timber or a concrete frame. A virtual prototype of the building system can thus be formed from the major components and its performance tested globally for the building system and both globally and locally for each of the specialist aspects generated from the prototype. In such a prototype, the design at the highest level concentrates on the provision of higherlevel function-based and cross-discipline components to fulfil the function of the building and the associated constraints. At lower levels the design concentrates on the vertical specialist aspects. The virtual prototype should be able to simulate its own behaviour, provide indication of its performance against set criteria and check its compliance with set constraints at the appropriate level. Figure 1, Schematic representation of the building system 3. INTEGRATED VIRTUAL BUILDING MODEL A demonstrator software for the design and appraisal of multi-storey steel buildings (called the 3D Virtual Building System; 3DVBS) has been implemented and evaluated. The feasibility of conducting a virtual building design has been investigated together with the methodologies and techniques that will enable such a design.

3 The term virtual building refers to the virtual representation of a building that behaves in a realistic way from the engineering point of view. The design process implemented in the system involved the use of virtual prototyping. This is where a building design prototype is incrementally built by assembling virtual building components such as columns, beams, floors and services, which collectively simulate the virtual behaviour of the building. The virtual building provides feedback on its performance in terms of structural behaviour, safety, cost and adherence to architectural constraints and client briefs. 4. IMPLEMENTATION OF THE VIRTUAL BUILDING MODEL An ideal building design process should produce the most cost effective building design, of the required quality, in the shortest space of time. In order to achieve these goals, several areas of particular importance should be taken into account [Tizani03]: Information should be available concerning the whole building project in a compatible manner in order to allow all building design aspects to be considered concurrently. The effect of any changes to the building s design should be apparent, so that collaborating nonspecialists designers can appreciate the effect these changes have upon the rest of the building design. The design process should be flexible enough to allow for the variation in design methodologies and domains of responsibility that are required by different partnerships. The decisions made by the building designers should be captured in a suitable way, so as to allow the logic behind the decisions to be maintained and then reused at later stages in the building s design. Low-level design processes should be automated where accuracy and speed are more relevant than creativity. The process should accommodate large-scale changes made late in the building s design by reducing the amount of manual reworking required. The building design should be conducted through a unified interface based around the integrated building design process in order to make sure that all design aspects can benefit from the advantages that such an integration provides. The next two sections describe the integrated process and product model and an overview of a typical design process. An integrated product and process model has evolved from this work and its concept is schematically represented in Figure 2 [Smith02][Ruikar01]. Within the term product and process model, the product consists of information and decisions regarding a building s design, and the process consists of the activities involved in the development and creation of the product. The processes are described in terms of the activities carried out by building designers alongside the operation and implementation of automated processes. The product is described in terms of the logical format of information required to produce a formalised model suitable for implementation in an IT solution. This product and process model enables an integrated and concurrent approach by allowing the simultaneous consideration of all significant building design aspects. This is managed through a coherent interface where all modifications to the building s design are made and where the wide-scale consequences of designers actions can be examined. A sequential process is allowed for to the extent of providing a general order in which design activities may be carried out, though with flexibility to allow for varied working styles formed by various working arrangements. Figure 2 shows four main process groups (boxes 1 to 4) that operate upon the three-tiers of information which make up the virtual building s product model. The interaction within the product and process model is described below in a simplified manner. The first process group relates to the design intent. The design intent is input, formalised and stored in the first of the product model tiers (Design Intent Model) constituting the IDEA (tier 1). The IDEA is composed of the decisions and choices made by each of the building designers. As such, this tier contains the most valuable information in the building s design, and the other two tiers are ultimately a logical development of the ideas expressed within. A manufacturing model constituting the PROTOTYPE (tier 2) is then generated from the IDEA using the second process group: Prototype Generation. The PROTOTYPE is the outcome of the total design process and principally includes the physical product (the description of actual products that make up the building, such as the steel frame components, floor system and cladding system). Later, it will be appropriate to include all the operations required for construction (construction methods and sequence, resources not yet implemented in this work). The manufacturing model was based on existing models: the Industry Foundation Classes (IFC) and CIMsteel Integration Standards (CIS/2) [IAI03][SCI00]. More specifically, the principle basis of this model was the CIS/2, since it provided a better subset for modelling the engineering steel design information than the IFC. It is also supplemented with other non-steel subsets, such as architectural, flooring system, services system and cladding system design models.

4 Product Model Design Intent IDEA Process 2. Prototype generation based on design criteria/ constraints and parametric rules Process 1. Design intent and appraisal Input and development of building design criteria. Product Model Manufacturing Model PROTOTYPE Process 3. Test model generation compatible with as-built model for purpose of constraint testing Process 4. Design Check Comparison of test results with original design requirements Product Model Analysis Model TEST Having generated a workable PROTOTYPE, various processes are applied to test the conformance of the building to the set constraints and the general engineering principles. This is done by generating transient TEST analysis models (tier 3) from the PROTOTYPE for each of the conformance tests required (process group 3) and then by carrying out suitable checks on these models in order to report on the conformity to the set IDEA (process group 4). For example, to test the structural engineering requirement, a structural analysis model is created, and based on the response of the structure a safety check is carried out (e.g. member sizing check), or to estimate the cost of the building a cost analysis model is created and checked against the cost targets. Other conformance tests can be carried out in a similar fashion, e.g. to ascertain the fire safety or fire escape requirements a suitable analysis model is created and checked against the regulations. Modelling the building in these terms constitutes the product model. These three models are complementary to one another and can also be self-sufficient. But since they are inter-related, they maintain a synchronised end product fulfilling the requirements of designers. The above sequence outlined a cycle of generating, from the IDEA, a PROTOTYPE and then TEST to gauge its performance. Further cycles can be carried out as required by refining the IDEA. The strategy adopted in the process model is to automate the low level, relatively deterministic, processes leaving the designer to concentrate on the direct manipulation of the building s design. Much of the detailing is delegated to software agents, though the engineer remains in full control of the building s design and can still specify several or all of the parameters at the intermediate design stage as required. However, it is desirable to allow the Figure 2, Integrated product and process model agents to retain as much control of the low-level design issues as possible for two reasons. Firstly, it saves the engineer time in conducting the low-level designs and reduces the chance of human error. Secondly, it means that as the building s design is changed the elements under the control of the agents will also be updated and optimised. This is helpful when catering for changes in the building s design due to either design configuration comparison, or changes to the brief. 5. IMPLEMENTATION OF THE VR SOFTWARE The software has been developed using the objectoriented methodology and written in the C++ programming language. All processes and product models are implemented in terms of objects logically interconnected. A modular approach is taken to the addition of agents used to carry out the processes of structural analysis, checking and design. The virtual reality interface was developed in OpenGL (Open Graphic Library) to create a real time dynamic system where all actions upon the model can be carried out through the 3D interface. This is a significant advance over the use of static VRML models whose main use is aesthetic. The software incorporates a real time interface with the ability to simultaneously visualise all aspects of the building s design. It includes the ability to have specialised views for each discipline that combine several different visualisation options alongside the tools appropriate for that discipline. Default views are provided for each of the traditional roles including the architect, structural designer and services designer. Model manipulation is specialised for each of the views so that no information over-load will occur. However, each view can be customised to visualise any of the available options by overriding the default set. So, the Structural engineering

5 view might be customised to super-impose any of the architect detail over the structural detail. All of the design ideas are visualised in terms of their corresponding manufactured model (which is at all times synchronised with the design intent), so that the interactions between the building components can be better understood. The results from the analysis tier are also visualised within the same 3D interface, which makes manual design checking possible, and provides the building s designers with an intuitive way of visualising the effect that changes have upon the model. 6. DECISION SUPPORT USING VR Decision support is provided through the ability to carry out rapid prototyping within an integrated system that facilitates concurrency between a number of inter-related design disciplines. The process modelled within the experimental software can also be described as intuitive since it is modelled on a best-practice approach that concentrates on the satisfaction of what is judged to be the critical goals required from the design process. With the ability to quickly generating workable solutions that meet the requirement of architectural and services constraints (floor layout, services accommodation, spatial clashing, etc.) the designer is left to concentrate on high-level decisions. In addition to the above, the system includes a parametric cost model that is based on the quantity surveying principles. The cost model adopted is judged to provide rough estimates accurate enough to allow for comparative costs sufficient for the purpose of economic appraisal. Using the model, the designer can input a target budget figure that can then be compared with the cost estimate of the proposed design solution. The experimental software is a so-called multi-document project which allows the user to generate what if scenarios that allow several design solutions to be compared by cost and structural performance. For example, the designer might produce a number of solutions differing by aspects such as architectural layout with various floor usage, services-structural integration, column spacing, floor systems, etc. The overall effect of alternative design options can then be readily appreciated. 7. OVERVIEW OF A TYPICAL DESIGN PROCESS The process model makes no assumptions concerning the roles of actors within the building design process, though it is helpful to consider the design activities in terms of the actors traditionally involved in those roles. As such, the activities within the processes developed in this model can be divided between the client, architect, structural engineer and services engineer. A typical design scenario, that may be followed using the software, is provided below. The client is responsible for providing the building s global requirements. This includes the building s target cost that may be subdivided between the structure, services, flooring and cladding. The client is also responsible for setting the total floor space required within the building as a whole. At all times during the building s design, the costs and areas are automatically calculated and compared with the client s requirements. Any failure for the actual figures to meet the targets will be flagged so that all building design participants will be aware of the issue. The architect is responsible for specifying the layout of the building s perimeter, the number of floors, and the internal height requirements for each floor (Figure 3). The height of any given storey of the building can be given in terms of the non-structural floor depth, clear depth and the ceiling depth, which includes the services and structural depths. This provides a number of requirements for the structural and services design to conform to, and sufficient information to specify a general model of the building in terms of size and spacing. Figure 3, Definition of building boundary The architect is also responsible for specifying the cladding types assigned to each part of the building s perimeter. This provides sufficient information to calculate the claddings cost, which will then be compared with the clients brief. The cladding information also provides an early indication as to the external look of the building, which may be useful for assessment of early prototypes by the client. In terms of the building s structure, the cladding information also provides data regarding its loading requirements that will then be incorporated into the structural analysis. The architect is responsible for specifying the floor usage for each part of the building (Figure 4). This provides information for the cost modelling process, loading information for the structural analysis process, and allowable structural response information for the building design checking process. The architect may also provide information regarding extra loading areas within the building, such as around building cores so that the appropriate loads will be added to the building s structural analysis model. The architect may also designate column spacing area within the building, in order to prevent the structural engineer from positioning columns inappropriately. The architect is also responsible for specifying cores in terms of their location and designated purpose (Figure 5). This information will be impor-

6 tant for use by the structural engineer and the services engineer. (Figure 8). Floor areas are then specified, which allow for the designation of the secondary beams and structural floor in one action (Figure 9). As with previous structural design stages, any or all aspects of the floor may be specified by the engineer including the secondary beam dimensions, spacing, orientation, and the floor type and floor dimensions. The detailing for the remaining design aspects, if any, will then be calculated automatically. Figure 4, Definition of floor plan and usage Figure 6, Structural: positioning of column grids to suit architectural constraints Figure 5, Definition of building cores The architect s design input, therefore, has a far-reaching effect on the building s overall design. It must meet the client s requirements in terms of the spacing requirements, while setting forth the requirements of the structural building services engineers. The structural engineer s first task is to specify the column positions within the building (Figure 6). The height is not specified, as this is automatically calculated based on the architects building information. It is also not necessary to specify the dimensions of the columns at this stage, as they may be calculated automatically from parametric rules and then later refined based on the columns structural response. The next step in the structural design is to locate the primary beams and either specify their dimensions or, as with the columns, allow the software to automate this process (Figure 7). The connection detailing between the primary beams and columns is optionally generated automatically, and may be redesigned later when structural analysis information is available. Bracing is similarly specified using simple connections Figure 7, Structural: propose framing system The structural engineer is therefore able to commit to any level of detail that he feels necessary, and this allows him to leave the less globally influential design issues to the software that is better suited to this task. As a result of these actions, data is generated concerning the selfweight of the structure and the cost of the building elements for use later in the design process. The services engineer is able to specify the location of service entry points to the building, the location of service cores and the main service routing in plan around each floor (Figure 10 & 11). The height of the actual service ducts is based on the service strategy chosen, and will either be positioned beneath the structural layer or within the structural layer. In the case of the latter, the

7 beams will be appropriately notched, and this will be taken into account in the building s structural analysis and costing. Figure 10, Services View: Adding services duct connected to services core Figure 8, Structural: Devise structural bracing system Figure 9, Structural: Complete structural system prototype With the information provided through these processes, there is sufficient data to produce a 3D structural analysis model of the building (Figure 12). This is generated automatically to accurately model the members and connections with the appropriate use of analysis members and dummy members to model connection offsets, hence maintaining compatibility between the as-built structure and the analysis model. Loading information is automatically generated from the information previously input by the architect, structural engineer and service engineer, in terms of factored dead and live loads. The analysis is carried out to produce the structural analysis response model (Figure 13). This information is used to perform a design check on the structural members, which may then be used by the structural engineer or automated processes to iteratively improve the building s design. Figure 11, Services/Structural : Checking structural floors - services integration Figure 12, Structural : General structural analysis model compatible with as-built details

8 Figure 13, Structural : Structural analysis results (bending moment, shear force and deflected shape) The information above has given an overview of a sequential design process. At this stage a complete building prototype is available for assessment. The information describing the building together will all relevant input is stored in the product model. Subsequent changes or refinements, by any of the designers to the model, are concurrently available to all other disciplines. Effecting concurrency is facilitated by the use of the single product model. In addition, partial building designs may still be carried by concentrating the work on a single discipline. For example, a structural engineer can input a steel frame and carry out analysis and design without the availability of architectural constraints. 8. SUMMARY AND CONCLUSIONS The engineering design process has a significant effect on the overall quality, cost and operation of a construction project over its life cycle. Such a process involves a number of currently separate and largely sequential processes spanning from architecture to site erection. This project has demonstrated that a process akin to virtual prototyping techniques, used in other industries, can be applied to the construction industry using suitable integrated product and process models. The implemented technologies centred on the development of product and process models spanning the related disciplines. The investigators believe that the future use of information technology will be to build upon the ability to formally represent all project data in a standard format, which can then be retrieved and manipulated for various design, construction and maintenance purposes over the life cycle of a project. This project has demonstrated that this is feasible for the AEC design process. Using similar methodology, the scope can be widened to include activities other than engineering design. The academic significance is in the realisation that proper specification of adventurous process models underlined by robust and standardised product models is a key area to effecting a visionary approach to construction projects over their life-cycle. This is especially true that available information technologies are far more advanced and not yet appropriately exploited for the benefit of the construction industry. Therefore the required breakthroughs need to be in the representation and manipulation of data and not in the information technologies themselves. 9. REFERENCES [IAI03] International Alliance for Interoperability. Industry Foundation Classes < [Ruikar01] Ruikar D, Smith R, Tizani W, Nethercot D. Best Practice in the Design of Multi Storey Steel Framed structures, Proceedings of the 1st Innovation in AEC Conference at Loughborough [Smith02] Smith R, Tizani W, Nethercot D, An Integrated Tool For Structural Design Within an Interactive Virtual Environment, proceedings of AI and CIVIL-COMP 2001, Eisenstadt, Austria, Civil- Comp Press, Stirling, Scotland [SCI00] The Steel Construction Institute, CIMsteel Integration Standards, Volume 1 4, SCI Publications, UK [Tizani03] Tizani W and Smith R A, (2003), Incremental Virtual Prototyping as an IT tool for CE projects, 4th Joint Symposium on Information Technology in Civil Engineering, Nashville, ASCE and EG-ICE. November 2003.