Running head: LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT... 1 Lab 2 – Surface Water Detection System Product Specification
Running head: LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
Lab 2 – Surface Water Detection System Product Specification
Version 1
Katherine Kenyon
CS 411 Workforce Development II
Old Dominion University
Professor Gene Price
March 21, 2011
1
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 2
Table of Contents
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
List of Figures
3
List of Tables
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 4
1 Introduction
Within the last decade, a vast level of improvement of roadway systems through the use of sensors, cameras, and computerized signs has been achieved. The results of infusing technology into the streets have been subtle, yet life changing for commuters; one such example is the improvement of traffic light coordination based on traffic flow. Recently, new waves of innovative technology solutions have been implemented; cameras that record traffic light violations, warning signs that can detect a violation of the speeding limit, signs that detect a freezing bridge, and webcams that allow remote monitoring of traffic buildup on major highways. These new innovations are very useful to law enforcement and technologically savvy drivers.
When it comes to alerting a driver about adverse roadway conditions, the use of technology is especially crucial. Notifying a driver of a dangerous roadway condition before it’s too late can potentially reduce the number of related accidents. Car accidents are the leading cause of death for Americans under thirty-five years of age (Online Lawyer Source, 2011). It is common knowledge that car accidents are more likely to occur when the roads are flooded, but sometimes driving through adverse weather conditions cannot be avoided.
1.1
Purpose
Luckily, there is a simple solution to this problem – the Surface Water Detection System.
The Surface Water Detection System employs a network of ultrasonic sensors to detect dangerous levels of flooding on highways and roads – with this information, drivers can be alerted through various channels to avoid taking a route that has dangerous water conditions.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
The primary benefactors of the Surface Water Detection System are automobile drivers.
5
Access to the end-user services will be provided to individuals free of charge. The Surface
Water Detection System’s main customer will be local and state governments interested in implementing it as a public safety service. Other potential customers include insurance companies, agencies interested in buying statistical data, and companies interested in utilizing services provided by the Surface Water Detection System within commercial applications.
The Surface Water Detection System will alert drivers of adverse flooding on the roadways, it will not tell drivers which route to take nor will it be able to directly control the actions of the driver or the vehicle. The Surface Water Detection System will record historical data about water levels in a certain area over time, this information will be provided as-is with no guarantees about accuracy or data permanency.
1.2
Scope
When a road flood is detected; strategically placed technologically-enhanced road signs will alert drivers that there are dangerous flood levels ahead. Upon noting the flood sign, a driver will decide whether or not to make a detour to a non-flooded route. In addition to becoming the first flood monitoring system put to use in the Hampton Roads Area of Virginia, the Surface Water Detection System offers a more comprehensive set of features than any of its competitors - including innovative mobile device alerts. By providing multiple channels with which to receive timely updates about flood conditions, drivers are able to reap the full benefits of the Surface Water Detection System. Road signs immediately alert a driver of a flood.
Advanced route planning can be accomplished through the use of interactive internet maps.
Mobile device support will provide cell phone subscribers with SMS updates about flooding
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 6 within areas of specified interest. By knowing adverse road conditions well in advance, a driver will be better able to make decisions resulting in a safer roadway experience.
Sensor
RSS
Feature
Microcontroller
Multi-Sensor Network
Centralized Data Center
Report Generator
GoogleMaps™ application
Real World Implementation
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.
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 real-time water depth measurements in inches.
Included on the product website for entities to subscribe.
Prototype
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.
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
The prototype will demonstrate the general concept behind the Surface Water Detection
System. A sensor unit is used to detect water levels and computer software records historical sensor data, as well as alert coordination and publishing of flood conditions to various web services such as RSS. The prototype may or may not include integration between sensor readings and data collection software. When actual readings and software can’t be functionally
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION integrated due to difficulties with the sensor or lack of sensors, simulated data will be created
7 to demonstrate software functionality. The prototype will include a demonstration of integration with Bing Maps and mobile updates.
The first functional objective of the prototype is to demonstrate the mechanism of water detection using an ultrasonic sensor. The purpose of this objective is to demonstrate that an ultrasonic sensor is proficient at water level detection. The second functional objective of the prototype is to demonstrate how data collected through the ultrasonic sensor can be interpreted into meaningful results. The data will be accessible through the World Wide Web in order to demonstrate ease of use.
An ultrasonic sensor will be directed at a container with varying water levels adjusted through the manual addition of water through the top or drainage of water through a release hatch. The information collected by the sensor will be collected and sent to a computer attached to the sensor through a USB port. The computer will be running software that is able to interpret the sensor data into meaningful results. These results will be stored into a MySQL database on an external webserver. Table 1 illustrates key differences between the real-world product and the prototype, the table explains how the functionality of the prototype will be reduced from the real world product.
1.3
Definitions, Acronyms, and Abbreviations
Administrative Web Application (AWA): Multipurpose portal containing management tools for administering remote devices.
Algorithm: A precise rule or set of rules specifying how to solve a problem.
Annual software license: A legal contract governing the usage of software that is updated once
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION a year.
8
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.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 9
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.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
Ruggedized housing: An enclosure designed to protect an electronic device such as a field
10 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
CS Green Team. (2011). Surface Water Detection System. Retrieved February 9, 2011, from
CS410 Green Team: http://cs.odu.edu/~411green/
Kenyon, K. (2011). Lab 1 – Surface Water Detection System Product Description
Online Lawyer Source. (2011). Car Accident Statistics. Retrieved February 8, 2011, from Online
Lawyer Source: http://www.onlinelawyersource.com/personal_injury/car/statistics.html
1.5
Overview
This specification provides a detailed explanation of the logical components of the Surface
Water Detection System Prototype. Explanations will be broken down into description of each functional component. Next, the two major functional modes will be described. Finally, hardware, software, and user interfaces will be defined. Following the general description are
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION specific functional, performance, and non-functional requirements. These requirements will
11 further clarify the needs of the prototype which must be met to demonstrate the product concept to a level which is acceptable.
2 General Description
The prototype for the Surface Water Detection System will consist of two separate parts that illustrate the closed system aspect of the system and some of the essential data services.
The first part of the prototype will consist of a demonstration of how the ultrasonic sensor detects water levels. This will be achieved through the use of an ultrasonic sensor and a container of water. The second part of the prototype involves demonstrating how collected sensor data will be made of use. Historical sensor information deals with sensor readings over time. This information is stored within a database and accessed through a web-interface. The city user view will illustrates the water depth measurements of various sensors with colors indicating which sensors are reading a severe level of flooding.
2.1
Prototype Architecture Description
Figure 1. Prototype Major Functional Component Diagram (MFCD)
Figure 1 illustrates the major functional components of the Surface Water Detection
System and the flow of data between them. The Surface Water Detection System Prototype
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION will consist of six functional components. The functional components are the Closed System
12
Remote Device (CSRD), the Networked System Remote Device (NSRD), the Data Acquisition
Host (DAH), Administrative Website (AWA), Public Web Server (PWS), and the Onsite Data
Acquisition Device (ODAD). In this section each functional component will be explained.
The CSRD is responsible for storing calibration information for the water sensor, obtaining data from the sensor, and processing that data. Data is processed through a filtering algorithm that is designed to screen out invalid data readings. The CSRD is also responsible for triggering the onsite sign and plays a role in buffering log data.
The NSRD is responsible for taking the data from the CSRD and packing it for network transmission. Data packets processed by the NSRD are sent to the DAH which receives the data and records it into a database. Information in the database is accessed by two clients: the AWA and the PWS. The AWA and PWS serve as human-computer interfaces to the logged data collection by the Surface Water Detection System. The AWA will be reserved for use by administrators and the PWS will be made accessible for use by the general public users.
In the AWA users will be able to view historical data and access the Remote
Management Console. The Remote Management Console is a web application where administrators will be able to set calibration information for each sensor and update remote device firmware. The PWS will be comprised of a news feed, connection with Bing Maps, and
RSS.
Finally, there is the ODAD. The ODAD is connected to the CSRD, it is responsible for storing some data and it also serves as an onsite-management console. The ODAD provides the prototype with closed system capability. This capability enables the most vital functions of the
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION system to operate when the network fails. The ODAD will allow for sensor calibration and
13 firmware updates.
2.2
Prototype Functional Description
The Surface Water Detection System is broken down into two major functional areas: the closed system and the networked system. These systems are shown in Figure 2 and Figure 3.
The closed system will provide the functional warning sign which alerts the driver to dangerous oncoming road conditions due to flooding. The networked system enables historical data collection, website access, and remote alerts via RSS and Bing Maps. The networked system is more complex than the closed system.
Figure 2. Networked System Functional Breakdown
Figure 2 shows a graphical breakdown of the networked system. The networked system deals with the following functional components; AWA, DAH, PWS, and the NSRD. At the center of the networked system is the database. The database component in Figure 2 is conceptual; the actual data is stored in the DAH. The following paragraph contains a verbal run-down of the networked system.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
The AWA gets sensor data information out of the database, and sends information
14 about the device configuration to the NSRD – this could be due to an administrative change made through the AWA’s Remote Management Console. The DAH receives sensor data from the NSRD and stores it into the database. The NSRD receives administrative information from the database. Finally, the PWS retrieves sensor data from the database. All of these processes can occur simultaneously. This functional diagram does not make any distinctions between raw sensor data and processed sensor data.
Figure 3. Closed System Functional Breakdown
The closed system deals with two functional components: the CSRD and the ODAD.
These two functional components are consequently the most vital of the entire system. As long as they remain functional the Surface Water Detection System will be able to provide core functionality without networking capability. In the closed system device configuration and administration as well as data logging is provided through the ODAD. The CSRD provides all other essential functions.
2.3
External Interfaces
This section identifies the physical and logical interfaces used within and by the prototype.
The interfaces will be categorized into one of three types; hardware, software, or user. In this section the actual prototype components will be described along with how they correspond with the prototype architecture and functions.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
2.3.1
Hardware Interfaces
15
The hardware interfaces used by the prototype include an eBox, tub of water, sensor, personal computer, USB cable, and an Ethernet cable. The eBox will encapsulate all of the logical functionality of the CSRD. The personal computer will store and provide access to the
MySQL database, user interface websites, access to internet services, and display terminal for closed system warning sign demonstration. The sensor will be connected to the eBox via a USB cable, and the eBox will be connected to the personal computer via an Ethernet cable. The tub of water will not be connected to any of the components; it will be used in testing the functionality of the sensor.
2.3.2
Software Interfaces
Software interfaces used by the prototypes will include a MySQL database, ebox software, and internet services. The MySQL database will be accessible by the personal computer mentioned in the hardware interface section. The eBox software refers to the software that contains the filtering logic and other code required to process data from the sensor and send it to the database. Internet services refer to data connectivity services associated with Bing Maps, RSS feeds, and online information access.
2.3.3
User Interfaces
User interfaces include the public website, the administrative website, the remote management console, and the onsite management console. The public website corresponds to the PWS. The administrative website and the remote management console correspond to the
AWA. The onsite management console corresponds to the ODAD, a user interface for the
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 16 closed system mode. See Figure 4, 5, and 6, in the appendix for user interface rapid prototypes.
Figure 4 illustrates a sample screen for the public website. Figure 5 and 6 show two sample screens for the administrative website.
2.3.4
Communications Protocols and Interfaces
Transmission Control Protocol/Internet Protocol (TCP/IP) over a standard Ethernet connection will be the only communications protocol that is used.
3 Specific Requirements
The following section describes the specific functional, performance, and non-functional requirements of the Surface Water Detection System prototype.
3.1
Functional Requirements (Eric Boyd)
The functional requirements describe the capabilities of the Surface Water Detection
System 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 D evice (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.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
2) The CSRD will be preprogrammed with filtering logic capable of discarding erroneous
17 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
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
3.1.2
Onsite Data Acquisition Device (ODAD)
18
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.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 19
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
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 20 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 realtime 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)
The following performance requirements describe how well the functions of the Surface
Water Detection System prototype shall be performed in quantifiable and measurable terms.
These requirements each correspond directly to one or more related functional requirements, and they provide quantifiable and measurable goals. Test cases will be used to verify the attainment of these goals.
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
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 21
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 Mostoller)
There are various assumptions, constraints and dependencies in place for the prototype development. Table 2 contains a list of each assumption, dependency and constraint. The table also lists a brief description of the effects on the prototype requirements.
Condition
A simulated sensor will not stop functioning during a simulation.
A customized web interface will not be used for each user type.
A method will be developed 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.
Data collected is not sensitive in any way.
Type
Constraint
Constraint
Constraint
Constraint
Assumption
Assumption
Effect on Requirements
Bounds the problem of malfunctioning sensors.
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.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
The microcontroller will not perform any data processing.
The user will not look up data archives for invalid dates.
Assumption
Assumption
Allows us to only develop high-level algorithms for the centralized data center.
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 be thrown out.
The eBox will be able to support the microcontroller.
Assumption
Dependency
Allows us to assume the data-sorting algorithm is correct.
The prototype will rely on the development PC to run the data sorting algorithms.
The 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
22
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
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION assumption is that the data transmission delay from the sensor to the centralized data center
23 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
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 24 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
The following section describes the non-functional requirements that characterize the performance of the product.
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
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION views to each type of user. The data does not need to be encrypted on the server because
25 hacking attempts are unlikely and even if they do occur the stored data is public information.
3.4.2
Maintainability (Cassie Rothrauth)
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 (Christopher 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
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION 26 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.
LAB 2 – SURFACE WATER DETECTION SYSTEM PRODUCT SPECIFICATION
4 Appendix
The appendix contains additional documentation for the Surface Water Detection System prototype.
27
Figure 4. General Public GUI
Figure 5. City User GUI
Figure 6. Insurance Agency GUI
