<?xml version="1.0" standalone="yes"?>
<Paper uid="W03-0706">
  <Title>The Pragmatics of Taking a Spoken Language System Out of the Laboratory</Title>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 Domains
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.1 LCS Marine
</SectionTitle>
      <Paragraph position="0"> One of the first LCS systems to be tested out in the field was our Marine Logistics spoken dialogue system.</Paragraph>
      <Paragraph position="1"> This application sought to connect the Marine in the field to the Small Unit Logistics (SUL) database, which maintains current information about supply requisitions.</Paragraph>
      <Paragraph position="2"> Warfighters wanted to be able to place requests as well as check on the status of existing requests without the need of additional hardware or communicating with a third party. It was also highly desirable to use existing communications procedures, so that the training time to use the system was minimized. The system needed to be speaker-independent and mixed initiative enabling the warfighters to develop a sense of trust in the technology.</Paragraph>
      <Paragraph position="3"> Marines using the system were able to perform several tasks. They could create new requests for supplies, with the system prompting them for information needed to fill in a request form. They could also modify and delete previously placed requests and could check on the status of requests in one of two ways. They could directly ask about the current status, or they could delegate an agent to monitor the status of a particular request. It was an easy addition to the system to add a constraint that the agent return after a specified time period if no activity occurs on the request, which is also valuable information for the Marine. These delegated agents travel across a lowbandwidth SINCGARS radio network from the Marine to the database and access that database to place, alter, and monitor supply requisitions.</Paragraph>
      <Paragraph position="4"> The challenges in deploying this system to the field were twofold - building trust in the system so that it would become part of normal operations and in dealing with the unique environmental factors. The former presented the conflicting goals of brevity versus confirming user inputs. Marines want to restrict their time on the radio net as much as possible. At the same time they want to ensure that what they requested is what they were going to receive. Much time went into defining and refining system responses that met both needs as best possible.</Paragraph>
      <Paragraph position="5"> This involved several sessions with a numerous Marines evaluating possible dialogue responses. We also spent much time ensuring that LCS Marine could handle both proper and malformed radio protocols. Broad coverage of potential expressions, especially those when under stress, such as recognition of the liberal use of curse words, led to greater user ability to successfully interact through the system.</Paragraph>
      <Paragraph position="6"> The second set of challenges, unique environmental factors, included access while on the move, battlefield noise, and coping with adverse conditions such as sand storms. Accessing LCS Marine while on the move meant using a SINCGARS radio as the input device. Attempts to use the system by directly collecting speech from a SINCGARS radio were dropped due to the technological challenges presented by the distortion introduced by the radio on the signal. Instead, we installed the majority of the system on laptops and put these into the HMMWV.</Paragraph>
      <Paragraph position="7"> We sent mobile agents over the SINCGARS data link back to the data sources. This meant securing hardware in a HMMWV and powering it off of the vehicle's battery as illustrated in Figure 1. (Only one laptop was damaged during testing.) The mobile agents were able to easily traverse a retransmission link and reach the remote data source.</Paragraph>
      <Paragraph position="8"> Dealing with hugely varying background noise sources was less of a problem than originally predicted. Fortunately, most of the time that one of these loud events would occur, users would simply stop talking. Their hearing was impaired and so they would wait for the noise to abate and then continue the dialogue. On the other hand, we did encounter several users who, because of the Lombard effect, insisted upon always yelling at the system. While we did not measure decibel levels, there were a few times when the system was not able to understand the user because of background noise.</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.2 Shipboard Information
</SectionTitle>
      <Paragraph position="0"> An LCS system has also been developed to monitor shipboard system information aboard the Sea Shadow (IX 529), a Naval test platform for stealth, automation, and control technologies. From anywhere on the ship, personnel use the on-board intercom to contact this system, SUSIE (Shipboard Ubiquitous Speech Interface Environment), to ask about the status of equipment that is located throughout the ship. Crew members do not have to be anywhere near the equipment being monitored in order to receive data. Figure 2 illustrates a sailor using SUSIE through the ship's intercom.</Paragraph>
      <Paragraph position="1"> Personnel can ask about pressures, temperatures, and voltages of various pieces of equipment or can delegate  ship's intercom monitoring those measurements (sensor readings) to the system. A user can request notification of an abnormal reading by a sensor. This causes the LCS system to delegate a persistent agent to monitor the sensor and to report the requested data. Should an abnormal reading occur, the user is contacted by the system, again using the intercom. null This domain presented several challenges and opportunities. Through numerous discussions with users and presentation of possible dialogues, we learned that the users would benefit from a system ability to remember, between sessions, the most recent activity of each user. This would permit a user to simply log in and request: &amp;quot;What about now?&amp;quot;. SUSIE would determine what had been this user's most recent monitoring activity, would then seek out the current status, and then report it. While this seems quite simple, there is significant behind-thescenes work to store context and make the interaction appear seamless.</Paragraph>
      <Paragraph position="2"> It was necessary to use the organic intercom system installed in the Sea Shadow for communication with crew members. Collecting speech data through the intercom system to pass to SUSIE required linking two DSPs (and adjusting them) to the hardware for the SLS. Once connected in, the next significant challenge was that of the varying noise levels. Background noise varied from one room to the next and even within a single space. We were not able to use a push-to-talk or hold-to-talk paradigm because of the inconvenience to the crew members; they leave the intercom open for the duration of the conversation. Fortunately, the recognizer (built on MIT's SUM-MIT) is able to handle a great deal of a noise and still hypothesize accurately. To improve the system accuracy, we will incorporate automatic retraining of the recognizer on noise each time that a new session begins.</Paragraph>
    </Section>
    <Section position="3" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.3 Battlefield Casualty Reporting System
</SectionTitle>
      <Paragraph position="0"> We are currently developing a new LCS system known as the Battlefield Casualty Reporting System or BCRS.</Paragraph>
      <Paragraph position="1"> The goal of this system is to assist military personnel in reporting battlefield casualties directly into a main database. This involves intelligent dialogue to reduce ambiguity, resolve constraints, and refine searches on individual names and the circumstances surrounding the casualty. Prior knowledge of every individual's name will not be possible. The deployment of this system will be again present many challenges such as noise effects on a battlefield, effects of stress on the voice, and the ability to integrate into existing military hardware.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
4 Future Work
</SectionTitle>
    <Paragraph position="0"> The areas of research needed to address needs for more dynamic and robust systems include better, more robust or partial parsing mechanisms. In addition, systems must be able to cope with multi-sentence inputs, including the system's ability to insert back channel activity. Ease of domain expansion is important as systems evolve. Varying environmental factors mean that the systems require additional noise adaptation or mitigation techniques, in addition, the ability to switch modes of communication if one is not appropriate at a given time.</Paragraph>
  </Section>
class="xml-element"></Paper>