10 Aug 2022

BS 8644-1:2022 – A detailed technical review of FIREie

Introduction

On July 31st 2022, BS 8644-1:2022 (Digital management of fire safety information Part 1: Design, construction, handover, asset management and emergency response – Code of practice) was published by the British Standards Institute (BSI). Published alongside this was an Executive Summary. Both these are available here. Subsequently a piece was published in BIM+ entitled ‘The new fire safety information management standard explained’ which sets out further information about the published standard. This is available here.

Like all standards and specifications we like to make sure as a business we fully understand exactly what has to be delivered and then develop our processes to comply around these publications. As Information Managers it is our job to absorb the complexity and to try and create processes that delivery teams can actually implement and ensure we deliver exactly the information clients need.

Below we review in detail some of the key implementation sections of BS 8644-1:2022, focussing particularly on section 5 (Representation of fire safety information in FIREie) and Annex B (Suggested fire safety properties for use in building information modelling). The former of these is a requirement of BS 8644, whilst the latter is deemed ‘informative’ (meaning it is not a requirement to strictly follow this for compliance).

For us the aim here is to ‘pull apart’ the standard in order to understand the delivery challenges and build compliant processes around this. It is vital that with any standard that we understand exactly how to deliver the requirement to ensure we can comply or understand where we can’t comply.

This review doesn’t aim to discuss the need for this standard or review the specific requirements around fire, only the technical implementation and understanding of FIREie and the supporting properties that may be included in this proposed information exchange.

We would also point out that there is no connection between COBie and FIREie other than the authors of FIREie have copied the spreadsheet representation. We however use COBie throughout this piece to compare the spreadsheets to understand the key differences between these representations.

In the technical review below we offer some conclusions on our findings.

Review of BS 8644-1:2022 Section 5: Representation of fire safety information in FIREie

This section makes reference to FIREie covering both ‘new development projects and existing assets’. No information is provided on the practicality of collecting information for existing assets which are likely to differ to information collected for new assets. For example, InstallationDate would simply not be available for an existing asset so what needs to be provided? It is unclear how FIREie might be practically used in these different scenarios.

5.1.1 General

This section states “FIREie should be used to collect, collate and digitally transfer information and linked documents between appointed and appointing parties in relation to an asset.” Aligning with ISO 19650 we would expect this to read “between lead appointed parties and appointing parties”.

This section also goes on to say “It is expected that FIREie will be most commonly viewed in spreadsheet rendition. XML and IFC renditions”. No reference is made to IFC (Industry Foundation Classes) in the Bibliography and no mapping to FIREie is currently published. The authors acknowledge this in both the Executive Summary and further BIM+ response however the standard itself does not make this distinction. Regardless, it does it does not take away from the fact that the standard does not provide information on how to use these suggested views even if this information may be published at a later date.

NOTE 4 states “This includes aspects that are not present in COBie (see 0.4), e.g. the “Event” tab and fire resistance properties.” Fire resistance properties can be supported through COBie using the Attributes tab (and often are currently) so this statement is not completely correct.

5.1.2 Information transfer

This section states “To facilitate the exchange of fire safety information using open data formats, the exchange should be completed using FIREie.” However no technical information is currently published about how FIREie supports or works with open data formats other than making passing reference to IFC in section 5.1.1.

5.1.3 Relationship to FIREie to IEPs

This section states “FIREie exists to exchange structured information between interested parties in the life cycle of an asset.” By contrast COBie really only has a single exchange between the Contractor and the Client at the handover stage (although earlier exchanges often exist to check progress). The statement alludes to ‘multiple exchanges’ but provides no information on the specific purposes for these multiple exchanges. Without listing these it is difficult to know if FIREie will satisfy its intended purpose.

The section goes on to say “Each IEP should have a defined set of information deliverables that should be included in FIREie”. This implies that FIREie is used as an Exchange Information Requirement. We would not expect to include defined information deliverables in FIREie as these would be included in either Appointing Party or Lead Appointed Party’s Exchange Information Requirements that would include many other purposes for exchange.

5.1.4 Representation of fire safety information

This section states “Fire safety information, whether geometrical or data, should follow a consistent approach across all parties to improve the fire safety information exchange.” To align to ISO 19650 and BS EN 17412-1:2020 (Building Information Modelling — Level of Information Need), we believe “geometrical or data” should be changed to “documentation, geometrical and alphanumerical information”. We believe it is important to recognise that documentation will form a large part of typical information exchanges.

