Multi-Agent Systems - Architecture

1. Multi-Agent Systems - Architecture Craig Thompson Object Services and Consulting, Inc. (OBJS)

2. OUTLINE • Vision • Agent Reference Architecture • Agent Services • Applications • Contributions & Directions

3. orders & subscriptions observations & recommendations Any threats? Need fuel! I see a tank! VISION – EVERYTHING IS ALIVE

4. AGENT REFERENCE ARCHITECTURE What is a Reference Architecture • a meta-architectural blueprint for a family of concrete architectures that may appear in implemented systems, providing architectural views, a collection of the component parts of the architecture, how they can fit together, and any constraints on how they fit. • a litmus test for a good reference architecture is that it covers actual systems and provides a way to reason about missing pieces, sub-architectures that make sense, interdependencies of parts, and how the architecture relates to other nearby architectures. What should an Agent Reference Architecture do? • help people understand the scope and value-added of agent systems so they can realize their potential more quickly (agents for the masses) • explain • how agent architectures solve application domain problems • how agent systems complement OMA, HLA, Web, DBMS • how to insure systemic properties of agent systems – scalability, survivability, … • identify • principle components of agent systems, their interfaces and their interactions • missing components • what parts of the architecture already exist in COTS and GOTS, what parts are already prototyped, and what parts are still needed. • candidate standards and a roadmap for adoption • research issues (e.g., agent control, agent interoperability)

5. Agents dynamically adapt to and learn about their environment Agents coordinate and negotiate to achieve common goals social personality social personality Adaptive to uncertainty and change Adaptive Cooperative self-organizing delegation Cooperative Autonomous proactive Autonomous Mobile Mobile Interoperate Interoperate Agents move to where they are needed Agents interoperate with humans, other, legacy systems, and information sources Agents are goal directed and act on their own performing tasks on your behalf Characteristics of Agents Intelligent Agents Information Agents

6. What are people saying about agents? • software that acts on a human’s behalf to provide some service or function in an intelligent manner • modular software that exhibits some of these properties: autonomy, mobility, intelligence • objects with an attitude -- component software constructed according to certain principles and/or mechanisms, e.g., objects that use an ACL to communicate, objects that make use of a planner, … • networked society where every software artifact, information source, and device is connected and running in parallel. Connect the $40B worth of DoD equipment that currently only interoperates with one or two other components, permitting better knowledge sharing. A process improvement in factory 1 is broadcast immediately to factories 2 .. N • intelligent automation-- application connectivity where networks of agents self-organize at run-time. Reduce the 60% of time in command and control systems spent manipulating stovepipes; incrementally replace stovepipes. • humans and agents connect to the agent grid anytime from anywhere and get the information and capability they need. Enable teams led by humans and staffed by agents. • agent-enable object and web applications to reconfigure as new data and function is added to the system. Add capability modularly. Stable, scaleable, evolvable, reliable, secure, survivable, ... • Scale to millions of agents so agents are pervasive and information and computation is not restricted to machine or organization boundaries. • Survivable so if one agent goes down, another takes its place;

7. Relevant Theories View • speech acts, conversations/dialogs • ontologies • KBMS • distributed AI • architecture description languages • patterns and protocols • OO middleware service architectures (OMA/ORB) • web architectures • workflow • dynamic DBMS • simulation • network management, QoS • planning & case-based reasoning • learning • game theory • economic markets • ... * = Architecture WG in Pittsburg

8. What is an Agent? deconstructionist view: agents augment objects with additional capabilities Object Component  Agent ? • state • behavior • encapsulation • inheritance • reflection • packaging • serialization • repository • agent comm. language • process inside • mobility • goals, planning, rules • autonomous • ontologies • collaborative/teams • TBD

9. FIPA Abstract Architecture Foundation for Intelligent Physical Agents -- http://www.fipa.org/specs/fipa00001 • Agent Abstract Architecture  goal is interoperability • Agent API via Agent Communication Language (ACL) • addressing • publish & subscribe • content language semantics • Agent Services • Encoding/Parsing Service – how messages are encoded • Message Transport Service – how messages are sent, guarantees, survivability • Directory Service – register agent description, discover agents • Borrows from other areas • User Interface(s) – optional – GUI, natural language, … • Security services • Directory services • Distributed communications – asynchronous, intermittent • Platform & comm. – host abstract machine, environment • Candidates not yet in current abstract architecture • Agent lifecycle • Mobility • Domains • Conversational policies • Ontologies – representation of state components & interfaces Interfaces insulate components. We should be able to add or change a component.

10. Agent Ontology View (aka Functional/Compositional View) Architecture Principle: separation of concerns deconstructionist view - what can you take away and still have an agent system • policy*, management • resource dial ALP, HLA, IA GRID federates • AGENT SYSTEM • single vs. multi-agent • heterogeneous* • computing environ. • agent systems • ACLs • content languages • ontologies • policies • services • open world assumption systemic grid features common services • ensembles • # of agents* • teams, peers, contracting, • org. responsibility • roles, capabilities, • mutual beliefs • hierarchy* • conversational policies* • societies • closed vs. open, communities of interest • agent properties & kinds • communication capability • computation capability • by role in system • information agent • data sources • interface agent • NL • fisheye view • task agent • web agent • middleware agent • mobile agent, itinerary • social, personality, motivation, forgetting • intelligent agent distribution messaging svcs* agent life cycle* - start, stop, checkpoint, name service** event monitoring leasing, compensation catalog services*, registry/repository* register*, offer/accept/decline publish*, subscribe* trading*, matchmaking, advertising*, negotiating*, brokering*, yellow pages* security** authenticate* encrypt access control lists* firewall* CIA model agent suspects transactions persistence* query, profile (of metadata)* data fusion replication* groups multicast (scarce) resource mgmt*, allocate*, deallocate*, monitor*, local, global optimization, load balancing*, negotiation for resources* scheduling time, geo-location rules, constraints planning* property list versioning, config autonomous decentralized* • control*, coordination*, • multi-agent synchronization • cooperation, competition I*3 BADD AICE OMG JTF Jini scalability* adaptation, evolution* via market model, ... licensing & cost mobility** • ONTOLOGY** • ontolingua, OKBC • metadata representations • interests, locations, availability, capability, price/cost • XML and web object models secure*, trust IA speech acts*: ACL* - KQML, FIPA ACL, OAA ICL survivability • planning* • reactive* • goal interactions* • discrete vs continuous* • constraints • iterative, revision • workflow • infrastructure • primitives • reflection • serialization • threads • interceptors • proxies • filters • multicast • wrappers • legacy sys • data sources evolvability EDCS • missing • views • MOP reliable* • QoS* • accuracy • priorities Quorum • learning • by example • ... More common services instrumenting, logging caching queuing routing, rerouting pedigree, drill down translation* ... time-constrained* • content languages • KIF, FOL, IDL, RDF * = Architecture WG in Pittsburg * = Control WG in Pittsburg * = Interoperability WG in Pittsburg red = Sun Jini green = other DARPA programs DDB

11. AGENT SERVICES • WebTrader – Use search engines as yellow pages to locate agent services. Anyone on the Web can advertise a resource (e.g., agent, service, data source) that anyone else can discover. • MBNLI – Use web pages to store semantic grammars. Humans can query agents across the web using constrained natural language. • eGents – Use email as agent transport supporting disconnected operations. Anyone with email can create an agent service that anyone else can use. • MsgLog – Provide several message transports and select among them using policy. Messaging is survivable (robust, secure, scalable). Piggyback agent service on standard widely deployed infrastructure for pervasive agent deployment … agents for the masses.

12. Services / Datasources Agent World White GeoCoder Pages 7 Ariadne 2 6 Open (ISI) Agent 1 Web World Architecture 3 (SRI) page page page WebTrader AD AD AD Agent 5 page page Agent page AD AD Grid 4 Search page Engine page AD page page page AD WebTrader was used in the NEO TIE to locate evacuees and to find a geocoder. AD WebTrader: Scalable Agent Discovery Problem Impact • If grid applications are to be assembled when needed, the parts must be found somewhere and probably not all will come from the local environment. • How can we find building block resources (e.g., agents, services, channels, components, data sources) when we need them? • Today, traders (matchmakers) are used for this purpose but these traders generally know only about closed worlds of resources of limited types (e.g., IDL). • Anyone on the Web can advertise a resource (e.g., agent, service, data source) that anyone else can discover. • Advertised resources can be located at runtime to dynamically extend the knowledge and/or capabilities of the client, as well as enable intelligent on-the-fly assembly and reconfiguration of distributed systems. Approach • WebTrader is a matchmaking service that locates XML-based advertisements for resources embedded in web pages indexed by industrial-strength search engines. • WebTrader supports type-specific matcher algorithms, trader federation, and can access multiple search engines.

