Adriano O. Solis, Ali Asgary, Jenaro Nosedal‐Sánchez and Beatrice Zaccaro 

March 1, 2018 

Developing a fire response test bench based on NFID  

 

 

Table of Contents  EXECUTIVE SUMMARY                              2  PROJECT OBJECTIVE                              3  NFID: INITIAL ANALYSIS AND QUALITY ASSESSMENT                      3    

DATA AVAILABILITY AND CONSISTENCY                       3  

FIRES IN RELATION TO OTHER EMERGENCIES                       6  INCIDENT DATASET: CURRENT CASE STUDY                      12  INCIDENT GENERATION ENGINE                        20  RESPONSE SIMULATION MODEL                        23  

MODEL DESCRIPTION                          23  

SIMULATION RESULTS (FUNCTIONALITY VALIDATION OF THE MODEL)               32  CONCLUSIONS AND FURTHER RESEARCH                       38  

EXTENSION AND IMPROVEMENT OF THE DEVELOPED MODELS                39  ACKNOWLEDGMENT                             39  REFERENCES                               39  AUTHOR BIOGRAPHICAL INFORMATION                                     40  LIST OF TABLES AND FIGURES                              41          

 

2  

 Executive Summary 

Based on assumptions of completeness and consistency of fire incident data reported in theNational Fire InformationDatabase (NFID) for the 11‐year period from 2005 through 2015, theresearch team had proposed to develop, by leveraging relevant information in the NFID, asimulation engine that would provide fire departments across Canada with a tool for fireprevention,riskanalysis,preparedness,training,andresponsemanagement.

Our initialevaluationof thevariousNFIDdata fields,however,showedveryseriousgapsboth intermsofmissingdatavalues(blanks)aswellasapparent inconsistencies inthedataasreported.Moreimportantly,ourreviewofannualreportsofatleastfourcities(threeinOntarioandoneinAlberta)showedthatfireincidentsconstituteverysmallpercentagesofoverallincidentstheyhavereportedrespondingto.ThishasrendereddevelopmentofthesimulationmodelusingNFIDdata,aspreviouslyenvisioned,unattainable.WerequestedtheassistanceoftheVaughanFireandRescueService(VFRS),whoseofficialsagreedto provide relevant information in their 2009‐2016 database, subject to a non‐disclosureagreement between YorkUniversity and the City of Vaughan.Wewere provided full 2009‐2016incidentdatasets(includingrespondingunits,civiliancasualties,andfirefightercasualties).We proceeded to develop amodelling and simulation (M&S) framework involving two separatesimulation models: (i) an Incident Generation Engine, a discrete event simulation model usingcoloredPetrinets,whichcreates a listof incidentsbasedonempiricaldistributionsover timeofemergencyincidentsandtheirkeyattributes,and(ii)aResponseSimulationModel,anagent‐basedsimulation model which uses as inputs the list of incidents generated by the first model. Bothsimulationmodelshavebeentestedandpreliminaryresultsarereportedhere.Whileverification,validation and accreditation (VV&A) have constantly been conducted in the development andapplicationofthetwomodels,bothmodelsaremaystillbefurtherrefinedandimproved.1

1 This is anupdated versionof our researchproject report on ‘Developing a fire response simulation testbenchbasedonNFID’. TheproposalassubmittedtotheCanadianAssociationofFireChiefs inDecember2016hadspecifieda12‐monthprojecttimetable.Delaysinprojectapproval/contractingresultedinaccessto the NFID datasets by research team members commencing only on April 12, 2017, even as projectcompletion and report submission deadline remained specified as December 31, 2017.We submitted apreliminarydraftonthatdate,whileindicatingsubmissionofanupdatedreportbyMarch1,2018.

 

3  

 Project Objective 

This research project was initiated to develop a simulation engine leveraging the National FireInformationDatabase(NFID)inordertoprovidefiredepartmentsacrossCanadawithadatadriventoolforevidence‐basedplanningandresponsetofireincidents,therebyhelpingthemcreatesafercommunities.

FinancialsupportwasprovidedintheformofagrantfromtheCanadianAssociationofFireChiefs(CAFC).

NFID: Initial Analysis and Quality Assessment 

DATAAVAILABILITYANDCONSISTENCY

TheNFIDwasmadeavailabletotheresearchteaminitiallyonApril12,2017– intwomaindatafiles, one with information about incidents and the other containing information about victims(civiliansandfirefighters)forthe11yearsfrom2005through2015.Theincidentdatasetincluded128fields(columns)with467,929reportedincidents(rows),whilethevictimdatasetincluded30fields (columns)with15,326 reported cases (rows). In addition, anNFIDDataDictionary andanNFIDUserGuidewereprovided.

After initial analysis,we reported to the CAFCResearchGrantsAdministrator onApril 28, 2017aboutanumberofissues/concernswiththedatasets.Amongothers,wehadfoundthefollowing:

Multiple incidents with the same Incident ID (INCDNTID). In one very extreme case, forinstance,142incidentsreportedforSaskatchewanhadtheexactsameIncidentID.

Clarificationwas requiredwith respect todefinitionsof certain fields, including apparent

inconsistenciesinvaluesforcertainfields.Forexample,anentryof8intheBuildingHeight(HEIGHT) fieldmaybe interpretedeither in termsof abuildingwith8 storeysor as ‘Notapplicable(vehicle,outsidearea,etc.)’.

WewerereferredtoStatisticsCanada’sProjectLead,CanadianCentreforJusticeStatistics,Social,HealthandLabourStatistics,who– inaconferencecallwiththeresearchteamonMay4,2017–providedinsightsandclarificationonsomeofthefieldsinquestion.

On July 14, 2017, updated versions of the incident and victimdatasetswere released, aswell asslightlymodifiedversionsoftheNFIDDataDictionaryandtheNFIDUserGuide.The‘new’incidentdatasetcontainsthesamenumberofincidents,buthas136fields(columns).Notably,thefirstfieldinthisupdateddatasetistheLinkingID(LINK_ID)whichsequentiallynumberstheincidentsfrom1through467,929.

The current incident dataset accordingly contains 136 fields, which correspond to specificattributesthatshouldberecorded/reportedforeachincident,alldefined/explained,alongwiththe

 

4  

codingvalues(i.e.,individualcategories,counts,magnitudes,etc.)intheNFIDDataDictionaryandtheNFIDUserGuide.

However,ourmacro‐analysisofboththeoriginalandupdatedversionsoftheincidentandvictimdatasets, we detected a very significant amount of missing values (blanks) that would haveconstitutedcriticalinputsforourmodellingandsimulation.

OurfirstfindingwasthattheNFIDdoesnotcontaininformationforallCanadianprovinces.Dataforonlysixprovinces(otherthantheCanadianArmedForcesasaseventhjurisdiction)arereported.Moreover,theNFIDdoesnotreport11yearsofincidentsforallthesesevenjurisdictions:

Only2005‐2014dataareavailableforOntario;datafor2015aremissing.

DataforSaskatchewancoveronlytheyears2012‐2015;datafor2005‐2011aremissing.

Intermsofthetemporaloccurrenceofincidents,thedataspreadsheetcontainsthefollowingfields:YEAR,MONTH,DATE,DAY, andTIME. In exploring data availability in theNFIDwith respect tothesefields,wefoundthefollowing:

YEAR:availablefor100%ofthelistedincidents.

MONTH and DATE: available for 95% of the listed incidents; no data reported for NewBrunswickandforCanadianArmedForces.

TIME: available for only 44 % of the reported incidents; not available for the entireincidentsrecordfromOntario.

Thefollowingfieldspertaintothelocationofeachfireincident:INCIDLOC(IncidentLocation),CSD(Census Subdivision Code),CSD_NAME (Census SubdivisionName),CMACA (CensusMetropolitanArea/CensusAgglomeration),CMA_NAME(CensusMetropolitan/AgglomerationAreaName).

