FD-CAST: A Tool for Analyzing
and Simulating Fire Department
Configurations
Naoya Yabuki1(B) , Sachio Saiki1 , and Masahide Nakamura1,2
1

Graduate School of System Informatics Kobe University,
1-1 Rokkodai, Nada, Kobe, Japan
yabuki@ws.cs.kobe-u.ac.jp, sachio@carp.kobe-u.ac.jp, masa-n@cs.kobe-u.ac.jp
2
Riken AIP, 1-4-1 Nihon-bashi, Chuo-ku, Tokyo 103-0027, Japan

Abstract. The ﬁre department conﬁguration, which determines thenumber and the locations of ﬁre stations as well as the formation ofﬁre trucks, is a key element to achieve eﬃcient ﬁre ﬁghting operations
under limited resources. In this paper, we develop a tool, called FDCAST, which visualizes estimated arrival information of ﬁre trucks forgiven ﬁre department conﬁguration. FD-CAST ﬁrst computes the distance and time between every pair of a ﬁre station and a town block,based on the conﬁguration and geographic information. Then, assumingthat a ﬁre occurs at a town block, FD-CAST derives a designated set
of ﬁre trucks to be dispatched and their estimated time of arrival. The
result is visualized in a table and a choropleth map. A user can also
simulate various situations by modifying the conﬁguration information.
We have implemented a prototype of FD-CAST, and conducted casestudies with practical examples. Through feedback from ﬁre oﬃcers, we
conﬁrm the eﬀectiveness of FD-CAST for analyzing the ﬁre department
conﬁguration problem.
Keywords: Smart city · Data visualization · Fire department · Web
application

1

Introduction

Recent years, many ﬁre departments in Japan are collecting digital records ofevery dispatch of ﬁre trucks and ambulances with ICT systems. The large-scaledispatch logs are supposed to be used for various data-driven approaches topredict the demands and optimize their resource operations. For example, theFire and Disaster Prevention Science Center are showing the distribution ofﬁreﬁghting demands, and the current fulﬁllment of the demands for some ﬁredepartments [2].
The Kobe City Fire Department (KCFD) has also started a similar datadriven trial. The objective is to see how much extent the conﬁguration of theﬁre departments (i.e., locations of ﬁre stations and the arrangement of ﬁre trucksc Springer Nature Switzerland AG 2020

V. G. Duﬀy (Ed.): HCII 2020, LNCS 12199, pp. 199–213, 2020.
https://doi.org/10.1007/978-3-030-49907-5_14

200

N. Yabuki et al.

in each station) can suﬃce the demand from every town block within the Kobecity. More speciﬁcally, the KCFD wants to know the answer for the following
question:
Question Q1: “When a ﬁre occurs in a town block B, can the designated set
F of ﬁre trucks arrive at B within allowable time T?” If the answer of Q1 isnegative for some B’s, the KCFD also like to know what the better conﬁguration is, which is characterized by the following question. Question Q2: “Whenthe conﬁguration is changed, how will the answer of Q1 be updated?” The conﬁguration changes in Q2 include updating the arrangement of ﬁre trucks in astation, moving a station to another place, and creating a new ﬁre station.
The goal of this research is to allow the staﬀs of the ﬁre department to
conduct the analysis for Questions Q1 and Q2 without special expertise of data
mining. To achieve the goal, we develop an application, called FD-CAST (Fire
Department Conﬁguration Analysis and Simulation Tool). FD-CAST isdeveloped based on the following Requirements R1 and R2, corresponding Q1
and Q2, respectively.
Requirement R1 (Visualization): For every town block B, the application
derives a list of ﬁre trucks of all types, each of which arrives at B earliest
among those with the same type. Every element of the list should contain the
ID of the ﬁre truck, the distance from the ﬁre station, and the estimated time
for arrival (arrival time). The list should be visualized so as to facilitate theanalysis of Questions Q1.
Requirement R2 (Simulation): Every user of the application can change theﬁre department conﬁguration to address Question Q2. The allowable changes
are to add, move, or delete the ﬁre trucks among the ﬁre stations. Similarly,
the application allows to add, move, or delete any ﬁre station. For a new
conﬁguration, the user can visualize the result as speciﬁed in P1.
To satisfy these requirements, we develop FD-CAST based on the following
steps:
Step 1 (Preparing Conﬁguration Data): We prepared the data which isessential for FD-CAST. The data includes “ﬁre station”, “ﬁre truck”, “townblock” and “distance along road”.
Step 2 (Visualizing Arrival of Fire Trucks): FD-CAST compute where
each type of ﬁre truck arrives from and how long it takes, when a ﬁre occuredin each town block B.1
Step 3 (Simulating New Conﬁgration): We develop a feature that allows
each staﬀ to independently edit the ﬁre department conﬁguration and reexecute visualization.
In this paper, we implemented the proposed FD-CAST prototype as a Web
application and performed a case study. Speciﬁcally, we had rough understanding
1