5.2 Completion of FIREie

This section states “The following subclauses describe the recommended content of each tab, as displayed in spreadsheet view, of FIREie, and the links between them.” Reviewing the subsequent subclauses no information is provided on the link between tabs. It has to be assumed this tried to follow COBie but where there are 3 new tabs no information is provided on how these relate to each other. COBie includes specific figures (refer to Figures 2, 3, 4 and B.1) showing the connection between each tab, unfortunately FIREie does not provide clear figures to show the relationships between tabs.

5.2.1 General

This section states that the colours follow BS 1192-4:2014. Whilst this is generally true we can find no reference to ‘black’ being used in BS 1192-4:2014.

As a side note BS 1192-4:2014 sets out HEX codes rather than RGB although it confusingly uses the word RGB in front of these HEX codes.

5.2.2 Instruction

This section includes Figure 9 which states it shows “part of an Instruction” tab. It is unclear why this is a partial diagram given all other sections are covered in 5.2.3 to 5.2.23. For the record the diagram is missing Spare (5.2.13), Resource (5.2.14), Job (5.2.15), Document (5.2.17), Attribute (5.2.18), Coordinate (5.2.19), Issue (5.2.20) and Event (5.2.21).

Figure 9 implies by its colouring that tabs coloured in yellow are ‘Required’ and tabs coloured in green are ‘If specified as required’. As the tabs listed above are missing it is not clear if the missing tabs are ‘Required’ or ‘Requirable’ (as noted in 5.1.1).

5.2.3 to 5.2.23 General

BS 1192-4:2014 sets outs next to each row of the required tabs in a Notes column if the information is ‘expected’, ‘reference’, ‘pick’, ‘application’ or ‘requirable’. Figures 10 to 30 in BS 8644-1 do not set this information out so it is not clear if these are the same requirement as COBie or different. Where new columns have been introduced to some of the tabs no Notes information is provided so it is not clear what type of information is to be provided.

5.2.3 Contact

Figure 10 shows Contact information which is identical to COBie with the addition of a ‘Competencies’ column. The example lists ‘CEng’ as an example value although 5.2.23 shows ‘BSMA’ as an example.

The example values differ in many places from those in BS 1192-4:2014 A.3 Contact.

The example ‘Category’ has listed ‘Coordinator’ but this is shown as a classification reference in BS 1192-4. We would expect the Category to be generated from Uniclass 2015 Ro Roles to provide consistency in output. As the value is different it is not clear why or not is allowed in this field.

As ‘Competencies’ is an additional column no information is published on how this is technically delivered or what information can or cannot be provided in this column. For example, if there are multiple values does the reader have to assume that values must be comma separated?

5.2.4 Facility

Figure 11 shows 7 additional columns not identified in BS 1192-4:2014 A.4 Facility. These additional fields are: ‘AddressLines’, ‘Town’, ‘Region’, ‘PostalCode’, ‘Country’, ‘Latitude’ and ‘Longitude’.

Table 8 of BS 1192-4:2014 identifies ‘RefLatitude’ and ‘RefLongitude’, which are both taken from the IFC schema, as additional Attributes. It is assumed that ‘Latitude’ is therefore delivered as ‘RefLatitude’ and ‘Longitude’ as ‘RefLongitude’ when producing IFC-SPF models if these additional columns of information are required.

The IFC schema supports address information including. ‘AddressLines’, ‘Town’, ‘Region’, ‘PostalCode’ and ‘Country’. However, BS 8644-1 does not make clear if this address information is provided agains the Project, Site or Facility (Building).

5.2.5 Floor

Figure 12 shows 4 additional columns not identified in BS 1192-4:2014 A.5 Floor (region). These additional fields are: ResistanceToFireRequiredStructure, ResistanceToFireRequiredIntegrity, ResistanceToFireRequiredInsulation and ReactionToFire. No information is provided on what information is to be populated in these fields or how to deliver this information using IFC-SPF models.

5.2.6 Space

Figure 13 shows 6 additional columns not identified in BS 1192-4:2014 A.6 Space (location). These additional fields are: ‘ResistanceToFireRequiredStructure’, ‘ResistanceToFireRequiredIntegrity’, ‘ResistanceToFireRequiredInsulation’, ‘ReactionToFireRequired’, ‘FinishedFloorLevel’ and ‘FinishedCeilingLevel’.

