Fire Service modelling

(1)

Fire Service

modelling

Fifth London Safety Plan

Supporting document No.11

Consultation draft

(2)

Fire Service modelling

There are a range of software suppliers and operational research consultants that can offer assistance to fire brigades when considering changes to their service. This documents sets out the background for not selecting the government initiated FSEC (Fire Service Emergency Cover Toolkit ) software which is used by some other brigades.

Rather than using FSEC, the London Fire Brigade choose to work with operational research consultants ORH Ltd to provide computer based fire service modelling. Appended to this document are two reports from ORH Ltd which explains the methodology of their modelling and details of how the computer model is validated against real data.

FSEC origins

The government’s Fire Service Emergency Cover Toolkit (FSEC) was the result of around ten years development and is the product of the work started by the Pathfinder project. At the time when Pathfinder was established as a project to consider national fire risk, brigades were still bound by the Fire Services Act 1947, the recommended national standards of fire cover and had very few flexibilities as to how and what services were provided.

Given the rigidity of the 1947 Fire Services Act, few brigades had any reason to examine more complex service risk assessment approaches and support in the commercial world was very limited. In this environment, FSEC was without doubt the most advanced fire service risk assessment tool available, and for perhaps the first time, that risk assessment approach was underpinned by statistical information to support professional judgement. It is therefore not surprising that the independent validation study of the FSEC methodology undertaken by Mott MacDonald in 2000, whilst finding some issues with the approach, generally accepted the methods and data underpinning the toolkit. However, since the change in fire service legislation (and guidance) in 2004, a range of new suppliers, consultants and risk assessment approaches have emerged and FSEC is no longer a sole supplier of fire risk methodologies. The

Mott MacDonald report concludes that “the [FSEC] toolkits can only inform on these issues, ultimately the amount of fire provision, and its disposition, is a result of management, financial and political decisions”.

Background

With the introduction of Integrated Risk Management Plans, senior managers in the LFB undertook discussions with a range of suppliers of software solutions and risk consultancies to assist in the development of what became the London Safety Plan. Interested parties undertook a programme of presentations detailing their product/approach and answering questions about identifying and addressing risks in London. Those presentations included the then ODPM fire statistics and research team (the team responsible for the FSEC toolkit) and ORH Ltd.

The main concerns raised during the FSEC presentation were: arrival time calculations only being measured in blocks of 5 minutes; a perceived lack of transparency between the FSEC inputs and resultant outputs; and an indicated significant resource requirement to populate the system with data.

ORH Ltd offered a more flexible, less resource intensive and significantly more transparent approach to fire service modelling and have been able to offer optimised solutions to problems, rather than just give calculated outputs. So whilst the FSEC software and hardware provided by former ODPM had been in the possession of the LFB, no use has been made of the system, nor any resource allocated to its development.

At the time, and still, there has been no mandate from government that FRS’s are obligated to use the FSEC toolkit.

Using FSEC as the only risk assessment tool

As the name indicates, FSEC is a range of individual (and in most parts independent) risk assessment tools, which together form a toolkit. Whilst the collection of the four FSEC modules (dwellings, other buildings, special service and major incidents) cover a significant proportion of fire service activities, it is not a complete model and to whatever degree fire services adopt FSEC, there Page 1

(3)

is a realistic need that additional risk assessment approaches would be needed to fill those gaps (albeit professional judgement may be deemed sufficient, as appears to be the case in some brigades in which FSEC has been adopted as the only risk assessment tool).

The most notable omissions to using FSEC as a single risk assessment tool are: • There is no demand element within FSEC. All calculations are based on all

FRS resources being available, at base location, to attend individual risks. • Only life risk incidents are modelled, so no account is made of high volume,

low risk incidents such as secondary fires, AFA’s or lift releases (of non-vulnerable persons).

• Attendance standards. As FSEC models attendance in blocks of 5 minutes, it could not be used to inform decisions about the benefits of adopting attendance standards at less than 5, or less than 10 minutes.

• The statistics are based on national data and fire rates with few provisions for local adjustment. The difference is most notable in the other buildings model, where the trend for fires in other buildings in London differs from the national trend [see appendix 1].

Using FSEC with other risk assessment tools

In March 2006, the LFB surveyed all English fire and rescue services on their use of FSEC and other risk assessment tools. Of the 34 responding, 11 (32 per cent) were using FSEC as the only risk assessment tool, with 17 (50 per cent) using FSEC alongside other risk assessment tools and 6 (18 per cent) either having never used FSEC or since stopped using FSEC.

For those eleven brigades using FSEC as the only tool, and given some of the limitations already highlighted, it is unclear in light of the new and emerging risk approaches whether the FSEC methodology alone would be sufficiently robust for an independent review (such as that previously undertaken by Mott Macdonald) to conclude that all risks have sufficiently been covered.

It would most certainly be the case in London that any use of FSEC would be alongside other risk assessment tools, as was the case for 50 per cent of the brigades surveyed in 2006.

How FSEC compares to LFB approach

In some ways the methodology used in FSEC and the approach taken by LFB are similar in that both model on the more serious incidents. In the FSEC dwellings and special services modules this is done by way of life risk incidents (an aggregation of those incidents where fatalities, casualties or rescues occurred). In LFB this has been done, through the work of ORH Ltd, by considering all two pump (or larger) incidents, although the outcomes of this work is also validated against life risk incidents.

Whilst both consider a selection of incidents rather than the full range, the methodology is quite different. FSEC aggregates its life risk incidents into risk areas and groups (by type), and then assesses the arrival times of appliances to those areas (predominantly census output areas). The LFB approach is to consider the demand of those incidents (with two, or more, pump incidents being those where a life risk is more likely) and the ability to meet the desired attendance standard.

It is therefore not unreasonable that the optimum location for appliances and stations would differ between the two approaches albeit both are intended to address the more serious incidents. This view is mainly due to:

