Food & Beverages

6 pages

Collaborative Agents for an Integrated Battlespace

of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Collaborative Agents for an Integrated Battlespace
   Appear in Proc. of the Fifth 2001 World Multi-Conference on Systemics, Cybernetics, and Informatics, Orlando, FL. Collaborative Agents for an Integrated Battlespace John C. Dumer and Timothy P. Hanratty US Army Research Laboratory Aberdeen Proving Ground, Maryland  and John Yen and Dwi Widyantoro Texas A&M University College Station, Texas  and Jason Ernst and T.J. Rogers University of Maryland College Park, Maryland ABSTRACT   Today’s modern battlespace can generally be defined as any and all aspects of the region of time and space surrounding a battle. Most see dominating the battlespace through digitization as the key force multiplier and primary focus for future success. Hampering this effort are the tremendous amounts of data and information that threaten to overload commanders and staff. Needed are integrated approaches that will improve collection, analysis, exchange and presentation of timely information tailored to specific users, allowing each an accurate view of the battlespace. Software agent technologies are one candidate offered to address the information overload   problem and the topic of this paper. Outlined in this paper is an on-going program between the US Army Research Laboratory (ARL), Texas A&M University (TAMU) and University of Maryland (UM) aimed at coupling disparate software agent architectures across a tactical and logistical military decision support system. Keywords: software agents, decision support, logistics, tactical, battlespace. INTRODUCTION For the US military, the information age and more importantly the advantage held by the US in this area has help shape the development of our weapon and communication systems into the most sophisticated and envy of the world. Unfortunately, it’s that same sophistication and associated information technology base that increases the widely recognized “information overload” dilemma [1]. New sources of data and information are continually being added. Needed are integrated approaches that will improve collection, analysis, exchange and presentation of data, information and knowledge to specific users, allowing each an accurate and adaptive view of the battlespace. One area growing in popularity as an effective means to manage complex areas of decision support and knowledge management are software agents. Software agents are generally defined as processes that are long-lived, semi-autonomous, proactive and adaptive with the goal of assisting users with computer-based tasks [2]. The degree of autonomy and proactive behavior associated with an agent is highly dependent on user preference and the agent’s goal and inferential capacity. The popularity of software agents has given raise to an explosion of agent types and architectures, to include: interface agents, mobile agents, collaborative agents, information agents and a myriad of others. For this program, the general goal is to demonstrate the applicability of software agents to reduce military information overload. Specifically, demonstrate the integration and collaboration of data, information and knowledge linking a military weapon system across disparate tactical and logistical software agent architectures to unit commanders and staff. Success would ultimately be measured by a real-time or near-real-time accurate view of the battlespace while reducing information overload.   Appear in Proc. of the Fifth 2001 World Multi-Conference on Systemics, Cybernetics, and Informatics, Orlando, FL. To accomplish this goal the research efforts and expertise from ARL, TAMU and UM were combined into a single working prototype. ARL, having developed the Army’s first successful diagnostic expert system for the M1 tank, provided the necessary weapon system expertise and overall system architecture [3]. TAMU, working out of its Center for Fuzzy Logic, Robotics, and Intelligent Systems (CFL) leverage its on-going efforts in battlefield information management and prognostics into the development of the tactical agent architecture [4]. While UM capitalize on its own software agents research, entitled Interactive Maryland Platform for Agents Collaborating Together (IMPACT), into the development of the logical agent architecture [5]. The following section gives a detailed perspective of how the system was designed and developed. SYSTEM OVERVIEW At its highest level of abstraction, the system can be viewed (Figure 1) as two disparate software agent environments that operate on a domain of interest. For our military application, the software agent model the tactical and the logistical environments for the domain of a battalion of US Army Abrams main battle tank (M1). Tactical Agent Environment Developed at Texas A&M University (TAMU), the Tactical Agent Environment (TAE) provides assistance in (1) generating repair/parts request to a Logistics Agent Environment (LAE), (2) modifying the priorities of the repair/parts request as necessary, and (3) predicting the fighting capability of a unit [6]. The left-hand side of Figure 1 depicts the TAE design, which is based on a client-server architecture. At the heart of TAE is an Information Broker Agent (IBA) that serves as the TAE server. Other sub-systems (e.g., TAE Interfaces, TAE Shells and On-board Simulator) act as the TAE clients. TAE sub-systems are implemented using Java 1.3 where all communication between TAE clients and TAE server are conducted using Java Remote Method Invocation (RMI). The IBA maintains all data and manages the traffic of information & messages among sub-systems within TAE and with other agent (e.g., LAE). Upon receiving a fault message from On-board Simulator signaling that a particular tank needs a repair, the IBA will send a repair/parts request to LAE and notify the corresponding unit commanders about Figure 1: System Overview On-board Simulator   Information Broker Agent   Database TAE SHELL • Fault Diagnostic • Health Check • Ammunition Level • Fuel Level TAE Interface TAE Interface TAE Interface Brigade Commanders Battalion Commanders Company Commanders Readiness Profiles Reair/Parts Priorities   • Tank • Unit Org • Faults/Parts • Messages • Orders • Clients LAE Coordinator Agent   Presentation Agents   Inventory Agents   Transport Agent   Repair Crew Agents   Inventory Database Repairs Database Route Information Monitor and update inventory levels oftank partsDynamically create PowerPoint presentations containing current logistics information Schedule tank repairs based on: • Tank Priority • Part Availability • Repair Personnel Resources • Fault Type Determines time required to ship parts between locations Tactical Agent Environment (TAE) Logistics Agent Environment   (LAE)     Appear in Proc. of the Fifth 2001 World Multi-Conference on Systemics, Cybernetics, and Informatics, Orlando, FL. the incident. A unit commander via   TAE Interface can view the unit readiness profile in real time or near real time, evaluate & modify the tank repair priorities, and confirm or cancel the submitted repair/parts requests. TAE Shell in Figure 1 provides unit commanders the ability to remotely connect to IBA and securely open the TAE Interface. The IBA maintains the unit organization, tanks, clients & their messages, and repair/parts orders databases. Unit organization defines the hierarchical structure of units (e.g., brigade, battalion, company and platoon) and their capacity. The main tank information consists of current readiness status, location, priority, health check number, ammunition level, fuel level and the expected time to fix (ETF). The TAE clients (TAE Shells, TAE Interface and On-board Simulator) connect with IBA through a sign-up protocol. Upon successful login, a client will be assigned a unique identification number, which will then be used as the client identification in subsequent interactions with IBA. The IBA keeps track of commanders who are on-line so that important messages can be delivered to them immediately. Incoming messages to commanders who are not currently connecting to IBA will be safely kept in its local storage, and the messages will be forwarded to the owners once they sign up with the system. The On-board Simulator (OS) is provided to simulate the output signals of the TED On-board diagnostics equipment [7]. The OS also simulates the output signals of other on-board sensors supplying strategic information such as current tank location, ammunition & fuel levels. By analyzing the changes of tank information based on messages sent by the OS, the IBA will take appropriate actions. For example, if the IBA detects a minor change on a tank (e.g., the change of tank location, a small decrease of fuel level etc.), the change will be propagated only to the TAE Interfaces that currently have the tank information. If a severe tank fault is detected, the IBA will automatically prepare and send a repair/parts request to the LAE and at the same time notify the problem to corresponding unit commanders. In response to the incoming important messages, the TAE Interface then activates an alert signal (currently using a blink red icon) to get the commander attention. The IBA also keeps track the status of repair/parts requests previously submitted. Any incoming messages from LAE about the status of a repair/parts request will be forwarded immediately to the respective unit commander. Similarly, a confirmation or cancellation of a repair/parts request from a commander will be sent back to LAE. Figure 2: Company-level Readiness Profile. Using TAE Shells, commanders can launch TAE Interfaces according to the levels of their unit. The top level of TAE Interface displays the unit readiness profile. This profile information is supplied by IBA based on the units’ organization and tanks readiness level information. Figures 2 shows an example of the readiness profile at the company level. Higher-level unit readiness profiles are presented as a summary of readiness profiles of its sub-units. Additionally, higher-level commanders can view the readiness profile of sub-units under their commands. For example, from the battalion-level readiness profile (Figure 3), a battalion commander is able to browse the readiness profile of Alpha-Company (Figure 2), Bravo-Company and Charlie-Company. Figure 3. Battalion-level Readiness Profile. Tank icons with three different colors are used to represent a tank readiness levels. Green   tank icon represents that the tank is in good condition and is operational. Amber   tank icon is a symbol for a tank that experiences a minor engine problem but the tank still can be operated. Red   tank icon represents a tank with severe engine fault and is   Appear in Proc. of the Fifth 2001 World Multi-Conference on Systemics, Cybernetics, and Informatics, Orlando, FL. currently not operational. The more detail information about a particular tank (e.g., current location, repair status, ammunition level etc.) can be viewed by clicking the corresponding tank icon (see Figure 4). At this point, a commander may review the current status of a repair/parts request, evaluate it against current policy of tank repair priorities, and decide whether to confirm or cancel the repair/parts request. If needed, the commander can submit a new repair/parts request. Figure 4. Detail Tank Information. TAE Interface also provides an interface to modify tank repair priorities. Figure 5 shows this interface at company level, which also enables a commander to explain the reason behind changing the tank repair priority. Any changes that occur in the tank repair priorities will trigger the sending of messages about the changes to other unit commanders and to IBA as well. Figure 5. Company-level Tank Repair Priorities. Logistical Agent Environment The right-hand side of Figure 1 depicts the architecture of Logistics Agent Environment (LAE). Logistics problems such as supply chain automation lend themselves naturally to agent-based solutions. Often in logistics problems the coordination and execution of several tasks is required. This coordination and execution of tasks can effectively be accomplished through the collaboration of multiple agents where each agent executes a small set of focused actions. The decisions to execute certain actions, such as ordering a part or scheduling a repair, in some situations need to be made in near-real-time. The challenge is that making near-real-time decision often also requires the ability to efficiently access and reason about data stored in distributed heterogeneous data sources. Utilizing UM’s IMPACT   program provided the agent framework that allowed the Logistics Agent Environment (LAE) agents to operate in a heterogeneous distributed environment. The logistics of a tank repair is complicated by two main constraints, limited quantities of repair parts and limited repair personnel resources. For a tank to be repaired, sufficient repair personnel must be available on-site at the tank’s direct support area. If the repair personnel available on-site is insufficient to repair all tanks ready to be repaired, then highest priority tanks must be serviced first. Also for a tank to be repaired, the parts necessary to conduct the repair must be available on-site. In a situation in which the parts required for a repair are not available on-site, then the parts must be transported from another direct support area or a warehouse that is in theater. If a necessary part for a repair can be obtained from more than one source, then the part should be shipped from the source that will minimize the time necessary to transport the part. In the tank repair application, agents are given the responsibility of scheduling tanks for repairs as well as allocating repair personnel and parts. Agents also generate presentations containing near real-time logistics information. Working together to accomplish these tasks is a coordinator agent, a transport agent, several inventory agents, several repair crew scheduling agents, and several presentation agents. An inventory agent is associated with each direct support area and warehouse. A repair-crew scheduling agent is associated with each direct support area. The following diagram illustrates messaging in the LAE. The coordinator agent is the most critical agent of the LAE. The coordinator agent is responsible for communication with the TAE, as well communicating and coordinating activities of the other agents in the LAE. When the TAE initially requests a tank to be repaired the request includes information about the tank such as its priority, the fault of the tank, and the time by which the repair should be finished. Upon receiving the request for a tank repair, the coordinator agent queries the   Appear in Proc. of the Fifth 2001 World Multi-Conference on Systemics, Cybernetics, and Informatics, Orlando, FL. inventory agent associated with the direct support area at which the tank is being repaired to determine if the parts necessary for the repair are already available on-site. The inventory agent based on data tables it maintains determines whether or not the part can be supplied, and if the part can be supplied whether the part must be reallocated from a lower priority tank. In the event that the repair parts are not available on-site or the parts must be reallocated from a lower priority tank, then the coordinator agent will query all other inventory agents as well as the transport agent. The inventory agents respond to the coordinator agent’s query with information as to whether the necessary quantity of the part is available for shipment. The transport agent determines the amount of time necessary to transport the part to the tank’s direct support area from each of the potential supplier locations. If the parts for the repair do not exist anywhere in theater, then a failure message is sent back to the TAE. If the parts can be made available for the repair, then the coordinator agent will send a message to the repair crew scheduling agent associated with the direct support area at which the tank is currently located. The coordinator agent provides the repair crew scheduling agent with the tank’s priority, the tank’s fault, as well as the time at which all parts necessary for the repair will be available on-site. The repair crew agent tentatively schedules the repair for a time at which both repair personnel and repair parts will be available. In situations where the repair personnel cannot immediately service all tanks, a higher priority tank will be scheduled before any waiting tanks of lower priority. The repair crew agent determines an estimate of the time the repair will take based on the tank’s current fault. The repair crew agent sends the estimated time at which the tank repair will be finished back to the coordinator agent, which passes the message along to the TAE. An agent in the TAE then replies with a message either canceling or confirming the tank repair. If the decision is to confirm the tank repair, then an order is made to transport any parts necessary for the repair. A set of presentation agents also work to dynamically create Microsoft PowerPoint presentations with current logistics information. Separate agents are responsible for generating a presentation about the tank repair schedule for each support area. Another agent generates a presentation containing information about current inventory levels. AGENT COLLABORATION One of the key challenges to this program was the ability for disparate agent architectures to Figure 6. TAMU / UMD Collaboration Gateway IOS Interface (Java RMI Server)   Message Queue   Roost QMonitor Thread   In Box   Out Box   YP Client   LAE Agent A   LAE Agent B   LAE Agent C   IOS Interface (Java RMI Server)   Message Queue   Bridge QMonitor Thread   In Box   Out Box   YP Client   Bridge Interface (Java RMI Server)   Callback   App Interface (Java RMI Server)   TAMU Agent App   Bridge Client  
Related Documents
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!