INCIDLOC:availablefor94.4%ofthelistedincidents.However,responsesarenotprovidedinastandardizedform,whichimpairstheiruseforareliablespatialanalysis.

CSDandCSD_NAME:availablefor85.4%ofthelistedincidents.InthecaseofSaskatchewanonly0.2%ofthelistedincidentsreporttheCSD.

CMACAandCMA_NAME:availableforonly70.4%ofthereportedincidents.

Averyrelevantdatafieldforpurposesofmodellingandsimulationoffiredepartmentoperationalperformance are the times to respond to incidents. In the NFID, the response time in minutes(RESPONSE),referringtothetimebetweenreceiptofthealarm/callbytheFiredepartmenttothearrivalofthefirstresponders(i.e.,ResponseTimeofFirstVehicleatthesceneofthe incident), isoneofthefields.Unfortunately,thisinformationisquitescarceintheNFID.

RESPONSE:availableonlyforthejurisdictionofAlberta(13.2%ofthereportedincidents).

 

5  

Infact,amoredetailedreviewoftheRESPONSEdataforAlbertaindicatesmanyinconsistenciesinthecoding.31.4%ofthevaluesarehigherthan60minutes(duetothecountofsuchvalues,thosecannot reallybe consideredaspotential statistical outliers).Moreover,30.5%of all the reportedvaluesare“999”,whichisclearlyproblematic.Afterremovingtheapparentlywronglycodedvalues,thedatagoesdowntoonly68.1%ofrecordedresponses,whichtranslates into9%oftheoverallincidentsreportedintheNFID.

Other relevant fields have to do with resources dedicated to the response, among others:CREWSIZE,NUMBEROFENGINES,NUMBEROFAERIALS,NUMBEROFTANKERS.

CREWSIZE:available for50.4%of thereported incidents,but, in fact, isonlyreportedforOntario.Oftheresponsesrecorded,45.2%arecodedas“0”(whichbearsnomeaning),andthe remaining values range from 1 to 251 ‐ which all clearly suggest the necessity of averificationofmanyofthereportedvalues.

NUMBEROFENGINES:entriesavailableforlessthan1%ofthelistedincidents.

NUMBEROFAERIALS:entriesavailableforlessthan1%ofthelistedincidents.

NUMBEROFTANKERS:entriesavailableforlessthan1%ofthelistedincidents.

Since the locations of the incidents are not reported in a consistently usefulway, an alternativerelevant piece of information for our research project is the reported distance from the firstresponderlocationtotheincidentlocation.ThisinformationisprovidedbytheDISTANCE(Distancefromfiredepartmenttoemergency,whichisspecifiedinkilometers)field.

DISTANCE: available for 50.4% of the listed incidents, and in fact only reported for theincidents from Ontario. However, 45.1% of the values entered are “0”, which may beinterpretedasanactualdistanceshorterthan0.5kmormayrepresentimpropercodingforan undetermined/non‐recorded distance. On the other hand, the remaining values are intheinterval[1,4600],withlargervaluesbeingdoubtfulasactualdistancesinkilometers.

WhiletheNFIDrepresentsasetofrelevantdatafortheanalysisofvariousfactorsassociatedwiththeoccurrenceof fires,areport issuedinSeptember2017bythetheCanadianCentre for JusticeStatistics [4], prepared for the Canadian Association of Fire Chiefs, summarizes the jurisdiction(provinces)thatprovidedincidentdataforvariousNFIDfields–ineffectindicatingotherdatagapsbeyondtheoneswehavereportedabove. 

 

6  

FIRESINRELATIONTOOTHEREMERGENCIES

Theproportionoffiresandfirerelatedincidentsinrelationtoothertypesofemergenciesthatfiredepartmentsrespondto,astheresearchteamfound,isperhapsequallyassignificantas,ifnotevenmore critical than, the issues and concerns raised above regarding availability andconsistency/qualityoftheNFIDdataforpurposesofourresearch.TherelevanceandusefulnessofNFID as a national database – one that allows the development of evidence‐based research toenablebetterunderstandingandawarenessof fire incidentsandcreateknowledge for improvingfiredepartmentresponsiveness–becomesdoubtfulwhenconsideringthefactthatfiredepartmentoperations coverwaymore than responding to fire incidents.We initially reviewedTorontoFireServicesoperationsdataasreleasedinJuly2017:

https://www1.toronto.ca/wps/portal/contentonly?vgnextoid=e04015093da69510VgnVCM10000071d60f89RCRD.

InFigures1‐8,wereportonbreakdownsofemergencyincidentsthatwererespondedtobythefiredepartments/servicesoffourcities–Calgary,Ottawa,Toronto,andVaughan–ineachoftheyears2011and2016.Thisissomehowindicativeofevolution,inthecaseofthesefourcities,ofincidentbreakdowns over the most recent five‐year period (2011‐2016). Fire departments’ workloadsclearlydonotcomeexclusively,norevenprincipally,fromfireorfirerelatedincidents,asmaybereadilygleanedfromthesefigures.

 

7  

FIGURE1.CALGARYFIREDEPARTMENT:BREAKDOWNOFEMERGENCYINCIDENTS,2011(DataSource:CalgaryFireDepartmentAnnualReport2011[2])

FIGURE2.CALGARYFIREDEPARTMENT:BREAKDOWNOFEMERGENCYINCIDENTS,2016(DataSource:CalgaryFireDepartmentAnnualReport2016[3])

 

8  

FIGURE3.OTTAWAFIRESERVICES:BREAKDOWNOFEMERGENCYINCIDENTS,2011(DataSource:OttawaFireService2011AnnualReport[7])

FIGURE4.OTTAWAFIRESERVICES:BREAKDOWNOFEMERGENCYINCIDENTS,2016(DataSource:OttawaFireServices2016AnnualReport[8])

 

9  

FIGURE5.TORONTOFIRESERVICES:BREAKDOWNOFEMERGENCYINCIDENTS,2011(DataSource:TorontoFireServices2011AnnualReport[9])

FIGURE6.TORONTOFIRESERVICES:BREAKDOWNOFEMERGENCYINCIDENTS,2016(DataSource:TorontoFireServices2016AnnualReport[10])

 

10  

FIGURE7.VAUGHANFIREANDRESCUESERVICE:BREAKDOWNOFEMERGENCYINCIDENTS,2011(DataSource:VaughanFire&RescueService2011AnnualReport[11])

FIGURE8.VAUGHANFIREANDRESCUESERVICE:BREAKDOWNOFEMERGENCYINCIDENTS,2016(DataSource:VaughanFire&RescueService2016AnnualReport[12])

 

11  

In2011,forinstance,forthesefourcities,thepercentagesoffireandfirerelatedincidentstototalincidents responded to by their fire departments ranged between 3.7% and 13% (see Table 1).Accordingly,thesefiredepartmentsrespondedtomuchlargerproportionsofnon‐fire incidents–whichwould not be reported in theNFID.More significantly, the last two columns of Table 1 –corresponding to the numbers of fire incidents reported in the NFID fields CMA_NAME andCSD_NAME, respectively – indicate that very small proportions of fire department resourceassignmentsactuallyfoundtheirwayintotheNFIDin2011.Thisobservationwouldalsoapplytoallotheryearsinthe2005‐2015timehorizoncurrentlycoveredbytheNFID.

TABLE1.FIREINCIDENTSREPORTEDINNFIDIN2011COMPAREDWITHTOTALINCIDENTSRESPONDEDTOBYFOURCITYFIREDEPARTMENTS

