Docstoc

lab2

Document Sample
lab2 Powered By Docstoc
					LAB 2 – Surface Water Detection System Product Specification                   1


Running head: LAB 2 – Surface Water Detection Product Specification




                Lab 2 – Surface Water Detection System Product Specification

                                    Marissa Hornbrook

                                         CS411W

                                      Professor Price

                                 Old Dominion University

                                      March 21, 2011

                                       Version Two
LAB 2 – Surface Water Detection System Product Specification                                                                              2


                                                  TABLE OF CONTENTS

1     INTRODUCTION..................................................................................................... 3
    1.1     Purpose................................................................................................................ 3
    1.2     Scope ................................................................................................................... 4
    1.3     Definitions, Acronyms, and Abbreviations ........................................................ 5
    1.4     References ........................................................................................................... 7
    1.5     Overview ............................................................................................................. 7
2     GENERAL DESCRIPTION .................................................................................... 8
    2.1     Prototype Architecture Description .................................................................... 8
    2.2     Prototype Functional Description ....................................................................... 9
    2.3     External Interfaces ............................................................................................ 11
3     SPECIFIC REQUIREMENTS .............................................................................. 13
    3.1     Functional Requirements .................................................................................. 13
    3.2     Performance Requirements ............................................................................... 17
    3.3     Assumptions and Constraints ............................................................................ 17
    3.4     Non-Functional Requirements .......................................................................... 20


                                                       LIST OF FIGURES

Figure 1. Major Funtional Component Diagram ................................................................ 7
Figure 2. Closed System Functional Breakdown ............................................................... 9
Figure 3. Networked System Functional Breakdown......................................................... 9


                                                        LIST OF TABLES

Table 1. Effects of Assumptions, Dependencies, and Constraints on Requirements ....... 18
LAB 2 – Surface Water Detection System Product Specification                                     3


1    INTRODUCTION

1.1. Purpose
    The intention of this paper is to serve as a technical introduction and overview of the Surface

Water Detection System (SWDS) prototype, detailing both the societal issue that has been

identified, and the corresponding solution. During heavy rainfall and flooding, it is not

uncommon to find that some drivers have endeavored to drive through a flooded portion of road

and have become stuck. This occurs when water levels on the road are high enough to reach the

vehicles’ electric system, causing it to short-circuit and shut down. Currently, many roadways

that are prone to flooding lack a city controlled, contiguous alert system to warn drivers of

hazardous water levels. Such a system could assist drivers in preventing said vehicle damage and

personal injury in cases where they attempt passage through flooded sections of road. This

negative impact is what our team aims to eradicate through the creation of the SWDS via its

hardware and software components shown through prototyping. We will demonstrate this

feasibility through comprehensive technical documentation of our prototype hardware and

software solutions.

    A basic closed system consists of an ultrasonic sensor and a microcontroller, which are

plugged into an embedded development machine. The sensor sends a signal to a road sign that

will flash when the water reaches a hazardous level. The networked system entails greater

complexity because it consists of multiple sensors that are connected, and which report water

depth to a centralized location for archival and manipulation by user applications. The

applications we aim to create include the main page of the product website, which will feature a

Bing Maps™ component for the general public to track water depth, RSS feeds, and an

administrative web application for end users.
LAB 2 – Surface Water Detection System Product Specification                                         4


   As a team, we have identified our primary target market as local city government. We

believe that in communicating with city engineers to find a solution that works best for their

individual needs, we can customize a solution and submit our idea through a bid proposal. We

have also identified an alternative customer, being the auto insurance industry leaders. Insurance

agencies may be able to take advantage of our product to lower the annual cost of policyholder

claims, as well as decrease the rate of auto insurance fraud.

1.2. Scope

   The scope of the prototype during this stage of development is designed to demonstrate that

the concept is feasible to implement, and the product website/user applications are functional as

well as user-friendly. It allows us to show what is possible within a smaller scope than the real-

world implementation, to serve as proof of concept. In order to demonstrate this, it is essential

for the SWDS team to eliminate extraneous components of the networked solution, namely the

existing network to tie into. We will be operating our prototype demonstration in a simulation

environment to fill the void where physical implementation is not practical. The overall

objectives for this project are to demonstrate that: The ultrasonic sensor functions properly by

accurately sensing water depth, relaying a message to trigger the road sign, filtering out