The rushing distance and time are calculated from geographical information and theaverage speed of the vehicle, and do not match actual dispatch data.

FD-CAST: A Tool for Analyzing and Simulating Fire Department

201

of the current situation of the water discharge vehicle arrival to all town block andsimulated improvement measures by relocating the water discharge vehicles. We
also analyzed the eﬀects of establishing a new ﬁre station from the perspectiveof arrival. In addition, the KCFD stuﬀ actually used FD-CAST for their workand they sent us feedback. The results showed that FD-CAST was a useful tool
for answering questions Q1 and Q2.

2

Preiliminaries

2.1

Fire Department Data

In recent years, the ﬁre departments of each municipality have introduced thelatest ICT system to improve the eﬃciency of ﬁre and emergency services. Representative data recorded and managed by such ICT systems include dispatch
data, ﬁre statioin data, vehicle data, and so on. The dispatch data records detailsof emergency and ﬁre dispatches at the ﬁre department, and data items include
dispatch date and time, disaster type, dispatched vehicle number, arrival date
and time, and so on. The type of disaster represents the type and duty of thecorresponding disaster, such as ﬁre, emergency, rescue, ﬂood, and alert. Fire station data is data about the ﬁre department, including the name and address ofﬁre stations under the jurisdiction of the ﬁre department. Vehicle data is dataof ﬁre and ambulance vehicles owned by the Fire Department, including datasuch as vehicle numbers, assigned ﬁre departments, vehicle types, and concurrent vehicles. Concurrent vehicle refers to a group of vehicles operated by thesame unit that also serves multiple duties Therefore, while one of the concurrent
vehicles is dispatched, the other vehicle cannot be dispatched.
2.2

Fire Department Conﬁguration Issues

In this paper, the problem of the local government’s ﬁre department deciding
where and how many ﬁre stations to set up in the area and how many vehicles toplace at each ﬁre station is referred to as the ﬁre department’s conﬁguration
problem. Conﬁguration issues is directly related to the possibility of quick andeﬃcient ﬁre ﬁghting when a ﬁre occurs. Therefore, it is necessary to consider abetter composition of the ﬁre department in anticipation of the current situationand the future situation.
In the case of Kobe City, there are 28 ﬁre stations in 9 wards, and a totalof 130 ﬁre trucks and ambulances are operating on a daily basis. Table 1 shows
the number of ﬁre stations and ﬁre trucks by vehicle type located in each ward.
Each row in the table indicates the number of ﬁre stations and ﬁre trucks ineach ward. Numbers in parentheses indicate the number of vehicles that can bedispatched at the same time, and are due to restrictions on concurrent vehicles.
Considering the municipal ﬁnances, it is not easy to increase units and vehicles.
The proposition is how to ﬁnd an eﬃcient conﬁguration within a limited rangeof resources.

202

N. Yabuki et al.
Table 1. Number of ﬁre stations and ﬁre trucks by vehicle type in Kobe

Ward

Station Command Rescue Water discharge Ambulance Ladder Total

Higashinada

4

1

1

9(6)

4

2(1)

Nada

2

1

1

3(2)

3

0

8

Chuo

3

1

2

5(3)

4

2(1)

14

Hyogo

2

1

1

3(2)

2

0

7

Nagata

2

1

1

3(2)

3

2(1)

10

Suma

3

1

1

5(3)

3

0

10

Tarumi

4

1

1

7(5)

4

2(1)

15

Nishi

3

1

1

6(3)

4

1

13

Kita

5

2

2

11(6)

5

3(2)

23

Total

