Lab II – Surface Water Detection System Specification
Running Head:
Lab II – Surface Water Detection System Specification
Lab II – Surface Water Detection System Product Specification Outline
CS 411W Lab II
Prototype Product Specification
For
Surface Water Detection System
Prepared by: Eric Boyd, Green Team
Date: 3/21/2011
1
Lab II – Surface Water Detection System Specification
2
TABLE OF CONTENTS
1
2
3
INTRODUCTION ...................................................................................................................5
1.1
Purpose ..............................................................................................................................5
1.2
Scope .................................................................................................................................5
1.3
Definitions, Acronyms, and Abbreviations .......................................................................8
1.5
Overview .........................................................................................................................11
GENERAL DESCRIPTION ..................................................................................................11
2.1
Prototype Architecture Description .................................................................................11
2.2
Prototype Functional Description....................................................................................13
2.3
External Interfaces...........................................................................................................15
SPECIFIC REQUIREMENTS ..............................................................................................23
3.1
Functional Requirements.................................................................................................23
3.2
Performance Requirements .............................................................................................27
3.3
Assumptions and Constraints ..........................................................................................28
3.4
Non-Functional Requirements ........................................................................................32
APPENDICES ...............................................................................................................................34
Appendix A
Hardware Listing ..............................................................................................34
Appendix B
Software Listing ................................................................................................34
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
3
LIST OF FIGURES
Figure 1. Major Functional Component Diagram .........................................................................13
Figure 2. Networked-System Functional Breakdown ...................................................................14
Figure 3. Closed-System Functional Breakdown ..........................................................................14
Figure 4. Hardware Component Diagram .....................................................................................16
Figure 5. Parallax Ultrasonic Sensor .............................................................................................17
Figure 6. EBox Front and Back View ...........................................................................................18
Figure 7. Software Component Diagram.......................................................................................19
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
4
LIST OF TABLES
Table 1. Prototype vs. Real-World Implementation Comparison....................................................7
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements ....................29
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
1
5
INTRODUCTION
Section one of this document provides an introduction to the Surface Water Detection
System, and identifies its purpose, the scope of its benefits and objectives, and establishing a
common nomenclature of definitions, acronyms, and abbreviations to be used in the remainder of
this document. Section one concludes with an overview of the remaining sections of this
document.
1.1
Purpose
The Surface Water Detection System (SWDS) is combination of hardware and software
components used to alert drivers of hazardous road conditions caused by inundations of water on
roadways. Drivers are alerted at the inundated location via a flashing warning sign triggered by a
small computer and ultrasonic sensor installed at a notoriously hazardous section of roadway.
The SWDS is marketed toward municipal jurisdictions such as a city or state to provide a higher
level of safety on its roadways.
1.2
Scope
The SWDS is designed allowing for two possible applications; a closed-system design for
rural areas, and a networked-system design for larger metropolitan areas with any number of
hazardous locations caused by frequent inundations of water due to snow, rain, or storm surges.
The main objective of the SWDS is to provide immediate warning of a hazardous section of
roadway caused by inundation. Often, drivers are not able to adequately identify a portion of
roadway that is impassible for their vehicle. The SWDS hopes to mitigate situations where
drivers try to pass these flooded areas, and become stuck, resulting in property damage or even
personal injury.
Lab II – Surface Water Detection System Specification
6
The second objective of the SWDS aims to use technology such as the World Wide Web
in order to provide a means for drivers to check frequently inundated stretches of road along their
route before leaving their home or office. Technologies such as geo-location services and
mobile syndication technologies can be used to provide an effective information and alert system
for today’s tech-savvy drivers.
The prototype design of the SWDS as described in this document will demonstrate these
main capabilities of the overall SWDS design. The major differences between this prototype
design and the commercial application of the SWDS involve: simulating a network infrastructure
versus utilizing a large-scale network in a metropolitan area, simulating certain physical
components along the network such as network switches, and using proof of concept hardware
for the ultrasonic sensor and embedded computer since ruggedized housings and industrial
strength sensors will not be necessary. The differences between the prototype and the
commercial implementation are further detailed in Table one below.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
Feature
Sensor
Microcontroller
Multi-Sensor
Network
Centralized Data
Center
Report Generator
Bing Maps™
application
RSS
7
Real World Implementation
Prototype
One sensor available for closed system;
multiple sensors for networked system.
Ruggedized housing to protect from the
elements.
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 sensor that
detects and sends data to the
simulation computer in the
closed system demonstration.
Will feature one
microcontroller that receives
data from a single sensor and
sends it to the development
PC.
This will be simulated for the
networked demonstration.
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.
Data collection server that stores the info
from the microcontroller
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.
Featured on the product website with realtime water depth measurements in inches.
Included on the product website for entities
to subscribe.
Will be simulated.
This is simulated in a GUI on
the development computer.
Will be simulated on the
product website via a GUI.
An icon will be featured on
the product website but will
not be functional.
Table 1. Prototype vs. Real-World Implementation Comparison
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
1.3
8
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.
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.
Lab II – Surface Water Detection System Specification
9
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.
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.
Lab II – Surface Water Detection System Specification
10
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 inturn, 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.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
1.4
11
Overview
This product specification outlines the hardware and software configuration, external
interfaces, and the capabilities and features of the Surface Water Detection System prototype.
Sections two and three of this document provide a general description of the prototype, a
description of the prototype’s architecture, the prototype’s major functional components, the
prototype’s functional and non-functional requirements, and any assumptions and constraints of
the prototype design.
2
2.1
GENERAL DESCRIPTION
Prototype Architecture Description
This section outlines each of the major functional components of the SWDS that
comprise its overall high-level architecture, and the actual hardware used in the implementation
of the prototype design.
2.1.1 Closed-System Remote Device (CSRD)
This component obtains the sensor measurement data from the ultrasonic sensor, and logs
the data to its local storage. In addition, this component stores its own configuration data, which
is configurable through a program also supplied by this component. This component of the
prototype will be demonstrated using the Microsoft eBox platform for embedded devices, and a
Parallax ultrasonic sensor.
2.1.2 Onsite Data Acquisition Device (ODAD)
This component interacts with the CSRD and allows the operator to download sensor
measurement data from the CSRD’s local storage, and configure the CSRD using the CSRD’s
built-in configuration program. This component of the prototype will be demonstrated using a
laptop connected to the Microsoft eBox via Ethernet connection.
Lab II – Surface Water Detection System Specification
2.1.3 Networked-System Remote Device (NSRD)
This component is essentially the same as the CSRD; it differs only in that it sends the
sensor measurement data that it collects over a network to be stored in a centralized database.
Also, network operators can set the configuration for a particular NSRD by updating its
configuration table in the centralized database, where the NSRD will check for new
configuration data if it successfully establishes network connectivity. This component of the
prototype will be demonstrated using the Microsoft eBox for embedded devices, and a laptop
connected to the eBox using an Ethernet connection.
2.1.4 Data Acquisition Host (DAH)
This component collects sensor measurement data from any number of NSRDs on the
network, and logs that data to a centralized database. This component of the prototype will be
demonstrated by a laptop running a program that listens for the sensor data being sent from the
Microsoft eBox connected via Ethernet connection.
2.1.5 Administrative Web Application (AWA)
This component provides an interface for network operators to monitor the status of
NSRDs on the network, configure NSRDs by updating a configuration table in the centralized
database, and querying the centralized database for historical sensor measurement data. This
component of the prototype will be demonstrated by a laptop that hosts a web application, a
database, and that is connected to the Microsoft eBox via Ethernet connection.
[This space left intentionally blank]
12
Lab II – Surface Water Detection System Specification
13
2.1.6 Public Web Server (PWS)
This component is a publicly available web server. The web server hosts a website with a
news feed section that alerts users to hazardous conditions, an interactive Bing Maps section that
displays the real-time status of the NSRDs on the network, and an interface for users to create a
custom alert by selecting specific NSRDs to be included in their alert.
2.2
Prototype Functional Description
This section describes the functional components of the SWDS by providing a summary
of each major functional component. Figure one illustrates these major functional components
and how they relate to one another. Figure two illustrates the type of data being transmitted
between each of the components over the networked-system.
Closed System
Remote Device
Networked System
Remote Device
Onsite Data
Acquisition
Device
Administrative
Web
Application
Data Acquisition
Host
Public Web
Server
Database
Figure 1. Major Functional Component Diagram (MFCD)
Lab II – Surface Water Detection System Specification
Administrative Store
Web
Get
Application
14
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 2. Networked-System Functional Breakdown
2.2.1 Closed-System Remote Device (CSRD)
The CSRD function provides the capability to record sensor measurement data, storing
that data locally on the embedded device, and providing the necessary software to record
measurements, and allow for onsite operators to configure the CSRD. Figure three illustrates the
functional breakdown of the CSRD.
Closed System
Remote Device
Device Configuration
Store
Logged Data
Get
Onsite Data
Acquisition
Device
Figure 3. Closed-System Functional Breakdown
2.2.2
Onsite Data Acquisition Device (ODAD)
The ODAD function allows an onsite operator to configure the CSRD and download
sensor measurement data from the CSRD’s local storage.
Lab II – Surface Water Detection System Specification
15
2.2.3 Networked-System Remote Device
The NSRD function encompasses the functions of the CSRD but also utilized a network
to transmit its sensor measurement data to the Data Acquisition Host (DAH) for storage in the
centralized database. Figure three illustrates the networked-system.
2.2.4
Data Acquisition Host (DAH)
The DAH function collects sensor measurement data from the NSRDs on the network
and stores that data in the centralized database.
2.2.5 Administrative Web Application (AWA)
The AWA function allows network operators to monitor NSRD status, remote
configuration of NSRDs, and querying the centralized database for historical sensor
measurement data.
2.2.6
Public Web Server (PWS)
The PWS function provides a website with a news feed of any current hazardous NSRD
status, an interactive Bing Maps section displaying the real-time status of NSRDs on the
network, and the ability to configure a custom alert.
2.3
External Interfaces
This section describes the physical and logical interfaces that make up the SWDS
prototype design.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
2.3.1 Hardware Interfaces
The following section describes the hardware components used in the SWDS prototype
design, and the physical connections between each of the hardware components. Figure four
illustrates the major hardware components.
Figure 4. Hardware Component Diagram
[This space left intentionally blank]
16
Lab II – Surface Water Detection System Specification
17
2.3.1.1 Parallax Ultrasonic Sensor
The Parallax Ultrasonic Sensor uses ultrasonic sound waves to measure the distance
between itself and any surface that it is aimed at. This sensor will be used to measure the height
of an inundation of water. The Parallax Ultrasonic Sensor will be connected to the Microsoft
eBox via USB adapter. Figure five shows a picture of the Parallax Ultrasonic Sensor.
Figure 5. Parallax Ultrasonic Sensor
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
18
2.3.1.2 Microsoft eBox for Embedded Devices
The Microsoft eBox for Embedded Devices is essentially a compact computer capable of
running software for devices connected to it such as the Parallax Ultrasonic Sensor. This
computer is capable of storing sensor measurement data, and providing a limited set of software
that allows onsite operators the ability to download data from its local storage and configure any
settings needed to operate the eBox and sensor. The eBox will connect to the Parallax Ultrasonic
Sensor via USB, and to the Development Computer via Ethernet cable. Figure six shows the
front and back views of the Microsoft eBox.
Figure 6. EBox Front and Back View.
2.3.1.3 Development Computer (Laptop)
The Development Computer is a standard laptop that will be used to plug-in to the
Microsoft eBox to demonstrate how data can be collected from the eBox, and also how to
configure the eBox and sensor. The Development Computer will also be used to simulate
network conditions, and will host the Administrative Web Application, Public Web Server, and
centralized database. The Development Computer will connect to the eBox via Ethernet cable.
Lab II – Surface Water Detection System Specification
19
2.3.2 Software Interfaces
The following section outlines the software interfaces involved in the SWDS prototype
design, the hardware that each software component resides on, and the information transmitted
between these software components.
Remote Device
Development PC
Data
Acquisition
Client
Data
Acquisition
Host
Control
Software
Database
User
Applications
Figure 7. Software Component Diagram
2.3.2.1 Sensor Measurement and Warning Sign Program
The Sensor Measurement Program resides on the eBox and controls the actions of the
Parallax Ultrasonic Sensor and warning sign. This program runs continuously checking for any
changes in the sensor’s measurement readings. An increment is specified in the program’s
configuration file, and no change is recorded unless the increment setting is surpassed. A
threshold is specified in the program’s configuration file, and triggers the warning sign if the
threshold is met or surpassed. Likewise, the warning sign is turned-off once the measurement
returns below the threshold. This program is also responsible for writing data to the eBox’s local
storage. This program is implemented using C# and the Microsoft .Net Compact Framework.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
20
2.3.2.2 Network Version of the Sensor Measurement and Warning Sign Program
The network version of the program checks for network connectivity to an IP address
specified in the program’s configuration file. If network connectivity is established, the program
is responsible for sending out sensor measurement data over the network to be recorded in a
centralized database. If network connectivity is lost, or if no IP address is specified in the
program’s configuration file, the program will continue to run the closed-system version of the
software. This program is implemented using C# and the Microsoft .Net Compact Framework.
2.3.2.3 Configuration Program for the eBox and Ultrasonic Sensor
This program allows an onsite operator to configure the various settings necessary for the
eBox and Ultrasonic Sensor to operate. This program resides on the eBox and allows an onsite
operator to connect over some network protocol such as Telnet or HTTP to access the program.
This program is implemented using C# and the Microsoft .Net Compact Framework.
2.3.2.4 Data Acquisition Host Server
This program resides on the Development Computer and is used to simulate physical
hardware that would reside on the commercial version of the SWDS. This program is responsible
for listening to network communications from the eBox (the sensor measurement data), and
writing that data to a centralized database. This program is implemented using C# and the
Microsoft .Net Framework, and LINQ (Language Integrated Query) to connect to and
manipulate the centralized database.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
21
2.3.2.5 Centralized Database
The Centralized Database is used in the network application of the SWDS to record
sensor measurement data from the networked eBoxes, provide a centralized location for eBox
configuration data, and an interface for network operators to query historical sensor
measurement data. The database resides on the Development Computer, and is implemented
using Microsoft SQL Server. The database is manipulated using standard SQL statements, and
the Object-Relational Mapping (ORM) tool, LINQ (Language Integrated Query) provided by the
Microsoft .Net Framework for use in C# applications.
2.3.2.6 Administrative Web Application
The Administrative Web Application is a program that is accessed through an internet
browser such as Microsoft Internet Explorer or Mozilla Firefox. The program can be deployed
over the World Wide Web or within a secured intranet. The Administrative Web Application
provides an interface for network operators to monitor the status of the eBoxes on the network,
the ability to configure any eBox by updating the configuration table in the centralized database,
and querying the centralized database for historical sensor measurement data. The
Administrative Web Application is implemented using Microsoft ASP.NET.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
22
2.3.2.7 Public Web Server
The Public Web Server is essentially a program that hosts the public website and web
services available to the general population. This includes a website with a news feed of any
current hazardous conditions, an interactive real-time map of sensor status implemented using
Bing Maps, and an interface allowing users to create customizable alters by selecting any
combination of eBoxes along their route. The Public Web Server is implemented using Microsoft
ASP.NET.
2.3.3 User Interfaces
2.3.3.1 Development Computer (Laptop)
This user interface will give users a graphical view when interfacing with the CSRD’s
configuration program, running the AWA, and accessing the PWS.
2.3.4 Communication Protocols and Interfaces
2.3.4.1 TCP/IP via Ethernet
This protocol is used for communication between the NSRD and the Development
Computer.
2.3.4.2 USB 2.0
This protocol is used to connect the Parallax Ultrasonic Sensor to the Microsoft eBox.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
3
23
SPECIFIC REQUIREMENTS
This section contains the detailed requirements for the SWDS.
3.1
Functional Requirements (Eric Boyd/Marissa Hornbrook)
3.1.1 Closed-System Remote Device (CSRD)
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 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 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 eastablish a location (Example, corner of Main St. and Route 44)
c. Latitude/Longitude: The global position utilized by Bind MapsTM.
Lab II – Surface Water Detection System Specification
24
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.
7. The CSRD provides a program that allows an onsite operator to configure the CSRD, and
copy the CSRD’s local storage of sensor measurement data via some network protocol
such as Telnet or HTTP.
3.1.2 Onsite Data Acquisition Device (ODAD)
This function defines interactions with the CSRD to collect sensor measurement data form
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 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.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
25
3.1.3 Networked-System Remote Device (NSRD)
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 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
overt the network to the Data Acquisition Host (DAH).
3.1.4 Data Acquisition Host (DAH)
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.
[This space let intentionally blank]
Lab II – Surface Water Detection System Specification
26
3.1.5 Administrative Web Application (AWA)
This function provides administrative services for querying the centralized database, and
monitoring and configuring NSRDs on the network. The following functional requirements shall
be provided:
1. The AWA provides a graphical display of the status of the NSRDs on the network.
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 data and time range.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
27
3.1.6 Public Web Server (PWS)
This function provides a publicly 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 Google 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
Both shall meet the following performance requirements:
1. Accurately read distances from one inch to eight feet in one inch increments.
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.
Lab II – Surface Water Detection System Specification
28
3.2.2 Data Acquisition Host (DAH)
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 and Constraints (Jill Mostoller)
There are various assumptions, constraints and dependencies in place for the prototype
development. Table two 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]
Lab II – Surface Water Detection System Specification
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 2. Effects of Assumptions, Dependencies, and Constraints on Requirements
29
Lab II – Surface Water Detection System Specification
30
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 indicate
an obstruction, such as a vehicle, in the road and should be caught by our data-sorting 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 time-span 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
Lab II – Surface Water Detection System Specification
31
public users. For the purpose of 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 sensor.
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.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
3.4
32
Non-Functional Requirements
This section describes the non-functional requirements of the SWDS.
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 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 it’s
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.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
33
3.4.2 Maintainability (Cassandra Rothrauf)
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.
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.
[This space left intentionally blank]
Lab II – Surface Water Detection System Specification
Appendices
Appendix A: Hardware Listing
1. Parallax Ultrasonic Sensor
2. Microsoft eBox for Embedded Devices
3. Laptop (as Development Computer)
4. USB Cable
5. Ethernet Cable
Appendix B: Software Listing
1. Microsoft Windows 7 Compact Edition
2. Microsoft .Net Compact Framework
3. Microsoft .Net Frameworks 3.5 and 4
4. Microsoft Visual Studio 2010 Professional Edition
5. Microsoft SQL Server 2008
6. Microsoft SQL Server Management Studio
7. Mercurial Software Configuration Management
8. NUnit Unit Test Software for the .Net 3.5 Framework and Unit Test Runner GUI
9. Ninject Dependency Injection/Inversion of Control
34