SOURCES SOUGHT
D -- Proof-of-Concept/Information on Technologies for Field Data Collection, QA/Control & submittal to a Central Data Processing Facility & Corporate Database which is currently Oracle 8i.
- Notice Date
- 7/3/2002
- Notice Type
- Sources Sought
- Contracting Office
- Department of Agriculture, Forest Service, Northeastern Research Station/State and Private Forestry, 11 Campus Blvd., Suite 200, Newtown Square, PA, 19073
- ZIP Code
- 19073
- Solicitation Number
- NEAT-POC-266
- Response Due
- 7/19/2002
- Archive Date
- 8/3/2002
- Point of Contact
- Patricia Pierce, Group Leader, AQM, Phone 610-557-4248, Fax 610-557-4224,
- E-Mail Address
-
ppierce@fs.fed.us
- Description
- INTRODUCTION The Forest Inventory and Analysis program (FIA) of the USDA Forest Service is seeking information on technologies for field data collection, quality assurance/control and submittal to a central data processing facility and the corporate database which is currently Oracle 8i. THIS IS NOT A COMMITMENT FOR SERVICE. After an initial information-gathering period, if FIA then decides to contract vendors who have expertise in this area and an interest in working with us to develop the necessary tools, a separate bid process will be initiated. The system will include support of 450+ data recorders that operate in an occasionally connected environment. The system must support collection of all national core variables, as well as provide easy customization to include regional variables specific to each of its five stations (geographic areas). In some cases, specific variables need to be added by state. National core variables include data on trees, soils, vegetation, ozone content, down woody debris, etc. Regional variables typically expand on these core variables and provide information on items of regional interest, such as regional tree damages (e.g., disease, insects) or tree grading. The data collection process needs to include verification of legal ranges for each value as well as extensive cross-checking between variables within tables and between tables. A Quality Assurance/Quality Control (QA/QC) system must also be incorporated that allows plot data verification to log and compare QA/QC crew values with original field crew values. Final edited data will integrate with the corporate Oracle database at national level. The prospective system must allow the Forest Service full access to any custom code. This will allow modification of the system as needed throughout its life cycle to meet our changing needs. Other requirements, such as geographic information systems and/or GPS integration, are very desirable to be included at some point in the system design, but are not a top priority in the initial implementation. PROOF-OF-CONCEPT (POC) PROCESS Technology is changing at a very rapid pace. There are many system development options available for the mobile computing environment. The Proof-of-Concept process that we are conducting will be to gain knowledge on available solutions and evaluate usability, maintainability, and integration capabilities with our corporate database (currently residing within Oracle 8i). The goal of the POC is to determine the specific ?architecture? that is most appropriate for FIA. The POC results will be reviewed by the entire field data recorder community of the Forest Service, as a part of our internal information sharing. We are inviting you to prepare a POC system to demonstrate to the FIA PDR (Portable Data Recorder) Team. This is in no way intended to be a complete prototype, but rather to provide one or two examples of each requirement listed. Although we would prefer to see a system that is based on the included Oracle export database (FIAField.dmp), we will view systems that have a similar background database structure and can demonstrate the items we have specifically identified under ?Items to Include in Demonstration?. The presentation will include an overview of the proposed system architecture, demonstration of the items requested, and an overview and demonstration (where possible) of the specific concepts found under ?Main Concepts?. A number of handhelds will be provided for testing and interactive demos. You may choose to bring your own handhelds, but we also request that sample software can be installed on two of the handhelds that we provide. Specific handhelds are posted under ?Items Provided?. The meeting will take place the last two weeks in August at the Rocky Mountain Research Station (RMRS) in Ogden, UT. We expect the presentation and interactive demo to be approximately 90 minutes in length with a 30 minute question/answer period to follow. This time may have to be adjusted depending on the number of respondents to this POC. If you would like to participate in this process, please respond by July 19, 2002. Details of the August POC Demo Schedule will be sent after confirmation of vendor interest. A second confirmation will be required on or before August 9, 2002 after being assigned a time slot to verify you will have a system to demonstrate. FIA OBJECTIVES To determine an appropriate architecture for our system and verify the need for pursuing a Request For Proposals to develop our system. Our overall timeframe for this system includes system development winter/spring 2003, extensive field testing throughout the development process beginning summer (field season) 2003, and implementation beginning nationwide for the 2004 field season. Full implementation must be completed by the 2005 field season. MAIN CONCEPTS (Requested Written Responses, Demos if Possible) Please respond to the following concepts in writing, and where possible include in your recommended system architecture design. If not included in your system design, please provide a detailed explanation describing why you are not recommending the use of that particular ?concept?. If included in your system design, please include in your demonstration. 1. What would be the best way to manage a national data collection program that would allow maintenance of national core variables separate from regional variables? This would basically be the equivalent of maintaining five individual systems that share a common national core. In some cases, customization may need to go beyond even this to the state level. 2. We are interested in the concept of an ?application generator?. This program would recreate applications for data recorders based on the database fields specified (e.g., National core variables plus North Central variables) and the data recorder specified. Once an application was generated for the specified region, then it could be customized to allow for specific crew preferences (e.g., order of variables, pick lists, ?). Please explain whether this would be a viable option for the FIA system or outline your suggestion for a better approach. Could further customization be made available to the user on the data recorder? Could multiple configurations be saved for easy-to-select settings? 3. Is it possible to maintain one program, possibly using an application or forms generator, for use on multiple data recorders with different screen orientations and sizes? How difficult and/or easy would this be and what would be the related opportunity cost on maintenance of each different screen size and orientation? 4. The feasibility of using a development environment that would ?generate? a program that would run on multiple platforms (Windows, Linux, Palm) and its subsequent effect on performance and field usability. If this is not feasible for your system, please explain. 5. The feasibility of using a database as a source for data validation criteria. The database would be used for organizing and maintaining these validation rules, and would be fully searchable and updateable. It would include range checks, cross checks between fields within a table and cross checks between fields in different tables. It could contain specific SQL or PL/SQL code that would define the edits and be referenced by the data recorder and desktop edit programs to perform data validation. (Please see ValidationExamples.zip, especially the Example_SQL_edit_database.doc within.) 6. The feasibility of utilizing a mobile GIS solution to access coverages and landscape information on the handheld computer to help navigate to a plot. Once on the plot, the feasibility of collecting our data spatially with our comprehensive validation checks. Would performance delays slow our crews down working with spatial information and coverages? How would we manage providing coverages for each plot? This will include GPS units and may also include technology such as the laser rangefinder for gathering spatial information (heights, distances) on individual trees. How would your system implement this initially or plan for future integration with these technologies? 7. The feasibility of having multiple data collection devices on a single plot networked using a wireless technology such as Bluetooth to keep the data sync-ed between the multiple devices. In addition to networking multiple devices running the data collection forms/software, what are the possibilities for utilizing wireless connections between peripheral devices such as GPS units (just starting to be released with Bluetooth), laser range finders, digital cameras, etc. 8. After seeing the scope of the project, please provide ballpark cost and time estimates for project completion. This is not expected to be ?the estimate? for the project, but will allow us to plan for our budget needs and approval for this project. ITEMS TO INCLUDE IN DEMONSTRATION To provide comparable testing for vendors who will not use our database: Minimum 12 tables with total of 160 fields. Please document and provide an overview of the proposed system during the presentation. State your demo system specifications (Laptop and handheld: speed, memory, processor, ?) and any system development software (e.g., Visual Studio) and database software (e.g., Oracle Standard Edition 9i on laptop, SQL Server CE on the handheld) and include in written overview. Plan to demonstrate your handheld software on a minimum of two of the machines listed under ?Items Provided?. System development and maintenance: 1. Drop a variable and corresponding edits from the national core. 2. Add a tree variable that only appears when the tree status is recorded as ?1? or ?live?. Include the corresponding edits to the NC regional variable list. 3. Change the order of the variables on the handheld form 4. Change the datatype of a field. 5. Add a range/value edit showing each step. Also demonstrate validating from a list of values instead of a range. 6. Add a cross-field validation rule showing each step. 7. Add a cross-table validation rule showing each step. 8. Replication system: demonstrate available settings. 9. Initiate/setup auto-handheld software update and demonstrate. 10. Print files directly from recorder, from laptop. 11. Demonstrate the ease of producing the data recorder forms or applications for two different screen orientations: portrait and landscape ? VGA screens. Also demonstrate for a larger traditional handheld ? VGA screen. 12. If your system supports, demonstrate the ease of generating data recorder forms or applications for multiple data recorder platforms (e.g., Windows CE, Palm, Linux devices). Also, discuss and demonstrate the performance on multiple platforms. Handheld forms/software use: 13. Transfer plot history data from Oracle Standard Edition database (Husky tables) to the handheld. 14. Give overview of navigation on the handheld software/forms. Demonstrate how to move between plot data, tree data, site tree data, etc. a. "folder-like" tabs b. command buttons c. pull-down menus d. scroll bars, horizontal and vertical e. auto-movement by tabbing or with data input 15. Demonstrate three different device input methods such as keyboard input, on-screen keyboard/number pad, and handwriting recognition on the handheld. 16. If possible, offer toggle between grid (spreadsheet where multiple subplots could be seen and/or edited at once) data input, and columnar entry (where an entire subplot set of variables would be on one screen) 17. Show the ease with which a note or memo could be added. 18. Prepare to demonstrate two instances of the following GUI data inputs: a. Option buttons b. Check box c. List box d. Combo box (drop-down list) e. Label box 19. Demonstrate a successful range validation of field values. 20. Demonstrate a successful list validation of field values. 21. Perform cross-data validation between fields within a table. 22. Perform cross-data validation between fields in two different tables. 23. Demonstrate conditional variables. Disable/Gray-Out certain fields based on input in other fields. 24. Customize a pick list on the handheld. 25. If possible, move a variable on the handheld form/software as handheld user. ITEMS PROVIDED Facilities in Ogden, UT - Rocky Mountain Research Station. Conference room will have a projector to connect your laptop to for "live" demonstrations of the desired features. Handhelds Provided. Although you may provide your own handhelds, we still ask that you attempt to load your software on two of these machines (one portrait and one landscape if you deem it feasible). Also, if you are supporting the concept of a software program that will run on multiple handheld platforms, be sure to demonstrate your handheld software on a Windows CE, a Linux and a Palm device. An updated list of handhelds will be sent with the details of the meeting. Windows CE machines - Landscape screens: Juniper Systems Allegro Field PC Juniper Systems Allegro CE DAP Technologies CE5320 DAP Technologies CE8640 TDS Ranger 200C Symbol PDT7500 Windows CE/Pocket PC handhelds - Portrait screens: Compaq iPaq 3635 HP Jornada 768 @migo PD-600C Panasonic Toughbook 01 Other Operating Systems: Sharp Zaurus PDA running Linux OS Palm OS machines (Handspring Visor and newer unit TBA) ATTACHMENTS FIA_POC_Introduction.doc This document in Word format. FIA_System_Requirements_7_2_02.doc This document contains software requirements that FIA is planning to incorporate into the final system design. (Hardware requirements are not included in this POC. At this point, FIA is planning on making hardware selections on a station by station basis once a system is developed. NCCoreManual_ver1_6.pdf The North Central Research Station (NCRS) Field Manual v1.6. This will match a good portion of the data in the Oracle export file. Please Note: Phase 2 (P2) Inventory variables are defined in Sections 1-8. They typically consist of ?tree data? that are collected on all forested plots. Phase 3 (P3) Inventory variables are described in Sections 9-14 and are only collected on a subset of the forested plots. The sample database FIAField only includes the P3 variables that make up additional tree data (Section 12). The new national system will include all of the variables found in Sections 9-14; but they are not intended to be included in the POC other than to plan for P3 modules. FIAField_Oracle_dmp.zip - Sample FIA Field Database (FIAField.dmp). This is a portion of a field database being used by the North Central Research Station provided in Oracle export format. It includes North Central regional variables in addition to the national core variables for all P2 data and P3 tree data only. Regional variable names are preceded with an "NC" in the column names. - Import Instructions for FIAField.dmp (FIAField_Import_Instructions.doc). These instructions must be followed carefully to install to your trial copy of Oracle Standard Edition and import the FIAField schema. - Crosswalk between columns of the sample database and the NCRS Field Manual v1.6 (FIAField_Columns_to_Manual_v1_6.xls). This will provide a detailed crosswalk between the FIAField sample database columns and the NCRS Field Manual. The second worksheet also lists the state-cycle-subcycle combinations that are manual v1.6 compliant. Set of regional variables from the Southern Research Station (SRS_Regional_Variables.doc). This word document outlines the variable names and types from the Southern as an additional example to NCRS?s to maintain one national and 5 station-level modules of within the system. It is intended that the vendor demonstrate a few variables from each of these stations to adequately describe the suggested ?maintenance? of these multiple modules. ValidationExamples.zip Here are examples of systems used in FIA to track validation checks. The validations need to be automated as much as possible to avoid maintenance in multiple locations. There is a strong possibility of using a database to maintain these edits and their SQL code in a single location that will automatically update both handheld editing software and laptop/desktop editing software. We are very interested in new ideas and suggestions. - National Programming Requirements for National Manual v1.6 (P2-3_programming_requirements_v1.6.doc). This document lists programming requirements for variables from manual version 1.6 including name, phase, width, business rules, range and list checks, ... - National Logic Checks for National Manual v1.6 (P2-3_logic_checks_v1.6_highlighted.rtf). This file provides examples of the extensive checking that occurs between data fields and tables. A few examples have been highlighted to focus on, possibly for inclusion in POC system or something similar. - Example of an edits database (Example_SQL_edit_database.doc) currently used for cross-field validation checks of P3 data from the national P3 database. This is not necessarily the design we are interested, but may provide an idea for an "Edits Database". 60-day Trial Version of Oracle Standard Edition. To receive a 60-day trial copy of Oracle Standard Edition (delivered within ~1 week), please contact: Patrick Gallagher OR Erin Lynch patrick.gallagher@oracle.com erin.lynch@oracle.com 703-364-5742 703-364-2051 Please utilize this trial version of Oracle Standard Edition to demonstrate your Oracle connection on your laptop during your demonstration in Ogden, UT. CONTACT INFORMATION If you are interested in being a part of the FIA Proof-of-Concept process, please contact: Patty Pierce ppierce@fs.fed.us 610-557-4248 on or before July 19, 2002.
- Record
- SN00110534-W 20020705/020704052117 (fbodaily.com)
- Source
-
FedBizOpps.gov Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |