LAB 1 – SURFACE WATER DETECTION SYSTEM PRODUCT DESCRIPTION1
Lab 1 – Surface Water Detection System Product Description
Version 2
Katherine Kenyon
CS 411 Workforce Development II
Old Dominion University
Professor Hill Price
March 19, 2011
Table of Contents
1Introduction
2Product Description
2.1Key Product Features and Capabilities
2.2Major Components (Hardware/Software)
2.3Target Market/Customer Base
3Product Prototype Description
3.1Prototype Functional Goals and Objectives
3.2Prototype Architecture (Hardware/Software)
3.3Prototype Features and Capabilities
3.4Prototype Development Challenges
4Glossary
5References
List of Figures
Figure 1. Technical Overview
Figure 2. Major Functional Component Diagram
Figure 3. Hardware Component Diagram
Figure 4. Software Component Diagram
Figure 5. General Public GUI
Figure 6. City User GUI
Figure 7. Insurance Agency GUI
List of Tables
Table 1. Competition Matrix
Table 2. Prototype vs. Real-World Implementation Comparison
Table 3. Prototype Assumptions
1Introduction
Within the last decade, a vast level of improvement of roadway systems through the use of sensors, cameras, and computerized signs has been achieved. The results of infusing technology into the streets have been subtle, yet life changing for commuters; one such example is the improvement of traffic light coordination based on traffic flow. Recently, new waves of innovative technology solutions have been implemented; cameras that record traffic light violations, warning signs that can detect a violation of the speeding limit, signs that detect a freezing bridge, and webcams that allow remote monitoring of traffic buildup on major highways. These new innovations are very usefulto law enforcement and technologically savvy drivers.
When it comes to alerting a driver about adverse roadway conditions, the use of technology is especially crucial. Notifying a driver of a dangerous roadway condition before it’s too late can potentially reduce the number of related accidents. Car accidents are the leading cause of death for Americans under thirty-five years of age(Online Lawyer Source, 2011). It is common knowledge that car accidents are more likely to occur when the roads are flooded, but sometimes driving through adverse weather conditions cannot be avoided. Luckily, there is a simple solution to this problem – the Surface Water Detection System. The Surface Water Detection System employs a network of ultrasonic sensors to detect dangerous levels of flooding on highways and roads – with this information, drivers can be alerted through various channels to avoid taking a route that has dangerous water conditions.
2Product Description
The Surface Water Detection System will consist of a network of above-ground ultrasonic sensors used to detect an unacceptable level of water on the road. The ultrasonic sensors will be strategically placed in areas that are prone to flooding. When a road flood is detected;strategically placed technologically-enhanced road signs will alert drivers that there are dangerous flood levels ahead. Upon noting the flood sign, a driver will decide whether or not to make a detour to a non-flooded route.
2.1Key Product Features and Capabilities
The Surface Water Detection System will feature a commercial front-end, roadside warning signs, interactive Internet maps, and mobile device support. Table 1 compares the functionality of the Surface Water Detection System with existing flood monitoring systems. In addition to becoming the first flood monitoring system put to use in the Hampton Roads Area of Virginia, the Surface Water Detection System offers a more comprehensive set of features than any of its competitors - including innovative mobile device alerts.
Table 1. Competition Matrix
Table 1 compares the functionality of the Surface Water Detection System with existing flood monitoring systems. In addition to becoming the first flood monitoring system put to use in the Hampton Roads Area of Virginia, the Surface Water Detection System offers a more comprehensive set of features than any of its competitors - including innovative mobile device alerts.
By providing multiple channels with which to receive timely updates about flood conditions, drivers are able to reap the full benefits of the Surface Water Detection System. The Surface Water Detection System uses road signs to immediately alert a driver. Advanced route planning can be accomplished through the use of interactive internet maps. Mobile device support will provide cell phone subscribers with SMS updates about flooding within areas of specified interest. By knowing adverse road conditions well in advance, a driver will be better able to make decisions resulting in a safer roadway experience.
2.2Major Components (Hardware/Software)
Figure 1 shows three levels of functionality for the Surface Water Detection System. Each layer builds upon the functionally of a lower layer, as indicated from the base layer to the top-most layer from left to right.
Figure 1. Technical Overview
At the most basic layer, each water detection device will act as a closed system. The closed system “Remote” device will consist of a single ultrasonic sensor, a microcontroller, a ruggedized housing unit, and a warning sign. The remote device will include (but does not require) a network interface to operate. Figure 2 illustrates how the hardware components interact within the remote device. In Figure 2 the gray box indicates which components will be consolidated within a ruggedized housing unit.
Figure 2.Major Functional Component Diagram
The next layer, called the Centralized Control layer - involvesa network of “Remotes” that communicate to a central server about roadway flood conditions. Figure 3 is a stylized high-level diagram that illustrates the interactions between the remote device layer and the central control layer. Each remote water detection device installed in the field will be connected to a network for centralized control. The network gathers instantaneous data from each of the remote devices and processesthe data into a central database located on a webserver. Lastly, the top-most layer consists of end-user applications which includewebsites, online maps with real-time information, mobile alert services, and syndicated status updates.
[This space intentionally left blank]
Figure 3. Hardware Component Diagram
Figure 4 illustrates the relationship between the centralized data server and user applications. Between the Centralized Control layer and the End-User Application layer is a server/client web interface. The Surface Water Detection System will utilize the internet to send data to various end-user applications. The network of remote units will not connect directly to the internet, for the Centralized Control layer will have its own dedicated network to gather flood level signals from each of the remote devices. However, the Centralized Control layer will store its central database onto a webserver and make its data accessible to clients via the internet.
Figure 4. Software Component Diagram
2.3Target Market/Customer Base
The primary benefactors of the Surface Water Detection System are automobile drivers. Access to the end-user services will be provided to individuals free of charge. The Surface Water Detection System’s main customer is local and state governmentsinterested in implementing it as a public safety service. Additional revenue for the Surface Water Detection System will come from secondary markets such insurance companies, agencies interested in buying statistical data, and companies interested in utilizing services provided by the Surface Water Detection System within commercial applications.
3Product Prototype Description
The prototype for the Surface Water Detection System will consist of two separate parts that illustrate the closed system aspect of the system and some of the essential data services. The first part of the prototype will consist of a demonstration of how the ultrasonic sensor detects water levels. This will be achieved through the use of an ultrasonic sensor and a container of water. The second part of the prototype involves demonstrating how collected sensor data will be made of use. Figure 5 shows a rapid prototype GUI screen for searching historical sensor information. Historical sensor information deals with sensor readings overtime. This information is stored within a database and accessed through a web-interface.
[This space intentionally left blank]
Figure 5.General Public GUI
Figure 6 and Figure 7 illustrate additional rapid prototyped GUI screens. The city user view illustrates the water depth measurements of various sensors. The colors indicate which sensors are reading a severe level of flooding. The prototype may or may not include integration between sensor readings and data collection software. When actual readings and software can’t be functionallyintegrated due to difficulties with the sensor or lack of sensors, simulated data will be created to demonstrate software functionality.The prototype will include a demonstration of integration with Google Maps and mobile updates. In the prototype many capabilities of the product will be reduced or eliminated.
[This space intentionally left blank]
Figure 6.City User GUI /
Figure 7. Insurance Agency GUI
3.1Prototype Functional Goals and Objectives
The first functional objective of the prototype is to demonstrate the mechanism of water detection using an ultrasonic sensor. The purpose of this objective is to demonstrate that an ultrasonic sensor is proficient at water level detection. The second functional objective of the prototype is to demonstrate how data collected through the ultrasonic sensor can be interpreted into meaningful results. The data will be accessible through the World Wide Web in order to demonstrate ease of use.
3.2Prototype Architecture (Hardware/Software)
An ultrasonic sensor will be directed at a container with varying water levels adjusted through the manual addition of water through the top or drainage of water through a release hatch. The information collected by the sensor will be collected and sent to a computer attached to the sensor through a USB port. The computer will be running software that is able to interpret the sensor data into meaningful results. These results will be stored into a MySQL database on an external webserver to be stored and accessed by web applications such as Google Maps. Table 2 illustrates key differences between the real-world product and the prototype, the table explains how the functionality of the prototype will be reduced from the real world product.
Feature / Real World Implementation / PrototypeSensor / One sensor available for closed system; multiple sensors for networked system. Ruggedized housing to protect from the elements. / Will feature one sensor that detects and sends data to the simulation computer in the closed system demonstration.
Microcontroller / For closed system, embedded data store and algorithms to throw out erroneous data. For networked solution, programmed to send data to centralized data center. / Will feature one microcontroller that receives data from a single sensor and sends it to the development PC.
Multi-Sensor Network / If client chooses to implement networked solution, this is available for implementation. The number of sensors will be determined by the client based upon several factors. / This will be simulated for the networked demonstration.
Centralized Data Center / Data collection server that stores the info from the microcontroller / Will be simulated.
Report Generator / Users can access reports from the product website which will feature an administrative login for clients. The data is pulled from a database on the server. / This is simulated in a GUI on the development computer.
GoogleMaps™ application / Featured on the product website with real-time water depth measurements in inches. / Will be simulated on the product website via a GUI.
RSS / Included on the product website for entities to subscribe. / An icon will be featured on the product website but will not be functional.
Table 2.Prototype vs. Real-World Implementation Comparison
3.3Prototype Features and Capabilities
The prototype will demonstrate the general concept behind the Surface Water Detection System. A sensor unit is used to detect water levels and computer software records historical sensor data, as well as alert coordination and publishing of flood conditions to various web services such as RSS. The prototype addresses risk mitigation by providing an example of a third-party network solution model that may need to be implemented in case existing networks such as the Intelligent Transportation Systems Network (ITS),or the Advanced Transportation Management System (ATMS) cannot be used by the real world product. Table 3 lists prototype assumptions.
Prototype AssumptionsA simulated sensor will not stop functioning during a simulation.
Any spike in data will be regarded as an obstruction (such as a vehicle) and will be thrown out.
The user will not look up data archives for a date that precedes the sensor installation date.
The microcontroller will not perform any data processing; it is assumed that software at the centralized data center will perform this task.
Table 3.Prototype Assumptions
3.4Prototype Development Challenges
An accurate demonstration of the product must be demonstrated despite the availability of only one sensor. Demonstration of data collection features dealing with data from multiple sensors will be simulated through pre-generated data. The prototype filter logic also presents a challenge. Successful implementation of filtering logic must be accomplished in order to demonstrate that the Surface Water Detection System will not be prone to a high level of false alarms.
4Glossary
Algorithm: A precise rule or set of rules specifying how to solve a problem.
Annual software license: A legal contract governing the usage of software that is updated once a year.
Application Programming Interface (API): Software implemented to allow for simpler and more abstracted interactions with other software.
Baseline package: The basic closed-system version of the flood detection system that includes the ultrasonic sensor, microcontroller, ruggedized housing, and flashing warning sign. This is best suited for remote locations where a sensor network would be impractical.
Bid proposal: An explanation of products and services given with an estimated cost.
Centralized data center: The software and hardware that acts a central point for collecting the sensor data transmissions over a network and recording their values into a database.
Client: Any end-system that is connected to a network.
Closed system: A single ultrasonic sensor, microcontroller, ruggedized housing, and warning sign set up that has no network interface.
Commercial front-end: An entity that provides some means, via website or physical location, to sell a product. These are direct whose primary goal is to sell its company’s deliverables to a targeted market.
Embedded data store: The ability to store data on the microcontroller.
Flooding: An inundated area of roadway that is considered impassible due to an influx of water.
Global Positioning System (GPS): A navigational system that pinpoints latitude and longitude of
a location using stationary satellites.
Google Maps API: A technology created by Google that utilizes maps to support a variety of
uses, typically displaying related locations in map form through a web browser.
Graphical User Interface (GUI): A user-friendly interface that allows easy access to an
applications features, which uses a mouse and keyboard as input devices.
Microcontroller: A small computer on a chip that is used to control electronic devices.
Modularized: Development technique which involves breaking a unified process or idea into coherent segments for the purpose of abstraction or simplicity.
Multi-sensor network: Several sensor installations connected by a network infrastructure that relay measurements back to a centralized data center.
Network: A system of interconnected electronic components or circuits.
Prototype: Logical step in the development process demonstrating the real world potential of a
concept.
Short Message Service (SMS): A mechanism which allows brief text messages to be sent to the phone. Several of the major phone standards support it.
Real time data:Information that is collected in the actual time the process is occurring.
Really Simple Syndication (RSS):Formatted XML used to provide subscribers with information
updated on a regular basis.
Risk analysis: Identifying and assessing factors that may compromise the success of a project.
Ruggedized housing: An enclosure designed to protect an electronic device such as a field
sensor from the elements.
Server: A computer used to accept incoming requests and information over a network, and in-
turn, generates and transmits data back to another user or computer (client).
Ultrasonic sensor: A sensor that calculates changes in depth using high frequency sound waves.
User base applications: Programs developed for the purpose of providing services to users.
Warning sign: A type of traffic sign that indicates a hazard on the road that may not be readily
apparent to a driver.
Web Server: A computer that delivers content from websites over the internet.
5References
CS Green Team. (2011). Surface Water Detection System. Retrieved February 9, 2011, from CS410 Green Team:
Online Lawyer Source. (2011). Car Accident Statistics. Retrieved February 8, 2011, from Online Lawyer Source: