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

SUO Communicator Agent-based Support for Small Unit Operations Barbara Brown – ScenPro, Inc. Paul Morris – ScenPro, Inc. Craig Thompson – OBJS October 1, 2003 SBIR Phase II Project KIMAS 2003 Object Services and Consulting, Inc.

The Problem Getting the right information at the right time to the right agent orders & observations & subscriptions recommendations Need Any I see a fuel! threats? tank!

Program Goals and Development Strategy The ASIV Communicator will provide relevant and timely information to personnel supporting a small unit operation. 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

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

Methodology Relevant Methodologies – Literature survey Understand the problem – Knowledge acquisition from subject matter experts – Scenario-based development – System-level requirements identification Architecture/Prototype – System architecture development – Simulation-based development – Human factors and field testing Field Test – we did not do this – 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

Scenaro 1 - Hostage Rescue at the Airport Squad3 • Squad 1 POLs – Monitor activity at terminals 1, 2, and 4 – Secure parked aircraft – Receive information on vehicles or people approaching terminals Squads 2 & 4 – Receive information from deployed Terminal 3 sensors in AOI • Squad 3 Command Center – Secure area around POLs (Airport Fire & – Receive information on buildings in area Rescue Station) of POLs (fuel tanks) – Receive information on vehicles or people approaching area – Receive information from deployed sensors in AOI • Squads 2 and 4 Squad 1 Squad 3 - Scenario – Secure perimeter of terminal 3 Terminals 1, 2, 4 – Report any observations of terrorist 1. Agents configured to role behavior 2. HQ sends maps / grid setup – Receive information on vehicles or people 3. Filters distributed to agents approaching area 4. HQ receives USMTF weather – Receive information from deployed sensors in AOI 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

Scenario 2 - MOUT 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.

Architecture Overview Distributed eGents-based Communication World HQ Unknown Sensor-03 Sensor-05 Ranger-14 Squad-03-Leader Platoon-01-Leader XML messages interpreted sent from one eGent to another (via email transport) so most routine messages require little or Ranger-13 no action on the part of a human Vehicle-02 A World eGent simulates the environments. All messages are sent to a Log eGent (not shown) which allows scenarios to be later replayed.

Ontology is Logically Central SUO mission SUO domain data sources ontology ontology have ontologies data data source source … individual agents have ontologies

Individual eGents

Ontology Editor = Stanford Protégé

Messaging XML <?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)> Message level <!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)> ACL level <!ELEMENT SUSPEND (SUBSCRIPTIONID)> <!ELEMENT RESUME (SUBSCRIPTIONID)> <!ELEMENT CANCEL (SUBSCRIPTIONID)> <!ELEMENT SUBSCRIPTIONID (#PCDATA)> <!ELEMENT TIMECONSTRAINTS (TIMEPERIOD?, REFRESHRATE?)> Subscriptions <!ELEMENT TIMEPERIOD (STARTDTG?, ENDDTG?)> <!ELEMENT STARTDTG (#PCDATA)> <!ELEMENT ENDDTG (#PCDATA)> <!ELEMENT REFRESHRATE (#PCDATA)> <!--in seconds or in offset time TBD by PM -->

Messaging XML (cont) <!ELEMENT CONTENTS (STATUS | ACTION | ORDER | METHOD1 | METHOD2 | COMMENT)+> Kinds of <!ELEMENT STATUS (#PCDATA)> Messages <!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)> Specific <!ELEMENT SENSOR (SENSORGET | SENSORSET)> Message <!ELEMENT SENSORGET (#PCDATA)> <!-- list containing one or more of LOC SENSORDIRECTION READING --> <!ELEMENT SENSORSET (LOC | DIRECTION | SETTING | READING)*> Types <!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)> …