Fire Service modelling

Transcription

1 Fire Service modelling Fifth London Safety Plan Supporting document No.11 Consultation draft March 2013

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 nonvulnerable 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 Page 2 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). 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. 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. 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 Page 3 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 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. Page 4

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 B Care Home E Hostel F Hotel H Other Sleeping Accommodation J Further Education K Public Building L Licensed Premise M School N Shop P Other Premises Open to the Public R Factory or Warehouse S Office T Other Workplace Page 5

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. Page 6

8 Page 7

9 LONDONFIREANDEMERGENCYPLANNINGAUTHORITY ORHReport:ORH/LFB/1/1.4/2 ModellingMethodology AIntroduction 1. This paper gives an overview of ORH s modelling methodology for the emergency services,withparticularreferencetothefireservice. 2. ORHhasbeenworkingwiththeemergencyservicesintheUKandoverseas,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. AnoverviewofthemodellingapproachusedbyORHfortheemergencyservicesis providedinsectionb.theanalysisandvalidationprocessesareexpandeduponin SectionC.Amoredetaileddescriptionoftheoptimisationandsimulationmodels used by ORH is provided in Section D and a summary of the process is given in SectionE. BModelOverview 5. ORH provides a bespoke modelling service based on proven Operational Research (OR)techniques.ORHmodelshavebeendesignedtohelpunderstandthecomplex relationshipsbetweendemand,performance,resourcesandefficiency,forservices 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 oforh smodellingframeworkisgiveninfigure1overleaf. LFB/1/1.4/2 ModellingMethodology 13 th November2012 Sup 11 appendix - Page 8

10 Figure1ORH smodellingframework Sup 11 appendix - Page 9

11 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: Simulation( FireSim ); 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 supportprovidesstrategicandtacticaladvice,ensuringthatplanningdecisionsare costeffective,robustandsustainable. 10. Withspecificobjectivessuppliedbytheclient,ORH soptimisationmodellingcanfind the bestsolution giventhecriteriaandconstraintsagreed.theseoptimalsolutions canthenbetestedoutwithfullsimulationmodelling. 11. Figure2overleafillustratestheoverallprocesswhichisbasedonacomprehensive analysisofthecurrentuseofresourcestomeetdemandandprovideriskcover. 12. Keytothesimulationandoptimisationmodellingisthedevelopmentofatraveltime matrix.thematrixincorporatesdifferencesintimesduetovehicletype,response type(lightsandsirensversusnonlightsandsirens)andtimeofday. 13. Travel times between nodes on the road network are key inputs to the models. Thesetimesareassignedinitiallybasedonroadtypesthatdifferentiateachievable 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 carefullycalibratedtoreflectthosebeingachievedbyhourandbyday(seebelow andappendixaforfurtherdetails). 14. Acomprehensiveanalysisisundertakeninordertosetupthemodelsandtoensure thattheyarevalidated(ie,reflectexactlythecoverthatiscurrentlybeingprovided). Once validated the models can be used to examine a wide range of resource planningandriskcoverissues. CAnalysisandValidation DataAnalysis 15. DataAnalysisisrequiredinordertogainanunderstandingoftheFRS soperational regime, including the demand placed on the Service, the performance standard achievedandtheutilisationofresources. LFB/1/1.4/2 ModellingMethodology 13 th November2012 Sup 11 appendix - Page 10

12 Figure2 Overview Resources: Utilisation Availability Crew/VehicleTypes JobCycle: ControlActivation CrewTurnout TimeatScene,etc. Analysis Analysis Demand: Locations Frequencies IncidentTypes Performance: Distribution/Average 1 st,2 nd,3 rd,etc. IncidentTypes Simulation Optimisation Incident Distribution Deployments Incident Distribution Optimisation Criteria TravelTimes Model Parameters TravelTimes Model Parameters FireSim OGRE Attendance Performance Appliance Utilisation Minimise Response Times Optimal Locations Mapsof Coverage Reportsby SubAreas Maximise Resource Efficiency Local/Region Optimisation Sup 11 appendix - Page 11

13 16. Acomprehensive,quantitativeunderstandingoftheServiceprofilegainedthrough analysis provides a baseline position for simulation and optimisation modelling, so thattheimpactsofanychangescanbecomparedtothecurrentposition. 17. ForFRSmodelling,dataisextractedonworkloadforatleastthelastfiveyears,and potentiallyformoreyears,dependingonthesizeoftheservice.theworkloaddata issourcedfromthecadandthereforeincludeseveryappliancemobilisationduring thesampleperiod.dependingonthescopeoftheanalysis,around50datafields 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: Demand (incident frequencies, station workload, appliance workload and levelofresponse). Jobcycletimes(controlcallhandlingtimes,crewturnout,timeatscene). Attendanceperformance(firstappliance,secondappliance). 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 LFB/1/1.4/2 ModellingMethodology 13 th November2012 Sup 11 appendix - Page 12