Itshouldbementionedthat,insomeannualreports,thebreakdownofincidentsdoesnotseparateactualstructuralfiresfromotherfirerelatedemergencies(e.g.,vehiclefiresoropenfires).Wheredifferentiation of structural fires is made, a narrower range of 3% to 10% (Fraser InstituteResearchBulletin,2015[6]).Intermsofallocationofresources(firevehiclesandcrewsassigned),responding to fire incidents demandsmore resources than other incident types. For instance, in2016, responses to fire incidents in Toronto corresponded to almost 60% of the unit responses(TorontoFireServices2016AnnualReport[10]).Itisclear,nonetheless,thatresourcesdemandedbytheother,morefrequenttypesofemergencieshaveadirectimpactonafiredepartment’sabilityto respond to fire incidents. For purposes of modelling and simulation of a fire department’soperations,therefore,itisnecessarytoincludeallthecategoriesofincidentsrespondedtobyafiredepartment.

In light of the above‐cited gaps in key operational data (incident location, time of alarm receipt,response time, etc.), as currently reported in the NFID, our research team decided to seek theassistanceoftheVaughanFireandRescueService(VFRS),intheprovinceofOntario,inordertobeabletodevelopasimulationmodelasenvisionedinourproposal.

OuraimwastodevelopafairlygenericmodelthatcouldbereplicatedforfiredepartmentsacrossCanada,foraslongastheappropriatesetofoperationaldataarecollectedandmaintainedbysuchother fire departments.Our case study and the resulting simulationmodelwouldnot have beenpossiblewithouttheassistanceandactiveparticipationofkeyofficialsofVFRS(FireChief,DeputyFire Chief, and a Fire Captain overseeing themaintenance of their incident database). The VFRS

City

Total 

Incidents

Fire & Fire 

Related Incidents % of Total

in Field 

CMA_NAME

in Field 

CSD_NAME

Calgary 50,520 1,869 3.7% 1,320 1,190

Ottawa 26,370 3,421 13.0% 1,164 1,126

Toronto 145,334 10,248 7.1% 6,925 3,368

Vaughan 10,166 813 8.0% None 369

No. of Incidents Reported in NFID

 

12  

dataset consisted of operational data covering the years 2009 through 2016. Throughout theconduct of our case study and the associated modelling and simulation (M&S) effort, the VFRSofficials provided clarification and guidance with respect to the interpretation and use of therelevantdatafields.

Theremainingsectionsofthisreportwilldescribetheoverallcasestudy,includingtheinformationthat we processed and the platforms/methods we employed to build the M&S framework. Wedecided to develop the simulation framework taking into account the standard informationavailableinthecaseofVFRSatfiredepartmentlevel(inaccordancewithdirectivesissuedbytheOfficeoftheFireMarshalofOntario).Ourresearchproposalhadanticipatedasufficientlyadequatelevel ofdetail anddata availability in theNFID toallow for ameaningful andproductiveM&Sofincidentoccurrenceandfiredepartmentresponse.

Incident Dataset: Current Case Study 

Inthissection,wedescribethedatasetmadeavailablebyVFRS(‘VFRSdataset’or‘VFRSdata’)forpurposesofourcasestudyandM&Seffort.Consistentwith thenon‐disclosureagreement,chartsandtablespresentdataprovidedwiththeconsentofVFRSrepresentatives.

The VFRS data cover eight years of consecutive incident records from January 2009 throughDecember2016.Inordertoaddressfilesizeissues,theVFRSdatasetwasbrokendownandmadeavailabletotheresearchteaminseveralMSExcelworksheets:

a. IncidentMainFeatures,

b. IncidentRespondingUnits,

c. IncidentCivilianCasualties,

d. IncidentFirefighterCasualties,and

e. IncidentOtherTables.

ItispossibletoextractfromtheVFRSdataasetofkeyfeaturesrelatedwithincidentsandresponsecharacteristics.Some fieldscoincidewith thosereported in theNFIDon the incident informationfields, such as INCIDENT ID, ALARM TIME, RESPONSE TIME and INCIDENT LOCATION. SomerelevantfieldsinadditiontothoseinNFIDare:TYPEOFINCIDENTandONSCENETIME.

We initially undertook an assessment of data availability and quality. We sought to eliminatewronglycodedvaluesandoutliers.Oftheabovementionedkeydatafields,theworstcase,forONSCENETIME,provided88%ofutilizabledata(availablerecordsafterthecleaningupprocess).

In Figure 9, we present the percentage distribution of the incident records on an annual basisthroughout2009to2016.Monthlypercentagedistributionthroughout2009to2016ispresentedinFigure10.

 

13  

FIGURE9.VFRSYEARLYINCIDENTS:NUMBERANDPERCENTAGETOEIGHT‐YEARTOTAL(2009‐2016)

FIGURE10.VFRSMONTHLYINCIDENTS:NUMBERANDPERCENTAGETOEIGHT‐YEARTOTAL(2009‐2016)

Byobserving themonthlynumbersof incidentsover2009 to2016 inFigure11, it ispossible todetectaslightupward(growth)trend.

 

14  

FIGURE11.VFRSDATA:TOTALNUMBEROFINCIDENTSPERMONTH(2009TO2016)

InFigure12,weperceiveanoverallupwardtrendinthemonthlynumberofvehiclerescues,withpotentialseasonalcomponents(forinstance,highsorlowsduringcertainmonths).Forfireincidentcalls, the plots in Figure 13 depicts a slight downward (decreasing) trend over the time. ThisdownwardtrendinfireincidentsmaybeindicativeofsuccessfulfirepreventioneffortsbyVFRS.

FIGURE12.VFRSDATA:TOTALVEHICLERESCUESPERMONTH(2009TO2016)

 

15  

FIGURE13.VFRSDATA:TOTALFIREINCIDENTSPERMONTH(2009TO2016)

Fromouranalysisof time intervals (inminutes)betweenconsecutivevaluesofALARMTIME (or“inter‐arrivaltimes”),weobtaintheinter‐arrivaltimedistributionforemergencycallsinFigure14,the frequency histogram for the overall incident list represents the expected inter‐arrivaldistribution,whichsuggestsanegativeexponentialfunctionandwhichisconsistentwithaPoissondistributionof“arrivals”ofemergencycalls.(ThePoissondistributioncommonlycharacterizesthearrivalofcustomersinaservicequeuingsystem.)

FIGURE14.VFRSDATA:DISTRIBUTIONOFTIMEBETWEENSUCCESSIVECALLS,INMINUTES

 

16  

Figure15showsthedistributionofRESPONSETIMEintheVFRSdataset.Basedonusualexperienceinservicesystems,a‘moundshaped’–ornormal–distributionisgenerallyexpected,whichimpliesthattheprocessismatureandwellimplemented(i.e.,theprocessandorganisationhavepassedthelearningcurveeffect).

FIGURE15.VFRSDATA:RESPONSETIMEDISTRIBUTION(ALLINCIDENTTYPES)

However,weapplyinoursimulationstudiestheactualempiricaldistributionsofRESPONSETIMEaccording to various incident types.We analysed theRESPONSETIME observed for each type ofincident,obtainingdifferentvaluesofmeansandvariabilitystatistics.

Asimilaranalysis isrequiredforONSCENETIME.Figure16showstheoveralldistributionofONSCENETIME,althoughwefoundparticulardistributions(differentshapesandparameters)acrossvariousincidenttypes.

 

17  

FIGURE16.VFRSDATA:ONSCENETIMEDISTRIBUTION(ALLINCIDENTTYPES)

Besidesthedistributionsofinter‐arrivaltimes,responsetimes,andonscenetimes,anotherhighlyrelevant component forM&S of emergency calls is their spatial distribution. The Longitude andLatitude coordinates recorded for each reported incident allow us to capture spatial patternsbehindvariousincidenttypes.WecreatedapartitionoftheentiregeographicalregioncoveredbyVFRS,usingalatticegranularityof500meters×500meters(0.25km2).‘Heatmaps’,asdepictedinFigure17,showthespatialanalysisfor:

a) Allincidenttypesin2009;

b) Allincidenttypesin2009‐2016;and

