SUO Communicator Agent-based Support for Small Unit Operations - - PowerPoint PPT Presentation

SLIDE 1

KIMAS 2003

Object Services and Consulting, Inc.

SUO Communicator

Barbara Brown – ScenPro, Inc. Paul Morris – ScenPro, Inc. Craig Thompson – OBJS October 1, 2003

Agent-based Support for Small Unit Operations

SBIR Phase II Project

SLIDE 2

I see a tank! Need fuel!

• bservations &

recommendations

• rders &

subscriptions Any threats?

The Problem

Getting the right information at the right time to the right agent

SLIDE 3

Program Goals and Development Strategy

Mission types may include: Stability and Support Operations (SASO), reconnaissance, homeland security incident response Small Units include: Military, Police, Fire, Relief, Robots, Weapons, and Sensors Strategy

• Develop and demonstrate SUO Communicator for intelligent

information push

• Develop ontological representation of several small unit

missions, supporting roles, and representative messages

• Develop application and middleware software to filter, query,

and push information to military small unit based on individual roles and missions

• Provide extensibility for expanding missions and roles

The ASIV Communicator will provide relevant and timely information to personnel supporting a small unit operation.

SLIDE 4

Considerations in Program Development

• Radio is the primary means of communication for rapid

tasking and situation update.

• ASIV Communicator does not compete with radio, but

extends effective capability

– Geo-location references – Many people can “speak” at once – Stealth – Auto-create messages – Store information over time

• Design with system extensibility in mind

– Phased approach to build up “knowledge” and scope over time – Scalable architectural design - Consideration for user’s eventual need to quickly add data sources, mission types, and roles

SLIDE 5

Methodology

Relevant Methodologies

– Literature survey – Knowledge acquisition from subject matter experts – Scenario-based development – System-level requirements identification – System architecture development – Simulation-based development – Human factors and field testing – Experimental design

Literature Survey – Related Work

– DARPA Control of Agent-based Systems (CoABS)

• OBJS eGents agent system was developed for CoABS to demonstrate agent (egent)

communication that uses email as a message transport and was the starting point for the current project.

– DARPA UltraLog - UltraLog agent system uses MsgLog, an extension of eGents that provides adaptive multi-transport message communication – Other research programs have focused on publish-subscribe architectures, field studies, geo-location sensitive communications, and user interface technology. These include:

• Air Force Joint Battlespace Infosphere
• Smart Sensor Web
• Army Force XXI Battle Command Brigade-and-Below
• DARPA Command Post of the Future
• DARPA Small Unit Operations: Situation Awareness System Program (SUO/SAS)
• DARPA Communicator

Knowledge Acquisition

– Consultants included former ranger, member of police SWAT team, Smart Sensor Web and MOUT personnel Understand the problem Architecture/Prototype Field Test – we did not do this

SLIDE 6

Scenaro 1 - Hostage Rescue at the Airport

• Squad 1

– Monitor activity at terminals 1, 2, and 4 – Secure parked aircraft – Receive information on vehicles or people approaching terminals – Receive information from deployed sensors in AOI

• Squad 3

– Secure area around POLs – Receive information on buildings in area

• f POLs (fuel tanks)

– Receive information on vehicles or people approaching area – Receive information from deployed sensors in AOI

• Squads 2 and 4

– Secure perimeter of terminal 3 – Report any observations of terrorist behavior – Receive information on vehicles or people approaching area – Receive information from deployed sensors in AOI

Command Center (Airport Fire & Rescue Station) Squads 2 & 4 Terminal 3 Squad3 POLs Squad 1 Terminals 1, 2, 4

• 1. Agents configured to role
• 2. HQ sends maps / grid setup
• 3. Filters distributed to agents
• 4. HQ receives USMTF weather
• 5. Squad 3 moves from CP to AOI
• 6. Sensors placed
• 7. Sensor trips & alerts subscribers
• 8. Ranger resets sensor
• 9. Sensor trips again
• 10. Activity near airport entrance
• 11. Activity near POL sensors
• 12. Ranger ordered to investigate
• 13. Ranger sends report

Squad 3 - Scenario

SLIDE 7

Scenario Background: The U.S. Army is on a routine peace keeping mission in MOUTopia, a small country considered friendly to U.S. interests. One challenge to the peace-keeping forces is the frequent harassment by the anti-U.S. forces in neighboring Sumania. Scenario Overview: On September 26, 2005, at 10:00 a.m. the Food Distribution and Medical Care Center located in MOUT City is attacked, probably sponsored by Sumanian

• patriots. The attack has pinned civilians, medical personnel and soldiers in the building, and