No information is provided on what information is to be populated in ‘ResistanceToFireRequiredStructure’, ‘ResistanceToFireRequiredIntegrity’, ‘ResistanceToFireRequiredInsulation’, ‘ReactionToFireRequired’ or how to deliver this information using IFC-SPF models.

‘FinishFloorLevel’ is covered by information provided in the ‘Elevation’ field of the Floor tab. No information is provided to enable the delivery of this information using IFC-SPF models.

‘FinishCeilingHeight’ is a duplication of ‘UsableHeight’. No information is provided on why this duplication might exist or provides information to enable the delivery of this information using IFC-SPF models.

5.2.7 Zone

Figure 14 shows 3 additional columns not identified in BS 1192-4:2014 A.7 Zone. These additional fields are: ‘ResistanceToFireRequiredStructure’, ‘ResistanceToFireRequiredIntegrity’, ‘ResistanceToFireRequiredInsulation’. No information is provided on what information is to be populated in these fields or how to deliver this information using IFC-SPF models.

5.2.8 Type

Figure 15 shows 4 additional columns not identified in BS 1192-4:2014 A.8 Type. These additional fields are: ‘ResistanceToFireStructure’, ‘ResistanceToFireIntegrity’, ‘ResistanceToFireInsulation’ and ‘ReactionToFire’. No information is provided on what information is to be populated in these fields or how to deliver this information using IFC-SPF models.

5.2.9 Component

Figure 16 shows 2 additional columns not identified in BS 1192-4:2014 A.9 Component. These additional fields are: ‘Area’ and ‘Length’. Not clear why this information is required for fire?

Example shows a Wall. Walls are excluded from BS 1192-4:2014 as they are not an entity that has planned preventative maintenance against it. A Wall would invalidate COBie but it is not clear without published rules whether a Wall would invalidate BS 8644-1.

The example shows a Wall example with a Name of ‘n/a’. If all Walls are listed as ‘n/a’ what value would any data be which is associated to these Components? BS 1192-4:2014 requires that all Names are unique. The example contravenes BS 1192-4 but it is not clear without published rules if this is acceptable in FIREie.

Walls are also shown as being associated to multiple Spaces. This is invalid in COBie except for Doors and Windows. Again unclear what the rules are for FIREie.

5.2.10 System

Figure 17 shows identical columns to BS 1192-4:2014 A.10 System.

‘ExtObject’ shows ‘n/a’. Unclear why this does not show ‘IfcSystem’ like BS 1192-4:2014.

5.2.11 Assembly

Figure 18 shows the same fields as BS 1192-4:2014 A.11 Assembly, although in a different order. ‘AssemblyType’ appears above ‘SheetName’, ‘ParentName’ and ‘ChildNames’ in BS 1192-4. It appears below in BS 1192-4.

The example lists a Slab as an example of an Assembly. A Slab is a Component and not an Assembly. The skins of the Slab (i.e., IfcMaterialLayer) would normally be considered an Assembly.

It is not clear what entities should be listed in the Assembly tab and it should be noted that a Slab would be invalid in COBie.

5.2.12 Connection

Figure 19 shows the same fields as BS 1192-4:2014 A.12 Connection.

The example Connection does not relate to the Component shown which makes it difficult to understand the relationship between these two tabs.

5.2.13 Spare

Figure 20 shows the same fields as BS 1192-4:2014 A.13 Spare.

No other comments are noted.

5.2.14 Resource

Figure 21 shows the same fields as BS 1192-4:2014 A.14 Resource.

No other comments are noted.

5.2.15 Job

Figure 22 shows the same fields as BS 1192-4:2014 A.15 Job.

DurationUnit is provided as ‘Minute’ (in BS 1192-4:2014 it is shown as ‘minute’). It is not clear why this differs and if there are different Pick Lists for FIREie compared to COBie.

Example for Priors is shown as ‘n/a’ but under BS 1192-4 this field is a required reference field. As the field is orange we would expect this to be the same in FIREie and have an actual value provided.

5.2.16 Impact

Figure 23 shows the same fields as BS 1192-4:2014 A.16 Impact.

The ‘Value’ column is shown as ‘n/a’ but this would be invalid in COBie as it is a required field (and BS8644-1 suggests it is required by colouring it yellow). Not clear without rules, what is and isn’t valid.

5.2.17 Document

Figure 24 shows the same fields as BS 1192-4:2014 A.17 Document.

