txE

CORPORATIO N

FINAL REPORT

EMERGENCY MANAGEMENT

COMPUTER-AIDED TRAINER (EMCAT)

CONTRACT NAS8-35815

( N A o H ~ Li\~1787,38) EHEFGENt-i

 v.A.N AG£HLIN T

COMPUTE*-AIDEt lfiAI*E: < (..MtAT ) l-xridl Report

(Essex Corp.) 26 p HC A03/M F A.I CSCL 146

.-2 1554

OncldS

GJ/09 05842

January 31, 1986

ESSEX REPORT NO. H-85-11

SPACE SYSTEMS GROUP • 690 Discovery Drive, Huntsville, Alabama 35806 • (205) 837-2046
FINAL REPORT

EMERGENCY MANAGEMENT

COMPUTER-AIDED TRAINER (EMCAT)

CONTRACT NAS8-35815

Prepared For:

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION

George C. Marshall Space Flight Center

Marshall Space Flight Center, Alabama 35812

and

FEDERAL EMERGENCY MANAGEMENT ADMINISTRATION

National Fire Academy

16825 S. Seton Avenue

Emittsburg, Maryland 21727-8995

Prepared By:

c

Ricardo C. Rodriguez

Randall P. Johnson

ESSEX CORPORATION

Space Systems Group

690 Discovery Drive

Huntsville, Alabama 35806

Report Number: H-85-11

January 31, 1986
FOREWORD

During the past two years, Essex Corporation developed the

Emergency Management Computer-Aided Trainer (EMCAT) system. This work

was performed under contract NAS8-35815 to the Technology Utilization

Office of the National Aeronautics and Space Administration (NASA),

Marshall Space Flight Center (MSFC). Technical direction was provided

by the National Fire Academy (NFA), an agency of the Federal Emergency

Management Administration (FEMA). The direction and support of Mr.

Kenneth Smith and Ishmail Akbay of NASA/MSFC and Mr. William Blair NFA

are gratefully appreciated.

The purpose of the EMCAT system is to provide a low cost,

realistic, real-time simulation system for training fire ground command

personnel in resource allocation and strategy decisions. Multiple

scenarios were developed to demonstrate the flexibility of the EMCAT

system and its ability to fulfill various training needs.

The EMCAT development effort was divided into two phases, the

Requirements and Design Phase and the Implementation Phase. This cost

sharing development effort resulted in three EMCAT systems, two for

delivery to NASA and one for Essex Corporation's use. Five scenarios

were also developed to operate on the system.

Any comments or questions should be addressed to Kenneth Smith at

(205) 453-1474 or Ricardo Rodriguez at (205) 837-2046.
TABLE OF CONTENTS

FOREWORD

LIST OF FIGURES

1.0 INTRODUCTION 1

1.1 Background 1

1.2 Scope 1

2.0 IMPLEMENTATION 2

2.1 Hardware 2

2.1.1 Requirements 2

2.1.2 Component Selection 3

2.1.3 Enclosure Design 3

2.2 Software 5

2.2.1 Requirements 5

2.2.2 Implementation 5

2.3 Video Scenes 8

2.3.1 Requirements 8

2.3.2 Implementation 8

3.0 METHODOLOGY OF SCENARIO DEVELOPMENT 11

3.1 Incident Definition 11

3.2 Responses and Effects Determination 11

3.3 Scene Story Board Development 12

3.4 Database and Software Programming 13

4.0 ASSUMPTIONS 13

5.0 SYSTEM REVIEW AND RECOMMENDATIONS 15

5.1 Reviews 15

5.2 Recommendations 16

APPENDIX A A-l

ii
LIST OF FIGURES

Figure 1: EMCAT System Layout 4

Figure 2: Optical Overlay Concept for EMCAT 10

Scene Generation

iii
1.0 INTRODUCTION

This final report describes the Emergency Management Computer-Aided

Trainer (EMCAT) developed by Essex Corporation under contract to NASA's

Marshall Space Flight Center (MSFC) and the Federal Emergency Management

Administration's (FEMA) National Fire Academy (NFA). This document

constitutes a deliverable end item for the Implementation Phase of the

EMCAT development contract.

1.1 Background

In early 1980, the Technology Utilization Office at MSFC was

approached by the Huntsville Fire Department for help in developing a

