Surface Water Detection System (SWDS) Prototype Product Specification
Running head:
LAB II – SWDS PROTOTYPE PRODUCT SPECIFICATION
Lab II- Surface Water Detection System (SWDS) Prototype Product Specification
Jill Mostoller
CS411
Professor Gene Price
Old Dominion University
March 21st, 2011
Version Two
1
Surface Water Detection System (SWDS) Prototype Product Specification
2
Table of Contents
1. INTRODUCTION……………………………………………………………………...4
1.1 Purpose …………………………………………………………………….....5
1.2 Scope ………………………………………………………………………....6
1.3 Definitions, Acronyms, and Abbreviations …………………………………10
1.4 References …………………………………………………………………...13
1.5 Overview……………………………………………………………………..13
2. GENERAL DESCRIPTION ………………………………………………………….13
2.1 Prototype Architecture Description …………………………………………14
2.2 Prototype Functional Description …………………………………………...15
2.3 External Interfaces…………………………………………………………...16
2.3.1 Hardware Interfaces………………………………………………..17
2.3.2 Software Interfaces………………………………………………...17
2.3.3 User Interfaces …………………………………………………….17
3. SPECIFIC REQUIREMENTS ...……………………………………………………..19
3.1 Functional Requirements ……………………………………………………19
3.1.1 Closed-System Remote Device ……………………………………19
3.1.2 Onsite Data Acquisition Device …………………………………...20
3.1.3 Networked-System Remote Device………………………………..21
3.1.4 Data Acquisition Host ……………………………………………..21
3.1.5 Administrative Web Application ………………………………….21
3.1.6 Public Web Server ………………………………………………...22
3.2 Performance Requirements ………………………………………………….23
3.3 Assumptions, Constraints and Dependencies ……………………………….23
3.3.1 Assumptions ……………………………………………………….24
3.3.2 Constraints ………………………………………………………...25
3.3.3 Dependencies ……………………………………………………...26
3.4 Non-Functional Requirements ………………………………………………26
3.4.1 Security ……………………………………………………………26
3.4.2 Maintainability …………………………………………………….27
3.4.3 Reliability ………………………………………………………….27
List of Figures
Figure 1. Technical Overview ……………………………………………………………6
Figure 2. Major Functional Component Diagram……………………………………….14
Figure 3. Closed System Functional Breakdown………………………………………..15
Figure 4. Networked System Functional Breakdown …………………………………...16
Figure 5. Insurance Agency GUI………………………………………………………...18
Figure 6. City User GUI…………………………………………………………………18
Surface Water Detection System (SWDS) Prototype Product Specification
3
List of Tables
Table 1. Prototype vs. Real-World Implementation Comparison ………………………...8
Table 2. Feature Comparison ……………………………………………………………..9
Table 3. Effects of Assumptions, Dependencies, and Constraints on Requirements…...23
[This space intentionally left blank]
Surface Water Detection System (SWDS) Prototype Product Specification
4
Lab II – SWDS Prototype Product Specification
1 INTRODUCTION
In the United States, floods are one of the most frequently occurring natural
disasters (FEMA, 2010). Unfortunately for drivers, there currently is no contiguous alert
system to warn when roadways are flooded and therefore unsafe to travel. With no
system currently in place, drivers are forced to use their own judgment for both the water
depth and the amount of water safe for their vehicle to pass through. This is not an easy
decision to make and this human error can result in vehicle damage and personal injury.
Tens of thousands of cars are damaged by floodwaters every year (CARFAX,
n.d.). Drivers whose vehicles can be repaired incur large costs, where as others may even
need to purchase a completely new car. The costs associated with the vehicle damage are
nothing compared to those of hospital bills and in some instances the cost of one’s life.
According to the National Climatic Data Center (2005), 42% of fatalities caused by
flooding involved vehicles in the United States.
While the safety of the average American driver is the biggest concern, a city
incurring large costs because of flooded roadways is also an issue. The work force
needed to rescue stranded motorists, as well as resources needed to block off roadways to
prevent any more accidents both cost time and money. When vehicles are waterlogged
and therefore cannot be driven, they are towed at the city’s expense.
An effective alert system could help prevent vehicle damage, personal injury, and
extraneous use in city resources in situations where a driver cannot accurately assess the
water depth in the roads. The Surface Water Detection System (SWDS) was developed to
aid drivers in evaluating road conditions during flooding. SWDS is designed to detect
Surface Water Detection System (SWDS) Prototype Product Specification
5
when roadways have a level of water deemed unsafe for vehicles to drive through without
causing damage. The system alerts drivers with the use of a warning sign on the road to
notify if a detour is necessary. With the use of the Bing Maps API and RSS feeds, drivers
can also check road conditions before even starting their commute. The main goal of the
SWDS is to make drivers aware of flooding so they can take the necessary steps to
protect themselves and their vehicles.
1.1 Purpose
The Surface Water Detection System is a hardware-oriented solution that detects
the change in depth between the road and the sensor. This information is then used to
determine whether the roads are safe for motorists. If a sensor detects flooding, a signal is
sent to a localized flashing road sign and to a centralized data center. The flashing road
sign serves as an immediate warning for current travelers. The centralized data center
collects the information through the networked system and allows a user to see a map of
local road flooding before they begin their drive. This information is also used in RSS
feeds so the user can get updates while away from the original web application. The data
center stores the information as well, which provides an archive for the user for historical
and statistical analysis.
The Surface Water Detection System starts with our baseline package and has two
proposed upgrades. In Figure 1, the system is broken down into each package. “Remote”
represents the baseline package, “centralized control” represents the network package and
“End-User Applications” represents the application package. The baseline package
consists of a closed system setup. This closed system would be ideal for remote locations.
Surface Water Detection System (SWDS) Prototype Product Specification
6
A sensor in a ruggedized housing would be installed along with a warning sign.
The microcontroller that controls the sensor has the ability to store a limited amount of
data for historical or statistical analysis. The system would allow embedded algorithms
for determining erroneous data for a more accurate alert.
Figure 1. Technical Overview
The networked system consists of multiple sensors that are all connected and send
information to a centralized data center. This allows for easier maintainability for the
software needing upgrades and allows the city user to determine if a sensor is
malfunctioning from a remote location. The information sent to the centralized data
center is then used with the third package, the end-user applications. The depth
measurements are used to display road conditions on a map application, as well as
sending alerts to drivers using the syndication service.
Although the main benefactor from this product is the average driver, the primary
customers consist of city governments. When roads flood and become hazardous to
drivers, it is the local government’s responsibility to assist motorists who may become
stranded or injured as a result. It is also their responsibility to try to prevent drivers from
passing through the waters. Currently, cities block off roadways with police cars and use
police officers and rescue workers to help divert traffic. This extraneous use of resources,
along with the cost of towing or rescuing stranded drivers, adds to the city’s expenses.
Surface Water Detection System (SWDS) Prototype Product Specification
7
Aside from decreasing ancillary costs, the local government will build good
public relations by being concerned with the safety of its citizens. The decrease in floodrelated accidents will not only make the city look appealing, but will give the voters
confidence in choosing the incumbent for re-election. With city governments, the system
would be sold through bid proposals, but our product has a commercial front-end that
allows it to be sold to private citizens, as well.
Individuals can benefit from the Surface Water Detection System if they have a
particular interest in knowing water levels at a given time. This could be especially useful
for those living near water or whose house is below sea level. The SWDS could be used
to detect the water levels at a boat dock or to give homeowners peace of mind that they
will not come home to a flooded basement.
1.2 Scope
The prototype of the SWDS solution demonstrates the feasibility of using an
ultrasonic sensor to determine if a roadway is flooded. The prototype allows us to
demonstrate how the sensor data sorting algorithms will work, as well as allow us to
simulate a networked system of sensors. Sample data that is simulated from the prototype
sensor and networked system will supply information to our web-based applications as
well.
The prototype will serve as a demonstration to mitigate any risks associated with
the final solution and proving the real world product concept for the customer. The
prototype will need to be limited to one actual sensor for simplicity. A networked system
will be generated in a simulation to demonstrate the software we are developing for the
network and to collect data for our web-based solutions. The Bing Maps and RSS feed
Surface Water Detection System (SWDS) Prototype Product Specification
8
aspects of our real world product will be demonstrated with our simulated data from the
networked system.
The main goal of our prototype is to show proof of concept to our customers so
that they feel confident purchasing the real world product. The prototype must
demonstrate all features of the real world product through simulated data. Though the
main software components would be the same between the prototype and real world
product, the hardware is much different for a cost effective demonstration. In Table 1, the
prototype components are compared to those of the real world product to illustrate the
main difference between the two systems.
Table 1. Prototype vs. Real-World Implementation Comparison
Surface Water Detection System (SWDS) Prototype Product Specification
9
By using an actual sensor, we can demonstrate the sensor’s ability to find the
depth. We can also show how our algorithm will sort data to determine whether the roads
are flooded or if debris or cars are causing erroneous readings. All of the data from the
sensor is sent to the microcontroller, which acts as an intermediate to our database that
will store the simulated information. The only difference between our web application
packages in the prototype versus the real world product would be the customizable wed
front to store both the Bing Maps interactive maps and the RSS feed sign up. Both the
Bing Maps demonstration and RSS Feed are available in our prototype.
The SWDS prototype shares many of the same features and capabilities of the real
world product. The prototype is able to calculate depth measurements and stores this
information for historical and statistical analysis. The information can also be passed to
our web-based applications in our prototype. In Table 2, a feature comparison is used to
show the similarities in the real world product and prototype.
Features
Real World Product
Prototype
Depth measurements
Included
Included
Data archive
Included, stored on
database.
Bing Maps
Included for both
microcontroller and
centralized data center
(server).
Included
RSS feed
Included
Included, Norfolk is used as
an example.
Included
Customizable web-front
Included
Not Included
Table 2. Feature Comparison
Surface Water Detection System (SWDS) Prototype Product Specification 10
1.3 Definitions 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.
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.
Surface Water Detection System (SWDS) Prototype Product Specification 11
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.
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.
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.
Surface Water Detection System (SWDS) Prototype Product Specification 12
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.
Surface Water Detection System (SWDS) Prototype Product Specification 13
1.4 References
CARFAX Flood Car Tips: Avoid flood-damaged cars, autos, and vehicles. (n.d.).
CARFAX - Vehicle History Reports and VIN number check. Retrieved February
7, 2011, from http://www.carfax.com/car_buying/flood_damage_cars.cfx
Flood Maps, Insurance, and Information. (2010, August 11). FEMA. Retrieved February
7, 2011, from www.fema.gov/hazard/flood/info.shtm
Mostoller, Jill. Lab I-Surface Water Detection System Product Description. February 9th,
2011.
Storm Data Publications. (2010, April 8). NCDC Climate Products. Retrieved February
7, 2011, from www.ncdc.noaa.gov/oa/climate/sd/
1.5 Overview
This prototype specification will outline the hardware and software needed for the
prototype development. In the remaining sections of this paper, details will be provided
about the major hardware and software components. Additionally, the hardware and
software architecture for the prototype will be broken down. An explanation of the
functionality of our prototype will be presented and the use of any external interfaces will
be addressed, as well.
2 GENERAL DESCRIPTION
The prototype of the SWDS solution demonstrates the feasibility of using an
ultrasonic sensor to determine if a roadway is flooded. The prototype allows us to
demonstrate how the sensor data sorting algorithms will work, as well as allow us to
simulate a networked system of sensors. Sample data that is simulated from the prototype
Surface Water Detection System (SWDS) Prototype Product Specification 14
sensor and networked system will supply information to our web-based applications, as
well.
The prototype will serve as a demonstration to mitigate any risks associated with
the final solution and proving the real world product concept for the customer. The
prototype will need to be limited to one actual sensor for simplicity. A networked system
will be generated in a simulation to demonstrate the software we are developing for the
network and to collect data for our web-based solutions. The Bing Maps and RSS feed
aspects of our real world product will be demonstrated with our simulated data from the
networked system.
2.1 Prototype Architecture Description
The major functional components for the Surface Water Detection System are
presented in Figure 2. Our prototype is a smaller scale of the real world product but
retains the functionality of each package we offer. The SWDS prototype has six major
components. The CSRD includes the ultrasonic sensor that calculates the depth
measurements. Similar to the CSRD, we have the NSRD, which are any ultrasonic
sensors that are networked together. Each calculates the depth measurements, but they are
associated with two separate packages.
Closed System
Remote Device
Networked System
Remote Device
Onsite Data
Acquisition
Device
Administrative
Web
Application
Data Acquisition
Host
Figure 2. Major Functional Component Diagram
Public Web
Server
Database
Surface Water Detection System (SWDS) Prototype Product Specification 15
Both the CSRD and NSRD will have a data acquisition host to obtain archival
data from the sensors. The CSRD will need an ODAD that can abstract this historical and
archival information. The NSRD sends the data through the network to a DAH to store
the data. The last two important components of the prototype both pertain to our “EndUser Application” package. The administrative web application and public web server are
both used to provide access to the depth measurements and archival data by multiple user
types. The PWS is also used in our news feed, Bing Maps and RSS services.
2.2 Prototype Functional Description
The first component of our prototype is the Closed System Remote Device (CSRD).
This device consists of the ultrasonic sensor, microcontroller and eBox. In Figure 3, a
functional breakdown is shown for the simplistic system. The CSRD stores the depth
measurements that it obtains from the sensor and logs the data. It then processes the data
through our filtering algorithm to throw out any erroneous measurements. If the water
level is considered too high, the CSRD triggers our warning sign. An Onsite Data
Acquisition Device (ODAD) will be used to get any logged data from the CSRD. It will
also be used to set the measurement offset for the device and update the device software.
Closed System
Remote Device
Device Configuration
Store
Logged Data
Get
Onsite Data
Acquisition
Device
Figure 3. Closed System Functional Breakdown
The Networked System Remote Device (NSRD) has almost the same functionality as
the CSRD. The difference between the two devices is the NSRD is attached to a network
therefore its data is easily obtainable. It is also easier to update the software over the
network. In Figure 4, the NSRD sends a request to the database to get the device
Surface Water Detection System (SWDS) Prototype Product Specification 16
configuration. This configuration is stored on the database by the Administrative Web
Application (AWA).
Administrative Store
Web
Get
Application
Device Configuration
Sensor Data
Sensor Data
Database
Sensor Data
Get
Public Web
Server
Store
Data Acquisition
Host
Sensor Data
Device Configuration
Get
Networked
System Remote
Device
Figure 4. Networked System Functional Breakdown
The AWA can also retrieve data on depth measurements from the database. The
NSRD sends the information through the Data Acquisition Host (DAH) and the DAH
stores the information on the database. Once the AWA retrieves the information from the
database, the user can view historical data or manage the remote device. The user can set
the measurement offset remotely and any updates to the system can be added. The Public
Web Server (PWS) can also retrieve information from the database. Figure 5 illustrates
one of the features supported by the PWS. Our Bing Maps application will obtain all the
depth measurement information from the PWS. Our news feed and RSS will also use the
PWS to keep the users up-to-date on road conditions on their commute.
2.3 External Interfaces
The external interfaces for the Surface Water Detection System prototype are
similar to those in the real world product. There are obvious differences in the hardware
Surface Water Detection System (SWDS) Prototype Product Specification 17
interface, as well as the software interfaces. Our prototype solution relies more on
software, where as the real world product would rely heavily on hardware interfaces.
2.3.1 Hardware Interfaces
For our prototype, we will be using an ultrasonic sensor, microcontroller and
eBox. We will also be using a development PC to store our database and web server so
that we can simulate each aspect of our product. The ultrasonic sensor used in the
prototype will have a shorter range than the one used in our real world product. The
sensor will be connected to the microcontroller. The microcontroller will then be
connected to the eBox and will represent the CSRD. Connecting the eBox to the
development PC will represent the NSRD.
2.3.2 Software Interfaces
Our prototype relies more on software than our real world product. We only have
one physical sensor, microcontroller and eBox, so other sensors will need to be simulated
using software. We will maintain a database to store the information that comes from our
physical sensor and the simulated sensors. We will also host a web server that extracts
depth measurements from our database and uses the information to update Bing Maps.
2.3.3 User Interfaces
The prototype will offer a web front for a user to log into. Figure 5 shows how the
user can obtain historical archived data. This website will also demonstrate how the user
can look up current depth measurements which is shown in Figure 6. The real world
product will have RSS capabilities but this will not be included in the prototype of the
system.
Surface Water Detection System (SWDS) Prototype Product Specification 18
Figure 5. Insurance Agency GUI
Figure 6. City User GUI
Surface Water Detection System (SWDS) Prototype Product Specification 19
3 SPECIFIC REQUIREMENTS
3.1 Functional Requirements
3.1.1 Closed-System Remote Device (Marissa Hornbrook)
The Closed-System Remote Device (hereafter referred to as CSRD) operates by
obtaining measurement data from the ultrasonic sensor and processing the data by
filtering it through the logic algorithm mentioned previously. The data is stored locally
and a copy of the device’s settings is kept inside it for configuration purposes. During a
collaborative session, a list of requirements was created to further detail the closed
system and they are as follows:
1.
The CSRD will be preprogrammed to accept measurement data directly from
the sensor.
2.
The CSRD will be preprogrammed with filtering logic capable of discarding
erroneous data.
3.
The CSRD will record data from the sensor to its internal storage device.
4.
The CSRD will activate a flashing warning sign on the road when the
incoming measurements record a depth that sets off a preprogrammed trigger.
5.
The CSRD will provide a program that allows a technician to configure the
device and copy its local storage of sensor measurement data via a network
protocol. (Telnet, HTTP, etc.)
6.
The CSRD will keep a local copy of its own configuration comprised of the
following items:
a. Unique ID: An identifier unique to each sensor
b. Name: To establish a location, e.g., corner of Main St. and Route 44.
Surface Water Detection System (SWDS) Prototype Product Specification 20
c. Latitude/Longitude: The global position utilized by Bing MapsTM.
d. Offset: The distance from the sensor to the road will be recorded once and
set as the zero marker. Any distance beyond that is the offset and will be
viable data.
e. Threshold: Preprogrammed trigger that will activate the flashing road sign.
f. Increment: Measurement fluctuation
g. IP address: This is to coordinate with the Data Acquisition Host to obtain
measurements from the closed system since the data is not being
transferred to a database over a network.
3.1.2 Onsite Data Acquisition Device (ODAD) (Eric Boyd)
This function defines interactions with the CSRD to collect sensor measurement data
from the CSRD’s local storage, and gives the onsite operator the ability to modify the
CSRD’s configuration file. The following functional requirements shall be provided:
1.
An onsite operator is able to connect to the CSRD via physical link such as
Ethernet or Serial cable to provide access to the CSRD’s configuration
program over some network protocol such as Telnet or HTTP.
2.
An onsite operator, once connected to the CSRD, can download sensor
measurement data from the CSRD’s local storage to free device space.
3.
An onsite operator, once connected to the CSRD, can configure the CSRD via
the CSRD’s configuration program.
3.1.3 Networked-System Remote Device (NSRD) (Eric Boyd)
This function encompasses those of the CSRD by allowing the NSRD to act as a
CSRD if network connectivity is lost. In addition, the NSRD transmits its sensor
Surface Water Detection System (SWDS) Prototype Product Specification 21
measurement data over a static network to a centralized collection node (the Data
Acquisition Host) and provides a means for network operators to configure the NSRD
and copy any of its local storage over the static network. The following functional
requirements shall be provided:
1. The NSRD shall revert to CSRD operations if network connectivity is lost.
2. The NSRD checks for network connectivity at regularly timed intervals.
3. The NSRD resumes NSRD operations if after a time of lost network connectivity,
the NSRD reestablishes network connectivity.
4. Once the NSRD establishes network connectivity, it sends its sensor measurement
data over the network to the Data Acquisition Host (DAH).
3.1.4 Data Acquisition Host (DAH) (Eric Boyd)
This function collects sensor measurement data from the NSRDs on the network and
logs that data to a centralized database. The following functional requirements shall be
provided:
1. The DAH receives data from NSRDs on the network.
2. The DAH logs data received from the NSRDs to a centralized database.
3.1.5 Administrative Web Application (AWA) (Eric Boyd)
This function provides administrative services for querying the centralized, and
monitoring and configuring NSRDs on the network. The following functional
requirements are provided:
1. The AWA provides a graphical display of the status of the NSRDs on the
network.
Surface Water Detection System (SWDS) Prototype Product Specification 22
2. The AWA provides a graphical user interface for remotely configuring a NSRD
over the network.
3. The AWA provides a graphical user interface for querying the centralized
database of sensor measurement data.
4. Queries of the centralized database can be performed according to both a
particular set of NSRDs, and a specific date and time range.
3.1.6 Public Web Server (PWS) (Eric Boyd)
This function provides a public available interactive website and web services to the
general population. The website provides a news feed, alerting users to current
inundations in the jurisdiction, and an interactive Bing Maps section where users can
view the real-time status of NSRDs in the jurisdiction. An interface for users to
customize personal alerts of monitored sections along their daily routes is also provided.
The following functional requirements shall be provided:
1. The PWS provides a news feed section on the homepage that informs users of any
current inundations in the jurisdiction.
2. The PWS provides an interactive Bing Maps section where users can view the
real-time status of the NSRDs in the jurisdiction.
3. The PWS provides a graphical user interface for allowing users to pick which
NSRDs in the jurisdiction shall be included in their own personal alert.
3.2 Performance Requirements (Robert Dayton)
3.2.1 Networked and Closed System Remote Devices (Robert Dayton)
Both shall meet the following performance requirements:
1. Accurately read distances from one inch to eight feet in one-inch increments.
Surface Water Detection System (SWDS) Prototype Product Specification 23
2. Make incremental measurement readings on an adjustable schedule with a five
second default interval.
3. Identify and filter out measurement reading jumps of greater than two inches over
a 15 second period.
4. For local data logging, the remote device must be equipped with a storage device
large enough to maintain historical data for at least six months.
3.2.2 Data Acquisition Host (DAH) (Robert Dayton)
The DAH shall meet the following performance requirements:
1.
Support receiving remote device sensor data at the same rate at which the
sensor is making incremental measurement readings.
3.3 Assumptions, Constraints, and Dependencies (Jill Mostoller)
There are various assumptions, constraints and dependencies in place for the
prototype development. Table 3 contains a list of each assumption, dependency and
constraint. The table also lists a brief description of the effects on the prototype
requirements.
[This space left intentionally blank]
Surface Water Detection System (SWDS) Prototype Product Specification 24
Condition
A simulated sensor will not
stop functioning during a
simulation.
A customized web interface
will not be used for each
user type.
Type
Constraint
Effect on Requirements
Bounds the problem of
malfunctioning sensors.
Constraint
Bounds the problem of
designing multiple web
interfaces with different
functionalities.
Bounds the problem of
transmitting the data
archives and updating the
software of the closed
system.
Bounds the problem of
setting up a network for the
city.
Allows us to assume data is
relevant and will be
effective in alerting drivers
in time.
Allows for minimal data
security.
Allows us to only develop
high-level algorithms for
the centralized data center.
Allows for minimal error
checking when processing
data archive requests.
Allows us to assume the
data-sorting algorithm is
correct.
A method will be developed Constraint
by the customer to transmit
data locally from a closed
system.
The city already has a
network set up that we can
piggyback.
Data transmission delay
will not be large enough to
effect real time results.
Constraint
Data collected is not
sensitive in any way.
The microcontroller will not
perform any data
processing.
The user will not look up
data archives for invalid
dates.
Any spike in data will be
regarded as an obstruction
(such as a vehicle) and will
be thrown out.
The eBox will be able to
support the microcontroller.
Assumption
The physical sensor is
available and functioning.
Dependency
Assumption
Assumption
Assumption
Assumption
Dependency
The prototype will rely on
the development PC to run
the data sorting algorithms.
The prototype will rely
exclusively on simulated
sensors.
Table 3. Effects of Assumptions, Dependencies, and Constraints on Requirements
3.3.1 Assumptions
Five assumptions are being made for our prototype. Our first and most important
assumption is that any spike in data will be thrown out. This spike in depth level would
Surface Water Detection System (SWDS) Prototype Product Specification 25
indicate an obstruction, such as a vehicle, in the road and should be caught by our datasorting algorithm. Our second assumption is that the data by the sensor is not sensitive in
any way. The system will not require extensive security for the information collected
because water depth measurements would not classify as confidential material.
The third assumption for our prototype is that the website user will not try to
access data archives for invalid dates. These include both dates that do not exist, as well
as dates that precede the installation of the system. This assumption will allow minimal
error checking with the data archive retrieval. Another assumption our prototype has is
that the microcontroller does not perform any data processing. This allows us to focus on
developing our algorithms solely in a higher-level language that would not be supported
by the microcontroller. Our final assumption is that the data transmission delay from the
sensor to the centralized data center and the warning sign will not be large. The system
will be able to detect dangerous water levels and warn drivers within a one-minute timespan of the event occurring.
3.3.2 Constraints
We have four constraints for our prototype to help limit the scope. Our first
constraint is that our simulated sensors will not malfunction during a given simulation.
This will simplify our simulation program and not require us to address sensor failures. In
the real world product, a city engineer will attend to any malfunctioning sensors in
person. Our second constraint is that there will be a generalized web front to show the
website components of our prototype. In the real world product, we will have three user
types, city users, insurance company users and general public users. For the purpose of
Surface Water Detection System (SWDS) Prototype Product Specification 26
our prototype, will be developing a web front for the user type with the most
functionality, i.e., the city users.
The third and fourth constraints bound the problems of setting up a network and
transmitting data from a closed system. The third constraint is that the city will already
have a network for us to piggyback. With this constraint, we will not need to worry about
setting up a reliable network to transfer data to the centralized data center. The fourth
constraint pertains to only the closed system. The city will need to develop a way, e.g.,
through Bluetooth, to transmit the data archives and update the software of the closed
system sensors.
3.3.3 Dependencies
There have been two dependencies identified for our prototype. The first
dependency is that the physical sensor is available and functional. If the physical sensor
cannot be obtained or is broken, we will need to exclusively use simulated sensors. The
second dependency is that the eBox is able connect with the microcontroller. The eBox
will hold the high-level sorting algorithms so if the microcontroller that controls the
sensor cannot connect to the eBox, we will need to connect it to a development PC
instead.
3.4 Non-Functional Requirements
3.4.1 Security (Katherine Kenyon)
There are two main areas of concern with regards to securing the Surface Water
Detection System; hardware and software. Securing the hardware involves ensuring the
integrity of the ruggedized housing unit and the components inside. The ruggedized
housing unit is designed to protect the inside components and withstand normal weather
Surface Water Detection System (SWDS) Prototype Product Specification 27
conditions. Concerns for the ruggedized housing unit include: sabotage, vandalism, and
accidents. Sabotage occurs when a person illegally tampers with the functioning of the
system. Vandalism refers to the illegal modification of the ruggedized housing exterior to
affect its appearance but not its functioning. Potential accidents include environmental
damage from extreme weather conditions like a hurricane - or collision with moving
automobiles. Vandalism, sabotage, and accidents can all be inhibited by placing the
housing unit in a secure location as far away from traffic as possible and out of reach of
potential criminals.
Since the software components do not collect personal or private information
security concerns are minimal. The software must be user-access protected to provide
customized views to each type of user. The data does not need to be encrypted on the
server because hacking attempts are unlikely and even if they do occur the stored data is
public information.
3.4.2. Maintainability (Cassandra Rothrauff)
The two main things that need to be maintained for the SWDS are the ultrasonic
sensors and how to plan and maintain the data on the servers. The sensors can be
physically stolen and broken due to bad weather. It is necessary to restore the failed
product by contacting the local service station. The station will have electric engineers on
the spot that will need to be equipped with the extra parts. Apart from replacing the parts,
maintaining a database is constantly being monitored. Maintainability is achieved by
modifying the software. Improvement and software changes in the environment will help
monitor the database system. The employees located at each station will need to be fully
knowledgeable of the software and how to fix the product.
Surface Water Detection System (SWDS) Prototype Product Specification 28
3.4.3 Reliability (Chris Meier)
The Surface Water Detection System’s prototype must be available 24/7 in order
to accurately maintain the updated weather conditions information for the user GUI. In
terms of the Insurance Agency and City GUIs, the availability can be somewhat more
flexible. The sensor and microcontroller must be protected from the elements to insure
this, by using a ruggedized housing. In addition, if the sensor data becomes erroneous and
continuously misreads then a debugging procedure will be initiated and if this fails to
remedy the problem, a technician will have to visit the sensor on site for manual
troubleshooting. If the sensor or any of its components were to become compromised, it
would no longer be able to maintain updated conditions and could create a problem. The
SWDS Data Center will annually back up all data in the database to another disk, as a
safeguard against any data corruption or disk failure.