The example shows ‘SheetName’ and ‘RowName’ as ‘n/a’. This would be invalid in COBie. It is not clear if the example is valid for BS 8644-1 as no rules are published.

We would expect the Category field example to show a reference from Uniclass 2015 PM Project Management table rather than the FI Form of information table.

5.2.18 Attribute

Figure 25 shows the same fields as BS 1192-4:2014 A.18 Attribute.

The example Attribute is not listed in any of the example Properties set out in Annex B. It would make more sense to use an example property from Annex B to illustrate this tab.

5.2.19 Coordinate

Figure 26 shows the same fields as BS 1192-4:2014 A.19 Coordinate, however the example shows two columns of examples side-by-side. It is not clear if this representation is different to how BS 1192-4:2014 is produced.

5.2.20 Issue

Figure 27 shows the same fields as BS 1192-4:2014 A.20 Issue. No other comments are noted.

5.2.21 Event

Figure 28 is an additional tab that is not published in BS 1192-4:2014. No detailed information is provided on the requirements for this tab.

Events that happen during the assets life are more likely to take place directly in a clients system where the data has been exchanged at the end of the design and construction phases. The information shown in this tab would not be captured during the design and construction phases of the building. This information is beyond the scope of COBie which only aims to collect information from the design and construction phases and transfer it into a technology system(s) for the operational phase.

In practical terms it is unclear how an event would be transferred in isolation given all other information is likely to have already been transferred to the clients technology system(s) at handover.

5.2.22 Package

Figure 29 is an additional tab that is not published in BS 1192-4:2014. No detailed information is provided on the requirements for this tab.

This tab looks like other tabs which are copied from COBie but provides no clarity on why it is exists or how it is to be used.

It is unclear why this information is needed for formal exchange into a clients technology system.

5.2.23 Competence

Figure 30 is an additional tab that is not published in BS 1192-4:2014. No detailed information is provided on the requirements for this tab.

This tab looks like other tabs which are copied from COBie but provides no clarity on how it is to be used.

It is not clear why this information is required to be provided as structured data. It would be more likely that this information would be captured through a documented process (e.g., Capability and Capacity Assessment) and listed as a document on the Document tab.

It is unclear how there is a direct link between the ‘Competence’ tab and the individuals listed in 5.2.3 (Contact) or any other tab in the spreadsheet.

Annex B (informative) Suggested fire safety properties for use in building information modelling

This section of the standard is described as ‘informative’ meaning it is not required to follow the information set out here to achieve compliance with BS 8644-1:2022. However we would make the following observations about the information set out in this standard currently:

Property names – The property names are extremely long and would be largely impractical in schedules. None of the properties appear to be taken from any recognised standards. Additionally it is not clear why the property ‘Asset_Dimensions_Orientation_AngletoDatum’ which ‘specifies if element is horizontal or vertical through angle to datum’ exists? This information is likely to be difficult to provide but it seems an arbitrary requirement when it comes to fire information.
Properties vs entities – Whilst some of the property names and descriptions allude to some of the entities that the properties shown apply to, no detailed information is provided on which entities must provide which properties. Again client implementations will vary, introduce potential information waste and increase cost.
GUID – A GUID is listed against each Property. GUIDs for properties are not supported by the IFC4 schema and it is not apparent how any technology could successfully provide or exchange this data between technology systems. The GUIDs presented look more like Autodesk Revit shared parameter values than GUIDs that would appear in IFC-SPF models.
Property sets – It is standard practice, when using IFC workflows, to set out Property Set information (essentially folders for Properties) in Exchange Information Requirements, to ensure data appears in a consistent location in IFC-SPF. Without this information again client implementation will vary.

Conclusion

The lack of supporting technical information in section 5 of BS 8644-1:2022 for information requirements outside of that already set out in BS 1192-4:2014 (COBie) means that most of the additional FIREie requirements will differ between client’s exchange information requirements (if clients try to implement FIREie) across the whole industry. This will lead to multiple different interpretations and implementations, resulting in additional costs and effort from delivery teams, and it is highly likely this will increase the cost of delivering projects for clients.