28

10

11

52

32

12

117

2.3

17

Evaluation and Improvement of Conﬁguration Based on Data

When a ﬁre occurs in a area, it is necessary that a group of appropriate ﬁre vehicles arrive to the scene according to the type and scale of the ﬁre and extinguishthe ﬁre. For example, there is an ideal criterion “four water discharge vehicles
can arrive within 8 min in the case of general building ﬁre”. Of course, dependingon the location of the ﬁre and the conﬁguration of the ﬁre department, thesecriteria may or may not be met. Therefore, it is the greatest concern for the ﬁredepartment to understand “How many minutes can a speciﬁed set of vehicles
arrive at a town block”, which is the question Q1 described in Sect. 1.
The KCFD sets various standards and evaluates the conﬁguration of theFire Department based on data, and is making eﬀorts to improve it. However,at present, the staﬀ are analyzing data using general-purpose tools such as Excel
and GIS (Geographic Information System), and it takes a lot of time to evaluate
the current conﬁguration. Furthermore, it is currently impossible to try andevaluate various conﬁgurations by simulation, which corresponds to the question
Q2 described in Sect. 1.
2.4

FigMap4SC: Fine-Grained Map Coloring Web Service
for Smart City Analytics

Our research group is developing a Web service FigMap4SC that colors maps
based on given data and creates choropleth map [3]. If the user gives a data set
with the address (city, ward, town or block) in the area as a key and the value
associated with it as a value, FigMap4SC automatically creates a choropleth
map with the speciﬁed granularity. In addition, we published the Web-API, andexternal applications can input data directly to FigMap4SC without humanintervention. By using FigMap4SC, any external application can easily visualize
its analysis results on a map. In this study, we also use FigMap4SC as a means
to visualize the ﬁre truck arival time on a map.

FD-CAST: A Tool for Analyzing and Simulating Fire Department

3

FD-CAST: Fire Department Configuration Analysis
and Simulation Tool

3.1

Requirement203

In this study, we will develop a ﬁre department conﬁguration analysis and simulation tool FD-CAST to solve the problems described in the previous section.
FD-CAST is developed based on requirements R1 (visualization) and R2 (simulation) described in Sect. 1.
3.2

System Architecture

Figure 1 shows the system architecture of FD-CAST. FD-CAST is developed as aclient-server type Web application. The left side of the ﬁgure shows the functions
on the client side. Users can visualize the arrival and change the conﬁguration
using a Web browser. It also has a user management function so that multiple
users can independently change the conﬁguration and simulate arrival. The rightside of the ﬁgure shows the functions and data on the server side. The following
sections explain these details.

Clientvisualize
arrivalAPI

getarrivalServer(e) Arrival data

calculation of arrival

simulatechangeconfiguration(d) Distance data

calculation of distance(a)Configuration
data

Actor

login
customize

maintenanceof user
information(b) Town data(c) User data

Fig. 1. System architecture of FD-CAST204

N. Yabuki et al.

3.3

Data Preparation

We prepare the data required to implement FD-CAST. As shown in Fig. 1,
FD-CAST consists of three types of master data ((a) Conﬁguration data,(b) Town data, (c) User data) and two types of derived data ((d) Distance data, (e) Arival data). Figure 2 shows the ER diagram that deﬁnes
the data model of FD-CAST. This ER diagram is based on the notation shownin [4]. Squares represent entities, — represents parent-child relationships, and—. . . represent reference relationships. Below the data item of each entity, an
instance is illustrated.

Town

towncode, address, lat, lng(b)Town

102096000, Rokkodi Nada, 34.728, 135.232
101014000, Sumiyoshi-higashi Higashinada, 34.691, 135.194:

Distance sid, towncode, distance, time(d)DistanceFirestationUseruid, sid, name, ward, address
1, 1, Nada, Nada, Kamiki-Dori1, 2, Aoyabashi, Nada, ShironoShita-Dori1, 3, Higashinada, Higashinada, Sumiyoshi-higashi
1, 4, Fukadaike, Higashinada, Sumiyoshi-yamate:

Arrivaluid, towncode, tid, order, vid, time, distance(e)Arrival