14 Figure3DataSourcesUsedinAnalysis Core Databases Geographical Demand Appliance Workload Response Parameters IRS CAD Utilisation Incident Profile Minuteby minute analysis Sup 11 appendix - Page 13

15 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. Thesetimesareassignedinitiallybasedonroadtypesthatdifferentiateachievable 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. LFB/1/1.4/2 ModellingMethodology 13 th November2012 Sup 11 appendix - Page 14

16 Sup 11 appendix - Page 15

17 DOptimisationandSimulation Introduction 30. ThemodelsusedbyORHaredividedintotwocategories: Optimisation: OGRE (Optimisation by Genetic Resource Evolution) can be applied to answering questions around the locations of resources in any EmergencyService. 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. OptionsputforwardbyOGREarealwaysevaluatedfortheirimpactonemergency 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. LFB/1/1.4/2 ModellingMethodology 13 th November2012 Sup 11 appendix - Page 16

18 Sup 11 appendix - Page 17

19 37. TheoptimisationcriteriatobeusedinthismodellingarediscussedwiththeService, and generally focus on a particular subset of incidents with a specified weighting between 1 st and 2 nd 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: Undertaking a Servicewide optimisation to inform the Service s estates strategy. Identifyingoptimal greenfield deployments. Evaluatingthelocationsofexistingstationsincomparisontooptimalsites. Developing an optimal strategy for the deployment of pumping appliances duringperiodsofreducedavailability(eg,pandemicflu). 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). LFB/1/1.4/2 ModellingMethodology 13 th November2012 Sup 11 appendix - Page 18

20 Sup 11 appendix - Page 19

21 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: Attendance performance against a specified set of response standards for firstandsecondappliance. Attendance performance and average times by area, as specified by the Service(eg,servicedeliveryareas,boroughsandstationgrounds). 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. Theworkloadandutilisationofpumpingappliances. 44. Modelling runs tend to be iterative, feeding back emerging results for discussion withthefrsclient,andthisgeneratesideasaboutfurthermodellingruns,leading finallytoanagreedsetofconclusions.thesearethentestedbycarryingoutarange of sensitivity modelling runs, varying key inputs, to ensure that the identified solutionisrobust. ESummary 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 whichcoveriscurrentlybeingprovided.theoptimisationmodelallowsanfrsto findthe best wayoforganisingcover,andthesimulationmodelteststhedetailed impacts ofoperating in a changedmanner. Sensitivity modelling ensures that any preferredconclusionsaretestedforvariationinanyoftheinputfactors. LFB/1/1.4/2 ModellingMethodology 13 th November2012 Sup 11 appendix - Page 20

22 Sup 11 appendix - Page 21

23 APPENDICES A B C NavteqTravelTimeData OGRE OptimisationModel FireSim SimulationModel Sup 11 appendix - Page 22

24 Sup 11 appendix - Page 23

25 Example of Navteq Data A kilometers MEANWOOD HEADINGLEY CAMPUS B6159 B6159 HEADINGLEY B6157 KIRKSTALL LEEDS A65 INNER RING ROAD A647 ARMLEY B6154 LEE NEW WORTLEY HOLBECK A58 A58 A653 A643 LOWER WORTLEY A58 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 A62 Sup 11 appendix - Page 24 M621 M621, J2

26 NAVTEQTravelTimeDataandRouteFinder NAVTEQ'scomprehensivedatabuildprocessensuresthehighestqualitydataavailableforroutingandmapping applications.thedataisfromavarietyofsourcesincludinglocalgovernments,utilitycompanies,otherpublic 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. 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, numberof lanes and the urbanity of the link. 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 NAVTEQAllrightsreserved.BaseduponCrownCopyrightmaterial. Attribute Compositespeed NAVSTREETScontainsthemostnavigableattributesavailableinadatabaseandhasover50layers. Importantattributesofthedata: Speedcategoryisbasedonthelegalspeedlimitofaroadlink,howeveritalsotakesintoaccountsome physicalcharacteristicsandaccessrestrictionsthatmayresultinadifferencefromthelegalspeedlimit (eg,speedbumps,chicanes). Functionclassisaddedtotheroadlinksinthedatabasetoindicatetheirimportanceforrouteguidance. Itallowsoptimisationofroutingandreducesrouteplanningtime. Lanecategoryisbrokeninto3categories:1laneroads(ie,onelaneineachdirectionoftravel),23lane roadsand4+laneroads. UrbanareashavebeendefinedinaseparatelayerinNAVTEQtocovermetropolitanareas,townsand 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. Sup 11 appendix - Page 25 A2