• The LFB approach seeks to maximise attendances within 6 and 8 minutes, whilst FSEC would seek to maximise them within 5 and 10 – and therefore with the potential that some stations/appliances could be located further apart with no obvious reduction in calculated risk/service, as to FSEC, once the five minute threshold has been passed, there is no calculated benefit in arriving in the next one minute compared to the next four minutes.

• The LFB approach considers the demand of the incidents being modelled and the ability to match the demand with the resources, whereas FSEC makes no account for demand (and therefore the potential that high demand areas would receive no more cover than low demand areas).

Page 2

• FSEC calculates attendance times on the basis of the 24,000 (approx.) census output areas in London, where as ORH Ltd base their range and response cover on 3,500 nodes.

(4)

An advantage of the ORH Ltd modelling approach is that it offers a range of optimised solutions, in that it can make recommendations for service

improvement. FSEC offers no such solution optimising, so that all changes to services must be decided outside of the FSEC environment, then tested, with potentially many variations having to be tested before the ‘best’ solution is found.

The FSEC model views Community Safety as a mitigation for longer attendance times. The Risk Areas it identifies for targeted community safety focus less on the needs and lifestyles of the residence but rather a calculation of Census proxies and distance from fire station. Risk Areas are whole census output areas and therefore it is unclear how useful FSEC outputs, if given to borough and station based staff, would be for the targeting of community safety activities. An example of this would be dwelling fires where there is no distinction between accidental and deliberate fires, for which prevention approaches are significantly different. This identification of incident type with cause is a strength of the Brigade’s Incident Risk Analysis Toolkit (iRAT) approach currently being used by stations and borough to target community safety activity (including home fire safety visits).

Implementing FSEC

Implementing FSEC requires a significant brigade input and staffing resource. From informal discussions with brigades which are using FSEC, the most significant resource time, both initially and on-going, is the maintenance of the underpinning ordnance survey integrated transport network (ITN) GIS layer on which all attendance times are derived. A view expressed by the CLG fire statistics team is that the ITN can be used ‘raw’ as it provides a general model for attendance times; but there is no knowledge of any brigades that use FSEC having done that, with all spending significant time correcting, maintaining and updating the ITN on an on-going basis with detailed and granular information on transport schemes, road layouts and real-time timed runs.

For those areas of other brigades which share a similar attendance time profile to census output areas for London, then this work is understandable. From preliminary analysis [not FSEC], 97.7 per cent of output areas in London have an average arrival time (first pump) of ≤ 10 minutes and 32.2 per cent have an

average arrival time of ≤ 5 minutes. But significant proportions have an average arrival time of either 5 minutes (24 per cent) or 6 minutes (29 per cent). Given the intolerance of FSEC to accommodate improvements in service at less than 5 minute attendance time blocks, the output areas on the cusp of 5 and 6 minutes could see sizable worsening or improvement in service on the basis of flawed ITN data.

It is also understandable that the work on the ITN would need to be completed before any modelling work is carried out; it being the case that the outputs of proposed service changes (or indeed implemented service changes) could be improved, or worsened, just through changes to the ITN. Anecdotal evidence suggests that at least one brigade has been correcting the ITN for over two years, without yet running the FSEC models in any meaningful way. Furthermore, the GIS on which FSEC and the ITN are maintained does not easily support the exchange of data with other GIS systems (including those used in LFB), so this investment of time and information is not always available for use in other FRS projects.

In the informal discussions with FSEC brigades, they considered a hypothetical London resources of six people for nine months ‘optimistic’ to achieve an accurate and reflective update of the ITN - a period of time during which FSEC wouldn’t be running, or in use, just the underpinning data corrected.

As well as updating the ITN, there is also the process of defining risk groups and risks areas for the dwellings, other buildings and special services modules (which are different in each module) and for creating planning scenarios (similar to PDA’s) and defining fire stations and appliances. Whilst this work can take place simultaneously with the updating of the ITN, resources would be required to do this. And whilst the FSEC computers are capable of running on their own local network, they are not designed, nor intended to be run as part of the FRS’s IT infrastructure. This creates problems with the upload and maintenance of data (and in particular incident data) as well as excluding the FSEC system from the security, backup and contingency planning of other FRS IT systems.

(5)

Page 4 Non-domestic buildings site assessments

The work of Pathfinder, and the intention of FSEC, is that all non-domestic buildings would receive an individual site assessment and associated life risk/building damage score through the regulatory fire safety regime. Until such time as all non-domestic buildings have been assessed, then those not assessed are assigned a default life risk/building damage score.

If the default scores and data are to be used, then there is again a level of work required to correct and update the Valuation Office data (on which the defaults are based) as this is known to be inaccurate. The London data suffers from a particular problem where there are a number of companies registered at London addresses (for trading purposes) but where no actual trade takes place. If these aren’t removed then this inflates the calculated risk of the non-domestic buildings where they are registered.

A common view within brigades using FSEC, and indeed the advice of the CLG fire statistics department, is that a reasonable model of non-domestic buildings module can be achieved from the accurate population of only five occupancy types; with those being hospitals, care homes, HMOs, hostels and hotels (known in FSEC circles as the 5Hs). In doing so, FRS’s accept that their other buildings risks are calculated on national averages and not local known occurrences of incidents, but this approach, if FSEC were to be used, would lessen the burden on regulatory fire safety teams and would put London in no worse situation than many other brigades. That being said, it would only be after running the module that the non-domestic buildings data could be validated and at which time further site assessments of the 5H property types may be required, which would have an impact on regulator fire safety inspecting officers within borough teams.

(6)

Appendix 1 - LFB incidents in other buildings compared to FSEC national rates

The table below show how the rates of fire in other buildings in London compare and differ from the National rates (based on 2006 data).

