<?xml version="1.0" standalone="yes"?>
<Paper uid="W01-1609">
  <Title>Automated Tutoring Dialogues for Training in Shipboard Damage Control</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2 Previous Work
</SectionTitle>
    <Paragraph position="0"> Eliciting self-explanation from a student has been shown to be a highly effective tutoring method (Chi et al., 1994). For this reason, a number of automated tutoring systems currently useNLP techniques to engage students in reflective dialogues. Three notable examples are the medical Circsim tutor (Zhou et al., 1999); the Basic Electricity and Electronics (BE&amp;E) tutor (Ros'e et al., 1999); and  thecomputerliteracyAutoTutor(Wiemer-Hastings et al., 1999). Our system shares several features with these three tutoring systems: A knowledge base Our system encodes all domain knowledge relevant to supporting intelligent tutoring feedback into a structure called an Expert Session Summary (Section 4). These expert summaries encode causal relationships between events on the ship as well as the proper and improper responses to shipboard crises.</Paragraph>
    <Paragraph position="1"> Tutoring strategies In our system, as in those above, the flow of dialogue is controlled by (essentially) a finite-state transition network (Fig. 1).</Paragraph>
    <Paragraph position="2"> An interpretation component In our system, thestudent'sspeechisrecognizedand parsed into logical forms (Section 3). A dialogue manager inspects the current dialogue information state to determine how best to incorporate each new utterance into the dialogue (Lemon et al., 2001).</Paragraph>
    <Paragraph position="3">  However, an important difference is that the three systems above are entirely textbased, whereas ours is a spoken dialogue system. Ourspeech interface offers greater naturalnessthankeyboard-basedinput. Inthisrespect,oursystemissimilartocove(Roberts, null 2000), a training simulator for conning Navy ships that uses speech to interact with the student. Butwhereascoveusesshortconversational exchanges to coach the student during the simulation, our system engages in extended tutorial dialogues after the simulation has ended. Besides being more natural, spoken language systemsare also better suitedto multimodal interactions (viz., one can point and click while talking but not while typing).</Paragraph>
    <Paragraph position="4"> An additional significant difference between our system and a number of other automated tutoring systems is our use of 'deep' processing techniques. While other systems utilize 'shallow'statistical approacheslikeLatentSemanticAnalysis(e.g. AutoTutor), oursystem utilizes Gemini, a symbolic grammar. This approach enables us to provide precise and reliable meaning representations.</Paragraph>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 Implementation
</SectionTitle>
    <Paragraph position="0"> To facilitate the implementation of multimodal, mixed-initiative tutoring interactions, we decided to implement our system within the Open Agent Architecture (OAA) (Martin et al., 1999). OAA is a framework for coordinating multiple asynchronous communicating processes. The core of OAA is a 'facilitator' which manages message passing between a number of software agents that specialize in certain tasks (e.g., speech recognition or database queries). Our system uses OAA to coordinate the following five agents:  1. The Gemini NLP system (Dowding et al., 1993). Gemini uses a single unification grammar both for parsing strings of words into logical forms (LFs) and for generating sentences from LF inputs.</Paragraph>
    <Paragraph position="1"> 2. A Nuance speech recognition server, which converts spoken utterances to strings of words. The Nuance server relies on a language model, which is compiled directly from the Gemini grammar, ensuring that every recognized utterance is assigned an LF.</Paragraph>
    <Paragraph position="2"> 3. The Festival text-to-speech system, which 'speaks' word strings generated by Gemini.</Paragraph>
    <Paragraph position="3"> 4. A Dialogue Manager which coordinates inputsfromtheuser, interprets the user's dialogue moves, updates the dialogue context, and delivers speech and graphical outputs to the user.</Paragraph>
    <Paragraph position="4"> 5. A Critique Planner, described below  in Section 4.</Paragraph>
    <Paragraph position="5"> Agents 1-3 are reusable, 'off-the-shelf' dialogue system components (apart from the Gemini grammar, which mustbe modifiedfor each application). We implemented agents 4 and 5 in Java specifically for this application. Variants of this OAA/Gemini/Nuance architecture have been deployed successfully in other dialogue systems, notably SRI's CommandTalk (Stent et al., 1999) and an un- null manned helicopter interface developed in our laboratory (Lemon et al., 2001).</Paragraph>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
4 Planning the dialogue
</SectionTitle>
    <Paragraph position="0"> Each student session with DC-Train producesa session transcript, i.e.atime-stamped record of every event (both computer- and student-initiated) that occurred during the simulation. These transcripts serve as the input to our post-session Critique Planner (CP).</Paragraph>
    <Paragraph position="1"> The CP plans a post-session tutorial dialogue in two steps. In the first step, an Expert Session Summary (ESS) is created from the session transcript. The ESS is a tree whose parent nodes represent damage events and whose leaves represent actions taken in response to those damage events.</Paragraph>
    <Paragraph position="2"> Each student-initiated action in the ESS is evaluatedastoitstimelinessandconformance to damage control doctrine. Actions that the studentshouldhavetakenbutdidnotarealso inserted into the ESS and flagged as such.</Paragraph>
    <Paragraph position="3"> Each action node in the ESS therefore falls into one of three classes: (i) correct actions; (ii) errors of commission (e.g., the student sets fire containment boundaries incorrectly); and (iii) errors of omission (e.g., the student failstosecurepermissionfromthecaptain before flooding certain compartments).</Paragraph>
    <Paragraph position="4"> Our current tutoring system covers scenarios generated by DC-Train 2.5, which covers fire scenarios only. Future versions will use scenarios generated by DC-Train 4.0, which coversdamagecontrolscenariosinvolvingfire, smoke, flooding, pipe and hull ruptures, and equipment deactivation. Our current tutoring system is based on an ESS graph that is generated by an expert model that consists of an ad-hoc set of firefighting rules. Future versions will be based on an ESS graph that is generated by an successor to the Minerva-DCA expert model (Bulitko and Wilkins, 1999), an extended Petri Net envisionment-based reasoning system. The new expert model is designed to produce an ESS graph  duringthecourseofproblemsolvingthatcontains nodes for all successful and unsuccessful plan and goal achievement events, along with an explanation structure foreach graph node.</Paragraph>
    <Paragraph position="5"> The second step in planning the post-session tutorial dialogue is to produce a dialogue move graph (Fig. 1). This is a directedgraphthatencodesallpossibleconfigu- null rations of dialogue structure and content that can be handled by the system.</Paragraph>
    <Paragraph position="6"> Generating an appropriate dialogue move graph from an ESS requires pedagogical knowledge, and in particular a tutoring strategy. The tutoring strategy we adopted is based on our analysis of videotapes of fifteen actual DC-Train post-session critiques conducted by instructors at the Navy's Surface Warfare Officer's School in Newport, RI. The strategy we observed in these critiques, and implemented in our system, can be outlined as follows:  1. Summarize the results of the simulation (e.g., the final condition of the ship).</Paragraph>
    <Paragraph position="7"> 2. For each majordamage event inthe ESS: (a) Ask the student to review his actions, correcting his recollections as necessary.</Paragraph>
    <Paragraph position="8"> (b) Evaluate thecorrectness of each student action.</Paragraph>
    <Paragraph position="9"> (c) If the student committed errors,  ask him how these could have been avoided, and evaluate the correctness of his responses.</Paragraph>
    <Paragraph position="10"> 3. Finally, review each type of error that arose in step (2c).</Paragraph>
    <Paragraph position="11"> A screen shot of the tutoring system in action is shown in Fig. 2. As soon as a DC-Train simulation ends, the dialogue system starts up and the dialogue manager begins traversing the dialogue move graph. As the dialogue unfolds, a graphical representation of the ESS is revealed to the student in piecemeal fashion as depicted in the top right frame of Fig. 2.</Paragraph>
  </Section>
class="xml-element"></Paper>