In this section, the technical description of the system is presented. It is centered on the architectural model as well as on the implementation of the concepts and algorithms, elaborated in the previous section.
A general overview of the system is depicted in
Figure 8. In particular,
Figure 8a shows the Graphical User Interface (GUI) from the citizens/users side, which implements the IoT Layer of the logical architecture described in
Section 4.1 as a mobile App. It allows citizens to generated
crime reports according to the concepts defined in
Section 4.2. It worth noticing that, when generating a crime report,
location and
timestamp are automatically extracted from the mobile device, whereas
type of crime and
description can be additionally inserted by the user.
Figure 8b shows the GUI from the Police Forces perspective. It implements the other layers of the logical architecture described in
Section 4.1, according to the concepts defined respectively in
Section 4.3 and
Section 4.4. In particular, a blu circle on the map represents a citizen, who can interact with the system by generating
crime reports and receiving
back notifications through the app, whereas the calculated
tracking path is represented as green segments interconnected by
tracking points depicted as smaller circles. The
predicted direction and the
area of risk is, instead, delineated from the triangular area enclosed between the two red segments.
5.1. Simulation-Based Approach
The simulation mode extends the operation mode by enabling the simulation of a criminal scenario by introducing two types of virtual actors: a VirtualCitizen and a VirtualCriminal. Such virtual actors replace the real users, in the generation process of crime reports, centered on the mobile app, when perceiving a real criminal, by implementing a simulated perception. More specifically, a VirtualCriminal is used to simulate the behavior of a criminal by generating a crime event in the scenario, whereas a VirtualCitizen simulates the behavior of a citizen, who can send and receive notifications about an event of crime.
As illustrated in
Figure 9, in the
operation mode (i.e., in reality) the generation of a crime report from a user is guided by the physical perception of a crime event. For example, at the sight of the criminal who is committing a crime, or being part/victim of a crime situation. In order to simulate this mechanism, in the
simulation mode, not only the role of the virtual citizen has been implemented, but also the role of the virtual criminal has been introduced in the simulator. This is necessary to simulate the perception of a crime situation, in order to trigger the virtual citizen to generate a crime report. As a consequence, when the software is working in
simulation mode, it includes all the architectural layers, that are described in
Section 4.1.
Figure 10 shows the GUI of the system in simulation mode. It is built on the top of Google maps, as it allows natively to visualize graphically streets and places. More details of the overall employed technologies for its implementation is provided below.
In the center of
Figure 10 is the map, which differs from that of
Figure 8b as the blue circles represent
VirtualCitizens, while the red circle models the concept of the
Virtual Criminal. On the top-left part of the software environment, it is possible to select the functioning mode:
Operation mode or
Simulation mode (as it is currently depicted). Below it, a panel for selecting
VirtualCitizen(s) and
VirtualCriminal(s) is available. The
VirtualCriminal, who plays the role of criminal, is used to simulate the behavior of a person who commits a crime and, as a consequence, it is used to trigger the event for the
VirtualCitizens in order to generate crime reports. More specifically, when the simulation mode is active, it is possible to select, through the respective buttons, virtual citizens and virtual criminals to be placed on the map and to configure them, in order to set up a simulated criminal scenario.
In particular, the Actor Configuration Panel is available on the left bottom side of the GUI which allows to configure VirtualCitizen. Through it, it is possible to configure each of such actors, in such a way that they are able to warn dangerous events (if the option “Active” is checked) when they perceive a close Virtual Criminals, which is specified in meter through the parameter “UserVisibility”.
The concept of perception is modeled using the size of the circle that is used to represent virtual actors, whose radius can be defined through the UserVisibility parameter. In particular, a Virtual Citizen perceives a criminal or a crime, when the circle representing him intersects the circle of a Virtual Criminal. At this point the Virtual Citizen is triggered to generate a report. As a consequence, the bigger a circle is configured the bigger is the possibility of a Virtual Citizen to get in touch with a Virtual Criminal through the intersection. The report is generated according to the Algorithm (1) by additionally specifying the “Type of crime” and an optional “ Textual Description”). Virtual actors with such configuration are used to simulate the citizens who, in the real life, have the App installed and active on their smart devices.
On the left middle side of the GUI, a configuration panel called Environmental Parameters allows, instead, to configure the parameters which are used to compute both the Tracking points and the Area of risk. In particular:
- -
the
Time Window is computed in minutes, and it is used both to select the most recent crime reports for generating tracking points, according to the concept defined in
Section 4.3 and
Section 4.4;
- -
the
Range of Action is computed in meters, and it is used to allocate crime reports to events of crime, on the basis of the proximity principle defined in
Section 4.3;
- -
the
Notification Range is defined in meters, and it is used to determine area of risk about the ongoing potential dangerous situation as well as whom to send the notifications on the basis of the concepts defined in
Section 4.4;
- -
the Range Angle, which is computed in angular degree, is used to define the size of the area of risk in order to delimit the places to be gathered as well as the citizens to be notified.
Before discussing the data gathered by running the tool in simulation mode, in order to illustrate how the defined algorithms work, a brief overview of the digital technologies, which have been employed to implement the above-presented system, is provided.
In particular,
JavaScript [
47] is a lightweight scripting language for developing web pages that allows to write client-side code, by making dynamic pages, in order to support the interaction with users. The main advantages rely on being client-side, that means to be very fast because it can be run immediately within the client-side browser, interoperable with other programming languages, and extendable in terms of functionalities. Whereas,
Node.js [
48] is a runtime environment for the server-side scripting execution. It is open source and cross-platform and it supports the generation of dynamic web page content before the page is sent to the user’s web browser [
49]. It is built on the V8 Chrome engine, and it is event-based and non-blocking. It means that it is able to have multiple requests in progress at the same time by the same process (or thread), as it uses a non-blocking I/O model.
Firebase [
50] is a Backend-as-a-Service (BaaS) app development platform, which supports data storage and sending notifications [
51]. Whereas, Firebase Cloud Messaging (FCM) is a free cross-platform solution for messages and notifications for Android, iOS, and web applications, which provides a real-time database and backend as a service. APIs, for the developers, are also available [
52].
Google Maps [
53] is a web mapping service, which provides APIs to build location-based services, that supports JavaScript. It offers satellite imagery; aerial photography; street maps; 360 panoramic views of streets (Street View); real-time traffic conditions; and route planning for traveling by foot, car, bicycle, air, or public transportation.
Ionic Framework [
54] is a mobile UI toolkit which provides a free and open source SDK for developing cross-platform mobile application for native iOS, Android, from a single codebase [
55]. Whereas,
AJAX [
56] is a client side technique for communication with a web server. It focusses on the exchanging data with a server, and update parts of a web page without reloading the whole page, by decoupling the data interchange layer from the presentation layer [
57].
5.2. Evaluation and Discussion
The evaluation was based on three different approaches: (i) a simulation-based experimentation to assess the functioning on the defined algorithms, (ii) an usability-based evaluation in order to assess the system in terms of its usability from the citizens perspective, and (iii) a statistics based approach in order to estimate the intervention time gained from the PFs by using it.
The experimentation of the above presented implementation has been tested on a city scale, and in particular in Darmstadt (Germany).
Figure 10 represents the area close to the train station of the simulated scenario, which has been used to test the proposed concepts and the related algorithms. It shows four
Virtual Citizens, that have been used and configured as “Active”, and one
Virtual Criminal. The simulation is performed by manually moving the
Virtual Criminal on the map. When the
Virtual Criminal enters in the range of visibility of a
Virtual Citizen (i.e., close to a citizen according its “UserVisibility”), a crime report is automatically generated by such specific
Virtual Citizen. The data coming from each report consists of the timestamp, the citizen coordinates, and eventually the type of crime and additional non-structured details, in terms of textual description.
Table 4 reports the temporal sequence of the data related to the crime reports generation.
In particular, the data in column “Crime Id” keeps on tracking who generated the crime report, whereas the generation time of the report is described in column “Report Timestamp”. In the column “User Coordinates” the location of the report are expressed through latitude and longitude. Additional data are provided through the other columns such as “Crime Type” and “Textual Description”.
It is worth noting that, as it is stated in
Section 4.2, both “Crime Type” and “Textual Description” are optional data. As a consequence, they are not used in the automatic computation process for the detection and tracking of criminals. However, if they are provided by the reporters, they can be afterwards analyzed from the LEAs to make off-line decisions, or elaborating statistic, such as the most popular crime type within a specific area, or in which period of the year a certain type of crime occurs most, and so on.
The crime reports generated from the citizens are used for the computation of the tracking points. As explained before, every time a new crime report is received by the system, a new tracking point is generated.
Table 5 shows the computation of three tracking points according to the temporal receivement of each crime report of
Table 4. In particular, in the column “Tracking Point Id”, the identifier of a tracking point is reported, whereas the column “Id Valid Crime Report” shows the valid crime report set
usd to to compute the tracking point under consideration. The columns “Generated Location” and “Reference Time” report the spatial and temporal value assigned to the calculated tracking point, as explained in
Section 4.3.
For example, the first Tracking Point with Id = “@01” coincides exactly with the information coming from the first report, that is, the Generated Location are the Users Coordinates and the Reference Time is the Report Timestamp. The Tracking Point with Id = “@02” is computed when the second crime notification is generated. In this case, this tracking point is computed by exploiting the data of the last notification and the previous one, because both of them have been generated within the
Time Window that is set equal to “10 min”. The Reference Time is always the Report Timestamp of the last crime report, whereas the Generated Location is calculated as the mean value among both the User Coordinates related to their crime reports. The Tracking Point with Id = “@03” is generated when the third Crime Report is received. As it is shown in
Table 5, the Tracking Point with Id = “@03 ” is computed only using the Crime Report with Id = 02 and Id = 04, as stated in the “Id Valid Crime Report” list. This is because the data gathered from the Crime Report with Id = 01 is considered already old, as it does not fall anymore within the Time Window. Consequently, it is considered obsolete/not valid, and then discarded for the computation of the next tracking point.
Table 6, instead, provides an extract of the Predicted Places where the information has to be sent in order to inform people about a potential threatening event coming. In particular, the prediction with Id = “#01” does not provide any important information as it is based on one single Tracking Point. Whereas both the prediction with Id = “#02” and Id = “#03”, as they are based on at least two Tracking Points, provide indications about the possible directions and, as a consequence, places towards the criminal is moving. For example, the indication gathered from the prediction with Id = “#03” is graphically shown in
Figure 10, where the tool is highlighting in red color the so called area or risk. Such information can be used both (i) to alert people around specific areas of the city about the potential threat and specifically the “Users in the Area of Risk”, and (ii) to improve the moves of the Police Forces by knowing in advance potential places and locations, called in the table “Place Information”, where a criminal might go.
Further evaluation has been conducted by assessing the real system in terms of user usability. We considered it is important to know people’s opinion and receive their feedback, as the ease of use of the crime notification system, in moments of panic, is of fundamental importance, to guarantee the effectiveness and the willingness to use this tool. This is the reason to keep it as simple as possible for making its use efficient and fast from the user perspective. To this aim, an user study has been conducted, by systematically examining the characteristics and behavior of the systems and services. The user study has been directly linked with the effectiveness (performance) and information services provided, as they aim at satisfaction of user needs.
In particular, the user study was carried out for the mobile application, by yielding qualitative indications on the goodness of the proposed system. The survey was conducted on a sample of 30 people between 18 and 50 years of both genders, by evaluating the following aspects: (i) Content and Navigation—the quality of being able to find content in a simple and intuitive way; (ii) Functionality—the quality of being suited to serve a purpose well; (iii) Look and Feel—the quality of the graphical user interface and aspects of its design, including elements such as colors, shapes, layout, and typefaces, as well as the behavior of dynamic elements such as buttons, boxes, and menus; (iv) Response Time: the total time that the system takes to react to a given input, such as loading data as well as sending a request; (v) Stability—which is a measure of the repeatability of a test over time, that gives the same results whenever it is used.
Figure 11 shows the mean value for each of those aspects (i.e., 4.7, 3.8, 3.0, 4.1, and 4.9), by highlighting a qualitative assessment, more than positive. In fact, not only the lowest mean value is greater than 3.0 (i.e., Satisfactory), but the average of all values is 4.1, which means better than Good.
Furthermore, based on the availability of statistical results (i.e., location detection time of the crime and intervention time) [
58,
59] related to four well-known cities (i.e., San Francisco, Houston, Los Angeles, and New York) with a crime rate between 50 and 65 according to [
60], the advantage in terms of intervention time, gained from the PFs by using the App, has been estimated. Whereas Darmstadt was not included in this estimate as it has a low crime rate, equal to 26.05, and data regarding the crime location detection time and response time is not available.
As it is represented in
Figure 12, the overall response time of the PFs is in average more than 5 min. It depends from the total time to reach the crime scene (depicted in green color), and it is strongly impacted from the Location Detection Time (depicted in red color), which takes at least 3.5 min to be identified. By using the location received through the app (depicted in blue color) the information about the crime scene is automatically gathered on the basis on the speed of the network and, as a consequence, it is detected in few seconds. Consequently, the overall response time decreases, as it mainly depends only from the time to physically reach the crime scene.
As it is represented in
Figure 12, from the analysis conducted by using the data of the above cities, for each city the intervention time would be reduced by about 3 min (as it is highlighted in gray color). In addition, by considering the worst case, that is given by the difference between the overall Response Time in New York using the App and the Total Response Time in San Francisco without App, it is more than 2 min, which might have a significant impact on real life in terms of human safety.