FSEC Code Description VO building counts FSEC Fire Rates (per 1,000) FSEC Predicted no.of fires LFB Actual Fire Rates (per 1,000) LFB Actual no.of fires Difference in No. of Fires Difference in Fire Rates Percentage difference A Hospital 220 930 205 973 214 9 42.7 4.59 B Care Home 1928 46 89 75 144 55 28.7 62.36 E Hostel 125 130 16 80 10 -6 -50.0 -38.46 F Hotel 1173 30 35 102 120 85 72.3 241.00

H Other Sleeping Accommodation 391 78 30 645 252 222 566.5 726.27

J Further Education 754 200 151 110 83 -68 -90.0 -44.96

K Public Building 2268 38 86 6 14 -72 -31.8 -83.75

L Licensed Premise 12541 33 414 27 336 -78 -6.2 -18.81

M School 3223 37 119 34 111 -8 -2.6 -6.91

N Shop 89133 4.8 428 7 644 216 2.4 50.52

P Other Premises Open to the Public 7921 38 301 38 304 3 0.4 0.99

R Factory or Warehouse 14056 11 155 6 78 -77 -5.5 -49.54

S Office 68177 7.2 491 4 261 -230 -3.4 -46.82

T Other Workplace 37558 11 413 7 247 -166 -4.4 -40.21

239468 1594 2933 2113.1 2818 -115 519.1 -3.91

(7)

Response time modelling and validation

The following two reports are provided by ORH Ltd (the suppliers of operational research consultancy to the LFB) and explain their approach to modelling and how the model is validated against real incident data.

1. Modelling methodology (13 November 2012)

2. (LFB) Modelling revalidation in 2012 (2 September 2012) Note: Some pages in the ORH documents are intentionally blank.

(8)

(9)

LFB/1/1.4/2 ModellingMethodology 13thNovember2012 BModelOverview AIntroduction

LONDONFIREANDEMERGENCYPLANNINGAUTHORITY

ORHReport:ORH/LFB/1/1.4/2

ModellingMethodology

1. This paper gives an overview of ORH’s modelling methodology for the emergency

services,withparticularreferencetotheFireService.

2. ORH has been working with the emergency services in the UK and overseas, using

these modelling techniques, for over 26 years, and in that time has undertaken about 600 studies for over 100 clients. ORH has worked with 14 Fire and Rescue Servicesusingthismodellingapproach,typicallysupportingtheirIRMPprocess.

3. ORH models have been used to support resource planning and strategic

development across several sectors, for provider organisations, commissioning agenciesandGovernmentdepartments.

4. An overview of the modelling approach usedby ORH forthe emergency services is

providedinSectionB.Theanalysisandvalidationprocessesareexpandeduponin Section C. A more detailed description of the optimisation and simulation models used by ORH is provided in Section D and a summary of the process is given in SectionE.

5. ORH provides a bespoke modelling service based on proven Operational Research

(OR) techniques. ORH models have been designed to help understand the complex relationships between demand, performance, resources and efficiency, for services involving emergency response (Fire, Ambulance and Police) and public access to facilities.

6. The modelling process involves validation (accurately representing the current

situation),optimisation(identifyingthe‘best’solutions),simulation(asking‘whatif?’ questions)andsensitivitymodelling(testingthatsolutionsarerobust).Anoverview

(10)

Figure1ORH’sModellingFramework

(11)

LFB/1/1.4/2 ModellingMethodology 13thNovember2012 CAnalysisandValidation

7. ORH modelling can help clients appraise and refine plans for operational change

beforeimplementation,therebyreducingriskandincreasingthechanceofsuccess.

8. A suite of ORH models has been developed inhouse over the last two decades

across the three emergency services. Two main types of model are used for FRS consultancywork:

x Simulation(‘FireSim’);

x Optimisation(‘OGRE’–OptimisingbyGeneticResourceEvolution’).

9. Simulation modelling can test the impact of changes to individual factors, such as

demand and resource levels, and to a combination of factors. ORH modelling support provides strategic and tactical advice, ensuring that planning decisions are costeffective,robustandsustainable.

10. Withspecificobjectivessuppliedbytheclient,ORH’soptimisationmodellingcanfind

the‘bestsolution’giventhecriteriaandconstraintsagreed.Theseoptimalsolutions canthenbetestedoutwithfullsimulationmodelling.

11. Figure 2 overleaf illustrates the overall process which is based on a comprehensive

analysisofthecurrentuseofresourcestomeetdemandandprovideriskcover.

12. Keytothesimulationandoptimisationmodellingisthedevelopmentofatraveltime

matrix. The matrix incorporates differences in times due to vehicle type, response type(lightsandsirensversusnonlightsandsirens)andtimeofday.

13. Travel times between nodes on the road network are key inputs to the models.

These times are assigned initially based on road types that differentiate achievable speeds in ‘average’ traffic conditions. ORH uses sophisticated Navteq travel time data and RouteFinder routing software for analysing travel times. This provides a comprehensive and customisable resource for ensuring that journey times are carefully calibrated to reflect those being achieved by hour and by day (see below

andAppendixAforfurtherdetails).

14. Acomprehensiveanalysisisundertakeninordertosetupthemodelsandtoensure

thattheyarevalidated(ie,reflectexactlythecoverthatiscurrentlybeingprovided). Once validated the models can be used to examine a wide range of resource planningandriskcoverissues. DataAnalysis 15. DataAnalysisisrequiredinordertogainanunderstandingoftheFRS’soperational

regime, including the demand placed on the Service, the performance standard achievedandtheutilisationofresources.

(12)

Figure2

Overview

Model Parameters Incident Distribution TravelTimes Deployments Attendance Performance Appliance Utilisation Reportsby SubAreas Mapsof Coverage FireSim Model Parameters Incident Distribution TravelTimes Optimisation Criteria Minimise Response Times Optimal Locations Local/Region Optimisation Maximise Resource Efficiency OGRE Analysis Demand: Locations Frequencies IncidentTypes Performance: Distribution/Average 1st_,2nd_,3rd_,etc. IncidentTypes Resources: Utilisation Availability Crew/VehicleTypes JobCycle: ControlActivation CrewTurnout TimeatScene,etc.

Simulation

Optimisation

Analysis

(13)

LFB/1/1.4/2 ModellingMethodology 13thNovember2012

16. A comprehensive, quantitative understanding of the Service profile gained through

analysis provides a baseline position for simulation and optimisation modelling, so thattheimpactsofanychangescanbecomparedtothecurrentposition.

17. ForFRSmodelling,dataisextractedonworkloadforatleastthelastfiveyears,and

potentiallyformoreyears,dependingonthesizeoftheService.Theworkloaddata issourcedfromtheCADandthereforeincludeseveryappliancemobilisationduring the sample period. Depending on the scope of the analysis, around 50 data fields maybecollectedforeachmobilisationincluding:geographical/addressinformation, alltimecomponents,vehicletypes,incidentclassification,etc.

18. In addition to the workload data from the CAD, other information sources include

data regarding appliance unavailability (in terms of OTR data for wholetime and retained appliances), station and appliance locations, mobilisation protocols, geographicboundaries(eg,stationgroundsandcommandareas).

19. AsummaryofthedatasourcesusedintheanalysisofdataforanFRSisprovidedin

Figure3overleaf.

20. A comprehensive data checking process is first undertaken, ensuring that ORH’s

interpretation is correctly validated against the FRS’s own information summaries. Typicalanalysisoutputsthenrelatetodemand,performance,resourceuseandkey jobcyclecomponents(eg,timesspentatscenebyincidenttype). 21. Theanalysisincludes,butisnotrestrictedto,thefollowingaspects,allofwhichare consideredatdifferenttemporalintervals,byincidenttype,byappliancetypeandby respondernumber:

x Demand (incident frequencies, station workload, appliance workload and

levelofresponse). x Jobcycletimes(controlcallhandlingtimes,crewturnout,timeatscene). x Attendanceperformance(firstappliance,secondappliance). x Resourceuse(applianceutilisation). ModelValidation

22. Model validation is the process whereby the model is calibrated against known

performance.Oncethisprocessiscompletedsatisfactorily,therecanbeconfidence that model outputs will accurately reflect changes in model inputs (eg, changes in stationlocationsorappliancedeployments).

23. There are a number of stages involved in preparing a validated model, and these

require a detailed level of understanding around the manner in which the Service functions (gained through data analysis and consultation), and sophisticated

(14)

Figure3DataSourcesUsedinAnalysis

IRS

CAD

Utilisation

Geographical Demand Minuteby minute analysis Appliance Workload Incident Profile Response Parameters

Core

Databases

(15)

LFB/1/1.4/2 ModellingMethodology 13thNovember2012 operationalresearchtechniques.TheORHconsultancyteamassignedtothisstudy areexperiencedinsuccessfullyvalidatingandrunningmodelsinUKFRSs.

24. Inordertorepresentfluctuationsindemand,performanceandapplianceavailability

that occur across the day, modelling periods are developed to ensure that the validation approach is robust. These are agreed with the Service and can be structured so as to take account of existing or proposed shift systems. An aggregated 24/7 model is also produced, and is used to present appropriate summariesoftheresults.

25. Travel times between nodes on the road network are a key input to the model.

These times are assigned initially based on road types that differentiate achievable speeds in ‘average’ traffic conditions. ORH uses sophisticated Navteq travel time

dataandRouteFinderroutingsoftwareforanalysingtraveltimes(seeAppendixA).

26. An appropriate travel time network is developed based on the existing station

locations,historicalincidentlocations,censusdataandtheunderlyingroadnetwork. The number of nodes within the matrix is representative of the local and Service widedemand.

27. A careful calibration process is then undertaken that gives appliance travel times

brokendownfordifferentperiodsoftheday,andfordistinguishingspeedsachieved bydifferentincidenttypes,basedonananalysisoftraveltimescurrentlyachievedby appliances.

28. Modelvalidationaimstoensurethatthemodelisaccuratelyreflectingperformance

across the entire spectrum of responses, not just focusing on a particular point or theaveragetime.Inaddition,firstandsecondapplianceattendancesarevalidated individuallyandinacombinedmanner.Finally,thevalidationprocessalsomatches modelledandactualutilisationofappliances.

29. Duringthemodelvalidationprocess,andinallfutureapplicationsforthemodel,all

responses to all incidents are simulated, even though the Service may only be concerned (in performance terms) with first or second attendance to a particular incident type. This ensures that appliance availability and utilisation levels are accurate.

(16)

(17)

LFB/1/1.4/2 ModellingMethodology 13thNovember2012 DOptimisationandSimulation

Introduction

30. ThemodelsusedbyORHaredividedintotwocategories:

x Optimisation:OGRE(Optimisation by Genetic Resource Evolution) can be

applied to answering questions around the locations of resources in any EmergencyService.

x Simulation: individual simulation models have been developed for each of

theEmergencyServices–AmbSim,PolSimandFireSim.

31. TwoORHmodelsarethereforeusedtoexamineoptionsforchangestudiesforFRSs:

OGRE (an optimisation model used to identify and evaluate location options) and

FireSim(asimulationmodelusedtoassesstheimpactsofchange).Fulldescriptions

ofthemodelsaregivenbelow.

32. OnceFireSimisvalidated,itispossibletopopulateOGREwithdemandfrequencies,

geographical incident distributions, the road network and a subset of input parameters.AsthemodellinginputshavebeenvalidatedinFireSim,OGREcanthen be used with confidence to identify potential changes in appliance deployments. Options put forward by OGRE are always evaluated for their impact on emergency responsetimesthroughafullsimulationrunusingFireSim.

33. The combination of the optimisation model (to identify and develop potential

solutions) and the simulation model (to fully evaluate options through a complete simulation of operational activity), coupled with input from the Service, can thereforedevelopoptionsforchangewhichmeettheService’srequirements.

Optimisation

34. OGRE is a powerful optimisation model that can optimise the deployment of