c) Vehiclecollisionincidentsin2009‐2016.

Thevaluesappearingineachcellarethenumbersofaccumulatedincidentswhichhaveoccurredinthat area over the period specified. Each incident type produces a different spatial distributionpattern(i.e., ‘hotspots’locatedinspecificareasdependingontheincidenttype),whichisrelevantforourM&Sframework.

 

18  

FIGURE17.VFRSDATA:SPATIALDISTRIBUTIONANALYSISFORSPECIFICINCIDENTTYPES(2009‐2016)

Inadditiontothespatialdistributionpatternsresultingfromthelongitudeandlatitudeinformationforeachincident,itispossibletoestimatetheexpectedtraveldistancefromtherespondingstationtotheincident.

We are also able to obtain, for each reported incident, an Alarm Processing Plus TurnOut Time(APPTOT), which is calculated as Roll‐out Time stamp (when the vehicle rolls out of its homestation)minusAlarmReceiptTimestamp(whenthealarmisreceivedattheVFRScommunicationscentre). Thedistribution ofAPPTOT is presented in Figure 18.Wemust point out that theVFRSdatasetonly includesasdata fieldstheAlarmReceiptTimestamp(alm_time intheIncidentMain

 

19  

Features file, or notif_time in the Incident Responding Units file) and the Roll‐out Time stamp(roll_time in the Incident Responding Units file). We use the Roll‐out Time stamp of the firstrespondingunitatthesceneincalculatingtheAPPTOT.Sincetheoriginatingstationisnotclearlyidentifiedbywayofaseparatedatafield,weassumethatthefirstrespondingunitoriginatesfromthestationresponsible for thegivenEmergencyPoint.AlarmProcessingTimeandTurnoutTimearenotseparatelyrecorded.

FIGURE18.VFRSDATA:APPTOTDISTRIBUTION(ALLINCIDENTTYPES)

OurM&Sframeworkinvolvedtwodifferentsimulationmodelsrunningonseparateplatforms:

1. AnIncidentGenerationEngine,developedandimplementedusingCPNTools4.0[5],whichsimulatesthe‘arrival’ofincidents.Eachincidentoccurrenceischaracterizedby:

a. typeofincident,

b. location,

c. ‘arrival’ time (based on the time stamp of Alarm Receipt at the VFRScommunicationscentre),

d. APPTOT,and

e. onscenetime.

2. AResponseSimulationModel,developedandimplementedusingAnyLogic8.0.5[1].

 

20  

Thesetwoseparatesimulationmodelsarefullydescribedinthetwoimmediatelysucceedingtwosectionsofthisreport.

Incident Generation Engine 

In this section, we describe the first of two simulation models. This Incident Generation Engineproduces a list of incidents (including the main features: type, location, ‘arrival’ time), which isgeneratedbasedontheempiricaldistributionsobtainedforthekeyincidentfeatures.ThisincidentlistprovidestheinputsfortheResponseSimulationModel.

AconceptualoverviewoftheintegrationoftheinformationproducedfromtheanalysisoftheVFRSdatasetispresentedinFigure19.

FIGURE19.INTEGRATIONOFEMPIRICALDATAFORSIMULATIONOFTHEINCIDENTLIST

Thesimulationof incidentoccurrenceshasbeendevelopedand implementedasadiscreteeventsimulation model with CPNTools 4.0 [5] as the platform. The model takes simultaneouslyinformationfromtheempiricaldistributions,consideringcentraltendencyandvariabilitystatistics,ofvariousdatafieldswithinthedatasettogenerate:

1. type of incident, considering the probabilities of occurrence of specific types of incidentsover time (at the level of frequencies on an hourly basis during the day), and at fourdifferenttimewindows(TWs)duringtheday(i.e.0:01‐5:59h,6:00‐11:59h,12:00‐17:59hand18:00‐23:29h.),

2. incidentlocation,basedonthe500m×500mcellsinthelatticeaspreviouslydescribed,

3. incident ‘arrival’ time,basedon thedistributionof inter‐arrival timesbetweensuccessivealarms,

 

21  

4. APPTOTforthefirstrespondingcrewdependinguponthetypeofincident,and

5. onscenetimeforthefirstrespondingcrew,dependinguponthetypeofincident.

The generation of incidents for one day has been implemented using colored Petri nets withCPNTools 4.0 [5] as platform. An overview of the main components of the model (places,transitions,andarcs)ispresentedinFigure20.

FIGURE20.INCIDENTGENERATIONENGINE:MAINCOMPONENTS

Theempiricaldistributionsobtained fromtheVFRSdatasetare themain inputsprovided for thesimulationthatproducestheincidentlistforanentireday.Descriptionsofcomponents(networknodes)aresummarizedinTable2.

Theoutputlistincludesthefollowingfeatures/attributesforeachincident:

ID:incidentID

TP:incidenttype

ST:spatiallocation(cellinthelattice)

t1:inter‐arrivaltime

PT:APPTOT

OT:onscenetime

 

22  

TABLE2.DESCRIPTIONSOFINCIDENTGENERATIONENGINECOMPONENTS(PLACESANDTRANSITIONS)

Name Nodetype Description

Incidentmain TransitionTakesonevaluefromeachoftheplaces(nodes)connectedtosimulatethemainfeaturesforanincident(interarrivaltime,type,location).

APPTOT TransitionTakesonevaluefromthedistributiondependingontheincidenttype.

Onscenetime TransitionTakesonevaluefromthedistributiondependingoftheincidenttype.

Day PlaceContainstheinformationoftheday(Monday,Tuesday,etc.),Month(Jan,Feb,etc.)forthegenerationoftheincidentlist.

Inter‐arrivaltime PlaceContainstheinter‐arrivaltime,obtainedfromthedistributionoftimebetweensuccessivecalls.

Typedailydistribution PlaceContainstheincidentoccurrencedistributionperdayforeachincidenttype.

Typemonthlydistribution PlaceContainstheincidentoccurrencedistributionpermonthforeachincidenttype.

Typehourlydistribution PlaceContainstheincidentoccurrencedistributionperhourforeachincidenttype.

Typeoveralldistribution PlaceContainstheincidentoccurrencedistributionforeachincidenttype.

Typelocationdistribution PlaceContainstheincidentoccurrencedistributionperlocation(cellsof0.5km×0.5km)foreachincidenttype.

Timewindows PlaceContainstheincidentoccurrencedistributionwithinthespecifiedTWsforeachincidenttype.

Incidentcall PlaceContainstheincidentsgeneratedalongwiththemainfeatures(interarrivaltime,type,location)

APPTOTdistribution PlaceContainstheestimatedAPPTOT,obtainedfromthedistributionfortheoverallincidenttypes.

Incidentresponse PlaceContainstheincidentsgeneratedalongwiththemainfeaturesplusthepreparationtime.

Onscenetimedistribution PlaceContainstheincidentonscenetimedistributionforeachincidenttype.

Incidentcleared PlaceFinalnodewithallthefeaturessimulated:interarrivaltime,type,location,APPTOT,onscenetime.

 

23  

Response Simulation Model 

TheincidentlistcreatedusingtheIncidentGenerationEngineservesasinputintothesecondmodel–theResponseSimulationModel.InordertorecreatetheenvironmentinwhichVFRSrespondstoemergencies of various types occurring throughout the day, we developed and implemented anagent‐basedsimulationmodelusingtheAnyLogic8.0.5simulationplatform[1].

While the IncidentGenerationEngine isbasedondiscreteeventmodelling,weusedAgent‐BasedModelling (ABM) to develop our Response Simulation Model. ABM is best described as adecentralized, individual‐centric approach tomodelling. In this approach, individual participantshavetheirownbehaviorandarereferredtoasagents.

WithintheAnyLogicsimulationplatform,weareabletotransformreportedlongitudeandlatitudeinformationonincidents(aswellasfirestations)intousableGeographicInformationSystem(GIS)coordinateswhichallowsimulationofvehiculartraveloncitystreets.

MODELDESCRIPTION

Theagentsthatcomeintoplayinthemodelare:

Dispatcher–thepersonwhoreceivesthe911callfromtheEmergencyPointanddecidestoalerttheappropriateStationtoattendtotheincident;

EmergencyPoint–anentitythatdevelopsandchangesitsstatusbasedontheactionsoftheotheragents;

Station– theagent thatreceives theexecutionorder fromtheDispatcherandchanges itsstatusaccordingtoavailabilityofresources;and

Vehicle – the entity that receives thedispatchingorder from the available Station. It alsousestheGISMapinordertotaketheappropriateroute.(BasedonVFRSpractice,acrewoffourfirefightersmanseachrespondingvehicle.)

FIGURE21.AGENTSUSEDINTHEMODEL

 

 

24  

As faras thesimulationmodelanimationview is concerned,a scaledrepresentationof thecity’sFireDistricts and stations involved helps the user to directly visualizewhat is happening in theenvironmentintermsofentitiesandtheflowofresources(seeFigure22).

 

 

FIGURE22.SUBDIVISIONOFTHECITYOFVAUGHANINTOFIREDISTRICTSANDCURRENTFIRESTATIONLOCATIONS

TheGISMapshapeenablesonetodisplayandmanageGIS(GeographicInformationSystem)mapsinthemodel.TheGISRegionelementtomarkupsomeclosedareaonthemapwasused,anditispossibletoaddanewregionormodifytheregionshape.Eachpointoftheregionhaslatitudeandlongitudecoordinates,definedindegrees.Itisalsopossibletouseashapefile(.shp)asaninputtobuildtheregioninsidetheCityDistrict.Thedefinitionofregionsisveryimportantbecausethelogicinside themodel is structuredondifferentdecision levels basedon theseboundaries. The agentthat is charged to take these decisions is theDispatcher that receives the latitude and longitudeinformationfromtheincident.Usingthesevaluesitispossibletodeterminewhichregion(district)andstationtakesprincipalresponsibilityfortheincident.

IntheinitialResponseSimulationModeldevelopmentandtesting,ourmodelwasrestrictedtooneresponding vehicle per incident. According to currentVFRSprotocol, different types of incidentscall for 1, 2, or 4 responding vehicles. In applying current protocol, we obtained the followingdistributionofnumberofrespondingunitsrequired:

 

25  

Thus,only5.3%ofincidentswouldbeexpectedtorequirefourrespondingvehicles.Wealsolookedinto the actual numbers of responding units, as reported in the Incident Responding Units file(January2009–December2016)andderivedthefollowingdistribution:

Basedonactualnumbersofunitsrespondingtoemergencyincidentsin2009‐2016,89.7%involvedoneortworespondingvehicleswhileonly10.3%involvedmorethantwovehicles.

Thus,whether based on current protocol or on experience,we see a relatively small percentage(5.3%and10.3%,respectively)of incidentsrequiringmorethantworespondingunits.Our teamdecided that a Response Simulation Model involving either one or two responding units wouldenable a relatively simple working model, but one which still is roughly indicative of resourcerequirements.Accordingly,allincidenttypecodesrequiringeithertwoorfourrespondingvehiclesperVFRSprotocolare–inourResponseSimulationModel,ascurrentlydeveloped–assignedtworespondingunits.

Currently,themodelusesthefollowinglogictosendresourceswheretheyareneeded:

1. Considerthestationsthatareinthesameregionastheincident.

2. ChoosetheNearestStationinRegionbyRoute.

3. Checktheavailabilityofresources.

4. ChecktheresourcesneededbytheEmergencyPoint.

5. If the available Station resources are exactly the number of needed resources ofEmergencypoint,sendallvehiclesrequired.

6. If not, send the vehicles available in the Station and update the resources neededdecreasingthevalue.

Number of Trucks per Protocol %‐age

1 60.5%

2 34.1%

4 5.3%

100.0%

Vehicles responding # incidents % occurrence

1 57,494 69.4%

2 16,819 20.3%

3 2,864 3.5%

4 1,712 2.1%

More than 4 3,909 4.7%

82,798 100.0%

 

26  

7. If resources needed to Emergency Point is greater than zero, check other Stations inRegionand:

7.1 If the available Station resources are exactly the number of needed resources ofEmergencypoint,sendallvehiclesrequired.

7.2 If not, send the vehicles available in the Station and update the resources neededdecreasingthevalue.

8. IfresourcesneededbyEmergencyPointisgreaterthanzero,choosetheNearestStationbyRouteamongallothersintheentirecitywithavailableresourcesand:

8.1 IftheavailableStationresourcesareexactlythenumberofneededresourcesofEmergencyPoint,sendallvehiclesrequired.

8.2 Ifnot,sendthevehiclesavailableintheStationandupdatetheresourcesneededdecreasingthevalue.

Itisalsopossibletochangethisdecision‐makingschemeinconnectionandconsistentwithcurrentoperatingprocedures/protocols as used in a given city. In order to better understand thewholelogicthatisinthemodel,apseudo‐algorithmhasbeenwrittenbelowthatcanrepresentthemainactionsandthedecisionprocessstepbystep.

inputfile:EmergencyPoints(IdentificationCode,Latitude,Longitude,Timestamp,APPTOT,Onscenetime,EmergencyCode,numberofvehiclesneeded)readFileperrowcalculateinwhichRegiontheEmergencyPointisinputfile:Stations(StationID,Latitude,Longitude,Regionofbelonging,NumberofVehicles)readFileperrowSetStationinGISMap;for(eachEmergencyPoints.file.row){if(themodeltimeisequaltoincidenttime)EmergencyPoint.statuschangestoActive;EmergencyPointsendthemessage:alarm;Dispatcherreceivesmessage;Dispatcherreceivesinformation:EmergencyPointparameters;SelectStationsinRegion;ChoosetheNearestStationinRegionbyStreetDistance;if(ResourcesAvailable&&resourcesneeded>0)Dispatchersendthemessage:operation;Stationreceivesmessage;Station.StatuschangestoOperation;Stationsendthemessage:go;Vehiclereceivesthemessage;Vehicle.statuschangestoPreparation;Station_selected.numberVehicles‐‐;resourcesneeded‐‐;Vehiclegoesto(EmergencyPoint.Latitude,EmergencyPoint.Longitude)else(ArethereotherStationsinRegion?)if(ResourcesAvailable&&resourcesneeded>0)Dispatchersendthemessage:operation;Stationreceivesmessage;Station.StatuschangestoOperation;

 

27  

Stationsendthemessage:go;Vehiclereceivesthemessage;Vehicle.statuschangestoPreparation;Station_selected.numberVehicles‐‐;resourcesneeded‐‐;Vehiclegoesto(EmergencyPoint.Latitude,EmergencyPoint.Longitude)elseif(resourcesneeded>0)(identifyavailableStations.outsideRegion)ChoosetheNearestStationbyStreetDistance;Dispatchersendthemessage:operation;Stationreceivesmessage;Station.StatuschangestoOperation;Stationsendthemessage:go;Vehiclereceivesthemessage;Vehicle.statuschangestoPreparation;Station_selected.numberVehicles‐‐;resourcesneeded‐‐;Vehiclegoesto(EmergencyPoint.Latitude,EmergencyPoint.Longitude)activatefunctionCheck.Station.Availability;if(numberVehicles==0)Available=false;Station.StatuschangestoUnavailable;Vehicle.statuschangestoOnRoute;Agent.Vehiclearrival‐>sendthemessage:OnSite;EmergencyPointreceivesthemessage;EmergencyPoint.statuschangestoRescue;Time=OnSceneTime;EmergencyPoint.statuschangestoCleared;Vehicle.statuschangestoReturning;Vehiclegoesto(Station.Latitude,Station.Longitude)Agent.Vehiclearrival‐>Station_selected.numberVehicles++;activatefunctionCheck.Station.Availability;

}