attempted to damage a support helicopter. The number of killed or wounded is not known.

Scenario 2 - MOUT

SLIDE 8

HQ Platoon-01-Leader Squad-03-Leader Ranger-14 Unknown World Sensor-03 Sensor-05 Vehicle-02 Ranger-13

XML messages interpreted sent from

• ne eGent to another (via email transport)

so most routine messages require little or no action on the part of a human

Architecture Overview

A World eGent simulates the environments. All messages are sent to a Log eGent (not shown) which allows scenarios to be later replayed. Distributed eGents-based Communication

SLIDE 9

data source data source

SUO mission

• ntology

SUO domain

• ntology

individual agents have ontologies

…

data sources have ontologies

Ontology is Logically Central

SLIDE 10

Individual eGents

SLIDE 11

Ontology Editor = Stanford Protégé

SLIDE 12

<?xml version='1.0' encoding='UTF-8'?> <!ELEMENT MSG (TIME, FROM, TO, CC?, BCC?, SUBJECT, BODY, ATTACHMENTS?, ACK)> <!ELEMENT TIME (#PCDATA)> <!ELEMENT FROM (#PCDATA)> <!ELEMENT TO (#PCDATA)> <!ELEMENT CC (#PCDATA)> <!ELEMENT BCC (#PCDATA)> <!ELEMENT SUBJECT (#PCDATA)> <!-- for the human, not really used by the system --> <!ELEMENT BODY (TEXTMSG | INFORM | REQUEST | SUBSCRIBE | SUSPEND | RESUME | CANCEL)> <!ELEMENT ATTACHMENTS (#PCDATA)> <!ELEMENT ACK (#PCDATA)> <!ELEMENT TEXTMSG (#PCDATA)> <!-- for the human, others are handled by the RAV02 system --> <!ELEMENT INFORM (CONTENTS)> <!ELEMENT REQUEST (CONTENTS)> <!ELEMENT SUBSCRIBE (SUBSCRIPTIONID, TIMECONSTRAINTS?, DELTA?, CONTENTS)> <!ELEMENT SUSPEND (SUBSCRIPTIONID)> <!ELEMENT RESUME (SUBSCRIPTIONID)> <!ELEMENT CANCEL (SUBSCRIPTIONID)> <!ELEMENT SUBSCRIPTIONID (#PCDATA)> <!ELEMENT TIMECONSTRAINTS (TIMEPERIOD?, REFRESHRATE?)> <!ELEMENT TIMEPERIOD (STARTDTG?, ENDDTG?)> <!ELEMENT STARTDTG (#PCDATA)> <!ELEMENT ENDDTG (#PCDATA)> <!ELEMENT REFRESHRATE (#PCDATA)> <!--in seconds or in offset time TBD by PM -->

Message level Subscriptions ACL level

Messaging XML

SLIDE 13

<!ELEMENT CONTENTS (STATUS | ACTION | ORDER | METHOD1 | METHOD2 | COMMENT)+> <!ELEMENT STATUS (#PCDATA)> <!ELEMENT ACTION (#PCDATA)> <!ELEMENT ORDER (#PCDATA)> <!ELEMENT COMMENT (#PCDATA)> <!ELEMENT METHOD1 (RANGER | UNKNOWN | SENSOR | ADDRBOOK | MAP | CLOCK)> <!ELEMENT RANGER (RANGERGET | RANGERSET)> <!ELEMENT RANGERGET (#PCDATA)> <!-- list containing one or more of LOC PULSE BODYTEMP --> <!ELEMENT RANGERSET (LOC | PULSE | BODYTEMP | AIRTEMP | WINDDIRECTION)*> <!ELEMENT LOC (#PCDATA)> <!ELEMENT PULSE (#PCDATA)> <!ELEMENT BODYTEMP (#PCDATA)> <!ELEMENT AIRTEMP (#PCDATA)> <!ELEMENT WINDDIRECTION (#PCDATA)> <!ELEMENT SENSOR (SENSORGET | SENSORSET)> <!ELEMENT SENSORGET (#PCDATA)> <!-- list containing one or more of LOC SENSORDIRECTION READING --> <!ELEMENT SENSORSET (LOC | DIRECTION | SETTING | READING)*> <!ELEMENT DIRECTION (#PCDATA)> <!ELEMENT SETTING (#PCDATA)> <!-- set | triggered --> <!ELEMENT READING (#PCDATA)> <!ELEMENT ADDRBOOK (ADDRBOOKADD)> <!ELEMENT ADDRBOOKADD (ADDRENTRY+)> <!ELEMENT ADDRENTRY (ADDRALIAS, ADDR+)> <!ELEMENT ADDRALIAS (#PCDATA)> <!ELEMENT ADDR (#PCDATA)> …

Kinds of Messages Specific Message Types

Messaging XML (cont)

SLIDE 14

• Type / Class identify messages

to apply filter to and Java class with filter-specific “evaluate” method.

• Conditions identify message

fields to evaluate, value(s) and range criteria.

• Operators identify boolean

relations between multiple conditions.

10 20 30 40 50 60 70 80 90 1st Qtr 3rd Qtr East West North

• <FILTER>

<NAME>Near Airport Terminal or Area 7</NAME> <CLASS>LocationFilter</CLASS> <TYPE>USMTF</TYPE>

• <CONDITION>

<FIELD>GM_OperExer</FIELD> <STRING>Quick Recovery</STRING> </CONDITION> <OPERATOR>AND</OPERATOR> <OPERATOR>(</OPERATOR>

• <CONDITION>

<FIELD>GM_Location</FIELD> <LOCATION>AREANM:AREA 7</LOCATION> <RANGE>SEC:000230N0000530W</RANGE> </CONDITION> <OPERATOR>OR</OPERATOR>

• <CONDITION>

<FIELD>GM_Location</FIELD> <LOCATION>SEC:351234N12810W</LOCATION> <RANGE>SEC:001000N0010000W</RANGE> </CONDITION> <OPERATOR>)</OPERATOR>

• </FILTER>

Message Filter Example

SLIDE 15

Sending Agent

Filter Trigger Event ASIV EGENT Send Message (email) Email Server ASIV EGENT Receive Message (email) Process Message

• ID Message Type
• ID class, method
• Invoke method

Apply Filters Resolve Location & Update GUI

Receiving Agent

Resolve address / filter Construct XML

Under the Hood of ASIV Communicator

SLIDE 16

Part of Ranger-14’s address book eGent aliases eGent addresses

Message Group Alias

Part of eGent initialization is sending messages containing address book, maps, role(s), etc.

SLIDE 17

Message Received

• Message sent as XML-formatted message.
• XML tags allow creation of summary

message, extraction of key fields.

• Geo-referenced messages plotted on map

using icon defined in ontology.

SLIDE 18

Wired, Secure Wireless, or mixed LAN or WAN

• ASIV egents run on one or many machines.
• ASIV platforms use any email server and/or multiple different email servers
• For demo, we use the Apache James running on one of the ASIV platforms

ASIV egent email server email server ASIV egent ASIV egent ASIV egent ASIV egent any email client

Machine boundaries process boundaries LAN or WAN

Scalable ASIV Architecture

Distributed Wireless ASIV eGents

SLIDE 19

• Message formats entered in Protégé message ontology
• Classes defined for message types
• Slots defined for message fields
• “High Value” fields identified by XML mapping file
• Message parsing routine maps text file to message format

definition in Protégé

USMTF Information Source

SLIDE 20

<?xml version="1.0" encoding="UTF-8" ?> <USMTF_MSG> <OriginalMessage> <EOBSREP> +<OPER> <MSGID> <MESSAGETEXTFORMATIDENTIFIER>EOBSREP</MESSAGETEXTFORMATIDENTIFIER> <ORIGINATOR>TOC</ORIGINATOR> <MESSAGESERIALNUMBER>HOMESTEAD</MESSAGESERIALNUMBER> </MSGID> + <ENACTLOC> + <OBTIME> + <EVENT>

• <GENTEXT>

<GENTEXTINDICATOR>ADDITIONAL ENEMY OBSERVATION INFORMATION</GENTEXTINDICATOR> <FREETEXT>HOSTILE CROWD SHOOTING REPORTED CASUALTIES UNKNOWN</FREETEXT> </GENTEXT> </EOBSREP> </OriginalMessage> <GENERIC> <GM_MsgType>Threat</GM_MsgType> <GM_Originator>TOC</GM_Originator> <GM_OperExer>QUICK RECOVERY</GM_OperExer> <GM_Activity>POSSIBLE ENEMY ACTIVITY</GM_Activity> <GM_Activity>SHOOTING</GM_Activity> <GM_Location TYPE="LATLON"> <LAT>24.135555555555555</LAT> <LON>80.48333333333333</LON> </GM_Location> <GM_Time>150830Z2727JULY2004</GM_Time> <GM_Freetext>HOSTILE CROWD SHOOTING REPORTED CASUALTIES UNKNOWN</GM_Freetext> </GENERIC> </USMTF_MSG> OPER/QUICK RECOVERY/HOSTAGE// MSGID/EOBSREP/TOC/HOMESTEAD// ENACTLOC/POSSIBLE ENEMY ACTIVITY/SEC:240808N0802900W//// OBTIME/150830Z2727JULY2004// EVENT/SHOOTING// GENTEXT/ADDITIONAL ENEMY OBSERVATION INFORMATION/HOSTILE CROWD SHOOTING REPORTED CASUALTIES UNKNOWN//

Text message parsed to XML; key fields identified

USMTF Messaging – Parsed Message

SLIDE 21

• Can be used to author

scenarios

• Can be used to run

scenarios, providing a common operational picture

• Can be used for after

action reporting and analysis

• Records messages via

Bcc

• View messages an

eGent can send and/or receive

• Select subset of the

log to study subset of the eGents e.g., medical, logistics

Simulation Mode driven by Message Log

aka Scenario Authoring Capability

SLIDE 22

Xybernaut Tallacomm Fujitsu Panasonic # Requirement / Goal Weight MA-V S Tacter31 S LifeBook P1000 S Toughbook 07 S 1 Runs ASIV Applications: Full Java VM PC Arch w/ 233 MHz min 128 MB RAM min 10

+ +

20

+ +

20

+ +

20

+ +

20 2 Runs & connects to standard COTS database 10

+ +

20

+ +

20

+ +

20

+ +

20 3 Small / Wearable 10

+ +

20

+ +

20

+ +

20

+ +

20 4 Field useable display size - 2" x 3" min 10

+ +

20

+ +

20

+ +

20

+ +

20 5 Wireless Network for battlefield 10

+ +

20

+ +

20

+ +

20

+ +

20 6 Soldier positioning via GPS 10

+ +

20

+ +

20

+ +

20

+ +

20 7 Integral camera 3

• -
• 6
• -
• 6
• -
• 6
• -
• 6

8 Targeting device - use w/GPS 2

• -
• 4

+ +

4

• -
• 4
• -
• 4

Integral / Interface to sensors: 9 Soldier health telemetry 3 10 Weather 1 11 Soldier motion 3 12 Soldier resource telemetry 3 13 Ruggedized 5

+ +

10

+ +

10

• 5

+ +

10 14 Wearable / weight bearing harness 3

+ +

6

+ +

6

+

3

+ +

6 15 Extended operation > 8 hours 3

+

3

+

3

+ +

6 16 Fast initialization (< 5 sec.) 1

• -
• 2
• -
• 2
• -
• 2
• -
• 2

17 Power saving modes 2

+

2

+

2 18 Field-tested - Acceptance 2

+

2

Total Trade Score > 127 137 114 126

Estimated Price: $5832 w/o GPS around $10K $1338 w/o GPS $6146 w/o GPS

Porting SUO Communicator to Small Footprint Hardware Platforms

• Multiple Systems evaluated against ASIV requirements
• Tacter31 meets most system requirements
• Performance of handhelds not optimal for maximum

demonstration system experience

SLIDE 23

Conclusion and Potential Impact

Demonstrations show feasibility for a SUO Communicator

• prototype. With more work and field testing, the SUO

Communicator could have significant potential impact:

– The SUO Communicator could complement radio as a digital situation awareness device that could be available to all echelons, down to troop level. – The egent-based architecture can filter and control information flow

• n a role and mission basis meaning per-agent control over the

blizzard of information. – The architecture extends uniformly to control remote equipment (embedded in sensors, weapons, vehicles, robots) and to provide access to a variety of remote information sources. – Egents can be distributed over LANs, WANs, and in wireless environments – the architecture is scalable, probably to thousands (or millions) of egents. – Using eGents, anyone with email can create an agent service that anyone else can use.

SLIDE 24

Future Directions

• Support planning and execution through separating the core

system, application, and scenario

• Ontology coverage extensions

– Extend Role, Mission, relationship coverage – Add to demo realism through additional message types, image and video exchange, allowing agents to come and go from scenario

• Interoperability extensions

– Interoperability with other messaging systems, data sources, C4ISR systems, simulations – Interoperability among ASIV Communicators used by different kinds of teams, e.g., rangers and police.

• Semantic extensions

– Deeper text understanding for message content and query support – Accommodate missing or out-of-date messaging due to intermittent connections or “being too busy to respond”

• Aggregate field reports to support more complex situation assessment
• Survivability, security, reliability, scalability, assurance testing
• Field testing

– User-based scenario development and ontology editing – Port system to Xybernaut and demonstrate at the MOUT – Integration on real hardware and with message traffic