13. Response Web Page 1 Trader Advertisement 2 WebTrader Architecture Query (Client Advertisement) 14 4 5 WebTrader 13 Web Trader Engine WebTrader matches and returns candidate advertisements 6 12 10 Matching 11 7 9 Web Search Engine(s) 8 Locates and returns candidate pages Indexed by 3 Trading advertisements may be distributed across some part of the Web

14. WebTrader Query Tool

15. MBNLI: Menu-based Natural Language I/F Problem Impact • Humans can task and query agents using complex but understandable commands in constrained natural language. • This technology can mix pervasively into all applications, both on the desktop and the Web. • Dynamic military situations will require people to task and query agents using complex commands. • Unconstrained natural language is still not tractable in many situations. Approach • Thesis: Natural language-enhanced user-to-agent communication will simplify basic human-agent interactions while making it possible for humans to formulate complex agent requests. • Approach: Agents communicate with people and other agents using restricted languages for stating complex queries and commands • How: MBNLI extends agents with natural language middleware wrappers, dynamically loads grammars, and uses menu-based natural language to query and task agents. Works over the web with many users, can auto-generate NLI interfaces to DBMS, works with speech, and is on the CoABS grid.

16. MBNLI Example

17. eGents: Agents communicating via Email Problem Impact • Dynamic military situations are often disconnected and asynchronous. Need a scalable way to deliver agent messages to 1000’s of (wireless) platforms. • Agent systems are often closed and require a lot of specialized agent technology. Email is a common denominator in coalition situations. • Anyone with email can create an agent service that anyone else can use. New eGent apps can be downloaded to the field as situations change. • Imagine eGents attached to sensors, actuators, people, equipment, and locations as pervasive observers & actors Theme: Everything is alive Approach • Thesis: Integration of agent technology with pervasive Web-ORB-Email backplanes is a route to making agent technology open, pervasive and robust. • eGents are agents which communicate over email. eGents leverages pervasive, robust email infrastructure, inherits support for disconnected operations, message queuing, mobile users, firewalls, filtering, logging, and security. eGents use FIPA or KQML Agent Communication Language (ACL) encoded in XML - no ACL parser needed. Status: Prototype, gridified via proxy and as comm. layer, on wireless Palm. NEO, MIATA, CoAX, JBI TIEs. Spec submitted to FIPA. eGents Inside Command Post Evacuees/ Troops/ Wildlife/ Etc. Medevac Liaison Family Member In these eGents applications, each evacuees/troops/animals have a Personal Status Monitor, which measures location, vital signs, etc. The PSM contains an eGent which intermittently communicates to subscribing entities using email protocols.

18. eGents Example

19. eGents interoperating with each other and with an eGent-grid proxy eGents Architecture Might be on machine 2 or anywhere on LAN or on grid-connected LAN PSM client grid agent Machine 1 installed on soldier, evacuee, vehicle, weapon Machine 2 perhaps installed at command post Machine 3 perhaps installed at medevac unit subscribe inform eGent grid agent proxy PSM server eGent PSM client eGent other eGents other eGents other eGents Grid eGents platform** eGents platform* eGents platform inform subscribe inform inform subscribe subscribe * Java-based ** KVM-based - runs on Palm uses J2ME CLDC 1.0 FCS (KVM), that is, Java for devices runs on a "wireless" palm over the CDPD digital cellular network Email Server All eGents can share one Email server or they can each have their own or anything in between

20. MsgLog: Agent Messaging Service Policy Mgmt Adaptive & Survivable Encryption Compression Recovery / timeout / Retry Adaptive Messaging Local Messaging Agent Periodic Connection Agent (Palm) RMI Messaging Mail servers (store & forward) Email Messaging Firewalled Agent NNTP Messaging Info servers (situation updates/ Logs) Overwhelmed Agent (only get latest update - not intermediate) Other Messaging sockets, JMS, … Mask Traffic Patterns White Noise

21. The Basic Idea

22. DARPA CoABS Coalition Agent Experiment DARPA CoABS-AFRL Joint Battlespace Infosphere AFRL Small Unit Operations Communicator APPLICATIONS