1, 102096000, WG, 1, Nada13, 223, 1859
1, 102096000, WG, 2, Nada11, 309, 2581
1, 102096000, WG, 3, Higashinada2, 369.3083
1, 102096000, WG, 4, Higashinada11, 565, 4715:

uid, name, password
1, yabuki, 1a9e...
2, kobefire, 2dee..
:
.

Color
(c)User

1, 102096000, 1859, 458
2, 102096000, 4715, 565
3, 102096000, 2581, 309
4, 102096000, 3083, 369:

Vehicleuid, order, color codeyabuki, 1, #0000FF
yabuki, 2, #0066FF:

Vehicletypeuid, vid, fire station, tid,concurrency vehicle
1, Nada2, Nada, SP, Nada13
1, Nada11, Aoyabashi, TA, 1, Nada13, Nada, NC, Nada2
1, Higashinada11, Higashinada, TA,
Higashinada3
1, Higashinada2, Fukadaike, SP, :tid, name, group

SP, Small Pump, WG
NC, Normal Chemical, WG
TA, Tank, WG
NP, Normal Pump, WG
WG, Water Group, :Allocation fire type, duty class, tid, # of dispatch(a)Configurationbuilding fire, extinguish, WG, 4building fire, rescue, RG, 1:

Fig. 2. Data model of FD-CAST (Color ﬁgure online)(a) Conﬁguration dataConﬁguration data is data that deﬁnes and manages the conﬁguration of theFire Department, and consists of four entities: ﬁre station, vehicle, vehicle
type, allocation. Fire station entity holds name, jurisdiction ward and addressof each ﬁre department under the jurisdiction of the Fire Department. Vehicle
entity holds the ID of each vehicle under the jurisdiction of the Fire Department,
belonging ﬁre station, vehicle type, and the information on the concurrency
vehicles. Vehicle type entity deﬁnes the type (class) of the vehicle, and deﬁnes avehicle type and multiple vehicle types as a group depending on the application.
Allocation entity holds information that assigns which car type (group) should
be dispatched to which ﬁre type/duty class and how many vehicles should be
dispatched. For the ﬁre department and vehicles, the user ID is included in the
primary key so that FD-CAST users can freely add and change them. This time,
the composition data is created based on the data provided by KCFD.

FD-CAST: A Tool for Analyzing and Simulating Fire Department

205(b) Town data
Town data is composed of a town entity that hold the addresses of all the
town blocks managed by the local government and the latitude and longitude of
the center point. In the case of Kobe City, there are 3,326 town-blocks in ninewards, each identiﬁed by a nine-digit address code (towncode) This town data
was created by obtaining the list of towns in all Kobe city [1] from the open
data catalog of Kobe city, and obtaining its latitude and longitude using Yahoo
GeoCoding API [5].
(c) User data
User data is data that manages user information of FD-CAST, and consists of
two entities user, color. User entity holds the user ID, name, and password.
Color entity deﬁnes a user-deﬁned color scale for visualization. User data iscreated by the user registration function of FD-CAST.
(d) Distance data
Distance data consists of a distance entity that manage the distance from theﬁre station to the town block. Each instance holds the distance (m) and theestimated time (sec) of one ﬁre department and one town block. The value ofthe distance is derived from the address of the ﬁre department and the coordinates of the town block based on geographic information. The estimated time
is calculated by dividing the distance by the average speed of the vehicle. Thistime, using Google Direction API, we found a route along all pairs of 28 ﬁrestations in Kobe × 3,326 town block, and created distance data using the length
as the distance. In addition, FD-CAST users can freely set the average vehicle
speed, and the default value is 30 km/h.
(e) Arrival data
Arival data consists of a arrival entity that holds which vehicle can arrive to eachtown block in how long time. The primary key is composed of [user ID, town
code, vehicle type, order]. We assume that each user independently manages
the arrival information and the vehicles arriving at each town in order of vehicle
type and arrival time. The attributes of each instance hold the ID of the arriving
vehicle, the estimated time, and the distance from the ﬁre station. Arrival datais calculated by FD-CAST according to the procedure described in the next
section.
3.4

Visualization of Arrival

When a ﬁre occurs in each town block B, FD-CAST calculate for each type ofﬁre truck which ﬁre truck arrives from where and how long by the following
procedure. In the following, the entities in Fig. 2 are abbreviated as [name].
1) Obtain the vehicle type τ and the number of dispatch n required for the
speciﬁed ﬁre type/duty from [allocation].
2) Get all vehicle types tau1 , τ2 , . . . , τk belonging to τ from [vehicle type].
3) Find all vehicles v1 , v2 , . . . , vs whose vehicle type is τ1 , τ2 , . . . , τk from [vehicle].

206

N. Yabuki et al.

4) Refers to the [distance] using the ﬁre station si to which each vi belongs
and the current town block B as keys, and calculates the distance δi and theestimated time ti from si to B.
5) Sort v1 , v2 , . . . , vs in ascending order by estimated time, and the ﬁrst n vehicles vf 1 , vf 2 , ..., vf n are selected as arrival vehicles for the vehicle type τin town block B. At this time, if a concurrency vehicle is included, the vehicle
is excluded and the next vehicle in the order is moved up and selected.
6) For 1 ≤ j ≤ n, register (B, τ, j, vf j , δf j , tf j ) in [arrival].
For example, we will calculate the arrival information required for a ﬁreextinguishing mission for a building ﬁre in Rokkodai, Nada, Kobe, with reference to the instance of Fig. 2. From [allocation], we can see that four Water
Group (WG) are required. From the [vehicle type], WG includes four types: small
pump, normal chemical, tank, and normal pump. Vehicles in WG such as Nada2
and Nada13 are listed from [vehicle]. From [ﬁre station] and [distance], we ﬁnd
the distance and estimated time between the ﬁre station to which each vehicle
belongs and Rokkodai, Nada, and sort them in ascending order. At this time,
Nada2 is excluded because it is a concurrency vehicle of Nada13. As a result,four vehicles, Nada13, Nada11, Higashinada2, and Higashinada17, are selected.
After the arrival data for all town blocks is created by the above procedure,
they are listed in a table format and visualized. At this time, each row of thetable shows the town block, and each column shows the arrival information foreach vehicle type. Each cell in the table displays the vehicle ID, the distancefrom the ﬁre station to the town block and the estimated time.
In addition, color-coding the cells according to the estimated time helps us
to understand the data. By default, the shorter the time is, the more blue it is,and the longer it is, the more red it is. This color scale can be customized to theuser’s preferred color scheme, and the settings are managed by color entities. In
addition, we can analyze the arrival data in detail by sorting by the attributeof each column, and searching and narrowing down by the value of the address
and the arrival time.
Moreover, by linking with FigMap4SC (see Sect. 2.4), we can visualize arrival
data on a map. By passing the pair of the address of each town and the color
code assigned to the cell to the Web-API of FigMap4SC, we can visualize thearrival information calculated from the current conﬁguration on the choropleth
map. Therefore we can see at a glance which town block it takes time to rush togeographically.
3.5

Change of Conﬁguration and Simulation

To respond to request R2, FD-CAST allows each user to independently change
the conﬁguration data. Speciﬁcally, it is allowed to add, update, and delete dataof [ﬁre station] and [vehicle] in the conﬁguration data of Fig. 2. For vehicle data,
it is also possible to set the vehicle to undispatchable. This allows you to set up a
new ﬁre station in the area, move vehicles under the control of one ﬁre station toanother ﬁre station, and try out various ﬁre station conﬁgurations. Since [vehicle

FD-CAST: A Tool for Analyzing and Simulating Fire Department

207

Table 2. Used technology
ClientJavaScript, HTML5

Server
Database
Web server
Library

PHP5, Python (generate data)
MySQL
Apache 2.4.37
Google Maps API, Direction API, phpoﬃcetype] and [allocation] are commonly used by ﬁre departments nationwide, thesechanges are not permitted at present.
When the user changes the conﬁguration data, FD-CAST calculates the distance and arrival again, and derives the distance data and installation data
based on the new conﬁguration data (see Fig. 1). Users can view and conﬁrm
the updated data by visualizing the arrival of Sect. 3.4.
The user can simulate and evaluate various conﬁgurations of ﬁre departments by repeatedly executing the above conﬁguration change and visualization
processes.
3.6

Login and Customize User

FD-CAST manages user information so that multiple users can independently
analyze and simulate conﬁguration information. Users can create a new user
account by registering their login ID and password in FD-CAST. When a newuser is created, FD-CAST creates its own [ﬁre station], [vehicle], [distance],[arrival] tables and loads the default data. It also creates a [color] table anda default color scale. By creating a dedicated table for each user, users canchange conﬁguration information, simulate, and customize visualization withoutaﬀecting other users.

4

Implementation

Based on the data model and functions described in Sect. 3, we implemented a
prototype of FD-CAST.
4.1

Used Technology

Table 2 shows the technology used to implement the prototype. We implemented
FD-CAST as a Web application, and programmed using HTML5 and JavaScripton the client side and PHP on the server side. Python was used to generate thedistance data. The database used MySQL, the Web Server used Apache 2.4.37,
and the library used Google Maps API, Directions API, and phpoﬃce.

208

N. Yabuki et al.

Fig. 3. Arrival visualization screen (Color ﬁgure online)

4.2

Arrival Visualization Screen

Figure 3 shows the arrival visualization screen. As described in Sect. 3.4, eachrow in the table represents a town block, and each column shows the arrival
information of the vehicle type at that town block. For example, looking at theﬁrst row and ﬁfth column of the table, we can see the ﬁrst water discharge vehicle
that can arrive at 1, Sannomiya, Chuo, Kobe is “Chuo 13”.
Each cell in the table is color-coded according to the arrival time of eachvehicle. By default, the cells are displayed in blue for fast and red for slow. You
can change the average speed of the vehicle from the pull-down list in the upper
left. In addition, there are buttons for sorting data by the value of each column
and buttons for searching.
Figure 4 shows a display example in map format. This ﬁgure visualizes thetime it takes for the water discharge vehicle to arrive in the entire area of Kobe
City. The same color as the visualization in the table format is used, areas where
the arrival time is short are displayed in blue, and long areas are displayed in
red.
4.3

Conﬁguration Change Screen

Figure 6 shows the prototype vehicle conﬁguration change screen. As deﬁned inFig. 2, each ﬁre truck has vehicle number (ID), belonging ﬁre station, vehicle
type, and concurrency vehicle, and these are displayed on the list screen. By
pressing the “Edit” button, the screen changes to the edit screen, and among
these information, it is possible to change information other than vehicle number.
The changed information is stored in the database. Users can also add a newvehicle by clicking the “Add” button, or change the vehicle to undispatchable
by using the “Unable” button. If you want to search for a speciﬁc vehicle, youFD-CAST: A Tool for Analyzing and Simulating Fire Department

209

Fig. 4. Visualization of arrival on the map in cooperation with FigMap4SC (Colorﬁgure online)

can go to the search screen by pressing the “search” button on the upper left,
and you can also search and display only vehicles that meet speciﬁc conditions.
With these functions, it is possible to simulate the conﬁguration of a virtual ﬁrestation that cannot be tried at actual sites.
4.4

Color Scale Setting Screen

FD-CAST performs color coding according to arrival time when visualizing
arrival information in tabular format. This color is deﬁned by a color scale thatassigns 11 diﬀerent colors to each segment in units of 60 s from 0 s to 600 s and
600 s or more. Figure 6 shows the default color scale. On this screen, users canchange the color of each section to their favorite color and change the appearance of the visualization result. They can set a visualization method suitable
for analysis, for example, by deﬁning the color scale according to the standardof interest, such as coloring only the area of 8 min or more by turning colorlesswithin 480 s and red for 480 s or more.

5

Case Study

In order to conﬁrm the eﬀectiveness of FD-CAST, we conducted a case study
using realistic examples.
Case 1: Current Situation of Water Discharge Vehicle Arrival and
Relocation The rapid arrival of the water discharge vehicle is an important

210

N. Yabuki et al.

Fig. 5. Conﬁguration change screen

Fig. 6. Color scale setting screen (Color ﬁgure online)

factor in minimizing the spread of ﬁre (see Sect. 2.3). We use FD-CAST to visualize how long a water truck can arrive each town block in Kobe. Figure 7 showsthe estimated time of arrival of the second water discharge vehicle at each town
street calculated by FD-CAST on a map using FigMap4SC. The central southerncity where many ﬁre stations are located is colored in cold colors, and it showsthat two water trucks arrive immediately in this area. On the other hand, thenorthern and western areas, which are far from the ﬁre department, are coloredin warm colors, and it shows that it takes time to arrive.
Next, we moved one water discharge vehicle from a ﬁre station in the city toa ﬁre station in the north, and visualized the arrival again. Figure 8 shows thearrival times of the two water discharge vehicles after the conﬁguration change.
The × and  marks in the ﬁgure indicate the locations of the ﬁre station in thecity and the ﬁre station in the north, respectively. Comparing Fig. 7 and Fig. 8,
this change in conﬁguration signiﬁcantly decreased the arrival time in some partsof the northern region without sacriﬁcing the rushing time in the city.
Case 2: Establish New Fire Station. Currently, the KCFD is planning toestablish a new ﬁre station in Nishi Ward. Therefore, we simulated the arrival
time of two water discharge vehicle if a new ﬁre station was established at theconstruction site. Speciﬁcally, we established a new ﬁre station at the address
in western Kobe, and a water discharge vehicle is added there. Figure 9 shows
visualization of the arrival times of two water discharge vehicles if a new ﬁreFD-CAST: A Tool for Analyzing and Simulating Fire Department

211

Fig. 7. Estimated arrival time of two water discharge vehicle (Color ﬁgure online)

station was established. The circles in the ﬁgure indicate the locations of theestablished ﬁre stations. Compared to Fig. 7, the arrival time around the newﬁre station is shorter.
5.1

Feedback from Staﬀ Members

The developed prototype of FD-CAST is currently used at the KCFD. We got
feedback about its beneﬁts and improvements from staﬀ members using thesystem. We introduce some of the feedback below.
– It is convenient because we can easily check and visualize the arrival to eachtown
– It is good to be able to simulate the eﬀects of vehicle conﬁguration and newor changed ﬁre departments that cannot be easily tested at actual sites.
– Why is the rush time signiﬁcantly diﬀerent from the actual result in someareas?
– Can FD-CAST automatically determine the optimal conﬁguration by calculation?
The ﬁrst and second feedbacks show that FD-CAST has contributed to theanalysis and investigation of the ﬁre department’s conﬁguration problems in
actual sites. The third comment is due to the fact that the route calculatedby the Google Direction API used to calculate the distance was signiﬁcantly
diﬀerent from the route that the ﬁre truck actually ran. We want to improveit by reviewing API options. The fourth comment is equivalent to solving an
optimization problem, and is a feature that is not supported by current FDCAST. We want to make it a future work.

212

N. Yabuki et al.

Fig. 8. Estimated arrival time of two water discharge vehicle (after conﬁguration
change) (Color ﬁgure online)

Fig. 9. Estimated arrival time of two water discharge vehicle (after establishing) (Colorﬁgure online)

6

Conclusion

In this study, we proposed FD-CAST, a tool to support the analysis and simulation of the conﬁguration of the ﬁre department. For a given conﬁguration,
FD-CAST calculates the arrival of ﬁre trucks to each town block, and visualizes it in a tabular form or on a map. In addition, we implemented a prototypeof FD-CAST and performed a case study using realistic examples. As futuretasks, we plan to study the optimization of the calculation of the distance whenchanging the position of the ﬁre department and the method of automaticallycalculating the better conﬁguration.

FD-CAST: A Tool for Analyzing and Simulating Fire Department

213

Acknowledgments. This study is conducted as part of a joint study with the Kobe
City Fire Department. This research was partially supported by JSPS KAKENHI
Grant Numbers JP19H01138, JP17H00731, JP18H03242, JP18H03342, JP19H04154,
JP19K02973.

References
1. Kobe city list. https://www.city.kobe.lg.jp/a53715/kurashi/registration/jukyo/
ichiran.html
2. Fire, G., Center, D.P.S.: Business such as appropriate placement of ﬁreﬁghting
power. https://www.isad.or.jp/to ﬁre department/proper placement/
3. Nakai, T., Saiki, S., Nakamura, M. July 2020, to be appeared
4. Watanabe, T.: Data Modeling for Production Management and Cost Management
System. Japan Business Publisher Co., Chiyoda City (2002)
5. YOLP(map): Yahoo! geocoder api - yahoo! developer network. https://developer.
yahoo.co.jp/webapi/map/openlocalplatform/v1/geocoder.html