With an agent‐basedmodel,wepopulate the environmentwith the various entities that interactwith each other. As mentioned previously, the agents used are the incidents, the vehicles, thedispatcher,andthestations.Thestationsareplacedinthemapbyuploadinga file;hence, inthismodel,anyactualnumberofstationsmaybespecified.Eachstation’sparameterswill includethefollowinginformation:

StationID;

Latitude;

Longitude;

Regiontowhichthestationbelongs;and

Numberofvehicles.

Regarding the number of vehicles per station, it is possible to set it at the beginning of thesimulationthroughappropriateslidersorbyenteringthenumberdirectlyinabox(seeFigure23).

 

28  

 

FIGURE23.MODELHOMEPAGEANDSETTINGNUMBERSOFAVAILABLEVEHICLES 

The operational capability of the stations depends on the availability of resources. The greensymbolontopofastationmeansthattheagent(station)isabletorespondtoanincident.Whenallthevehiclesbelonging to thatstationhavebeendispatchedor theyarealready inpreparation toattendtoanincident,thestationisunavailableintermofresources.Forthepurposeofshowingthestationunavailability, theblacksymbolon topof thestationwasdesigned,and itmeans that theagent isnotabletorespondtoany incident.Figure24showsthesymboldescribedpreviously inconnectionwithstationstatus.During thisstateofunavailabilityof thestation, it is important todefinethelogicofimplementationofthemodelandcollecttheoutputdataappropriately.

 

FIGURE24.STATIONSTATUSANDRELATEDSYMBOLS

For each station a certain number of vehicles is assigned. Each vehicle is an agentwith its owncharacteristicsandbehaviors.Tobetterunderstandhowthesetypesofagentsbehaveinthemodel,thestatusofeachvehiclehasbeensummarizedinthefollowinglist:

 

29  

Waitingisthestatusinwhichthevehiclewaitsatitsstation.Thisstatemeansthatthevehicleisavailableforassignmenttoanincident.

PreparationstatusstartsassoonasthealarmisreceivedbytheVFRScommunicationscentreand lastsuntil thevehiclerollsoutof thestation.SinceAlarmProcessingTimeandTurnoutTimearenotseparatelyrecorded,themodeltreatsavehicleasbeinginthe‘Preparation’statusthroughouttheperiodoftimereferredtoasAPPTOT,asprovidedbytheIncidentGenerationEngine.(AstationandavehicleareassignedtoanincidentbaseduponthethelongitudeandlatitudeinformationoftheEmergencyPoint.)

ThestatusOnRoutereflectsthevehicletravelingtowardstheEmergencyPoint. TheOnScenestatusreflectsthevehiclebeingattheEmergencyPointandattendingto

theincident. Returningisthestatusaftertheemergencyhasbeencleared,withthevehicletraveling

backtoitshomeStation.

Thevehiclesreachthe incident locationusingtheexistingroadsandroutesbasedonrealspatialdata.Furthermore, thankstoGISMapfeatures, thesimulatorchooses the fastestway toarriveattheincident.Asalreadymentionedabove,anotherextremelyrelevantentitywithinthemodelistheEmergencyPoint,withthefollowingcharacteristicsasspecifiedbytheIncidentGenerationEngine:

Incidentidentificationcode; Latitude; Longitude; AlarmReceipt Time stamp (when the alarm is received at the VFRS communications

centre); APPTOT; Onscenetime;and Incidenttypecode.

The Emergency Point information is entered into the model as an input file, where each rowrepresents an incident. The incident type codeautomaticallydetermines thenumberof requiredvehiclestobeassignedtorespondtoagivenincident.SincethesimulatorallowstheuploadoftheinputfilecomingfromtheIncidentGenerationEngine,therearenorestrictionsonthenumberofemergenciesthatcanbesimulatedinarun.

TheEmergencyPointagentiscloselyrelatedtotheotheragents’statusdiagram,becauseitsendsandreceivesinformationto/fromalltheotheragentsinthemodel.Thedifferentstatesrelatedtoanemergencypointarelistedbelow:

Inactive:Thestateinwhichtheincidenthasnothappenedyet; Active: The state inwhich the Emergency Point sent an alarm and it iswaiting for a

response; Rescue:StateinwhicharesponderhasarrivedattheEmergencyPoint; Cleared:ThestateinwhichtheEmergencyPointhasbeencleared.

Byusingstatechartsonecanvisuallycaptureawidevarietyofdiscretebehaviors.,Forthisreason,statecharts were used to better represent the various agent states in the model (as described

 

30  

above).Figure25 includes theagentsstatecharts thatweredeveloped in themodel toreflect therealenvironmentprocess:

FIGURE25.AGENTS’STATECHARTS

Thesimulationmodel,asdeveloped,providesasetofindicatorsofoperationalperformance.Suchindicatorsaresimplyvariousperformancemeasuresrelatedtothedifferentrescuesoperations.Tofulfilltheirpurpose,suchindicatorsaresimpletounderstand.Oncethesimulationiscompleted,abuttonbecomesavailableinthewindow,toallowtheusertocollectthesimulationresultsavailableintermsofoutputfiles.

 

31  

Theoutputfilescontainthefollowingperformanceindicators:

Timeperiodbetweenalarmreceiptandtheendoftherescueprocedures,

Traveltimeofeachvehicleusedandthetotaltimeamountofallvehiclesperday,

Traveldistancesofeachvehiclesintermsofmetersandthetotalamountofallvehicles

perday,

Accumulatednumberoftheincidentsoverthetime,

NumberofvehiclesremainingperStation,

Vehicles sent by other Stations for each Emergency point,when the Station thatwas

supposedtorescuehasn’tallvehiclesneededavailable.

Thesimulationmodelhomepageallowstheusertochoosebetweentwooptions:

1. immediately launch the simulation runwithout worrying aboutmodel customizationandagreeingwiththedefaultconditionsandsettings;or

2. modify pre‐implemented default settings and customize themodel input parameters,enablingthemodeltotestdifferentconfigurations.

Thehomepagecontainsdifferentnumberofboxwheretheusercansetupthemodelparametersrelatedtoagentinthesimulatedenvironment,asshownpreviously(Figure23).Eachrunincludesthesimulationofadayofactivityof the firedepartment,duringwhichvariousemergenciesmayoccuraccordingtothestatisticaloutputsdefinedintheprevioussection.Figure26showsaviewofthe performancemeasures listed above that the simulationmodel is able to provide during thesimulationandalsocollectinadataset.

FIGURE26.PERFORMANCEINDICATORSVISUALIZEDDURINGSIMULATION

 

32  

SIMULATIONRESULTS(FUNCTIONALITYVALIDATIONOFTHEMODEL)

EachreplicationofoursimulationexperimentsimulatesonedayofVFRSresponsestoemergencyincidents.Wehavethuscompletedandcollectedstatisticsfrom180replications(correspondingtoasix‐monthperiodfromJanuarytoJune)oftheexperiment. Ineffect,180daysof incidentsweregeneratedusingtheIncidentGenerationEngine,andtheresultingincidentlistwasusedasinputfortheResponseSimulationModel.

Wepresentthedistributionsofresponsetimesonamonthlybasisaftereliminatingoutliers(nearly5% percent of the simulated values). All the presented values were obtained by simulating theresponse times with empirical distributions derived from the Incident Generation Engine incombination with the Response Simulation Model. Figures 27‐33 present the response timedistributionsobtainedforeachmonthfromJanuarytoJune.

FIGURE27.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,JANUARY

 

33  

FIGURE28.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,FEBRUARY 

 

 

FIGURE29.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,MARCH 

 

34  

 