27 ProportionofRoadLengthbyStreetAttribute Urban/ Rural %RoadLength UK Englandexcl.London WestYorkshire Total Fast Quick Average Slow VSlow Total lane lanes lanes Total Rural Urban Total StreetAttribute Speed Category Function Class Lane Category SpeedCategory Only7ofthe8speedcategoriesinRouteFinderareusedintheUK(category1isgreaterthan80mphand thereforeusedinothereuropeancountries). 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. Byregion,theproportionof3+6roadsrangesbetween78%(NW)and90%(SW).Lowerproportionsof category3+6roadsinsomeregions(eg,nwandyorkshire)areduetohigherproportionsofcategory7 roads(620mph)inurbanauthorities(manchester,merseyside,southyorkshireandwestyorkshire). FunctionClass 86%ofroadsfallintotwoofthefiveclasses:class4(slow;11%)andclass5(veryslow;75%)inWY. Theproportionofroadsfallingintoeachofthefiveclassesisverysimilarinallregions,includingLondon. LaneCategory AcrossEngland,around95%ofroadsare1laneroads,5%ofroadsare23laneroadsandlessthan1% are4+laneroads. TheproportionofroadsfallingintothethreelanecategoriesisverysimilaracrossallEnglishregions. Urban/Rural JustunderhalfofEnglishroads(48%)areclassifiedasbeinginurbanareas,withsignificantdifferencesin theurban/ruralsplitbyregion(from34%inthesouthwestto61%inthenorthwest).londonisan outlier with 97% urban, which is expected given that the population density in London is three times higherthananyothermetropolitanauthority,andthe8regionsoutsidelondonareamixtureofmetro andnonmetroauthorities. Thereisahighcorrelationbetweentheproportionofruralroadsandtheproportionofspeedcategory3 roadswithinaregion(rvalue=0.90).roadschangefromurbanspeedcategory6toruralspeedcategory 3whencrossingbetweenurbanandruralareas.Clearly,speedlimitsaresetwithconsiderationofbuilt upareas,andtypically,3040mphlimitsareinplaceinbuiltupareasasopposedto5060mphlimitsin moreruralareas. Sup 11 appendix - Page 26 Speed Category Range (mph) Default setting (mph) <6 3 A2

28 B E s t a b l i s h e d 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. Billions of Deployment Options Processed in Minutes 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. London Fire Brigade ORH Ltd Sup 11 appendix - Page 27

29 B 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. FRS Criteria OGRE FRS input OGRE FRS input - OGRE - Solution 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. London Fire Brigade ORH Ltd Sup 11 appendix - Page 28 orh@orhltd.com Telephone: +44 (0)

30 C E s t a b l i s h e d Simulation Modelling using FireSim What is 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. Decades of Fire Service Time Processed in Minutes How is FireSim used? 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). London Fire Brigade ORH Ltd Sup 11 appendix - Page 29

31 C The Simulation Process 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. Options FireSim Appraise FireSim Appraise FireSim Solution NAVTEQ All rights reserved. Based upon Crown Copyright material. Modelling Outcomes 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. London Fire Brigade ORH Ltd Sup 11 appendix - Page 30 mike.v@orhltd.com Telephone: +44 (0)

32 LONDON FIRE AND EMERGENCY PLANNING AUTHORITY ORH Report: ORH/LFB/1/1.4/1 Model Revalidation in 2012 A Introduction 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 previous model will be to take account of the change in shift patterns and an enhanced travel time matrix for London. B Data Analysis 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 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 previous models and to provide a robust sample of incident locations, the five most recent complete financial years of data (April 2007 to March 2012) have been used for incident distributions. 6. Appendix A1 shows how the LFEPA stop codes correspond to 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. Page 1 Sup 11 appendix - Page 31

33 FIGURE 3 ACTUAL VS MODELLED PERFORMANCE BY INCIDENT TYPE (VALIDATION PERIOD) Average Crew Response Performance (minutes:seconds) Incident Type Responder Response Type Actual* Modelled 1A 1st 1/1A 05:26 05:27 2A 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 2FX 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 Page 2 Sup 11 appendix - Page 32

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 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 Page 3 Sup 11 appendix - Page 33

35 FIGURE 2 CALL COMPONENTS BY INCIDENT TYPE Average Times (minutes:seconds) 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 2A 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 2FX 1st 00:52 01:20 03:49 05:07 40:51 2nd 01:17 01:27 05:55 07:18 31:37 Page 4 Sup 11 appendix - Page 34

36 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: 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 E421 at Biggin Hill (2.5%). 19. The crew response performance by borough for the 1 st in 6 minutes and 2 nd in 8 minutes targets is shown in Appendix C6. The map highlights the disparity in response times between Central London and outer parts of the Service. C Model Revalidation 20. ORH s Fire Simulation Model (FireSim) uses highly sophisticated Navteq travel time data. These data, when combined with RouteFinder software for producing and analysing travel time networks, provide a detailed and robust source of information, which can then be calibrated against travel times actually achieved. 21. The travel time matrix used for the most recent validation was based on Navteq data collected at the end of This was appropriate to use for the most recent validation because of the non contiguous validation period used for 2010/11. An updated version of the UK Navteq data has recently been released and this has been used as the basis for determining the base travel times. 22. The ORH travel time matrices are developed using a node system, with an appropriate geographical distribution of nodes essential for modelling purposes. The requirement for a large number of nodes to improve the granularity (and potentially Page 5 Sup 11 appendix - Page 35