emergency service resources. It uses a sophisticated genetic algorithm to assess millionsofoptionsinminutes,quicklyidentifyingoptimumsolutions.Themodelis runbyexperiencedmodellingconsultantsandtheoptimisationcriteriaarecarefully agreedwiththeclienttoensurethatsolutionsmeetindividualclient’sneeds.

35. OGREisaflexiblemodel,designedtoidentifythescopeforoperationalefficiencies,

improving service delivery and optimising the location of resources. Further

informationaboutOGREisprovidedinAppendixB.OptionsgeneratedbyOGREare fullyevaluatedintheappropriatesimulationmodeltoconfirmthatoptimalsolutions deliverserviceimprovements. 36. Forundertakinganyoptimisationmodellingitisnecessarytocarefullyconsiderthe criteriawhichwillbeused.OGREprovidestheflexibilitytolookforoptimalsolutions whichmeetanygivenoptimisationobjective.

(18)

(19)

LFB/1/1.4/2 ModellingMethodology 13thNovember2012

37. TheoptimisationcriteriatobeusedinthismodellingarediscussedwiththeService,

and generally focus on a particular subset of incidents with a specified weighting

between 1st and 2nd pump attendances. When solutions are tested in FireSim, all

incidents are included in the modelling so as to capture all pumping appliance activityandaccuratelymonitorperformancestandards. 38. Thebroadaimofoptimisationmodellingistodevelopeffectiveandefficientoptions forthedistributionofoperationalresources,includingthenumberofappliancesat eachlocation. 39. Therangeoftheoptimisationcouldincludethefollowingaspects:

x Undertaking a Servicewide optimisation to inform the Service’s estates

strategy.

x Identifyingoptimal‘greenfield’deployments.

x Evaluatingthelocationsofexistingstationsincomparisontooptimalsites.

x Developing an optimal strategy for the deployment of pumping appliances

duringperiodsofreducedavailability(eg,pandemicflu).

x Producing sitesearch maps to define optimal locations and informing the

Service’sassetmanagement. Simulation

40. FireSim is a sophisticated simulation models that simulates operational service

delivery – the model is run inhouse by experienced modelling consultants. All of ORH’s simulation models are spatially dependent discrete event simulations developedspecificallyforemergencyserviceoperations.Oncevalidated,themodels can provide evidencebased answers to a wide range of ‘what if’ questions. The impactofchangestoanumberofoperationalfactors,suchasstationlocationsand appliance deployments, duty systems and resource use, service demand and responseregimes,canbefullyassessed.FurtherinformationaroundFireSimisgiven

inAppendixC.

41. In the simulation model, incidents are generated at specific locations and vehicles

are assigned to respond based upon rules covering incident types, crew skills and operational mobilising protocols. The full job cycle for each incident is simulated usingtimestomobilise,reachtheincident,beatscene,andreturntostation.The simulation models report operational performance in terms of attendance times, vehicle workload and capacity for nonincident workload (eg, community safety work).

(20)

(21)

LFB/1/1.4/2 ModellingMethodology 13thNovember2012 ESummary

42. FireSimcantakeaccountoftheoccurrenceoflarge,multipumpincidentsinvolving

extendeddurationsonscene.Itreflects‘simultaneousincidents’automaticallyand processes unavailability in line with measured ‘off the run’ levels. It can model a varietyofdutysystems.

43. The presentation of results from FireSim is fully customisable and outputs can be

shownintabularandmappedformatsasappropriate.Theexactformatisdiscussed withtheServiceanditispossibletoproduceresultsencompassing,butnotlimited to,thefollowing:

x Attendance performance against a specified set of response standards for

firstandsecondappliance.

x Attendance performance and average times by area, as specified by the

Service(eg,servicedeliveryareas,boroughsandstationgrounds).

x The geographical coverage given by a particular option in terms of a map

showing areas which either meet or fall outside of specified attendance standards.

x Theworkloadandutilisationofpumpingappliances.

44. Modelling runs tend to be iterative, feeding back emerging results for discussion

with the FRS client, and this generates ideas about further modelling runs, leading finallytoanagreedsetofconclusions.Thesearethentestedbycarryingoutarange of sensitivity modelling runs, varying key inputs, to ensure that the identified solutionisrobust.

45. ORH’s modelling approach has been developed over at least two decades across

several hundred assignments for about 100 emergency service clients. The applicationofthisapproachtoFireandRescueServicesintheUKhasbeenrefined overthelasttenyearsandhasbeenusedin14FRSsinthelastfiveyears.

46. The validation stage ensures that the base model accurately reflects the way in

which cover is currently being provided. The optimisation model allows an FRS to findthe‘best’wayoforganisingcover,andthesimulationmodelteststhedetailed impacts of operating in a changed manner. Sensitivity modelling ensures that any preferredconclusionsaretestedforvariationinanyoftheinputfactors.

(22)

(23)

APPENDICES A NavteqTravelTimeData B OGRE–OptimisationModel C FireSim–SimulationModel

(24)

(25)

LEEDS LEEDS LEEDS LEEDS LEEDS LEEDS LEEDS LEEDS LEEDS LEEDS LEEDS LEEDS LEEDS LEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDSLEEDS

HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUS HEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUSHEADINGLEY CAMPUS

A647 A647 A647 A647 A647 A647 A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647A647

A58 A58 A58 A58 A58 A58 A58 A58 A58 A58 A58 A58 A58 A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58A58

A62 A62 A62 A62 A62 A62

A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62A62

A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65 A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65A65

A653 A653 A653 A653 A653 A653 A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653A653

INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROAD

B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154 B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154B6154 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159 B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159B6159 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157 B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157B6157

INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROAD INNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROADINNER RING ROAD

M621 M621 M621 M621 M621 M621 M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621M621 M621, J2 M621, J2 M621, J2 M621, J2 M621, J2 M621, J2 M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2M621, J2 LOWER WORTLEY KIRKSTALL HEADINGLEY ARMLEY NEW WORTLEY HOLBECK MEANWOOD LEE LEE LEE LEE LEE LEE LEE LEE LEE LEE LEE LEE LEE LEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEELEE

0 1.000

kilometers

Example of Navteq Data

(26)

NAVTEQTravelTimeDataandRouteFinder

NAVTEQ'scomprehensivedatabuildprocessensuresthehighestqualitydataavailableforroutingandmapping applications. The data is from a variety of sources including local governments, utility companies, other public agencies,andcommercialmappingagencies.AerialphotosanddifferentialGPSareusedtoaccuratelyposition roads and represent lakes, rivers, railroads, etc., and proprietary software is then used to add navigable information,addresses,andpointsofinterest.

NAVTEQdatahasbeenadditionallyroadtestedtocollectandverifynewdata,anddrivesaretakentoconfirmthe accuracy of all information contained in the database. Photographs are also taken of all overhead signage to ensurethatthedataaccuratelyreflectstherealworld. NAVSTREETScontainsthemostnavigableattributesavailableinadatabaseandhasover50layers. Importantattributesofthedata: x Speedcategoryisbasedonthelegalspeedlimitofaroadlink,howeveritalsotakesintoaccountsome physicalcharacteristicsandaccessrestrictionsthatmayresultinadifference fromthelegalspeedlimit (eg,speedbumps,chicanes). x Functionclassisaddedtotheroadlinksinthedatabasetoindicatetheirimportanceforrouteguidance. Itallowsoptimisationofroutingandreducesrouteplanningtime. x Lanecategoryisbrokeninto3categories:1laneroads(ie,onelaneineachdirectionoftravel),23lane roadsand4+laneroads.

x Urban areas have been defined in a separate layer in NAVTEQ to cover metropolitan areas, towns and settlements.UrbanisappliedtoallroadlinksthatfallwithintheNavteq‘BuiltUpArea’polygon.

RouteFinder is a MapBasic program which works in MapInfo. It creates a street network from Navteq tables. Changescanbemadetothenetworksuchasclosingroads,changingspeedsandchangingthedirectionoftravel. RouteFinder can be used to calculate the shortest times and distances along roads between points. Multiple drivetimeisochronesandcatchmentareascanbecreatedaroundmanypointsinatable. ©NAVTEQAllrightsreserved.BaseduponCrownCopyrightmaterial. FieldName Description Link_ID Uniquereference StNm_Base Streetname Ref_Intrsect_ID Intersectingroadlinks Func_Class Typeofroad Speed_Cat Roadspeedcategory Lane_Cat Numberoflanes Dir_Of_Travel Onewayorbothdirections AR_EmerVeh Accessibilitytovehicles Bridge Levelsofroads ControlledAccess Generalaccessibility Urban Urban/Ruralidentifier Attribute Compositespeed

There are over 90 fields associated with each section of road, including those listed in the table below. Four properties of each road section (shown in bold) are used to determine the potential speed achieved (or ‘attribute’), taking account of road type, speed restrictions, number of lanes and the ‘urbanity’ of the link.

(27)

ProportionofRoadLengthbyStreetAttribute

SpeedCategory x Only7ofthe8speedcategoriesinRouteFinderareusedintheUK(category1isgreaterthan80mphand thereforeusedinotherEuropeancountries).

x 63% of roads fall into category 6 (2130mph) in West Yorkshire. These categories are generally coterminous with the urban/rural definitions. Generally, category 3 roads exist in rural areas and category 6 roads exist in urban areas. There is an inverse relationship between the proportion of category3and6roadsataregionallevel. x Byregion,theproportionof3+6roadsrangesbetween78%(NW)and90%(SW).Lowerproportionsof category3+6roadsinsomeregions(eg,NWandYorkshire)areduetohigherproportionsofcategory7 roads(620mph)inurbanauthorities(Manchester,Merseyside,SouthYorkshireandWestYorkshire). FunctionClass x 86%ofroadsfallintotwoofthefiveclasses:class4(slow;11%)andclass5(veryslow;75%)inWY. x Theproportionofroadsfallingintoeachofthefiveclassesisverysimilarinallregions,includingLondon. LaneCategory x AcrossEngland,around95%ofroadsare1laneroads,5%ofroadsare23laneroadsandlessthan1% are4+laneroads. x TheproportionofroadsfallingintothethreelanecategoriesisverysimilaracrossallEnglishregions. Urban/Rural x JustunderhalfofEnglishroads(48%)areclassifiedasbeinginurbanareas,withsignificantdifferencesin the urban/rural split by Region (from 34% in the South West to 61% in the North West). London is an outlier with 97% urban, which is expected given that the population density in London is three times higherthananyothermetropolitanauthority,andthe8RegionsoutsideLondonareamixtureofmetro andnonmetroauthorities.

x Thereisahighcorrelationbetweentheproportionofruralroadsandtheproportionofspeedcategory3 roadswithinaRegion(rvalue=0.90).Roadschangefromurbanspeedcategory6toruralspeedcategory 3whencrossingbetweenurbanandruralareas.Clearly,speedlimitsaresetwithconsiderationofbuilt upareas,andtypically,3040mphlimitsareinplaceinbuiltup areasas opposedto 5060mphlimits in moreruralareas. UK Englandexcl.London WestYorkshire 2 4 5 4 3 48 44 13 4 1 1 1 5 3 3 6 6 39 42 63 7 6 6 13 8 1 1 1 Total 100 100 100 1Fast 3 3 3 2Quick 5 6 4 3Average 7 7 8 4Slow 13 12 11 5VSlow 72 73 75 Total 100 100 100 1lane 95 95 96 23lanes 5 5 4 4+lanes 0 0 0 Total 100 100 100 Rural 45 48 26 Urban 55 52 74 Total 100 100 100 Urban/ Rural StreetAttribute %RoadLength Speed Category Function Class Lane Category 1 80 69 2 65-80 69 3 55-64 59 4 41-54 50 5 31-40 37 6 21-30 25 7 6-20 13 8 <6 3 Speed Category Default setting (mph) Range (mph)

A2

(28)

© ORH Ltd. 2010

©

London F

ire Brig

ade

OGRE - Optimisation Modelling for FRSs

OGRE is a unique program that can be used

to optimise the deployment of appliances.

A sophisticated genetic algorithm assesses

billions of options, quickly identifying

optimal deployment solutions.

The model is run by ORH modelling experts

and outputs then discussed with the FRS.

OGRE was specifically developed for use

within the UK Fire & Rescue Services.

OGRE is fully customisable and can be

tailored to the specific needs of the

individual FRS.

Optimisation criteria are determined

through consultation with the client – what

is the FRS trying to achieve?

OGRE identifies optimal solutions that

minimise attendance times.

Optimisation modelling can identify scope

for operational efficiencies.

Billions of Deployment Options Processed in Minutes

E s t a b l i s h e d 1 9 8 6

(29)

Comprehensive workload analysis is

undertaken to provide modelling inputs

alongside detailed travel times.

The FRS specifies the criteria and any

locations and deployments that are to

remain fixed in the model runs.

OGRE can be used to consider any

combination of appliances, crewing and

stations in finding the optimal solution.

Multiple attendance standards can be

processed for any incident type sets and

PDAs.

Solutions found through OGRE are

discussed with the FRS in a series of

iterative modelling runs.

Preferred options identified by OGRE are

then evaluated in full simulation mode

using ORH’s Fire Simulation Model (FSM).

OGRE can be used to produce a ranked list

of options for appraisal by the FRS.

The advanced Operational Research

techniques utilised in OGRE, supported by

FSM, produce clear and concise results.

FRS Criteria – OGRE – FRS input – OGRE – FRS input - OGRE - Solution

(30)

©

London F

ire Brig

ade

Simulation Modelling using FireSim

FireSim - the Fire Simulation Model - is a

sophisticated program designed specifically

for modelling fire appliances.

The model simulates appliances attending

calls given specified PDAs by incident type.

FireSim is used by ORH experts in

operational research and draws on the

professional experience of the client.

FireSim was specifically developed for use

within the Fire Service.

Once validated, FireSim can be used to test

any scenario put forward by the client or

identified through OGRE optimisation.

FireSim

provides an evidence-based

answer to any ‘what if?’ question.

Full assessments can be made for any

change in controllable factors (appliance

deployments, shift systems, mobilisation

policy, station locations, etc).

Uncontrollable factors are also modelled

(eg, future projected demand profiles).

Decades of Fire Service Time Processed in Minutes

E s t a b l i s h e d 1 9 8 6

H

o

w

i

s

F

i

r

e

S

i

m

u

s

e

d

?

W

h

a

t

i

s

F

i

r

e

S

i

m

?

C

(31)

© ORH Ltd. 2011 © London Fire Br ig ade

Email: [email protected]

Telephone: +44 (0)118 959 6623

Comprehensive workload analysis is

required in order to provide modelling

inputs alongside detailed travel times.

FireSim is carefully validated against the

actual attendance times achieved by

appliances in the Fire Service.

The model will simulate years of data in

seconds, allowing a large number of

options to be appraised.

FireSim runs for each period of the day,

taking account of variations in demand,

and variation in travel times.

Results from FireSim are fully tailored to

the needs of the Fire Service.

Attendance standards are output for 1

st

,

2

nd

, 3

rd

, etc responder by incident type.

The model produces results for the whole

FRS and by sub-area.

FireSim allows the client to understand the

impact of options for change on utilisation.

FireSim solutions are discussed with the

client through iterative model runs.

Options FireSim Appraise FireSim Appraise FireSim Solution

T

h

e

S

i

m

u

l

a

t

i

o

n

P

r

o

c

e

s

M

o

d

e

l

i

n

g

O

u

t

c

o

m

e

s

C

(32)

B Data Analysis

A Introduction

LONDON

FIRE

AND

EMERGENCY

PLANNING

AUTHORITY

ORH

Report:

ORH/LFB/1/1.4/1

Model

Revalidation

in

2012

1.

ORH’s

models

were

most

recently

updated

in

Summer

2011,

and

it

is

now

timely

to

refresh

the

models

with

more

up

‐

to

‐

date

demand

and

performance

data,

and

improved

travel

time

modelling.

2.

This

paper

presents

summaries

of

current

workload

and

performance,

and

determines

appropriate

sample

periods

for

incident

distributions

and

modelling

parameters

(see

Section

B).

The

approach

undertaken

to

validate

the

model

and

the

results

of

this

process

are

given

in

Section

C.

3.

All

of

the

analysis

and

modelling

work

presented

in

this

paper

is

in

relation

to

pumping

appliances

only,

and

does

not

include

special

appliances.

The

most

significant

changes

from

the

will

be

to

take

account

of

the

change

in

shift

patterns

and

an

enhanced

travel

time

matrix

for

London.

4.

ORH

was

provided

with

incident

and

response

data

from

the

Incident

Management

System

(IMS)

by

the

LFEPA.

Data

held

by

ORH

now

encompasses

the

period

1

st

April

1999

to

31

st

March

2012.

5.

It

has

been

determined

that

the

most

recent

complete

financial

year

of

data

(2011/12)

will

be

used

for

demand

rates,

performance

measurement

and

appliance

availability

to

validate

the

model

against.

To

ensure

consistency

with

the

incident

types

used

in

the

analysis

presented.

The

incident

types

are

determined

by

the

stop

codes

and

the

number

of

pumping

appliances

attending.

The

five

different

incident

types

are

shown

in

Figure

1

overleaf.

(33)

FIGURE 3 ACTUAL VS MODELLED PERFORMANCE BY INCIDENT TYPE (VALIDATION PERIOD)

Incident Type Responder Response Type Actual* Modelled

