Introduction - Old Dominion University · Web viewThe basic closed-system version of the flood...

Running Header: Lab 2 Surface Water Detection System Prototype Product Specification 1

CS 411 Lab II

Prototype Product SpecificationFor

SWDS

Prepared by: Chris Meier, Green Group

Date: 3/21/2011


Table of Contents

1. Introduction..............................................................................................................................4

1.1 Purpose..............................................................................................................................4

1.2 Scope.................................................................................................................................4

1.3 Definitions, Acronyms, 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...................................................................................11

2.3 External Interface............................................................................................................12

2.3.1 Hardware Interface..................................................................................................13

2.3.2 Software Interface....................................................................................................13

2.3.3 User Interface...........................................................................................................13

2.3.4 Communications Protocols and Interfaces...............................................................13

3 Specific Requirements (Total Collaboration)........................................................................14

3.1 Functional Requirements (Eric Boyd)............................................................................14

3.1.1 Closed-System Remote Device (CSRD) (Marissa Hornbrook)..............................14

3.1.2 Onsite Data Acquisition Device (ODAD)...............................................................14

3.1.3 Networked-System Remote Device (NSRD)..........................................................16

3.1.4 Data Acquisition Host (DAH).................................................................................17

3.1.5 Administrative Web Application (AWA)................................................................17

3.1.6 Public Web Server (PWS).......................................................................................17

3.2 Performance Requirements (Robert Dayton)..................................................................18

3.2.1 Networked and Closed System Remote Devices: Both shall meet the following performance requirements:....................................................................................................18

3.2.2 Data Acquisition Host (DAH): The DAH shall meet the following performance requirements:.........................................................................................................................18

3.3 Assumptions and Constraints (Jill Mosteller).................................................................19

3.3.1 Assumptions............................................................................................................20

3.3.2 Constraints...............................................................................................................21


3.3.3 Dependencies...........................................................................................................21

3.4 Non Functional Requirements........................................................................................22

3.4.1 Reliability (Chris Meier)..........................................................................................22

3.4.2 Maintainability (Cassie Rauthroff)..........................................................................22

3.4.3 Security (Katherine Kenyon)...................................................................................23

4 Appendix................................................................................................................................24

List of Figures

Figure 1. Major Functional Components Diagram.........................................................................9

Figure 2. Networked System Functional Breakdown...................................................................12

Figure 3. Closed System Functional Breakdown..........................................................................12

Figure 4. Technical Overview.......................................................................................................24

Figure 5. Hardware Component Diagram.....................................................................................24

Figure 6. Hardware Overview.......................................................................................................24

Figure 7. Software Component Diagram......................................................................................25

Figure 8. General Public GUI.......................................................................................................25

Figure 9. City User GUI................................................................................................................26

Figure 10. Insurance Agency GUI................................................................................................26

List of Tables

Table 1. Prototype vs. Real-World Implementation Comparison.................................................11

Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements....................20

[This space left intentionally blank]


1. Introduction

Heavy flooding of roadways can present many problems for traffic. Countless motorists fall

victim to what seems like shallow water only to become trapped when their vehicles fail to pass

through much deeper water. The damage a vehicle can have after being caught in a flooded area

can be potentially devastating. The cost of replacing an engine that has taken in water or simply

replacing parts that have become water logged can be expensive. In addition to compromising

frame integrity and the problems that might arise from it later on (rust damage). When this sort

of problem arises, it is up to public works to rescue those unfortunates who are caught off guard.

When flooding occurs, many a motorist face the problem of not being able to get from one point

to another without the risk of becoming stranded.

1.1 Purpose

In the last couple of years there have been storms that created severe flooding problems

for the entire city. Many vehicles were left abandoned in the streets, where they had failed to

cross over the water and were forced to leave their vehicles until conditions became suitable for

reclaiming them. Others remained trapped in their homes, unable to travel anywhere due to such

severe flooding. Even the lucky few who had the means to travel were not always lucky enough

to have a route that could lead them to escape.

1.2 Scope

Many roadways that are prone to flooding lack a city controlled contiguous alert system to

warn drivers of dangerous water levels. Such a system could assist drivers in preventing vehicle