erroneous data, and properly archiving it for report retrieval.

   Our prototype will consist of the sensor and microcontroller attached to an eBox (eBox-

3310A-MSJK) embedded development machine, which will act as the closed system. The

networked option will be shown when the eBox is connected to a development PC, which will

display our database and show the simulated scenarios and their results update on the product

website.
LAB 2 – Surface Water Detection System Product Specification                                      5


1.3      Definitions, Acronyms, and Abbreviations

      The SWDS team has collaborated and identified a set of key terms that is specific to our

prototype, and which will be useful when evaluating our product. They are listed alphabetically

as follows:

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.

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.
LAB 2 – Surface Water Detection System Product Specification                                     6


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.

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
LAB 2 – Surface Water Detection System Product Specification                                       7


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.4      References

            Parallax Industrial Sensors Retrieved March 17, 2011, from http://www.parallax.com
            CS 410 Documentation and Diagrams
            CS411 Lab 1 Documentation and Diagrams

1.5      Overview

      The information provided in the remaining sections of this document includes a detailed

description of the hardware, software, and external interface architecture of the SWDS prototype,

as well as the key features and parameters that will be used to control, manage, or establish that

feature. Also, information about the performance characteristics of each feature in terms of

outputs, displays, and user interaction is documented. To give a pictorially representation of the

SWDS solution, the major functional components are shown in Figure 1 to demonstrate how

they relate to one another and interact.

                                        Onsite Data       Administrative
                Closed System                                               Public Web
                                        Acquisition           Web
                Remote Device                                                 Server
                                          Device           Application



               Networked System            Data Acquisition
                                                                     Database
                Remote Device                   Host



                         Figure 1. Major Functional Component Diagram




                                  [This space intentionally left blank]
LAB 2 – Surface Water Detection System Product Specification                                        8


2     GENERAL DESCRIPTION

        The prototype of the Surface Water Detection System will focus on the innovative design

of a simulated dynamic sensor network that will read, display, and store simulated water depth.

The prototype will be largely simulated, but will have a physical sensor, eBox development

machine, microcontroller, and development PC as part of the demonstration. All aspects of the

prototype that are to be simulated will go through a series of tests and display its competency

with an inclusive test suite.

2.1. Prototype Architecture Description
    As demonstrated in the introduction and key features description, this solution is extremely

hardware intensive. It relies on physical hardware pieces like the ultrasonic sensor,

microcontroller, server, eBox, and associated wiring to perform the majority of the work. The

software components include the product website, filtering logic, as well as the user applications

mentioned previously. The filtering logic is a necessary part of the software because without it,

the data would be inaccurate due to outside elements influencing the reading. For example, the

sensor may be placed in a particular section of road where cars are stopped in a traffic jam. The

sensor will function properly, but the distance it will read is to the top of the nearest car, not the

ground. This is an example of a reading we would discard as being erroneous data. Our software

will feature the capability to throw out this type of inaccuracy.

    Another case that needs to be accommodated and tested for is that of weather elements other

than rain. If a sensor reads in data that appears to be a rain measurement yet the outside

temperature is below 32°, it is most likely snow that is being detected. The filter logic will also

accommodate these scenarios as to report the most accurate information. The snow example will

also change the icon from rain to snow when displayed on the Bing Maps™ part of the product
LAB 2 – Surface Water Detection System Product Specification                                9


website. These things should be demonstrated in the final prototype of the SWDS. The team has

identified six major components of the prototype, which are listed as follows:

   Closed System Remote Device (CSRD)
   Networked System Remote Device (NSRD)
   Data Acquisition Host (DAH)
   Administrative Web Application (AWA)
   Public Web Server (PWS)
   Onsite Data Acquisition Device (ODAD)

2.2. Prototype Functional Description
     1. The Closed System Remote Device (CSRD) is responsible for the following tasks, as

        listed and demonstrated in Figure 2.

         Storing measurement offset
         Obtaining data from sensor
         Processing data (filtering algorithm)
         Triggering flashing road sign
         Logging data
                                         Device Configuration   Store   Onsite Data
                         Closed System
                                                                        Acquisition
                         Remote Device      Logged Data         Get       Device


                           Figure 2. Closed System Functional Breakdown

     2. The Networked System Remote Device (NSRD) will feature the following functionality,

        and its relationship is documented in Figure 3.

         Storing measurement offset
         Obtaining data from sensor
         Processing data (filtering algorithm)
         Triggering flashing road sign
         Installing software updates
