CCRTS June 2005

Flexible Data Entryfor

Information Warning and Response Systems

Alice M. Mulvehill (BBN Technologies)James Reilly (Air Force Research Lab)

Brian Krisler (BBN Technologies)

Report Documentation Page Form ApprovedOMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.

1. REPORT DATE JUN 2005 2. REPORT TYPE

3. DATES COVERED 00-00-2005 to 00-00-2005

4. TITLE AND SUBTITLE Flexible Data Entry for Information Warning and Response Systems

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) BBN Technologies,10 Moulton Street,Cambridge,MA,02138

8. PERFORMING ORGANIZATIONREPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited

13. SUPPLEMENTARY NOTES The original document contains color images.

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT

18. NUMBEROF PAGES

20

19a. NAME OFRESPONSIBLE PERSON

a. REPORT unclassified

b. ABSTRACT unclassified

c. THIS PAGE unclassified

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

CCRTS June 2005

The Problem: Incidence Response

• The need to collect data that can provide warnings to avert crisis situations is paramount to many modern military and civil response systems.

• Flexibility in the collection and description of new or ongoing incidents is critical for accurate and timely analysis and response.

CCRTS June 2005

Integrated Information Management System - IIMS

• A Suite of Information Technologies:– Support the Command and Control (C2) required to detect, track, collect, and

analyze a variety of incidents.– Provide the means for fusing information from a variety of data sources that are

associated with the detection and tracking of chemical and biological attacks, both overt and covert.

• Detailed Capabilities:– Effective Nuclear-Biological-Chemical modeling.– Display and update of situation awareness.– Information fusion and analysis.– Incident detection and tracking.

CCRTS June 2005

IMMS System Components

• Digital Dashboard Command Post Software– A data fusion system providing a suite of applications designed to consolidate,

display, and manage both day-to-day and Chemical-Biological contingencies and hazard data from sensors, reconnaissance reports, and hazard modeling.

• Detection Network– Is established by using electronic, signal-control devices that provide a

communication link and a computer interface to integrate dissimilar, remotely located devices (e.g., detectors, sirens, warning lights, GPS receivers, and meteorological sensors) into a common network.

• Warning Devices– Consisting of both audio systems and light systems that disseminate alarms and

critical condition information.

Digital Dashboard

CCRTS June 2005

IMMS Digital Dashboard

• The dashboard can be configured to suit the needs of a particular operator or for a particular situation.

• Incidents (along with associated analysis data) can be displayed and tracked through the dashboard.

CCRTS June 2005

Incident Collection

• IMMS supports the collection of a variety of incidents through a tool called the Electronic Activity Report (EAR) Manager.

– The EAR tool is available through the IIMS Digital Dashboard.

– The EAR tool supports both standalone incident collection and collaborative collection and analysis.

CCRTS June 2005

Incident Collection and Analysis

incident

incident

incident

FUSIONVia

IIMSDatabase

Closed

Open

Update

Update

Update

EAR Header

Event Unique Information

EARFooter

EAR Header

Event Unique Information

EARFooter

EAR Header

Event Unique Information

EARFooter

Monitor

Monitor

Monitor

CCRTS June 2005

Electronic Activity Report (EAR)

EAR Header

Event Unique Information

EAR Footer

CCRTS June 2005

Electronic Activity Report Categories

• There are over 33 EAR categories currently defined and used in IIMS:

– Some of these have detailed fixed data entry elements.

– Some have only headers and footers for comment fields.

– Any undefined data type must be described as text in the comment fields

CCRTS June 2005

Experiment Objectives

• Situation: Since all of the data description elements in the EAR forms cannot be realized in the design process, it would be useful to provide forms that can adapt to the data being collected.

• Objectives:– Allow the user to capture data about events that were not anticipated

and therefore not defined in the existing data entry forms or database schema.

• Allow EAR data fields to be extended by those users who are actually conducting the monitoring and collection.

• Allow users to specify new data fields in a structured format instead of as a textual comment.

– Convert EAR data element representation to XML.

CCRTS June 2005

Expected Benefits

• Reduced use of incident descriptions as textual remarks– By allowing users to add incident descriptions as XML data

elements more immediate automated data analysis and interchange with other XML based systems would be enabled.

• Facilitate database schema revisions to meet incident reporting requirements

• Enhance ability of IIMS to interchange data with XML-based systems/tools

CCRTS June 2005

Our Approach

• Use a tool called Tracker to support the generation of incident templates.

• Use the Tracker tool to support the extension of the data-entry forms during incident reporting.

• To store Tracker-based incident reports into the IIMS Oracle Database.

CCRTS June 2005

Tracker Overview

• Tracker was developed as part of the DARPA Active Templates program. It was developed to support both the construction and usage of templates at different levels of the C2 structure.

• It supports template authoring with:– A full set of Java/Swing widgets.– Custom widgets, loaded dynamically by a template.– Scriptable values, role-based field-locking, and pictures.

• It supports template usage and extension in both a standalone and in a collaborative mode.

CCRTS June 2005

Tracker User Documentation

• Complete documentation.• On-line Help.

CCRTS June 2005

Tracker Authoring Tools• Text field/area, checkboxes,

radios, menu, list, images, table, grid, slider, date(s), URL, external-app-call (e.g., maps), sub-templates.

• Custom Java widgets (special output reports including: text and PowerPoint).

• Easy linking of pre-defined templates.

• Easy linking of field values with other values with or external to a template.

• Action buttons (script code).• Script-computed value fields

(for supporting computations).

• Attachments.• Database interfaces.

CCRTS June 2005

Tracker Collaboration

“Host”

• A set of related templates can be shared among users.• All edits are dynamically sent to all others who have that template open.

The Update Button changes color to indicate when a change has occurred

CCRTS June 2005

Tracker/IIMS Experiment Tasks

• Run Tracker as a Dashboard Cell and as a standalone application.

• Use Tracker to convert existing EARs into XML-based templates.

• Allow end users to modify an EAR during incident reporting through the use of a Tracker EAR template.

• Store Tracker-based incident reports into the IIMS Oracle Database.

• Provide information about added data elements to IIMS for possible incorporation into the IMMS database.

CCRTS June 2005

Tracker Version of the EAR• We developed Tracker templates to represent

many of the 33 EAR categories.• We enabled data value pulls from IIMS

database.• Tracker templates partition parts of the EAR

structure into separate templates that can be reused across templates as sub-templates.

• New data entry fields can be easily added while templates are being used to collect data.

CCRTS June 2005

Results

• We were not able to implement Tracker as a cell within the IIMS Dashboard.– Future option: if the Tracker authoring widget tools were separated

from Tracker, then the authoring capabilities could be more easily integrated and used by tools like IIMS.

• We were able to demonstrate that by using a standalone Tracker, EAR data fields can be easily extended by those doing the incident monitoring and collection.

• Tracker EARs are already represented as XML.• A database table was developed to provide the IIMS administrator

with information about newly added or modified Tracker-based EAR templates and/or data fields. This table in effect specifies requirements for future EAR (and associated database schema) revisions.

CCRTS June 2005

Conclusion

• Flexibility in the collection of incident data and incident descriptions is critical for accurate and timely analysis and response by military and civil response systems.

• The importance of both the need for data and the need for dynamic flexibility in data collection is magnified when the incident is ongoing.

• Our research indicates that the provision of unstructured, flexible data entry systems like Tracker can offer the end user the ability to modify and update templates that have schema-specific structure.