FIGURE30.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,APRIL 

 

FIGURE31.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,MAY 

 

 

35  

 

FIGURE32.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,JUNE 

 

 

FIGURE33.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,JANUARY–JUNE

ByinspectionofFigures27–33,thedistributionsobtainedshowjustslightlydifferentshapesfromonemonth to the next. Our simulation experiment yielded an average travel speed of 41 km/hrbasedon the travel time(ArrivalTimestampminusRolloutTimestamp)and thestreetdistancefromtherespondingstationtotheincidentlocation.

 

36  

As part of model validation, we summarize in Table 3 the distribution of simulated values ofresponsetimes,andcomparethestatisticswiththoseofactualvaluesoverallin2009‐2016:

TABLE3.STATISTICALCOMPARISONOFSIMULATEDVS.ACTUALRESPONSETIMEDISTRIBUTIONS

Onaverage,oursimulationyieldslongerresponsetimes(thedifferencebetweenoverallmeansisslightlyover37seconds),andexhibitinggreatervariability.Thismayindicatetheneedforamoresophisticatedmodelforrespondingvehicles’speedsforincidentslocatedinthemore‘rural’areas(withlongertraveldistancesandpossiblyhigheraveragespeedascomparedwiththemoreurbanareas).

Besidestheanalysisoftheresponsetime,themodelallowsthegenerationandcollectionofotherrelevantoperationalindicators(e.g.traveldistance/time,workloaddistribution,etc.).InFigure34,forinstance,wepresenttheaveragetotaltraveldistanceforfirstrespondingunits.ThesimulateddistributionofincidentsamongthedifferentregionswithinthecityofVaughanisshowninFigure35. In Figure 36, we see the breakdown of responding vehicle/crew overall time into APPTOT,Travel,andOnscenetimes.

MonthMean

(minutes)StdDev(minutes)

Max(minutes)

Min(minutes)

n

January 6.31 3.17 16.8 1.2 873February 6.42 3.26 16.8 1.5 796March 6.29 3.19 16.9 1.6 891April 6.39 3.2 16.9 1.3 884May 6.44 3.17 16.9 1.4 885June 6.29 3.03 16.9 1.3 904

Overall(180replications) 6.36 3.17 17 1.2 5,233Overall(actualvalues) 5.74 2.32 17 1 80,310

 

37  

FIGURE34.AVERAGETRAVELDISTANCEPERINCIDENT(INMETERS)FORFIRSTRESPONDERVEHICLES(180REPLICATIONS)

FIGURE35.SIMULATEDNUMBEROFINCIDENTS,BYREGION(180REPLICATIONS) 

 

38  

 

FIGURE36.RESPONDINGVEHICLE/CREWOVERALLTIMEBREAKDOWN,BYREGION(180REPLICATIONS) 

Conclusions and Further Research  

The current Incident Generation Engine involves stochastic modelling and simulation of theoccurrenceofincidents(asspecifiedintermsofincidenttype,‘arrival’time,location,APPTOT,andon scene time). In spite of the inherent variability/uncertainty in observed values, our incidentgenerationmodelappearstoprovidesimulatedresponsetimesthatmoreorlessfollowtheactualpatterns arising in the historical data.However, themodel still needs to be calibrated to furthervalidateresultingdistributionsofincidentattributesinrelationtoactualdistributions.

Thesimulationproducedbymeansof thetwomodels(IncidentGenerationEngineandResponseSimulation Model) as developed is capable of reproducing the performance of the system.Deviationsobservedfortheexperiment(180replicationseachhavingadurationofoneday)comemainly from thenecessity of calibrating themodel (for instance, fine tuningof someparameterssuchasaveragevehiclespeed).

The Response SimulationModel is intended to provide a flexible tool for planners and decisionmakerstoevaluatevariousoperatingscenariosoralternativeprocedures/protocols–e.g.,differentnumbers, types or allocation of resources, expected demand fluctuations, alternative assignmentrules,amongothers.

 

 

39  

EXTENSIONANDIMPROVEMENTOFTHEDEVELOPEDMODELS

We are currently concluding an extended experiment consisting of 365 replications (or theequivalent of one year of emergency incidents and response operations) and will subsequentlyreportonresults.

Basedontheinitialresultsobtained,furtherworkmayincludeextendingthesimulationmodelstoenable:

DefinitionintheResponseSimulationModelofdifferenttypesofrespondingvehicles,andestablishing protocols for assignment of different types/numbers of responding unitsdependinguponthetypeofincident.

Developing more extensive experiments to evaluate different scenarios – e.g., impact ofresource demand fluctuations on response times/capacity, comparison betweenassignmentofrespondingunitsaccordingtoresponsibledistrict/regionvs.geographicallycloseststation(s).

Acknowledgment 

ThisworkwassupportedbyagrantfromtheCanadianAssociationofFireChiefs(CAFC).

The research teamwishes to acknowledgepartial financial support fromProfessor JianhongWu,UniversityDistinguishedResearchProfessorandCanadaResearchChairinIndustrialandAppliedMathematics,ofYorkUniversity.

We are deeply indebted to Chief Larry Bentley, Deputy Chief Deryn Rizzi, Deputy Chief AndrewZvanitajs,andCaptainKevinPlestedoftheVaughanFireandRescueService,notonly formakingavailable their incidentdatasetover theeight‐yearperiod fromJanuary2009toDecember2016,butmostespeciallyforprovidingtheirassistance,guidance,andinsightsinourstatisticalanalysisof the VFRS dataset and the necessary verification/validation/accreditation of our simulationmodels.

 References 