LAB 2 – Surface Water Detection System Product Specification                                           10

                 Administrative Store
                    Web
                  Application    Get           Device Configuration


                                 Sensor Data
                                                                                          Public Web
                                                   Database           Sensor Data   Get
                              Sensor Data                                                   Server
                      Store
                                               Device Configuration
                 Data Acquisition
                      Host                          Get
                                                 Networked
                              Sensor Data      System Remote
                                                   Device


                       Figure 3. Networked System Functional Breakdown


     Regarding points three, four, and five, they will act as the centralized control center.

     3. Data Acquisition Host (DAH) will do the following:

        Receive data
        Log data

     4. Administrative Web Application (AWA) is responsible for:

        Viewing historical data
        Setting measurement offset (remote management console)
        Updating remote device software (remote management console)

     5. The Public Web Server (PWS) will be responsible for housing the database which will

       be used to produce the following functionality:

        News Feed
        Bing Maps
        RSS

     6. The Onsite Data Acquisition Device (ODAD) machine will handle the following tasks.

        Store logged data
        Set measurement offset (onsite management console)
        Update remote device software (onsite management console)
LAB 2 – Surface Water Detection System Product Specification                                        11


   The Closed System Remote Device (CSRD) refers to the sensor, microcontroller, and eBox,

and its job is to simply take distance measurements, record the data, and activate the flashing

road sign as appropriate. The Networked System Remote Device (NSRD) does the same, except

it transfers the data over a network to be stored in a database for archival and retrieval. The

results are displayed in real-time through this option because the data is being sent automatically

to the public web site. The Data Acquisition Host (DAH) in the closed system refers to the server

that collects the data to be stored in the database for archival/retrieval. The Administrative Web

Application (AWA) is the private user portion of the product website which houses a report

generator for the client to specify and view records. The Public Web Server (PWS) is responsible

for housing the database, in which measurements are stored for use on the public website and

report retrieval through the administrative website. The Onsite Data Acquisition Device (ODAD)

is the machine that connects to the CSRD to retrieve data from the closed system, since the

measurements are not being sent out over a network. Each of these elements are elaborated on in

section 2.1 following. The prototype will also feature a simulator, which is responsible for

demonstrating the various scenarios in which the SWDS should be tested. To be thorough, it

should be tested in extreme cases, average cases, and non-valid cases to demonstrate how the

system will handle every possible input.

2.3. External Interfaces
   This section identifies the physical and logical interfaces used within and by the prototype.

The characteristics of each type of interface used and the type of information transferred are be

described below, as they relate to the SWDS. This section will detail not only the hardware

interfaces, but the software and user components as well.
LAB 2 – Surface Water Detection System Product Specification                                     12


2.3.1 Hardware Interfaces

    The SWDS prototype will feature several hardware components, as our solution is extremely

hardware intensive. The major hardware pieces include:

       Ultrasonic sensor

       Microcontroller

       eBox embedded development machine


The sensor and microcontroller work together when plugged into the eBox development

machine, to act as the CSRD portion of the SWDS solution. Together they record distance

measurements and store them internally. To retrieve the data that is stored with the CSRD, the

ODAD comes into play as the next hardware interface. It will be connected (wired or wireless,

depending on the preference and specification of the client) to the CSRD to obtain the data that is

stored on the eBox. When the NSRD is deployed, the hardware interface is that of the DAH as it

transfers the data to the host to be stored on the PWS in the database that will be created. These

interfaces are outlined in further detail later in this text.

2.3.2 Software Interfaces

    The software interfaces in this solution are seen in several pieces as listed below and outlined

in the following paragraph.

       Filtering logic

       DAH transmittal

       SWDS database on the PWS

       Bing Maps™ API

       RSS feed
LAB 2 – Surface Water Detection System Product Specification                                      13


The filtering algorithm software will be present on the microcontroller when either the CSRD or

NSRD are in effect, and will allow for accurate data when acquired by the ODAD or the

database, depending on the system used. The DAH interface as part of the NSRD will feature the

ability to transmit the data over a network to be stored in a database on the PWS for future

retrieval. The Bing Maps™ API and RSS feed software components will be the portion that the

end user directly interfaces with on a regular basis.

2.3.3 User Interfaces

    The mechanisms by which users will interact with the software portion of the SWDS solution

