An interactive simulator for maintenance Training

Johns hopkins ApL TechnicAL DigesT, VoLume 27, number 1 (2006) 75

inTerAcTiVe simuLATor For mAinTenAnce TrAining

O

An interactive simulator for maintenance Training

Donna L. Koczaja

ften one of the first casualties of today’s numerous defense programs competing for funding is training. To address the rising costs of and diminishing resources for train-ing, the navy seeks innovative methods to train sailors efficiently and effectively. one such method is to employ high-fidelity, realistic, and user-friendly pc-based training sim-ulators. The hovering and missile compensation maintenance simulator was created for sailors in the Trident ssbn community to learn how to conduct maintenance on two shipboard ballasting systems. The simulator combines high-resolution graphics with physics-based models of the mechanics and electronics involved in these systems. stu-dents use this program to conduct actual maintenance procedures on simulated equip-ment. An instructor-led multi-user capability is also available, which includes introducing failures into the systems, often requiring students to take corrective action. This article provides an overview of the technology used to create this maintenance simulator and discusses the challenges in creating a realistic simulation that will motivate the sailor to use such a tool.

INTRODUCTIONThe Trident ssbn community identified a need to

provide a training mechanism with which sailors could learn to conduct maintenance on two shipboard bal-lasting systems—hovering and missile compensation (hov-comp). The hovering system comprises two bal-last tanks in which water continually moves rapidly in and out to maintain a stable platform at low speeds for ballistic missile launch. The missile compensation system is used each time a missile is launched; a pre-scribed amount of water is flooded into the forward and aft compensation tanks to compensate for the resultant weight loss at launch. both systems include numerous sensors, transducers, and controls located throughout

the ship, making them especially suitable for computer-based training.

periodic calibration and signal continuity checking of these components is vital for their continued proper operation. Thus, a set of standard maintenance pro-cedures (smps) is routinely conducted by ship’s force during each maintenance period. Junior sailors are given only limited instruction on how the systems work and how to properly conduct the smps. Land-based training resources are limited because of the widespread nature of these two onboard ballasting systems, and time for on-the-job training during the maintenance period in which smps are conducted is often inadequate.

76 Johns hopkins ApL TechnicAL DigesT, VoLume 27, number 1 (2006)

D. L. kocZAJA

As a result of the past success of ApL’s Trident Launcher simulator,1 the navy looked to the Laboratory to develop a pc-based training simu-lator in which the sailor could per-form an actual smp on virtual hov-comp equipment.

MAINTENANCE SIMULATOR CONCEPT

The intended users of the hov-ering and missile compensation maintenance simulator are primar-ily junior sailors, some of whom are completing basic training and have not yet been on a submarine. To

will react to stimuli just as the real hov-comp equip-ment would. As entire systems are modeled (to the level required to complete the selected smps), an action per-formed—correctly or incorrectly—on one component will affect the state of a related component in addition to its own state. This development methodology allows the student to experience the result of making a mistake without causing any damage to the real system or any personal injury.

in addition to hov-comp components, it was also necessary to model several test kit components, such as a multimeter and a pressure calibrator. The student may connect these tools to various test points or ports and use them to complete the smp. Figure 3 illustrates a rep-resentative test setup.

The hov-comp systems may be set up initially in an “ideal” configuration, or the instructor may set various components to exhibit out-of-tolerance values (e.g., voltages, times) that the student may have to mitigate throughout the course of smp conduct. Figure 4 illus-trates the Fault insertion Window. The instructor has a list of faults available for a selected smp; for faults that involve tolerance values, the instructor has the option to select other out-of-tolerance values.

An important exception to fault insertion is that test equipment may not be faulted; it was therefore deter-mined that advanced test equipment training was out-side the goals of this product.

because some smps require multiple sailors in dif-ferent locations around the ssbn, a multi-user mode is available. Any number of networked computers may participate in a joint training session, though the maximum number of sailors needed to complete any of the available smps is four. if a multi-user mode is selected, a designated instructor logs into the program first, and then the students log in and join the session. The instructor creates a new or loads an existing sce-nario, which consists of the smp to be conducted and relevant faults (if any). The students then proceed to Figure 1. Navigator Window.

