Transportation_Info_system_report.pdf - Divyansh Singh, Akshay Kumar Gupta

Please enable JavaScript to view the full PDF

Transportation Information System Project report submitted in partial fulfillment of the requirements for the degree of Bachelor of Technology in Computer Science and Engineering by Divyansh Singh - 16UCS062 Akshay Kumar Gupta - 16UCC011 Under Guidance of Dr. Rajbir Kaur Department of Computer Science and Engineering The LNM Institute of Information Technology, Jaipur December 2019 Copyright c The LNMIIT 2017 All Rights Reserved The LNM Institute of Information Technology Jaipur, India CERTIFICATE This is to certify that the project entitled “Transportation Information System” , submitted by Divyansh Singh (16UCS062), and Akshay Kumar Gupta (16UCC011) in partial fulfillment of the requirement of degree in Bachelor of Technology (B. Tech), is a bonafide record of work carried out by them at the Department of Computer Science and Engineering, The LNM Institute of Information Technology, Jaipur, (Rajasthan) India, during the academic session 2019-2020 under my supervision and guidance and the same has not been submitted elsewhere for award of any other degree. In my/our opinion, this thesis is of standard required for the award of the degree of Bachelor of Technology (B. Tech). Date Adviser: Dr. Rajbir Kaur Dedicated to My Family and Friends Acknowledgments The success and results of this project required guidance and help from many people, and we are honored to have it all with the completion of our project. We are very grateful to our project supervisor, Dr. Rajbir Kaur, and co-supervisor, Dr. Preety Singh, for guiding us through the project, providing all the necessary information required to complete the project. I am grateful and fortunate to have received the encouragement, support and guidance of all the faculty and staff of the Computer Science and Engineering Department. In addition, I would like to extend my sincere gratitude to the laboratory supervisors for their quick support. v Abstract Development of transport information system to monitor the activities within the a give public trans- port to ensure safe travel for women and children. Public transports fitted with an array of sensors that procure relevant data to ensure safe traveling conditions for female and child passengers. This project constituted of two modules to achieve the above objective, a mobile application, and a control center. The control center consists of an application that helps in monitoring activities inside different public transports. The onboard system on the vehicle continuously monitors the vehicle for any suspicious behavior. Upon detection of any suspicious activity, the communication module on the vehicle sends an alert to the control center along with the video feed. The control center receives the alert and prompts the operator assigned to the control center to investigate and take necessary action. The mobile application helps users in tracking buses, checking availability, checking schedules to ensure hassle-free traveling experience. This application can also be used to report any suspicious activity that a passenger may observer via a panic button mechanism that alerts the operator at the control center. vi Contents Chapter Page 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 The Area of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Problem Addressed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Existing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3.1 Mukti Bus Surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1 Web Server and Database Server . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1.1 Cloud Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1.2 Database Management System . . . . . . . . . . . . . . . . . . . . 2 2.1.1.3 Cloud Hosting Service . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.2 Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.3 Video Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.4 Activity Alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.5 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Control Center Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Centralised Tomcat Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.0.1 Prototype of API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Distributed Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Real Time Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4.1 Content Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4.2 Background Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 Video Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6 Android Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7 Authority Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.8 Control Center Web Portal User Interface . . . . . . . . . . . . . . . . . . . . . . . . 8 3.9 Authority Web Portal User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.10 Android Application User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1 Scope of further work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1 Video Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 vii viii CONTENTS 4.1.2 Authority Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.3 Centralised Tomcat Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Chapter 1 Introduction 1.1 The Area of Work The transport information system is software that monitors activities in a given public transport to ensure the safety of women and children. This software consists of a mobile application that allows users to track transport vehicles and check their schedules and availability. The mobile application also helps in ensuring the safety of aboard female passengers. The software also provides a mechanism to alert relevant authorities via the control center. 1.2 Problem Addressed In recent times public transportation has proved to be extremely unsafe for women and children. Numerous complaints of quarrels between passengers, intoxicated drivers, eve-teasing, kidnapping are registered every day. Furthermore, women avoid traveling in a public transportation because of safety concerns due to unchecked environment variables like abusive passengers, deserted routes, poorly lit buses. We devise a surveillance system to check these environment variables and ensure a safe, hassle- free traveling experience. 1.3 Existing System The only government enabled systems to ensure female safety are the female transportation vehicles and the quick response dial 100 police vehicles. However there are few private surveillance systems that provide live video feed from the bus. 1.3.1 Mukti Bus Surveillance Mukti is a private company that use their Ambi cam to monitor a bus. They provide real time video surveillance only therefore fail to provide real time alerts in case of a suspicious activity occurs. 1 Chapter 2 Literature Survey 2.1 Introduction 2.1.1 Web Server and Database Server 2.1.1.1 Cloud Web Server For the webserver, an Apache Tomcat server is used to host a java servlet. Tomcat is a very lightweight and fast application due to a lack of sophisticated features as compared to other options available which leads to faster deploy cycles. Tomcat is also open source and very extensively docu- mented making it easier to develop an application in tomcat. Tomcat is one of the oldest servers available and has been heavily optimized in various revisions resulting in one of the most stable servers available. 2.1.1.2 Database Management System For database management, we used MySql because of its scalability and stability. MySql was also the most feasible choice because it was open source and could be readily integrated with the java servlet and hosted on Amazon RDS (Relation Database Service). 2.1.1.3 Cloud Hosting Service To develop the transportation information system required a cloud hosting service for which we used Amazon web services. Amazon web services provided hosting of tomcat servers which could easily be integrated to MySql server also running on Amazon. Other hosting services like Digital Ocean did not provide enough memory in affordable plans for our system to run smoothly. Amazon also allowed us to easily update our running server reducing the considerable time required to sync the server to updated code. 2.1.2 Control Center To develop the Control Center, we used Node.js to host the Web server. There are many options for developing web applications, but Node.js is best suited for real-time applications. Compared to 2 traditional multithreaded Java or ROR frameworks, single-threaded event-driven systems are fast, even if they handle a large number of requests at the same time. Node.js is ideal for applications with a large number of concurrent connections, and each request requires very few CPU cycles because the event loop (along with all other clients) is blocked during the execution of the function. Using a technique called ”long polling”, you can write an application that sends updates to users in real-time. Long- term polling of many Web giants, such as Ruby or Django on Rails, can create a huge load on the server because each active client consumes a server process. This situation is equivalent to a tar attack. When using things like Node.js, the server does not need to maintain a separate thread for each open connection. 2.1.3 Video Streaming The video stream sent from the vehicle is routed through a socket client. To make the socket server we used a Java socket server running on the machine also hosting the Node.js control center server. The socket server can be implemented on any language but due to the very descriptive and easily available documentation available, Java was used for this purpose. 2.1.4 Activity Alert In case a suspicious activity is detected the web portal should automatically alert the operator and open the details of the bus in question. To achieve this functionality we needed to formulate a mechanism that operates on the front end of the web application. Any front end manipulation is not possible from the web server, therefore, we used browser extensions to execute scripts if an alert is triggered by a vehicle. Another solution to this problem was to open a socket server at our web server and open a client at the front end of the application however this mechanism will operate only when the web portal is active on the operator’s browser however extension will work irrespective whether the operator has an active tab running the application. 2.1.5 Mobile Application The Transport management mobile application was built using the standard IDE for android appli- cation development, Android Studio. To display the real-time location of buses and routes that the bus takes Google’s map API and routes API was used. Google was one of the leading map providers and facilitated seamless integration with the android application. Google also provides users the opportunity to use a different set of API’s along with the maps API to make integration between different features easy. Google maps also have the most landmarks making it easier to use. The routing API works with the maps API to show routes between different landmarks without the need for new code to achieve this functionality. 3 Chapter 3 Methodology 3.1 Control Center Architecture The following diagram is how the Transport information system is implemented. Figure 3.1 Control Center work Flow Two separate servers are used instead of one to make the control center. The first server is a cloud tomcat server and the second server a Node.js server. Two different servers are used to decouple the input raw data and the video feed. The control center should be capable of handling a cumbersome amount of video feed which results in a lot of processing power being spent to receive and route these video feeds to the front end. To make sure the system does not bottleneck due to video feeds we decoupled the video feed and the other raw input. 4 3.2 Centralised Tomcat Server The Tomcat server handles and processes all the raw input and stores them to the database. It also provides an array of APIs to access this stored data to any of the multiple control center’s possible. All the suspicious activity alerts are also handled by the Tomcat server and routed to the relevant control center. All the bus initializations are also automatically handled by the tomcat cloud server. 3.2.0.1 Prototype of API Following is the emergency API that the controller hits in case suspicious activity is detected. All the other APIs use similar prototypes. Figure 3.2 API requests Several APIs were created keeping to cater to the needs of the control center and other modules like the recommender system. This centralized server offers the following APIs, 3.3 Distributed Control Center The Node.js server hosts the web portal and receives all the video feed. Node.js server also has a socket open that communicates to the browser extension that prompts the alert in case suspicious activity is detected. 5 Request Name Request Type Get Vehicle POST Create Vehicle POST Update Vehicle POST Initialize Vehicle POST Terminate Vehicle POST Live Status GET Report Emergency POST Escalate Emergency POST Resolve Emergency POST Get Location POST Set Location POST Update Location POST Create Routes POST Get Route POST Update Route POST Get Subroute POST Create Subroute POST Get User POST Set User POST Authorize User POST Table 3.1 List of APIs This mechanism helps us to avoid any bottleneck that might occur due to heavy input of video feeds, it also allows us to expand the system to multiple control center without the hassle of creating and hosting new databases because they are hosted centrally at the tomcat server. 3.4 Real Time Updates In case the Control Center is alerted, the web application needs to prompt the operator into action by opening the details of the bus in question. To implement this feature we need a tool that can manipulate the front end of an application. To do so we developed a browser extension that communicates to the Node.js server via a socket. A browser extension can manipulate the front end of an application via injecting a script into the HTML document. An extension runs two scripts: 3.4.1 Content Script Content Script have access to the DOM of the web page and can read, write, execute scripts in the HTML document. 6 3.4.2 Background Script Background scripts are listeners and listen for different events that can occur on the web site. A web socket client is active in the background script waiting for the server to send a message in case the server receives an alert from a vehicle. Upon receiving an alert from the server the background script shows an alert and opens a new tab containing the bus detail page of the bus in question and executes a content script on that page. Figure 3.3 Extension Work Flow 3.5 Video Feed A Java Socket Server is running on the machine hosting the web portal. The socket server receives a video stream from the bus and streams it in the bus detail page of the bus. Figure 3.4 Video Streaming Work Flow 7 3.6 Android Application The development of an android application was done using the standard IDE android studio. The an- droid application also uses the APIs provided by the centralized Tomcat server to list the bus schedules. The android application uses Google Maps API to track buses and Google Routes API to show the bus routes. The android application also implements a panic button feature where users mark themselves as passengers on a given bus by pressing the ride button available on the details page of the given bus, upon doing so they receive a notification where the get the option of pressing emergency which alerts the control center that suspicious activity has been observed by a user. 3.7 Authority Portal The operator at the control center can investigate an alert and upon determining it as suspicious he can escalate the alert to a relevant authority. The operator at the authority portal can view all the escalated cases and after taking necessary action and can mark the issue as resolved after which the system assumes that the bus conditions are now normal. Figure 3.5 Feedback Activity 3.8 Control Center Web Portal User Interface Following is the user interface for the control center web application. 8 Control Center Dashboard Bus Details 3.9 Authority Web Portal User Interface Following is the user interface for the authority web application which is the same as control center, but with the functionality to resolve issues. 9 Figure 3.6 Feedback Activity 3.10 Android Application User Interface Following is the interface for the android application. 10 Figure 3.7 a) Search Activity b)Bus Schedule Activity 11 Figure 3.8 a) Panic Button b)Feedback Activity 12 Figure 3.9 Bus Details Activity 13 Chapter 4 Conclusions and Future Work Using a mixture of various technologies we were able to create a real-time surveillance system that could significantly reduce the response time of authorities if suspicious activity occurs inside a bus. The system is scalable to multiple control centers due to the two server architecture that has been imple- mented. 4.1 Scope of further work The architecture of the system is put in place some areas where further optimization are possible are, 4.1.1 Video Streaming The Java socket server can be optimized to reduce the latency of the video feed, this can be achieved by opening another socket client at the Node.js server and sending the stream to the Javascript socket client, however as of now the Socket.io API used to create socket in Node.js server are incompatible with Java’s Socket server, therefore and interface has to be created to perform this optimization. 4.1.2 Authority Portal Like the Control Center, the authority portal also needs an extension to make sure the operator at the authority portal gets updated in real-time. This extension can be implemented in the future. 4.1.3 Centralised Tomcat Server The Tomcat server is made such that it supports cloud processing which allows shifting all the on- board processing to the cloud. This would significantly reduce the cost of hardware that needs to be installed on the bus and can reduce the latency of alerts. 14 Chapter 5 References 1. “Node.js Documentation” [Online]. Available: https://nodejs.org/en/docs/ 2. “Tomcat Documentation” [Online]. Available:http://tomcat.apache.org/tomcat-8.0-doc/ 3. “Java Documentation” [Online].https://docs.oracle.com/en/java/ 4. “Chrome Extension Documentation” [Online]. Available:https://developer.chrome.com/extensions/devguide 5. “Socket.io documentation” [Online]. Available:https://socket.io/docs/ 6. “Android Documentation” [Online]. Available:https://developer.android.com/docs 7. “Firebase Documentation” [Online]. Available:https://firebase.google.com/docs 8. “AWS Documentation” [Online]. Available:https://docs.aws.amazon.com/ 9. “Javascript Documentation” [Online]. Available:https://devdocs.io/javascript/ 10. Stack overflow, How to decide when to use NodeJs[Online]. Available:https://stackoverflow.com/questions/506261 to-decide-when-to-use-node-js 11. Mathew Davis,Reasons to use Tomcat, June 2014. [Online]. Available:https://www.futurehosting.com/blog/five- reasons-you-should-use-tomcat/ 12. Github Repository Control Center Web Portal: https://github.com/divyansh9711/Transport-ControlCenter Authority Web Portal: https://github.com/divyansh9711/transport-Authority Android Application: https://github.com/divyansh9711/TransportationManagement Activity Alert Chrome Extension: https://github.com/divyansh9711/transport-alertChromeExtension 15