Levee Health Monitoring and Surveillance (Real-time)
Dipak
Abstract
When Hurricane Katrina struck New Orleans, the levees failed to protect the city. There's now an initiative to improve the monitoring systems for them. A student could create a system that analyzes stored input from sensors that are already in place for anomalies. This system would then alert the proper authorities through a variety of different means. For guidance on how to design such a system, seek out information on best practices for safety monitoring systems.
Additional Information
Mentoring Organisation:
Fibercorps (http://www.fibercorps.com/)
Mentors:
Dr. Raju Gottumukkala and Crawford Comeaux
Latest source code and revisions:
Master source tree readme:
Introduction:
As we know the levees plays a very vital role to protect the city. But if they failed to do so then then a disaster is certainly unavoidable. In order to make sure that the levees will do good one need to concern about it’s health.
Proposed “Levee Health Monitoring and Surveillance (Real-time)” system will help to make sure that the levee’s health is monitored well and alerts will be sent to proper authorities. This should help local authorities and civilian to decide evacuation strategy. This system has following building blocks:
1. Sensor base (Hardware (devices), Software(API) , Simulated (fake one!) )
2. Real-time Data Acquisition Module (An embedded system)
3. Event based Real-time Levee health monitoring and surveillance system
4. Event based rule engine and action cases with knowledge base
5. An emergency alerting systems etc
As we know the levees plays a very vital role to protect the city. But if they failed to do so then then a disaster is certainly unavoidable. In order to make sure that the levees will do good one need to concern about it’s health.
Proposed “Levee Health Monitoring and Surveillance (Real-time)” system will help to make sure that the levee’s health is monitored well and alerts will be sent to proper authorities. This should help local authorities and civilian to decide evacuation strategy. This system has following building blocks:
1. Sensor base (Hardware (devices), Software(API) , Simulated (fake one!) )
2. Real-time Data Acquisition Module (An embedded system)
3. Event based Real-time Levee health monitoring and surveillance system
4. Event based rule engine and action cases with knowledge base
5. An emergency alerting systems etc
Proof Of Concept (POC) system diagram:
A. Real-time Levee Health monitoring and surveillance - Brief class diagram [1]
A. Real-time Levee Health monitoring and surveillance - Brief class diagram [1]
B. Real-time Levee Health monitoring and surveillance - Brief sequence diagram [2]
Description:
Per shown in diagram [1] and [2], Real time data acquisition (D.A) [3] module will be primarily responsible for fetching raw sensor data from various sensors and generate a relevant event out of it. Arduino[4] based board could be the best embedded board to build D.A. module. D.A module will also be responsible for pre-processing raw data fetched from sensors.
Main levee health monitoring system will keep listening for events sent by D.A. module. Upon pre-processing these events it will take a help of an event based rule engine to fork corresponding rule which will eventually performs action associated with it. It will also keep all logs of caught events from DA and action performed per indicated by rule engine. Alerting actions are delivered by deliver module on mobile phones or by other means...
Programming languages and skills needed: Embedded C, firmware, C++, XML (library for XML parser), Bash or Shell scripting, HTML, Ajax (basic), Mysql (library api in C++), php and gnu/linux kernel device drivers (serial over usb).
Description:
Per shown in diagram [1] and [2], Real time data acquisition (D.A) [3] module will be primarily responsible for fetching raw sensor data from various sensors and generate a relevant event out of it. Arduino[4] based board could be the best embedded board to build D.A. module. D.A module will also be responsible for pre-processing raw data fetched from sensors.
Main levee health monitoring system will keep listening for events sent by D.A. module. Upon pre-processing these events it will take a help of an event based rule engine to fork corresponding rule which will eventually performs action associated with it. It will also keep all logs of caught events from DA and action performed per indicated by rule engine. Alerting actions are delivered by deliver module on mobile phones or by other means...
Programming languages and skills needed: Embedded C, firmware, C++, XML (library for XML parser), Bash or Shell scripting, HTML, Ajax (basic), Mysql (library api in C++), php and gnu/linux kernel device drivers (serial over usb).
O.S. Platform: GNU/Linux 2.6.x
Plan Of Execution:
Milestone and deliverable break down:
|
Week [0-15] |
Planned tasks (Completion status marked) |
Notes (Anything) |
| 0 (April-22May) | Milestone: Not applicable Deliverable: To get ready with development environment, code snippets for later use, to get ready with hardware involved in the project 1. Set development environment (firmware) 2. Compose new Wiki, documentations for later use, 3. Get to know community and mentors and keep tweaking proposed system specifications, 4. Make a rigid blue print of proposed system, 5. Get ready with code snippets for later use. 6. Order new required sensors, wires and tool-kits needed for the project if any |
Demonstration of D.A. with hard-coded action - rule: http://www.youtube.com/watch?v=HeaswHKIZKw |
| 1 ( May) | Milestone: Not applicable Deliverable: Firmware code base with hardware sensor demo, D.A. code base for later use 1. To focus on Data Acquisition module for hardware sensor(s). 2. To design base firmware wrapper [Arduino Duemilanove kit] for hardware sensor. 3. Plug the sensors to D.A. module and fetch real-time data. 4. To extend firmware wrapper to pre-process fetched raw data 5. Prepare a getting started guide for DA and sensor kit so that anyone can reproduce the hardware setup 6. Commit code to Fibercorps source-code repository |
Basic D.A. Wrapper source code: https://code.google.com/p/levee-health-monitoring-and-surveillance/source/browse/trunk/levee-data-acquisition-system/hardware-sensors/arduino_hardware_sensors/arduino_hardware_sensors.pde?spec=svn3&r=3 |
| 2 (May-June) | Milestone: Completion of base D.A system Deliverable: Anevent based communication in between core system and D.A., Raw data logger 1. To extend D.A. firmware to send and receive data using real-time events 2. To design new XML based communication protocol for events 3. Compose new server-client serial communication program whose payload should be events 4. To design new raw data logger service to log the readings from different sensors (or at least from sensors used in this project) |
|
| 3 (June) | Milestone: Not applicable Deliverable: Mini server system on alix6f2 board, event parser, simple rule engine. 1. To write a report on how to flash SBC-alix6f2 (single board computer / standard i386 system) using gnu/linux based ubuntu distribution 2. To start working on core expert system for levee health monitoring and surveillance 3. To build simple rule engine with nominal rules 4. To start thinking on parameters needed for knowledge base 5. To parse XML events sent by D.A. module upon desire events |
|
| 4 (June) | Milestone: Not applicable Deliverable: Basic alerting system, Software/internet sensors support 1. To build alerting and other action taking mechanism based on knowledge base 2. To extend an expert based system to support software/Internet sensors (crawled data feeds from weather nationwide weather station/labs e.g. http://www.weather.gov/ currently only USA is considered! ) 3. Extend different alert delivery systems (e.g. speaker beeps, email notification, feeds) |
|
| 5 (June) | Milestone: Completion of core monitoring system Deliverable: background cron/scripts jobs, knowledge base, documentation of core monitoring system along with rule enigne. 1. To work on finalising cron jobs for proposed system 2. To extend rule engine so that rule builder, executor , rules interference and data logger will be in place 3. To extend knowledge base for real-life scenarios 4. To write a report on how to use both service client systems (D.A) and how does event based communication happens |
|
| 6 (June-July) | Milestone: Not applicable Deliverable: Demonstration of proposed system using hardware and software sensors, performance test 1. To complete Internet feeds parser for software sensors 2. To demonstrate how software sensors works in real-time 3. To demonstrate how hardware sensor(s) works in real-time (probably to upload video on wiki) 4. To work on overall system’s performance 5. To start identifying bugs, weakness, improvement in proposed system |
|
| 7 (July) Mid-Term | Milestone: Demonstration of proposed system (with performance stats) Deliverable: Mid term report for project and mentoring organization 1. Buffering week (To finished delayed but planed tasks) 2. To start writing mid-term report, update wiki, to do some more detailed documentation if any 3. To write a mid-term report sent by Google for student side mentoring organization's evaluation |
|
| 8 (July) |
Milestone: Not applicable
Deliverable: Code cleanup 1. To do code cleanup 2. To integrate standalone weather sensors into mini rule in order to test noaa’s feeds renewal mechanism every 20-30 minutes 3. To cross compile rule engine to run on alixboard
|
Short Presentation before mid-term evaluation: https://levee-health-monitoring-and-surveillance.googlecode.com/svn/trunk/documentations-presentation/milestone-1.0-short-presentation.pdf |
| 9 (July) |
Milestone: Not applicable
Deliverable: Noaa’s water level feeds integration 1. To understand Noaa’s water levels | hydrographs feeds. 2. To modify weather software sensors code base to support hydrographs integrations 3. To tune weather stations dump cleanup mechanism. |
|
| 10 (July) |
Milestone: Not applicable.
Deliverable: Integration of water levels feeds and alerting mechanism. 1. To configure final cronjobs to fetchs feeds periodically. 2. To do log rotation of logs generated through software and hardware sensors. 3. Simulation of disaster scenarios. |
|
| 11 (July-August) |
Code cleanup (mini rule engine)
Buffering week to resolve issues listed on https://code.google.com/p/levee-health-monitoring-and-surveillance/issues/list
|
|
| 12 (August) |
Source code cleanup and POC-demo trail.
|
|
| 13 (August) Final-term |
Handled DA hardware actions along with software sensors actions. Tweaked final make files. Updated cronjobs. |
|
| 14 (August) | Published stable release of source code at: | https://code.google.com/p/levee-health-monitoring-and-surveillance/source/browse/trunk#trunk%2Flevee-mini-rule-engine |