Figure 2. AMR-2 scrollable panorama.

this end, the ApL simulator was designed to teach the sailors about

1. The hov-comp system equipment2. The location of this equipment aboard the ssbn3. equipment operation in the context of maintenance,

potentially in a team environment

The first two goals are achieved by generating high-resolution graphics that the student can navigate. Figure 1 shows the simulator’s navigator Window, from which the student may proceed to 1 of 17 areas where hov-comp–related equipment is located. clicking on any of these icons produces a photograph of the corresponding space on the ssbn, and the student can either interact with the equipment directly on the graphic or navigate into more detailed areas.

For maximum effectiveness in achieving the second goal, 6 of the 17 hot spots (designated by funnel icons) on the navigator Window produce scrollable panora-mas of ship spaces. Figure 2 shows a snapshot of the panorama visualizing the Auxiliary machinery room 2 (Amr-2) space, where much of the key hovering equip-ment resides.

Teaching a sailor to operate hovering and missile compensation equipment in the context of mainte-nance is the primary goal of this simulator. The graphi-cally represented components are also modeled math-ematically and logically such that virtual equipment



conduct the smp using actual promulgated procedures, and any action performed by one student propagates to all other students’ pcs (all are affecting the state of a single system). The instructor may monitor the students’ progress by referring to an event log that is dynamically created, in addition to monitoring graphic equipment panels. The instructor may also control fault insertion in real time—either adding or removing faults depend-ing on the sailors’ progress.

SIMULATOR ARCHITECTURE

Three primary programs com-prise the hov-comp maintenance simulator: the simulation, the graphical user interface (gui), and the database manager (Dbman). A simple spawn service program is also included to start (spawn) the simulation and Dbman programs when the gui is launched by the user (via desktop icon). Figure 5 shows the system architecture.

The simulation maintains con-trol of the overall program. Within it are the mathematical models of all equipment. object-oriented programming techniques are used in creating component models, and in cases where the hov-comp sys-tems have redundant equipment, multiple instantiations of a model (class) are created at runtime. com-ponents are then connected via an input/output scheme to build the system.

The simulation is time driven; the state of all components is updated at 10 hz. updates to the state may come from logic internal to the component (e.g., a water line drain-ing) or from a user interacting with a component via the gui program (e.g., pressing a button). Though the simulation receives inputs from the gui for state updates, the gui pro-gram does not actually contain any component logic and is therefore essentially “dumb.” That is, a user can push a button or turn a dial, and the gui will send an input to the simulation indicating that a button or dial on a form has been moved. The simulation will make the appropriate state change within the corresponding models and then

Figure 3. Hov-comp simulator screen-capture of a pressure calibrator connected to a differential pressure transducer.

Figure 4. Fault Insertion Window.

send an output to the gui indicating that the state has changed. Thus the simulation maintains control of the system, and the gui reflects the state of the system at all times.

The primary motivation in selecting this architec-ture was the ability to create effective multi-user train-ing. in a multi-user scenario, a single simulation runs on the designated instructor’s machine. (The instructor must establish a multi-user training session before any


D. L. kocZAJA

other users log in.) once the training environment is established, all students start their own gui programs, which connect to the single simulation. in this manner the students can experience collaborative training on a single system in which the actions of one user are reflected to all users.

The simulation and gui programs also communicate

once the water in the line is drained, to insert a known test pressure into the transducer.

The transducer performs a simple subtraction of the two pressure inputs to obtain a Dp that represents the real-world pressure differential across the DcT sea valve. Then, from within the transducer model, the Dp is converted into a voltage via a (nearly) linear relation.

Figure 5. Simulation architecture.

Figure 6. Differential pressure transducer overview and related equipment connectivity.

Simulation Program ExampleThe simulation contains approx-

imately 45 different equipment models. Figure 6 is a specification diagram illustrating how several specific components interrelate. here, four separate object models are used: isolation valve, valve with test connection, depth control tank (DcT) differential pressure (Dp) transducer, and hovering position control unit (pcu). The Dp trans-ducer receives inputs, in the form of a water pressure head, from within the DcT and from the sea directly. simple fluid models representing tank levels and seawater above the keel generate pressure signals sent to the valves in series before being sent to the transducer. in this manner the valves, based on their position, regulate the water pressure sensed by the Dp transducer. Also, an automatic pressure calibrator (Apc) can be connected to the Dp transducer via the test connection,

with the Dbman, which records the system state and scenario informa-tion (both from the simulation) and event log entries (from the gui). The Dbman is a generic framework that was developed independently at ApL for use by any training sim-ulator that needs to perform typical database management functions. it interfaces directly with the micro-soft sQL server Desktop engine and was developed to insulate spe-cific applications from inevitable changes in coTs support soft-ware. since the Dbman was not developed specifically as part of the hov-comp maintenance simula-tor, further details are not presented here.2

Additional details about the simulation and gui programs are illustrated by example in the fol-lowing sections.

Win

dow

upd

ates

Use

r cl

icks

and

text

GUI program

Spawn serviceprogram

Models

Simulationprogram

Microsoftdesktop engine

Database

Databasemanager

QuickTime

Markerstateand

events

Markerstate

packets(both

directions)

(Loa

d)

(Sav

e)

(Ret

rieve

)

(Sto

re)

User-generatedcommands

Model states,sound information

Logged events

(both directions

for instructor only)

DCT DP transducer

Isolationvalve

Isolationvalve

HOV PCU

Valve with testconnection

Valve with testconnection



ideally, the Dp transducer would behave completely lin-early, but in practice sailors have difficulty calibrating these transducers because of real-world nonlinearities. Therefore, to more realistically model the transducers (and effectively make them more difficult to calibrate), the following equation was used to introduce a nonlin-ear effect into the conversion.

VDpmax max

nL(spAn Zero)

( ).

spAn Zero

= −−

+P P

P FD 0 8

×× +

×−

( )

sin

Zero spAn

max maxspAn Zero

To To

PP P

l l

D

+ Zero ,

where

VDp = output voltage from the transducer, spAn = spAni + 0.4(AdjspAn + EZsAdjZero), Zero = Zeroi + 0.4(AdjZero + EsZAdjspAn), Adj = potentiometer adjustment (user input), E = effect on the Zero value of adjusting the spAn potentiometer and vice versa, DP = (tank pressure 2 sea pressure), FnL = nonlinearity factor, To = required tolerance on Zero or spAn voltage readings during smp conduct, and Pmax = pressure when voltage is at zero VDc or at the maximum span voltage.

The instructor may choose the severity of the non-linearity factor by setting it between 0 and 100 when selecting equipment faults.

The Dp transducer voltage output may be attenuated by adjusting the Zero and/or spAn potentiometers (Fig. 6). From the spAn and Zero equations above, it can be seen that adjusting the Zero potentiometer affects the spAn reading (via the EZs term) and vice versa. This effect, like the nonlinearity, is a real-world phenomenon that challenges sailors attempting to calibrate the transducers.

once the voltage is calculated, it is sent to the hov-ering pcu model, which further processes it via logic models of pcu circuits and sends it to other compo-nents requiring it.

This is only a small sampling of the functionality modeled in the simulation. other hov-comp model types include circuit cards, tank-level transmitters, receiver/indicators, circuit breakers, switches, control panels, valves (water and hydraulic), signal conditioners,

fuse panels, and terminal boards, in addition to ancillary test equipment such as multimeters, pressure calibrators, decade resistance boxes, and jumpers.

GUI Program ExampleThe previous section described the mathematical algo-

rithms and logic of the DcT Dp transducers and associ-ated hardware. These algorithms are vital for producing an accurate, realistic representation of the real system as long as they are coupled with a believable, user-friendly graphics front-end. The hov-comp maintenance sim-ulator gui program comprises more than 90 separate forms accessible to the user. To develop each form, visu-ally identifiable equipment states were specified. These specifications were then used to generate the graphics as well as create code for manipulating them. Although the graphics were ultimately driven by the simulation program, the original stimulus may come from the user through the gui program or directly from the simula-tion logic. An example of this process follows.

The Dp transducer described in the previous section is accessible from the panorama shown in Fig. 2. The user may click (and hold) anywhere on the panorama and “drag” the mouse pointer around to view the entire area. The “+” and “2” buttons on the bottom left of the window allow zooming in and out. because some of the equipment may be difficult to locate, clicking on the arrow with the “?” icon outlines all of the hot spots available on the panorama that will navigate the user to a particular piece of equipment.

The base form for the Dp transducer, shown in Fig. 7, is what the student sees when first opening this form. The user can perform several actions here, all of which will affect the graphic state. The numerous states are illustrated in Fig. 8. on the left are the transducer isola-tion valves with a test connection. The student must be able to shut the valve (isolate it from the system piping) as well as remove the test caps and connect a hose to the test connection. This simulation is achieved by overlaying the proper graphic or text onto the base graphic when a user action is recorded. inset A shows the graphic depicting the test cap. To remove a cap, the student clicks on it, and after a verification pop-up window appears, the graphic changes to that shown in inset b. When a cap is removed an icon appears in the “removed equipment” repository (inset D). clicking on this icon restores the test cap. note that the state of the valve itself (vice the test cap) is indicated only when the mouse pointer is hovering on the valve (not shown). A text hint of open or shuT will appear over the valve because the valve looks the same in both cases. clicking on the valve wingnut will change its state.

once a test cap is removed, the student may con-nect a test hose to it. First, the user must acquire the test hose from the pressure calibrator form (depicted in Fig. 3). once the user is “holding” a test connector


D. L. kocZAJA

(signified by the icon shown in inset e), he or she clicks on the desired connection and the graphic in inset c is displayed. if the test cap is on when the student does this, a warn-ing is given that it must be removed before connecting the hose.

A user may also remove the cover of the transducer (compare Fig. 8 to Fig. 7) to make adjustments to the Zero and spAn potentiometers within. clicking on any of the arrow buttons will increase or decrease the Zero/spAn as calculated in the previous section. Any student who connects a virtual multimeter to the proper test point on the pcu form will see changes in the output voltage on the multimeter.

Finally, in keeping with the philosophy of maintaining strict procedural compliance—an impor-tant facet of sailor training—the student may affix a calibration label onto the transducer cover by right-clicking anywhere on the cover and Figure 7. Differential pressure transducer, base graphic.

Figure 8. Differential pressure transducer states.

A: Test cap on

F: User “holding”nothing

E: User “holding”test connector

D: Removedequipment icons

B: Test cap removed

C: Test hose connected

A: Test cap on

B: Test cap removed

C: Test hose connected

Replace transducer

Cover

Cap

Removed equipment



then enter relevant information. upon completion, the label appears on the transducer (Fig. 9).

CHALLENGESThe overarching challenge in this effort was to create

a resource that sailors would actually want to use. in practical terms this means that the hov-comp mainte-nance simulator had to be

• Visually and functionally accurate• easy to use with little preparation• interesting and engaging

experience showed that if any of these criteria were not achieved, it was difficult to entice the sailors to use the product. The most important resource available to ensure that the product met all of these qualities was the advice of senior enlisted fleet experts. These navy chief petty officers were consulted throughout the develop-ment, implementation, and testing process. examples of how fleet representatives provided invaluable input are described throughout the following paragraphs.