1. AnyLogicSimulationSoftware,2017.[Downloadableathttp://www.anylogic.com].

2. CalgaryFireDepartmentAnnualReport2011.

3. CalgaryFireDepartmentAnnualReport2016.

 

40  

4. CanadianCentrefor JusticeStatistics,2017.FireStatistics inCanada,SelectedObservationsfrom the National Fire Information Database 2005 to 2014. Report prepared for theCanadianAssociationofFireChiefs,September2017.

5. CPNTools,2017.[Downloadableathttp://cpntools.org/].

6. FraserInstituteResearchBulletin.MunicipalFireServicesinCanada:APreliminaryAnalysis,May2015.

[Available online at https://www.fraserinstitute.org/sites/default/files/municipal‐fire‐services‐in‐canada.pdf(accessedonDec22,2017).]

7. OttawaFireServices2011AnnualReport.

8. OttawaFireServices2016AnnualReport.

9. TorontoFireServices2011AnnualReport.

10. TorontoFireServices2016AnnualReport.

11. VaughanFire&RescueService2011AnnualReport.

12. VaughanFire&RescueService2016AnnualReport.

 Author Biographical Information 

The research project team is composed of researchers who are affiliated with the School ofAdministrative Studies and the Advanced Disaster, Emergency and Rapid Response Simulation(ADERSIM) programat YorkUniversity. TheDisaster andEmergencyManagement graduate andundergraduateprogramsofYorkUniversityarehousedintheSchoolofAdministrativeStudies.

Dr.AdrianoO.SolisisanAssociateProfessorofLogisticsManagementandDecisionSciencesandcurrently theDirectorof theSchoolofAdministrativeStudiesatYorkUniversity.He teachesandconducts research in the areas of operations/logistics/supply chain management and decisionsciences.HeisamemberofthegraduatefacultyinDisasterandEmergencyManagement,andisanactive collaborator in the ADERSIM program. His research interests are in inventory systemsmodeling, supply chain management, intermittent/lumpy demand forecasting, applied modelingand simulation, and IT in operations and supply chainmanagement. He has served as ProgramChair of the Summer Computer Simulation Conference of the Society forModeling & SimulationInternational (SCSC 2013, Toronto, Canada) and as General or Program Co‐Chair of theInternationalConferenceonModelingandAppliedSimulation(MAS2014,Bordeaux,France;MAS2015,Bergeggi, Italy;MAS2016, Larnaca, Cyprus;MAS2017,Barcelona, Spain).Hewill serve asGeneralCo‐ChairofMAS2018inBudapest,Hungary(September2018).ProfessorSolisholdsBScandMScdegreesinmathematics,anMBA,andaPhDinManagementScience.BeforejoiningYorkUniversity, he was Associate Professor of Operations and Supply Chain Management at theUniversityofTexasatElPaso.HehasbeenaVisitingProfessorattheUniversityofCalabria(Italy),wherehehascontinuedtosupervisemanagementengineeringgraduatestudentsintheirresearch

 

41  

work.His teaching isenhancedby industryexperience, includinghavingbeenVicePresidentandDivision Manager for Professional Products and Systems in the Philippine operations of PhilipsElectronics,theNetherlands‐basedmultinationalcompany.

Dr. Ali Asgary is an Associate Professor of Disaster and Emergency Management in YorkUniversity’sSchoolofAdministrativeStudies.HeisaPrincipalInvestigatorandProgramLeadforYork University’s ADERSIM program. He is an expert in disaster, emergency, and businesscontinuitymanagement.Hisextensiveresearchandeffective teachingareenhancedbyhisactivecontributionstotheprofessionandbytranslatingthemintorealworldpracticesatdifferentlevels.HisresearchhasbeenfundedbySSHRC,NSERC,GEOIDE,PreCarN,AIF,YUFA,andothers.Heistheauthor or co‐author of numerous scholarly and practitioner articles in disaster and emergencymanagement, and his work has been extensively cited and referenced by other researchers.ProfessorAsgaryhas receivedvariousawards forhis research, teachingandother contributions,including the International Association of Emergency Management Award and the outstandingpaperof theyearawardby the JournalofDisasterPreventionandManagement.HeobtainedhisPhD at University ofNewcastle UponTyne in England.Hewas one of the facultymemberswhoestablishedthedisasterandemergencymanagementdisciplineinCanadianuniversities,includingYorkUniversityandBrandonUniversity.

Dr.JenaroNosedalisaPost‐DoctoralVisitoratYorkUniversity’sSchoolofAdministrativeStudiesanditsDisasterandEmergencyManagementprogram,andanADERSIMcollaborator.Heiscoursedirector in Operations Management and Quantitative Methods in Business at the School ofAdministrative Studies. He holds bachelor’s andmaster’s degrees in Industrial Engineering, andreceived his PhD in Telecommunications and Systems Engineering from the AutonomousUniversityofBarcelonain2016.Dr.Nosedal’sgeneralareaofresearchisinoperationsandlogisticsmanagement,specializinginsystemsmodelingandsimulation.

Ms.BeatriceZaccaro holds a Laurea in IngegneriaMeccanica (bachelor’s degree inMechanicalEngineering)andiscurrentlyastudentintheLaureaMagistraleinIngegneriaMeccanica(master’sdegreeinMechanicalEngineering)programattheUniversityofCalabriainItaly.InFall2017,shewas an International Visiting Research Trainee (IVRT) in the graduate program in Disaster andEmergency Management at York University. Her research interests include modeling andsimulationwithapplicationsinlogisticsandinsafetyandsecurityinindustrialplants.

List of Tables and Figures 

TABLES

TABLE1.FIREINCIDENTSREPORTEDINNFIDIN2011COMPAREDWITHTOTALINCIDENTSRESPONDEDTOBYFOURCITYFIREDEPARTMENTS 11

TABLE2.DESCRIPTIONSOFINCIDENTGENERATIONENGINECOMPONENTS(PLACESANDTRANSITIONS)22

TABLE3.STATISTICALCOMPARISONOFSIMULATEDVS.ACTUALRESPONSETIMEDISTRIBUTIONS 36

 

42  

FIGURES

FIGURE1.CALGARYFIREDEPARTMENT:BREAKDOWNOFEMERGENCYINCIDENTS,2011 7

FIGURE2.CALGARYFIREDEPARTMENT:BREAKDOWNOFEMERGENCYINCIDENTS,20167

FIGURE3.OTTAWAFIRESERVICES:BREAKDOWNOFEMERGENCYINCIDENTS,2011 8

FIGURE4.OTTAWAFIRESERVICES:BREAKDOWNOFEMERGENCYINCIDENTS,2016 8

FIGURE5.TORONTOFIRESERVICES:BREAKDOWNOFEMERGENCYINCIDENTS,20119

FIGURE6.TORONTOFIRESERVICES:BREAKDOWNOFEMERGENCYINCIDENTS,2016 9

FIGURE7.VAUGHANFIREANDRESCUESERVICE:BREAKDOWNOFEMERGENCYINCIDENTS,2011 10

FIGURE8.VAUGHANFIREANDRESCUESERVICE:BREAKDOWNOFEMERGENCYINCIDENTS,2016 10

FIGURE9.VFRSYEARLYINCIDENTS:NUMBERANDPERCENTAGETOEIGHT‐YEARTOTAL(2009‐2016) 13

FIGURE10.VFRSMONTHLYINCIDENTS:NUMBERANDPERCENTAGETOEIGHT‐YEARTOTAL(2009‐2016)13

FIGURE11.VFRSDATA:TOTALNUMBEROFINCIDENTSPERMONTH(2009TO2016)14

FIGURE12.VFRSDATA:TOTALVEHICLERESCUESPERMONTH(2009TO2016) 14

FIGURE13.VFRSDATA:TOTALFIREINCIDENTSPERMONTH(2009TO2016) 15

FIGURE14.VFRSDATA:DISTRIBUTIONOFTIMEBETWEENSUCCESSIVECALLS,INMINUTES 15

FIGURE15.VFRSDATA:RESPONSETIMEDISTRIBUTION(ALLINCIDENTTYPES) 16

FIGURE16.VFRSDATA:ONSCENETIMEDISTRIBUTION(ALLINCIDENTTYPES) 17

FIGURE17.VFRSDATA:SPATIALDISTRIBUTIONANALYSISFORSPECIFICINCIDENTTYPES(2009‐2016)18

FIGURE18.VFRSDATA:ESTIMATEDAPPTOTDISTRIBUTION(ALLINCIDENTTYPES) 19

FIGURE19.INTEGRATIONOFEMPIRICALDATAFORSIMULATIONOFTHEINCIDENTLIST 20

FIGURE20.INCIDENTGENERATIONENGINE:MAINCOMPONENTS 21

FIGURE21.AGENTSUSEDINTHEMODEL 23

FIGURE22.SUBDIVISIONOFTHECITYOFVAUGHANINTOFIREDISTRICTSANDCURRENTFIRESTATIONLOCATIONS 24

FIGURE23.MODELHOMEPAGEANDSETTINGPARAMETERS 28

FIGURE24.STATIONSTATUSANDRELATEDSYMBOLS 28

FIGURE25.AGENTS’STATECHARTS 30

FIGURE26.PERFORMANCEINDICATORSVISUALIZEDDURINGSIMULATION 31

FIGURE27.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,JANUARY 32

FIGURE28.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,FEBRUARY 33

FIGURE29.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,MARCH 33

 

43  

FIGURE30.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,APRIL 34FIGURE31.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,MAY 34FIGURE32.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,JUNE 35FIGURE33.DISTRIBUTIONOFSIMULATEDRESPONSETIMES,JANUARY–JUNE 35FIGURE34.AVERAGETRAVELDISTANCEPERINCIDENT(INMETERS)FORFIRSTRESPONDERVEHICLES

(180REPLICATIONS) 37

FIGURE35.SIMULATEDNUMBEROFINCIDENTS,BYREGION(180REPLICATIONS) 37FIGURE36.RESPONDINGVEHICLE/CREWOVERALLTIMEBREAKDOWN,BYREGION(180REPLICATIONS)38 

 

44