damage and personal injury in cases where they proceed through inundated portions of the road.

Surface Water Detection System aims to provide just that, a network of above ground ultrasonic

sensors able to detect water levels in areas prone to flooding. In addition to the sensors, physical

signs placed strategically would warn drivers of dangerous roadways. Supporting this system, a


centralized data center allowing for easy access by user-based applications, allowing for motorist

to find information on blocked roadways and plan accordingly.

1.3 Definitions, Acronyms, Abbreviations

Administrative Web Application (AWA): Multipurpose portal containing management tools

for administering remote devices.

Algorithm: A precise rule or set of rules specifying how to solve a problem.

Annual software license: A legal contract governing the usage of software that is updated once

a year.

Application Programming Interface (API): Software implemented to allow for simpler and

more abstracted interactions with other software.

Baseline package: The basic closed-system version of the flood detection system that includes

the ultrasonic sensor, microcontroller, ruggedized housing, and flashing warning sign. This is

best suited for remote locations where a sensor network would be impractical.

Bid proposal: An explanation of products and services given with an estimated cost.

Bing Maps API: A technology created by Bing that utilizes maps to support a variety of uses,

typically displaying related locations in map form through a web browser.

Centralized data center: The software and hardware that acts a central point for collecting the

sensor data transmissions over a network and recording their values into a database.

Client: Any end-system that is connected to a network.

Closed system: A single ultrasonic sensor, microcontroller, ruggedized housing, and warning

sign set up that has no network interface.

Closed-System Remote Device (CSRD): Combination of components which are in charge of

gathering information and onsite data logging.


Commercial front-end: An entity that provides some means, via website or physical location, to

sell a product. These are direct whose primary goal is to sell its company’s deliverables to a

targeted market.

Data Acquisition Host (DAH): Software component in charge of receiving information from

remote sensors and logging to the database.

Embedded data store: The ability to store data on the microcontroller.

Flooding: An inundated area of roadway that is considered impassible due to an influx of water.

Global Positioning System (GPS): A navigational system that pinpoints latitude and longitude

of a location using stationary satellites.

Graphical User Interface (GUI): A user-friendly interface that allows easy access to an

applications features, which uses a mouse and keyboard as input devices.

Microcontroller: A small computer on a chip that is used to control electronic devices.

Modularized: Development technique which involves breaking a unified process or idea into

coherent segments for the purpose of abstraction or simplicity.

Multi-sensor network: Several sensor installations connected by a network infrastructure that

relay measurements back to a centralized data center.

Network: A system of interconnected electronic components or circuits.

Networked-System Remote Device (NSRD): Combination of components which are in charge

of gathering and communicating information over a network to a centralized location.

Onsite Data Acquisition Device (ODAD): Device capable of configuring the CSRD and

downloading its stored data.

Prototype: Logical step in the development process demonstrating the real world potential of a

concept.


Public Web Server (PWS): Computer that hosts the public website and web services.

Real time data: Information that is collected in the actual time the process is occurring.

Really Simple Syndication (RSS): Formatted XML used to provide subscribers with

information updated on a regular basis.

Risk analysis: Identifying and assessing factors that may compromise the success of a project.

Ruggedized housing: An enclosure designed to protect an electronic device such as a field

sensor from the elements.

Server: A computer used to accept incoming requests and information over a network, and in-

turn, generates and transmits data back to another user or computer (client).

Ultrasonic sensor: A sensor that calculates changes in depth using high frequency sound waves.

URL: Uniform Resource Locator

User based applications: Programs developed for the purpose of providing services to users.

Warning sign: A type of traffic sign that indicates a hazard on the road that may not be readily

apparent to a driver.

Web Server: A computer that delivers content from websites over the Internet.

1.4 References

"Repository." CS410 Green Team. Green Team, 19 Oct. 2010. Web. 1 Feb. 2011.

<cs41x.com/repository>.

Meier, Chris. (2011) Lab 1-SWDS Product Description Norfolk, VA: Author.



1.5 Overview

This product specification provides the hardware and software configuration, external

interfaces, capabilities and features of the SWDS. 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; the key features of the prototype; the parameters that will be

