National Defense Maritime Engineering Journal · 2017-03-06 · • Simple Steps for Effective Software Management • A Readership Survey Canada. A veritable "green machine" is about

National DefenseDefence rationale

MaritimeEngineeringJournal

October 1994

Designing effective ESM human/computerinterfaces...Where does the end-user fit in?

Also:• Simple Steps for Effective Software Management• A Readership Survey

Canada

A veritable "green machine" is about to hitthe waves - see page 21

MaritimeEngineeringJournal Established 1982

Director GeneralMaritime Engineering andMaintenanceCommodore Robert L. Preston

EditorCaptain(N) Sherm EmbreeDirector of Marine and ElectricalEngineering (DMEE)

Production EditorBrian McCulloughTel.(819) 997-9355Fax (819) 994-9929

Technical EditorsLCdr Keith Dewar

(Marine Systems)LCdr Doug Brown

(Combat Systems)Simon Igici

(Combat Systems)LCdr Ken Holt

(Naval Architecture)

Journal RepresentativeCPO1 Jim Dean (NCMs),(819)997-9610

Graphic DesignIvor Pontiroli, DC A 2-6

Translation Services bySecretary of State Translation BureauMme. Josette Pelletier, Director

OCTOBER 1994

DEPARTMENTS

Editor's Notes 2

Letters 3

Commodore's Cornerby Commodore Robert L. Preston 4

FORUM

• SRUA in Transition by Capt(N) Roger Chiasson 5• Life as a Junior CSE by Lt(N) Pierre Langlois 6• Technical Spec for a CPO1 ERA by Cdr G.L. Trueman 7

FEATURES

The Role of the End-user in the Design of EffectiveESM Human/Computer Interfaces

by Barbara Ford 8

More Effective Software Managementby LCdr Doug Brown 11

Fuel Cells and the Navyby LCdr M. J.Adams 15

East Coast MARE Seminar 1994byLt(N)BradYeo 20

GREENSPACE:A Solid Waste Pulper for the Navy

by Mario Gingras 21

LOOKING BACK:Canada's first astronaut (and MARE) in space

by Brian McCullough 22

NEWS BRIEFS 24

READERSHIP SURVEY 28

OUR COVERNaval electronic warfare analyst MS Ed Campbell reviews the pre-productionCANEWS 2 user interface being developed by Defence Research EstablishmentOttawa. (DREO photo by Bill Townson)

The Maritime Engineering Journal (ISSN 0713-0058) is an unofficial publication of the Maritime Engineersof the Canadian Forces, published three times a year by the Director General Maritime Engineering andMaintenance with the authorization of the Vice-Chief of the Defence Staff. Views expressed are those of thewriters and do not necessarily reflect official opinion or policy. Correspondence can be addressed to:The Editor, Maritime Engineering Journal, DMEE, National Defence Headquarters, MGen George R.Pearkes Building, Ottawa, Ontario Canada K1A OK2. The editor reserves the right to reject or edit anyeditorial material, and while every effort is made to return artwork and photos in good condition the Journalcan assume no responsibility for this. Unless otherwise stated, Journal articles may be reprinted withproper credit.

MARITIME ENGINEERING JOURNAL, OCTOBER 1994

Editor's Notes"Quick is Beautiful'

By Capt(N) Sherm Embree, CD, P.Eng., CIMarEDirector of Marine and Electrical Engineering

In these days of restraint it is as muchthe responsiveness of our DND pro-cesses that is being scrutinized as it isthe cost of those processes. Cost is cer-tainly a byword of any project, but sotoo are "schedule and performance."Customers demand satisfactory results,and they expect them quickly. If a sup-plier responds too slowly to a demand,conditions can change so drastically inthe interim that the final output satisfiesno one. This applies to DND's ownprocesses of project management andengineering change. Unless these pro-cesses are made to function quickly, theytempt failure.

In his book, "Infinite In AH Direc-tions" (Harper and Row, 1988), Profes-sor Freeman J. Dyson offers a morethorough discussion on the reasons whyengineering projects fail. Dyson identi-fies some of the snags to be avoidedwhen introducing new technologies. Forinstance, if we take too long to come up

with a solution to a problem, he says, theconditions of the problem could wellchange enough in the interim to make thesolution irrelevant. Do we fall into thistrap in DND? When we go through thedrawn-out process of establishing a busi-ness case for every change, are we cer-tain that the financial conditions westarted out with are still applicable at theend of the exercise?

A second concern of Dyson's is thatregulations and requirements can changein less time than it takes to introduce atechnology. What happens when every-one jumps onto a new-technology band-wagon and the wagon can't follow themajor turns in the road? Our own experi-ence with information and control sys-tems may bring some lessons home to usin this respect.

Dyson also points out that we may befooled into thinking there are economiesof scale to be had with new technologies

when, in fact, those economies may belost if a big plant takes too long to build."Small is beautiful" may not always beappropriate, but if your massive newmaintenance information system is tak-ing too long to establish, the economiesof scale might very well be lost to inter-est and overhead charges. Never mindthat a cumbersome system will sufferfrom its own inherent inflexibility aschanging regulations and requirementsoutpace the system's implementation.

In my view DND has no choice but toadopt a "quick-response" work ethic toavoid these problems. We will have tosee more off-the-shelf buys, streamlinedonce-only acquisitions and processreengineering if we are to ensure timelyresponses and customer satisfaction."Quick is Beautiful" might not yet berecognized as a clarion call, but wemight be well-advised to rally to itsooner rather than later. *

Attention all readers!....Speaking of keeping the customer

happy, we have included a readershipsurvey with this issue of the Journal. Welast conducted a formal survey in 1987and were delighted to receive repliesfrom seven percent of the readership.

This time we would like to do even bet-ter. Since the Journal is privileged with aworldwide readership, we would like tohear from anyone and everyone whoreads the Journal, including our "ex-tended family of readers" in the serviceof other countries.

Please take a few minutes to let usknow how we can make Canada'sMARE branch journal more responsiveto your needs. Your feedback will guidethe editorial committee in bringing aboutchanges to improve the magazine, andwe will report back on the results of thesurvey as soon as possible, m


Letters to the Editor

A/HOD position on board ship a job

It has been just under a year since Ifirst read the Forum article entitled "As-sistant Head of Department: Should a jobbe an OSQ?" (MEJ: July 1993). Aftergoing over the article again during ourtransit through the Panama Canal(Operation Forward Action), and withthe benefit of another year at sea as aCSE head of department, I feel it is timefor a reply.

Lt(N) Pitre states that with respect tothe A/HOD billet "it seems a bit unreal-istic to affirm that it is not a trainingposition." It's been my experience thatthis depends wholly on the person theA/HOD is working under. If an A/HOD'sperformance objectives are used as thesole basis by which he/she is employed,then yes, the A/HOD can turn into atrainee who runs around looking only forsignatures. But in my opinion the perfor-mance objective package for an A/HODis nothing but a guideline. I hardly everlooked at the packages for the threeA/HODs I have successfully employed(one in HMCS QuAppelle, two inKootenay). Merely completing the "reqs"does not by any stretch of the imagina-tion mean that one will pass the HODboard or perform well as a HOD. What isimportant is that A/HODs be given in-creasingly important taskings and re-sponsibilities, so that by the last fourmonths of their employment they can begiven the chance to fully function asthe HOD.

While, as Lt(N) Pitre says, an assis-tant technically "cannot take responsibil-ity for a department until the OSQ has

been completed," as an A/HOD's experi-ence grows he/she should be given thechance to take on this responsibility. Ofcourse, the HOD is taking a chance bygiving the assistant this role. Inevitably,mistakes will be made and will have tobe answered. This can involve a lot ofspilled blood in the CO's cabin, but Ihave been lucky enough to have had COswho (after the dust has settled) havegenerally agreed with my theory on theevolution of an A/HOD. The alternativeis to produce an A/HOD with little expe-rience or know-how in dealing with thepressures and responsibilities of being aHOD, and in learning how to interactwith others (civilian and military) atthis level.

LT(N) Pitre goes on to say, "Why dowe allow newly sub-MOC qualifiedlieutenants to take on responsibilitiesashore that sometimes exceed those of adepartment head in a ship, yet demand anOSQ for the job at sea?" Personally, Idon't think you can compare the two.Who says a shore job at that rank levelcan match or exceed the responsibilitiesof a HOD at sea? Having spent one post-ing at NDHQ, I find it difficult to believethat there is a job a lieutenant(N) CSE orMSB HOD could have that is more im-portant or challenging than ensuring aship is technically ready and capable ofperforming the mission required of it.When all is said and done, is not the fleetthe business end of what it's all about?And to say that the divisional responsi-bilities of a shore based lieutenant are thesame as those of a HOD at sea is, for the

most part, absurd. Except for the FMGsor the Fleet Schools, the vast majority ofLt(N) shore billets (from what I sawduring my posting to DMCS) don'tinvolve divisional responsibilities what-soever, and those that do usually involvethe ranks of PO1 and above. Being re-sponsible for POls and above is far lesstime consuming and troublesome thanbeing responsible for MS and below.

Finally, I totally disagree with thestatement: "There is no need to make theA/HOD position an OSQ," primarilybecause I feel the A/HOD position is notone all sub-MOC qualified personnel aresuitable for. Over the last three years Ihave successfully trained seven PhaseVI candidates, but only four of themdisplayed the potential to succeed as anA/HOD (Yes, this was stated in theirPERs). Good technical ability does notnecessarily translate into good manage-ment ability or good leadership. If onedoes not display the potential, then oneshould not be given the A/HOD job.Definitely, the OSQ is needed to differ-entiate between those who are capableas a HOD and those who are not.

In closing, I have never had troubleconvincing anyone that the A/HODposition on board ship is a job. I thinkthis is mainly due to proper employmentand the increasingly important tasks andresponsibilities assigned, climaxing withbeing given the department to run for aperiod of time. It's never been a matterof just "signing the reqs off" with me. —Lt(N) D. Wong, CSEO, HMCSKootenay. m

Writer's GuideThe Journal welcomes unclassified

submissions, in English or French, onsubjects that meet any of the statedobjectives. To avoid duplication ofeffort and to ensure suitability of sub-ject matter, prospective contributorsare strongly advised to contact theEditor, Maritime Engineering Jour-nal, DMEE, National Defence Head-quarters, Ottawa, Ontario, K1AOK2, Tel,(819) 997-9355, before

