LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION1
Lab 2 – Surface Water Detection System Product Specification
Version 1
Katherine Kenyon
CS 411 Workforce Development II
Old Dominion University
Professor Gene Price
March 21, 2011
Table of Contents
1Introduction
1.1Purpose
1.2Scope
1.3Definitions, Acronyms, and Abbreviations
1.4References
1.5Overview
2General Description
2.1Prototype Architecture Description
2.2Prototype Functional Description
2.3External Interfaces
2.3.1Hardware Interfaces
2.3.2Software Interfaces
2.3.3User Interfaces
3Specific Requirements
3.1Functional Requirements (Eric Boyd)
3.1.1Closed-System Remote Device (CSRD) (Marissa Hornbrook)
3.1.2Onsite Data Acquisition Device (ODAD)
3.1.3Networked-System Remote Device (NSRD)
3.1.4Data Acquisition Host (DAH)
3.1.5Administrative Web Application (AWA)
3.1.6Public Web Server (PWS)
3.2Performance Requirements (Robert Dayton)
3.3Assumptions and Constraints (Jill Mostoller)
3.3.1Assumptions
3.3.2Constraints
3.3.3Dependencies
3.4Non-Functional Requirements
3.4.1Security (Katherine Kenyon)
3.4.2Maintainability (Cassie Rothrauth)
3.4.3Reliability (Christopher Meier)
4Appendix
List of Figures
Figure 1. Prototype Major Functional Component Diagram (MFCD)
Figure 2. Networked System Functional Breakdown
Figure 3. Closed System Functional Breakdown
Figure 4. General Public GUI
Figure 5. City User GUI
Figure 6. Insurance Agency GUI
List of Tables
Table 1. Prototype vs. Real-World Implementation Comparison
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements
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 useful to 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.
1.1Purpose
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.
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 will be local and state governments interested in implementing it as a public safety service. Other potential customers include insurance companies, agencies interested in buying statistical data, and companies interested in utilizing services provided by the Surface Water Detection System within commercial applications.
The Surface Water Detection System will alert drivers of adverse flooding on the roadways, it will not tell drivers which route to take nor will it be able to directly control the actions of the driver or the vehicle. The Surface Water Detection System will record historical data about water levels in a certain area over time, this information will be provided as-is with no guarantees about accuracy or data permanency.
1.2Scope
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. 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. Road signs immediately alert a driver of a flood. 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.
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 1. Prototype vs. Real-World Implementation Comparison
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 may or may not include integration between sensor readings and data collection software. When actual readings and software can’t be functionally integrated 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 Bing Maps and mobile updates.
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.
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. Table 1 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.
1.3Definitions, Acronyms, and Abbreviations
Administrative Web Application (AWA): Multipurpose portal containing management tools for
administering remote devices.
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.
Bing Maps API: A technology created by Bing that utilizes maps to support a variety of uses,
typically displaying related locations in map form through a web browser.
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.
Closed-System Remote Device (CSRD): Combination of components which are in charge of gathering information and onsite data logging.
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.
Data Acquisition Host (DAH): Software component in charge of receiving information from
remote sensors and logging to the database.
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.
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.
Networked-System Remote Device (NSRD): Combination of components which are in charge of
gathering and communicating information over a network to a centralized location.
Onsite Data Acquisition Device (ODAD): Device capable of configuring the CSRD and
downloading its stored data.
Prototype: Logical step in the development process demonstrating the real world potential of a
concept.
Public Web Server (PWS): Computer that hosts the public website and web services.
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.
URL: Uniform Resource Locator
User based 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.
1.4References
CS Green Team. (2011). Surface Water Detection System. Retrieved February 9, 2011, from CS410 Green Team:
Kenyon, K. (2011). Lab 1 – Surface Water Detection System Product Description
Online Lawyer Source. (2011). Car Accident Statistics. Retrieved February 8, 2011, from Online Lawyer Source:
1.5Overview
This specification provides a detailed explanation of the logical components of the Surface Water Detection System Prototype. Explanations will be broken down into description of each functional component. Next, the two major functional modes will be described. Finally, hardware, software, and user interfaces will be defined. Following the general description are specific functional, performance, and non-functional requirements. These requirements will further clarify the needs of the prototype which must be met to demonstrate the product concept to a level which is acceptable.
2General 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. Historical sensor information deals with sensor readings overtime. This information is stored within a database and accessed through a web-interface. The city user view will illustrates the water depth measurements of various sensors with colors indicating which sensors are reading a severe level of flooding.
2.1Prototype Architecture Description
Figure 1. Prototype Major Functional Component Diagram (MFCD)
Figure 1 illustrates the major functional components of the Surface Water Detection System and the flow of data between them. The Surface Water Detection System Prototype will consist of six functional components. The functional components are the Closed System Remote Device (CSRD), the Networked System Remote Device (NSRD), the Data Acquisition Host (DAH), Administrative Website (AWA), Public Web Server (PWS), and the Onsite Data Acquisition Device (ODAD). In this section each functional component will be explained.
The CSRD is responsible for storing calibration information for the water sensor, obtaining data from the sensor, and processing that data. Data is processed through a filtering algorithm that is designed to screen out invalid data readings. The CSRD is also responsible for triggering the onsite sign and plays a role in buffering log data.
The NSRD is responsible for taking the data from the CSRD and packing it for network transmission. Data packets processed by the NSRD are sent to the DAH which receives the data and records it into a database. Information in the database is accessed by two clients: the AWA and the PWS. The AWA and PWS serve as human-computer interfaces to the logged data collection by the Surface Water Detection System. The AWA will be reserved for use by administrators and the PWS will be made accessible for use by the general public users.
In the AWA users will be able to view historical data and access the Remote Management Console. The Remote Management Console is a web application where administrators will be able to set calibration information for each sensor and update remote device firmware. The PWS will be comprised of a news feed, connection with Bing Maps, and RSS.
Finally, there is the ODAD. The ODAD is connected to the CSRD, it is responsible for storing some data and it also serves as an onsite-management console. The ODAD provides the prototype with closed system capability. This capability enables the most vital functions of the system to operate when the network fails. The ODAD will allow for sensor calibration and firmware updates.
2.2Prototype Functional Description
The Surface Water Detection System is broken down into two major functional areas: the closed system and the networked system. These systems are shown in Figure 2 and Figure 3. The closed system will provide the functional warning sign which alerts the driver to dangerous oncoming road conditions due to flooding. The networked system enables historical data collection, website access, and remote alerts via RSS and Bing Maps. The networked system is more complex than the closed system.
Figure 2. Networked System Functional Breakdown
Figure 2 shows a graphical breakdown of the networked system. The networked system deals with the following functional components; AWA, DAH, PWS, and the NSRD. At the center of the networked system is the database. The database component in Figure 2 is conceptual; the actual data is stored in the DAH. The following paragraph contains a verbal run-down of the networked system.
The AWA gets sensor data information out of the database, and sends information about the device configuration to the NSRD – this could be due to an administrative change made through the AWA’s Remote Management Console. The DAH receives sensor data from the NSRD and stores it into the database. The NSRD receives administrative information from the database. Finally, the PWS retrieves sensor data from the database. All of these processes can occur simultaneously. This functional diagram does not make any distinctions between raw sensor data and processed sensor data.