FLOOD ALERT SYSTEM via SMS (FASvSMS) MOHD FADZIL BIN MD ARAP This report is submitted in partial fulfillment of the requirements for the Bachelor of Computer Science (Computer Networking) FACULTY OF INFORMATION AND COMMUNICATION TECHNOLOGY UNIVERSITI TEKNIKAL MALAYSIA MELAKA 2007
ABSTRACT Flood Alert System via SMS (FASvSMS) is a real-time system that is developed to provide SMS alert to residents whom living in flood-risks areas. FASvSMS require the administrator to register ill the residents whom living in the flood-risks areas and make reports for future references. The user must press the button to send an alert to residents while the resident can register their application using SMS technology for immediate registration. The system will determine the received SMS and registration will be done the user. Residents will receive an alert if the flood may happen in their areas.
ABSTRAK FZood Alert System via SUS(FASvSMS) adalah satu sistem yang berjalan mengikut masa sebenar akan dibangunkan untuk menyampaikan mesej berjaga-jaga dalam bentuk khidmat pesanan ringkas (SMS) kepada penduduk yang menetap di kawasan berlakunya bencana banjir. FASvSMS memerlukan pentadbir sistem untuk mendah sernua penduduk tersebut dan membuat laporan untuk rujukan di masa hadapan. Para penduduk boleh mendaftarkan permohonan mereka untuk menerima peringatan dari sistem melalui SMS. Sistem akan mengenalpasti samada SMS itu boleh didaftarkan ataupun tidak. Jika permohonan tidak berjaya, sistem akan menghantar SMS untuk memaklumkan penduduk bahawa mereka tersalah maklumat yang diperlukan. Penduduk akan menerima peringatan dari sistem jika di kawasan itu menunjukkan tanda-tanda banjir.
CHAPTER I INTRODUCTION 1.1 Project Background The deadly tsunami and recent floods has showed how important it is to alert public about natural disaster threats. Considering the fact that mobile phone is a device which we keep close to us at almost all time, it has become a perfect tool for all sort of alert systems and provides method of quick alert distribution to the public. Overall this technology has such a huge potential, that it is very quickly adopted in many countries. A GSM operator in Sri Lanka was already able to provide ongoing emergency information to its subscribers, to give news updates, to direct people to supply and distribution centers and even to arrange donation collections. Benefiting on a wide coverage of GSM networks, a lot of things can be done. In Japan, cellular phone companies provide immediate notification of earthquakes and other natural disasters to their customers and in the event of an emergency, disaster response crews can locate trapped or injured people using the signals from their mobile phones. In New Zealand employees of an electricity distribution company receive alerts about fire threats to power lines via SMS. Dutch government uses cell broadcast to alert public about floods while for IT administrators worldwide are using SMS to alert them about problems with their systems, hacking attempts, virus attacks and helping them to quickly know about the problem and immediately take actions.
1.2 Problem Statement(s) There are several issues that always discuss from the street-wise people to politicians. The problems that issues are: The flood may costs hugely without any alert warning from the Authority that suppose to provide information about prediction of flooding. There is no system that stored the database of residents. The method of alerting residents not too practical to implement in some of places and sometimes the device that could be used may not affordable to some of person. 13 Objectives The objectives of this project are: To develop an alert system that could be used to residents who living in the floodrisk areas. To create a report based on the level of flood warnings. To send a warning message to the residents via Short Message Service (SMS). 1.4 Scope Login module This module is to verifj the user before use. The login module will determine only the authorized personnel can access into the system.
Registration module This module is to allow user to register the resident and the user of system. The resident also can register their account using SMS. Report module This module will provide the spaces for new reports based on the real-time system and provide the form for printed document. SMS system module This module will send alerts about the flood warning to the registered residents via Short Message Service (SMS) and it can send the confirmation, receive the SMS for resident registration and responses to the resident if their application successful or not. 1.5 Project Significance The system will be going to help the community to have better preparation to face disaster like flood. The flood will costs hugely to the communities and country. So with this application, the costs will reduced and many lifers can survived. This application will communicate with the SMS provider to send alerts to the residents. The reasons of using the SMS as a medium communication between application and the residents are its easy to use and more effective way compared to email services or mass media announcements.
1.6 Expected Output The expected outputs fiom this application are the alerts via SMS and the reports which are provided by the officer in charge. The alerts have 3 level of flood warning which is Alert, Beware and Danger. This application may help the residents to have better preparations to face flood while the authorities will get ready with an emergency situations and the medical helps. 1.7 Conclusion As conclusion, the Flood Alert System via SMS will be developed to make some changes to reduce costs, save lifers and avoid huge damage because of flood. This application will be implemented to some areas that have risks to floods. From this chapter, the problem statement, objectives, scope, project significance and expected output are being identified in order to develop the application that will be used by the target users. After finishing this chapter, it will bring to the second chapter that is the literature review and project methodology.
CHAPTER I1 LITERATURE REVIEW AND PROJECT METHODOLOGY 2.1 Introduction This chapter will discuss about literature review and project methodology of the related project. Literature review is a collecting related data, analyze business processes, identi@ underlying patterns and create the conclusion. The project methodology means technique and type use to complete the project. In order to develop a successfhl project, the current systems are collected. Three related of Flood Alert System are searched and analyzed which are LISTFLOOD ALERT, Flood Control District of Maricopa County and CASA Flood Alert System for Houston Using NETRAD. Studies of these systems are significant to develop a valid, reliable and efficient system. Flood Alert System will be using is a System Development Life Circle (SDLC). Methodology is very important in developing the web based system. Choosing a right methodology will help to produce a better quality product, in terms of documentation standard, acceptability to the user, maintainability and consistency of software.
2.2 Facts and findings This section will be discussing about the domain of this project, the existing system and finally the other techniques that applicable used in to develop this project. 2.2.1 Domain The domain of this application is new networking and security alerts that can benefit the community who's living at the flooding area-risks. This application will connect to the device for water measurement and it will analyze which level that the risk is. This application will be designed to fulfill the needs because of many reasons. Therefore, the system may save many lifers, properties, businesses and reduce of costs that caused by the flood disaster. The SMS will be used as the human-machine interaction because of efficiency and well-known technology that can be used widely. The community will received the alerts via SMS which is more practical than e-mail. Generally, the community may have own mobile phone, so they will get the updates from the application. The SMS text messaging offers an accessible and cost effective facility for the general public to communicate with the council. The list of benefits to adding the technology to send and receive SMS into the public is endless.
2.2.2 Existing System The examples of existing systems are LISTFLOOD ALERT, Flood Control District of Maricopa County and CASA Flood Alert System for Houston using NETRAD. The details about the hnction and features are as:- 2.2.2.1 LISTJ?LOOD ALERT This application will be complete by 2008 and it will used at certain area in Europe. This application needs some changes that can relate to the latest technology such SMS and email to alert communities and the Authority Officer to take actions. This system will involve the following four stages: Data Collection: The National and Regional Public Water Authorities will feed structured data to a central notification management system or digital database, located at the Global Runoff Data Centre in Koblenz, Germany. The Joint Research Centre will also be given access to the management system. Data Exchange: The National and Regional Public Water Authorities will transfer near real-time structured data electronically. The data will be processed locally and converted to an agreed business message format. Compressed Data Dissemination: The dissemination of structured hydrological data will take place on demand from the Public Water Authorities, via normal security sharing. There will be no shared areas for collaborative editing or similar. Once the data is collected andlor exchanged, a plausibility check will be run by the GRDC. The resulting data could be disseminated again to the original senders (Public Water Authorities) upon request. Alerts: Email-based flood alerts will be sent out with moderate or high urgency to the Public Water Authorities and DG Environment, according to an agreed structured message and digitally signed by the sender. In the case of a potential flood being predicted, secured alert messages will be sent to
DG Environment and the relevant National andlor Regional Public Water Authorities in the Member States. 8 2.2.2.2 Flood Control District of Maricopa County The Flood Control District of Maricopa County operates a 24-hour rain, stream and weather gage network, which provides "real time" information to the County and many other agencies about rainfall, storm water runoff and weather conditions in Maricopa County Data collection: The ALERT system uses "automatic" telemetry gages for data collection. This means that the gages transmit their information to the District base computers via VHF radio. The computers then quickly compile the information and display it on video screens. The automatic gages are powered by 12-volt batteries, which are recharged using small solar panels attached to the top or sides of the gages. Water Detection: The information provided by the ALERT system is important to the District because occasional heavy rainfall can generate stream flows which significantly impact flood control facilities such as dams and channels. Each gage is programmed with an alarm setting. The alarm is sounded when the measurements reach a certain threshold and the on-call hydrologist evaluates and monitors the situation. Alerts: Flood warnings are provided to District observation teams, other County departments, city emergency management departments, and the National Weather Service. Public flood warnings and other weather advisories are issued by the National Weather Service. Emergencies are declared by the County Emergency Management Agency. The agency will send alerts to the mass media to inform all the residents to take actions.
2.2.2.3 Flood Alert System in Poyang Lake, East China. This system developed to fight against the flood losses which are 400 buildings surrounding the lake were inundated, leaving more than 1 million people homeless and causing economic losses of more than 30 billion yuan (3.6 billion US dollars) during the devastating 1998 floods. Detector devices: The latest optic-fibre and satellite communication technology and facilities will be used for the system. Data Processing: The system would automatically collect information regarding rainfall, water level, danger situations and possible disasters, and then analyze the data in reference to past cases to offer proposals to effectively prevent flooding. Alerts: The system will send alerts to the authorities to take actions and announce to public. 2.2.3 Technique GIs is a collection of computer hardware, software, and geographic data for capturing, managing, analyzing, and displaying all forms of geographically referenced information. A geographic information system (GIs) is to locate a data, such as people to addresses, buildings to parcels, or streets within a network. GIS can integrate and relate any data with a spatial component, regardless of the source of the data. For example, the combination the location of mobile workers, located in real-time by GPS devices, in relation to customers' homes, located by address and derived fiom the database. GIS maps this data, giving dispatchers a visual tool to plan the best
routes for mobile staff or send the closest worker to a customer. This saves tremendous time and money. 10 23 Project Methodology The project methodology used for developing this system will be System Development Life Cycle (SDLC). This methodology was chosen because it fits the approach for developing the system which relies on techniques that produce deliverables intended. SDLC presents guidance for selecting appropriate methods, techniques and tools based on the specific requirements for the project. With this approach, project is desired to move consecutively according to steps planned for each phase. The phases involved for this project are requirements planning, analysis, design and implementation. a) Planning In the planning phase, first of all, the project is identified. Once the project is identified, data is collected and requirements regarding the project are gathered. At this point, a lot of research is needed to be done for obtaining ideas on how to implement the project and gathering requirements to hlfill the project needs. Information from current existing system is studied; for example, methods available for current switch configuration and what are the advantages and disadvantages for the existing method. With that, research is done to find if any improvement can be done to provide a better system. The most important thing to be planned is the time schedule for developing the project. This is vital so that milestones and deliverables can be delivered on time. Apart from that, the planning phase involves to know how the system is going to be developed and why the system is to be built. Tasks are identified along with scope and objectives of project.
b) Analysis In the analysis phase, an analysis of the current system and its problems are done. This is known as the real-time system. In this phase, the business requirements are also gathered. Analysis is also done to ensure who, what, when, and where will the system be. Problem analysis and requirement analysis is also studied in depth in this phase. c) Design There are several things that are designed in this phase. The first is the architecture design. This includes network infrastructure, hardware and software selection. Next is the interface design that will determine how users will move through the system. For example, by using navigation methods such as menus, forms and on-screen buttons. In this phase, the program will also be defined; what program needs to be written and what each program do for the system. All this will lead steps to determine how the system will work. d) Implementation The implementation phase is the critical and final phase in SDLC. It involves programming to generate the actual system, and a series of tests to ensure that system is well working. Among the tests are Unit Testing, Integration Testing, System Testing and User Acceptance Testing. Once system is working as intended and the test results are as expected, then the system is ready for use.
2.4 Project Requirements This section will briefly explain requirements needed to develop this application. It includes software requirements, hardware requirements plus additional side requirements. 2.4.1 Software Requirement Software is used for many purposes in this project. Different software is used for different tasks. Some of them are used as the pre-requisite and some of them are used to build the system or the project itself. The software requirements for Flood Alert System are: Development tools o Microsoft Visual Basic 6.0 o Microsoft Visio 2003 o Microsoft Project 2003 o Microsoft Word 2003 Operating System 1 server o Microsoft Windows XP Database system o Microsoft Access 2003
2.4.2 Hardware Requirement Hardware is the device used in order to build or aid the development of the project. Basically, since the project is mainly about the disaster of flood on alert SMS system; the hardware requirements are not too hard to get. The minimum requirements are as follows: Table 2.1: Hardware Requirements No. 1. 2. Hardware Requirements Computer Processor : Intel Pentium or compatible 166 MHz or Server higher Memory : 128MB or higher Hard Disk :Capacity of 20GB or higher GSM Modem Brand : Itegno integrated with SMS API v3 Port : USB 2.4.3 Other requirements The list of hardware requirement for this project is listed below: GSM coverage. 2.5 Project schedule and Milestones This section will provide the schedule and milestones for this project. The project schedule is as shown in the table below. Gantt chart is one of the effective methods used to outline the project plan. Gantt chart for this project is shown in Appendix A.
Table 2.2: PSM Milestones Num. Milestones Duration Start Date End Date 1. Selecting project title and 2 days 9/5/2007 10/5/2007 supervisor 2. Submit proposal to supervisor 1 day 1 1/05/2007 1 1/05/2007 approval 3. Plan the project 4 days 15/5/2007 1 8/05/2007 4. Gather Information for Chapter 1 : 2 days 15/5/2007 16/05/2007 Introduction 5. Determine contents for Chapter 1 3 days 1 6/05/2007 1 8/05/2007 6. Gather Information for Chapter 2: 2 days 2 1/05/2007 22/05/2007 Literature Review and Project Methodology 7. Determine content for Chapter 2 3 days 22/05/2007 24/05/2007 8. Submit Chapter I and Chapter 2 1 day 25/05/2007 25/05/2007 9. Analysis problem statement 2 days 04/06/2007 05/06/2007 10. Analysis system requirement 2 days 05/06/2007 06/06/2007 1 1. Determine and' priority system 3 days 05/06/2007 07/06/2007 requirement 12. Submit Chapter 3: Analysis 1 day 08/06/2007 08/06/2007 13. Gather information which is 2 days 1 1 10612007 12/06/2007 needed to develop FASvSMS. 14. User Interface Design 3 days 12/06/2007 14/06/2007 15. Submit Chapter 4:Design 1 day 15/06/2007 15/06/2007 16. Finalizing PSM 1 Report 5 days 18/06/2007 22/06/2007 17. PSM 1 Presentation 5 days 25/06/2007 29/06/2007 1 8. Detailed Design :Chapter 4 5 days 23/07/2007 27/07/2007 19. Submit Detailed Design 1 day 03/08/2007 03/08/2007
20. Gather information that correlates 14 days 05/08/2007 1 9/08/2007 GSM modem connected with the application. 2 1. System implementation 14 days 20/08/2007 30/08/2007 22. Submit Chapter 5 1 day 6/09/2007 06/09/2007 23. Planning system testing 5 days 10/09/2007 14/09/2007 24. Testing system and error handling 14 days 17/09/2007 01/10/2007 25. Submit Chapter 6: Testing 1 day 05/1012007 0511012007 26. Performers and progress project 5 days 01/10/2007 0511 012007 evolution 27. Complete and submit PSM 2 final 1 day 221 1012007 2211 012007 report 28. Present Project 5 days 2211 012007 2611 012007 2.6 Conclusion As overall this chapter, the fact and finding, domain, existing system, technique, project methodology, project requirements and project schedule are identify and completed doing the researches. Next chapter will identify about design which are the High-level design and database design. In the High-level design include system architecture, user design interface, navigation design, input design and output design. Database design will identify about conceptual and logical design, detailed design, software specification and physical database design.
CHAPTER I11 ANALYSIS 3.1 Introduction In this chapter will be elaborate about problem analysis and requirement analysis. Analysis involved a detailed study of the current system, leading to specifications of a new system. Analysis is a detailed study of various operations performed by a system and their relationships within and outside the system. During analysis, data are collected on the available files, decision points and transactions handled by the present system. Interviews, on-site observation and questionnaire are the tools used for system analysis Besides that, we can know deeper about the operation in the organization. Through this analysis also can help to determine problems face by users. Due to this point, the system will be designed for the purpose to solve the user problems. Besides that, requirement analysis is very important to make sure that the system developed implement well in the real environment. Hardware and sorware requirement play an essential role in developing the system. Without identify the requirement clearly, the system will not function properly in the real environment. The requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users. Requirements analysis is critical to the success of a project.
3.2 Problem analysis To develop a system must be going analyze user requirements and investigate scenario of the current system to identify the problems. The problem identified will have to analyze for make a solution. 3.2.1 Background of the current system Currently, there is a system in Europe that still in progress to alerting residents. But the only problem with the system is the method of alert which is not too efficient for Malaysian community. They are using e-mail which is not many users use it mobility. Therefore, the new system will connected to SMS server for alert residents, so the residents and the authority can take further actions. 3.2.2 Data Flow Diagram (Dm) of The Current System Data flow diagram is a technique which is the business processes and the data passes among them. The focus is mainly on the processes or activities that are performed. Context Diagram of the Flood Alert System via SMS. A context diagram shows the entities or actors that are involved with in the system and its data flow. Below is a Context Diagram of the Current Flood Alert System via SMS in Figure 3.1.
RESIDENTS FLOOD ALERT SYSTEM Alert Messages via emails REPORT MAKER Figure 3.1: Context Diagram of Current System (LISFLOOD ALERT) 3.23 Problems of current system The development of this application is taken ahead after analyzing few problems as stated below. Email as alert provider. This system will be added new type of alert which is more efficient compared to e-mail. The SMS will provide fast and sharp alert to residents while the residents easy to receive it. No database of the resident. The current system cannot send the alert to resident because they do not have a certain database for certain residents. The Registered residents will get alerts sending fiom the system.
No report based on flood. The current system does not have s function to save the report which is needed for future references. 33 Requirement analysis The requirement of the system will be described in terms of data requirements, functional requirements, non-functional requirements and other requirements. The requirement will base on Appendix B. In the Appendix B, the topology will show 3 areas which are Area I, Area 2 and Area 3. For whom living in outside the area, they will receive an alert fiom neither Area 1 or Area 2 or Area 3. 33.1 Data Requirement The data requirements for Flood Alert System via SMS are: Table 3.1 Data Requirement Data Description Registered Residents First Name Last Name IC number Phone Number Address Postcode Identity number of resident Resident's name Resident's identity card number Resident's cell phone number Resident's mail address To determine area.
20 SMS System Report Phone Message Datemime Datemime Level of warning Report Phone number from received number. Message text from the resident Date and Time received. Real-time date Alert, Beware and Danger message Description based on situations. 33.2 Functional Requirement Flood Alert System via SMS will develop to be a center of information relating flood disaster, manage data and alert the residents by sending warning messages. The system will determine which area that will be shown in Appendix B. The system will send alert automatically when the water achieve the surface of warning. Login module This module is to register resident account for receiving alerts from the system. Registration module This module is to register resident account for receiving alerts from the system. This registration can be done by the resident via SMS. Report module This module allow user to create a report for the future references. SMS system module The user will select the area and the type of alert while the resident can register their application using SMS. The system can received the SMS and send it back to the resident
3.3.2.1 Data Flow Diagram (DFD) of To be Developed The new system to be developed is use by an administrator to monitor the system, register the residents and making a report on situation that happened in short and easy understanding. report Register user Register residents * v 0 -- - - - - - Level of waming- Sending an alerts -- --List of registwed residents-- FLOOD MANAGEMENT SYSTEM --Register via SMS-+ A A -- - - '-List of registered residents----" - reportrt Figure 3.2: Data Flow Diagram (DFD) to be developed
P -Register resident -Register user - h 1.0 REGISTRATION. I \ b Register resident detail- User Administrator Register detail 2.0 LOGIN Resident Colled data I Register Jser Produce reporl '' - 7 3.0 REPORT Residents A 4.0 SMS SYSTEM -Receive alerts ALERT SERVICES Figure 33 Data Flow Diagram level 0 Flood Alert System via SMS
ust of registered r e s i d e ; 7 T Residents Administrator A REGISTRATION -Registeratiion irbmatm Register b C Resident Register residents Register resideill SMS System Figure 3.4: Data Flow Diagram level 1 Registration module Register user Administrator 2.0 LOGIN Register user verification Figure 3.5: Data Flow Diagram level 1 information module
Administrator A Produce re+: b 3.0 REPORT I Report saved Report display v Report Figure 3.6: DFD level 1 Report module Residents ALERT SERVICES Send Alerts via SMS Send level of warning Reports Figure 3.7: DFD level 1 SMS system module