computer-based training system for fire fighting personnel. A prototype

EMCAT system was developed by NASA first using video tape images and

then video disk images when the technology became available. This

prototype was demonstrated at various fire fighting conferences and was

evaluated by personnel from the National Fire Academy.

The association of these two federal agencies led to a development

contract for an operational EMCAT system. This contract was awarded to

Essex Corporation in October 1983. During the performance period of the

contract, two operational EMCAT systems were to be produced for delivery

to the Government. Also, various scenarios would be produced to develop

a simulation methodology and to demonstrate the system's flexibility.

The contract effort has led to a marketable fire ground incident

training system, which the Essex Corporation intends to produce.

The EMCAT system is meant to fill the training needs of the fire

fighting community with affordable state-of-the-art technologies. An

automated real-time simulation of the fire situation was needed to

replace the outdated manual training methods currently being used. In

order to be successful, this simulator had to provide realism, be user

friendly, be affordable, and support multiple scenarios. The EMCAT

system meets these requirements and therefore represents an innovative

training tool, not only for the fire fighting community, but also for

the needs of other disciplines.

This document presents the final report for the EMCAT system

developed by Essex Corporation. Three areas are covered: operational

considerations, software, and hardware. The intent of this document is

to provide final development information about the EMCAT system to NASA

and FEMA.
2.0 IMPLEMENTATION

This section provides information about the requirements and design

concepts used in developing EMCAT, including trade-offs made during the

process. Three areas are addressed: hardware, software, and video

scenes.

2.1 Hardware

This section discusses the EMCAT hardware requirements and hardware

design. The EMCAT hardware consists of the components required for the

task, including the computer and the video disk player, the interfaces

required between the components such as the video disk control card, the

computer support hardware such as the disk drives and printer, and the

operator interfaces such as the keyboard and monitors.

2.1.1 Requirements

The EMCAT hardware components must meet certain requirements.

First, they must provide the capabilities required to perform the

functions defined below. They must also be affordable and easy to

transport, set up, and operate. The more detailed requirements for the

system are listed below.

1. The functions that the hardware must perform are:

a. Operate software

b. Output video images

c. Allow for operator interaction

d. Allow for software control of video images

e. Provide status information to the operator

f. Allow for easy scenario swapping.

2. The hardware system must be affordable to many smaller

training groups. This can be accomplished by using simple,

commercially available ("off-the-shelf") components. A

modular approach using readily available components and

standard interfaces helps keep the system price down for users

that already own some components.

3. An integrated package is required to provide ease of handling

and transporting, compactness, and ease of set-up. Since

component level maintenance is desired for simplicity, the

various components in the system must be integrated intact.

All components must be removable by non-skilled personnel for

maintenance. The system console must conform to human

engineering design standards and must be attractive.

4. A highly desirable feature to make the system much more

versatile to the users is the ability to use the individual

components for their original purpose. This would allow other

software to be used on the computer and other video disks to

be used on the player.
2.1.2 Component Selection

The components which are required, along with the selection

criteria for each, are listed below.

1. The computer selected to control the EMCAT system is the Apple

lie computer. In terms of capabilities required, availability

of higher level languages and operating systems, availability

of interface hardware, and price, the Apple was superior to

other available computers. The Apple also has the advantage

of having an extensive line of software available, thus

providing the user with a computer for tasks other than EMCAT.

2. The video disk player selected to generate the video scenes is

the Pioneer LD-V6000 advanced Laserdisc. This player is an

industrial quality machine capable of very fast scene

switching and communication with a computer through a standard

serial interface (RS-232C).

3. The other components include a text monitor, two disk drives,

a printer and interface, a clock, and a video disk interface.

These were selected from those available as meeting the

requirements at the lowest cost and are listed below.

a. Text Monitor - Sanyo 12 in. Monochrome Monitor

b. Disk Drives - Apple Disk II or MicroSci A2 5j in. floppy

drives with Apple control card

c. Epson RX-80 printer and Dumpling buffered interface

d. Clock Card - Timemaster II H.O. from Applied Engineering

e. Video Disk Interface - Apple SuperSerial Card.

2.1.3 Enclosure Design

The EMCAT enclosure must house the hardware components in a manner

that places them in the correct operating orientation as well as makes