used to control, manage, or establish that feature; and the performance characteristics of that

feature in terms of outputs, displays, and user interaction.

2 General Description

SWDS prototype will consist of one ultra sonic sensor connected to an eBox and linked to a

personal computer running various applications, with the sensor being suspended over a small

basin into which various amounts of liquid will be poured. For demonstration purposes the

network of sensors will be simulated as well as the DAH. These constraints are due to time and

cost budgets.



2.1 Prototype Architecture Description

Figure 1. Major Functional Components Diagram

Figure 1 illustrates the major functional components of the SWDS prototype and the flow

of data between them. The following six component are described in the following paragraphs:

Closed System Remote Device (CSRD), Networked System Remote Device (NSRD), Data

Acquisition Host (DAH), Administrative Website Application (AWA), Public Web Server

(PWS), and Onsite Data Acquisition Device (ODAD).

The CSRD is responsible for storing the measurement offset for the sensor. The CRSD

also collects data from the sensor and processes it using a filtering algorithm. If a measurement

data from the sensor is outside the offset being stored the CSRD triggers the onsite warning sign.

Lastly, the CSRD will log all data that is accepted within the tolerance of the filtering algorithm.

This component is a failsafe device in that it remains operational even if the network connection

becomes unavailable.

The ODAD is responsible for storing logged data from the remote device. In addition,

the ODAD supplies an onsite management console which provides for the onsite setting of

measurement offset and the updating of remote device software. The ODAD has capabilities for

use as an onsite troubleshooting and maintenance device. The ODAD maintains operational

standards when the remote device becomes a CSRD.


The NSRD is responsible for storing the measurement offset for the sensor. The NRSD

also collects data from the sensor and processes it using a filtering algorithm. If a measurement

data from the sensor is outside the offset being stored the NSRD triggers the onsite warning sign.

Lastly, the NSRD will log all data that is accepted within the tolerance of the filtering algorithm.

In addition, the NSRD is responsible for installing software updates.

The following three components are all part of the Centralized Control Center which

works in tandem with the remote device, provided it has connectivity. The DAH receives

incoming data and logs it. The AWA maintains the historical data and provides capabilities for

viewing it. Also, the AWA is responsible for the Remote Management Console, that allows for

the setting of the sensors measurement offset and updates to the remote device software. The

PWS generates updated News Feed, Bing Maps, and RSS feeds. These three components work

together with the database.

Feature Real World Implementation Prototype

Sensor One sensor available for closed system; multiple sensors for networked system. Ruggedized housing to protect from the elements.

Will feature one sensor that detects and sends data to the simulation computer in the closed system demonstration.

Microcontroller For closed system, embedded data store and algorithms to throw out erroneous data. For networked solution, programmed to send data to centralized data center.

Will feature one microcontroller that receives data from a single sensor and sends it to the development PC.

Multi-Sensor Network

If client chooses to implement networked solution, this is available for implementation. The number of sensors will be determined by the client based upon several factors.

This will be simulated for the networked demonstration.

Centralized Data Center

Data collection server that stores the info from the microcontroller

Will be simulated.

Report Generator Users can access reports from the product website which will feature an administrative

This is simulated in a GUI on the development computer.


login for clients. The data is pulled from a database on the server.

GoogleMaps™ application

Featured on the product website with real-time water depth measurements in inches.

Will be simulated on the product website via a GUI.

RSS Included on the product website for entities to subscribe.

An icon will be featured on the product website but will not be functional.

Table 1. Prototype vs. Real-World Implementation Comparison

2.2 Prototype Functional Description

In general the SWDS product has two types of functionality. The first is shown in Figure

2 and is referred to as the NSRD (Networked System Remote Device), the second is shown in

Figure 3 and is referred to as the CSRD (Closed System Remote Device). The NSRD

functionality consists of several other components namely: AWA (Administrative Web

Application), PWS (Public Web Server), and DAH (Data Acquisition Host). Each of these

components relies on one another for storing and getting either device configurations or sensor

data from an associated component site. All these components rely on obtaining data either from

one another or the database. The CSRD is slightly less complicated as it consists of only one

other component the ODAD (Onsite Data Acquisition Device). As the CSRD operates as

normal; save network connectivity, the ODAD is able to access and modify stored device

configuration and get sensor data to be temporarily logged.



Figure 2. Networked System Functional Breakdown

Figure 3. Closed System Functional Breakdown



2.3 External Interface

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

2.3.1 Hardware Interface

The prototype will consist of an industrial ultra sonic sensor connected to an eBox

embedded platform device running Windows CE 6.0. This assembly will not be housed and will

be mounted on a simple stand attached to a basin. Also included in the demonstration will be a

personal computer running MySQL database. The sensor will be connected to the eBox using a

USB cable. The eBox will be connected to the PC via standard Ethernet cable and will use

TCP/IP as the communication standard. The purpose of which will be to simulate the centralized

data center and the real time updating of sensor information

2.3.2 Software Interface

The prototype software interfaces consist of MySQL, Windows CE 6.0(eBox OS), and

Internet Services that are required for RSS, Bing Maps, and News Feed. SWDS web pages will

utilize PHP and C#. The AWA, DAH, and PWS will be run off of the MySQL database.

2.3.3 User Interface

The user interfaces, will consist of a keyboard and mouse attached to a personal computer

for command entry and module selection. The sensor and basin will be manually adjusted as

needed physically by hand. To simulate a change in water level a bucket containing water will

be gradually emptied (physically by hand) into the basin that the sensor is monitoring.



2.3.4 Communications Protocols and Interfaces

The prototype will use a Universal Serial Bus (USB) port for communications between the

ultra sonic sensor and the eBox. The prototype will use Transmission Control Protocol/Internet

Protocol (TCP/IP) over an Ethernet cable as the communication standard between the eBox and

the personal computer (PC).

3 Specific Requirements (Total Collaboration)

The following section describes the specific functional, performance, and non-functional

requirements of the SWDS prototype.

3.1 Functional Requirements (Eric Boyd)

The functional requirements describe the capabilities of the SWDS prototype. They

describe what the product must do in order to meet the previously discussed goals and objectives

of the project.

3.1.1 Closed-System Remote Device (CSRD) (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 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

[This space intentionally left blank]


3.1.2 Onsite Data Acquisition Device (ODAD)

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)

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)

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)

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.

3.1.6 Public Web Server (PWS)

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): 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 Mosteller)

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 RequirementsA simulated sensor will not stop functioning during a simulation.

Constraint Bounds the problem of malfunctioning sensors.

A customized web interface will not be used for each user type.

Constraint Bounds the problem of designing multiple web interfaces with different functionalities.

A method will be developed by the customer to transmit data locally from a closed system.

Constraint Bounds the problem of transmitting the data archives and updating the software of the closed system.

The city already has a network set up that we can piggyback.

Constraint Bounds the problem of setting up a network for the city.

Data transmission delay will not be large enough to effect real time results.

Assumption Allows us to assume data is relevant and will be effective in alerting drivers in time.

Data collected is not sensitive in any way.

Assumption Allows for minimal data security.

The microcontroller will not perform any data processing.

Assumption Allows us to only develop high-level algorithms for the centralized data center.

The user will not look up data archives for invalid dates.

Assumption Allows for minimal error checking when processing data archive requests.

Any spike in data will be regarded as an obstruction (such as a vehicle) and will

Assumption Allows us to assume the data-sorting algorithm is correct.


be thrown out.The eBox will be able to support the microcontroller.

Dependency The prototype will rely on the development PC to run the data sorting algorithms.

Condition Type Effects on RequirementsThe physical sensor is available and functioning.

Dependency The prototype will rely exclusively on simulated sensors.

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

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

3.4.2 Maintainability (Cassie Rauthroff)

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



4 Appendix

Figure 4. Technical Overview

Figure 5. Hardware Component Diagram

Figure 6. Hardware Overview


Figure 7. Software Component Diagram

Figure 8. General Public GUI


Figure 9. City User GUI

Figure 10. Insurance Agency GUI

Introduction - Old Dominion University · Web viewThe basic closed-system version of the flood...

Documents

Transcript of Introduction - Old Dominion University · Web viewThe basic closed-system version of the flood...