will vary, depending on the user. In the case of the general public user and city employee user,

they will most likely be accessing our data through a computer or mobile device. The computer

will employ a standard interface consisting of a monitor for viewing, a mouse for

maneuverability and selection, and a keyboard for data entry. Considering a mobile device, a

Smartphone will be used to view either the SWDS website in the mobile browser or a mobile

application that the SWDS team will have created. The product would be viewed on a cell phone

screen with either physical keys or a touch screen for maneuverability and data entry. In the case

of the city worker whose responsibility is to retrieve the data from a CSRD through an ODAD,

they will be interfacing with the product through a separate machine specifically designed to

connect to the CSRD and retrieve that information. This could be through a custom designed

machine or a standard laptop, depending on the client specification and request.

3    SPECIFIC REQUIREMENTS

    This section contains the detailed requirements for the SWDS, listing each requirement under

its own subsection. They are grouped logically, in areas according to their functionality along

with descriptions of each task. The information documented in these sections details the
LAB 2 – Surface Water Detection System Product Specification                                       14


functions in a more specific manner, to get a deeper look at what each piece of the solution will

be performing and the method by which it will do so.

3.1 Functional Requirements

    The major functional components that have been identified and grouped into subsections are

listed below in the order they will be presented. The issues that are clarified for a better

understand of the product are listed in standard requirements documentation fashion, with intent

to define the exact responsibility of the section in question.

   CSRD

   ODAD

   NSRD

   DAH

   AWA

   PWS

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.
LAB 2 – Surface Water Detection System Product Specification                                  15


   4) The CSRD will activate a flashing warning sign on the road when the incoming
      measurements record a depth that sets of 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 (Example, corner of Main St. and Route 44)

       c) Latitude/Longitude: The global position utilized by Bing Maps™

       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.
LAB 2 – Surface Water Detection System Product Specification                                     16


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 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.

   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.
LAB 2 – Surface Water Detection System Product Specification                                    17


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 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 Google 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

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
LAB 2 – Surface Water Detection System Product Specification                                     18


3.3 Assumptions and Constraints (Jill Mostoller)

    There are various assumptions, constraints and dependencies in place for the prototype

development. Table 1 contains a list of each assumption, dependency and constraint. The table

also lists a brief description of the effects on the prototype requirements.

Condition                         Type                          Effect on Requirements
A simulated sensor will not       Constraint                    Bounds the problem of
stop functioning during a                                       malfunctioning sensors.
simulation.
A customized web interface        Constraint                    Bounds the problem of
will not be used for each user                                  designing multiple web
type.                                                           interfaces with different
                                                                functionalities.
A method will be developed        Constraint                    Bounds the problem of
by the customer to transmit                                     transmitting the data archives
data locally from a closed                                      and updating the software of
system.                                                         the closed system.
The city already has a network    Constraint                    Bounds the problem of setting
set up that we can piggyback.                                   up a network for the city.
Data transmission delay will      Assumption                    Allows us to assume data is
not be large enough to effect                                   relevant and will be effective
real time results.                                              in alerting drivers in time.
Data collected is not sensitive   Assumption                    Allows for minimal data
in any way.                                                     security.
The microcontroller will not      Assumption                    Allows us to only develop
perform any data processing.                                    high-level algorithms for the
                                                                centralized data center.
The user will not look up data    Assumption                    Allows for minimal error
archives for invalid dates.                                     checking when processing
                                                                data archive requests.
Any spike in data will be         Assumption                    Allows us to assume the data-
regarded as an obstruction                                      sorting algorithm is correct.
(such as a vehicle) and will be
thrown out.
The eBox will be able to          Dependency                    The prototype will rely on the
support the microcontroller.                                    development PC to run the
                                                                data sorting algorithms.
The physical sensor is            Dependency                    The prototype will rely
available and functioning.                                      exclusively on simulated
                                                                sensors.

        Table 1. Effects of Assumptions, Dependencies, and Constraints on Requirements
LAB 2 – Surface Water Detection System Product Specification                                      19


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 2 – Surface Water Detection System Product Specification                                         20


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 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 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
LAB 2 – Surface Water Detection System Product Specification                                       21


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.

3.4.2. Maintainability (Cassie 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.

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
LAB 2 – Surface Water Detection System Product Specification                                      22


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.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:8/19/2011
language:English
pages:22