## 2 Materials and Methods
### Method
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline  & **Backbone** & **AP** & **AP\({}_{\text{50}}\)** & **AP\({}_{\text{75}}\)** & **AP\({}_{\text{S}}\)** & **AP\({}_{\text{M}}\)** & **AP\({}_{\text{L}}\)** \\ \hline
**Two-Stage Methods** & & & & & & \\ Faster R-CNN++ & ResNet-101-C4 & 34.9 & 55.7 & 37.4 & 15.6 & 38.7 & 50.9 \\ Faster R-CNN w FPN & ResNet-101-FPN & 36.2 & 59.1 & 39.0 & 18.2 & 39.0 & 48.2 \\ Faster R-CNN by G-RMI & Inception- ResNet-v2 & 34.7 & 55.5 & 36.7 & 13.5 & 38.1 & 25.0 \\ Faster R-CNN w RDM & Inception- ResNet-v2-TDM & 36.8 & 57.7 & 39.2 & 16.2 & 39.8 & 52.1 \\ \hline
**One-Stage Methods** & & & & & & \\ YOLOV2 & DarkNet-19 & 21.6 & 44.0 & 19.2 & 5.0 & 22.4 & 35.5 \\ Ssd513 & ResNet-101-SSD & 31.2 & 50.4 & 33.3 & 10.2 & 34.5 & 49.8 \\ DSSD513 & ResNet-101-DSD & 33.2 & 53.3 & 35.2 & 13.0 & 35.4 & 51.1 \\ RetinaNet & ResNet-101-FPN & 39.1 & 59.1 & 42.3 & 21.8 & 42.7 & 50.2 \\ RetinaNet & ResNeXt-101-FPN & 40.8 & 61.1 & 44.1 & 24.1 & 44.2 & 51.2 \\ YOLOV3 608 \(\times\) 608 & Darknet-53 & 33.0 & 57.9 & 34.4 & 18.3 & 35.4 & 41.9 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: One-stage methods and two-stage methods AP. Figure 5: YOLOV3 performance comparison. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Backbone** & **Top-1** & **Top-5** & **Bn Ops** & **BFLOP/s** & **FPS** \\ \hline Darknet-19 & 74.1 & 91.8 & 7.29 & 1246 & 171 \\ ResNet-101 & 77.1 & 93.7 & 19.7 & 1039 & 53 \\ ResNet-152 & 77.6 & 93.8 & 29.4 & 1090 & 37 \\ Darknet-53 & 77.2 & 93.8 & 18.7 & 1457 & 78 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Comparison of backbones. images. When the CCTV test video is carried out on the Flask or Django server through the converted model, it detects a traffic accident or detects an obstacle. The architecture of the whole system in this study is presented in Figure 6. In Figure 6, the server consists of three parts. The server consists of a Flask server that stores the model produced through the model training process, a Django server that detects obstacles on the road, and a Django server that stores images detected as abnormalities. Because it is important to transmit information as quickly as possible during communication, FCM is used to transmit anomaly data. Because FCM puts a cloud messaging server in the middle, it has the advantage that users can send and receive messages quickly in real-time even with a low battery and weak network. However, since FCM makes it difficult to transmit images, HTTP is used to transmit abnormal images. Moreover, Web application uses Figma to create screen components and brings the components to Axure to implement screens and actions. Figure 7 shows the results of detecting anomalies. In this figure, a square box represents an anomaly object. Figure 7a shows a traffic accident using a traffic accident detection model, and Figure 7b shows an obstacle on the road  
In Flask and Django servers where the abnormality-detection model exists, CCTV images are executed in real time, and when abnormalities are detected as shown in Figure 6, information related to abnormalities is transmitted to the web application. The detected image is sent to another Django server through HTTP communication. The server that receives the image distributes the image into PythonAnywhere. After the image is delivered, it is set to store the image and information related to the image in the database. Figure 8 shows the screen of the created web application. To explain the operation sequence of the web application, enter the DRAS site and Figure 8a is the first screen. If you click 'Find Paths' here, a window for inputting the starting point and destination appears on the right, as shown in Figure 8b. If you input the starting point and destination and press enter, you can see a screen like Figure 8c. If the red CCTV is visible on the Figure 8c screen, this means that an anomaly has been detected in this CCTV. So, if you click this CCTV, the detected anomaly image is displayed.