Cross UK Report 1232 & 1170
Collaborative reporting for safer structures. Report 1232: Failure of firefighter’s lift to operate.
A firefighter’s lift switch was found not to have been connected.
A firefighting lift switch, located on the Fire Service Access Level (FSAL) of a multistorey building, failed to operate. When turned on, the switch did not recall the firefighter’s lift to the FSAL. The reporter then interrogated the operation and maintenance drawings and discovered that the switch was not connected to the relay and did nothing.
The electrical engineering drawing for the lifts showed only a communication line running to the FSAL. This was for the two-way communication between the lift car and the firefighter’s lift switch intercom.
It is felt by the reporter that those persons with responsibility for buildings are not conducting regular checks on lifts provided for the fire and rescue service (FRS) or on evacuation lifts. They suggest that there are occasions where lift engineers do not have a thorough understanding of these types of lifts.
Furthermore, the reporter feels firefighters are not checking the operation of these lifts when they conduct their familiarisation visits and that fire risk assessors are not checking test records, which is of particular importance for higher-risk buildings as it is a requirement of the Fire Safety (England) Regulations 2022 (Reg 7).
The reporter suggests that this might be a widespread issue. They hope this report will raise awareness of the guidance issued by the Lift and Escalator Industry Association (LEIA) on the tests and inspections of lifts for use by firefighters, evacuation lifts and lifts with recall.
Comments
This is, unfortunately, a common occurrence. It is often discovered firefighter’s and evacuation lift controls are not operational, either because they were never connected and tested, or because they subsequently failed and have never been subjected to periodic testing during routine maintenance.
It is rare to see any comment in a fire risk assessment regarding the existence or nature of emergency lift controls. If such provision is noted, commentary regarding their maintenance is usually limited to identifying which part of the organisation retains the maintenance certificates.
All functions should be confirmed as operational for the commissioning and sign-off. There appears to have been an initial design error, which was then missed due to error in the commissioning. These errors were then in turn missed in the ongoing maintenance.
There is a need to review what functionality is checked by different parties, including the fire service. Any reliance on commissioning checks alone is likely a flawed approach.
Highlighted guidance
Checks should follow BS 8899 Improvement of firefighting and evacuations provisions in existing lifts – Code of practice once revised, but in the meantime, advice on routine checks can be found in section 3.1 of Checks and inspections of lifts for use by firefighters, evacuation lifts, and lifts with recall on the LEIA website.
Fire Safety (England) Regulations 2022 has additional requirements for Responsible Persons and Accountable Persons of high-risk residential buildings in England. They must:
- undertake monthly routine checks of lifts for the use of the FRS and evacuation lifts and make a record available to residents. All Responsible Persons should regard regular checks such as these as best practice
- inform the FRS electronically, as soon as practicable, when an identified fault with a lift cannot be rectified within 24 hours; and
- record information on all the lifts in the building on floor plans stored within a secure information box (SIB).
Report 1182 Design criteria for firefighting lifts explains the terminology for lifts provided for use by the FRS.
Collaborative reporting for safer structures. Report 1170: Combination load cases in proprietary software cause concern.
A reporter is concerned about a widely used software package that does not, in their opinion, generate correct load combinations.
For roofs, the software combines imposed loads with snow loads and wind actions and this, the reporter says, contradicts the relevant Eurocode [clause 3.3.2(1) of EN 1991-1-1], which states that on roofs (particularly for category H roofs) imposed loads need not be applied with either snow loads and/or wind actions. They are further concerned that for certain load combinations, the software utilises incorrect load factors for leading and accompanying actions.
The reporter believes that the algorithm for the automatic generation of load combinations is incorrect and that the interface with the software does not readily allow for manual intervention. This makes it difficult for designers who rely on the software for the selection of load combinations and could lead to incorrect design outputs.
Comments
The reporter deserves credit for doing enough validation to establish that the software appears to be combining loads incorrectly and is right to have highlighted their concerns to the software supplier. Software deficiencies are relatively rare, but they do happen. Report 538 Failure to check designs produced by software, published in 2016, concerned an error in a design package that the software developer later confirmed had not been previously picked up.
It is a pre-requisite for using software that the user must be able to recognise incorrect or unexpected situations and outputs. Simply put, software should only be relied upon by those who can anticipate the outputs, otherwise they will not recognise errors in the software – or, more likely, errors in the use of the software. ‘Sense checking’ of all outputs, including load combinations, should be carried out as part of output validation.
The reporter raises an important concern about selecting appropriate load cases and factors, which should not neglect any possible circumstances – for example, where wind loading may cause uplifts on roofs, care must be taken when considering the partial factors. Under the Eurocode system, where an imposed load is favourable – as is likely in a wind uplift case – a suitable partial factor (normally zero) should be applied.
Software developers should validate that their software complies with code requirements so that users can trust the software when using it within clearly defined constraints.
When errors in commercially available software are found, suppliers should be challenged to demonstrate both the validation and the calibration of their software. Where an error in marketed software is confirmed, it would seem reasonable to expect a software house to issue revised software to all licence holders. In addition, all previous users of the software could be notified of the error so that the implications upon earlier work can be assessed.
The reporter also makes a valid point regarding the ease of checking software outputs. When selecting software, designers should think through how the outputs presented by different packages will be validated. Ultimately, the responsibility for all outputs rests with the designer, not the software supplier.
To subscribe to the CROSS UK newsletter (structural and fire safety concerns), visit cross-safety.org/uk/user/register