To achieve visual accuracy, source material for the graphics was obtained by visiting two ssbns and the Trident Training Facility laboratories in submarine base kings bay, georgia. more than 700 photographs were collected based on an extensive list of required equipment generated by reviewing the smps. The pho-tographs were sorted, cleaned up, and edited. in many cases the graphic artist had to alter the state of a compo-nent (e.g., a valve handle from open to shuT) using Adobe photoshop because it was often not permissible to alter a system lineup onboard the operational ssbn.

Depicting the proper component states was one area where obtaining fleet expert input was helpful. When the state of the onboard system was fixed or equipment in the training laboratory was insufficient, the experts’ system knowledge and experience were necessary to

Figure 9. Calibration label.

confirm what the various components looked like in various states. consultants were always available via telephone to verify information (e.g., how many pins are on a particular connector, what color does an indica-tor emit when energized) when available documentation was not clear.

For functional accuracy, each component was researched to determine how it worked internally, how it related to other components, and how it responded to internal and external stimuli. Although ApL has considerable technical knowledge of hov-comp systems, emulating them with sufficient detail for this simulator required further research on individual components. in some cases technical manuals were available, and these were important resources for creating mathematical models. For those components that had incomplete or unavailable documentation, fleet experts were able to fill in the gaps. here again, fleet input—during visits to the submarine bases, through hands-on product reviews, and through telephone consultations—was invaluable in creating an accurate, detailed simulation.

With regard to creating a user-friendly environment, several design decisions in graphics presentation and scenario control were implemented. perhaps the big-gest challenge in graphics presentation was embedding the scrollable panoramas, described in the maintenance simulator concept section, directly into the simulation executable. The panoramas require Apple’s QuickTime Vr multimedia software to display and manipulate. it was undesirable to have QuickTime run as a separate executable, as doing so would require the user to switch back and forth between programs, which could become cumbersome. The solution was discovering and using a third-party ActiveX control, skyLight pro,3 which allowed seamless integration of QuickTime files into the executable.

Also of concern in graphics presentation was the logical flow of gaining access to various components.

The goal was to maintain enough visualization of the environment in which components reside while not having to navigate through count-less forms to get to an individual piece of equipment. Fleet personnel provided excellent insight into pro-gram navigation, as well as how to interact with (i.e., do work on) indi-vidual components. With their help it was possible to streamline main-tenance actions such as connecting test equipment to hov-comp com-ponents and removing and rein-stalling equipment.

scenario control—the process of how a training session is started, executed, and saved—also required


D. L. kocZAJA

extensive consideration. having a high-fidelity simu-lation of the hardware is of little use if the instructor cannot easily create a training scenario, control it in real time, and save parameters for subsequent re-creation. Fleet instructors were particularly interested in this aspect of the program and were consulted during the requirements generation phase of the project to capture desirable features. Two items in particular that resulted from these discussions were the ability to re-create a training scenario and the ability to add and remove faults from the training session in real time. To achieve the former, the Dbman program was modified so that the scenario (which includes system initial conditions and any faults injected into the system) could be stored and retrieved at a later time. For the second item, logic was added into component models to create the fault condition when requested (and remove it as well). For some components this translated into setting a boolean fault variable in the component model to “True”, which resulted in the simulation setting various component variables to a faulted condition, e.g., an indicator does not light, power is not available. most of the compo-nent faults, however, required inserting an out-of-toler-ance value onto some numeric quantity (e.g., a voltage, resistance, or time) that the component outputs. This can get complicated because the complexity of some of the models is such that many of these outputs depend on other internal variables. Therefore, to maintain the integrity of the logic in the component, producing the desired effect required adding logic to alter the proper independent variable in the component model to result in the out-of-tolerance value selected by the instructor.

CONCLUSIONpc-based simulation trainers offer several advantages

over other means of training, one of which is that they are cost-effective. generally, a simulation costs less to produce than a complete hardware trainer. in addition, once the program is completed, there is little mainte-nance involved. hardware must be purchased, installed, and maintained throughout its life cycle.

Another advantage of pc-based simulators is their portability. Though the real systems may be very large, system training via software simulation may be con-ducted anywhere a pc or laptop with the minimum requirements is available. This is especially helpful to the submariner who might wish to conduct some refresher training while on patrol at sea.