23. Coalition Agent Experiment (CoAX) Theme: Everything is alive • Are the Safari Park elephants in danger? • eGents monitor and transmit positions of the two elephant herds • menu-based natural language queries determine the elephants are migrating out of the firestorm area Elephant herd migrations over the last 40 months Current position of herd 17.0N/ 34.4E - 2012/09/01 14:20 Safari Park OBJS role in CoAX TIE

24. Safari Park Vignette

25. MBNLI So elephants were here at beginning of the month. Where are they now?

26. eGents subscribe inform

27. World HQ Unknown Sensor-03 Sensor-05 Squad-03-Leader Ranger-14 Platoon-01-Leader Vehicle-02 Agent-basedSUO* Communicator Develop a reconfigurable handheld computer capability, tailorable to the user role and mission for mission planning and execution, and extensible to new small unit applications. Complement Radio • Many people can “speak” at once • Auto-create and handle messages • Memory & Listening Aid - Store information over time • Accuracy of Geo-location references • Support for disconnected opertions • Assured delivery • Stealth • After action analysis * Small Unit Operations (SUO) • military, police, NGOs, …, • leaders, soldiers, medics, …, • robots, vehicles, weapons, sensors, …

28. Squad3 POLs Scenario Actions • Agents configured to role • HQ sends maps / grid setup • Filters distributed to agents • HQ receives USMTF weather • Squad 3 moves from CP to AOI • Sensors placed • Sensor trips & alerts subscribers • Ranger resets sensor • Sensor trips again • Activity near airport entrance • Activity near POL sensors • Ranger ordered to investigate • Ranger sends report Squads 2 & 4 Terminal 3 Command Center (Airport Fire & Rescue Station) Squad 1 Terminals 1, 2, 4 Scenario – Terrorists at the Airport Soldier Tasks 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 of POLs • 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

29. Scenario – Hostage Rescue at the MOUT The U.S. Army is on a routine peace keeping mission in Sol del Naro, 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. 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.

30. SUO eGents and Ontology

31. Messaging XML DTD <?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 milliseconds --> Message level ACL level Subscriptions

32. Messaging XML DTD (cont) <!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

33. Message Log • 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 aka Scenario Authoring Capability aka Simulation Driver Capability

34. Under the Hood of SUO Communicator Sending Agent Trigger Event Apply Filters Construct XML Resolve address Send Message (email) Email Server Receiving Agent • Invoke Method • - Resolve Location • Update GUI • … Apply Filters Receive Message (email) Parse Message

35. Message Filter Example • <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> • 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.

36. Agent Conversation REQUEST SUBSCRIBE SUSPEND CANCEL RESUME ACK ACK INFORM INFORM Y-JBI sends, eGents receives – eGents sends, Y_JBI receives

37. Example

38. Example

39. Distributed Wireless ASIV eGents Wired, Secure Wireless, or mixed LAN or WAN Scalable Architecture Machine boundaries email server email server LAN or WAN process boundaries ASIV egent ASIV egent ASIV egent ASIV egent ASIV egent any email client You can run one or several ASIV egents on one or many machines. For standalone demos, we use the Apache James email server running on one of the ASIV platforms. But you can use any email server and/or multiple mix-and-match email servers.

40. Hand Held Trade Study

41. CONCLUSIONS

42. Contributions • Strawman agent reference architecture influenced • DARPA CoABS Agent Grid • OMG Agent Architecture ** • FIPA Abstract Agent Architecture ** • Agent Grid Services developed for DARPA CoABS Program • WebTrader * • AgentGram * • eGents agent system • Generic XML2Java mapping * • FIPA adopted • Representing agent communication language messages in XML ** • Email message transport ** • SUO artifacts • SUO Communicator requirements • SUO Ontology – coverage issues • SUO Message XML DTD • Explicit representation for scenarios as collections of messages • Useful for simulation and after action analysis • SUO Communicator Prototype • Cougaar uses our adaptive, survivable message service * Patent Application ** Standard