BS 8644-1 notes in section 0.4 that “FIREie resembles but is not the same as the COBie information schema as documented in the UK BIM Framework”. Whilst this statement may exist the reality is FIREie is an obvious copy of COBie with modifications to ‘adapt’ it to suit another use. If the authors intended it to be completely different none of the differences are described or in lieu of this the alternative technical information behind it to deliver it. For users we have to largely assume the same delivery mechanisms and processes for the parts that are the same as COBie in the absence of proper technical information to support FIREie. Behind BS 1192-4:2014 is vast amounts of technical detail covered in NBIMS-US V3 which enables the actual implementation of COBie. FIREie lacks this technical rigour and without it, it leaves questions about how the authors expect the information to be delivered consistently.

Most of the requirement for FIREie appears to be largely already deliverable via COBie, without breaking any of the rules of COBie (note: this doesn’t mean COBie should be used for this, but just an observation that there are significant parts of FIREie that are already supported by COBie currently). However COBie only includes certain entities (ones for planned preventative maintenance) and FIREie appears to include entities beyond the scope of COBie (e.g. walls). COBie therefore only supports SOME delivery of FIREie. The authors have copied the spreadsheet representation of COBie, not the standard. And that if you do adopt COBie, it wont satisfy non maintainable elements so another solution will still be required. FIREie however is not explicit on the entities it proposes to include and exclude in the information exchanges. A clear list of entities for inclusion and exclusion is critical and the authors need to consider that copying COBie for some entities simply isn’t logical. E.g., SerialNumbers for entities outside of COBie would be information waste. There is a need for a similar document to the COBie Responsibility Matrix which sets out explicitly what is and isn’t included in COBie. If the entities that COBie excludes are to included in FIREie then the authors need to publish a clear set of rules to support efficient and effective delivery. Image: Information which is captured by COBie (blue) and additional information identified by FIREie which is outside the scope of COBie (red) – click image to enlarge

Delivering BOTH COBie and FIREie in a spreadsheet format makes no practical sense as this won’t work when trying to import this data into client’s technology systems without causing somebody headaches as data will be duplicated between both information exchanges. No information is provided on how these exchanges will work together. It looks possible to develop an approach that removes any possibility of duplication but it is probably necessary to understand more about the purposes and technical requirements before deciding on a final solution.

FIREie by including ‘Event’ appears to suggest that this information exchange will be used for trigger events during the operational phase. COBie was only ever designed to exchange information from the design and construction phase into the operational phase, so with FIREie it suggests extending information exchanges into the operational phase. However it is not clear how this could ever work in practice and no information explains this from a technical point of view.

COBie is an exchange at a single point in time. i.e., handover. With FIREie it implies there are multiple exchanges to multiple parties but it is unclear how this could be technically possible as it risks importing data into technology systems multiple times. The authors of the standard have not set out how this process is expected to work. If the standard was updated to be more explicit about the data requirements then industry could look at developing solution(s) that enable one set of information (without any duplication) to be produced on projects. Fire information is only one use case for information and there is a question about how information for multiple purposes is considered.

Fundamentally though there is a bigger question about the need for an exchange requirement built around a singular purpose. The reality is that there will be lots of other information exchanges around multiple purposes, for example exchange information for carbon analysis or quantification to support consistent cost analysis. We would suggest that ultimately the requirements currently identified for FIREie will need to be considered within the context of ISO 19650-4 (Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 4: Information exchange) which is currently under development. It will be crucial to understand not just how fire information is exchanged between parties but how all information is exchanged between parties for specific purposes.

As some final words, we would say to clients that there is a need to consider the technical issues that exist in the current version of BS 8644-1 and the potential cost and programme impact of simply instructing delivery teams to comply with this standard when by the authors own admission it lacks a fully developed schema to support it. For now the British Standard should be effectively considered a work in progress (or a publicly available specification would have been a more preferable term) which needs far more technical rigour to be developed around it before industry can consistently deliver the aims of this standard across different clients, projects and sectors.

Rob Jackson, Director, Bond Bryan Digital Ltd

Terms and conditions

All content provided on this Knowledge Hub is for informational purposes only. The owner of this Knowledge Hub makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. Bond Bryan Digital Ltd will not be liable for any errors or omissions in this information nor for the availability of this information.

Bond Bryan Digital Ltd will not be liable for any losses, injuries, or damages from the display or use of this information. We are happy for others to share our Knowledge Hub pieces through all social media platforms. You may include links to the original blog pieces and use part of the Knowledge Hub to then provide a link to the original content. However we would appreciate it if the content is not reproduced in full on other sites or publications without written consent being granted by Bond Bryan Digital Ltd.

This policy is subject to change at any time.