1A 1st 1/1A 05:26 05:27 1st 1/2A 04:49 04:49 2nd 2/2A 06:15 06:15 1F 1st 1/1F 05:49 05:47 1X 1st 1/1X 05:56 05:55 1st 1/2FX 05:06 05:05 2nd 2/2FX 06:44 06:43 *Excludes incidents with a crew response performance greater than 20 minutes Average Crew Response Performance (minutes:seconds) 2A 2FX Page 2

(34)

7.

Appendix

A2a

presents

the

demand

level

by

month

and

incident

type.

The

demand

does

fluctuate

by

incident

type

between

months

but

generally

a

fairly

natural

pattern

occurs.

The

number

of

‘1F’

incidents

(1

‐

appliance

fires)

varies

more

than

the

other

incident

types,

peaking

in

May

2011.

The

demand

by

day

is

presented

in

Appendix

A2b

.

8.

Appendix

A3a

shows

the

average

response

performance

by

month

over

the

last

financial

year.

Appendix

A3b

shows

the

performance

on

a

daily

basis

over

the

last

financial

year.

The

London

‐

wide

performance

is

broadly

consistent

over

the

year

with

only

a

few

days

noticeably

worse

than

the

norm.

9.

To

validate

against

periods

when

normal

operational

activity

is

being

carried

out

is

essential

as

the

primary

use

of

the

model

will

require

comparison

to

the

base

position

of

169

appliances

across

112

stations.

The

most

recent

complete

financial

year

(April

2011

to

March

2012)

can

be

confidently

taken

as

a

reliable

sample

period

for

demand

rates

and

performance

measurement.

10.

The

geographical

distributions

of

incidents

(for

each

of

the

five

incident

types

listed

in

Figure

1

)

are

mapped

in

Appendices

B1

to

B5

using

a

five

‐

year

sample

period

(April

2007

to

March

2012).

The

distribution

of

false

alarm

incidents

(Types

1A

and

2A)

are

highly

concentrated

around

Central

London.

The

most

evenly

distributed

incidents

are

one

‐

appliance

fires

(Type

1F).

11.

A

geographical

correlation

analysis

(covering

the

five

‐

year

sample)

is

presented

for

each

of

the

five

incident

types

in

Appendix

B6

.

As

expected,

false

alarm

incidents

have

the

strongest

year

‐

on

‐

year

correlations.

For

all

incident

types

the

analysis

shows

that

the

correlations

become

only

marginally

weaker

as

the

time

period

increases;

this

supports

the

use

of

a

five

‐

year

sample

for

incident

distributions

to

be

used

in

the

model

validation.

12.

As

from

May

2011

shift

changeover

times

have

changed,

with

the

day

shift

now

running

from

0930

to

2000

(previously

0900

to

1800).

As

a

result,

a

greater

proportion

of

demand

now

falls

during

the

daytime

shift

as

shown

in

Appendix

C1

.

To

make

it

possible

to

effectively

explore

the

consequence

of

potential

crewing

changes

by

shift,

the

changeover

times

have

been

taken

into

account

when

selecting

suitable

modelling

periods.

13.

In

addition

to

the

shift

changeover

times,

demand

and

crew

turnout

by

time

of

day

are

also

key

factors

in

selecting

appropriate

modelling

periods.

Appendix

C2

presents,

by

half

hour,

the

demand

by

incident

type

and

the

average

turnout

time

by

responding

appliance.

The

day

has

been

broken

up

into

7

modelling

periods,

3

during

the

day

shift

and

4

during

the

night

shift.

They

are

as

follows:



Day

–

Modelling

Period

1

(MP1)

09:30

to

12:30



Day

–

Modelling

Period

2

(MP2)

12:30

to

17:00



Day

–

Modelling

Period

3

(MP3)

17:00

to

20:00

(35)

FIGURE 2 CALL COMPONENTS BY INCIDENT TYPE

Incident Type Responder Control

Activation Crew Turnout Time to Scene

Crew Response

Performance Time at Scene

1A 1st 00:51 01:13 04:19 05:32 10:31 1st 00:45 01:17 03:33 04:50 11:06 2nd 00:48 01:24 04:59 06:22 08:34 1F 1st 00:51 01:15 04:47 05:59 18:46 1X 1st 01:00 01:17 04:51 05:59 18:32 1st 00:52 01:20 03:49 05:07 40:51 2nd 01:17 01:27 05:55 07:18 31:37

Average Times (minutes:seconds)

2A

2FX

(36)

C Model Revalidation



Night

–

Modelling

Period

4

(MP4)

20:00

to

22:30



Night

–

Modelling

Period

5

(MP5)

22:30

to

01:00



Night

–

Modelling

Period

6

(MP6)

01:00

to

07:00



Night

–

Modelling

Period

7

(MP7)

07:00

to

09:30

14.

The

graphs

presented

in

Appendix

C3

give

various

half

‐

hourly

analyses

in

terms

of

different

performance

aspects

for

the

one

‐

year

‘validation

period’,

broken

down

by

responding

appliance.

15.

A

summary

of

the

average

times

for

all

components

by

incident

type

is

given

in

Figure

2

opposite.

16.

The

London

‐

wide

crew

response

performance

distribution

is

presented

in

Appendix

C4

and

shows

the

cumulative

proportion

of

responses

falling

within

each

minute

for

1

st

and

2

nd

appliance

responses

to

all

incident

types.

17.

Appendix

C5

presents

an

analysis

of

the

utilisation

for

all

pumping

appliances

in

London,

based

on

the

amount

of

time

spent

travelling

to,

attending

and

returning

from

incidents.

The

amount

of

time

spent

carrying

out

various

other

tasks

is

not

taken

into

account.

18.

The

average

utilisation

for

all

appliances

in

London

was

7.4%.

The

appliance

with

the

highest

level

of

utilisation

during

financial

year

2011/12

was

A242

at

Soho

(16.5%);

the

appliance

with

the

lowest

utilisation

was