1,351
edits
Structural design processes: Difference between revisions
Structural design processes (view source)
Revision as of 20:41, 20 November 2021
, 20:41, 20 November 2021no edit summary
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
Structral design requires the use of [[System Planning|system planning]] i.e. the overal process and the sub-processes need to be optimised. | Structral design requires the use of [[System Planning|system planning]] i.e. the overal process and the sub-processes need to be optimised. | ||
Figure 1 shows how, when creating a structure, one starts with a set of requirements that define the performance of the structure. This is transformed by a design process into design output, i.e. into information about what the structure will be and justification for the design decisions.. A construction process then transforms the design output into the physical structure. | Figure 1 shows how, when creating a structure, one starts with a set of requirements that define the performance of the structure. This is transformed by a design process into design output, i.e. into information about what the structure will be and justification for the design decisions.. A construction process then transforms the design output into the physical structure. | ||
[[File:Structure-process.png|none|thumb|600x600px|Figure 1 Stages in the creation of a structure]] | [[File:Structure-process.png|none|thumb|600x600px|Figure 1 Stages in the creation of a structure]] | ||
=== Models of the design process === | |||
[[File:Structure-process-2.png|thumb|400x400px|Figure 2 Design process stages]] | [[File:Structure-process-2.png|thumb|400x400px|Figure 2 Design process stages]] | ||
| Line 12: | Line 13: | ||
The process is not normally linear. 'Review and revise' is at the heart of the process. Iterations may be needed and revisions are made based on continuous review activity, | The process is not normally linear. 'Review and revise' is at the heart of the process. Iterations may be needed and revisions are made based on continuous review activity, | ||
At the | At the the InceptionStage, requirements for the performance of the stucture and for the design process are established and information about, for example, the site is identified. | ||
At Conception, investigations are carried leading to a decisoin about the general form of the structre to be adopted. | At the Conception Stage, investigations are carried leading to a decisoin about the general form of the structre to be adopted. | ||
At Production, the chosen form of structure is developed to produce drawings and specifications to be passed on to the construction stage. Other outcomes include documents that justify the decisions taken. | At the Production Stage, the chosen form of structure is developed to produce drawings and specifications to be passed on to the construction stage. Other outcomes include documents that justify the decisions taken. | ||
==== Process mapping ==== | ==== Process mapping ==== | ||
| Line 28: | Line 29: | ||
[[File:Des-proc-2.png|center|thumb|800x800px|Table 1 Simplified process map for structural design]] | [[File:Des-proc-2.png|center|thumb|800x800px|Table 1 Simplified process map for structural design]] | ||
The work starts at the top left of the map with the definition of requirements and moves across the stages and down the sub-processes to achieve the basic project outcomes In the case of stuctural design the basic outcome is in the form of drawings and specifications that define what the structure will be. Other outcomes are required that, for example, justify the choices made or show how risk was controlled. | The work starts at the top left of the map with the definition of requirements and moves across the stages and down the sub-processes to achieve the basic project outcomes In the case of stuctural design, the basic outcome is in the form of drawings and specifications that define what the structure will be. Other outcomes are required that, for example, justify the choices made or show how risk was controlled. | ||
Table 1 only indicates some of the complexity of the system plan. | Table 1 only indicates some of the complexity of the system plan. It does not show iterations that are common, especially at the concept stage, nor does it show interactions among the sub-processes. | ||
=== Controlling Risk === | === Controlling Risk === | ||
A structural collapse can have serious consequences and all structural engineering activities should be treated as being, to some degree | A structural collapse can have serious consequences and all structural engineering activities should be treated as being, to some degree [[Risk|safety critical]]. | ||
It is important to pay special attention to the requirements of the client but such considerations should not over-ride duty of care to the publc. | It is important to pay special attention to the requirements of the client but such considerations should not over-ride duty of care to the publc. | ||
| Line 104: | Line 105: | ||
Changes to the brief should be avoided, if practical, after the Concept Stage | Changes to the brief should be avoided, if practical, after the Concept Stage | ||
This guidance about the project brief in the RIBA plan of work states that: "The project brief is likely to be presented as a report, however, where possible, information and requirements should be scheduled in a database or spreadsheet format that will be easy to expand and will be easy to use to test whether proposals satisfy requirements later in the project." Such a schedule can be viewed as a design process map or an extended plan of work | This guidance about the project brief in the RIBA plan of work states that: "The project brief is likely to be presented as a report, however, where possible, information and requirements should be scheduled in a database or spreadsheet format that will be easy to expand and will be easy to use to test whether proposals satisfy requirements later in the project." Such a schedule can be viewed as a design process map or an extended plan of work. | ||
==== Establishing the design brief ==== | ==== Establishing the design brief ==== | ||
To establish the requirments, design issues should be identified and expressed in the form of requirements. Figure 4 shows generic structural design issues. | To establish the requirments, design issues should be identified and expressed in the form of requirements. Figure 4 shows generic structural design issues. | ||
[[File:Issues-1.png|none|thumb|700x700px|Figure 4 Generic structural design issues]] | [[File:Issues-1.png|none|thumb|700x700px|Figure 4 Generic structural design issues]] | ||
'''Principles''' | |||
* Work to a process for establishing the brief | * Work to a process for establishing the brief | ||
* Ensure that all requirements have been identified and adequately stated in the Structural Design Brief | * Ensure that all requirements have been identified and adequately stated in the Structural Design Brief | ||
'' | '''Recommended verbal forms to be used in the brief''' (from GG 101-page 4) | ||
* The verb ’must’ indicates a statutory or legislative requirement. | * The verb ’must’ indicates a statutory or legislative requirement. | ||
| Line 121: | Line 123: | ||
* The verb ’may’ indicates advice expressed as a permissible approach. | * The verb ’may’ indicates advice expressed as a permissible approach. | ||
* The verb ’can’ or verbs expressed in the present tense other than ’must’, ’shall’, ’should’ and ’may’ are used to introduce notes, which provide a short clarification of a concept or statement of fact. | * The verb ’can’ or verbs expressed in the present tense other than ’must’, ’shall’, ’should’ and ’may’ are used to introduce notes, which provide a short clarification of a concept or statement of fact. | ||
'''Using the design brief''' | |||
* Work to a process for ensuring that the reqirements will be satisfied | * Work to a process for ensuring that the reqirements will be satisfied | ||
| Line 141: | Line 141: | ||
Develop a set of options to a degree of detail sufficient to assess them against the requirements. Compare them against the requirements and decide on the form of the structure to be used. | Develop a set of options to a degree of detail sufficient to assess them against the requirements. Compare them against the requirements and decide on the form of the structure to be used. | ||
'' | '''Principles for the options analsis''' | ||
* At the outset, all options should be 'on the table'. | * At the outset, all options should be 'on the table'. | ||
| Line 147: | Line 147: | ||
* Carry out partial designs for these options to provide information adequate for assessing their relative merits. | * Carry out partial designs for these options to provide information adequate for assessing their relative merits. | ||
* Assess the options using [https://eit.engineers.scot/index.php?title=Critical_thinking#Proposal_testing proposal testing] principles. | * Assess the options using [https://eit.engineers.scot/index.php?title=Critical_thinking#Proposal_testing proposal testing] principles. | ||
* Consider using a multi-criteria assessment | * Consider using a multi-criteria assessment [https://eit.engineers.scot/images/d/db/Ch2_evaluating-design-options.pdf method] | ||
==== Design brief - Stage 2 ==== | |||
The design brief should be updated taking account of the decisions made as a result of the options analysis. For example a detailed list of codes of the relevatn codes of practice should be added to the brief. | |||
==== Design proposal - Stage 2 ==== | |||
=== Production === | |||
* | * | ||