submitting material. Final selection ofarticles for publication is made by theJournal'-; edicoria! committee. ! |

As a general rule, anicle subrnis-should not exceed 12 double- '

spaced pases of text. The preferred jformat is WordPerfect on 3.5" disfc8BK|?iaccompanied by one copy of the type-script. The author's name, tide, addfepvand telephone number should appear-on the first page. The last page should

pip complete figure captions for all

photographs and illustrations accom-panying the article. Photos and otherartwork should not be incorporatedwith tlit typescript, but should be J

prolecKd and inserted loose in themailing envelope. A photograph of theauthor would be appreciated.

Letters of any length are alwayswelcome, but only signed correspon-dence will be considered forpublication. :


Commodore's CornerAfter the FRP:future for MAREs as good as ever

By Commodore Robert L. Preston, DGMEM

Since I last wrote an article for theCommodore's Corner there have beensome significant events that continue tohave an impact on the business in whichwe engage ourselves as Maritime Engi-neers. The world situation continues todevelop in a more fragmented mannerthan we were used to in the 60s, 70s and80s. Our members have, over the pastfew years, served in the Persian Gulf, theAdriatic, in Yugoslavia, Cambodia andSomalia. Our navy continues to enjoy ahigh standard of technical readiness,notwithstanding the challenges of intro-ducing new and modernized classes ofships at the same time. One of the sig-nificant issues with which we must dealis the reduction of military activities inresponse to the financial problems (fac-ing most developed nations today) enun-ciated in the February budget.

The budget announcement resulted intwo personnel reduction initiatives, onebeing the Forces Reduction Program(FRP), the other being the CivilianReduction Program (CRP). While actionon the CRP was delayed until legislationcould be put in place, the FRP (whichaffected the MARE classification alongwith 14 other classifications) has movedthrough a number of stages. By now,all those who applied for the programhave been notified of the outcome oftheir application.

FRP 94 was effective in reachingits overall target of 963 releases. In fact,933 CF personnel accepted the offerand will be released this fall. From the

point of view of the MARE classifica-tion, the following numbers of MAREsaccepted offers:

Capt(N)

Cdr

LCdr

I

2

7

25

While there were some problemsgetting information to those who wereoffered the FRP, I believe the programwas generally well received. The FRPhas provided immediate opportunities forsome MAREs, and will open up ahealthier promotion flow in a classifica-tion which would have otherwise suf-fered from throughput problems.

"The FRR..will open up ahealthier promotion flow ina classification which wouldhave otherwise suffered fromthroughput problems."

With the first phase of the FRP behindus we must look to some longer termsolutions to the challenge of operatingwith reduced resources. The MARCOMFunctional Review and NDHQ's Opera-tion Excelerate are the initiatives which

will define some changes to the way thenavy does business. I anticipate evengreater reliance on in-service supportprovided by the industries involved inbuilding the Canadian patrol frigate andmodernizing the Tribal class.

The big question now is, "How willall these changes affect our business asMAREs?" As I see it there will be littlechange to the early part of a MARE'scareer, which is oriented toward operat-ing and maintaining the ships at sea. Onthe other hand, our new-equipment ac-quisition function will be affected, aswill the in-service system and equipmentsupport function we perform for theMaritime Commander.

The challenge will be to learn how touse and develop the capabilities of Cana-dian industry more effectively to providethe equipment and in-service support ournavy needs. This challenge is not a smallone and it will place tough, excitingdemands on our members in the latterpart of their careers.

In my opinion the future for theMARE is as good as it ever was. Serviceat sea as a Head of Department continuesto be the focus of the early stages of theMARE career. It prepares our officerswell for the demands they will face inproviding effective technical support tothe Maritime Commander. Although ourclassification will be smaller there is agreat deal of change occurring and inthat change there is opportunity for newapproaches and exciting careers. «

Maritime Engineering JournalObjectives ~?s

* To promote professionalismamong maritime engineers andtechnicians.

• To provide an open forum whereig topics of interest to the maritimelie engineering community can be

presented and discussed, even ifthey might be controversial.

To present practical maritime

To present historical perspec-tives on current programs, situa-tions and events.

To provide announcements ofprograms concerning maritimeengineering personnel.

To provide personnel newsnot covered by officialpublications. : : : ~ ~ :


SRUA in TVansition —You Wouldn't Recognize the Old Place

Article by Capt(N) Roger Chiasson

Ship Repair Unit (Atlantic) has prob-ably undergone more change in the lastfour years than it has since it wasfounded as a Royal Naval Dockyard in1759. Much of that change has been self-imposed, by the introduction of a Con-tinuous Improvement Program (ourversion of Total Quality Management).

Our reasons for embarking on thisinitiative were somewhat idealistic. Wewanted to work smarter, and we wantedto empower our employees so as to re-duce their frustration at being shackledby archaic rules and "systems." We alsohad an inkling that we needed to become"leaner and meaner," but little did weknow how prophetic that gut feelingwould be. SRUA, like everywhere else,continues to be affected by Department-wide budget cuts, and by a commitmentin the naval engineering and mainte-nance community to drastically reducethe cost of doing business.

I have often compared the challengeof introducing a new management phi-losophy and employee culture in a unitlike SRUA, which is so steeped in tradi-tion and inertia, to that of changing thecourse of a 300,000-tonne tanker using arudder the size of a briefcase. It's not abad analogy when you consider it takesfive to seven years for a TQM initiativeto fully mature. Our "300,000-tonnetanker" has taken on a definite momen-tum, to the extent that most of us inSRUA are convinced the change ofcourse has started and is irreversible.

The change of direction is clearlyevident from the following significantachievements and/or initiatives which areattributable (either directly or indirectly)to our Continuous Improvement Program:

Adoption of Strategic andBusiness Planning

SRUA is now in its third business-plan cycle;

A cost-awareness and budget manage-ment philosophy has been adopted;

Goals and objectives are driven bycustomer and stakeholder needs.

Commitment to Improved EfficiencyA 7% reduction in the salary wage

envelope (entirely out of overhead) hasbeen achieved to date;

Further reductions are planned toachieve a mandated 20% reduction in thecost of doing business by April 1, 1996;more than half of this will be achievedthrough reductions in overhead.

"Somehow, the spark thathad ignited the enthusiasmand pride for OperationFriction had to be relit."

Commitment to Increased EfficiencyThe proportion of direct productionperson-hour effort has been increasedfrom 42% to 49%;

Repair-and-Overhaul turnaroundtimes for supply system componentshave been reduced by more than 50%;

SRUA's accident rate has been re-duced by 17%; lost time due to acci-dents reduced by 35%;

Workforce flexibility (reduction of tradedemarcations) and a team concept formajor projects have been introduced;

ISO 9001 international quality assurancestandard has been introduced; registra-tion planned prior to August 1996.

Commitment to a People-focusedEnvironment

Excellent labour relations exist de-spite the climate of wage constraintand downsizing;

There is mutual commitment to stra-tegic alliances between managementand labour;

Unions enjoy full consultative andparticipatory status in Human Re-sources Management, ContinuousImprovement and Strategic and Busi-ness Planning committees;

An empowered workforce and a cul-ture in which labour and managementare amenable to and committed tochange have emerged;

The representation of EmploymentEquity group employees hasquadrupled;

Sensitivity and awareness training hasbeen introduced to develop greateracceptance of a diversified workforce.

The decision to embark on a Continu-ous Improvement Program was made inthe wake of SRUA's crowning achieve-ment — preparing three warships for de-ployment to the Persian Gulf in 1990.SRUA was awarded the Chief of DefenceStaff Commendation for its part in Opera-tion Friction, but enthusiasm levels soonwaned. Somehow, the spark that hadignited the enthusiasm and pride forOperation Friction had to be relit.

Today, thanks to a great deal of slow-burning, enduring effort, these qualitiesare gradually beginning to reemerge. Westill have some distance to go, but SRUAis well on its way to becoming the "lean-est and the keenest" repair facility of itskind anywhere. You just wouldn't recog-nize the old place. *

Capt(N) Chiasson was the CommandingOfficer of SRUA from 1990 until this pastJuly. He is now undertaking languagetraining for his appointment as the Canadiannaval attache in Japan.


