Structural design processes

Structural design requires the use of system planning where the overal process and the sub-processes need to be optimised. This article demonstates how system planning is applied in structural engineering design.

Since every strucuture is different and innovatiion may be needed, a flexible approach to the processes is needed.

Figure 1 shows how, in the creation of a structure, one starts with a set of requirements that represent the objecties and constraints forthe 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. In this article, processes used in structural design are discussed

Figure 1 Stages in the creation of a structure

A basic model of the design process

Figure 2 Design process stages

Figure 2 shows a model of the design process as an instance of the Top-down strategy. The 'system model' is information about the stucture being designed and about its context.

The process is not normally linear. Iterations and revisions are made based on continuous review activity,

At the the Inception Stage, requirements for the performance of the stucture and for the design process are established and information about, for example, the site is identified.

At the Conception Stage, investigations are carried out leading to a decisoin about the general form of the structre to be adopted.

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

The Institution of Structural Egineers publishes a Structural Plan of Work that sets out an overall process for structural engineers working on the design of a building.

The stages in the IStructE Plan of Work are shown in Figure 3.

Figure 3 Stages in the IStructE Plan of Work

A process map for structural design is shown in Table 1.

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.

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

Reducing risk, e.g. risks of collapse, inadequate performance, cost escalations, etc, is a fundamental strategy in engineered processes. A structural collapse can have serious consequences and all structural engineering activities should be treated as being, to some degree safety critical.

Structural egineers have a duty of care to ensure that what they design will be safe to use.

Naval architect, Stephen Payne, designer of the Queen Mary 2, said (at a talk given to the Institution of Engineers in Scotland in 2020). "When designing a cruise liner, the regulations represent the starting point for my safety assessment. The Titanic met the then current regulations." Hundreds of people might drown if a passenger liner was lost at sea. There are equivalent risks in structural design e.g. for a long span bridge or the roof of a sports stadium. Use of the principle that the starting point for design should be the regulations should be adopted in all strutural designs. This requires critical thinking by all participants.

Structural design briefs should require that consideration should be given to the issues that are not covered by standards and that analysis models should be validated [reference needed].

Design Programme

The work of the project is controlled by a programme where tasks are defined and allocated and timelines are established.

Items in such a programme include:

Task descriptions
Task schedules.
Manpower schedules
Reviews

Core actions in preparing a project programe include:

Break down the work into tasks.
Estimate the time it will take to complete each task.
Define the precedence of the tasks, i.e. decide which tasks can be carried out in parallel and which need to be handled consecutively.
Identify any lead times needed for starting the tasks - e.g. where one needs to wait for information to be delivered.
Identify critical tasks, i.e. those which if not done on time will cause delay in the overall completion
Draw up a schedule for the work, typically using a bar chart which shows when each task should start and finish. Leave some slack in the system to allow for unforeseen circumstances.
Record progress and update the task times as the work proceeds.

Task Assignment

When assigning a task, take account of (a) the competence of the person who is to carry out the task and (b) the need to train people to do the task.

Reviews

Regular review meetings should be included in the schedule to address:

Progress in relation to the programme.
Progress in relation to meeting the requirements

Milestone reviews Two major reviews in the design plan are:

At the end of the concept stage the state of the design is reviewed to ensure that what is proposed has the potential to satisfy the requirements i.e. that the design is valid. This results in a Design Proposal for agreement by the client.
The final review assessesm the outcomes against the requirements.

Critical thinking is a key attribute in review work. Constantly asking reflective questions and responding to them is essential for ensuring successful outcomes. Key reflective questions are:

Validation: Is the process suited to the context?
Verification: Has the process been correctly implemented?

Inception Stage

Structural design brief

This is a collection of all requirements that may affect the structural design including information about the processes to be used. At Stage 1, it should, if practical, not relate to a specific structural form so as not to limit the scope of the options to be considered.

The brief starts with the client requirements and is developed at the Concept Stage based on information from the options analysis. At the end of Stage 2, a Stage 2 Design Brief should be issued and therafte changes to the brief should be avoided, if practical.

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."

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.

Figure 4 Generic structural design issues

Principles

Work to a process for establishing the brief
Ensure that all requirements have been identified and adequately stated in the brief

Recommended verbal forms to be used in the brief (from GG 101-page 5)

The verb ’must’ indicates a statutory or legislative requirement.
The verb ’shall’ indicates a requirement of the Overseeing Organisation.
The verb ’should’ indicates advice expressed as a recommendation.
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.

Using the design brief

Be vigilant throughout the design process about requirements conformance
At design review meetings have requirements conformance on the agenda.
Ensure that that the mandatory requirements have been satisfied.

Explain why any non-mandatory requirements have not been fully satisfied.

Site information

This document may include information about: topography, existing site features, former usage, services, ground conditions, etc.

Conception Stage

Options analysis

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'.
Select a set of 'candidate options' that have potential to meet the requirements
Carry out partial designs for these options to provide information adequate for assessing their relative merits.
Assess the options using proposal testing principles.
Consider using a multi-criteria assessment 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

This document is similar to the Approval in Principle document for bridges and to the Basis of Structural Design document recommended in the IStructE Plan of Work.

It is recommended that the Design Proposal - stage 2 includes:

1. A project description

2. Reference to documents:

Site Information
Options Analysis Report
Structural Design Brief (Stage 2)

3. Information about the proposed structure - what has been decided at the end of the Concept Stage (this may part of the Options Analysis Report)

4. Statements in relation to:

The requirements that have been addressed at the end of Stage 2.
Actions/processes needed at the Production Stage to ensure that all requirements will be properly addressed.
Issues to be addressed that are not included in codes of practice. This is especially important in innovative contexts. See, for example, the Ronan Point Collapse

Production Stage

Technical assessment

Technical assessment is the combined use of analysis modelling and performance criteria to seek to ensure that the structure will satisfy the technical requirements set out in the Design Brief - Stage 2. A main requirement of technical assessment is to ensure that the strucutre will be stable i.e. that it will not be close to collapse.

Analysis modelling

There is significant risk that errors in the modelling will cause the structure to be unsafe and therefore a fit for purpose analysis modelling process must be used.

Conformance to technical criteria

Validation of technical criteria

It is essential that all the relevant code of practice critera are addresses. It is also very important to be vigilant for issues that are not covered by codes of practice and may not have been identified in the Design Proposal - Stage 2 document.

Performing the calculations

Code of practice rules should be processed using software that has been subject to rigorous QA assessment.

Hand calculators should only be used in preliminary work and back-of-an-envelope checks. They should not be used for final calculations because of the increased risk of errors.

A process is needed for checking that:

the input to calculations is correct,
the calculations have been correctly implemented
all criteria have been satisfied.

Drawings and specifications

A process is needed to verify that the decisions made are correctly implemented in the drawings and specifications that are used to construct the structure and for other purposes.

Design verification report

This report should:

demonstrate that the mandatory requirements have been satisfied and show how the non-mandatory requirements have been addressed.
record the validation of the processes used and how theys were verified.
serve as a record for archiving purposes of what has been done .

Typical contents of a verification report:

1. Modelling

Description of the models used.
Modelling reviews: model validation, results verification

2. Code of practice calculations.

Record of calculations
Record of verification processes

3. Stability and Robustness report.

4. Sustainability Report

5. Access and Maintenance strategy

6. Cost analysis

7. Construction Methods statement