Flood Warning System Group 6

Size: px

Start display at page:

Download "Flood Warning System Group 6"

Ashlee Maxwell
6 years ago
Views:

1 COMP 145 UNC Chapel Hill Contract I Flood Warning System Group 6 Submitted to: Stephen Tell and Prof. Greg Welch February 6, 2001 Alex Giouzenis Kevin Berry Ruigang Yang Ashes Ganguly

2 PREFACE This document is the first version of the Contract, to be delivered to the Client on February 6. It lists in a structured way the agreed-upon requirements of the project. The Client has one week to review this document and the team will deliver a revised version of the Contract on Feb Introduction The goal of this project is to develop a Flood Warning System that will be deployed near Little Creek, Chapel Hill. The upstream tributaries of Little Creek flood regularly and frequently damage Eastgate Shopping Center and Camelot Village apartments. Our client is Stephen Tell, who already has a camera setup at Little Creek near his house. s taken by the web camera would be analyzed and the water level of the creek would be estimated, both in daylight and at night. Web pages will be generated that will show the image, give a numerical estimate of the water level and an associated confidence metric. alerts would be sent out if the water level increases to dangerous levels. 2. User-Level Requirements Specifications A. User Interface C. Water Level Detection Flood Warning System D. Processing Lib B. Database E. Acquisition Figure 1: Context Model Diagram

3 Fiducial Template E. Acquired Raw D.1 Enhancement Enhanced D.2 Template Matching Enhanced + Fiducials + confidence value A.2 System Admin. System Config. B. Database Water level + confidence value System Config. C. Detect Water Level Database Query Raw image + Fiducials + Water level + Confidence values Report Request A.1 Report Generator Water level Report Figure 1: Process Model Diagram 2-A. User Interface It shall provide two sets of interfaces: (2-A.1) A web-based interface for graphical water-level reports; (2-A.2) A console-based interface for system administration and maintenance. 2-B. Database: An image and report database. It shall contain archives of past images and reports, and support simple database queries. 2-C. Water Level Detection It shall be able to detect water level with some known and fixed fudicials in the images. The fiducials are a white striped yardstick for daytime, and a LED stick for nighttime. Some confidence measures shall be supplied with each measurement. 2-D. Acquisition To retrieve source images from hardware or through a web-based interface, i.e. ftp from a remote site.

4 3. System-Level Requirements Specification 3.1 Functional Requirements A. User Interface B. Database A.1 Output A.2 Administration B.1 History B.2 Settings B.3 Archive A.1.1 Web C. Water Level Detection D. Processing Lib A.1.2 Alerts C.1 Day Module C.2 Night Module D.1 Enhancement D.2 Analysis E. Acquisition C.3 Post Processing E.1 Capture E.2 File Format Processing Figure 3: System-Level Context Diagram

5 Captured Enhancement Enhanced Analysis Configuration File Processed Settings Module Selection Processed Day Module Settings Processed Water Level & Confidence Water Level & Confidence Configuration File Night Module Post Processing Web Reporting Water Level & Confidence Alert Report Web Page History File Figure 4: Data-Flow Diagram Alert System Calibrate Determine Water Level Calibration do: Acquisition do: Enhancing do: Analysis do: Estimate Level & Confidence read: Current Level & Settings do: Generate Configuration Waiting Invocation Water Level Detection do: Acquisition do: Enhancing do: Analysis do: Estimate Level & Confidence do: Create Log Entry do: Generate Web Report do: Determine Alert Status decide: Send Alerts Figure 5: State Machine Diagram