43. Directions • Architectural modularity - separating the core system, application, and scenario • Addin for planning • Addin for MBNLI - Semantic web and web object model • MBNLI I/F descriptor (e.g., grammar) as wrappers for any entity (agent, web page, info source, internet resource, …) • MBNLI wrapper composition so you can talk to collections of heterogeneous entities • Web-enabled MBNLI accessible from any web page – grammars on web pages • Ontology coverage extensions • Demo realism - through additional message types, image and video exchange • Ontology editor to define and edit eGents, address books, missions, roles, maps, grids, icons, subscriptions, filters, message types, scenarios (sequences of message instances), data sources, panels and .jars • Mission doctrine coverage • Interoperability with other messaging systems, data sources, C4ISR systems, simulations • Framework for adding new data sources • Interoperability among ASIV Communicators used by different kinds of teams, e.g., rangers and police • Enable end users to extend system by integration of ontology with GUI/eGents • Semantic extensions • allowing agents to come and go from scenario – enclaves, mobility • Incomplete info - due to missing or out-of-date messaging due to intermittent connections or being too busy to respond • Aggregate periodic field reports • Borg Collective • P2P XML and SQL query and evaluating distributed queries • Agent Management • Adaptability – esp. Policy Management Infrastructure for agents • Survivability, security, reliability, scalability, assurance testing • Assuring safety • Basic performance • Garbage collecting servers • Gathering statistics on communications behavior & predicting expected future behavior • Amplify capability of log file to support After Action Review • Field testing • Can mission planners use the system to create new scenarios quickly • Port to small footprint platform and field test at MOUT • Can ASIV communicator users use system in field exercises • Scalability - automated deployment to new platforms, download eGent apps to the field as situations change -- currently eGents requires manual installation limiting fast fanout of new eGent applications. - ASIV applet for training

44. QUESTIONS

46. BACKUP

47. Acronyms • OMG Object Management Group (Agent SIG) • FIPA Foundation for Intelligent Physical Agents • CoABS DARPA Control of Agent-based Systems • CoAX Coalition Agent Experiment • JBI AFRL Joint Battlespace Infosphere • UltraLog DARPA UltraLog Program (Survivable Agents for Logistics) • ALP DARPA Advanced Logistics Planner • Cougaar DARPA Cognitive Agent Architecture • Msg*Log OBJS Agent Messaging Service • MBNLI Menu-based Natural Language Interface • ACL Agent Communication Language • LAN Local Area Network • WAN Wide Area Network • RPC Remote Procedure Call • Java RMI Java Remote Method Invocation • SMTP Simple Mail Transfer Protocol • POP3 Post Office Protocol • NNTP Network News Transport Protocol • XML Extensible Markup Language • TIE Technology Integration Experiment

48. Joint Battlespace Infosphere (JBI) Small Unit Operations TIE • Headquarters in Bosnia gets mole report of enemy shadowing US platoons. [1] • Rome Y-JBI Outlook agent system received email alerts from info sources it is monitoring. • Commander zooms map to the affected area and subscribes to platoon-level status reports. [2, 3, 4] • OBJS eGents representing platoons receive these subscriptions by (wireless) email. • Feeds from troops are aggregated in platoon level reports which are sent to subscribers, including the commander. [5] • Platoon level eGents aggregate troop level reports and begin to send back platoon level reports to subscribers, including the commander. • Map changes to show changing platoon locations. • As the scenario plays, fuselets notice two platoons are under attack, one via conventional weapons, the other via chemical attack. [6] • As simulation plays, map changes to show platoons in trouble. This is discovered by Y-JBI fuselets that look for specific patterns in the communication. In this case, one soldier is killed and another wounded in one platoon and another suffers a chemical attack.

49. JBI TIE Scenario 2 1 4 3 5 6

50. SUO eGents send messages to each other Two modes: use GUI point-and-tap to send messages –or– use scenario message log to drive simulation Simulation Control (World) HQ MsgLog Bcc log of messages provides an explicit scenario representation that can be replayed or analyzed for after action reporting sends ADVANCE CLOCK messages to step thru demo - or alternatively - user can use ASIV egent GUI to create a stream of messages Platoon Leader Squad Leader Ranger-14 USMTF Messaging System Other External Data Source USMTF proxy proxy Sensor-5 other message format USMTF slash message format • ASIV eGents use XML message format; eGents proxies handle foreign message formats • ASIV eGents automatically handle most messages • aliasing allowed in addresses, e.g., TO: All Platoon Leaders Bcc: MsgLog • subscriptions are used to auto-send updates periodically • filters are used to block sending and receiving unwanted messages