A key benefit of using pc-based simulators for train-ing, especially in a military application, is that the simu-lations provide a completely safe method of training. in this context safety refers to both the sailor as well as the equipment. While on-the-job training is a beneficial, effective method of training, it risks damage to tactical equipment, which may have operational implications.

practicing on a high-fidelity simulator allows sailors to become familiar with equipment and procedures with-out risking injury to themselves or the hardware.

While the above considerations helped drive the con-cept development of the hovering and missile compen-sation maintenance simulator, perhaps the most impor-tant advantage of pc-based trainers exploited in this simulator was the potential to be engaging enough for the student to want to use it. This philosophy ultimately drove the selection and development of the technologies described in this article, summarized as follows:

• realistic, detailed, and interactive graphics: This was achieved by creating scrollable panoramas of ship spaces and incorporating the skyLight pro hot-spot utility, as well as generating a substantial library of photographs from which to create interactive equip-ment forms.

• Accurate, sufficiently comprehensive logic models: The system experts who developed the algorithms in the models combined their knowledge with techni-cal manuals when available and consulted with fleet system experts when documentation was insufficient to achieve the level of detail desired.

• networked, multi-user capabilities: The hov-comp maintenance simulator team leveraged off other software developers at the Laboratory who created generic frameworks that provided capability for basic simulation functionality such as networking and database management.

• intuitive and user-friendly program flow: Through-out simulator development, fleet hov-comp experts were consulted not only for their system expertise, but also for their insight as sailors into the most effec-tive methods of navigating around equipment spaces, interaction with the equipment, and the most useful scenario control features.

ultimately, these features of the hovering and mis-sile compensation maintenance simulator were used to maximize training value to sailors by giving them an easily accessible opportunity to exercise the system rather than merely observing how the system is sup-posed to operate.

AcknoWLeDgmenTs: This simulator could not have been realized without the dedication, ingenuity, and excellence of the development team: for the simula-tion architecture/coding, Dan chandler and John Fewer; for gui implementation, Jean bell; for systems engineer-ing support, Jeffrey brown, John Fewer, and James mu-maw; for photography and graphic design, Ann bonner and Jeffrey Fiske; for framework development, m. paul Anderson, James brown, clay Fink, William macneil, and glen swanger; and for program management, paul biegel and John Dubro. in addition, many thanks to the



THE AUTHOR

Donna L. koczaja

Donna L. Koczaja is currently supervisor of the naval missile Defense radar Analysis section of the missile Defense ra-dar engineering group. she joined ApL in June 1996 as a member of the missile systems group in the strategic systems

Department. There she spent 9 years doing analysis, test and evaluation, training, and modeling and simulation in support of the Trident strategic Weapons system program. From February 2003 to march 2005 she served as the project manager of the hovering and compensation maintenance simulator project, and from march 2005 to november 2005 she served as the Trident Launcher simulator project manager before transferring to the Air and missile Defense Department to as-sume the role of Aegis ballistic Defense Weapons system project manager. in november 2006 she transferred to her current position. ms. koczaja received a b.s.e. in mechanical engineering and applied mechanics from the university of pennsylvania in 1994 and an m.s.e. in mechanical engineering from The Johns hopkins university in 1996. her e-mail address is [email protected].

chief petty officers who were invaluable in the development of this product: eTc James bartok, eTc Donald click, eTcs eric gibson, eTcs rodney mackey, and eTc matthew Walewski.

reFerences 1coolahan, J. e., “modeling and simulation at ApL,” Johns Hopkins APL Tech. Dig. 24(1), 63–74

(2003). 2Fink, c. r., Database Manager/Scenario Control Framework Comprehensive Design Review, pse-

03-087, Jhu/ApL, Laurel, mD (6 oct 2003). 3skyLight pro ActiveX control, skylight Associates, county Donegal, ireland; www.skylark.ie.

Documents

An interactive simulator for maintenance Training