Telecommunications Input and Output

Pattern Language
Robert Hanmer
Lucent Technologies
hanmer@lucent.com
2000 North Naperville Road
PO Bo !0!!
Naperville" #L $0%$$&'0!!
voice( $!0 )')&*'+$
,reg -t.m/al
0, 1ommunications -.stems
st.m/alg@agcs.com
2%00 2topia 3rive
PO Bo %24')
Phoeni" 05 +%0'2&24')
voice( $02 %+2&'4!+
1op.right6c7 4))+. Lucent Technologies and 0, 1ommunications -.stems. 0ll Rights Reserved.
Permission is granted to cop. /or the purposes o/ PLoP&)+.
Introduction
0 speciali8ed set o/ patterns /or de/ining the human&machine inter/ace has come into use 9ithin
the 9orld o/ telecommunications s9itching products. The patterns presented here provide /or the
essential interaction bet9een a s.stem and its human masters. -everal o/ the patterns discuss
concepts speci/ic to a telecommunications s.stem" but most are general enough to provide
insight /or an.one designing the #nput:Output 6;#:O<7 inter/ace /or a large s.stem.
This paper begins b. discussing the environment 9ithin 9hich these patterns are applicable.
T9o di//erent methods o/ visuali8ing the overall structure o/ this language are then presented"
one graphical and the other in the /orm o/ pattern groupings b. related topics. The patterns are
then introduced. -upplemental material includes thumbnail s=etches o/ several patterns
re/erenced /re>uentl..
Background
The environment 9ithin 9hich telecommunications s9itching e>uipment is installed is di//erent
than that o/ a traditional computing center. This section describes some o/ these di//erences.
These di//erences constitute much o/ the common contet 9ithin 9hich these patterns are use/ul.
0 =e. di//erence bet9een the input output o/ a telecommunications s.stem and a general
computer is that the #:O o/ a telephone s9itching s.stem is purel. secondar. to its main purpose.
0 general computer might be speciali8ed to a special /unction" such as processing mathematical
e>uations >uic=l." but the results still must proceed through the #nput:Output channel. This is not
the case in a s9itching s.stem. These s.stems are designed to manage speciali8ed hard9are to
connect 6s9itch7 di//erent telephone lines. This /unction does not re>uire 1RTs" paper printers"
=e.boards" mice or magnetic tape.
0nother =e. di//erence is the multitude o/ 9or=ers that are responsible /or s.stem maintenance
and administration. This ?On&-ite @or=/orce? 6O-@A7 can be grouped into several di//erent
communities o/ interest 6BHCC-DE" B,HHCE" B,HR-E7(
Those concerned 9ith the maintenance o/ the machine. This communit. has a 9or=center
called the ?Faintenance Operations 1enter? 6FO17.
40:44:4* 4
Those concerned 9ith administrating the machine. Their 9or=center is called the
?Faintenance 0dministration 1enter? 6F017.
Those concerned 9ith the telephone lines and trun=s connected to the s9itching machine.
The. have t9o 9or=centers in addition to the F01" called the ?Trun= Operations
1enter? 6TO17 and the ?Terminal G>uipment 1enter? 6TG17.
Telephone s9itching s.stems are large. 0 s9itching o//ice serving a cit. center might occup.
several thousand s>uare /eet" and have tens o/ thousands o/ telephone lines and trun=s connected
to it. This leads to the 9or=/orce being a long ph.sical distance /rom the primar. input:output
devices 9hen the. are 9or=ing inside the s.stem. #t also means that to the 9or=/orce having
man. pieces o/ e>uipment that the. are responsible to operate and maintain.
Reliabilit. is a ver. important s.stem capabilit.. Reliabilit. engineers calculated the epected
reliabilit. based upon some predicted ;Fean Time To Repair< 6FTTR7. The time it ta=es /or the
maintenance personnel to respond to a /ailing component is a =e. contributor to this metric. #t is
there/ore ver. important that the maintenance people be in/ormed >uic=l. o/ an. problems. This
reliabilit." 9hich is usuall. a /e9 minutes per o//ice per .ear" also leads the designers to9ards
using custom hard9are and so/t9are especiall. designed to /acilitate reliable s.stems. #n order to
maintain this reliabilit." telephone s9itching s.stems are t.picall. monitored around the cloc= b.
personnel trained and read. to respond to an. emergenc..
2sing custom hard9are and so/t9are usuall. results in the s.stem being behind the leading edge
o/ computer technolog.. @hen the s.stems /rom 9hich these patterns 9ere mined 9ere being
created in the 4)'0Hs their input:output channels 9ere capable o/ being operated at either 440 or
4200 baud. 6 BB3NNDE" pp. 4$)&4'07
0s telephone net9or=s get more complicated" the desire to remotel. monitor and maintain them
has increased. The abilit. to remotel. monitor s.stem operations adds an additional level o/
compleit.. Handling this additional compleit. 9asnHt al9a.s provided /or in the initial designs.
Known Uses
The patterns contained here are the proven practices o/ a number o/ telephone s9itching s.stems
such as the Lucent Technologies 40 G--I local s9itch" the *G--I toll and tandem s9itch also
/rom Lucent Technologies and the 0, 1ommunications -.stems ,T3&%I local s9itch.
40:44:4* 2
Language Map
Groupings of Patterns
These lists divide the patterns up b. /our di//erent /unctional concepts that 9ill be used later as
=e.9ords on each pattern to help the reader understand ho9 the. relate. One pattern" MML,
deals with all four of these topics. The topics are: physical location, the relative importance of
input, the quantity of messages and periods of emergency interaction.
1. Ph.sical LocationsJ -9itching o//ices are large in ph.sical terms. These patterns address the
measures need to be ta=en to mitigate the e//ects o/ large si8e.
Mind Your Own Business Beltline Terminal
seudo !O
40:44:4* !
"larm #rid
Office "larms
$estricted %ommands
&ho "s'ed(
2. Relative Importance o/ #nput J -ome interactions 9ith the s.stem is more important than
others. These patterns describe the measures need to be ta=en to ensure that the important
interactions can happen in a timel. /ashion.
!O Triage
Timestamp
)hut *p and Listen
+on,t Let Them -orget
3. Quantity o/ Fessages J -9itching s.stems are large in terms o/ lines o/ code and
subs.stems" man. 9ill have things to sa. at the same time. These patterns help to manage
the sheer >uantit. o/ messages.
#eorge &ashington !s )till +ead
The Bottom Line
!O Triage
. Minutes of /o 0scalation
Messages
)hut *p and Listen
4. Periods o/ mergency #nteraction J 3uring crisis times special rules should appl.. These
patterns discuss some o/ these special rules as the. impact #nput:Output.
"larm #rid
Office "larms
)tring " &ire
$aw !1O
+on,t Let Them -orget
T!e Patterns"
MML
Ke.9ords( Location" #mportance" Luantit." Gmergenc.
Pro#lem" Ho9 does a person communicate 9ith a large and comple machineM
$onte%t" There are man. di//erent subs.stems that 9ill need to communicate 9ith human
operators and administrators. 0 large volume o/ #:O 9ith man. varied user needs and /unctions is
epected.
&orces( -9itching s.stem so/t9are development 9ill be easier 6/e9er people to coordinate 9ith7
i/ each so/t9are subs.stem de/ined and implemented its o9n input output speci/ications.
3evelopment epense and s.stem architecture 9ill be more streamlined i/ the di//erent
subs.stems de/ine input output languages to a common speci/ication.
0t least one third o/ errors are due to human operator error. 6The other t9o thirds being hard9are
and so/t9are.7 0n. simple steps that can be done to reduce the man&machine input output
s.stemHs contribution to this statistic 9ill be bene/icial.
'olution" 2se a standard messaging /ormat. FFL 6Fan&Fachine Language" 9hich is a 11#TT
standard7 and the P3- 6Program 3ocumentation -tandard7 are t9o eamples. This allo9s the
s.stem to be consistent 9hen reporting problems in di//erent parts o/ the s.stem. #t also allo9s
40:44:4* *
humans to become /amiliar 9ith the /ormat o/ messages and thus simpli/ies learning.
(esulting $onte%t" 0 large volume o/ #:O 9ith man. varied users needs and /unctions using a
standard language:/ormat 9ill be given a consistenc. to help users. Fechanisms to deal 9ith the
large volume o/ input and output are needed" such as Bottom Line and #eorge &ashington is )till
+ead.
0lso since the s.stem is >uite large" there might be man. di//erent users each tr.ing to interact
9ith the s.stem. To =eep things straight" a pattern such as Mind Your Own Business and !O
Triage are use/ul.
-ometimes" especiall. to save human resources a computer s.stem might be created to monitor
the s.stem. #n man. cases a custom inter/ace can be created to /acilitate the computer to
computer communications. -ometimes this etra overhead is too much and a pattern such as
seudo2!O helps b. having the monitoring computer use the FFL messages intended /or
humans.
There might not be people 9atching the s.stem all the time" so some alternative method o/
alerting them to problems is re>uired. "larm #rid describes a method.
(eference" B1A,LRE" pp. 2*%&2*$.
Mind )our Own Business
Ke.9ords( Location
$onte%t" There is a standard input and output messaging language 6MML7 de/ined /or the 9hole
s.stem. This implies that there 9ill be some /rame9or= 9ithin the s.stem to that supports all
#:O" consolidating messages /rom ever. part o/ the s.stem into a single uni/ied output.
Pro#lem" But i/ the output is all derived /rom a single subs.stem" 9ho should see itM
&orces( Onl. a small number o/ the 9or=ers need to see an. particular output. Aor eample the
people in the Faintenance Operations 1enter 6FO17 donHt need to see messages about the
progress o/ a Recent 1hange 6database update7 transaction.
The s.stem shouldnHt con/use the 9or=ers b. presenting in/ormation that the. donHt =no9 ho9 to
use.
The volume o/ messages that are possible /rom a large s.stem is enormous. #/ it 9ere all to be
dumped to one terminal it 9ould be net to impossible /or the 9or=ers to /ind the in/ormation
that the. need.
0ccess control is enhanced i/ the t.pe o/ in/ormation a particular terminal receives is changed
through simple 9iring con/igurations 6i.e. 9hich terminal plugs in 9here7.
Are>uentl. the entities 9atching the outputs are not human" but are other computer s.stems. But
these s.stems are still onl. interested in a small part o/ the possible output" so speciali8ation is
still use/ul.
Fuch o/ the in/ormation that the s.stem presents to the 9or=ers is routine and not related to an.
particular user that ma. or ma. not be logged in at an. one time.
The primar. output devices in a maintenance center should al9a.s receive output" even i/ no one
40:44:4* %
is logged on.
'olution" 3e/ine di//erent output classi/ications. Far= di//erent terminal:console connections to
onl. receive output /or some classi/ications. These are called ?logical channels?. The s.stem
sends messages onl. to the communit. o/ users that is interested in them. This results in labor
savings && 9or=ers donHt need to 9ade through the output to /ind the messages that the. are
interested in.
(esulting $onte%t" 0 large volume o/ #:O is reduced on an. one channel b. distributed it b.
/unction. -ome users move around and might still need to see the output. Beltline Terminals
addresses this b. providing the abilit. to redirect output to a di//erent output device.
B. centrali8ing output processing 6see !O Triage7" the categories and logical channels can be
used to send output to the right place as in &ho "s'ed(.
$estricted %ommands are use/ul because some o/ the 9or=ers at some logical channels might be
/amiliar onl. 9ith their Nob /unction and not 9ith the entire range o/ s.stem capabilities. This
could lead to inadvertentl. entering a message that results in s.stem degradation.
(eference" B1A,LRE" pp. 2*%&2*$.
IO Triage
Ke.9ords( Luantit." #mportance
Pro#lem" #mportant in/ormation is hidden or dela.ed b. less important in/ormation.
$onte%t( 0 large volume o/ #:O is still presented to the 9or=ers 6even a/ter appl.ing the message
reduction patterns #eorge &ashington !s )till +ead and The Bottom Line7. The #:O message
stream is standardi8ed 6MML7.
&orces( Too much in/ormation deadens the 9or=ers.
#n/ormation about a critical situation 6/or eample all the telephone lines going out o/ service" or
a critical piece o/ the s.stem hard9are /ailing7 needs to be issued as soon as it is detected to
allo9 the 9or=ers to repair it.
#n/ormation that reports trivial things can be de/erred to displa. a/ter the important in/ormation
is presented.
'olution" Tag messages 9ith a priorit. classi/ication. The input:output so/t9are should be
designed to epedite the presentation o/ the higher priorit. message" putting them on the output
device be/ore a message o/ a lo9er priorit.. 0 consistent de/inition o/ the di//erent priorities is
re>uired. One such de/inition is this(
1R#T#10L( The o//ice cannot per/orm its re>uired actions to process telephone calls.
F0COR( The s.stem is in a state that one more /ailure 9ill result in a 1R#T#10L loss o/
service.
F#NOR( 0 small portion o/ the s.stem is in trouble. The s.stem is more than one /ailure
a9a. /rom a lac= o/ service.
F0N20L( -.stem responses to human input.
40:44:4* $
#n/ormational( The s.stem is behaving normall..
(esulting $onte%t" This pattern leads to the most important in/ormation coming out /irst"
/ollo9ed b. possibl. >uite old less important in/ormation. This necessitates a gate=eeping
/unctionalit. in the s.stem to prepare the messages /or displa. in the desired order. -ome sort o/
timestamping or message se>uence tagging is needed to /acilitate a complete understanding o/
the s.stem state 6see Timestamp7.
Output messages are sometimes re/erred to as ?0ction Fessages? because the. re>uire some
action on the part o/ the local 9or=/orce.
Aive levels o/ output message are used because conventional 9isdom is that humans 9or= best
9ith /ive D:& t9o things.
Timestamp
Ke.9ords( #mportance
Pro#lem" Ho9 do 9or=ers provide some sense to seemingl. random order o/ outputM
$onte%t" !O Triage has been applied. Fessages ma. not come out in the order that parts o/ the
s.stem re>uest that the. be printed.
&orces" -ome problems that are reported in the #:O stream are di//icult to anal.8e. Little clues
might be important and the order in 9hich things happen can be important 9hen anal.8ing
output. Gspeciall. 9hen tr.ing to decipher near coincident /ailures. That in/ormational message
printed /ive minutes ago might contain the essential clue to help 9ith the critical message printed
/i/teen minutes ago.
Time 9ithin a computer s.stem is di//erent than time to humans. 0 timestamp 9ith Nust the
minutes and seconds might hide details /rom the millisecond time period.
-ince there is some gate=eeper 6implied b. !O Triage7 it could per/orm a little etra processing
and tag messages 9ith some help/ul in/ormation.
'olution" 0ppl. a se>uence number to all messages 9hen the gate=eeper receives them. That
9ill help identi/. message ordering.
-ince humans li=e to 9or= 9ith a time base" also displa. the current time on messages. ?1urrent<
means 9hen the message 9as sent to the gate=eeper. #/ the message printing time is also
displa.ed" the di//erence in times can provide a valuable clue to the anal.st.
*!o +sked,
Ke.9ords( Location
Pro#lem" @hat logical channel receives the results o/ a speci/ic manual input re>uest. Lots o/
terminals" lots o/ terminal classi/ications" man. users" do the. all see m. messagesM
$onte%t( 0 9or=er usuall. onl. uses one terminal at a time. Mind Your Own Business has
resulted in the #:O stream being divided into di//erent logical channels. 3ue to !O Triage having
been applied" output is centrali8ed /or the prioriti8ation b. some gate=eeper /unction.
&orces( Oou could broadcast the ans9er to ever.one. But that 9ould con/use the 9or=ers that
40:44:4* '
have no idea about that /unction 6i.e. maintenance 9or=ers seeing recent change output7. #t also
pollutes the output channels 9ith etraneous in/ormation" resulting in desired in/ormation being
s9amped.
There is a class o/ 9or=ers that has primar. responsibilit. /or the correct /unctioning o/ the
s.stem. These 9or=ers should be =ept in/ormed" to some degree" o/ 9hat the other communities
o/ 9or=ers are doing.
'olution" 3ispla. the output related to a speci/ic input re>uest primaril. to the logical channel
that made the re>uest. Oou might 9ant to put it on an additional channel to allo9 /or logging or
oversight b. a ?super user?.
(esulting $onte%t( -ometimes important in/ormation 9ill need to be displa.ed at the primar.
maintenance terminal" so that the people most responsible /or the correct /unctioning o/ the
s.stem see it.
B. tagging the message as Fanual to indicate it is a direct response to an input message 6see !O
Triage7" the message 9onHt be misunderstood as being a spontaneous s.stem output.
This pattern is the output converse /or $estricted %ommands.
(eference" B1A,LRE" pp. 2*%&2*$.
George *as!ington is 'till -ead
Ke.9ords( Luantit.
Pro#lem" Ho9 can the output be =ept /ree /rom too man. messages sa.ing the same thingM
$onte%t" -ometimes the s.stem needs to output reports about the state o/ the machine. @hile a
particular problem might be detected hundreds o/ times 6as in The Bottom Line7" i/ the state isnHt
changing /re>uentl. the messages might be over=ill. Aor eample" i/ hundreds o/ trun=s go out o/
service" the o//ice ?condition? might change 9hen the /irst one trun= goes out o/ service" and
then not change again until the 404st trun= goes out o/ service.
&orces( 3ispla.ing the status o/ the o//ice ?condition? /or each ne9 trun= out o/ service report
/rom the second to 400th trun= is too much in/ormation. There isnHt reall. that much change to
re>uire a ne9 report.
Too much in/ormation deadens the 9or=ers.
The /act that the o//ice state or ?condition? is being changed is the real in/ormation that the
9or=ers need to =no9.
'olution" Onl. displa. messages that report a change in state. 3onHt report them each time the
alarmed state is detected.
(esulting $onte%t( Redundancies 9ill be removed /rom an other9ise large volume o/ #:O.
-ometimes there are no actions that the 9or=ers can per/orm in response to a change in s.stem
state. #t is in these circumstances that the -ive Minutes of /o 0scalation Messages pattern
applies.
The reports o/ state changes are important" so some method o/ reporting them is re>uired. !O
Triage is needed to =eep the important in/ormation coming out even 9hen the output channels
40:44:4* +
are /looded.
Gven 9ith the reduction in messages /rom appl.ing this pattern" a mechanism to ensure that
humans are able to input a message against a /lood o/ output is re>uired. )hut *p and Listen
addresses this problem.
T!e Bottom Line
Ke.9ords( Luantit.
Pro#lem" Fan. messages are about the same t.pe o/ event 6such as a trun= going out o/ service7
and the. /lood the output message stream.
$onte%t( 1ertain circumstances result in man." man. reports. Aor eample" i/ a part o/ the
s.stem inter/acing to hundreds o/ trun=s has Nust gone out o/ service" a message reporting that a
trun= is out o/ service might displa. hundreds o/ reports" one /or each trun=. This pattern applies
to the places 9here a report should be generated because some condition has Nust been detected.
&orces( Outputting a report 9hen ever. event happens pollutes the output channels" diverting
attention /rom other activities. Gven 9ith a priorit. output s.stem in place 6see !O Triage7" the
channel can become /ull and important output or input 6see )hut *p and Listen7 can be missed.
-ometimes reporting o/ man. events gives the 9or=ers an idea o/ a trend" but this in/ormation
can be given man. times" or as a single message reporting man. events.
'olution" ,roup messages about a common event and onl. displa. a summar. message that
includes a tall. o/ the number o/ occurrences.
(esulting $onte%t" The s.stem should also provide a 9a. to provide the entire output at human
re>uest" as it ma. be essential to identi/. problems.
Gven 9ith the reduction in messages /rom appl.ing this pattern" a mechanism to ensure that
humans are able to input a message against a /lood o/ output is re>uired. )hut *p and Listen
addresses this problem.
This pattern relies upon the developers o/ the individual subs.stems. #t is their responsibilit. to
per/orm the summari8ation o/ messages.
&i.e Minutes of /o scalation Messages
Ke.9ords( Luantit.
Pro#lem" Rolling in console messages( the human&machine inter/ace is saturated 9ith error
reports that ma. be rolling o// the screen" or consuming resources Nust to displa. the messages.
$onte%t( 0n. continuous&running" /ault&tolerant s.stem 9ith escalation" 9here transient
conditions ma. be present. The transient nature produces copious messages even 9ith summar.
and priorit. /ilters 6The Bottom Line, #eorge &ashington is )till +ead, !O Triage7.
&orces( There is no sense in 9asting time or reducing level o/ service tr.ing to solve a problem
that 9ill go a9a. b. itsel/.
Fan. problems 9or= themselves out" given time.
Oou donHt 9ant the s9itch using all o/ its resources displa.ing messages.
40:44:4* )
Oou donHt 9ant to panic the user b. ma=ing them thin= the s9itch is out o/ control 6Minimi3e
4uman !ntervention BPLOP3&2E7.
The onl. user action related to the escalation messages ma. be inappropriate to the goal o/
preserving s.stem sanit..
There are other computer s.stems monitoring the actions ta=en. These s.stems can deal 9ith a
great volume o/ messages.
'olution( @hen ta=ing the /irst action do9n a scenario that could lead to an ecess number o/
messages" displa. a message. Then periodicall. displa. an update message. #/ the abnormal
condition ends" displa. a message that ever.thing is bac= to normal. 3o not displa. a message
/or ever. change in state.
1ontinue continuous machine to machine communication o/ status and actions throughout this
period.
#/ something is so important that it canHt 9ait /ive minutes" the "larm #rid should report it.
(esulting $onte%t( This solution 9ill =eep the s.stem operator /rom panic=ing /rom seeing too
man. messages. Fachine to machine messages and measurements 9ill =eep a record /or later
evaluation as 9ell as =eeping the s.stems actions visible to people 9ho can deal 9ith it.
Other messages that are not related to the escalating situation that is producing too man.
messages 9ill be displa.ed as though the s.stem 9ere normal. Thus the volume o/ escalation
messages does not adversel. a//ect the normal /unctioning o/ the s.stem.
Note the con/lict 9ith eople 5now Best BPLOP3&2E in which humans should 6e 'ept thoroughly
informed of system progress.
Shut Up and Listen
5eywords: 7uantity, !mportance
Problem: 4umans need to 6e heard 6y the system.
Context: " priority scheme for message output is in place 8see !O Triage9. This will get the most
important information out to the wor'ers first. !t doesn,t address humans ta'ing control and
altering system 6ehavior. The eople 5now Best :LO+2;< pattern discusses that even when
the system is designed to correct pro6lems automatically e=perts will sometimes 6e a6le to help
the system through >stressful> incidents.
)ometimes, even though #eorge &ashington !s )till +ead and The Bottom Line are applied, the
output stream is still flooded.
Forces: The system output stream is 6usy with 6oth priority messages reporting some a6normal
event, and informational messages. *sers need a way to shut the output stream off. But if they
shut it off, important information might 6e missed. !f they wait until the outputting is completed
the system might 6e in a degraded service mode. Then again, in some circumstances the output
stream may 6e perpetually flooded.
-ull +uple= input1output might help, 6ut that has pro6lems of message interpretation 6eing
made more difficult. !f half duple= is chosen some way of interrupting the output is necessary.
40:44:4* 40
Solution: #ive a higher priority to recogni3ing human input commands than is given to display
more output information. rovide the system with a way to ma'e sure that input messages are
processed even when the output system is operating at full capacity. Mar' the output related to
human input messages at priority level compara6le with %$!T!%"L output messages priority
8see !O Triage9 so that their responses are not stuc' at the end of the output message queue.
Resulting Context: 4uman requests 8input messages9 will 6e heard even though the output
6uffer is full. Both !nput and Output messages are prioriti3ed.
4uman input messages are all treated as 6eing at the same priority level. " separate input
mechanism 8such as a Master %ontrol %onsole9 that 6ypasses the !1O su6system is provided for
high priority input.
Restricted Commands
5eywords: Location
Problem: 4ow should the system 6e protected from malicious or naive users(
Context: )ome input messages can disrupt the system very dramatically. The system has many
input commands? many are quite similar to others. There are also different categories of users
that have a need to input different commands 8Mind Your Own Business9. 0ach user category
has its own su6set.
Forces: )ome commands could result in disastrous results, such as reducing call handling
capa6ility or causing some unnecessary and time2consuming recovery action.
There are some users, who have a certain terminal assigned to them 8&ho as'ed(9, that 'now
what is safe and what is not. They can 6e trusted.
Solution: $estrict certain 'ey input to the primary terminal of a given classification.
This will provide additional tracing for the command and will put the 'nowledge that it was
e=ecuted into the hands of the system e=perts, rather than the person who only 'nows a6out a
small part of the system.
Pseudo-IO
5eywords: Location
Problem: This is a 6ig system and sometimes one su6system will provide a way to access certain
information for humans. /ow another su6system needs this same information also.
Context: The system is large and has several su6systems. The !1O su6system is one that
processes individually 6uffered messages and distri6utes them to the appropriate su6system to
handle them. !1O that used to go only from machine to human now must also go from machine to
machine.
The system has many logical !1O channels. 8Mind Your Own Business9 There is some gate'eeper
function, introduced 6y !O Triage, which will mar' priorities on the messages as well.
Forces: " new machine to machine interface, with all of its inherent comple=ities, could 6e
defined 8in addition to the human interface9 or...
40:44:4* 44
Solution: rovide a way for one su6system to insert a message into the input message stream for
the other su6system. !n other words, allow the system itself to create a message that is processed
@ust li'e any other input message.
Resulting Context: This provides a system that ma'es it easy to add new capa6ilities and to
connect them to already present input1output services.
/ote the difference 6etween this pattern and )tring " &ire that deals with informing monitoring
systems of the system state during emergencies.
Beltline erminal
5eywords: Location
Problem: The terminal isn,t where the wor'er needs to 6e to do their wor'.
Context: " large volume of !1O distri6uted 6y function. )ome wor'ers move around in the office.
&ith the si3e of the system measured in floor space, they might 6e a long way from their
maintenance terminal when they want to enter or see some messages related to what they are
doing. 8e.g. they might 6e changing circuit pac's9. %ertain terminals are dedicated for these
wor'ers. 8)ee Mind Your Own Business.9
-or many years within a telephone office there have 6een @ac's to plug in audio headsets to
allow the wor'ers to tal' with other wor'ers.
Forces: $educed la6or costs1higher productivity if the wor'er doesn,t need to continually go for
long wal's to use a terminal.
$educed possi6ility of accidentally damaging something 6y frequent traversals of the office to
reach the terminal.
!ncreased system relia6ility if the wor'er can attend to their wor' quic'ly. The long wal's to the
terminal area increase the Mean Time To $epair 8MTT$9.
The system is already physically large, with many wires. The system is mounted in custom
ca6inets with custom wiring. "dding a few additional wires around the office to allow the
wor'ers to plug in a terminal 8in addition to audio headsets9 is a minor e=pense.
Solution: rovide remote terminal connections out in the aisles with the equipment so that the
wor'er can plug in a terminal input1output device anywhere they want. This is called a >6eltline
terminal>. "lso provide the a6ility for the wor'er to redirect 8copy9 the output of the desired
logical channel to that remote terminal.
Resulting Context: The wor'ers can move around the office and can ta'e their terminal with
them. This helps increase productivity and system relia6ility and reduce MTT$. The typical
configuration of a 6eltline terminal is an ordinary display device, such as a ATBCCD terminal,
on a cart.
Re!erence: BHCC-DE" p. 40%0
"larm #rid
5eywords: Location, 0mergency
40:44:4* 42
Problem: 4ow can we get information to wor'ers immediately when a significant pro6lem has
occurred(
Context: )ome things are too important to wait for a potentially slow !1O system to process and
to wait for some human to notice and read. eople 5now Best :LO+2;< requires that humans
and support systems monitoring the system have full information a6out its state. +ue to the
comple=ity of the input1output system the overhead to perform the standard !1O cannot 6e
afforded in all circumstances, so MML does not apply. The time to 6egin the correct remedial
action has a contri6ution towards the Mean Time to $epair 8MTT$9, which in turn has an impact
on the system,s overall relia6ility.
Forces: !n a large office a simple message on one or several terminals might go unnoticed 6y
the office personnel that are needed to handle the pro6lem. This can lead to service 6eing
impacted longer than is a6solutely necessary.
The !1O system has a lower processing priority than the systems that ensure that the system is
sane and functioning normally. &e cannot count on the !1O system 6eing e=ecuted in a timely
manner during times of crisis. This can delay processing for a long time in a system that is
trying to recover from catastrophes.
+uring crisis situations the humans are pro6a6ly loo'ing elsewhere and they will not see a
report on a terminal.
Solution: rovide a speciali3ed alarming system. On this alarm >grid>, alert all concerned
personnel via audio and visual mechanisms that there is a pro6lem.
This alarm grid will provide an interface to the human operators that parallels the interface
provided 6y the !1O system. )ince it is in parallel, it will provide the operators with information
that they might not get through the !1O system in a timely manner.
By 6rea'ing the equipment into different categories, the alarm grids can 6e refined to report
pro6lems within certain communities only. This is similar to the logical channel concept of Mind
Your Own Business. The different grids can 6e grouped together to report larger com6ined
events during off2hours, when fewer people are watching the system.
Resulting Context: riority messages will 6e presented to personnel in a way that stimulates
three of the five senses.
The specification of the alarmed items is usually done at design time. )ince these are 6ig
systems that may vary su6tly from office to office some method of customi3ing to a specific
customer site is desira6le. )ee Office "larms.
The system should 6e one that will have a low pro6a6ility of failure. The hardware should 6e
designed to have few failure points and to use relia6le components. "nother consideration in the
hardware design is to ma'e the system >toothpic' proof>. This refers to the ease that office
personnel can disa6le a part of the system 6y inserting a toothpic' into the appropriate relay
contact to prevent closure.
!n the area of the "larm #rid the usual principle of >failing silently> may not apply. !f the alarm
grid itself is to fail, having it report its own failure is a desira6le event.
The alarm grid will typically 6e presented 6oth locally at the switching office and to some
remote monitoring location.
40:44:4* 4!
Re!erence: BHCC-DE" p. 40%4.
O!!ice "larms
5eywords: Location, 0mergency
Problem: 4ow can pro6lems that are unique to a particular field site 6e integrated into the pre2
defined classification of messages( +ifferent sites might have custom alarming requirements,
such as door loc's, speciali3ed "1%, coffeepots, related systems, etc.
Context: riority messages have visual and audio alarms from the "larm #rid.
Forces: You could define a separate, parallel interface for site specific alarms. That could
introduce confusion, as the user interface would pro6a6ly not 6e identical to the standard user
interface.
The actual interface and system actions when the alarm is >fired> could 6e transparent and
indistinguisha6le from the 6ase generic supplied alarms. This will help avoid user errors and
potential outages 6ased upon failure to act on stimuli.
"larming some things and not others results in not 6eing given the importance that they should.
The designers and equipment manufacturers can,t foresee every unique office configuration
containing conditions that need to 6e alarmed. The customers pro6a6ly don,t want to pay for
such thoroughness either.
#ood user interface design has similar things 6ehaving in li'e manners.
Solution: "llow the seamless definition of >office alarms>. )ite specific alarming should 6e
facilitated through whatever speciali3ed definition mechanism is required.
"dding a new alarm to an e=isting "larm #rid is an e=ample of the +ecorator pattern from the
B,OAE.
Resulting Context: Both generic priority messages and site specific events have visual and
audio alarms.
This provides a measure of >customer programma6ility> to the office. They may tailor at least
this small part to their own corporate operating policies.
$on%t Let hem Forget
5eywords: !mportance, 0mergency
Problem: 4ow long should the manual action of silencing the alarms 6e remem6ered 6y the
system( )hould it reassert alarms immediately, or 'eep them quieted for some pre2determined
length of time(
Context: The alarm grid can 6e very annoying, leading wor'ers to want to silence and ignore
them. " system in trou6le can have many alarms asserted simultaneously. )ometimes the noise
can 6e overwhelming and distracting to the wor'ers.
Forces: )ome mechanism to silence the alarms is desira6le to provide some quiet for thought.
!f the system is in trou6le the a6ility to function properly may 6e compromised if alarms aren,t
reported promptly. This can lengthen Mean Time to $epair.
40:44:4* 4*
!gnoring the manual action to silence alarms will 6e annoying and distracting to the wor'er.
They might spend time trying to silence them, instead of resolving the pro6lem that is trying to 6e
reported.
Solution: +on,t remem6er a request to silence alarms. The ne=t time that the system detects an
alarmed condition, sound the alarm, regardless of how recently it was retired.
Resulting Context: The system will report alarms whenever they are appropriate. The wor'er
will have to repeatedly silence them, until the pro6lem is corrected and the system no longer
reasserts the alarm. The wor'er will have the grace period of the alarm detection period during
which their retire alarm action will 6e remem6ered.
This pattern differs from #eorge &ashington !s )till +ead in the severity of messages. This
pattern deals with alarmed situations, whereas the other pattern is a6out slightly less critical
information.
String " &ire
5eywords: 0mergency
Problem: %ritically important information must get to other computer systems.
Context: )ometimes there is the need for direct Machine to Machine messages. This might 6e
6ecause !1O is sometimes inefficient, or 6ecause the system is in a partial capa6ility mode or the
system can,t afford the resources to do !1O.
Forces: )tandard MML messages could 6e used 6etween two systems, 6ut 6oth systems will have
to spend resources 8memory, time9 to encode and decode the message in the foreign language.
"n interface specification document has pro6a6ly 6een written that outlines how the two systems
should communicate. Or at least that the need to communicate e=ists and what information
should 6e e=changed.
Solution: rovide a hardwired messaging connection. 80.g. +ynamic Overload %ontrols, 0;"
telemetry channels, etc.9 *se the interface specification document to descri6e the interface so
that 6oth systems can 6e developed towards a common interface view.
Resulting context: The system will present information to monitoring systems even when the
ordinary !1O methods cannot 6e afforded due to emergency or resource utili3ation priorities.
!f more information is needed than a simple hardwired messaging connection can provide,
consider adding some $aw !1O capa6ility.
Re!erence: B,HHCE" pp. 44'*&44'%.
Ra' I(O
5eywords: 0mergency
Problem: 4ow do we get !1O out during those times when the !1O system is unavaila6le, for
e=ample during system initiali3ation, or times of emergency.
Context: )ometimes the system is in a partial capa6ility mode or the system can,t afford the
resources to do all the !1O for machine to human messages. But these might 6e @ust the situations
40:44:4* 4%
where people need to 6e informed a6out system state. )tring " &ire cannot provide enough
information in these circumstances.
Forces: 4umans watching a system that has no a6ility to communicate are tempted to do
something drastic 22 li'e manually requesting an initiali3ation. This is rarely the right thing to
do. 8)ee Minimi3e 4uman !ntervention :LO+2;<9.
!f the system doesn,t communicate any information during these times of crisis, there is nothing
to help an e=pert user to help the system 8see eople 5now Best :LO+2;<9.
$ecovery and initiali3ation programs are in total control of the system, and typically have the
a6ility to loo' inside other su6systems and perform their wor'. !n fact this is pro6a6ly safer than
allowing the !1O su6system loose during periods of system recovery.
Solution: +isplay the output out via 6rute force mechanisms such as writing directly to the
channel and avoiding the !1O system. This should 6e restricted to recovery periods only.
The periods during which this raw !1O mechanism should 6e limited. The system should
endeavor to restore the !1O system as early as possi6le.
Resulting Context: +uring critical periods the safe course is chosen and the recovery programs
administer !1O rather than relying on the !1O system. The !1O system is pro6a6ly much larger
with many more interfaces, so this results in the amount of code that must 6e availa6le during
recovery.
+cknowledgments"
The authors 9ould li=e to ac=no9ledge the /ollo9ing people /or their help preparing this pattern
language(
Revie9ers 9ithin Lucent Technologies( Ric= Roc=ershousen 9ho revie9ed 40 G--I contentP ,len
Foore 9ho 9as one o/ the original developers o/ the *G-- -9itch #:O s.stemP 1huc= Borcher and
3eatrice 1hilds 9ho participated in a revie9 o/ "larm #rid and Office "larms.
3avid 3eLano" our PloP&)+ shepherd provided invaluable comments to improve these patterns.
Ralph Cones. 4)!'&4))+. #nventor o/ the "larm #rid concept.
-ive Minutes of /o 0scalation Messages is co&authored b. Fi=e 0dams and a previous version 9as
published in BPLOP3&2E.
eople 5now Best 9as 9ritten b. Robert ,amo=e and is published in BPLOP3&2E.
Re!erenced Patterns:
attern /ame ro6lem )olution
LO+2;
age
Minimi3e 4uman
!ntervention
eople cause many pro6lems +esign system to care for itself ..B2..;
eople 5now Best
Balancing human authority with
automation
"ssume people 'now 6est ..;2..E
40:44:4* 4$
Re!erences:
)B$**+,: Budlong, ". 4., B. #. +eLugish, ). M. /eville, F. ). /owa', F. L. 7uinn and -. &. &endland. BGHH. >B"
rocessor: %ontrol )ystem.> Bell S-stem echnical .ournal, vol. .I, no. ;, -e6., BGHH: BE.2BHG.
)CF#LR,: %lement, #. -., . ). -uss, $. F. #riffith, $. %. Lee and $. +. $oyer. BGHH. >B" rocessor: %ontrol,
"dmininstrative, and *tility )oftware.> Bell S-stem echnical .ournal, vol. .I, no. ;, -e6., BGHH: ;EH2;.J.
)#//.,: #reen, T. A., +. #. 4aensch'e, B. 4. 4orn6ach and %. 0. Fohnson. BGHH. >/o J 0)): /etwor'
Management and Traffic "dministration.> Bell S-stem echnical .ournal, vol. .I, no. H, )ept, BGHH: BBIG2B;C;.
)#/RS,: #iunta, F. "., ). -. 4eath !!!, F. T. $aleigh, and M. T. )mith, Fr. BGHH. >/o J 0)): +ata1Trun'
"dministration and Maintenance.> Bell S-stem echnical .ournal, vol. .I, no. H, )ept, BGHH: B;CE2B;EH.
)#OF,: #amma, 0., $. 4elm, $. Fohnson, and F. Alissides. BGG.. $esign Patterns 0lements o! Reusable Ob1ect-
Oriented So!t'are. $eading, M": "ddison2&esley u6lishing %o.
)/..S+,: 4uttenhoff, F. 4., F. Fani', Fr., #. +. Fohnson, &. $. )chleicher, M. -. )lana, and -. 4. Tendic', Fr. BGHH.
>/o J 0)): eripheral )ystem.> Bell S-stem echnical .ournal, vol. .I, no. H, )ept, BGHH: BC;G2BC...
)PLOP$-2,: "dams, M., F. %oplien, $. #amo'e, $. 4anmer, -. 5eeve and 5. /icodemus. BGGI. >-ault2Tolerant
Telecommunication )ystem atterns> in Pattern Languages o! Program $esign3 edited 6y F. M. Alissides, F. O.
%oplien and /. L. 5erth. $eading, M": "ddison2&esley u6lishing %o.
40:44:4* 4'