Firefighter Communication System
Part 2: Design Alternatives
|
Fall Semester 1999 |
Team Canada
|
|
|
|
|
|
|
|
|
|
Project Description
Unlike many emergency workers, firefighters operate in a complex, rapidly changing environment, frequently in coordination with a large number of other individuals. Often, the firefighter is so lacking in situational awareness that he/she cannot even see the rest of the 4-person company, let alone the rest of the team. Over the years, a highly-evolved command structure has developed through bitter experience. This structure serves to coordinate the efforts of all the firefighters and insure their safety in situations that can change from safe to lethal in seconds. Unfortunately, in most cases, the communication system which facilitates this command structure is not tailored to the unique needs of firefighters. Instead, it has been adapted from off-the-shelf components that were developed for other, less-demanding purposes.
The command structure is rigidly hierarchical, enforcing the principle that no one person should handle more than about four problems simultaneously. It is also modular, so that as the situation evolves new personnel may be plugged in to keep the same number of simultaneous problems for all individuals. This structure developed through much effort and thought and, therefore, should not be changed by our system. Instead, we should try to enhance it through the use of technology that better affords the tasks they are trying to perform. Ideally, our communication system would be so natural that it would fade into the background of the firefighter’s tasks. It is likely, however, that this ideal is simply unattainable, if for no other reason then because what is natural for one person is not so natural for another. Thus, we have instead focused on ease of use in enabling activities that fit within the command structure and making difficult or impossible activities that depart from or frustrate that structure. Since these latter activities have been the cause of many deaths among firefighters (and are indeed the reason the command structure has evolved in the way it has), this seemed a wise choice.
We chose, then, to focus our design efforts more on the interpersonnel communications aspects of the problem and less on the management aspects. There exists an elaborate command and control system using a large number of preprinted whiteboards and magnetic boards. When asked, the firefighters with whom we spoke agreed that it would be a Very Bad Thing if this system were ever to go down with information being lost even temporarily. Since they are very experienced with its use, since the grease pencil and magnet operation is inherently robust (and waterproof), since the preprinted boards serve the role of placing their “memory in the world,” and since we did not see much we could add beyond record keeping that would not admit the possibility of information loss and the consequential chaos, it seemed best to leave this part of the system as it was.
Therefore, our system is designed to enhance the personal safety of individual firefighters, to be transparent to the command structure and allow it to operate smoothly and efficiently, to easily enable necessary communications and disable unnecessary ones, to offer functions appropriate to the role each individual firefighter plays, and to be robust and stable.
Our target population is as described in the previous part of the project under User Profile. See http://www.cc.gatech.edu/classes/AY2000/cs6750b_fall/projects/Team9B/part1.html.
Requirements Summary
Functional
Observable
Firefighters operate in an environment of severely reduced situational awareness. The Backdraft depiction in the movies is very far from the truth. Firefighters on the line operate in an environment filled with poisonous fumes and smoke so thick that they frequently keep in contact with each other by touch due to literally no visibility. In contrast, commanders are typically outside – sometimes far away from – the scene. Though their vision is unimpeded, they are not located where they can see what is going on. In both cases, accurate verbal communication is essential in forming a complete mental picture. Feedback is a necessary part of completing the communications loop. For instance, when a firefighter triggers a distress signal, he needs immediate feedback that he has successfully turned the distress on as well as feedback from the outside that the distress signal has been received and noted. A commander needs to know that his orders have been received and that nobody has dropped out of the communications system. It should be clear at all times who is being conversed with and the operational state of the radio.
Physical Robustness
More than most other emergency personnel, firefighters operate in an environment where it is easy for a radio to be damaged. It may succumb to excess heat, water, physical impact, noise, or simply be snagged on something. In fact, firefighters claim that the best way to test the durability of any product is to leave it in a fire station with the firefighters for a week. Most of these can be addressed by appropriate physical construction – for example, the use of gold contacts rather than copper to avoid water corrosion or a membrane in front of a speaker to exclude water so it remains audible. While much of this is not an interface design issue per se, it is a usability issue since it is essentially a requirement that the radio[1] remain usable.
Safety
In the first part of this project, we reported several cases in which firefighters were either seriously injured or killed due to inability to make an emergency situation known. This becomes an interface design issue in that it is easy to imagine situations in which a firefighter may not be able to actuate a particular distress mechanism. Unconsciousness, for example, would prevent voice actuation. Being trapped under a fallen timber may prevent actuation of a physical button. Another interface design issue occurs at the other end of the signal where the next person up in the command hierarchy must be able to easily recognize that a distress signal has occurred and rapidly identify its source.
Command Hierarchy Support
This requirement has been added since the previous part of the project as the result of feedback from the firefighters with whom we spoke regarding that part. It partially subsumes the previous customizability requirement. The system should be structured so as to easily afford communication within the command structure and make it difficult to go over the head of one’s supervisor. Command and control has evolved into its current state over many years and is specifically designed to avoid chaos on the fireground. Firefighters are loathe to change it and the more tightly the communication system is integrated into the existing hierarchy the better it will be perceived to be. This may dictate different radio functionality for different levels in the hierarchy. It certainly requires a degree of modularity matching that of the command hierarchy. As an emergency incident grows, personnel are plugged into the command hierarchy or their duties are modified on the fly. The communications system must afford a matching level of modularity.
Nonfunctional
Universality
Ideally, all firefighters should be equipped with at least a minimum level of communication equipment. At the lowest level, this may involve simply a means of signaling distress but, for safety’s sake, universality of equipment is essential.
Minimal Interaction
Although firefighters are not averse to the operation of equipment (in some cases quite sophisticated equipment), it is clear that they frequently have their hands, literally, full with more important things. Thus, the fewer times they have to take a hand away to actuate a communications device, the better. This may be less true outside, in the command positions where it may be effective to trade off flexibility and customizability here, but is certainly true in the front line positions which are equipped with communication devices.
Backups and Redundancy
Again, as a safety issue, it is essential that a minimum level of functionality be maintainable even when the radio is damaged. Firefighters do operate in teams and that in itself provides some redundancy but it is easily conceivable that a firefighter may become separated from his team or may be the only conscious member of his team. Therefore, each device needs to satisfy this requirement individually. A less obvious example of a backup might involve dispatchers, in a calmer and less stressful environment, being specifically tasked to pay attention to message traffic to insure that important pieces of information – especially distress signals – are not missed. Finally, some of our designs rely on sophisticated computer equipment for tasks such as voice command recognition or managing traffic on multiple radio channels. Since no software can be relied on to be functional 100% of the time, clearly there must be the possibility of an alternate system during downtime.
Language
This may become a partially functional requirement in a system that employs voice activation but it is a consideration in any case. Keywords for situations involving immediate attention should be obviously related to the situation but not so common as to be frequently employed in other situations. This will enhance the audibility of these terms and increase the chance that they will be heard and the situation dealt with. For example, a distress situation should not be signaled by saying “Help!” since help may be employed in many non-emergency situations as well – “Help me get that hose over here.” Frequent non-emergency use would dull the visibility of the word. A more useful emergency word would be something like “Mayday” since that is unlikely to be use in a non-emergency context.
Designs Options
Design 1: The FireBoard
Description
Independent of technologies that the individual firefighters use, the necessity of maintaining high-level control of communication systems quickly presents itself when communication requires multiple channels. Operated by the Technical Officer[2], the FireBoard (the FireBoard) allows centralized control of the dynamics of the communication system.
The FireBoard is a small board that is about the size of a regular sheet of paper with depth of about one inch. Physically this board is very similar to the StuPads that were tested recently in Classroom 2000 at the Georgia Institute of Technology. The FireBoard contains a touch-sensitive screen which can be used for interacting with the system. The screen can be operated using either a stylus or a finger. A computer and a radio are embedded in this board, allowing it to intelligently make decisions about communication structures (channels, frequencies, etc.) and to communicate these decisions to the individual firefighter communication units.
The interface with the FireBoard is hierarchy-chart creation utility. See Figure 1. This hierarchy is the fire command hierarchy that we have described in the first portion of this project. The Technical Officer simply fills in the details of which units are on the scene for each element of the hierarchy. Once one node has been filled in, another one becomes available. The number of children nodes in the hierarchy, however, is limited to 5 nodes. Once 5 children nodes have been reached, the Fire Ground Commander must sub-task before more nodes can be added. This enforces the “Span of Control” principle which keeps a commander from being overwhelmed with communication.
This begs the question: How does the necessary information get into the FireBoard so that the Technical Officer is not overwhelmed entering information about the individuals on the scene of the emergency? Currently, firefighters write their names on a card in the fire truck when they arrive at work. When a crisis situation emerges, these cards are removed from the trucks and used by the Fire Ground Commander to know which individuals are on the scene. Using the FireBoard, we would need to modernize this system.
When a firefighter arrives a work, he/she would check in at a computer through a swipe of the identification card that is already worn at all times. He/she would also check out a radio with a swipe of the card. This allows a computer to know which individuals are accounted for and which radio each individual possesses. The cards on each truck would, necessarily, become cards with a magnetic stripe containing information about the individuals on the truck. Then, when the card was removed from the truck at the scene of a crisis, the Technical Officer would only need to swipe the cards on the FireBoard in order to transfer all pertinent communication information to the system. Then, choosing which units are in the hierarchy would simply be a matter of choosing the correct unit from a list of units at the scene.
Should firefighting units with differing systems be called in to help with the crisis, they could be entered into the FireBoard by hand. The FireBoard would contain a handwriting-recognition unit similar to many of the palm computers currently on the market. Also, The FireBoard would tell the Technical Officer what to tell the arriving units with regards to appropriate frequencies, etc. This would also allow the Technical Officer to make changes in the system in cases such as a malfunctioning radio that must be replaced.
Figure 1: FireBoard
Rationale
The FireBoard serves several purposes:
- Centralized control and decision making regarding communication;
- Easy maintenance of large communication structures;
- Logs of the command hierarchy as a crisis progresses; and,
- Flexibility in communication systems and structures[3] while maintaining a single interface to the communication structure.
Design Scenario
“Two alarm fire at 801 Atlantic Dr,” the call goes out. Two units screech out of the fire station headed to stop a fire and rescue the helpless engineering students. As they pull into the scene, the commander can tell this is going to be a long day. Students and professors are hanging out most of the windows screaming, “I’m not leaving without my computer.”
The Technical Officer grabs the bags of communication boards and begins to lay them on the hood of the car. Meanwhile, an assistant has gathered the cards from the fire trucks located at the scene and has begun to swipe them into the FireBoard. By the time the Fire Ground Commander has assessed the scene and the firefighters have suited up, all information has been entered into the FireBoard and the Technical Officer has already entered the Fire Ground Commander into the communications hierarchy.
“ECO1[4], you vent the roof. ECO2, take care of the second floor. Lewis, you’re Safety. Camp, handle the media.” As the orders flow to the teams, the Technical Officer clicks on the nodes in the command hierarchy on the FireBoard and chooses which individuals (or groups) are fulfilling the particular roles. By the time the firefighters begin to move into places, the radio communication structure has been completely set up for them. Now the firefighters can breath easily knowing that they will be able to communicate with each other during the difficult task ahead. With so many weary-eyed programmers still in the building, it is nice to know that communications have been taken care of already.
Design Assessment
The firefighters we talked with liked this idea in general. In particular, they focused on the fact that the FireBoard forces the commander to sub-task when a certain number of children nodes has been reached. This saves lives. Their suggestion was to make the default 10, but to allow departments to customize the maximum number of children nodes based on their individual needs.
Additionally, the firefighters felt that the particular use of StuPad technology was not the most appropriate technology. Many Fire Ground Commanders are already carrying laptops with them. They felt that the software we were describing should be integrated into the laptop, reducing the number of things with which a commander must worry. In a world where much is happening and a large number of artifacts are already in use, reducing the load by one can be a big help. Having a laptop do these functions would also better support expandability to other tasks in the future.
Design 2: The “Star Trek” Personal Communication System
Description
For
this design, we decided to support the current half-duplex communication style
and complement it by adding the ability to direct the communication channels
via a wrist control. The communications
system will have two major parts – the speaker/microphone/personal safety
system (See Figure 2) that will be attached to the shoulder of the fireman and
the channel selection system (See Figure 3) that would attach to the wrist of
the firemen using Velcro straps. Most
users of the system would be the higher-level officers that have multiple
groups underneath them. On the bottom
level of the command hierarchy, the officer for the company would be the only
one with a radio – as it is in the current system – and it would be a
simplified version without the wrist pad.
We did not give the lower-level officers the wrist pad for two reasons. First, they only have one direction of
communication (up) and it would be unnecessary equipment. Secondly, the bottom-level individuals will
be those that will be entering the harsh environments and the wrist pad is not
designed to survive these environments.
Figure 2: "Star Trek" Personal Communication System
Figure 3: Wrist Pad Control Module
The wrist pad would control the flow of information and allow users to speak up the command hierarchy or to a subset of the groups below them. The assignment of groups to channels would be performed by either the Dispatcher or by the Technical Officer who works with the Fire Ground Commander, potentially using a system similar to that described in Design 1. When a channel becomes available, the button on the wrist pad illuminates yellow to show that that there is a communication link between the two users. This communication link is achieved through the radio systems “pinging” other specific radio systems with which it is trying to stay in contact. When the user presses down a button to designate the direction of their communication, the selected buttons will blink between two levels of intensity to indicate selection. When the user operates the radio, he/she will only send the communication to the users selected on the wrist pad.
The microphone/speaker/PASS[5] system will operate by the user pressing the big red button attached to it. When the button is held down, the microphone will be active and they will broadcast their message to the parties designated by the wrist control. Releasing the button terminates the transmission. To activate the PASS system, the user would tap rapidly on the button to activate the system. This would send a radio signal as well as having the radio emit a high-pitched sound.
Rationale
The reason that we chose the half-duplex structure based on the command hierarchy is to reduce communication clutter throughout the crisis team. The half-duplex allows users to perform their actions in the current manner. They speak in terms of whom they want to talk to, who they are, and then their message. For example: “Ground control, this is sector 2 control, the fire is spreading quickly above us and we are moving out, over.” By limiting the direction of the communications, we assume that we are reducing the amount of attention individuals must spend on monitoring the radio since groups receive information only when it is relevant to them. While the current structure uses a confirmation system to indicate when a message is received, sometimes a message is not blocked by other noise in the environment, but because they were not parsing the information on the system. Thus, this should reduce the monitoring load on firefighters.
The use of rapid tapping to activate the distress signal is also important. As we described in part 1 of this project, activating the distress signal is difficult in a crisis situation and easy in an unintentional situation, such as while asleep at the fire station. A large button provides an easy target in a fire situation. Unfortunately, a large button will also get hit frequently. Rapid tapping, however, is far less likely to occur accidentally, but can be easily performed while suited in full fire gear. Additionally, rapid tapping tends to be a natural action in a distress situation.
Design Scenario: Under Captain Sulu’s Command
Captain Sulu is the sector 2 chief in a 3-alarm structural fire at a high school. He reports to the ground control officer and has 3 engine crews and one ladder team under his responsibility. He hears on his radio: “Sector 2 this is fire ground control. We need you to contain the fire from spreading into the gymnasium area. Over.” Then, Captain Sulu looks at his wrist channel. He sees that he currently has the first and second buttons selected and flashing, indicating that his communication lines are currently directed toward the first and second group. Sulu presses the flashing first and second buttons to deselect them and then presses the up button to speak to his commanding officer. He, then, holds down the button on his microphone saying, “Ground control this is sector 2. Roger on the gymnasium fire containment, over.” One of his engine crews (#2 on his wrist controller) is already putting water on the fire on the east side of the building trying to keep it from spreading further. So, he presses the up button to cancel speaking “up”, then presses the first button to speak to the first engine crew and tells them to concentrate their water stream on the same location as the second crew. He decides to leave the third engine crew to run a check through the gymnasium area, so he sends a message to them telling them to check the bottom floor of the gymnasium for any survivors and to get those individuals evacuated. Then, he orders the ladder team to go to the other side of the building and set up a fan on the hallway before the gymnasium in order to block the fire’s progression.
A few moments after giving the orders, the ladder team frantically radios in reporting that the fire has extended on the other side of the building more rapidly than expected and that it is spreading across the roof of the gymnasium. Mr. Sulu for a moment becomes frantic and forgets which button correlates to which group, so to ensure that his message goes through, he presses all the buttons 1-4 and says: “Engine team 3, this is sector command, pull out of the building, the fire has spread on the west side of the building. Repeat, pull out of the building, over.” Engine team 3 (as well as the rest of the team) receives the message and is able to retreat out of the building with enough warning.
Design Assessment
The “Star Trek” design has many strengths as well as many weaknesses. The major strength of the system is that is supports the current communication structure and that the users must only make slight behavioral modifications to use this system with its increased functionality. The layout of the radio mirrors the current systems and users would not have to grope around to communicate during an emergency. The ability to communicate with subgroups of individuals below you makes that system useful, especially at the higher levels of the command hierarchy.
One of our major goals with the Star Trek system was to eliminate audio clutter received by individuals on the communications system. We feel we have accomplished this with the wrist selection system, but not without consequences. The problem with the wrist communication system is that before communication can be started, the user must select the groups that they are speaking to. We thought this was a minor task, but it is a source of error for individuals will forget what buttons correspond to what groups and will forget that some buttons have already been pressed resulting in communication going to the incorrect groups. Looking at it from the original system, where all communication goes to all the groups, this does not seem like a weakness. It may be a problem when users become acclimated to the system and believe that every communication that they receive is directed toward them. If the users continue to use the standard format[6] then that will eliminate some of the misunderstanding. If the receiver somehow misses the header of the message, they may become confused and try to communicate with the sender of the message creating more radio clutter.
A problem with the Star Trek system that we had a hunch about and the firemen confirmed our fears is the lack of peripheral information. We believed while designing the system that we should strictly reinforce the command structure and that the only information that groups needed was what their commanding officer gave them. In hindsight, this was very poor design because there is no way that the officer could understand all the situations that each group was in and he/she would have to convey the same repetitive information to various groups, a task that humans do not perform well. For example, if two low-level groups (a ladder and engine crew) are working on the same area of different floors and the ladder group radios to their commander that they cannot cut a hole in the ceiling because the fire has spread over their heads. An engine crew further down in the building now knows that their lives are in danger and can react accordingly. The ability to get this information to the needed party quickly becomes difficult when you consider the time delay of going through the hierarchy. If that communication has to go through 2 levels of the hierarchy, it is questionable if the message would get to the firemen who need it.
Another hierarchy misunderstanding that made it’s way into design was the believe that all communication was vertical, units talked to their superior officers or to the men under them, never to other groups at the same level. The firemen quickly corrected this assumption. The current half-duplex communication system and our “Star Trek” system, in general, excel at giving orders and responding to orders, but are poor in dealing with the context heavy communication done within the lower-level groups for accomplishing tasks. The lower-level communication usually occurs through the command hierarchy, but can be in concert with a larger set of groups. This current design does not include the ability to communicate laterally.
We believe that the Star Trek system would be most effective in crises that currently have high information clutter. Situations that have high information clutter are large-scale crises with multiple levels of hierarchy. In situations that have even a two level hierarchy, the original radio may perform better.
Design 3: The “Chat Room” Personal Communication System
Description
The idea behind this system is to move away from the existing strict one-way (half-duplex) communication and toward a more open system in which firefighters can communicate in a more conversational style – a full-duplex system. Under the “Chat Room” metaphor, users are grouped into “rooms” and anyone in a room may talk to everyone else in that room without the possibility of being cut off or cutting someone else off. At the lowest level of the command hierarchy, i.e. the companies, all four firefighters in each company are in the same chat room—they may communicate freely. Of course, this means that all firefighters have radios in this system. Above them, the commanding officers are in their own individual rooms.
To communicate up or down the hierarchy, individuals must essentially change their room. This is accomplished via a voice-command system designed to recognize and respond to a limited set of keywords. For example, a firefighter may issue the command “CommSys: Fire Ground Command, this is ECO1; we need more water in sector C.” The system understands the self-identifying keyword “CommSys” as well as the specification of the endpoints of the communication. It then changes the room of the individual in Engine Company 1 to that of Fire Ground Command so the rest of the message reaches its intended target. In this example, the Fire Ground Commander would hear: “This is ECO1; we need more water in sector C.” When this conversation is over, another command returns the user to his default room. Distress is also signaled via a voice command. Of course, this is in addition to the PASS devices and the physical activation of distress signals. Obviously, the choice of proper keywords is a deep issue, and has only been addressed in passing during our discussions.
Figure 4: "Chat Room" Personal Communication System
Figure 5: Headphones and Throat Microphone
In addition to the PASS device, the gear worn by the firefighters consists of a throat microphone and headphones over the ears, both connected to a radio transceiver most likely worn on the belt or strapped to the midsection of the body. See Figure 4. The headphones have a special feature in which they isolate the wearer from environmental sound. See Figure 5. The sound is mixed with incoming radio transmissions and the volume of each may be adjusted via a dial on the transceiver[7]. Should the mixer fail, this feature can be mechanically disabled, once again directly connecting the firefighter to sound in his environment. Similarly, the throat microphone may be switched off if necessary.
Rationale
The half-duplex nature of the existing system is believed to be a hindrance. The new system completely removes this limitation in favor of more natural communication between and among users, especially those at the lowest level of the command hierarchy. Everyone in the same room can be heard, so there is less chance of vital information being lost because of excessive radio traffic. Another benefit of this system is that it is completely hands-free. Under normal operation, the system needs no tactile input because it is controlled with voice commands. The fact that everyone in a company has a radio has two additional benefits:
- Anyone may call up to his commander rather than going through a single point man; and,
- There is no longer a need to yell or wear voice amplification boxes.
Design Scenario
Engine Company 1 (ECO1), consisting of Jim, Paul, Russ, and Scott has been hosing down the third floor of a burning office building and searching for survivors. Visibility is low, so they each grasp the hose they are carrying to stay together. Jim, ahead of the others, hears a crash in the next room, but doesn’t know what caused it. He decides to check it out, and informs the others by simply talking. Each member of the team utters his agreement immediately.
Jim then says, “CommSys: Sector Chief, this is ECO1; we are moving into sector E.” The communication system, recognizing the command, places Jim in the room with his Sector Chief, Beth, and she hears that ECO1 is moving. Just as Jim is about to return to his own room, Gregory from Ladder Company 3 (on the roof) enters the room. Breathless, he announces that they were not able to put out the fire in time and the roof over sector E is about to collapse. Normally, Beth would have immediately called down to ECO1 to tell them to get out, but since Jim was still in the room with her, he overheard Gregory’s message.
Frantic, Jim yells, “Get out now!” to his company, but he has forgotten to end the conversation – he is still in the room with Joanna, and she quickly informs him of this fact. Jim says “CommSys: Return.” Now back in his room, Jim and the rest of ECO1 narrowly escape with their lives. Joanna, in the meantime, has called up to her commanding officer to request that another ladder company be assigned to Sector E.
Design Assessment
One obvious problem with this system is the unreliability of voice recognition in stressful situations. Hopefully, the set of keywords recognized by the system can be limited enough that recognition will always work, but this must be rigorously tested under real conditions.
Another issue is the modality problem introduced by the chat room. The user is provided no visual feedback indicating to whom he is currently talking. This could be a serious problem, as indicated in the scenario above.
In talking with the firefighters, we were informed of another problem: our rationale is inherently flawed – half-duplex communication is not always bad! While the new system benefits the firefighters at the lowest level of the command hierarchy tremendously, it can be a problem for people higher in the chain of command trying to give orders. In most cases, there is no time to question orders and the existing half-duplex system helps enforce the strict hierarchy. The firefighters felt that this system would work well if it were only applied to the companies of firefighters while keeping a system similar to the existing one for the rest of the hierarchy.
Design Space
Requirements within the Context of Design
The requirements as stated involve some subtleties and are not entirely consistent. This has, of course, led to some tradeoffs. Each of these has engendered considerable discussion during design meetings. For example, a strict adherence to the requirement for Command Hierarchy Support would seem to indicate the desirability of radios that are hardwired to communicate solely with one’s immediate supervisor and subordinates. This, however, would conflict with the modularity aspect of the same requirement since it would be difficult or impossible to insert people into the hierarchy as the incident grows. Some reasonable compromise would need to be struck.
The universality requirement may conflict with the command hierarchy support requirement. The greater number of radios that are present on the fireground, the more opportunity that exists for nonessential traffic that may interfere with the efficient passing of command messages. To some extent, this may be dealt with by limiting the functionality of radios but that may in turn conflict with the safety requirement. Firefighters should listen to the radio traffic for information that may affect the performance of their assignments but this may be difficult to do with limited functionality equipment. This is clearly a sticky design problem.
The use of reserved keywords to enhance the commander’s situational awareness and emergency response leads to a dependence on jargon that can cause problems as well. Some situations require the cooperation of diverse emergency response teams, perhaps the police department from the same city, perhaps a fire department from another city, perhaps even elements of the Federal government. It is unlikely that all these departments would depend on the same jargon and so translation problems may impede communication. The firefighters with whom we spoke have indicated that this is frequently a problem with ex-military firefighters who use a different system of numerical codes. It is difficult to see how to resolve this without a generally agreed upon code system that all departments use. Given the extent to which current methods are entrenched, there is likely to be a degree of resistance to such a change.
Designing a communications system to inhibit out-of-hierarchy messages may conflict with the safety requirement. Some such messages may be necessary to make the incident commander aware of potentially threatening changes in the situation. A balance must be found between limiting unnecessary radio traffic and ensuring that potentially important information is broadcast.
Evolution of Prototypes
Our design discussions centered on understanding the nature of the tradeoffs mentioned above as well as trying to understand the role of metaphors and the way in which existing technology might interfere with our designs.
We had a great deal of difficulty wrapping our minds around the meaning of an audio metaphor. It is not as straightforward as visual metaphors are. For example, the command hierarchy structure kept creeping into the metaphor definitions. While it is important, it is not a metaphor. Since we were having difficulty with this concept, we decided to tackle it first. In the end, it seemed useful to keep the view broad at first and narrow in later. However, it was difficult to keep technology out of that discussion, which would have limited its breadth. We began making progress when we identified “Star Trek” and “Chat Rooms” as sort of polar opposites in the spectrum of possible verbal-communication metaphors. These categories started life as “broadcast” and “conversational” but the more picturesque terms helped us to make the design ideas more specific.
We also spent considerable time debating the relative merits of incremental vs. large-scale change in communications systems. We felt the former would be more acceptable to the firefighters due to its familiarity and obvious usefulness but would limit what we would be able to accomplish, perhaps severely. On the other hand, a larger scale change, which would provide more room for design innovations, would also present knottier integration and acceptability issues. In the end, we did both since we had more than one prototype to play with. Basically, that amounts to a punt but it is a punt with a purpose. Now that we have feedback from the firefighters on our proposals, we can make a more intelligent assessment of the magnitude of acceptable change for the third part of the project.
We also struggled with some technological issues. One of these, the ability to manage virtual one-to-one connections, is discussed in some detail below. Some issues of lesser importance involved multi-modal output and the role of sound as an interface. We briefly debated the merits of tactile output of some sort before rejecting it on the grounds that it would impose to great a cognitive load to interpret the various pokes and prods. This might take attention off the task at hand and might require hands-on use, something we wished to avoid (one of our goals was to make a more hands-free system).
Sound presented some similar issues. The current system requires active filtering on the part of the user to determine whether what the radio is saying is directed to him. One design goal that we settled on was to do our best to create a system in which if your radio is making a noise, that noise is intended for you. Sound as an interface also goes the other way as well. Voice command recognition, an essential part of one of our designs, may be difficult to achieve in the noisy environment of a fire. We believe that this may be resolvable but it was what motivated the choice of a directional, noise-canceling throat mike. In fact, we spent some considerable time debating the relative merits of voice vs. manual activation. In the end, we decided that this was really only a crucial issue for the firefighters on the front line, not so much for the commanders outside who are not actively operating firefighting equipment. After noticing that, we realized that it was not necessary to provide identical radios to every firefighter. Perhaps it would be more useful to tailor the radio, and its interface, differently for different firefighting roles. The firefighters with whom we spoke independently came to this notion as well when they suggested that the “chat room” system was appropriate to the front line guys whereas the “Star Trek” interface was better suited for the guys further up the hierarchy.
The interface of the Star Trek system went through some considerable evolution. It started as a dial for selection but this ended up being cumbersome and potentially threatening. It may be possible to feel four or five independent dial positions for speaking to specific individuals. However, we soon realized that new positions would have to be added to accommodate the various combinations in which the user might wish to speak to more than one person at a time. This presented two distasteful alternatives: make it necessary to take your attention off what you are doing to see where the dial is pointed, or eliminate the combination possibilities and make it necessary to repeat a message multiple times. This led to the button interface, which seems to be a great deal simpler and could even be navigated by touch if necessary. We settled on toggle buttons so that the user would not have to hold down awkward combinations while speaking to several persons.
After beating our heads against all the sorts of issues in designing the “Star Trek” system, devising the “chat” system was much easier. We found that we had already settled most of the difficult conceptual issues. Primarily, it was a matter of adapting those concepts to see how they would be expressed physically in the “chat” context. For example, we did not have to resettle all the requirements tradeoffs nor did we have to reconsider how to embed the command hierarchy in the system.
Important Underlying Technology
Many of the designs we have considered rely upon managing one-to-one and one-to-many communications on the fly. This requires some mechanism for establishing and breaking connections during conversations, similar to telephone switching, and so it seems desirable to spend a moment showing that this can be accomplished.
There are in fact several systems that may accomplish this, some existing and some in the pipeline. One example draws on telephone switching ideas to create a “trunk line” out of a set of radio channels. The basic idea is to reserve one channel for data transmission and the rest for voice. All radios receive all channels but the user only hears the one that his radio has be instructed to listen to on the data channel and similarly for transmission. At any moment, then, a conversation may switch to any clear channel without interruption since the relevant radios automatically switch when instructed to on the data channel. Conversations migrate around through these momentarily reserved channels throughout their lifetimes, using whichever one is currently vacant when the speaker starts talking. The data channel may also be used to monitor which radios are currently on the system and pay attention for dropouts. All radios may thus be programmed to speak with any subset of the other radios with such programming being managed on the fly by traffic on the data channel. The 800 MHz band, reserved by the FCC for emergency communications, will in fact only be allocated to departments which use trunking technology.
Another technology, not yet implemented in radio communications but in the pipeline, involves digital encoding similar to network packet management. Encoders arrange the information in such a way that only specific receivers may decode it. Examples include frequency division (for analog signals) and time division (for digital) multiplexing. Another method of encoding that borrows some aspects of trunking technology is called “guarding.” The idea is to note that the frequency range of human speech may be rather severely restricted without affecting audibility. Though humans are sensitive to frequencies up to about 20,000 Hz, the bulk of the important information for speech is within the 300 to 3000 Hz band. Guards are created by using shaper circuits that discard speech frequencies outside this band, creating room for transmission of encoding signals in the resulting gap. If the code is correct, the receiver hears the transmission. If it is incorrect, he does not.
Acknowledgements
We would like to thank the firefighters at the Atlanta Airport Fire Station for their useful feedback in this section of the project. We are grateful to Randy Camp, Stanley Morrow, and Troy McClure (you may remember him from such papers as Fire Fighting: The Lost Art, and Part 1: Defining the Requirements). Finally, we are especially grateful to Jeff Pollard for the countless hours that he has spent explaining firefighting to us, reading (and re-reading) our ideas, and helping us to further those ideas. Without him, progress in this project would be impossible.