Life as a Junior CSE Officer*Article by Lt(N) Pierre Langlois("First presented at the 1993 MARE Seminar in Halifax.)

We all know how long it takes to getrid of the "U" in our MOC and replace itwith an "A," and how long it takes toreplace that with a sub-MOC designator.But obtaining that final, recognizedqualification still only leaves us as "jun-ior officers." So what is it like to be ajunior officer in your first position? Mostreaders of this journal have been throughthat experience already, but I have beenasked to give my own point of view, onenot yet seasoned by broad experience inthe MARE community.

I graduated from the Royal MilitaryCollege in 1990 with a degree in Electri-cal Engineering. After training at Ven-ture and in HMCS Mackenzie Icompleted the Applications Course atFleet School Halifax and did my PhaseVI on board Algonquin. I also had theopportunity to do some on-the-job train-ing with Paramax in Montreal and withthe Defence Research EstablishmentAtlantic in Dartmouth. I was posted tothe TRUMP detachment at the MILDavie shipyard in Lauzon in October1992.

My first responsibilities in TRUMPwere as D/CSEO. After benefitting fromwhat has to be the longest turnover in thehistory of the Canadian navy (seven

months), I became the CSEO — or, asmy NCOs put it, "le boss." It is the re-sponsibility of my office to verify andinspect all combat systems work per-formed by the shipyard. We evaluatetrials, revise and approve unscheduledwork proposals, provide technical assis-tance and generally liaise between sub-contractors and DND agencies.

The position of CSEO involves a lotof responsibility, especially for a juniorofficer fresh out of training. My presentsupervisor was somewhat reluctant totake on a non-HOD-trained officer whodid not have even a couple of years ofexperience. Not only did I have to provethat I was motivated to perform, but thatI was capable of doing so. Being ac-cepted by the other section heads was agreat help, and I owe a debt of gratitudeto the officer I replaced for all his support,encouragement and confidence in me.

What worried me most was how thesenior non-commissioned memberswould react to me. These men had moresea time than I can ever dream of getting.I made it clear to them that even though Iwas a qualified CSE, I valued their opin-ions and recommendations highly. Fortheir part they recognized my technicalcompetence, and together we created avery efficient and powerful workingrelationship. Some of the shipyard em-ployees, on the other hand, tried to takeadvantage of my inexperience duringnegotiations over contract work andinspection standards. The problems dis-appeared after I adopted a strong posi-tion on a few occasions.

My MARE training seemed to prepareme well for the CSEO position. Thetechnical information it provided on thevarious areas of combat systems wasexcellent, and it gave me a good grasp ofthe concepts and a broad understandingof how the different systems interact onboard ship. The training was also ad-equate in the broader naval engineering

issues (especially in marine systems) andin general naval knowledge. In that lastarea, more time at sea would certainlyhelp, though. If I could add anything tothe training package it would be in lead-ership and the management tools to sup-port it. Leadership seems to be a skill weare expected to develop on board ship,whether we have divisional responsibili-ties or not. I was not prepared for myfirst tour as Officer of the Day duringPhase IV training.

From the position of CSEO in TRUMPLauzon, I will take away excellent expe-rience as a section head, as a MaritimeEngineer in a major refit project and as amediator in dealings between naval sup-port agencies. There are some things thattraining alone cannot provide, andamong these is the management of realresources to meet real deadlines.

"Leadership seems to be askill we are expected todevelop on board ship,whether we have divisionalresponsibilities or not."

As far as my outlook on a career inthe navy goes, there are many interestingand challenging jobs available. The con-tinuing training program of the CanadianForces is certainly appealing, especiallythe postgraduate studies, but it seems thepromotion opportunities will be limitedas many excellent candidates fight forthe extra gold. There is also an apparentcontradiction in the absolute requirementto be HOD trained (to get ahead), versusthe limited number of training billets in afleet that is decreasing in size. Success, Ihave heard, is the combination of talentand opportunity. My classmates and Ibelieve we have the talent, but will theopportunities be there? a

MARITIME ENGINEERING IOURNAL, OCTOBER 1994

Technical Specification for aCPOI Engine Room ArtificerArticle by Cdr G.L. Trueman

Author's Note: On April 28 a retirement farewell gathering was held at the C&PO's Mess in Halifax for CPOI ERAJ.L. Macintosh and CPOI ERA S. Jenkins. As the senior MSEO on the Coast I was asked to say a few words tomark the occasion. I wrote and delivered this "technical specification" as a tribute to the two chiefs, and to allCPOI ERAs "worth their salt."

References:A. BR2007 Marine Engineering Notes

for Engine Room Artificers andMechanicians Training (by Com-mand of their Lordships of theAdmiralty), 1952, Parts I-V.

B. BRCN5521 (NEM).

C. Divisional Officers' Handbook.

General1. The role of a CPOI ERA is to be all

things to all people: a confessor/confidante to his Engineer Officer,a father figure and idol to his "kids"on the plates, a tough man of actionto his Captain and a fount of knowl-edge on all things mechanical toanyone outside his chosen profes-sion. To fulfil this role, he must beable to recite verbatim all five partsof reference A on boilers, recipro-cating machinery, turbines, auxil-iary machinery and internalcombustion engines. He must be onmore intimate terms with the provi-sions of reference B than he is withhis wife. He must be the livingpractical example of the provisionsof reference C.

Performance Requirements2. For a CPOI ERA to be worth his A

salt, he must satisfy the following ||performance requirements:

a. must always put his ship, hismen and the welfare of hisBranch before anything else:

b. must be able and willing to go tosea and fight his ship, anytime,anywhere;

c. must be able to slap a bearing ona triple-expansion steam engine

without losing a finger, all thewhile whistling Hearts of Oak;

d. must be a recognized expert onall things mechanical, pseudo-mechanical, remotely mechanicaland nonmechanical, whetherauthorized or unauthorized forRCN use;

e. must be able to extract a sparepart anytime, anywhere, from thePusser's shop, using the mini-mum amount of force necessary;

f. must be able to manoeuvre at fullpower, either ahead, astern orsideways, preferably all at thesame time, without propellers(read little to no pay), lackinglube oil (read lacking beer orbeverage of choice) and lackingany form of closed-loop controlsystem (read no direction andguidance); and

g. must be able to lead his menfrom ahead and his officers fromastern.

Physical Requirements3. A successful CPOI ERA must pos-

sess the following physical charac-teristics:

a. big feet for motivating the back-sides of wayward mechanicians;

b. nerves of hardened, tempered,cold-rolled steel to AISI 4150Standard, while all those aroundhim possess nerves of pig iron orlesser grade materials;

c. an intelligence quotient propor-tional to his Common Dog quo-tient and skin thickness; and

d. the thermodynamic properties ofan irradiated black body (i.e. canabsorb all incoming heat, flackand abuse without retransmittingsame).

Test and Trials Requirements4. Besides satisfying the foregoing

requirements and all of the tests andtrials specified by reference B, aCPOI ERA will satisfy the follow-ing tests and trials:

a. wax eloquent for a minimum of 1hour, without normalizing, onany topic of choice, in anunstabilized condition, to thestandard specified by the Chair-man of the Black Angus Society;and

b. after a minimum of 35 years'service to the Navy recite, with-out error, the motto of his Engi-neering Branch, with a smile onhis face, m

Cdr Trueman retired from the navy inSeptember to take up private business pursuitsin Nova Scotia.


The Role of the End-user in the Designof Effective ESM Human/Computer InterfacesArticle by Barbara Ford

Human/computer interfaces are oftendesigned without direct input from theend-user. This is true especially of mili-tary systems where a headquarters unitdetermines the requirement for the hu-man/computer interface (HCI), and as-sumes the operator (i.e. the end-user) willbe trained to use the final product how-ever it turns out. In fact, in cases wherethe end-user has not been involved in thedesign process, the operator tends tosimply avoid those portions of the HCIthat are too confusing, thereby reducingefficiency. Inevitably, this process leadsto a spate of expensive engineeringchange requests.

As more and more HCIs are beingdesigned, it is becoming clear that theend-users are valuable to the process ofcreating effective interfaces'11. This par-ticularly applies to military HCIs, sincedeficiencies in an interface could havecatastrophic consequences. For instance,it is possible that lives could have beensaved on board the USS Stark had theinformation on the ship's SLQ-32 beenconveyed in a different way121.

Designing a human/computer inter-face for an electronic support measures(ESM) system is not trivial. There isconsiderable information available abouta potentially large number of pulses,

emitters and platforms in the environment.The information is context dependent andof a critical nature. The effectiveness ofelectronic countermeasures and ship sur-vival depend on the results of interpreta-tion of the information.

Not only are the complexity and so-phistication of the functions performed byan HCI increasing, but it is also essentialto minimize development time and life-cycle costs. The achievement of thesegoals is dependent on the employment ofeffective system development methodolo-gies. The Defence Research EstablishmentOttawa (DREO) has formulated a devel-opment strategy for HCI systems that

Full Input Methodology: Emphasis: Overall effective HCIResult: Timely, Cost-effective, Respected, Effective HCI

Research/Specification

Input from:- customer- designer- scientist- engineer- end-user- programmer

Prototype

1 \.

Test/Redesign

Input from:- end-user- customer- designer- scientist- engineer- programmer

^ Implementation

Minimal Input Methodology: Emphasis: Bug-free HCIResult: Costly, Less effective HCI

Research/Specification

Input from:- customer- scientist- engineer- designer

Prototype

i k

Test/Redesign

Input from:- designer- programmer

ImplementationEngineeringChangeRequests

1

Fig. 1. Human/Computer Interface Strategies


borrows elements from concurrent engi-neering'3'41. DREO's Full Input method-ology minimizes the need for makingdesign changes when the system devel-opment is nearly complete.

It does this by obtaining input fromthe intended users of the interface atvarious phases in the design process. Inthe older design methodology, which werefer to as Minimal Input, user feedbackis obtained only after the HCI entersservice. It is considerably more economi-cal to identify and correct errors, and toimplement and evaluate potential im-provements at earlier stages in the sys-tem design. Consequently, the DREOmethodology results in a more effectiveHCI, saving money and reducing thetime required before the HCI is fullyoperational.

The phases of designing a human/computer interface are[5]:

Research/Specification — define therequirement, generate and analyze designideas;

Prototype — build an experimentalversion of the specified design;

Test/Redesign — continue to try outand improve the design until it is effec-tive and complete; and

Implementation — build the designto be fielded.

Input from the end-user is useful atthe Research/Specification phase as wellas the Test/Redesign phase. Figure 1shows these phases in both the Full In-volvement and Minimal Involvementmethodologies.

DREO is currently involved in de-signing the human/computer interface forCANEWS 2, the next-generation navalESM system. DREO designed theCANEWS HCI currently in service inthe Canadian patrol frigates and Tribal-class destroyers, and several of its fea-tures and functions are being maintainedfor the next generation. However, muchhas changed in the past decade: there isconsiderable additional information nowavailable to the operator, and displaytechniques have advanced. The new HCIuses many windows, menus and buttons.The operator has considerable flexibilityover what information windows hewishes to have visible. There is, how-ever, a fixed window that cannot beremoved or obscured since it containscritical information that must be dis-played at all times.

Defence scientist Barbara Ford observes EW analyst MS Ed Campbell as heperforms a fixed set of tasks on DREO's pre-production user interface forCANEWS 2.

The end-users, ESM operators, havecontributed significantly to the design ofthe next-generation ESM system HCI.They have been useful in maintainingconsistency with the old system inter-face, in determining which new featuresare most useful, and in identifying whichnew functions appear too complex. ESMoperators were used at the Researchphase to make sure all expected func-tionality was present, and during theTest/Redesign phase. The next sectiondescribes the process DREO used to testthe design using the ESM operators.

Testing a Design using ESMOperators

Appropriate users must be selected forthe test process. They should have anexperience level typical of the expectedend-users of the product, and should notbe biased by the opinions of the de-signer111. DREO selected operators whohad used other ESM systems, includingthe one the next-generation ESM systemis to replace. They were, therefore,knowledgeable about what to expectfrom an ESM HCP1. These ESM opera-tors had their own biases about what theylike to use on ESM interfaces, but thiswas considered during the design test.

Such bias was appropriate for the DREOapplication since progressive improve-ments on previous ESM interfaces arepreferred over revolutionary changes.

The operators were told the purposeof the test and it was stressed that it wasthe product being tested, not them. Theywere told that if they had any difficultiesit would indicate weakness in the design,not in their abilities.

The ESM system HCI is designed tobe as intuitive as possible since the op-erator must react quickly to new infor-mation on the display, often understressful conditions. Having an HCI thatbehaves as the operator expects it to canminimize errors in those critical mo-ments. Due to this requirement, the op-erators were asked, one at a time, to usethe system for five minutes without anytraining time. They were shown only themain menus and how to operate the inputdevice. They were then observed to seehow effectively the interface couldbe manipulated and which functionswere accessed.

A short training period followed inwhich all interface functions and accessprocedures were explained. The opera-tors were then given the opportunity to


play with the system for 15 minutes.Although any questions would be an-swered during this time, the operatorswere left alone to explore and makemistakes without feeling inhibited by thepresence of staff.

At the end of the training period eachoperator was observed performing afixed set of tasks which included at-tempting functions, manipulating win-dows, and accessing menu items. Todraw consistent conclusions about thedesign, it was important to use a fixed setof tasks when testing each operator.

By this time the operators had manyopinions about the design of the ESMHCI. Any thoughts they expressed dur-ing the test were noted, and a wrap-updiscussion among several ESM operatorsand the designer proved particularlyuseful. Everyone had a chance to bounceideas off one another as the designerguided the discussion. Each function andwindow was put onto the display anddiscussed as to its usefulness and effec-tiveness. The operators were also askedto indicate if anything seemed to bemissing from the interface.

The process just described constitutedonly one iteration of the Test/Redesignphase. Operators will be used again infurther iterations for the design of theESM system HCI.

How useful are the end-users?The observations of the operators

using the system with zero traininghelped to indicate the extent to which thedesign is intuitive. They demonstratedthe effectiveness of the basic layout ofthe display, the accessibility of the func-tions through the menus and buttons, andwhether the information the operatorneeds is where he expects to find it.

The fixed test showed whether theinformation the operator requires is eas-ily accessible, and which display func-tions the operator is likely to use toobtain necessary information.

Many good ideas were presented inthe wrap-up discussion, including ideasfor changes to numerical units, additionsto display options, and new graphs. Theoperators indicated areas where informa-tion or functions appeared to be missing,and pointed out which windows theywould be most likely to use and inwhat form.

In general, consulting the end-usersfor this design test provided valuableinsight into what they need in the de-sign. Information from the operatorscontributed to consistency of terminol-ogy and usage among the various ESMsystems. Consistency is needed for easeand comfort of use of the new interface.In any given day an operator is likely touse several ESM-related HCIs, soswitching systems should be as easy aspossible. The more familiar new toolsare, the more likely it is the operator willuse them effectively.

End-user design testing can be usefulin determining how cluttered an inter-face can become. For instance, afterusing the interface for some time it maybecome cluttered with too many openwindows. Operators will need to betrained to close windows that are nolonger required. Restricting flexibilityof the interface is possible, but is oftennot desired.

ConclusionsOperators should not be solely re-

sponsible for the design of a human/computer interface. They are not ex-pected to be aware of all available sys-tem functionality and will show atendency to initially reject what they arenot used to. Still, it is important they beconsulted.

The end-user, or operator, best knowsthe environment in which the HCI willbe used and how the information will beinterpreted. He knows best which infor-mation is presented in too complex amanner, and which aspects of the inter-face might rarely be used. He is also inthe best position to enforce consistencybetween his various systems with re-spect to units of measure, and to howthings appear, are used or accessed.

When the operator is consulted in thedesign of the interface, the changes heinevitably requires can be made beforedesign implementation. This minimizesthe need for costly, post-implementationengineering changes.

End-users should be in the loop forthe design process of military HCIs. Theuse of the ESM operators at DREO forthe design of the next-generation ESMHCI proved very useful. The operatorsenjoyed the exercise and were veryenthusiastic. It is anticipated that the

operators will have more respect for thefinal product, and confidence in it,knowing they were part of the designprocess, m

References[1] K. Gomoll, "Some Techniques for

Observing Users," in The Art ofHuman Computer InterfaceDesign (Reading, MA: Addison-Wesley Publishing Co)., 1991,pp.85-90.

[2] J. Adam, "USS Stark: WhatReally Happened?" IEEESpectrum, Vol. 24, No. 9(September 1987), 26-29.

[3] J. Turino, "ConcurrentEngineering: Making It WorkCalls for Input From Everyone,"IEEE Spectrum, Vol. 28, No. 7(July 1991), 30-32.

[4] S.G. Shina, "ConcurrentEngineering: New Rules forWorld-class Companies," IEEESpectrum, Vol. 28, No. 7 (July1991), 22-26.

[5] L. Vertelney and S. Booker,"Designing the Whole-ProductUser Interface," in The Art ofHuman Computer InterfaceDesign (Reading, MA: Addison-Wesley Publishing Co., 1991), pp.57-63.

[6] B. Ford, "Evaluation of theCANEWS 2 Operator InterfacePrototype," DREO Technical Note93-17 (July 1993).

Barbara Ford is a defence scientist with theElectronic Warfare division of DefenceResearch Establishment Ottawa.

10 MARITIME ENGINEERING JOURNAL, OCTOBER 1994

More Effective Software ManagementArticle by LCdr Doug Brown

Software is a pervasive element intoday's complex society. It forms anessential component of virtually everycontrol system, including those for allweapon systems. Yet the procurement andsupport of software is fraught with diffi-culty. Delivery of software on time,within budget and meeting initial require-ments is the exception rather than the rule.Many of the problems encountered alongthe way stem from a lack of understand-ing of the software development processand its associated cost-drivers.

A great many software developmentprojects are huge, and push technology tothe limits. The command and controlsystem for the Canadian patrol frigate, forexample, will cost more than $200 mil-lion, but by today's standards this is notan unusually large undertaking. As com-plex as some development projects maybe, managing the acquisition of softwareis not rocket science. The managementprinciples involved are the same as forany other development project. It is thefailure to apply these principles thatcauses many of the problems. The U.S.Defense Science Board recently statedthat, "today's major prob-lems with military softwaredevelopment are not tech-nical problems, but man-agement problems."

Even minor managerialoversights can involvelarge cost overruns. Withsoftware so crucial tonaval operations, we can-not afford ineffectivemanagement of its devel-opment. To this end it isworth examining five keysoftware managementissues:

Life-cycle Cost DistributionIf software were to be characterized by

one word, that word would likely be "ex-pensive." Costs in the order of $200 to$300 per line of code are often quoted forweapon systems. As these systems fre-quently exceed one million lines of codeit is not surprising that software develop-ment costs range in the hundreds of mil-lions of dollars. Software and relatedcosts can often be found in the range of20-40 percent of total acquisition costsfor weapon systems. Unfortunately, track-ing software costs accurately can be diffi-cult, especially when they have beenburied within other costs (often for goodreason). It is one thing to be unable to sayin advance exactly how much your soft-ware is going to cost, but it is completelyinexcusable at the end of the day to beunable to say how much you did spend.The first step in controlling software costsis to make them clearly visible so thatthey can be accurately measured andanalyzed. Only then can norms be estab-lished and deviations dealt with.

We must also understand that there aretwo distinct phases in the software life

I'll find out what they need. The restof you start coding!

cycle: the acquisition/development phaseand the maintenance/in-service phase.Weapon system software is historicallylong-lived; service lives of 15 to 20 yearsand longer are normal. Inevitably, main-tenance costs will more often than notexceed development costs. The UnitedStates Department of Defense has foundannual maintenance costs as high as 10-15 percent of the total development costs.Over the lifetime of a system, mainte-nance costs can reach 70-80 percent of

life-cycle cost distri-bution of software,

language of imple-mentation,

effects of hardwareon software,

changing require-ments, and

future technologies.

Development

Maintenance

Fig. 1. Software Life-cycle Cost Distribution

MARITIME ENGINEERING JOURNAL, OCTOBER 1994 11

3.0

£ 2.5

£ 2.0-

1 1'5oo

In.u

0.5-

0

_ rpn

Memory t

Both CPU & Memory //

/

i i i i i

20 40 60 80 100

Percent Utilization

Fig. 2. Software Cost Escalation resulting from High CPU and Memory Utilization.

An experiment con-ducted here in Canadaserves to highlight theeffectiveness of Ada. Twoteams were given identi-cal requirements andequal time to implement asmall utility. One teamused C-language; theother, Ada. In use, theAda code was found to bemore robust, requiringless than one-third theeffort to implement achange. A similar experi-ment by the USAF foundthe Ada maintenanceeffort to be less than halfthat of C. While savingsof this magnitude areunlikely to be found onlarge systems, savings ofeven a few percent cannotbe ignored when annualmaintenance costs arein the tens of millionsof dollars.

the total software-related costs. For thisreason, software development costs areoften compared to the tip of the softwarecost iceberg (Fig. I ) .

To date, much effort has been focusedon reducing software development costs.Little effort has been focused on reduc-ing maintenance costs, where the great-est expenditures lie. It is a well-knownmaxim that the largest target is easiesthit. Perhaps economic necessity willfinally force us to focus on the targetwith the greatest potential for savings. Itdoesn't help that maintenance costs areoften inadvertently increased by misin-formed decisions made during develop-ment. When a project is late or overbudget, considerable pressure is oftenexerted to get the software "out thedoor" at any cost. In the rush, essentialdesign documents may be ignored, orshort-cuts taken, which can easily doublethe subsequent maintenance costs.

The problem stems from the nature ofsoftware itself. Software is largely anintellectual artifact and must be under-stood before it can be modified. Short-cuts in development are achieved at theprice of understandability and reliability,which increases the level of effort andthe cost associated with maintenance. Itmakes better fiscal sense to expend extraeffort in development to achieve a qual-ity product to help reduce the largermaintenance costs.

Language of ImplementationThe language used for implementation

can also significantly affect life-cyclecosts. Unfortunately, selecting a suitablelanguage is difficult. The world is full ofself-professed "experts" who praise oneparticular language and trash all others.Also, the mandate to use Ada is frequentlyresisted, often for no other reason thanpeople don't like to be told what to do.Project managers can easily find them-selves at a loss as to which languagemight be the best for their project.

When the issue is examined rationally,Ada can be found to be the most benefi-cial and economical language to use overthe life cycle of a weapon system's soft-ware. It must be acknowledged, however,that although Ada has been adopted asthe standard high-order language forweapon systems in the Canadian Forces,it does have a number of deficiencies.Many of these faults apply equally toevery other language in use today, butfew people understand that the primaryadvantage of using Ada is not reduceddevelopment costs. Ada's intimacy withsound software engineering principlesleads to the development of high-qualitysoftware that is easier to maintain. Theprimary advantage of Ada, therefore, isreduced life-cycle costs through reducedmaintenance effort. Unfortunately, devel-opers often base their recommendationson software development costs alone.

Impact of Hardware SelectionSystems with embedded computers

have traditionally had their hardware se-lected first. The software was then made tofit the hardware. This may have been cost-effective 40 years ago when hardware wasexpensive, but no longer. Today, the choiceof hardware can be a significant cost-driverfor software development and mainte-nance. U.S. DoD analysis indicates thatsoftware-related costs form about 90 per-cent of the cost of embedding computingresources in a system. But even though itforms a very small percentage of the totalcost, the selection of hardware is crucial.

Curiously, attempting to utilize all avail-able CPU and memory capacity can sub-stantially increase software costs (Fig. 2).While there is apparently no impact belowa threshold of 60-percent utilization, oncethis limit is breached the cost of developingsoftware to fit the available resources in-creases rapidly — by more than two anda half times at 95 percent capacity than at60 percent.

None of this has been lost on themaintainers who will spend days and evenweeks trying to devise new algorithms thatare just a few bytes smaller or a few cyclesfaster. Understandably, many of the algo-rithms and control structures devised to copewith limited resources are arcane. Thus,future maintenance activities become pro-gressively more complex and expensive.


In a similar vein, we must also exam-ine our embedded computer hardwareprocurement practices. Twenty years agomilitary computers were on the leadingedge of technology. Today, most areobsolete before they even get off thedrawing board. The half-life of a modernCPU is very short and declining. Withprocurement lead times of 10 years andlonger, we can no longer afford to de-velop specialized military computers. Weare also faced with a dilemma: do wespecify current technology and guaranteeobsolescence, or do we increase the riskby specifying undeveloped technology?

The solution is to specify the interfaceand not the hardware. While the hard-ware interface remains well defined, thehardware and software can be developedin isolation and integrated with minimaldifficulty. We need to emulate the modelof the PC. Although the PC has manytechnical limitations, it does have well-defined architecture and interfaces. Thisallows PC software to be developed inisolation so successfully that it is noteven given a second thought.

The PC model has another attributeworthy of emulation. It is possible toeasily upgrade the CPU, add morememory, or any other needed resourcesand not worry about software compat-ibility. We can even replace one PCwith a completely differ-ent model. We are findingthat this flexibility is in-creasingly needed forweapon systems. Just asapplication programs forthe PC are growing in sizeand resource demands, sotoo is the software in ourweapon systems. We mustbe able to cater to soft-ware growth approachingan order of magnitudeduring a system's 20- to30-year life cycle. It isrelatively easy to physi-cally change a processor,but we must also be ableto move our considerablesoftware investment aswell. We rightly demandto be able to migrate a$200 word processingpackage from an older PCto the latest model withoutmodification. We mustdemand the same for a$200-million commandand control system.

Changing RequirementsSoftware requirements frequently are

allowed to be changed in mid-develop-ment. Most people view software asbeing something akin to gold: simple instructure and easily shaped by anyone. Inreality it is like crystal — very complexand liable to shatter if mistreated. Al-though software can accommodate mostany change during the development pro-cess, it is seldom simple and almostnever cheap. Uncontrolled change caneasily double the cost of software devel-opment. Fortunately, it is one of the mostpreventable causes of cost escalation, andthus merits special attention. Not surpris-ingly, all successful software projectsshare the common attribute of rigorouscontrol over requirement changes.

Software development is frequentlyinitiated with incomplete requirements.Perhaps the three most common lettersfound in a requirements specification are"TBD" (to be determined). While thereare some cases where requirements arebest sorted out after development hasbegun, all too often this is used as anexcuse to truncate requirements defini-tion and "get on with the job." This is amistake. This does not imply that re-quirements should never be allowed tochange (which would present an impos-sible situation). Rather, requirements

should be rigorously controlled suchthat the potential impact of every pro-posed change is carefully examined andunderstood.

Future TechnologiesSoftware, like all leading-edge tech-

nologies, has a number of innovationsthat show great potential. It is prudent,though, at this point to interject twowords of caution. Fred Brooks stated in1986 that there is no silver bullet thatwill magically increase software produc-tivity. This remains true today, despiteclaims to the contrary. The second pointto remember is that all new technologiesare attractive. We must not let this cloudour judgment. The acquisition of newtechnologies must help fill bona fiderequirements and should not be endsunto themselves. After all, many of eventhe most innovative software productsare destined to spend their lives ona shelf.

Three emerging technologies seem tobe most relevant to weapon systemsoftware: CASE, software reuse andprototyping. CASE or Computer AidedSoftware Engineering has been touted asmany things and has been greatly over-sold. If half the marketing literaturewere to be believed, a novice with aCASE tool could develop practically

Requirements& Design

Coding

Testing &Integration

Fig. 3. Applicability of Software Reuse


any real-time application to the mostexacting military standards. This just isnot so. CASE technology can be benefi-cial, and when properly applied canachieve substantial economies, but theunderlying methodologies must first beunderstood. A fool with a tool is stilla fool.

One of the problems with CASE toolsis that developers must adopt the methodespoused by the tool; it is very difficult tomould the tool to match existing practise.Many software developers are still tryingto refine their processes, and find thatCASE tools constrain and hamper devel-opment rather than enhance it. Widelyaccepted standards that allow the outputof one CASE tool to be used as the inputto the next are still being developed. Thelevel of effort presently required to pro-vide this intertool interfacing could easilynegate any potential savings from auto-mation. It is often forgotten that CASEtools are meant to be used by people,meaning that the most important factor insuccessfully implementing a CASE prod-uct is adequate training. CASE withoutthe training is a waste of resources.

Finally, CASE technology cannot yetbe applied retroactively. A large portionof the naval software now in service wasdeveloped without benefit of modernmethodologies. Adapting this software tomodern methods is proving to be verychallenging. Still, all is not doom andgloom. CASE technology holds greatpromise for automating the repetitivetasks and busy work associated withsoftware development. Part of the chal-lenge will be avoiding inappropriateCASE applications which can lead toexpensive "shelfware," or even a lossin productivity.

Software reuse is also gaining promi-nence as a potentially attractive means ofreducing costs. Considerable effort —such as with the U.S. DoD's STARS andCAMP initiatives — has been expendedto develop repositories of reusable soft-ware components. To put this into per-spective, consider that softwaredevelopment typically breaks down to40-percent effort defining requirements,30 percent developing source code, and30 percent testing and integrating (Fig.3). Limiting reuse to source code, as isfrequently envisaged, constrains its im-pact to only 30 percent of developmenteffort, which itself is only a small portionof the total life-cycle costs. Clearly, alarge-scale economic breakthrough willnot be achieved in this fashion.

Some firms are achieving consider-able success with reusing design, codeand integration software across a limitedproduct line. Thompson CSF of France,for example, is achieving 60-80 percentreuse rates with the code and design forits air-traffic control systems. Whilethese high levels of reuse represent onlymodest cost savings, the biggest benefitis the substantial reduction in the risknormally associated with completing asoftware project on target. Reuse hasmuch promise, but it is still immatureand there are many technical and legalissues that need resolution.

The last of the new technologies to beconsidered is prototyping. Prototypes areuseful in many development situations tofurther refine requirements, especially inareas such as the user interface. Userinterfaces are historically subject to veryhigh levels of maintenance activity,mainly because users often don't knowexactly what it is they want. They seemto follow the rules of "IKIWISI" — I'llknow it when I see it!

Developers are asked to provide aproduction interface, and user input isoften limited to negative feedback, beingreceived late in the development process.A great deal of effort can be wastedtrying to define user requirements. Mod-ern prototyping tools allow designers toeasily and rapidly build software func-tions so the user can provide meaningfulpositive feedback before extensive effortis wasted delivering an inappropriateproduct. In this situation, a picture trulyis worth a thousand words. A word ofcaution, however: prototypes are meantto be disposable. Prototyping yields lowquality code that should not be consid-ered for use in production software.

Conclusion

Software has become an essentialcomponent of weapon systems in a re-markably short period of time. To sup-port its increasing importance, softwaremust be managed cost-effectively. Tak-ing some simple steps will help achievethis.

Most importantly, all software-relatedcosts must be tracked. It is important toknow exactly how much is being spenton software development and support.To control life-cycle costs, softwaremust be developed with a view to easingmaintenance. This includes using appro-priate languages such as Ada, and com-pleting all required documentation in a

meaningful and useful manner. Thismight even entail extra effort during thedevelopment phase. Requirements mustbe meticulously analyzed, and changesrigorously controlled. Hardware has to beselected judiciously to ensure it does notincrease software development and main-tenance costs. Interfaces need to be speci-fied so that appropriate hardware can beselected and then upgraded as required,while maintaining any software invest-ment intact. Finally, new technologymust not be allowed to override commonsense. It must be shown to be useful,cost-effective and to satisfy a specificoutstanding requirement.

Software can be very impressive inoperation, providing flexibility andgreatly increasing the capability of oursystems. But it is not without cost. Man-aging weapon systems is complicated andintolerant of mistakes. Any attempt tosuspend common sense and good mana-gerial practice will always be disclosed inthe bottom line, m

References[1] John Bailey and Victor Basiler,

The Software Cycle Model for Re-engineering and Reuse, Tri-Ada 91Conference Proceedings,(Baltimore: ACM Press, 1991), pp.267-281.

[2] Barry Boehm, Software EngineeringEconomics (Englewood Cliffs:Prentice Hall, 1991).

[3] Roger Pressman, SoftwareEngineering, A PractitionersApproach, 3rd ed. (New York:McGraw Hill, 1992).

[4] Test and Evaluation, U.S. GeneralAccounting Office Report GAO/NSIAD-93-198, September 1993.

LCdr Brown is a software engineer inDMES 5.


Fuel Cells and the NavyArticle and Illustrations by: LCdr MJ. Adams, CD, MEng, P.Eng.

For the past several years the navy hasbeen supporting Canadian industry in thedevelopment of electro-chemical tech-nologies. Figure 1 depicts the three basictypes of electro-chemical power systems,which depend on anodes, cathodes and anelectrolyte to enable their respectivereactions. They are:

the battery, which stores energy withinitself through electro-chemical poten-tial between an anode and cathode;

the Semi-Fuel Cell, which producesenergy from a chemical reaction be-tween a fuel (stored internally as theanode) and an oxidant (stored exter-nally and fed to the cathode); and

the Fuel Cell, for which a hydrogen-based fuel and oxidant are stored ex-ternally and fed to the fuel cell'sanode and cathode, respectively, toreact and provide energy.

DND's efforts have focused on thedevelopment of two of these technologies:the proton-exchange membrane fuel cell(PEM FC) and the aluminum/oxygensemi-fuel cell (sFC). The rationale forDND interest in these emerging technolo-gies can be distilled to a single element:process efficiency. Both technologiespromise system efficiencies in the 50-percent region, compared to the average 25-percent overall system efficiency of thermalsystems. Theoretical fuel-cell efficienciescan reach as high as 70 percent.

PEM Fuel CellFigure 2 shows a basic proton-ex-

change membrane fuel cell. A fuel cellcombines hydrogen and oxygen (in aprocess which is the opposite of the elec-trolysis of water) to produce energy, withits by-product being water. It works asfollows. A catalyst at the anode causesthe following reaction:

H2—> 2e +2H*

The protons (FT) migrate through themembrane, which is an electron insulator.This forces the electrons (e) through theexternal path, i.e. the load. At the cath-ode, the electrons recombine with theprotons and oxygen to form water:

2e +2H+ + 1/2O2—>H2O

There are several options for storingthe hydrogen fuel. It can be stored in its

pure form as a high-pressure gas, a cryo-genic liquid or in a metal hydride. An-other option is to derive the hydrogenfrom a hydrogen-rich substance such asmethanol (CH3OH), one litre of whichcontains 1.4 times as much hydrogen asthe same amount of liquid hydrogen.

It is for this reason that we have se-lected the latter method for hydrogenstorage. Methanol is catalytically brokendown, or reformed, into hydrogen for thefuel cell, with carbon-dioxide as the by-product. This method has much simplerstorage requirements and gives the high-est system energy density, even thoughthe presence of a "reformer" reducespotential system efficiency from 70percent to 50 percent. This still equatesto twice the fuel efficiency of a corre-sponding thermal system. For instance, afuel-cell generator would require onlyhalf the fuel and oxygen of a comparablediesel generator to produce the samepower, and would produce only half thecarbon dioxide.

Since the fuel-cell system does notactually burn the fuel, there are certainadditional benefits:

• the reforming process is cleanerand does not produce hazardousby-products, such as nitrousoxides;

• the reforming process does notneed high-calorific-value fuel; thispermits a much wider range offuels for a fuel-cell system, makingit easier to design a multifuel-capable system; and

• the ability of the fuel cell to usemethanol greatly enhances its envi-ronmental appeal, since methanol isa synthetic, hence renewable, fuel.

A1/O2 Semi-Fuel CellThe basic aluminum/oxygen semi-fuel

cell can be described as a hybrid betweena fuel cell and a battery. A helpful way ofunderstanding this system is to envisionthe aluminum as an electron storage de-vice in which electrons are stored in themetal during the refining process andreleased during the oxidation process.

Figure 3 illustrates this relationship.Bauxite is refined into aluminum, usinglarge quantities of power. An intermedi-ate stage in the refining process producesaluminate (A1(OH)3) which is then fur-ther refined into a pure aluminum alloy.This alloy is used as the fuel in the semi-fuel cell, where it undergoes controlledcorrosion, releasing about 50 percent ofthe energy used in the refining process.The aluminate by-product can be re-refined back to aluminum. The aluminate,


Electrolyte

Anode Cathode

BATTERY

0, or Air

ElectrolyteH,

Anode Cathode

SEMI-FUEL CELL

0,or Air

Electrolyte

Anode Cathode

FUEL CELL

Fig. 1. Basic Electro-Chemical Power Systems

by the way, is an inert product which,among other things, is used as a mainingredient of tooth paste.

Figure 4 shows a basic A1/O2 semi-fuelcell. The abbreviated mechanism of thealuminum/oxygen energy conversionprocess consists of a catalyst at the cath-ode, reducing water in the electrolyte andthe supplied oxygen into OH , or hy-droxyl, ions:

3O 6H2O 12e — > 12OH

The electrolyte passes these ions tothe anode where they react with the alu-minum to provide the electrons, hencethe power to the load:

4AI + 12OH — > 4AI(OH)3 + 12e

The aluminate by-product can eitherremain in solution in the electrolyte, orprecipitate out of solution. Since themanagement of the electrolyte has adirect impact on the overall system en-ergy density, three management systemsare currently under development.

Figure 5 summarizes these three ver-sions. The simplest system consists ofmaintaining the aluminate ions in solu-tion in the electrolyte. This solids-freesystem is basically a pumped systemwhereby the electrolyte is stored in acommon reservoir and pumped to eachcell. There is sufficient electrolytevolume to prevent the aluminate ionsfrom precipitating out of solution.

One way to increase the energy den-sity of this type of system is to deliber-ately precipitate the aluminate out of

solution. This has the effect of maintain-ing electrolyte conductivity, hencepower production, while reducing therequired volume of electrolyte. Onevariant of this strategy being developedis an unpumped self-managed system,whereby each cell contains its own elec-trolyte and reservoir. As each "self-managed" cell is discharged, thedissolved aluminate ions supersaturateand self-precipitate out of solution tosettle at the bottom of the reservoir.

A second precipitating system variant,the solids-managed system, is a pumpedprocess that actively precipitates the

aluminate out of solution. It does this byseeding the electrolyte, which increasesthe size of the aluminate precipitateparticles. A settling tank is incorporatedto provide sufficient settling time toenhance higher packing densities.

These modifications result in a sig-nificant increase in system energy den-sity. A typical aluminum-air sFC, forexample, has more than ten times theenergy density of an equivalent bank oflead-acid batteries. In other words, ansFC system requires only one-tenth thevolume of a bank of lead-acid batteries.

The fuel cell and the semi-fuel cellsystems both have the added advantagesof low-noise operation, reduced infra-redsignature, modular design and fuels whichare either recyclable (sFC) or renewable(methanol). The systems are Canadian,and the two companies involved in devel-oping them are world-leaders in theirrespective technologies: AlupowerCanada Ltd."1 of Kingston, ON (alumi-num-oxygen semi-fuel cell); and BallardPower Systems Inc. of North Vancouver,BC (proton-exchange membrane fuelcell).

Fuel Cell ApplicationsThe navy is currently developing

these electro-chemical technologies foruse in:

• unmanned underwater vehicles;, . , .

• ship s service generators; and

• air-independent power.

REFORMER

H.O

FUEL CELL

CH,OH

Anode Cathode

Fig. 2. Basic PEM Fuel Cell


ENERGYIN

ENERGYOUT ALUMINUM

ALLOY

Fig. 3. Semi-Fuel Cell Energy Conversion

Unmanned Underwater VehiclesUnmanned underwater vehicles

(UUVs) and autonomous underwatervehicles (AUVs) are becoming more andmore important to naval forces. UUVstypically have an umbilical cord for elec-trical power and/or communications (Fig.6), and an onboard power source. Themore versatile, free-swimming AUVs areentirely self-contained. As the technologi-cal capabilities of these vehicles in-creases, so does their suitability forlonger duration missions which require agreater onboard supply of energy.

Most AUVs operate on lead-acid ornickel-cadmium batteries, which severelylimits their submerged endurance. Al-though higher performance batteries, suchas silver-zinc batteries, are becomingavailable, they have limited cycle life, areextremely expensive and are difficult tocharge. To fully utilize the increasedcapabilities of modern AUVs, a enhancedendurance power system is required.

To this end the navy has been support-ing Alupower in developing a powersystem for small underwater vehicles.Alupower has developed a 2-kW, 54-kWhr system for the navy's AutonomousRemote Controlled Submersible (ARCS)AUV, using decomposed hydrogen per-oxide as the oxygen source and a "solids-free" electrolyte management system. TheARCS submersible, which is 27 inches indiameter and 15 feet long, operates on ni-cad batteries which give it a maximumendurance of six hours. The Alupowersystem was successfully trialled at sea in

June 1994, achieving a 30-hour endur-ance (a five-fold increase). Alupowerhas also modified the current ARCSpower system into a "solids-managed"system. A bench-top version of thissystem trialled in March 1994 delivered54 hours of power — a nine-fold in-crease in endurance.

Figure 7 shows a comparison be-tween typical UUV power sources. Thedensities shown represent installedweights and volumes for the Alupowersystems, and best estimates for those ofother power sources. It quickly becomes

apparent that aluminum power sourceshave much to offer UUV developers.Gravimetric energy densities are betweensix and 10 times greater than lead-acid,and five to eight times that of ni-cadbatteries. Volumetric energy densities aretwo to four times better than lead-acid.

Investigations are currently underway todetermine how the navy can best continuethe development of this promising technol-ogy. Assuming the technology remains inCanada"1, it is tentatively planned to furtherdevelop the "solids-managed" ARCSpower system and perform another set ofsea trials as resources permit.

Ship's Service GeneratorsThe second area the navy is investigat-

ing is the application of PEM fuel cells toship's service generators (SSGs). We areapproaching this applicationfrom two angles — technology andrequirements.

On the technology side Ballard isstudying how much better a fuel-cellship's service generator would be over adiesel SSG. The efforts are being focusedon an 850-kW SSG that will be directlycompared to the 850-kW diesel SSGfitted in our patrol frigates. The study,which is expected to be completed byMarch 1995, will address such issues asthe use of multifuel operation: i.e metha-nol, for when the ship is in waters con-trolled by stringent discharge restrictions;and JP-5 or marine distillate for morerelaxed operating conditions. Hardwaredevelopment projects are being planned

current collector

carbon/resinhydrophilic layer

carbon/resinhydrophobia layer

ANODE / CATHODEELECTROLYTE

Fig. 4. Basic AI/O Semi-Fuel Cell


SOLIDS-FREE

SELF-MANAGED

SOLIDS-MANAGED

KOH

AI(OH), AI(OH),

Fig. 5. Electrolyte Management Systems

for after the study to refine the PEMtechnology for SSG applications.

On the requirements side DMEE 6 willcommission a study next spring to de-velop a ship-configuration optimizationprogram for patrol frigate SSGs. Thestudy will quantify how much better afuel-cell SSG has to be to justify theexpense of changing-out one or morediesel generators, and investigate theimpact of replacing one or more SSGs.The study will enable us to play out"What if?" scenarios to determine theoptimal configuration and associatedcost benefits.

Air-Independent Power (AIP)

DND began its proactive role in AIPdevelopment by commissioning Alupowerand Ballard to report on the feasibility ofapplying their technologies to AIP. Thestudies, which were completed in March1992, showed that both technologies werefeasible and that neither technology wasclearly superior to the other in the AIPapplication.

In the two years that followed wecontinued to fund the development ofthese technologies and prepared for amajor R&D project for an AIP explor-atory development model, or XDM. In-volved is the development of two 40-kWAIP technology demonstrators: a proton-exchange membrane fuel-cell systemusing reformed methanol for its fuel, andan aluminum/oxygen semi-fuel cell sys-tem. Unfortunately, Alupower's sale to aU.S company eliminated them from the

XDM project. A $3.7-million XDMcontract is now in place with BallardPower Systems Inc., with a December1996 completion date.

One novel application of an AIP sys-tem using PEM fuel cells is a regenera-tive power system being developed byNASA for a manned moon base. DND iscontributing 20 kilowatts of Ballard fuel-cell stacks to the system, the basics ofwhich are shown in Fig. 8. During thetwo-week lunar day a solar array willpower the moon base and electrolysestored water into hydrogen and oxygen

for storage and later use. During the lunarnight the fuel cells will use the storedhydrogen and oxygen to produce powerfor the moon base. The water by-productwill then be stored for use during the nextlunar day, and so on. The Ballard stacksare ready for delivery to NASA and it isexpected that this system will be up andrunning at the let Propulsion Laboratoryin Pasadena by early 1995.

Related Projects

Several other related projects are sup-porting our fuel-cell application work.Royal Military College has been workingclosely with DMEE to enhance our un-derstanding of these exciting technolo-gies. Another project consists of thedevelopment of the Hybrid SubmarinePropulsion System software model,which will model the integration of anAIP system with a conventional subma-rine propulsion system. We want to get anidea of how these two active power sys-tems will interact.

Conclusion

The DND approach to the develop-ment of these promising technologies hasobviously paid dividends. Both compa-nies are recognized as world leaders intheir respective technologies and DNDnow has several opportunities to refinecutting-edge technologies for implemen-tation into the fleet.

The next challenge is to maintain themomentum in the development of thesetechnologies and their application to

UUV-Power &Comms

•••L tether

UUV - Comms onlytether

Fig. 6. UUV/AUV Relationships


GRAVIMETRIC ENERGY DENSITY VOLUMETRIC ENERGY DENSITY

Fig. 7. UUV Power Source Energy Densities

DND requirements. While the commer-cial sector can now maintain the devel-opment of these technologies, DNDmust still participate to ensure DND'srequirements are addressed. &

Note[1] At the time of writing, Alupower

was in the process of being soldby its parent company, AlcanInternational, to the U.S. batteryfirm, Yardney. It is not yet knownif or how DND can continue itsCanadian developmental effortsof the sFC system.

MainPower

Fig. 8. Regenerative Power System

LCdr Adams is the DMEE 6 project officerfor air-independent power.


East Coast MARE Seminar 1994Article by Lt(N) Brad Yeo

The East Coast MARE communityheld its annual seminar at the RamadaRenaissance Hotel in Dartmouth on April20 and 21. The theme for this year'sseminar was "Lessons Learned." Each ofthe presentations shed new light on amajor engineering event as we looked atwhat happened, what went wrong andhow we could avoid a repeat occurrence.

During the opening remarks RAdmL. Mason, Commander MARLANT, saidthe challenge for the navy was to becomecritically self-analytical in everythingit does. In a similar vein, CmdreD.G. Faulkner (MARL N4) challengedus to examine our leadership responsibili-ties toward NCMs, both individually andas a community. From an NDHQ perspec-tive, Cmdre R.L. Preston (DGMEM)highlighted the critical introspection hisdivision must face in dealing withDGMEM's downsizing and restructuring,and with the expected associated reduc-tion in engineering change.

Capt(N) R. Buck (D5) presented anoperator's viewpoint, suggesting thechallenge to the engineering communityis to become flexible and innovative. In acontroversial presentation he suggestedMAREs should learn to overcome theirperceived tendency to avoid risk. Riskavoidance, he said, will be unacceptablein the face of reduced resources, short-notice operations, a higher operationaltempo and a focus on core operationalcapacity. As we begin to accept some riskin the way we do business, the changeprocess will have to become more flex-ible to define requirements and respond tothem more rapidly.

On the materiel management side,Maj Marty Burke (DMAS 5) describedthe cost-avoidance value of effectivetransition management in major capitalequipment projects. Citing from the filesof a number of major projects, he re-viewed some of the difficulties encoun-tered in transferring system managementresponsibilities from a project manage-ment team to the matrix.

CPF Construction: Experience GainedCapt(N) B. Blattmann and Cdr V.

Archibald described how CPE's ad-vanced ship-construction techniques and

strategies have recouped initial overrunsto make the project a success story. Theyreviewed the lessons learned regardingthe design and contractual processes,focusing on the benefits of advancedship-construction methods, the hindranceof negative guidance in the design pro-cess and the need for a realistic lead-shipstrategy.

The presenters took us through theprogression of methods and designchanges — from the 26 constructionunits of HMCS Halifax to the ninemegamodules of HMCS Charlottetown— associated with CPF construction.They also explained how negative guid-ance impedes a team approach, and howtoo short an interval between the start oflead-ship construction and that of follow-on ships does not allow enough time toprofit from lessons learned from the firstof class.

Algonquin FloodIn a lively, humorous presentation,

LCdr S. Lamirande described theevents surrounding the incident of No-vember 15, 1991 when HMCSAlgonquin accidentally flooded during aheeling trial. The ship's EO at the time,LCdr Lamirande punctuated his remarkswith personal, witty observations as heshared the human and technical lessonsof the incident.

The human lessons focused on thefailure by all agencies to recognize theproblem, the lack of a clear understand-ing of who was in charge during the trial,the distraction of secondary duties duringthe preparation phases, the excellentvalue of damage-control and section-base team training, and the personal riskstaken to save the ship.

Technically, it was relearned thatsubmersible pumps are not interchange-able between steamships and tribals, andthat the tribals have no overboard dis-charge for submersibles on No. 2 andNo. 3 decks. Also, the messdeckcentreline drains could not be used todraw water from those spaces when theship was listing. The TRUMP ships,LCdr Lamirande said, could benefit froma cross-connect for the pre-wet pumps.

New Submarine Engine OverhaulProcedures

After a brief commercial message forthe U.K.'s new Upholder-class subma-rines, LtCdr P.J. Southern, RN enter-tained us with a presentation preparedwith LCdr W. Nesbitt on the new en-gine-overhaul procedures for subma-rines. The highlight was the technicaldescription of how HMCS Ojibwa wascut in two to remove her main enginesand generators for overhaul. LtCdrSouthern showed the first part of a videobeing produced by Base Photo to docu-ment the procedure, as well as a video ofa similar repair in the U.K. He thor-oughly discussed the risks associatedwith the RxR of the main engines ina submarine.

The seminar also included well-re-ceived presentations on: the Naval E&MFunctional Review (LCdr Findlay —MARCOM); ICEMaN and Configura-tion Management (Lt Bedard and LtBoulet — FMG, and Debra Burke —DMES 6); Accountability: Case Studyof ECPs (LCdr Guyot — NEUA);Apocalypse II: The UNTAC Experience(Lt Doma — DMCS, and Lt Mack —CFFSH); and the Cormorant breathinggas incident (Mr. S. Dauphinee —NEUA, and LCdr Woodhouse and LCdrMuzzerall — FTO).

In his closing remarks CmdreFaulkner emphasized the need to criti-cally analyze our leadership in thesetimes of restraint. He also took time torebut Capt Buck's comments regardingrisk-taking, reminding the community ofits function to minimize the risks ourMARS brethren face when they sail intoharm's way. «

Lt(N) Yeo is the Machinery Control SystemsSoftware Officer for the MSE Division ofNEUA.


Greenspace: Maritime Environmental Protection

A Solid Waste Pulper for the NavyArticle by Mario Gingras

A ruggedized solid-waste pulper hasbeen procured for operational evaluationby the Maritime Environmental Protec-tion Project (MEPP). The pulper will befitted on board HMCS Preserver, likelythis fall, to test the system in the marineenvironment and to establish a standardfor future permanent installations. Adedicated compartment will be con-structed in the after, starboard side ofPreserver's dispersal area on 01 deck.The MEPP will eventually purchasesolid-waste handling equipment forthe fleet.

The pulper, which was designed anddeveloped by the U.S. Navy, processesorganic solid waste (food, paper andcardboard) into a negatively buoyantslurry for overboard discharge in accor-dance with international regulations. Thepulper is a marine version of a commer-cial unit and works like a giantgarborator. The operator dumps wasteinto the feed tray and pushes it into apulping chamber where it is mixed withsea water and drawn down to be pulver-ized by a number of cutting blades fittedto a rotating impeller. The oatmeal-likeslurry is evacuated through a screenedring surrounding the blades by a drain-line suction induced by an eductor.

The unit is designed to resist damagein case trash sorting errors allow metal,glass or other non-pulpable material intothe machine. Metal and glass debris areshunted to a "junk box" which must beemptied manually. Plastics are partiallyshredded and, to some degree, retainedwithin the pulping chamber for manualremoval. During trials a metal officewastebasket thrown into the pulper madeit through without so much as scratchingthe cutting blades. (The wastebasketdidn't fare nearly as well.) The unit in-corporates numerous safety features toprevent sailors from "processing"themselves.

The pulper is an improvement overthe presently fitted garborators, and alsopermits the processing of paper andcardboard. The large feed tray and tankopening allow bulky waste to be dis-posed of with a minimum of pre-process-ing. The unit can pulp 450 kg/hr of foodwaste, or 225 kg/hr of paper and card-board, which amounts to handling thenormal daily output of an AOR in justover an hour of operation. A smaller unitis also under consideration.

Pulping solid waste will improveoperational flexibility, as well as mini-mize health and safety hazards for ship'scompanies by allowing most organicwaste to be safely and legally dischargedeven in restricted waters. The pulperrepresents a step toward eliminating thedischarge of unprocessed solid wastematerial into any body of water. *

Mario Gingras is the DMEE 5 projectengineer for the navy's solid-waste pulper.

A pre-production prototype of a shipboard solid-waste pulper is put through itspaces at the U.S. Naval Research Laboratory in Annapolis, Maryland.


Looking B

Canada's first astronaut (and MARE) in spaceUpdate by Brian McCullough

The date was Oct. 5, 1984. Thevehicle — the NASA space shuttleChallenger (Mission 41-G). The astro-naut, of course, was Cdr Marc Garneau.

Ten years ago this month Garneau,who was a navy Combat Systems Engi-neer at the time, made headlines bybecoming the first Canadian to belaunched into Earth orbit. He flew as apayload specialist on board the shuttleChallenger, which made headlines of itsown a year and a half later when it ex-ploded on January 28, 1986, killing allseven of its crew.

"I can't believe ten years have goneby," Garneau, 45, said during a tele-phone interview from Houston a weekbefore the anniversary of his flight. "I'mten years older of course," he chuckled."They (the Canadian Space Agency) aregoing to make a bit of a fuss and I'mthrilled," he said of plans for him tomake publicity tours to Montreal, Ot-tawa and Toronto in early October.Garneau said he enjoys living in Hous-ton, but misses the change of seasons."Weatherwise, I'm a Canadian to thecore," he said.

Garneau remained with the CanadianAstronaut Program following his flight,but retired from the navy as a captain in1989 (see MEJ January 1989, page 30).In August 1993 he and colleague ChrisHadfield became the first Canadians toqualify as mission specialists, whoseprime responsibility would be the in-flight operation and repair of orbitersystems including the Canadarm.Garneau himself has now been trainedon the Canadarm, as well as in rendez-vous operations and extra-vehicularactivity (spacewalking).

"By some quirk of circumstance I'vecompleted all the optional training,"Garneau said. "They (NASA) take theapproach they want everybody trained ineverything." The former MARE has thedistinction of being the oldest person tostart training as a mission specialist inthe history of the program. "I think for

/' „/ :


Canada it's increasing our credibility tohave our people trained (to professionallevels)."

With a mission specialist qualificationunder his belt Garneau can expect toreceive a flight assignment in three tofour years. "I think that's in the cards,"he confirmed. "I might get assigned to amission." It helps, he said, that he hasalready flown a mission. Hadfield isscheduled to fly on mission STS-74next year.

Garneau is currently working on tech-nical issues for the Astronaut OfficeStation-Exploration Branch. As a mem-ber of the Robotics Information team hehas technical input to a space stationremote manipulator arm, and said he is

very proud of the Canada's role in that."It's very important to have a Canadianpresence down here," he said.

Garneau is the first non-American toassume the duties of Capcom (capsulecommunicator) — the sole voice-linkbetween astronauts in an orbiting shuttleand scientists and mission controllers onthe ground. "I've been assigned toCapcom for missions through to nextsummer," Garneau said. He will be thelead Capcom for Mission STS-66.

Garneau's enthusiasm for his workwith the manned space program is infec-tious. "It's a fabulous job," he said. "It'san exciting business to be in if you're anengineer...It's a great place to be work-ing — it's exhilarating."

And what's the best part of it all?"The chance to rub shoulders with somevery interesting people." •


News Briefs

1993 MARE AWARDS

Submitted by LCdr Jim Dziarski, CFFS/NES HalifaxCFB Halifax Photos by Cpl. C.H. Roy

CAE AwardsCongratulations to CAE Awardwinners Lt(N) Bruce Trayhurn (right)and Lt(N) Eric VanGemeren. Bothofficers received a plaque and two-volume Marine Engineering ReferenceLibrary, donated by CAE Ltd., fortaking top marks in the shore phase oftheir respective MARE 44Bapplications courses in 1993.

Westinghouse Awards

SLt J.P. Laroche and SLt Eric Tremblay receive the Westinghouse Award from company representative Robert Dufault inrecognition of their professional excellence during Phase VI (Ashore) CSE training in 1993. The presentations included aplaque and a set of binoculars. Congratulations to both officers.

24MARITIME ENGINEERING JOURNAL, OCTOBER 1994

Paramax AwardLt(IM) Norbert Duckworth receives the1993 Paramax award from Capt(N)(Ret.) Bruce Baxter of ParamaxElectronics. The award recognizes thetop CSE candidate achieving MARE44C qualification in the previous year.Bravo Zulu to Lt(N) Duckworth (whoreceived a plaque and naval sword)and to the other finalists.

Peacock AwardMETTP graduate Lt(IM) Ken Squirereceives the 1993 Peacock Award forexcellence in MARE 44B training fromPeacock Inc. president and CEO BrianEmo. The award of a plaque andnaval sword is made to the MARE 44Bgraduate who demonstrates the bestoverall performance in a calendaryear during sub-MOC training. BravoZulu, Ken.


;". :-:/'-'••.:; • " • : : " I '"'-'""''Sir;"^--''-'' '^-"-•'M. | -: • : : "wi1;-;":-;--'

careful are you withgrounds?

OPIs should ensure that the require-ments for electrical interfaces are care-fully defined in procurement andinstallation specifications for new sys-tems, equipment or modifications. Thecruise engine controls on the TRUMPships have had to be modified to correcta power ground and to isolate the digitalsignals from the analogue signals. Agood number of stand-alone relay boxeshave been installed in the TRUMP shipsto get the correct interface between userequipment such as the Allison 570 Elec-tronic Control Unit and the IntegratedMachinery Control System.

Unlike utility power systems, or somecommercial marine power systems, thepower systems on navy ships are de-signed to be electrically ungrounded (i.e.isolated from the hull) to enhance reli-ability (see General Electrical Specifica-tions D-03-003-005/SF-000). Any userequipment that causes a ground duringnormal operation will degrade the reli-ability of the power system to which it isconnected. Problems in the past havebeen largely confined to diesel or gasturbine controls which, if of amanufacturer's standard, may be basedon the industrial practice of using theengine structure as a power return.

Also, digital and analogue signals toan external system must be electrically

isolated from one another and from thepower circuits. Such isolation allows thesignals to be connected to the externalcontrol and monitoring system withoutrunning the risk of ground loops (cou-pling between different signals) orgrounding the ship's power supply.Ground loops due to a difference inground potential, or inadvertent cou-pling, can cause malfunction of not onlythe offending equipment, but of otherequipment or systems as well. Problemsof this type are difficult to identify, par-ticularly if they are infrequent and occurin a ship-wide system controlling a largeinventory of user equipment. — W.A.Reinhardt and G. Swamy, DMEE 6. 4

Long Service Awards!

Long-service award recipients Maureen Collins (44 years of service) andCdr (Ret.) Bob MclMeilly (39 years) worked together in DSE 5 before retiringearlier this year. Cmdre Robert L. Preston, DGMEM, presented the awards lastMay 11. Congratulations to both for their years of dedicated civilian andmilitary service.

IMDEX 95:March 28-31,1995

The International Maritime DefenceExhibition and Conference, sponsoredbiennially by the U.K. Defence ResearchAgency, resumes March 28-31, 1995 atthe Greenwich National Maritime Mu-seum. The theme of the conference willbe: Creating the Naval Task Force.

Seven nations have already commit-ted to sending ships to London forIMDEX 95, with several more likely tofollow suit. No Canadian ships arescheduled to attend.

According to Capt(N) Edward E.Davie, naval adviser to Canada's HighCommissioner in London, the exhibitionand conference provide "excellent oppor-tunities to demonstrate Canadian equip-ment, technology and ideas, whilepursuing joint venture possibilities." AtIMDEX 93 held at Brighton, Canadiandefence industry, in co-operation withthe naval staff and the HighCommission's Commercial section, hadthe second-largest contingent, a

Bravo ZuluThe Maritime Engineering commu-

nity congratulates Capt(N) GerryHumby on his recent promotion.Capt(N) Humby took command of ShipRepair Unit Atlantic in June, m


UNTAC - Mission to CambodiaComing up in our February issue


Maritime Engineering Journal - Readership Survey

You can help us make the Journal better for you by taking afew moments to answer these questions.

1. What is your rank and MOC, or civilian occupation?

12. Do you retain back issues for reference?

Yes No

13. How many people read your copy of the Journal?

2. Where do you work?a. Canada

Abroad (please specify)b. Ship/Dockyard

Base/HeadquartersTraining CentreUniversity/Military CollegeMarine IndustryOther (please specify)

3. Which sections of the Journal do you usually read?a. Cover to coverb. Editor's Notes/Letters

Commodore's CornerForumOne articleTwo or more articlesGreenspace (environmental protection)Looking BackNews Briefs

4. Which sections do you enjoy most?

5. Which sections do you enjoy least?

6. On average, the articles are:Too technicalToo generalJust right

7. The non-technical and general interest articles areusually:Too detailedToo shallowJust right

8. Do you think there is a good mix of articles in eachissue?

Yes No

9. What would you like to see covered by the JournaR

10. Would you rather the Journal were mailed to units, orto individual subscribers?

11. Which audiences should the Journal target?MARE officers/cadetsMar Eng chiefs & petty officersMar Eng master seamen and belowEngineering branch retireesNon-engineering MOCs (please specify)Military/government agenciesCommercial marine organizations

14. How useful is the JournaHo you?Very usefulSomewhat usefulOf little useOf no use

15. What is your overall impression of the JournaRVery favourableFavourableNeutralUnfavourableVery unfavourable

16. In general, do you think the magazine meets its statedobjectives?Yes No (Why not?)

17. What should be the objectives of the JournaRa. As publishedb. Other (please specify)

18. Do you read the Journal in English or French?

19. How would you rate the quality of the Frenchtranslation?Can't sayVery goodGoodPoorVery Poor

20. How often should the Journal publish?

21. Can you suggest a better format for the JournaR

22. Would you pay a subscription fee to receive the Journal?Yes No

23. How can we make the Journal better for you?

Thank you. Please mail or fax your completed questionnairepromptly to:

The EditorMaritime Engineering JournalDMEE, National Defence Headquarters101 Colonel By DriveOttawa, Ontario K1A OK2

Fax: (819) 994-9929

Please reproduce this form locally.


Documents

National Defense Maritime Engineering Journal · 2017-03-06 · • Simple Steps for Effective Software Management • A Readership Survey Canada. A veritable "green machine" is about