6 3.1-A User Interface 3.1-A.1 Output The output towards the user will consist of web pages, generated in HTML and alert messages, issued according to the water level. 3.1-A.1.1 Web Reports The web reports will display the current water level and confidence estimates, together with the image that resulted in those measurements. 3.1-A.1.2 Alerts Alerts will be issued when the current level of the water is above some threshold value with a sufficient confidence, so that concerned individuals may be notified promptly. 3.1-A.2 Administration This will provide an interface for the user to calibrate the system, in the event that the physical characteristics of the camera, landscape and/or measuring facilities change. 3.1-B Database 3.1-B.1 History A log with values of historical measurements will be kept in a human-readable ASCII text file. 3.1-B.2 Settings Various configuration settings, such as threshold levels, calibration values and alert recipient lists will be stored in separate files. 3.1-B.3 Archive Older log files will be periodically archived and stored in a compressed format 3.1-C Water Level Detection 3.1-C.1 Day module This module will be responsible for receiving a pre-processed daylight image of the water and using it to determine the level and a confidence measure. 3.1-C.2 Night Module This module will be responsible for receiving a pre-processed night-time image of the water and using it to determine the level and a confidence measure.

7 3.1-D Processing Lib 3.1-D.1 Enhancement Functions for making the image more suitable for analysis: morphology, such as dilation and erosion. Color space conversion, o RGB Intensity o RGB HSV Pixel values and statistics histogram, contrast adjustment, etc 3.1-D.2 analysis Edge detection, template matching, sharpen, etc. 3.1-E Acquisition 3.1-E.1 Capture Retrieval of water image. This can be either by accessing a locally available image grabber device, or by fetching a remotely stored image over the network., 3.1-E.2 File Format Processing Conversion of the retrieved image to a format acceptable by the image processing libraries. Also storage of the image in a format suitable for display over the World Wide Web. 3.2 Non-Functional Requirements 3.2-A. Timing The whole software will run every 10/15 min. Therefore, the whole system grabbing the image, preprocessing, image-analysis, confidence measurements, logging into database and producing web-pages should be complete within that time. 3.3 Domain Requirements 3.3-A. The software should run on Linux. 3.3-A.1 The software should be Open Source.

8 4. Hardware and Software Resource Requirements This project involves having a web camera at the creek and a setup that facilitates water-level measurement. For daytime, we shall have an upright wooden log painted with alternate white and black bands placed near the edge of the creek as a reference to measure water-level. At night, an array of LEDs will be used for the same purpose. Our client has most of this setup already in place. The software requirement of this project is having access to a Linux machine, since that is the OS on which we shall do the development. We also need a web server to implement the web interface of the software. 5. Preliminary Schedule 5.1 Development Items Major Phases Hardware placement of the daytime measuring device with black and white stripes in the water. Beside this device mount a stack of LED s to measure the nighttime water depth. Decide Implementation of processing decide how to process the images to determine the depth of water. Prototyping develop a preliminary design of the warning system. Packaging put everything into one package. Testing make sure system works with confidence Tasks and Dependencies Dependencies: 1. Hardware none 2. Processing none 3. Learn AutoConfig none 4. Prototyping 1,2,3 5. Interface Definition 4 6. Processing / Coding 4 7. Packaging Code 5 8. User Manuals 6 9. Testing Deployment 8, 9

9 5.1.3 Major Milestones Client/Student build the water depth measuring devices. Place the daytime measuring device with black and white stripes in the water. Beside this device mount a stack of LED s to measure the nighttime water depth. Decide whether measuring devices are fixed or should the software search for them in the picture. Learn how to use AutoConfig to package everything together. Write a User Manual for the Flood Warning System. Test the system with a set of created images and judge how much trust goes into the depth report. Build a prototype of the system Deliverables Contract I Contract II Design Specification Schedule II Prototype User Manual Implementation Manual 5.2 Development Diagrams

10 5.2 Risk Analysis and Management Identified Risks Will the depth measuring devices move from their original location? Will the camera move during high wind? What will the software do with a blank image from camera failure? Plans We have already mounted the pole in several bags of concrete hopefully making it secure from movement. Assume the camera will not move. Design the software not to crash when blank or no images are received.

Flood Warning System Group 6

COMP 145 UNC Chapel Hill Contract II Flood Warning System Group 6 Submitted to: Stephen Tell and Prof. Greg Welch February 17, 2001 Alex Giouzenis Kevin Berry Ruigang Yang Ashes Ganguly Stephen Tell PREFACE