Lab I – Surface Water Detection System Description Running head: Lab I – Surface Water Detection System Description Lab I – Surface Water Detection System Product Description Eric Boyd CS411 Professor G. Price March 21, 2011 1 Lab I – Surface Water Detection System Description 2 TABLE OF CONTENTS 1 INTRODUCTION ...................................................................................................................5 2 SWDS PRODUCT DESCRIPTION ........................................................................................6 3 2.1 Key Product Features and Capabilities .............................................................................6 2.2 Major Components (Hardware/Software) .........................................................................8 2.3 Target Market/Customer Base ..........................................................................................9 SWDS PRODUCT PROTOTYPE DESCRIPTION ..............................................................10 3.1 Prototype Functional Goals and Objectives ....................................................................10 3.2 Prototype Architecture ....................................................................................................14 3.3 Prototype Features and Capabilities ................................................................................18 3.4 Prototype Development Challenges ................................................................................18 GLOSSARY ..................................................................................................................................20 [This space left intentionally blank] Lab I – Surface Water Detection System Description 3 LIST OF FIGURES Figure 1. Technical Overview .........................................................................................................7 Figure 2. Hardware Component Diagram .......................................................................................8 Figure 3. Software Component Diagram.........................................................................................8 Figure 4. City User GUI ................................................................................................................12 Figure 5. Insurance Agency GUI...................................................................................................12 Figure 6. Public User GUI .............................................................................................................13 Figure 7. Major Functional Component Diagram .........................................................................14 [This space left intentionally blank] Lab I – Surface Water Detection System Description 4 LIST OF TABLES Table 1. Competition Matrix..........................................................................................................10 Table 2. Prototype vs. Real-World Implementation Comparison..................................................15 [This space left intentionally blank] Lab I – Surface Water Detection System Description 1 5 INTRODUCTION Metropolitan areas and their inhabitants are in a constant battle against flash-flooding caused by uncontrollable conditions such as heavy rain fall and storm surges combined with regularly occurring tidal forces. Often these conditions come on with little or no warning, and predicting exactly what areas will be affected is extremely difficult. Drivers and their vehicles are often the first to encounter these hazardous conditions. One of the biggest challenges drivers face when these conditions are present, is estimating their vehicle’s ability to pass an inundated stretch of roadway. Often, a driver is navigating through only a couple of inches of water, and then suddenly finds themself in over their head. Whether situations like these are caused by gross negligence, or are truly accidental is hard to determine. In either case, the Surface Water Detection System aims to mitigate the resulting property damages and personal injury. The Surface Water Detection System (SWDS) is a simple warning system that alerts drivers to impassible sections of roadway caused by inundations of water. The warning is produced by a roadway warning sign with flashing lights at the exact location of the inundation. The flashing lights are triggered by a nearby device that measures the depth of the water, and actuates the warning sign based on a configurable threshold depth. In addition to being able to alert drivers with a warning sign at a particular location, the SWDS uses contemporary technologies like high-speed computer networks and the World Wide Web to deliver a host other alert mechanisms for today’s tech savvy drivers such as interactive web maps and customized alerts than can be sent to mobile devices. Lab I – Surface Water Detection System Description 2 2.1 6 SWDS PRODUCT DESCRIPTION Key Product Features and Capabilities The SWDS uses an ultrasonic sensor to measure water depth installed at a location that is prone to flooding caused by heavy rains or tidal forces. Often, city or state jurisdictions opt to place a ruler, sometimes painted on the walls of an underpass, to help drivers gauge and realize the depth of the water at the section of road they are confronted with. These measurement guides are not obvious and do not do enough to warn drivers that there is imminent danger. The ultrasonic sensor of the SWDS triggers a warning sign equipped with bright flashing lights to alert the driver to the danger. The lights are triggered once a configurable threshold depth is met, and remain active until the water level recedes below the threshold. The SWDS was designed to be used in two different configurations. The first configuration, referred to as the “closed-system”, includes the ultrasonic sensor, the warning sign, flashing lights, and necessary hardware and software to control the sensor and lights. The second configuration, referred to as the “networked-system”, allows any number of sensors and related hardware to be networked together, and controlled by a centralized data center. This centralized control allows jurisdiction operators to monitor and remotely configure sensors, and query a centralized database that stores sensor measurement data recorded from the sensors over the network. Figure 1 illustrates this technical overview of the SWDS, and where the distinction between the closed-system and networked-system is drawn. [This space left intentionally blank] Lab I – Surface Water Detection System Description Figure 1. Technical Overview Because sensor measurement data is constantly recorded over the network, and in realtime, the SWDS can deliver public web services including a website that users can access for real-time updates to water depths in the jurisdiction. These updates include, but are not limited to: a “news feed” that provides up to date warnings for hazardous locations in the jurisdiction, interactive maps that use geo-location services that provide the real-time status of sensors in the jurisdiction, and the ability for users to create a customizable alert that includes only those sensors they are concerned with. [This space left intentionally blank] 7 Lab I – Surface Water Detection System Description 2.2 8 Major Components (Hardware/Software) Figure 2. Hardware Component Diagram Remote Device Development PC Data Acquisition Client Data Acquisition Host Control Software Database User Applications Figure 3. Software Component Diagram Figures 2 and 3 illustrate the major functional hardware and software components of the SWDS design. The first major component is the remote device which houses the ultrasonic sensor, embedded microcontroller, and the device’s internal data store. The second major functional component is identical to the remote device in every aspect, except that the device’s network interface is taken into account. The network interface of the remote device enables the device to communicate its sensor measurement data over a network Lab I – Surface Water Detection System Description 9 infrastructure to a centralized data center, and receive communication, such as configuration settings, from the data center. The next component is the centralized data center which acts as a network hub for all of the remote devices on the network. The data center receives sensor measurement data from the remote devices, and redirects that data to a centralized database. In addition, operators at the data center can configure the remote devices by updating a configuration table in the centralized database, and query the centralized database for historical sensor measurement data. Lastly, a public web server is in place that hosts the various end-user applications such as a public website with alerts and interactive maps, and the customizable alert system. 2.3 Target Market/Customer Base The SWDS product is marketed toward municipal jurisdictions such as city or state governments, especially those which include low-lying areas, or areas prone to flash-flooding. It is difficult to estimate the total cost jurisdictions incur over a given timespan handling vehicular damage and personal injuries resulting from vehicles becoming stuck or submerged in inundations of water. These situations may involve law suits, vehicle insurance companies, hospitals and ambulance services, towing companies, and any costs needed to repair private or government property. These jurisdictions, especially those with frequent flooding problems, have an obligation to keep their drivers safe, and to provide adequate warning to dangerously high water levels. The SWDS is designed as a supplementary warning system to a jurisdiction’s existing warning mechanisms. The added benefit to these jurisdictions include, but are not limited to: a higherlevel of highway safety for their drivers, lower costs in recouping property damages and public Lab I – Surface Water Detection System Description 10 services rendered, and the ability to charge fees for historical data provided to insurance companies for third-party law suits. 3 SWDS PRODUCT PROTOTYPE DESCRIPTION The prototype design of the SWDS demonstrates all of the core capabilities and components of the overall commercial SWDS design. The major differences will be covered in the following sections. 3.1 Prototype Functional Goals and Objectives The first functional objective of the prototype is to successfully demonstrate the ability to use an ultrasonic sensor to measure water depth. Existing means of gauging water depth involve underground sensors that measure the pressure of the water above it. These installations are cumbersome and expensive, and the SWDS prototype will demonstrate that an above-ground mounted ultrasonic sensor, allows for a more flexible and easy installation. Table 1 highlights some of the differences between the SWDS design, and some competing technologies. Table 1. Competition Matrix Lab I – Surface Water Detection System Description 11 The second objective is to demonstrate that filtering-logic, embedded on the prototype remote device, can successfully determine what the true depth of a body of water is. Moving traffic, obstructions caused by roadway debris and animals, and any other erroneous readings must be filtered-out if the above-ground ultrasonic sensor design of the SWDS is to be proven effective. The third objective is to demonstrate that multiple remote devices can be networked, and manipulated from a centralized location. This will involve demonstrating remote devices transmitting their sensor measurement data over the network to a centralized database, and the ability to configure remote devices over the network. The fourth objective is to demonstrate a mock-up of the centralized data center, and the user interfaces necessary to monitor and configure remote devices over a network, and to query the centralized database for historical sensor measurement data. [This space left intentionally blank] Lab I – Surface Water Detection System Description Figure 4. City User GUI Figure 5. Insurance Agency GUI 12 Lab I – Surface Water Detection System Description 13 The fifth and final objective will demonstrate a mock-up of the public web server, and the various public services it provides. This will include demonstrating a news feed that is configurable over the network from the centralized data center, an interactive map that displays the real-time status of the remote devices, and the ability to configure and receive customized alters that are configurable by selecting which remote sensors to include in the alert. Figure 6. General Public GUI [This space left intentionally blank] Lab I – Surface Water Detection System Description 3.2 14 Prototype Architecture Roadside Warning Sign Remote Device Ultrasonic Sensor Embedded Microcontroller Internal Data Store Data Center Web Server Figure 7. Major Functional Component Diagram Figure 7 illustrates the major functional components of the SWDS prototype. It provides a higher-level view of the overall SWDS architecture than is depicted in the hardware and software component diagrams (Figures 2 and 3 in Section 2.2). Table 1 highlights the differences between the prototype and real-world implementations. [This space left intentionally blank] Lab I – Surface Water Detection System Description Feature Real World Implementation Sensor Microcontroller 15 Prototype One sensor available for closed system; Will feature one sensor that multiple sensors for networked system. detects and sends data to the Ruggedized housing to protect from the simulation computer in the elements. closed system demonstration. For closed system, embedded data store and Will feature one algorithms to throw out erroneous data. For microcontroller that receives networked solution, programmed to send data from a single sensor and data to centralized data center. sends it to the development PC. Multi-Sensor If client chooses to implement networked This will be simulated for the Network solution, this is available for networked demonstration. implementation. The number of sensors will be determined by the client based upon several factors. Centralized Data Data collection server that stores the info Will be simulated. Center from the microcontroller Report Generator Users can access reports from the product This is simulated in a GUI on website which will feature an administrative the development computer. login for clients. The data is pulled from a database on the server. GoogleMaps™ Featured on the product website with real- Will be simulated on the application time water depth measurements in inches. product website via a GUI. RSS Included on the product website for entities An icon will be featured on to subscribe. the product website but will not be functional. Table 2. Prototype vs. Real-World Implementation Comparison Lab I – Surface Water Detection System Description 16 The biggest differences between the prototype and real-world implementations involve simulating much of the hardware needed to create a true, large-scale network infrastructure. Much of the software remains identical in both implementations. Multiple remote devices on a network will have to be simulated due to the cost-prohibitive constraint of purchasing multiple sensors and embedded device platforms. A program written in C# and running on the Microsoft .Net Compact Framework will reside on the remote device. This program will be responsible for listening to the measurements coming from the ultrasonic sensor, and filtering-out erroneous measurements. A separate program written in C# and running on the Microsoft .Net Compact Framework will reside on the remote device that allows a technician to configure the remote device. The technician will connect to the remote device via Ethernet cable, and access the remote device’s configuration program using a protocol such as Telnet or HTTP. In addition to the programs that are used in the closed-system implementation, the remote device will be programmed to act as a networked-sensor if network connectivity is established. If an IP address is specified in the remote device’s configuration file, the remote device will attempt to connect to the IP address on a regular time interval. If the remote device successfully connects to the IP address (this simulates the connection between the centralized data center and a networked-remote device), the remote sensor will routinely request an update to its configuration file, and transmit its sensor measurement data over the network to be recorded in the centralized database. The second-half of the prototype involves building the software that controls the centralized data center, and the public web server. The centralized data center and public web server will be implemented as web applications writer in C# using the ASP.NET web platform. Lab I – Surface Water Detection System Description 17 A centralized database will also be created using Microsoft SQL Server 2008. The centralized database will be accessed by the data center and the public web server to demonstrate the remaining capabilities of the SWDS prototype. The centralized data center is essentially a website that accesses the database for various things. Incoming sensor measurement data over the network is packaged and stored in the centralized database. This data is then used to display the current status of the remote devices on the network (both the physical prototype and the simulated devices). This data can be queried, using LINQ (Language Integrated Query), for historical purposes. The data in the database, once queried, is displayed to the webpage and possibly can be used to generate various other report formats (Excel, CSV, etc.). The centralized database will also use LINQ to manipulate a sensor configuration table in the database. On regular intervals, the remote device will request an update to its configuration. If a change in the configuration table is found, the data center will package the configuration data, and send it over the network to the remote sensor. The public web server is a web site that accesses the centralized database for sensor measurement data. This website will create automated alerts on the homepage, updated regularly, when sensor measurement readings are hazardous, or quickly becoming hazardous. In addition, the website will provide an interactive map using the Google Maps API. This interactive map displays all of the sensors in the jurisdiction, their current measurement reading, and their address by using a combination of JavaScript and C#. Lastly, the website allows users to create a customizable alert that. This alert is created by users selecting which sensors they are concerned with (typically those sensors along their daily route). When any of those sensors have reached a hazardous level, the website is responsible for automatically alerting the user. Lab I – Surface Water Detection System Description 3.3 18 Prototype Features and Capabilities Ultimately, the SWDS prototype demonstrates flood-detection using an above-ground sensor, and contemporary technology such as the World Wide Web offers significant benefits over existing technologies with similar objectives. The SWDS prototype demonstrates that utilizing more powerful computer technology versus mechanical-only solutions is not only costeffective, but offers greater flexibility and capability. Because internet technology is so easily incorporated into the SWDS design, its demonstration will mitigate any advantages touted by competing technologies that do not offer as flexible or capable solution. 3.4 Prototype Development Challenges There are a few areas of the SWDS prototype design that will present real challenges to its developers. The first challenge will be in correctly identifying the necessary filteringalgorithms to discard erroneous measurements. The main advantage in-ground, pressure sensitive solutions offer, is that water pressure is easy to gauge, and cannot be confused with other debris, or vehicles that may cause erroneous measurements. There are many variables to consider in the filtering-logic, and they must be as accurate and effective as possible to demonstrate that the above-ground, ultrasonic sensor solution is a viable and effective one. The second challenge will be in identifying the proper risk management strategies that will offer solutions to any technical problems on the network. Identifying what the proper course of action is in case of network-outages will be crucial in demonstrating that a safety device that is so closely tied to a large-scale network is cost-effective and a viable solution to alerting the public to hazardous road conditions. Lab I – Surface Water Detection System Description 19 The last challenge will be the time constraint of implementing the prototype. The overall architecture of the software will have to be established early, and good software engineering practices will have to be used to ensure the product is delivered on-time and in a reasonably operating condition. Likely, the most pertinent features to demonstrate will need to be identified, and those areas of the software development will take precedence over any lesser deemed features. Other aspects of software engineering, such as Software Configuration Management (SCM), will need to be evaluated in terms of the learning-curve for some members of the group, and their overall added value to the project. Test-driven development will also fall into this category. Likely, group members will need to be evaluated on their particular software development experience, and will take on roles according to their level of competency. [This space left intentionally blank] Lab I – Surface Water Detection System Description 20 GLOSSARY 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. 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. 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. Google Maps API: A technology created by Google that utilizes maps to support a variety of Lab I – Surface Water Detection System Description 21 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. Prototype: Logical step in the development process demonstrating the real world potential of a concept. Real time data: Information that is collected in the actual time the process is occurring. Really Simple Syndication (RSS): Formatted XML used to provide subscribers with information updated on a regular basis. Risk analysis: Identifying and assessing factors that may compromise the success of a project. Ruggedized housing: An enclosure designed to protect an electronic device such as a field sensor from the elements. Server: A computer used to accept incoming requests and information over a network, and inturn, generates and transmits data back to another user or computer (client). Ultrasonic sensor: A sensor that calculates changes in depth using high frequency sound waves. User base 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. Lab I – Surface Water Detection System Description Web Server: A computer that delivers content from websites over the internet. 22