them accessible for repairs. These factors were considered in designing

the enclosure shown in Figure 1. The cabinet closes into a solid box

for transport and has been provided with casters and handles. When

opened, the cabinet provides an ergonomically correct workstation for

the system operator and easy access to the components.

Notice; Apple He is a trademark of the Apple Computer Company,

Cupertino, California. Laserdisc is a trademark of the Pioneer Video,

Inc., Montvale, New Jersey.
(£

. O

UJ

h-

cco ^ h- Z IIoo o

<r

o>-<LJh- co>- COO2UJI

LjJo: 13

ooUJ
2.2 Software

The EMCAT software provides the brain of the system. Without it no

simulation would exist, only a set of video images without any control.

This section discusses the requirements for the software and provides a

review of the methods of implementation.

2.2.1 Requirements

At a top level, the EMCAT software is required to support the

following functions:

1. Accept Operator Inputs

2. Resource Allocation and Tracking - including personnel,

equipment, water, and time

3. Structure/Situation Tracking - including fire and smoke

progression, fire and water damage, victim condition, and task

progress

4. Video Scene Control - including determining the proper video

scene to reflect the current situation and controlling the

video disk player through the interface card.

5. Update Operator Status - including the status display on the

text monitor and printed reports both during and after the

simulation.

The software must provide these functions in a real-time mode and must

provide these functions for multiple fire ground scenarios. Flexibility

shall be provided to customize a scenario to individual user's needs,

realizing that such customizing is limited by the video disk.

In addition to the functional requirements listed above, the

software must conform to certain programming standards. These include

the use of structured programming and code modularity. The use of a

compiled language, such as PASCAL, is also required to provide the

processing speeds needed to keep up with all of the functions in a

real-time mode.

2.2.2 Implementation

To meet the requirements on the software discussed above, the Apple

Pascal system, version 1.2, was selected for developing the EMCAT

software. The system not only provides the PASCAL compiler, but also

provides an editor and the necessary file management utilities to

support the software development. The PASCAL language is designed for

structured programming techniques which simplifies code debugging and

maintenance.

The EMCAT simulation software was generated in three sections to

better utilize the available memory resources of the Apple computer. An

introductory section provides operating instructions, scenario pre-plan

information, and several other options for an instructor/operator. The

main section is automatically invoked by the introductory section. The

main section performs the functions required to support the simulation
session. The reporting section is automatically invoked by the main

section upon termination of the simulation. The reporting section

provides final status information to evaluate the trainee's performance

in the simulation.

2.2.2.1 Database

The software was designed to allow for multiple scenarios by using

a database to provide most of the information to define the scenario.

An editor has been developed to allow the user to modify the databases.

This provides the benefit of allowing database changes prior to any

simulation session, thus providing the capability for users to custom

tailor the scenarios to their needs. At the start of a simulation

session, the software reads in the database information.

One section of the database defines the units and areas in a

session, including the burn and put-out characteristics, the search

order and time, and the location of victims. This information defines

the scenario's structure and default progression.

Another section of the database defines the resources available for

the scenario. Up to 10 companies can be included, with the arrival

time, number of firefighters, amount of water, and various fail flags

for each company defined. The services available and the number of

hydrants available are also defined.

The final section of the database defines the tasks which can be

performed by the operator. These include search and rescue, laying a

line, putting water on an area, trenching, ventilating, and operating

the machinery. The information provided for each task includes the

number of firefighters required, the various times required, whether a

task is cancelable and, if so, the time required to make the resources

available for reassignment. The effects of some tasks, such as search

and rescue, are built into the software. The effects of other tasks,

such as putting water on the fire, are defined by the rules.

For more information about the contents of the database, see

Section 5 of the EMCAT System Operations Manual.

2.2.2.2 Physical Simulation

The EMCAT software is designed to provide a simplified simulation

of the real physical properties and behavior of the fire in the

structure. This approach was taken to allow the software to more

closely simulate the effects of time and operator inputs on the fire.

Most of the inputs for this software are provided by the area definition

portion of the database.

The default fire progression is defined by a series of ignite times

in the database and by a series of coefficients which can be set by the

rules. The ignite time indicates the elapsed time into the simulation

at which each area will ignite. In a default progression,
each area will ignite in a predetermined sequence. The coefficient

provides for an adjustment to the ignite time in response to certain

actions by an operator. It can be positive which causes the ignite time

to be accelerated, or negative which causes the ignite time to be

delayed. For example, water in one area may cause an adjacent area's

slow coefficient to be set to delay or completely halt the fire spread.

Venting an area may cause that area's coefficient to be set to

accelerate the spread of fire into that area.

Once an area is on fire, the simulation uses the following equation

to determine the amount of fire involvement in that area:

%FIRE = %FIRE + (CFIRE) - (CWATER * WATER1'

2

)

In this equation, the WATER term is the amount of water (in gallons per

minute) being put in the area. The CFIRE coefficient, which is defined

in the database, determines how fast the fire in the area will build

(CFIRE is in percent growth per second). The CWATER coefficient, which

is also defined in the database, determines how fast the fire in the

area will be extinguished (CWATER is in percent extinguishment per GPM

per second).

The fire growth equation is invoked every 4 seconds for each area

on fire. The amount of water being put into an area is automatically

factored in. If the water is increased, the effectiveness of it

increases exponentially as in an actual fire. Insufficient water into

an area can cause the fire growth to slow down, but not stop.

2.2.2.3 Tasks

The operator's inputs to the EMCAT simulation are defined by the

tasks which the available firefighters can perform. As tasks are

performed, they affect the default fire progression, the disposition of

victims, or the resources of the scenario. The manner in which a task

affects the scenario is defined in the software for some tasks or in the

rules for the other tasks.

There are a limited number of possible tasks in the EMCAT

simulation: laying a line to a hydrant, putting water on an area,

ventilating an area, trenching an area, search and rescue, and

communications. The resource and time requirements for these tasks are

defined in the database for each scenario, as discussed in the previous

section. For each task, the operator must provide certain parameters to

the software such as the line size to use, the area being affected, and

the number of firefighters to perform the task.

Note that if the operator selects a company with insufficient idle

firefighters assigned to a task, the software will allow the operator to

reassign those firefighters. If a firefighter is reassigned, the

effects of the task he/she was previously involved in are negated and

the firefighter will begin performing the new task after a "backout"

period of time.
2.2.2.4 Rules

In order to define the effects of actions of the operator on the

fire status, a set of rules is developed for each scenario. Rules are

incorporated into the software as a series of conditional (IF)

statements. A rule can have conditions such as time, water status, and

ventilation status. If a rule's conditions are true, the rule can

change the amount of water, the "slow coefficient," or the water or fire

coefficients of various areas. Rules are also used to end a simulation

based on the current video scene and to switch from one scene to the

next.

2.3 Video Scenes

The most challenging aspect of developing the EMCAT system was the

development of a low cost method of generating the realistic and dynamic

visual fire scenes. This section lists the scene requirements and

describes the method used for generating the images.

2.3.1 Requirements

The contractual requirements for the visual scenes are:

1. Visual sequences shall be limited to an affordable number

while providing sufficient variety for meaningful scenarios.

2. The images of burning structures shall be as realistic as

possible. Flame shall grow or diminish in a natural way.

Smoke shall change from dark to light (steam) at the

appropriate time.

3. Stylistic representations of fire and smoke are unacceptable.

4. Simulation depth and realism shall be achieved in such a way

that production doesn't become prohibitively expensive, for it

is anticipated that users will demand many affordable, perhaps

even customized, scenarios.

2.3.2 Implementation

In order to meet the requirements for the visual scenes at an

affordable price, several concepts were considered. These are listed

below along with the advantages and drawbacks of each:

1. The use of a Chromakey system to electronically superimpose

fire and smoke on an image of the structure was considered.

This method allows the "stock" fire and smoke footage to be

electronically scaled and positioned over the structure. A

photograph of the structure would be sufficient for this

method.
There are three disadvantages to the Chromakey method. The

first is the "halo" effect which is evident on the overlayed

objects which gives the objects a "pasted on" look. The

second, and most serious, disadvantage is the prohibitive cost

of renting the required electronic editing equipment. The

third disadvantage is the scene degradation resulting from the

editing the dynamic elements onto the scene one at a time.

2. The use of real scale models of the structure with real fire

and smoke was considered. This method permits the realistic

geometry of the structure and the capability to incorporate

structural damage.

The main disadvantage to this concept is again one of cost. A

model of the larger and more complex structures could cost

several thousand dollars. Another disadvantage is the problem

of scaling the fire and smoke effectively.

3. The generation of the images using only software graphics and

animation was considered. This concept would provide for very

flexible scene generation since little or no real imaging is

required. If carried to an extreme, this system would even

allow for the elimination of the video disk, with the software

electronically generating flame and smoke on an image.

Again, the major disadvantage of this concept is cost. Systems

capable of generating the required scenes are very expensive

and the process is labor intensive, at least initially.

Current systems also lack the ability to generate completely

realistic images and animate them convincingly. Current

scenes tend to look cartoonish.

4. The method considered and ultimately developed for generating

the EMCAT visual scenes is the optical overlay concept shown in

Figure 2. In this concept a photograph of the structure is cut

to allow smoke to pass through the windows, door, vents, etc.

Two black templates with the shape of the structure are made.

Behind one template fire is generated in the windows, doors,

vents, etc. White smoke (steam) is pumped through the windows,

doors, vents, etc, of the other template. The three images

are optically overlayed by using a half-silvered mirror.

This method offers the advantage of being inexpensive, since

little specialized equipment is required. It also provides for

realistic geometry of flames and reasonably realistic flame and

smoke.

The disadvantages of this method mainly stem from the problems

of scaling flame and smoke down to the required size. Both

fire and smoke tend to move too quickly at this scale and the

fire tends to be unrealistic and difficult to control. The

speed problem was resolved by slowing down the image to

one-half the original speed. The fire problem was resolved by

using simulated flames created by fast-moving segments of

cellophane.
16x20 PHOTOGRAPH

FOR SMOKE

BLACK MODEL

FOR FIRE

BLACK MODEL

FOR STEAM

BEAM SPLITTING

MIRRORS COMBINE

ALL 3 IMAGES

OBJECTIVE

MIRROR

1st. SURFACE

FOR FLAME

MODEL

OBJECTIVE

MIRROR

1st SURFACE

FOR WHITE

SMOKE MODEL

FIGURE 2 - OPTICAL OVERLAY CONCEPT

FOR EMCAT SCENE GENERATION

10
3.0 METHODOLOGY OF SCENARIO DEVELOPMENT

This section describes the steps used in developing each scenario

for the EMCAT system. This development methodology was a key design

goal of the EMCAT development contract. The development process assumes

that a technical consultant for fire progression and fire fighting is

involved to provide all the required information.

3.1 Incident Definition

The first step in the development of a scenario is the selection of

the training objective, i.e., fire situation to be simulated. Once this

is known, the following information must be generated.

1. A structure is selected and photographed from the appropriate

vantage point. Other photographs showing exposures, other

sides of the structure, or other pertinent views can also be

taken for inclusion in the pre-fire section of the video disk.

2. The structure layout and construction is determined. As long

as the external features are not violated, the real floor plan

can be altered to fit the fire progression desired.

3. The fire progression is determined by selecting a point of

origin and determining the fire flow paths. Technical input

is required to determine fire growth rates, the time to burn

through an obstacle, etc. For each area in the structure, the

fire start time, burn rate, and extinguishment rate need to be

determined.

4. An initial assessment is made of the occupancy rate and the

location of the victims, as well as the resource availability.

This information is in the database and can be updated later as

desired.

3.2 Responses and Effects Determination

Once the basic incident has been determined, the possible fire

fighting and rescue responses can be determined. The effect on the fire

progression for each response is also determined. Note that each

response needs to be assessed individually. The following types of

responses need to be considered.

1. Application of water for each area or groups of areas. How

will it affect the fire in that area and how will it affect the

fire progression into other areas?

2. Ventilation of an area. If done in the correct place, this

could greatly slow the fire spread. If done incorrectly, it

could greatly increase the fire spread.

11
3. Search paths for each group of areas need to be determined.

4. Any areas which can only be reached through another area need

to be determined. The simulator will allow the scenario to be

defined with these "paths" which must be extinguished before

another area can be reached.

3.3 Scene Story Board Development

Using the fire progression and responses developed above, the scenes

for the scenario can be determined. These are drawn on simple outline

drawings of the structure to create a story board which is used during

filming. The location of fire, smoke, and steam is shown for each scene

in the story board. The process of development is as follows:

1. The fire progression assuming no action, or "default"

progression, is drawn. This is normally between 5 and 10

scenes long. Each time a major change in the smoke, fire, or

steam occurs, a new scene is required. The progression should

end when all major areas are involved.

2. For each scene in the default progression, determine the visual

effect, if any, for each possible response. Water application

on each area which shows smoke or flames will require a new

scene. Ventilation of an area will require a new scene (by

showing fire appearing through the vent). Fire appearing due

to alternate progressions or due to the removal of water will

require a new scene. As new scenes are developed, these are

also drawn on the story board if they do not already exist.

3. The process in step 2 is repeated for each scene developed

until an "end" scene is reached. An end scene will usually

show all areas extinguished, major areas protected while others

are extinguished, or major areas burning out of control while

other areas are protected or extinguished.

A. When all scenes have been illustrated on a story board, the

number of scenes may be excessive. Since only about 100 scenes

will fit on a video disk (assuming 15 second scenes and

overhead for pre-plan information, etc.), the scenes may need

to be reduced.

Some factors which will help in reducing the number of scenes are:

a. Eliminating transition scenes. For instance, fire will

immediately turn to steam in the simulation.

b. Combining similar scenes, especially those which are the

result of second or third generation responses.

c. Limiting the extent of the incident simulated. Once an

attack has been established and depicted, the simulation

should end.

12
5. Once the story board is completed, the scenes can be filmed and

edited. Each scene should be filmed at least 10 seconds longer

than required to allow for editing and video disk overhead.

Since the order of the scenes on the video disk is not

important, it should be selected for ease of filming and

editing.

3.4 Database and Software Programming

In this phase of scenario development the information generated

during the previous phases is used to develop the scenario specific

software and the database. The database is developed from the structure

definition, fire progression and resource availability information

defined in the Incident Definition phase. The scene change rules in the

database can be directly transferred from the information developed for

the scene story boards. The rules and any other special software

required for the scenario can be determined from the information

determined in the Responses and Effects phase. This includes areas

where firefighter actions can be taken, any limitations on

accessibility, and the effect of ventilation and water application in

the various areas.

4.0 ASSUMPTIONS

This section documents the assumptions which are built into the

software, as well as those made during development of the software. A

list of those assumptions follows.

1. During search and rescue operations:

a. If area is greater than 50% involved, it will not be

searched and will result in a "Too Hot to Search" message.

b. One firefighter is required to rescue each victim found.

c. If the number of firefighters searching is less than the

number of victims found, excess victims will be left

unrescued.

d. If the number of firefighters searching is greater than

the number of victims found by more than one (i.e., 2 or

more firefighters), then the victims will be rescued and

the search will continue with the remaining firefighters.

e. Firefighters will not re-enter the structure after

rescuing operations unless commanded.

2. During water application:

a. Any time water is being used from an engine, a pump

operator will be assigned automatically by the software.

b. The turret is assumed to be pre-connected.

13
c. The water application rates for the various line sizes

are:

3/4" Line = 15 GPM

1" Line = 30 GPM

1-1/2" Line = 80 GPM

1-3/4" Line = 200 GPM

2-1/2" Line = 250 GPM

Turret Line = 500 GPM.

These figures were provided by Mr. Blair of the National

Fire Academy.

d. If firefighters are assigned to put water on an area which

is not on fire, no water will be applied (no water damage)

but the effects of water will be applied.

e. While applying water, firefighters will search the areas

and, if victims are found, will abandon their hoses to

perform rescue.

f. If the water.supply runs out ("TANK EMPTY"), any

firefighters applying water will automatically back out

and will have to be reassigned when the water supply is

restored.

3. Regarding the water supply:

a. The water in the tanks of all the engines or tankers on

the scene is assumed to be available to all firefighters.

b. As soon as one engine is hooked to a hydrant, all engines

are assumed to have access to an unlimited supply.

c. A hydrant is assumed to be able to supply as much water as

needed unless it is failed.

d. When firefighters lay to a failed hydrant, they will

report it and stop. They must be assigned to lay another

line to an unfailed hydrant.

4. For ventilation and trenching:

a. If the area to be vented or trenched is above the third

floor, an aerial ladder can be used to speed up the

process, if available.

b. If a saw fails, the firefighters will automatically return

to get another saw.

14
5.0 SYSTEM REVIEWS AND RECOMMENDATIONS

This section presents the results of the various demonstrations and

reviews of the system. In the original contract, an evaluation period

was provided whereby the system would be made available to various

agencies for review. This was not performed as specified due to time

and money constraints. However, an extended evaluation of the system

has been conducted on the system by the National Fire Academy, since

they have had access to an EMCAT system for almost 11 months due to an

early delivery. A system has also been purchased by the Kentucky

Vocational Education system and has undergone extensive evaluation over

an 8 month period. These extended evaluations have allowed many of the

problems found to be corrected in later versions of the software, a

capability which would not have been possible under the original

contract.

5.1 Reviews

Listed below are the demonstrations and reviews of the EMCAT system

which have been conducted during the contract period. Note that those

demonstrations which were held using the prototype EMCAT system

developed by NASA are not listed.

1. National Fire Academy - Two review/discussion visits to the

NFA January 15-16, 1985 and December 9-10, 1985. Two

review/discussion visits by Mr. Blair to Essex on February

14-15, 1985 and July 15-16, 1985. During these visits

requirements for scenarios and software and problems with

the system were discussed. Most of these requirements

have been implemented and most of the problems have been

solved in the final EMCAT system.

2. Kentucky - The Public Safety Occupations division of the

Kentucky State Vocational Education system has purchased a

system for the purpose of evaluation. On August 22, 1985

several demonstrations of the EMCAT system were arranged for

Essex personnel to attend and gather comments. The system was

also used during the Lake Cumberland Regional Fire School held

on August 24-25. The details of these reviews and the results

are provided in Appendix A.

3. The system was demonstrated as part of the National Fire

Academy presence at the Fire Department Instructors Conference

held in Cincinnati during March 20-21, 1985.

4. The system was demonstrated at the U. S. Navy's Southeast

Regional Fire Officer's Training Course at Whiting Field in

Milton, Florida during December 3-5, 1985.

Although most of the problems or discrepancies which were uncovered

during the various reviews have been incorporated into the final version

of EMCAT, some of the comments were not within the scope of the

development effort.

15
5.2 Recommendations

Several recommendations have been made for the EMCAT system which

would greatly enhance the EMCAT but were not within the scope of the

original contract. These are listed below.

1. Make the EMCAT system available for IBM and IBM compatible

equipment. It was also mentioned during the Navy review that

the U. S. Navy and Air Force have selected the Zenith Z-151

personal computer, which is IBM compatible.

2. An input mode easier to operate than the current keyboard had

been requested many times. The touchscreen software, which

will greatly simplify user inputs, has been developed as part

of the development effort. If found to operate as expected

during subsequent testing, this version of the system will

probably be the version which is marketed by Essex.

3. Multiple fire situations for a scenario were requested in order

to increase the factors available to training officers. The

database makes this capability currently available in software,

the only limit being the scenes available on the video disk.

This could be made possible by generating more fire

progressions on one video disk (limited to 2 or 3 fire

progressions) or on multiple video disks (unlimited fire

progressions).

4. Various suggestions have been made for providing a "difficulty

factor" in the software which could be set by the instructor

prior to each simulation session. This factor could be

incorporated by simply increasing the speed of the fire spread

or could involve adjusting many or all aspects of the

simulation.

5. Many reviewers have complained about the inability to see any

of the hardware or personnel fighting the fire. Suggestions

include showing trucks as they arrive, showing personnel going

into the structure when assigned, and showing lines that are

put into a building. These could be accomplished with digital

graphics overlayed over the video image.

6. The addition of sound effects has been mentioned as a

worthwhile enhancement to the realism of the simulation. These

include both background sounds of the fire scene and voices to

simulate radio transmissions. The current system will not

support sound because the video disk player shuts off the sound

during slow-speed play modes, which are used for all EMCAT

scenes. Newer technology players, or external sound sources

such as synthesizers, would provide the capability for future

development.

7. Many requests have been made by potential users in other fields

for similar systems. Applications which have been considered

16
include police and security force training, plant operations

training, driver training, and command post operations training

and management. Essex is considering the development of other

systems and is seeking funding for this purpose.

8. In order to eliminate the limiting aspects of the video disk in

terms of the number of scenes and the unvariability of the

simulation, it is becoming- apparent that the newly emerging

computer graphics technology will provide some exciting

breakthroughs. Using software very similar to that already

used in the EMCAT system, a simulator using this technology

could generate an unlimited number of fire progressions for a

given structure. The small amount of realism lost would be

offset by an increase in fidelity of transition scenes,

variability of smoke and flame density, and even structural

damage due to fire.

In summary, the EMCAT system has been demonstrated to be an

effective device for training fire scene commanders in the allocation

and deployment of resources and real-time decision making. The system

also appears to be marketable in the fire fighting training community,

and Essex plans to pursue additional development and sales activities.

17
APPENDIX A

EMCAT DEMONSTRATIONS AND REVIEW COMMENTS

A-l
A listing of the demonstrations and reviews conducted in Kentucky

during August 22-25, 1985 and a listing of the comments and problems

recorded during those reviews follow. Note that the "new version" of

the software referred to in the text is the final version delivered at

the end of the EMCAT contract.

A. Demonstrations and reviews of the EMCAT System:

1. Campbellsville-Taylor County Fire Department; August 22.

2. Elizabethtown Fire Department; August 22.

3. Cave City Fire Department; August 22.

A. Lake Cumberland Regional Fire School; August 25.

B. Comments and problems recorded during the reviews listed above:

1. Develop an EMCAT System on the IBM Personal Computer.

2. Provide an audio track of fireground sounds during the

simulation.

3. Output status messages, which currently appear on the status

screen, via an audio system.

4. Provide a status monitor, currently provided only for the

operator, for the trainees. This is possible with the current

system by "splitting" the video signal for this display.

5. Show equipment and personnel on the video scene to help in

tracking resources. Other alternatives to this concept include

providing a plot plan of the fire scene with some means of

tracking available resources. This can either be a digital,

computer-controlled scene; a table-top, three dimensional

model; or a magnetic, manually controlled "simulation board"

(as currently used with the sand-box systems).

6. Provide standard pre-fire plan information in the scenario

manual. Also provide information about the time of day,

weather, and other factors which affect the incident. These

provided in the scenario manuals.

7. Develop a Tanker/Chemical Spill/Hazardous Materials scenario.

8. Several comments were received which would make EMCAT more

useful for volunteer departments:

a. Randomize the number of firefighters available for each

scenario.

b. Stagger the arrival of firefighters at the scene. This is

supported by the new version being developed.

A-2
c. Provide for drop tanks, ponds, or other water sources.

Some of these sources, such as ponds, can be supported in

the current system by using hydrants.

d. Provide the capability of calling for additional companies

rather than calling for the next alarm.

e. Provide the capability to assign any firefighter to any

task, regardless of which company to which they belong.

9. Several comments were received about the printout provided by

the system:

a. Print the line size used when water is applied. This is

supported by the new software version.

b. Print the total amount of water used during the simulation

session.

c. A problem exists with the determination of water damage

which will be corrected in the new software version.

10. The effect of smoke inhalation on victims is not supported.

However, the new version of the software automatically injure

the victim when the fire starts in the area and kills the

victim when the fire reaches about 50% involvement in the area.

11. Provide a flag by which the use of breathing apparatus must be

requested or the firefighter will be injured. Currently, the

operator can disable a firefighter manually.

12. Support the ability of firefighters to search a room with a

line. This is supported by the new version of the software.

It was also noted that replacements for a water crew that had

abandoned their lines to perform a rescue would have a

decreased setup time.

13. It was pointed out that one firefighter was usually assigned to

protection with a charged line when ventilation was being

performed. This can be supported in the current system by

setting the minimum number of firefighters required to perform

the ventilation task.

14. Provide some method to injure or kill firefighters if utility

support is not requested or if the power and gas lines are not

disconnected.

15. Currently, if a firefighter is sent to an area with a line,

water will be applied even if the area is not on fire. This

is changed in the new version of the software.

A-3
16. The question of the EMCAT system use in the one-on-one

training mode versus the classroom mode (with an instructor

and/or operator) arose. The current system requires some

prior operator knowledge. However, it has been designed for

both modes of training. A touch screen was subsequently

implemented to make the system easier to operate. A light pen

input system could also be implemented.

A-4