national defense defence nationale maritime *t&

1*1 National DefenseDefence nationale

MaritimeEngineeringJournal

*t&<£V

July 1990

Canada

Update:Whatever happenedto Kootenay'sold bow?

...page 36

MARITIME ENGINEERING JOURNAL, JULY 1990

MaritimeEngineeringJournal

Director GeneralMaritime Engineering andMaintenanceCommodore W.J. Broughton

EditorCapt(N) Dent Harrison

Technical EditorsCdr Roger Cyr (Combat Systems)LCdr Rick Bracken (Combat Systems)LCdr N. Leak (Marine Systems)LCdr Darcy Byrtus (Naval Architecture)LCdr Cliff Johnston (Naval Architecture)

Production EditorLCdr(R) Brian McCullough(819) 997-9355

Graphic DesignIvor Pontiroli DPGS 7-2

Word Processing by DMAS/WPRC 4MSMrs. Terry Brown, Supervisor

Translation Services bySecretary of State Translation BureauMrs. Elaine Lefebvre, Director

JULY 1990

DEPARTMENTS

Editor's Notes

Letters 4

Commodore's Corner 5

FEATURES

NaMMS EDM - Automated MaintenanceManagement for the Fleetby LCdr R.H. Bayne, LCdr W. Dziadyk and Lt(N) J. Roop 7

AAW Computer Modelling of CPF and TRUMPby Michel Beaulne and Greg Walker 13

U.S. Navy Ship Shock Trial:An Observer's Accountby Ole Bezemer 18

Authors' Proposal:A Naval Reserve NCM Engineer Training Planby Lt(N) Dave Marecek and PO1 Ken Quick 20

Why Ada Makes Good Senseby Cdr Roger Cyr 25

FORUM 29

LOOKING BACK : DDH-205 Destroyer Towing Incident 33

NEWS BRIEFS 34

OUR COVERDomenic Racanelli, NETE system managerfor the NaMMS EDM (see story inside),explains VMS operating system commandsto MSET Jim Green and P2 Gilles Desrosiersof HMCS Huron. (CFphoto by Cpl RichardSirois, Base Photo Esquimalt)

The Maritime Engineering Journal (ISSN 0713-0058) is an authorized, unofficial publication of themaritime engineers of the Canadian Forces, published four times a year by the Director General Mari-time Engineering and Maintenance. Views expressed are those of the writers and do not necessarilyreflect official opinion or policy. Correspondence can be addressed to: The Editor, Maritime Enginee-ring Journal, DMEE, National Defence Headquarters, MGen George R. Pearkes Building, Ottawa,Ontario, Canada K1A OKI. The editor reserves the right to reject or edit any editorial material, andwhile every effort is made to return artwork and photos in good condition the Journal can assumeno responsibility for this. Unless otherwise stated, Journal articles may be reprinted with proper credit.


Editor's NotesThe investment is paying offKeep those cards and letterscoming in. . .

We've done it! After eight years ofpublication the Maritime EngineeringJournal has officially gone quarterly.Only three issues will appear during thiscalendar year, but the publication of theissue you are reading now marks thebeginning of our new quarterly produc-tion schedule. From here on in we'll bebringing you the Journal four times ayear — in January, April, July andOctober.

This is a significant milestone for usbecause it marks the achievement of agoal that was set back in 1985. That wasthe year the Journal began publishingthree times a year after being redesignedinto more or less the format we seetoday. In the five years since then theeditorial staff has been steadily groom-ing the Journal and streamlining itsproduction process to make quarterlyproduction of our branch journal areality.

So why a quarterly. Well, it might in-terest you to know that we did not stepup publication to accommodate an in-creasing number of article submissions.To the contrary, when the Journal wasstarted along this path five years ago,there was some concern we wouldn'treceive enough articles to "fill" fourissues every year.

What was certain, however, was thatthe Journal had to be made more acces-sible to the membership it serves. Breaksof even four months between issues werejust too long for the magazine to func-tion properly as a working journal ofCanadian maritime engineering activity,ideas and concerns. It would have to ap-pear at least quarterly. So we pressedon, believing that somehow enougharticle submissions would find their wayinto our mail-bag.

As it turned out, the supply of arti-cles was the least of the worries. Con-tributions have reached the point nowwhere we must produce four issues ayear just to accommodate them allwithin a reasonable time frame. This istremendously encouraging, especiallysince we're beginning to see some fairlystrong feedback to articles published inrecent issues. If ever proof were neededof the Journal's importance within themaritime engineering branch, few thingscould be more convincing than thepresent demands for publishing space.

And finally, as I prepare to leaveDMEE and the Journal to take up mynew posting as Director of Military Pro-gram Planning in NDHQ, I would liketo extend farewell best wishes to threesenior MAREs who will be retiring thissummer: Rear-Admiral D.R. Boyle(Chief of Engineering and Main-tenance), Commodore Ed Bowkett(Project Manager Canadian SubmarineAcquisition Project) and CommodoreBill Broughton (Director GeneralMaritime Engineering and Main-tenance). These officers deserve the con-gratulations of the maritime engineeringcommunity for their many years of dedi-cated and meaningful naval service.

Our thanks go to Captain Harrison forthe discerning editorial direction andguidance he provided during the pasttwo years, and we extend to him our bestwishes for a successful term with his newdirectorate. (The editorial staff)


Cmdre E.G.A. Bowkett

Cmdre W.J. Broughton


Letters to the Editor

Dear Sir,

Thank you for sending me the(January/April issue) of the MaritimeEngineering Journal. I especiallyenjoyed the article on the HMCS Koo-tenay collision repair as I was workingat NEU(P) when this work was done.

Slt(R) Bruce TrayhurnHMCS Unicorn

Saskatoon, Sask.

Dear Sir,

A short while ago I had occasion toread an article in the April 1989 editionof the Maritime Engineering Journalentitled "Naval Officers as Program-mers - A Wasted Resource" by CdrRoger Cyr. Being the present courseofficer for the Advanced ProgrammerAnalyst course at the Canadian ForcesFleet School in Halifax, I am opposedto much of the content of this article.Accordingly, I am enclosing a paperwhich looks at Canadian naval pro-grammers from a different perspective.

Lt(N) C.P. ConradAPA Course Officer

CF Fleet School, Halifax

(Lt Conrad's paper and other commen-taries appear in the Forum section ofthis issue. - Ed.)

Dear Sir,

We write this letter to explore certainaspects of professional engineeringwithin the DND.

Provincial statutes (in Ontario "TheProfessional Engineers Act") requirethat no person shall practice engineeringin the province without licensure as aProfessional Engineer. This requirementis cascaded from a federal statute whichrequires the provinces to enact suchlegislation, but exempts employee engi-neers of the federal government fromcompliance with the licensing requi-rement.

To quote from the Ontario Act, Arti-cle 2.(3) : "The principal object of theAssociation is to regulate the practice ofprofessional engineering and to governits members, holders of certificates ofauthorization, holders of temporarylicences and holders of limited licencesin accordance with this Act, the regula-tions and the bylaws in order that thepublic interest may be served and pro-tected." Clear evidence of the results ofthis activity are reflected in the bi-monthly APEO journal "EngineeringDimensions," with its publishing of dis-ciplinary actions against members.

Specific obligations under the Actinclude compliance with a Code of Pro-fessional Conduct, a Code of Ethics,and Performance Standards (OntarioRegulation 538/84 Sections 86, 91, and9la). To quote from a letter issued bythe Order of Engineers of Quebec :"...the engineer must affix his seal andsignature on plans and specifications,sign reports and studies which he hasprepared himself or which have beenprepared by a non-member, under hisimmediate supervision. By performingsuch an act the engineer commits hisentire responsibility relative to any faultresulting from his work."

There is no provision in the Actexempting licensed Professional Engi-neers from the requirements of the Actshould they happen to work for thefederal civil service.

The apparent contradiction is this:even though many engineers within theDND are licensed "P.Eng." (or "ing."in Quebec), we are not necessarily com-pliant with all of the requirements of theAct.

It would seem that the situationwithin the federal civil service creates anenvironment where incompetent andnegligent engineers could continue towork, and escape responsibility andaccountability for their actions.

A further complication arises in theMARE community as many of ournumber are relocated to different pro-vinces on a regular basis. Should we beseeking to be relicensed every time thishappens? An unworkable situationwould result.

The opinions of the readership aresolicited.

G.E.Clunis, P.Eng., ing.(formerly) DMEE 2-7-3

M.L. Gingras, ing.DMEE 2-3-4


Commodore's CornerThe View from Washington

-

By Commodore E. Lawder

I was delighted to be asked to writethe Commodore's Corner for this issue.The last time I had the honour was in1985 when I was COSMAT in MaritimeCommand. In that last job I was verymuch in a "technical" position so therewas some logic to appear on this augustpage. Other than having "grown up" asa MARE, you may ask what are mycredentials now for this honour since Iam the Canadian Forces Naval Attache(CFNA) in Washington. Good question!Let me try to explain and then go on togive you some insights from "the mostimportant capital in the world" as ourhosts would have us believe.

By far the greatest number of navalattaches have been MARS officers.When VAdm Hotsenpiller was in thePersonnel Branch he actively promoteda concept of "Best Sailor" for a num-ber of "Naval Operations" and "NavalEngineering" jobs, meaning they wouldbe filled by either MARS- or MARE-background officers. The Naval Attachejob became one of those. From my ex-perience, I can say that this job is oneof the most gratifying and interestingjobs available to our MARE com-munity.

What makes this job so interesting?On maritime matters for our navy, theNaval Attache Section is one of the maindoors into the U.S. Navy. On behalf ofour navy, we deal with the "technicali-ties" of engineering and operations mat-ters. Where Canadian interests arejeopardized, we also deal with substan-tial issues at the diplomatic and politi-cal level. A current example concerns amaritime boundary dispute.

The CFNA staff's most importantinternational activity is bilateral andmultilateral relations with the USN. Ouraccreditation and location in Washing-ton allow us to know with whom todeal, and therefore, who can best help

us with Canada/U.S. Navy problems.At the direction of MARCOM orNDHQ, we can conduct discussionswith the USN on an attributable basiswhich could lead to bilateral agree-ments. More importantly, though, wecan conduct discussions on a non-attributable basis which can set the stagefor agreements important to our navalinterests. In cases like these, it isvital to look one's counterpart in the eyeto judge if he is hiding something, isbluffing or is sincere about a commoninterest. Often, the opportunity to dothis arises on short notice, and to seize

the opportunity means the difference be-tween capitalizing on it or missing it.This can only be done from Washington.

The importance of the relationshipbetween the Canadian navy and theUSN should not be minimized. TheUnited States is our strongest ally and,compared to us, they have the ability toaddress problems with overwhelmingresources. Canada can benefit fromclose ties if we have a common goal orinterest. There is great potential forcooperation and greater payoff forcooperation that is successful. Notwith-


MARITIME ENGINEERINGJOURNAL OBJECTIVES

• To promote professionalism among mar-itime engineers and technicians.

• To provide an open forum where topicsof interest to the maritime engineeringcommunity can be presented and dis-cussed even if they may be controversial.

• To present practical maritime engineer-ing articles.

• To present historical perspectives on cur-rent programs, situations and events.

• To provide announcements of programsconcerning maritime engineering per-sonnel.

• To provide personnel news not coveredby official publications.

WRITER'S GUIDE

We are interested in receiving unclassi-fied submissions, in English or French, onsubjects that meet any of the stated objec-tives. Final selection of articles for publi-cation is made by the Journal's editorialcommittee.

Article submissions must be typed,double spaced, on 8 1/2 x 11" paper andshould as a rule not exceed 4,000 words(about 17 pages). The first page mustinclude the author's name, address andtelephone number. Photographs or illus-trations accompanying the manuscript musthave complete captions. We prefer to runauthor photographs alongside articles, butthis is not a must. In any event, a shortbiographical note on the author should beincluded with the manuscript.

Letters of any length are always wel-come, but only signed correspondence willbe considered for publication.

standing, the USN is a big self-interestedbureaucracy where often the left handdoesn't know what the right hand is do-ing. They have relationships with manyother navies and their attention to anysingle small navy is therefore limited.CFNA's job is to lobby the USN, andif necessary the Congress, on behalf ofour Canadian naval interests to keep im-portant Canadian issues in the forefrontof their attention.

The Naval Attache staff can quicklyrespond to Canadian naval interests. Bytelephone, we handle a high volume oftechnical queries and a high volume ofinformation on diverse subjects rangingfrom barbershop chairs to "poopysuits" for submariners. We are the"guardian" for many InformationExchange projects and memoranda ofunderstanding. We provide support tomajor Crown projects like CPF andTRUMP by monitoring Foreign Mili-tary Sales projects for weapon and sen-sor systems. We also provide supportthrough the Commercial Section of theEmbassy to the many Canadian indus-tries which do business with the USN.

On the personnel side, the NavalAttache staff looks after the interests of84 naval officers, enlisted ranks and

civilians who work in the United Stateswith the USN. The most important taskis the review of PERs. We also carry outa major function to clear and coordinatevisits to the USN and to arrange bilateralstaff talks between our navies.

In short, there are a considerablenumber of engineering, operational,diplomatic and administrative issues ofimportance to the Canadian navy whichare woven into our relationship with theUnited States and the U.S. Navy. Theoffice of the CFNA must be proactivein these issues in order to represent theinterests of Canada and the Canadiannavy. It is an interesting and at times aformidable task. Being on CFNA staffrequires attention to a wide range ofactivities and is a challenging posting.Our southern neighbour is a friendlygiant who sometimes forgets that we arethere. Our task in the Naval AttacheSection is to see that the right offices inthe USN are prodded in order to con-vey Canada's and the Canadian navy'sinterests. The bottom line is that ourefforts are to support you in NDHQ andin Maritime Command.

A farewell messagefrom CommodoreW.J. Broughton,DGMEMJust about the time that this issue goes to distribution, I will be going onretirement leave after thirty-seven years in the navy. Since entering the RoyalRoads Military College in September, 1953 I have had numerous fortunatehappenings, have met innumerable first-class officers and sailors, and hadmany challenging and interesting appointments.

Without question, the most rewarding and satisfying appointment has beenthis last one - as DGMEM and Branch Co-Adviser for the Naval TechnicalOccupations. The support I have enjoyed has been tremendous and it is witha deep sense of gratitude that I bid farewell.

Maritime Engineering will soon be in the very capable hands of CommodoreMike Saker, and I urge you all to give him the same high quality of supportthat you gave me.

Thank you and Godspeed.

Yours aye,

W.J. Broughton


NaMMS EDMAutomated maintenance managementfor the fleetBy LCdr R.H. Bayne, LCdr W. Dziadyk and Lt (N) J. Roop

CF photos by Cpl Richard Sirois, Base Photo Esquimalt

Introduction

At present the Naval MaintenanceManagement System Exploratory De-velopment Model (NaMMS EDM) isone of the most important maintenancemanagement projects of the Canadiannavy. It has far-reaching implicationsfor the maintenance and readiness of fu-ture naval vessels, including TRUMPand CPF. With the addition of thesenew naval vessels, along with updatedmarine and combat systems, the 1990swill bring great advances and even great-er challenges in the field of automateddata processing (ADP) within the Cana-dian navy. The installation and im-plementation of the HMCS HuronExploratory Development Model is thefirst coordinated attempt at investigat-ing the uses of networked ADP in au-tomating the Naval MaintenanceManagement System.

Background

The Naval Maintenance ManagementSystem is the policy document that hasdirected the Canadian navy in main-tenance administration for over a de-cade. NaMMS uses the Ship'sMaintenance Management InformationSystem (SMMIS) to provide computer-ized services throughout the navy.Although SMMIS has developed a largedata base, its input/output mechanismsare obsolete and do not satisfy user re-quirements at each level of support.

In order to take advantage of newtechnology, a replacement informationsystem, NAMMIS (Naval MaintenanceManagement Information System), isunder development to upgrade not onlythe existing shipboard maintenance in-formation system, but the commandand NDHQ systems as well. Enhancedinput/output features, state-of-the-arthardware and software, and user-oriented philosophy will combine toeliminate the deficiencies associated withfirst-generation information systems; in

System Manager P1ET Jim Christie performs checks on the Huron EDM localarea network. The success to date with the EDM signals a major step forwardin the process of naval maintenance administration.

particular, SMMIS. From out of theNAMMIS development project, theNaMMS EDM was born as a demon-stration project to prove the feasibilityof shipborne ADP equipment and to de-velop the "way ahead."

System Description and Scope of theEDM

The scope of the NaMMS EDMproject is to evaluate the feasibility ofa computerized, on-board maintenanceadministration system over a two-yearperiod. The first six months would becritical since opinions and work prac-tices would be established during this in-itial stage.

In October 1988 DMES 6 installedten colour Z286 PC-AT workstations inworkshops and offices in HMCS Hu-ron, each with its own dot matrix printeras shown in Figure 1. (Huron was select-ed for the trial because she will be the

last of the Tribal class to undergoTRUMP refit.)

Using an ethernet local area network,the workstations were connected to aruggedized, rack mounted, hard-diskdata base which stores all the ship'sdata. The Digital Equipment of Cana-da Ltd. (DEC) VAX-based hardwareand software platform is managed bytwo petty officer first class tradesmen(HT and ET). They ensure defectiveequipment is sent to the contractor (whohas offices worldwide) and that systemsoftware is operating correctly.

The primary software under investi-gation is the Equipment ManagementSystem (EMS), a contractor-developedprogram for the automation and im-provement of shipboard maintenancemanagement. Designed particularly forship's engineers and technicians, EMSis able to:

* screen a Maintenance Action Form(MAF) for endorsement;


Dlpttl Eltorn«t Multi-Port R»p««t«r

•PRINTERS WITH FORHS.SUPPLY VOUCHERJ1AF 13B4.UCR.

ALL PMNTER5.LETTEB OUAUTY.OIGITftL LA75. EXCEPTELECTRICAL WOnCSHOP.WTOC CARRIAGE NEAR LETTEROUMJTY LA21B.

ALL PC/AT. 4 XT FITTED WITH A DIGITAL ETHERNETPC ADAPTER CARODEPCA)

THE IV OPEN RACK LOCATED IN F.C.WORKSHOP.

DEC SERVER AND DEMPR LOCATED IN EBR.

P.M. OFFICECSE

Fig. 1. NaMMS EDM local area network on board HMCS Huron.

Port A^nyMd.not fitted

FX. WORKSHOP

* print the MAP for transmission torepair facilities ashore;

* schedule and print planned main-tenance routines;

* transfer the MAP to floppy diskfor upload to the SMMIS database;

* automatically record MAP actionsin the EMS "electronic Kalama-zoo" equipment record register;

* screen and print UCRs and supplydocuments; and

* provide software for graphing,storing and reporting equipmenthealth monitoring (EHM) activi-ties within the ship.

A block diagram of the EMS appli-cation program is included as Figure 2.

The use of equipment healthmonitoring techniques is a prerequisiteto the implementation of reliabilitycentred maintenance (RCM) policies.RCM can eliminate unnecessary routinemaintenance and prolong equipment lifecycle. This means considerable cost sav-ings both in terms of manpower andspare parts. The NaMMS EDM projectincludes an experimental EHM modulewhich provides SOAP, Diesel Lube OilCondition, Diesel Cooling Water Con-


f OPERATING SYSTEM

^T~

}

EMS ACCESS/PASSWORD CONTROL 1

\<

EQUIPMENT |HEALTH 1

MONITORING 1

1 '

CHOOSE EHM TECHNIQUE 1

r r r| EHM |

ALARMS SELECT 1 EQUIPMENT 1I ^J UST__J

| I |

I T TCHART j GRAPH j ™™ j

i

TEQUIPMENT RECORD I

REGISTER |

1 '

SELECT 1 , SEAECAT 1EQUIPMENT f crpEPM I| SCREEN |

'

MAINT. 1ADMIN. 1

Fig. 2. Equipment Manager

.fc. EQUIPMENT L^ WEAPONS IDATA 1 DATA 1

.. EHM llHISTORY 1

PARTICULAR*

_^ CANAVMOD IIS4)

.. MAF IREMARKS 1

_ SUPPLY I" USAGE 1

SIGN-OFF 1 MAF 1si MAF 1 n PRINTOUT!

PREVENT. | _- COMPLETE, 1 JPM ROUTINEJMAINT 1 INCOMPLETE! n PRINTOUT J

t

r=| ^KALAMA^OOJ

MAFs j f MAF |S2 TO S5 F *1 PRINTOUTj

CONDITIONMONITOR

FILE

nent System Program Organization

dition and Millipore Patch Test utilityprograms.

The Huron EDM also provides theopportunity to test the Computer BasedSystems Timer (CBST), a device whichautomatically records equipment oper-ating time for automatic recording onthe MAF and UCR. This Canadian in-vention uses the power-main currentfluctuations to indicate when the equip-ment is being switched on and off. Inthis manner, accurate mean time be-tween failures (MTBF) can be obtainedautomatically.

The NaMMS EDM also hosts theshipborne version of BLIPSS-M, the

military personnel administration partof the Base ADP program, soon to beinstalled in all Canadian Forces bases.

One of the NaMMS EDM objectiveswas to measure the usefulness of com-mercial microcomputer software undershipboard conditions. To assess this, anumber of software packages were in-stalled on the computer networktogether with a menu program whichcontrols and records their usage rates.The network services include:

* a word processor with thesaurusand spell-checker;

* a database management system;

* a spreadsheet;

* two programming languages;* a scheduler;* a communications package;

* a windowing system which pro-vides an appointment calendar,screenable clock, file cards, phonelists, editor, graphics program andmany other handy programs; and

* several other software utilityprograms.

The NaMMS EDM project is alsoevaluating the suitability of both com-mercial grade and ruggedized computerhardware in a shipboard environment.(The Naval Engineering Test Establish-ment in LaSalle, Quebec developed ap-propriate mountings for the workstationsfor testing in an operational destroyer.)

EDM Development and Preparation

Development of such an ambitiousEDM required specialists in computerengineering, the naval engineering dis-ciplines of combat and marine systems,and in software design. These areas ofexpertise are provided, respectively, byNETE, DGMEM and Fleetway Con-sulting Services Inc. of Ottawa.

In January 1987, DMES 6 and NETEconducted a fleet-wide survey of ships'maintainers with the aim of assessing therequirements for a computerized main-tenance management system. This studycollected the data which formed the ba-sis for the selection of the basic hard-ware and software systems which wereused in Huron.

The next step was to approach theNaval Modification Review Board(NMRB) for permission to trial theequipment. NMRB was told that, basedon the experience and information fromsuch shipboard trials, the navy could de-velop a comprehensive maintenancemaintenance management system forthe entire fleet. Approval was grantedin the fall of 1987.

The complete EDM system, includ-ing software, was first installed atNETE. For four months both the hard-ware and software underwent exhaustivetesting and evaluation. This land-basedtesting and verification of the systemproved to be extremely valuable. Sever-al hardware and software failures weredetected which could have crippled theevaluation had they occurred during thesea trials. The experience was similar inthe case of the BLIPSS-M software.


After successfully passing thisrigorous testing period, the system wasmoved to the Canadian Forces FleetSchool in CFB Esquimalt. During thesummer months classes were given onvarious software packages such as sys-tem management, word processingspreadsheets, MS-DOS applications andthe Equipment Management System.

NETE Involvement

The Naval Engineering Test Estab-lishment has established a section ofcomputer specialists which has as one ofits mandates the evaluation of commer-cial grade ADP equipment for use inHMC ships. NETE engineered and su-pervised the Huron installation and as-sisted in training ship's staff for theEDM. They also provided ongoinghardware and software maintenancesupport for Huron. NETE set up thefollowing evaluation plan:

* Conduct a preinstallation survey toestablish baseline maintenancepractices and attitudes of the ship'scompany;

* Conduct a six-month post-installation survey, reassessingmaintenance practices and at-titudes;

* Automatically record computerusage according to user class, sta-tion and software package em-ployed;

* Record all relevant information,interruptions, system malfunc-tions, etc. on event logs;

* Compare automatic time recorderreadings with results of manuallogs of hourmeters;

* Assess the effectiveness of trainingthrough interviews and surveys;

* Compare, where appropriate, theNaMMS EDM survey results withthe findings of the original, Janu-ary 1987, fleet-wide survey; and

* Conduct periodic post-installationassessments.

Interim EDM Findings

In March 1989 DMES 6 and theNaval Engineering Test Establishmentconducted a six-month post-installationassessment of the NaMMS EDM onboard Huron. In addition to collectingand analyzing technical data, the ship'sofficers and maintainers were ques-tioned to determine maintenance ad-

Ship's staff was very positive about the availability of computing equipmenton board Huron. Computer expertise increased during the first six monthsof the NaMMS EDM trial, and the effect of computers on non-maintenance-related work was beneficial.

ministration practices and attitudes.This information was compared to theJuly 1988 pre-installation baseline dataand, wherever possible, to the fleet-widesurvey results from 1987.

The assessment of the DMES6/NETE evaluation team was unani-mous in judging the NaMMS EDM tri-al, to date, a success. Moreover, themajority of the ship's company warmlyendorsed the project, having adaptedtheir work pattern to the computerizedmaintenance management system. All inall, Huron's staff judged it to be moreefficient than the manual process. Forexample, whereas most maintainersreadily admitted the paper version of theequipment record register does not pro-vide an accurate indication of equip-ment status, the automatic databaseupdate and MAF search features of theNaMMS EMS electronic Kalamazoomet with their unequivocal approval.

The complaints voiced most oftenduring the interviews focused on theslow response time of the system and thelack of an adequate number of worksta-tions. In particular, a workstation is re-quired in the Avionics Workshop. Thesystem response problem will be ad-dressed by the installation of the latestDEC software, and several other areasrequiring system improvement have al-ready been actioned.

The use of the EHM utility programssuch as SOAP, Diesel Cooling WaterCondition and Millipore Patch Test waslow during the trial. However, thosemaintainers who did make use of the ap-plications felt they were beneficial.

The most popular packages proved tobe the word processing and databasemanagement systems. Other softwarewas only available on a single-user ba-sis, which may explain its relatively lowusage rate. Generally, the ship's staffwas very positive about the availabilityof computing equipment on boardHMCS Huron. According to 60 percentof the survey respondents, computer ex-pertise increased during the first sixmonths of the trial and the effect ofcomputers on non-maintenance-relatedwork (such as the watch-and-station-bill) was also beneficial.

The commercial grade microcom-puters were found to perform accepta-bly in the operational environment,provided they were mounted to with-stand shock and vibration. Unfortunate-ly, the performance of the ruggedizedMicroVAX met with design problemsand was replaced in March 1990 by acommercial grade CPU which is expect-ed to be more reliable. The EquipmentManagement System software used dur-ing the EDM trial fulfilled the require-

10 MARITIME ENGINEERING JOURNAL, JULY 1990

The central processing unit for the NaMMS EDM network with the systemmanager's workstation mounted above it. Atop this (not shown here, but visi-ble on this issue's front cover) is the Computer Based Systems Timer.

ments, and the low-cost commercialsoftware packages were found to be ade-quate for other shipboard work.

There is no question that the effec-tiveness of ship's maintenance, to agreat extent, depends on accuraterecord-keeping. Based on analysis of thecollected data, short-term maintenancedecisions are made and long-term poli-

cies established. The current method ofmaintenance action recording utilizes anoutdated system, SMMIS, which doesnot hold the confidence of its majorusers, the LCMMs and ship maintain-ers. The NaMMS EDM project isdemonstrating that the first step in im-proving maintenance record-keepingmust be at the level of data input.

In addition to naval maintenancemanagement, several shipboard applica-tions could benefit from the use of com-puters: personnel management,financial services, inventory control,office automation, supplies/stores,training and the requirements of themedical office. Care, however, shouldbe taken to coordinate the hardware in-stallations and system development forthese applications. The current additionof the BLIPSS-M application to theNaMMS EDM hardware is a good ex-ample of such coordination and efficientuse of the physical resources.

The NaMMS EDM project is provid-ing valuable first-hand experience witha shipboard ADP installation. The suc-cess to date with the EDM signals amajor step forward in the process ofnaval maintenance administration. Thefeasibility of a fleet-wide, computerizedon-board maintenance management sys-tem now seems assured, and it can onlybe a matter of time before the navyreaps the full benefits that such a sys-tem can provide.

The Way Ahead

The first six months of the EDM werejust the first step in the introduction ofon-board non-tactical ADP to the shipsof the fleet. The NaMMS EDM will con-tinue until HMCS Huron entersTRUMP refit. The major activities as-sociated with the remainder of the EDMare:

* Suggestions of the ship's staff andthe evaluation team are being con-sidered for immediate implementa-tion. (Most will have been done bythe time this article appears inprint).

* Planned improvements to the sys-tem are being carried out; e.g.,transfer of MAP data to the DataCollection Centre through asyn-chronous communication lines.(Those considered cost-effectivehave either been done or are beingengineered.)

* System management staffing re-quirements are being determined.A new "System Manager" role isemerging which will be a departurefrom the traditional Assistant andDepartmental Maintenance Coor-dinator roles of the past.

* Concepts introduced by theNaMMS EDM are being consi-

MARITIME ENGINEERING JOURNAL, JULY 1990 11

LCdr R.H. Bayne is the DMES 6subsectionhead for naval maintenance information sys-tems and is Project Director for NAMMIS.

A Maintenance Action Form is printed on the LA75 printer in Huron's PlannedMaintenance Office. The automated features of the Equipment ManagementSystem software were well received by the ship's maintenance personnel.

dered for adoption in the new ves-sels of the Canadian navy.

* A comprehensive report and feed-back will be given to the staff ofHMCS Huron.

* A second interim evaluation will beconducted a year and a half fromthe date of installation.

At the time of writing the second in-terim evaluation was under way in Hu-ron . Although the full data had not yetbeen assessed, early indications seemedto support the successful results of theMarch 1989 evaluation. One thing isclear, though. If the fleet is to capital-ize on this positive, initial experiencewith a NaMMS exploratory develop-ment model, both a process and an or-ganization to oversee the updating ofnon-tactical ADP software will be re-quired within the Canadian navy.

Acknowledgment

The authors would like to expresstheir appreciation to the captain andcrew of HMCS Huron for making theshipboard evaluation of the NaMMSEDM a success. In particular, P1HTDon Nicholson and PIET Jim Christiedeserve special mention for their effortsin pioneering the new System Managerposition.

LT(N) J. Roop was the DMES 6 NaMMSEDM project officer from 1987 until hisposting last February to PM DELEX.

Reference

1. NETE Report 33/89, " Interim Evalua-tion of the NaMMS EDM on HMCS HU-RON", by Ivan G. Fuchs. LCdr W. Dziadyk was the HMCS Huron

Combat Systems Engineer during theNaMMS EDM evaluation. He is currentlythe senior electronic warfare project officerin DMCS 9.


AAW Computer Modelling ofCPF and TRUMP

By Michel Beaulne and Greg Walker

Introduction

As the application of computers con-tinually expands, computer simulationis being realized as an increasingly moreimportant and cost-effective tool fordecision-making and analysis. Com-puter models and simulations are usedto predict the operation of physical sys-tems. These models are defined bymathematical or logical relationshipswhich correspond to processes andevents in a "real-world" system. AsFigure 1 might suggest, experimentationwith the actual system or physical modelis not always possible and a validatedcomputer model can be beneficial. Someof the benefits for naval combat systemsimulations are:

a. Cost — a computer model reducesthe number of costly sea trials re-quiring test targets, aircraft, am-munition, ships, and crew. (Note:some sea trials are required tovalidate the computer model.)

b. Repeatability — performanceevaluation scenarios can berepeated as many times as is neces-sary, using the model with identi-cal target, environmental and shipsystem conditions,

c. Adaptability — parametersrepresenting weapons, sensors andthreats are easily modified toevaluate ship performance underdifferent scenarios.

It is important to note that it is notinexpensive, in terms of time andmoney, to design, develop and validatea computer simulation. However, thesecosts can be reduced by using an exist-ing validated model possessing sufficientfidelity to do the studies desired. If acombat system model is well document-ed, modular and written in a high-levellanguage, it should be relatively easy fornew users to acquaint themselves withits limitations and tailor it with theparameters of their own combat system.

Where's the simulator?I want to see whatthis baby can do.

By having a common naval combat sys-tem model, many users can benefit fromsharing such developments asparameters for a given ship, modulesdescribing a new weapon, and the post-processors used as analysis tools. Thisleads naturally to increased communi-cation and exchange, while reducingredundant effort.

Background

In 1988 the Surface and Anti-AirWeapons Systems section of DMCS ac-quired a powerful, validated Ship Com-bat System Simulation (SCSS) modelfrom the U.S. Naval Surface WarfareCenter in Dahlgren, Virginia. The modelis currently being tailored to simulate theanti-air warfare (AAW) suites forTRUMP and CPF.

SCSS is a simulation program writ-ten in SIMSCRIPT II.5, a general-purpose simulation language which sup-ports software engineering principlessuch as structured programming andmodularity. SIMSCRIPT provides con-structs such as processes, resources,events, attributes, entities and setsdesigned especially to make formulationof a simulation model easier. The modu-

lar design of the SCSS program allowsfor reconfiguration into different com-bat system architectures.

An SCSS user's group with membersin DMCS, Defence Research Establish-ment Valcartier and Defence ResearchEstablishment Suffield is working to es-tablish this simulator as a common tool.Upgrades for electronic warfare, threatprofiles and new weapon modules arebeing exchanged within the group andwith the U.S. Naval Surface WarfareCenter.

Immediate Applications

The flexibility of SCSS to modelnaval combat systems and threatscenarios has suggested some immediateapplications.

The contractors for TRUMP andCPF have proposed weapon-system ac-ceptance trials which have been designedto demonstrate the capabilities of theirsystems through a series of testscenarios. It is not feasible to test theships against a full range of threats dueto technical, safety and cost reasons, sothe contractors have developed theirown computer models to demonstrate


contractual compliance. SCSS can act asthe Crown's comparison model to vali-date the contractor model's predictedship's performance against these typesof threats.

The correct choice of verticallylaunched missile to install aboard theTRUMP ships can also be verified bymodifying SCSS with the parametersdefining various systems. The modelscan be run under the same series ofscenarios for each missile configurationto determine if there is a significantdifference in ship survivability.

Future Applications

Experiments with SCSS code can beused to develop more powerful, fasterThreat Evaluation and Weapon Assign-ment (TEWA) algorithms which will op-timize ship survivability.

A ship's separate tracking and illumi-nation radars (STIR) "light up" incom-ing threats to provide guidance forsemi-active missiles. Thus the number ofmissiles which can be launched andguided is limited by the illuminating ra-dars (typically fire-control radars) andthe way they are employed. An opti-mum TEWA scheduling algorithm cancontrol the missile launches so that anilluminating radar will be available to"light up" the target when the missileenters terminal mode. Thus each illumi-nator could control several missiles inthe air simultaneously if the missiles arespaced appropriately. The TEWAscheduling algorithms will be investigat-ed using SCSS to achieve this capabili-ty for Canadian ships.

Improvements will also be necessaryfor the TEWA algorithms which com-pute weapon assignment tactics utilizingall the weapon systems available to theship. The perfect TEWA processorwould be one that could instantly readthe incoming threat, examine all the pos-sible defence scenarios and execute, infully automatic mode, or recommend tothe Command team in semi-automaticmode, the defensive action which op-timizes the ship's survivability. Taskforce TEWA characteristics could alsobe improved to quickly coordinate allweapons into a defence plan which op-timizes the force's survivability.

Aircraft

Fig. 2. Structure of the SCSS Model

Validation

A validation test plan is necessary toshow that the components of a simula-tion model operate as expected. TheCrown as well as the CPF and TRUMPcontractors have designed tests to vali-date their own models.

As an example of a test scenario forthe TRUMP AAW suite, ten shallow-diving missiles could be simulated at-tacking the ship. TEWA would compilethe threat list as each is detected and cal-culate engageability. The STIRs, mis-siles, 76 mm gun and the close-inweapon system (CIWS) would be as-signed their targets. The Monte Carlo"dice" would be rolled and the scenariowould unfold.

Validation tests such as this aredesigned to give an incremental ap-proach in validating a model's capabil-ities. In this way, components whichhave been validated in earlier tests canbe incorporated in later, more compli-cated scenarios.

Each scenario described in the planshas been analyzed and the expectedtimes and ranges at which significantevents should occur have been predict-ed. After executing a statistically signifi-cant number of runs of a particularscenario, the results will be compared tothe expected values and any large devi-ations will give cause to further investi-gation and refinement. By examiningresults from other models, such asThomson's Tactical Simulation (TAC-SIT) model, discrepancies can be at-tributed to invalid expected values or themodels' design.

Model Structure

The structure of the SCSS model canbe broken down into three distinct com-ponents (see Figure 2):

a. the external environment model;

b. the platform model; and

c. the simulation control and datainput/output managementroutines.


DETECTIONEQUIPMENT

OTOMELARA

76mm GUN

TR. ModuleFCSC. EC

SWC

STIR hH FC.OPS I

VERTICALMISSILELAUNCHER

PHALANXBLOCK 1

CIWS

LEGEND

DA 08 - Medium-Range Search Radar

AUTO.DT — Automatic Detect and Track

TRCKNQ — Tracking

TRKSUP - Tracking Supervlaor

LW 08 — Long-Range Search Radar

COC — Control Officer Console

QF.COM — Qun-FIre Computer

QCC — Qun Control Console

LIROD — Lightweight Radar Optronlc Director

76mm Qun — Gun

FC.COM — Fire-Control Computer

FC.OPS — Fire-Control Operations

VLSS — Vertical Launch Sea Sparrow

RADAR — Tracking and Search Radar

PH.COM - Phalanx Computer

PHALANX - Phalanx Gun

Fig. 3. TRUMP ship platformcomponents as representedby SCSS

* . * • *

• * .

.

. '

• . * •*. • -^

* * • .

• • t *

4- . • • • .V • ' "•"'• x 4-;.

X. • .• * *•. . • T» •

• • • • * > • • : + -:x- • • • *• _f •

' • • * • '.*• . *

X• • . • • A,X

• . • X •x •x- . x .x.4 ' ' ' ^

• . . *t ' • • % . • " .

•

•• . *

. • •

• • . • . . • '

Fig. 4. Polar Plot Example

SCSS POLAR PLOT

DATE : 15-MAY-1989 SHIP : HMCS-IRUMPSPEED : 0.1 m/s HEADING : 180.0°

TITLE : EXAMPLE

INITIAL THREAT INFORMATION

TYPE : ASM RCS : 3.0 BEARING : 135°HEADING : 315'- ALT : 1000.0m SPEED : 354 m/s

TYPE : ASM RCS : 3.0 BEARING : 225°HEADING : 45° ALT : 1000.0m SPEED : 354 m/s





ENGAGEMENT INFORMATION

SYM EVENT THRT* MPN TIME RANGE BEAR

FIRM TRACK 1 --- 12 16097 m 135°MPN DESIG 1 SAM 13 15385 m 135°WPN DESIG GUN 13 15321 m 135°MSL LAUNCH SAM 17 14187 m 135°GUN FIRING GUN 19 13618 m 135°GUN FIRING GUN 23 12320 m 135°GUN FIRING GUN 27 11075 m 135°GUN FIRING GUN 31 9814 m 135°DESTROYED GUN 34 8981 m 135°

FIRM TRACK 2 13 16753 m 225°MPN DESIG 2 SAM 14 15703 m 225°MSL LAUNCH 2 SAM 19 14087 m 225°DESTROYED 2 SAM 45 6421 m 225°

FIRM TRACK 3 --- 15 15771 m 45°MPN DESIG 3 SAM 34 9735 m 45°FIRM TRACK 3 47 6061 m 45°CIMS FIRING 3 RFG 59 2477 m 45°DESTROVED 3 RFG 59 2477 m 45°

• FIRM TRACK 4 18 s 16422 m 315°


WEAPON FIRING

THREAT: Generic Example

TOTAL RUNS: 25SHIP SURVIVABILITY: 92%

VLSS-P: 17.33%VLSS-S: 17.33%

GUN: 58.67%CIWS: 06.67%

WEAPON KILLS

WEAPON EFFECTIVENESS(Weapon Kills / Weapon Firing) :

VLSS-P VLSS-S GUN CIWS84.62% 61.54% 56.82% 80.00%

VLSS-P: 21.57%VLSS-S: 15.69%

GUN: 49.02%CIWS: 07.84%

NO KILLS: 05.88%

% THREATS KILLED VS RUN NUMBER

100 -,

90 -

% 80

H 7°RE 60ATS 50 -

K 40I

i;30D 20

10 -

The external environment model cre-ates and maintains the physical objectsin the scenario. These objects includehostile and friendly ships, aircraft andmissiles.

The platform model describes thecombat systems of a ship. Figure 3 il-lustrates the nodes and links of theTRUMP ship's platform model as de-fined by the SCSS model. Each noderepresents a key component of the com-bat system and the links represent thecommunication lines between the nodes.For example the fire-control computer(FC.COM) and the vertical missilelauncher (VLSS) are represented, andsince each of these nodes must commu-nicate with the other there is a link be-tween them.

The simulation control and data in-put/output management component ofthe model oversees the interactions be-tween the user and the program. Theseinteractions are limited mostly to inputand output files. Through the input file,the user has control of the parametersdefining the capabilities of the modelledship, the nature of the threats, the struc-ture of the simulated scenario and thedegree of output detail produced in theoutput files. The output files contain ex-ternal object information, event varia-ble numbers and all on-board messagesbetween combat systems during ascenario run.

AVERAGE = 77.2%THREATS PER RUN : 10

I I I I I I I I I1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

RUN NUMBER

Fig. 5. Pie Chart and Histogram Examples


Model Adaptation

The SCSS model will be modifiedand refined to create two versions, us-ing the sensor and weapon parametersand combat doctrines of TRUMP andCPF. An existing contract has installedSCSS on DMCS 2's Tempest MicroVaxand has created a data file and workingexecutable image of the TRUMP AAWcombat suite. This data file representsthe vertical launch missile, gun, CIWS,command and control system, associat-ed radars and TEWA. SCSS is beingmodified in-house, at DMCS 2, to in-corporate the main features of the CPFAAW combat suite.

More specific enhancements are re-quired for the models to facilitate thetest scenarios described in the validationtest plan. Some of these enhancementsinclude:

a. modifying the platform model toinclude soft-kill capability; i.e. de-veloping nodes and links to simu-late flare and CHAFF systems;

b. IFF capability to classify targetsas friendly or hostile with an ap-propriate time delay;

c. a capability to insert and use NOFIRE zones; and

d. more detailed output from theLW08 long-range and DA08medium-range search radars; i.e.status of each radar scan — hit ormiss, track creation or track drop.

Post-Processors

The information gathered in theSCSS output files can be used by post-processors to serve in the detailed anal-ysis of each SCSS simulation run. Onesuch processor called Polar Plot uses thepositions of the simulated objects in anaval combat scenario to overlay theirtrajectory plots on a polar graph. Sig-nificant events such as firm tracks,weapon designations, weapon firingsand weapon kills are represented on theplot by distinct symbols for each type ofevent. The ship is located at the centreof the plot (Figure 4) and the positionsof the symbols indicate where the eventoccurred with respect to the ship's po-sition at that time. The text data sectionto the right of the plot includes ship, in-itial threat, engagement and engagementsummary information.

Post-processors for generating piecharts and histograms to illustratestatistical information have also beencreated (see Figure 5). A number of runsof a particular scenario must be execut-ed. Each run will have the same type andnumber of threats, but the heading ofthe threats and probable results willdiffer from one run to the next. Infor-mation accumulated by the post-processors, such as the percentage ofthreats killed per run and the percen-tages of weapon firings/kills for eachscenario, will help in determiningweapon effectiveness.

Conclusion

A naval combat simulator's ability topredict the performance of an actualAAW suite makes it an important toolin development and analysis. Numerousapplications for the modified SCSS pro-gram have already been suggested forthe Canadian Patrol Frigate and TribalClass Update and Modernizationprojects, with a view to maximizing theeffectiveness of these ships. Wider useof computer simulation, however, is es-sential to evaluating the naval techno-logical advances and changes inoperational doctrine designed to op-timize the ships' performance againstthe challenging threats of the presentand future.

Greg Walker is the DMCS 2 project engineerfor above-water warfare computer simula-tion at NDHQ.

.Michel Beaulne was a University of Water-loo Co-op student in DMCS 2 during thesummer of 1989. Last fall he entered hisgraduate year in Waterloo's AppliedMathematics and Computer Scienceprogram.


U.S. Navy Ship Shock TrialAn observer's account

By Ole Bezemer

As part of our information exchangeand cooperative R & D programs withthe United States Navy, Canada was in-vited to witness the underwater shocktrial of the "Improved Spruance"-classdestroyer, USS Kidd. Kidd and three sis-ter ships had originally been construct-ed for the Iranian navy, but werediverted to the USN in 1979 followingthe Iran hostage crisis. The ships weresufficiently different from the 963 classto warrant a separate shock trial. Sincethe trial would take place off Key West,Florida, this visit looked most attractivein addition to being interesting.

I flew first to Fort Lauderdale* wherethe U.S. trial teams had gathered forbriefings and a walkabout inspection onboard the Kidd. It was surprising to seehow many people were involved in thetrial. In addition to the ship's crew,there were at least a hundred. I met twoother observers, one from Australia andone from the U.K., both pleasant fel-lows. (* The reason for meeting the shipin Fort Lauderdale was that Kidd's so-nar dome stuck too deeply into the waterfor her to comfortably enter Key Westharbour. This meant that once in KeyWest all trials personnel would have tobe ferried to and from the ship at seaeach day, an exciting prospect becausethe sea was quite rough from a stormjust a few days before.)

The day after arriving in Key West wedeparted the motel at five in the morn-ing in pitch darkness. The temperaturealready hovered around 21° C. About80 of us boarded an open landing craftand chugged out to join Kidd at sea. Assoon as we hit open water the situationbecame miserable. The sea was roughand at regular intervals waves wouldbreak over the square bow, drenchingus. I was glad to have hidden my brief-case under a waterproof tarpaulin be-cause the seawater soakings meant

certain corrosion for unprotected brief-cases. I saw the results next day: themetalwork on many briefcases hadturned a vivid rust colour. At last dawnbroke and we spotted the menacing sil-houette of the USS Kidd on the greyhorizon.

Earlier I had noticed a hinged ladder-like contraption on the landing craft'sbow. Its purpose became clear when weapproached the square stern of theKidd. The idea was to come right upagainst the stern with the rubber bufferson each side of the landing craft's bow,and open the ladder up onto the destroy-er's flight-deck. Not a bad idea in a deadcalm sea. However, when we butted upto the Kidd's stern in the considerableswell, the rubber scraped away from thebuffers of the landing craft and we be-gan gouging Kidd's stern with our me-

tal bow. (Apart from the horrendousnoise, we were literally making a deepimpression on the poor ship.) The lad-der in the meantime was folding up anddown alarmingly and only three braveand foolhardy souls scampered acrossbefore an enraged destroyer captainwaved us off. The chaps who got acrossseemed heavy-hearted as they watchedus bear away for terra firma and cooldrinks poolside. They were stuck on a"dry" ship with a C.O. who, not sur-prisingly, heartily disliked the prospectof having 100 irreverent civilian trialspersonnel knock his ship about for thenext four days.


Back in Key West I spent the day withthe two other observers seriously dis-cussing the trial and reminiscing overpast ones. Next morning we dutifullyboarded the landing craft and chuggedout again. The sea was still rough andwe heaved and rolled towards the in-trepid Kidd. Farther out to sea I noticedthe huge floating crane which would beused to handle the explosive charges forthe trial. (The charge for the most se-vere shock weighed 20 tons!) Halfwayto the Kidd, though, we received themessage to turn back because the crane'scables had become entangled while lift-ing one of the charges in the rough sea.

Day three arrived with calmerweather. Once again we went out in our(by now) familiar craft, clutching ir-reversibly corroded briefcases. Theboarding procedure had been sensiblymodified, and we now boarded the des-troyer via a Jacobs ladder which hungover the side of the ship. One simplygrabbed the ladder when the landingcraft was on the crest of a wave andclimbed up! Once on board we gatheredin the huge hangar where tables hadbeen set up for the use of the test crews.

Toward the end of the morning theship was ready for the first shock. Wetook our designated places and waitedfor the countdown. The explosion cameexactly as planned and felt as if the shiphad been hit with a heavy hammer. Theeffect of this relatively mild shock wasonly very minor and no significantdamage was noticed. At the end of theafternoon we boarded the landing craftand returned to Key West.

Next day, to make up for time lostduring the first two days, the trial agen-da was pushed ahead to proceed direct-ly with the "third" shot. For this oneI positioned myself on the bridge. Theeffect of the shock on the bridge was bi-

zarre. While the radar unit closest to theshock side survived undamaged, the uniton the far side had lifted off its pedestaland been heavily damaged. The low-frequency response of the bridge super-structure to the shock energy must havebeen considerable and complex. Afterthis, I was not looking forward to whatwas in store for us the next day.

Day five: for the final, severest shockof the trial I was stationed in the mainmachinery control room. The count-down was agony, and when the explo-sion came my first thought was that,surely, the ship would open up and sendus gurgling down to feed the sharks. Themachinery that had been running hadstopped instantly and now we werebathed in the unearthly glow of theemergency lighting. Amidst the pan-demonium of console alarm claxons, si-rens, horns and blinking red lights I sawthe officer-in-charge gaping at the con-fusion with open mouth. I sympathizedwith him — "What the hell do you dofirst!"

It could only have been seconds be-fore he reacted. His first move was cor-rect as far as I was concerned: he startedone of the three diesel generators. Wheneverything seemed all right he startedone propulsion engine after the other.During the damage assessments laterthat day I learned that all the machineryhad tripped on spurious signals like ex-cessive vibration, low fuel pressure, etc.,except for the third generator. It hadtripped on overload since it could notshed its load quickly enough when theother two generators shut down.

It was heartening to see what littledamage there was. A few bulkheads hadmildly buckled at the deck joints andsome equipment damage had occurred,but nothing that would prevent the shipfrom moving and manoeuvring. Thecrew's reaction to the trial was interest-

ing. Obviously they were relieved it wasover, but also — and this is somethingI have observed during other shock tri-als — they had developed a strong con-fidence in the ability of their ship tosurvive combat conditions.

While quite a few of the trials person-nel remained on board to work on theirreports, my two observer friends and Ireturned to Key West. There wecelebrated the end of an eventful weekat the famous Sloppy Joe bar (ofHemingway fame). Later as we werewalking back to the motel a passing carbackfired loudly. The three of usjumped at the sound. Obviously, we hadbecome sensitive to explosive sounds!We laughed nervously and walked on,somewhat chastened by the experience.

Ole Bezemer is the DMES 3 section head fornaval passive protection systems.


Authors9 ProposalA Naval Reserve NCM EngineerTraining PlanBy Lt(N) Dave Marecek

and PO1 Ken Quick, CD

Introduction

Traditionally, naval reserve NCM en-gineers have been operator-maintainersresponsible for engineering, hull, elec-trical, fire-fighting and damage control.Currently, the trade is defined as R315Diesel Mechanic, with the majority oftraining emphasizing diesel theory andoperation. The training over the last tenyears has led the Diesel Mechanics downa road to where the naval reserve hasdiesel watchkeepers, but few charge-tickets and a minimal number of quali-fied maintainers capable of first-linemaintenance.

New Role

The naval reserve today has respon-sibility for two maritime functions:naval control of shipping and maritimecoastal defence, including the clearingof mines. With the new role, upgradingof the reserve NCM engineer will be ofparamount importance due to the mas-sive shift from 1940s technology tomodern integrated systems. The deliv-ery of mine countermeasure vessels andtheir full complement of integratedmachinery control systems means thereserve engineer will have to have im-proved operational training. But moreimportantly, the reserve engineer mustbecome a knowledgeable first-line main-tainer of modern integrated machinerycontrol, electrical, propulsion, controland auxiliary systems.

Aim

It is the purpose of this paper to pro-pose a naval reserve NCM engineertraining plan which would allow thenaval reserve to meet the engineeringcommitments of maritime coastaldefence. The prime focus of the discus-sion is the training of NCM engineersfrom the recruit level through to thequalified CERA, within the confines ofthe naval reserve training system. Thiswill include a proposed training plan to


cover in-unit training (September-May)and out-of-unit summer training forboth the operation and maintenance ofnaval reserve marine engineeringsystems.

Background

The naval reserve Diesel Mechanictrade R315 (DMech) is composed ofthree trade-ticket levels (Fig. 1). For aminor war vessel (MWV) to put to sea,the minimum manning is one C-ticket,two B-tickets and two A-tickets for daysailing, and an additional A- and B-ticket for overnight steaming.

Current DMech Training Problems

The naval reserve DMech trainingsystem in its current state is not meet-ing the goal of training qualified dieselmechanic operators and maintainers.The following list of concerns arisesfrom the current DMech training poli-cy and standards:

a. The fleet standard for A-, B- orC-tickets is unidentifiable as thereis no TQ4 or TQ6 course availa-ble. The available course contentand duration do not follow thetrade progression of the DMech.

b. There is no consistency in trainingat the TQ4 and TQ5 levels as thereare no objectives, and only OJPR(on-the-job performance require-ments) at the TQ5 level. The bulkof the knowledge is passed downfrom senior to junior personnel —hence, procedures vary through-out the fleet.

c. The training relies on the assump-tion that the recruit has basicmechanical experience andfamiliarity with hand tools, whichis not the case in the student-centred recruiting.

d. Personnel are rushed to get theirtickets with too few steaminghours and minimal experience,resulting in poorly qualified oper-ators and no maintainers. This canbe attributed to the limited num-ber of vessels for training, ineffi-cient use of fleet school facilities,insufficient numbers of trained in-structors, and ticket shortagescaused by limited retention (i.e.2-5 years).

e. Maintenance, both preventive andcorrective, is not covered oncourses or demonstrated in thefleet due to limited vessels.

GENERAL MILITARY TRAINING 1,11,111ABLE SEAMAN

BTQ3A 4 WEEK COURSE BASIC DIESELPROMOTABLE TO LS AFTER 2 YEARS

TQ4 OJPR & JLC & 40 HRS STEAMIMGPROMOTABLE TO MS AFTER 2 YEARS "A" TICKET

CERTIFICATION

DTQ5A 6 WEEK COURSE

PROPULSION, AUXILLIARY, EOOW

TQ5B OJPR & 120 HRS STEAMINGPROMOTABLE TO PO2 AFTER 2 YEARS •B' TICKET

CERTIFICATION

TQ6 OJPR & SLC & 150 HRS STEAMINGPROMOTABLE TO PO1 AFTER 2 YEARS •C' TICKET

CERTIFICATION

PROMOTABLE TO CPO2 AFTER 2 YEARS

Fig. 1. Diesel Mechanic R315 Career Progression

DMechs are normally not on handwhile actual maintenance is beingcarried out by Reserve TrainingUnit staff.

f. Personnel employed by civilianemployers have only two weeks

(average) a year for training andoperations.

g. Trade qualifications are linked torank and promotion. The un-availability of training time andthe inability to attain a higher


trade qualification stops promo-tion which leads to unit demorali-zation or the loss of a trainedmember.

Discussion

Naval Reserve NCM Engineer Functions

To meet the commitments imposedupon the naval reserve, the question thatmust be asked is "What is the functionof the naval reserve NCM engineer in re-lation to the role of the naval reserve?"

In the naval reserve environment, anengineer must be able to take a vessel tosea and support the engineering systemfrom an operational and maintenanceperspective. The engineer must befamiliar with more than diesels, as anMWV has electrical, control, auxiliary,hydraulic and hull systems. With all ofthese individual systems, it is proposedthat the naval reserve NCM engineertraining cover all aspects of MWV en-gineering systems to allow the engineerto operate competently and performfirst-line corrective maintenance. (Pleasenote that the title "Engineer" is beingused in lieu of DMech for the reasonsjust stated.)

The MOC of DMech or Engineer isan issue under the Total Force concept,as the reserve would require a trade thatdoes not exist in the regular force. Sincean MWV will probably not have morethan 40 billets, and seven billets are re-quired for engineers (20 percent of thecrew), there will be no room for separateengineering trades as there is in the regu-lar force.

This would require that the reserveengineer be a reserve-specific trade thatwould use various portions of regularforce engineering training packages fordiesels, hull, auxiliary, electrical andcontrol systems. By using portions ofeach package, equivalence of trainingwould be achievable.

It is proposed that the reserve en-gineer be one of the exceptions to theTotal Force trade structure. The re-mainder of the discussion will proceedon the assumption that the reserve NCMengineer is a reserve-specific trade.

Training Concept

It would be preferable to follow thenaval trade structure of separate opera-tors and maintainers. However, withonly one engineering MOC and limitedspace on an MWV, the operator-maintainer concept must be applied to

the engineering trade. The naval train-ing system has a concept that could besuccessfully applied, whereby engineersare trained as operators only until theleading seaman level or A-ticket. Thenaval reserve could then follow the regu-lar force engineering maintainer train-ing for the B-ticket and administrativetraining for the C-ticket.

This concept would allow the navalreserve to build up a cadre of qualifiedoperators by concentrating initial train-ing on operating only. This would in-clude all systems, but from anoperational perspective. Once the mem-bers become qualified operators theywould embark on their maintainer train-ing working towards a B-ticket. The fi-nal step of their career progressionwould be the C-ticket with its adminis-trative duties.

The training should also be modifiedsuch that all courses are two-week mod-ules (TWM). This would allow a TWMto be taught as a term course (in-unit)or as a concentrated course at a special-ized facility (e.g. fleet school). Twoweeks is specified because this is theaverage time a reservist has availablefrom his civilian employer. When areservist has a larger block of time,several modules could be completed. In-cluded in every TWM would be aCommand-wide exam. This systemwould allow reservists' training to pro-ceed rather than stagnate.

The training concept must also ad-dress in-unit training. Currently, thereare no in-unit training courses.However, 20 out of 40 A-ticket OJPRs,15 out of 30 B-ticket OJPRs and 24 outof 27 C-ticket OJPRs could be taughtin-unit. Under the present training plan,engineers spend a large proportion oftheir time on the coast in class insteadof steaming and operating equipment.By conducting the training in-unit, theoperational time would be maximized.

The proposed training concept wouldbe valid for the following reasons:

a. The naval reserve has its largestresource pool in the first 2-5 yearsdue to student recruiting. In thistime span operator training onlywould be conducted, therebyminimizing training costs.

b. With an earlier operationalqualification, the number ofqualified operators would in-crease to allow the reserve to meetits operational commitments.

c. If personnel choose to make along-term commitment to thenaval reserve (i.e. more than threeyears), they would progress onmaintenance training toward theirB-ticket. Since this is time-consuming and expensive train-ing, it makes sense to fund it onlyfor personnel who are committedto the naval reserve.


SENIORITYLEVEL

MINIMUM TRADELEVEL FOR SENIORITY

CURRENTTRADE VSSENIORITY

MINIMUM SENIORITYFOR TRADE LEVEL

TRADE LEVEL

Fig. 2. Seniority vs. Trade Level

d. This concept would allow in-dividuals to continue trainingthroughout their career, thus im-proving morale and job satis-faction.

e. This concept of two-week trainingmodules would make it easier forreservists (and civilian employers)to schedule time off for navaltraining.

f. This concept would allow class-room training to proceed in-unitand maximize operational time onthe coast, leading to more confi-dent operators.

With the function of the naval reserveNCM engineer defined and a trainingconcept established, the naval reserveNCM engineering training plan can beoutlined.

NCM Engineering Training Plan

Personnel

Under the CF recruiting plan, univer-sity students form the majority of newrecruits in the naval reserve each year.In addition to out-of-unit training (fourmonths each summer for the first fouryears), the in-unit training covers ap-proximately 28 3{-hour training nightsper year (equates to 3 weeks) and ap-proximately eight weekends per year (3weeks). Thus, in the first four years,there are approximately 18 weeks peryear for training. However, after fouryears, training is reduced to a maximum

of eight weeks per year if the membercan get leave from civilian employment.With the constraint of training time forreservists, the training plan must bestructured to maximize available time.

The respecification of MobilizationMilitary Occupational Classifications(MOBMOQ to allow a wider separationbetween trade and rank qualificationswould allow the reserve to accept trainedpersonnel from industry into a hightrade class, but low seniority class (Fig.2). Additionally, the change would givepersonnel more latitude in their careersby allowing them to become proficientin either management (rank) or technol-ogy (trade).

This concept could increase recruit-ing of skilled personnel from industry,thus reducing the CF training costs. Itcould also decrease attrition by allow-ing flexibility of career progression toeither management or technology, andcould improve morale as job satisfactionwould be increased. The concept wouldideally suit the training availability limi-tations placed on reservists.

Facilities

Naval reserve engineers train in threelocations: in-unit, West Coast and EastCoast. The majority of the units haveonly classrooms and a cutaway diesel forteaching. At the coasts, fleet school fa-cilities and operational vessels are avail-able. Some exceptions do exist where aunit has a fleet tender for local steam-ing during part of the year.

The brunt of the operational hands-on training must occur at the coasts onvessels or in fleet school shops. With thecurrent facilities at units, some watch-keeping may be done in-unit on fleettenders and during gate-vessel weekends(at the coast). However, the unit is stillbest suited for classroom instruction inoperational procedures, maintenanceprocedures and theory supporting theproposed training concept.

Improvements in the training aids ateach unit may be helpful, but it does notseem feasible to mock up electrical, aux-iliary, control, hydraulic and hull sys-tems at the 24 units across the countrywhen these mock-ups already exist in thefleet schools. One solution may be toconduct fleet-school weekends for tradesthroughout the year. In fact, use of fleetschool facilities for teaching seniormaintenance courses on weekends couldadd the much-needed training time af-ter the initial four-year period.

Another option is to procure mobiletraining facilities through the purchaseof a 40-foot trailer. Operational diesel,electrical, auxiliary and control systemscould then be trucked from unit to unitthroughout the training year, therebyeliminating TD travel to a fleet school.During one four-week stopover, up to12 full training days could be achievedwith the equipment.

Trade Progression

Trade and rank progression in thenaval reserve are highly dependent uponthe amount of training time available.Thus the critical path for rank becomestrade qualifications under the currenttrade structure. In addition to qualifi-cations, the minimum time requirementsfor each rank still apply as set out by theCF. With the incorporation of MOB-MOC, trade progression would offermore latitude as the engineer would beable to progress either upwards withmilitary knowledge or laterally withtechnology.

The following naval reserve NCM en-gineer rank progression is proposed:

a. For Able Seaman, the membershould complete basic militaryknowledge, basic seamanship andengineering outside roundsmanclassroom training, and at least 80hours of steaming time as an out-side roundsman.


b. For Leading Seaman, the membershould be a qualified operatorholding an A-ticket. This wouldrequire at least three TWMs ofclassroom time and 120 hours ofsteaming toward an A-ticket.

c. For Master Seaman, at least fourTWMs of maintenance training inthe time frame prior to the fourthyear as this would be the last avail-able time period for a long train-ing course. After the classroom,at least 240 hours of steaming timewould be required prior to sittingthe B-ticket board.

d. For Petty Officer 2nd class, threeTWMs on administration wouldbe completed.

e. For Petty Officer 1st class, at least480 hours of steaming time as a B-ticket would be required, followedby the C-ticket board.

Course Specifications

Based on all previous assumptionswithin this paper, the following are theproposed course specifications for navalreserve NCM engineering training:

General Military TrainingGMT I/II in-unit basic militaryknowledge (1 TWM)GMT III at-sea basic seamanship (1TWM)TQ3 Engineering Outside Rounds-manTQ3A in-unit outside engineeringrounds (1 TWM)TQ3B on-board outside roundsman(80 hours)TQ4 Engineering OperatorTQ4A in-unit operating procedures,all systems (2 TWMs)TQ4B fleet school operating proce-dures (2 TWMs)TQ4C steaming time toward A-ticket(120 hours)

TQ5 Engineering MaintenanceTQ5A in-unit first-line maintenance(1 TWM)TQ5B fleet school maintenancecourse (3 TWMs)TQ5C maintenance steaming hours(240 hours)

TQ6 Engineering AdministrationTQ6A in-unit administration self-study (2 TWMs)TQ6B fleet school administrationcourse (1 TWM)TQ6C CERA steaming time (480hours)

With the trade and rank levels de-fined, every course should have aCourse Training Standard developed.For in-unit training, it is especially im-portant that a standard course packagebe made available to naval reserve unitssuch that engineers across the countryreceive the same level of instruction. Ex-ams for every module should be ad-ministered at a national level byCommand.

Additionally, the OJPRs for the A-,B- and C-tickets should be split into twopackages. The first part would be non-vessel-specific. The second portionwould be vessel-specific in the samemanner as the regular force trainingwhere the type of vessel an individual isassigned to defines the training package.

Conclusions

The current DMech training systemand standards are producing neither theconfident operators nor the qualifiedmaintainers needed to meet the navalreserve's operational commitments.Meeting the challenge of creating trainednaval reserve NCM engineers is feasibleif priority is placed on training. It is pro-posed that the following concepts beconsidered as the possible way ahead forreserve NCM engineers:

a. redefinition of the DMech trade toEngineer,

b. operator training in the first threeyears,

c. development of two-week mod-ules for training,

d. increased in-unit training ofOJPRs,

e. reserve-wide course trainingspecifications and exams,

f. increased operational steaminghours for each ticket,

g. MOBMOC changes, allowing lati-tude in career progression,

h. institution of trade-trainingweekends at fleet schools,

i. portable training facilities for in-unit training.

Recently, in-unit training of reserveNCM engineers has been discarded, yetmore in-unit training and more steam-ing hours are needed to provide confi-dent, qualified operators andmaintainers. This paradox must be ad-dressed at the Command level with a ra-tionalization of engineering training.

Lieutenant Marecek is the EngineeringOfficer of HMCS Carleton in Ottawa. Anex-regular force CSE, he is now a programmanager with DY-4 Systems Inc. ofNepean.

Petty Officer Quick is the Chief ERA ofHMCS Carleton. He has been a reserveDMech for 14 years and has held a C-ticketfor six years. He is currently a self-employedcomputer consultant.


Why Ada Makes Good Sense

By Cdr Roger Cyr

Introduction

Doubts are often being expressedabout the benefits of using Ada for mili-tary software applications. Some of thequestions that are raised regarding Adainclude:

a. Is software more maintainablewith Ada?

b. Will it cost less to implement aproject with Ada?

c. Will the use of Ada improve theperformance of a system?

The intent of this article is to answerthese questions and clear away themisconceptions regarding Ada.

Background

Software has become a very expen-sive commodity. The U.S. Departmentof Defense spent $12 billion on embed-ded computer software in 1987, and es-timates show that this expense isincreasing at an annual rate of 17 per-cent. By its own estimates the U.S. DODwill be spending $42 billion per year onmilitary software by 1995.

Past experience with the U.S. DOD,however, has revealed that many con-trollable factors have made software ac-quisition unnecessarily expensive. Oneof these factors is diversity. In the late1970s as many as 300 different computerprogramming languages were being usedfor military software. There was also theproblem of ownership of the softwarebeing developed in insolation by a largenumber of contractors. There was noclear understanding as to whether DODactually owned the software beingproduced. In addition, there was noplan to reuse existing software, and sinceproduction methods did not make useof engineering tools, the productionprocess was considered somewhatarchaic.

To this was added the fact that qual-ity control of software was minimal. Ina large number of cases the code was ac-tually written before the high-level sys-tem design or software design was done.The end result was unreliable and un-predictable software which was expen-sive to build and even more expensiveto maintain. Yet, this unreliable soft-ware was intended to be the control-ling element of tactical and strategicsystems.

The Creation of Ada

Faced with what was referred to asa software crisis, the Department ofDefense initiated a program to developand enforce software standards. TheHigh-Order Language Working Groupwas formed in 1975 to come up with astandard language which would beusable for all applications. The languageeventually developed by this group wasinitially called DoD-1. However, in thepost-Vietnam era it was felt this namesounded too military and would bescorned by the academic sector. In 1979the language was officially named Ada,in honour of Augusta Ada Byron,Countess of Lovelace. Ada Byron wasconsidered the world's first programmersince she was involved in programmingwhat is known as the first computerinvented by Charles Babbage.

The purpose in developing Ada wasto create a language that could be usedto program the embedded computersthat are components of major systems,such as those found in the various sen-sor and weapons subsystems of a ship'scombat suite. In these applications,where reliability is critical, software re-quirements are complex. The softwareproduct is usually very expensive to de-velop, has a long life-cycle and requiresfrequent enhancement.

Some of the organizations whichadopted Ada as a standard include:

* the Ada Joint Program Office,which is the U.S. DOD officeresponsible for the implementationof the language;

* the American National StandardsInstitute; and

* the International Standards Or-ganization.

Software Technology and Concepts

To appreciate the benefits that can bederived from Ada, it is important tounderstand the technology and conceptsof software as they apply to Ada. In thepast, specialized languages were deve-loped for specific uses since no languagewas suitable for all applications. Forexample, Cobol was developed forbusiness applications, and Fortran forscientific applications.

Ada was developed primarily forembedded computer applications sincethis was considered to be the mainstayof military applications. However, Adawas the first language to be also consi-dered well suited for all types of appli-cations, be they military or commercial.It is a sophisticated language which, be-cause of its special features, allows sys-tem designers to describe precise systemparameters early in the design phase.This saves on test, integration and main-tenance costs, and makes the program-ming of the design much simpler.


Ada as a programming language in-corporates improved features whichmake programming simpler and easier.The more pertinent of these features are:

a. Strong Data Typing ensures thatdata fields only contain the typeof data that was specified for thatparticular field. For example, aprogrammer could not inadver-tently have numbers assigned to afield which had been declared tocontain letters. This sort of errorwould automatically be detectedduring compilation with Ada.

b. Exception Handling specifieswhat the program will do when anabnormal condition occurs as aresult of a programming error. In-stead of the program corruptingand blowing up as would happenin the old days of the CCS-280system, program execution wouldnow continue in accordance withprescribed actions.

c. Modularity — Ada programs canbe broken down into self-contained modular componentscalled tasks or packages. All dataassociated with a particular pack-age is contained within thatmodule, with the interfaces toother modules being well defined.These module interfaces are con-trolled by strict rules that are en-forced by the Ada compiler. Thisprocess eliminates the old ways ofjumping in and out of subpro-grams which resulted in the even-tual degradation of the programand in maintenance nightmares.SPAR Aerospace used Ada toprogram the Space Station Re-mote Manipulator System. In thisapplication it was found that sys-tem integration was much easierthan if Fortran or Pascal had beenused, because Ada compilerschecked program interfaces as theprogram was being compiled.

d. Concurrency is supported by thetasking feature of Ada. It pro-vides the ability to specify multi-ple tasks that can be executedconcurrently. This parallelprocessing is most useful since itallows for a number of tasks to beperformed at the same time,resulting in much faster executionof programs.

Fig. 1. Ada Language System

Compilers are also an important ele-ment of the Ada technology and con-cepts. Compilers translate the high-levellanguage into a sequence of machine in-structions that will be stored in the com-puter and will form the program to beexecuted. One difference with Ada com-pilers is that they must be tested and cer-tified as correct by the Ada Joint ProjectOffice.

Ada compilers are unique in that theyhave a program library feature whichstores the results of each successfultranslation. A task being compiled canbe compared with tasks previously com-piled to ensure that the required inter-faces have been included. Other tools inthe program library allow for suchthings as the analysis and managementof the software development process.

An aspect of programming supportwhich is flourishing with Ada is theavailability of tools and environments(Fig. 1) that make software productionmore integrated, structured and con-trolled. Such environments incorporateall the necessary tools to design softwaresystems in a top-down fashion, and alsosupport the management of software.

These are called Ada Programming Sup-port Environments or APSEs. AnAPSE is a total system used to specify,design and manage software. Some ofthe tools that form an APSE include:

* Computer-Aided Software Engi-neering tools,

* Dynamic tools,* Debuggers,* Optimizers,* Configuration Managers, and* Database Managers.

One more aspect of compilers ingeneral is the run-time executive, a smalllayer of software typically contained inembedded computers. In the past, theapplication software called on this soft-ware to make hardware-specific appli-cations happen. This was a problemsince all run-time executives were dif-ferent. As a result, application softwarewas not portable from one computer tothe other. Ada, however, provides therun-time executive features as part of theAda language itself. Consequently, spe-cial run-time executives do not directly


CONVENTIONAL APPROACH ADA'S SAFER APPROACH

MODULE 1CODE

\MODULE 1

DATA

MODULE NCODE

v\E NDATA

ADA CODEMODULE 1

DATAMODULE 1

ADA CODEMODULE 2

DATAMODULE 2

I

ADA CODE DATAMODULE N ' MODULE N

Fig. 2. Conventional vs. Ada Programming

interface with the applications, and Adasoftware becomes portable betweendifferent compilers and, hence, differentcomputers.

Software Engineering

The major feature of Ada, and ob-viously the major reason for using it, isthat it promotes sound software en-gineering practices which result in theearly detection of errors and in lowerlife-cycle costs. Sound software en-gineering practices require thatprogramming be structured. Ada as alanguage enforces the requirement forstructured programming and places theemphasis on the design stage during theproduction cycle. The coding activitythen becomes secondary to the design ef-fort and flows from it. This processforces the design engineer to produce asystem design that will be manageablethroughout its life cycle.

Some of the features which supportlong life-cycles include:

a. Modularity, Abstraction or Infor-mation Hiding — programmodules are composed of twophysically separate parts — thespecification and the body. Thisway it is possible to compile pro-grams which make use of a mod-ule before the module body evenexists. All of the informationneeded to compile programsreferencing a module is given inthe module specification. Thisstructure ensures that modules arefunctionally independent fromeach other (Fig. 2) and that theirinterfaces are well defined early inthe system design process.

b. Syntax Checks — rigorous check-ing of the syntax facilitates finalintegration of the various modulesof a large program by ensuring theconsistency of module interfaces.

c. Testing — Ada code can be test-ed on different target computers,making development easier andfaster.

d. Reusability — The same Adamodules can be reused for a num-ber of different projects, meaningthe initial investment can beamortized over a longer timeframe.

Software production with Ada can becompared to a civil engineering situationwhere an engineer produces a designspecification and a bricklayer stacks thebricks in accordance with the specifica-tion. Similarly with Ada, the system orsoftware engineer produces the designspecification and the programmer stacksthe programming instructions. Withprevious languages the percentage splitbetween design, coding and testing was40-30-30. With Ada, there is a greateremphasis on design, the split being60-20-20.

Rationale for using Ada

The Ada language has been accept-ed worldwide as one standard. Unlikeother languages, there is only one Ada.Ada is undoubtedly the best there is atthis time. It allows the software design-er to ignore the hardware specifics andis not dependent on a specific compileror computer. Ada code can run on anymachine for which there is an Ada com-piler, and when better machines comealong the code can be easily transported.

Ada also means software engineer-ing. The language promotes the use ofsound software engineering principles.Because Ada makes software engineer-ing easier, it has made the use of the lan-guage more widespread. Ada ensuresthat software is developed in a dis-ciplined fashion and as such contributesto the production of quality software.The high-level features of the languageensure that a structured approach is fol-lowed in the development of software,thereby ensuring good design.

Finally, and most importantly, be-cause Ada software is not system-specific, programs will not only be re-usable, but they will also be available asoff-the-shelf software. Indeed, Ada willundoubtedly change the way software isproduced since the language providesthe opportunity to basically do awaywith tailor-made software. It is quite


300

250

200

150

100

1983 1984 1985

Number of Compilers

1986 1987 1988 1989

Fig. 3. Current Ada Technology Status

feasible that software for most applica-tions, be they military or commercialwill one day be available over thecounter.

Cost of using Ada

The bottom line for using Ada todayis cost. Recent studies conducted by theU.S. Navy indicate that the cost toproduce one line of code in any of theold languages such as Fortran or CMS-2is $200 (Cdn), whereas the cost toproduce the same line of code in Ada is$65.00 (Cdn).

Another interesting aspect of cost isthat for traditional languages a line ofcode gets more expensive as the projectgets larger. With Ada, the line of codegets cheaper as the project gets larger.This is because Ada, with its structuredengineering approach to programming,actually results in ease of integration andeconomies of scale. For the same rea-sons, life-cycle maintenance costs areexpected to be much lower for Ada soft-ware than for code produced in thetraditional languages.

Current Situation with Ada

There are now more than 200 validat-ed Ada compilers available in the mar-ketplace from about 50 differentvendors (Fig. 3). The compilers coverthe entire spectrum of the software andcomputer industry. APSE tools are alsoreadily available from more than 100vendors around the world.

Number of Vendors

Ada is now also undergoing its for-mal review with Project 9X. For thisreview, a team of industrial and militaryexperts has been assembled to look atways of improving the language. Oneparticular aspect of the language that isbeing looked at is the use of Ada in mul-tiprocessing environments.

What is particularly interesting aboutthe growth of Ada is its worldwide ap-peal. Some of the commercial projectsusing Ada now include:

* the Canadian Air Traffic ControlSystem

* project Columbus, of the Europe-an Space Agency

* the Copenhagen Airport TrafficControl System

* the Inter-Bank Banking System ofFinland

* the Australian Lottery System

* the Nippon Telephone and Tele-graph Company (for a computer-ized telephone network in Japan)

Expectations

There is no doubt that the process ofstandardizing on Ada will continue. Noris it too presumptuous to believe thatthere could eventually be global reposi-tories of Ada software applicationspackages. Indeed, with Ada, there is noreason why software programs for navalsystems of the future cannot be assem-bled from standard software com-ponents.

Conclusion

First and foremost with Ada is thatit promotes the use of software engineer-ing practices. It is making softwareproduction truly evolve from an art-form to an engineering discipline. Adaenforces the software engineering dis-cipline.

Ada's importance in supporting soft-ware engineering has been recognizedworldwide. What is most surprising isthat even though it was initially deve-loped for the military sector, it is nowwidely used commercially. Major indus-trial projects have chosen Ada becausethe technology is unquestionably matureenough for their applications. Eightypercent of Ada use in Europe is in com-mercial applications such as communi-cations, banking and teleprocessing. Theunderlying value of Ada is that, for thefirst time since the invention of soft-ware, a single language is being acceptedas a world standard for both militaryand commercial applications. A movewhich will undoubtedly have tremen-dous long-term benefits for the military.

Commander Cyr is the DMCS 8 section headfor naval computer technology at NDHQ.


ForumNaval Officers as Programmers -A programmer's viewpointBy Lt(N) Chester Conrad

Introduction

Over the past two decades, a miscon-ception has existed that all naval officersemployed in the field of tacticalprogramming are severely career-limitedand fulfil at best a mechanical function,more appropriately carried out by anytechnician with a bit of training in aprogramming language.

This attitude is perhaps best exempli-fied in the April 1989 edition of the Mar-itime Engineering Journal in an articleby Cdr Roger Cyr entitled "NavalOfficers as Programmers - A WastedResource."

The article assumes a level of naiveteon the reader's part of very largeproportions. Anyone who has had theslightest involvement with commandand control systems - or any computer-ized naval application for that matter -would find it difficult to believe that anylarge software system could be main-tained and upgraded over the years bya group of untrained junior officers hav-ing little or no background experiencewhatsoever.

In a previous article published in theSeptember 1988 edition of the Journal,entitled "Software and the MARE,"Cdr Cyr pointed out that the entireevolutionary model for system develop-ment may be repeated throughout themaintenance phase of a system's life-cycle. "Maintenance" is perhaps a weakword to describe the effort required tomanage a naval tactical system oversome twenty years without any majorchanges in the underlying hardware ar-chitecture - despite the exponentially in-creasing number of requirements thatmust be addressed. The qualities re-quired to be successful in this endeavourinclude innovation, resourcefulness, te-nacity and a good ration of commonsense. Analysis review, redesign, codingand retesting require every bit as muchskill and grey matter - perhaps even

more - than designing new systems fromthe start. To suggest that these qualitiesare limited to the Combat Systems En-gineer is ridiculous. The premise thatsoftware design requires engineeringskills and should be performed by aCombat Systems Engineer is analogousto saying that writing a letter is a liter-ary skill that should be performed onlyby a person possessing an Arts degreewith a major in English.

Software Production - A MethodicalProcess

It is generally accepted that thephases of modern software developmentare Analysis, Design, Coding, Testingand Maintenance. When we speak ofprogramming, it is understood that thismeans coding, or converting the soft-ware design into a form recognizable toa computer by using a programminglanguage. There is nothing magicalabout this process, and yes it is amechanical function that can be per-formed by a person with the requisitetechnical background.

Requirements analysis, software de-sign and testing are phases of generic de-sign that also proceed in a methodicalfashion. They produce the functionalspecifications, design specifications andvalidation documentation to see the sys-tem through to its completion.

In a perfect world, with amplemoney, personnel and time, we couldcertainly give the coding tasks strictly toprogrammers, and our computer liter-ate end-users could produce glowingStatements of Requirements that anydesigner would have no trouble inter-preting. They could also test our systemin great detail, having full knowledge ofthe required inputs and expected results.

However, the world is not perfect!End-users require help in expressing re-quirements in technical terms. The navydoes not have platoons of automatons,known as coders, falien-in three-deepwaiting to code their next application.Testing can be so complex at times thatit requires the combined efforts of end-users, designers and hardware expertsjust to perform a validity check.

"The navy does not have

platoons of automatons...

fatten-in three-deep waiting

to code their next appli-

cation. "

What the navy does have is a charac-ter known as a Programmer Analyst.This person may commence his or herother career in software by learning afew programming languages and per-forming the duties of a coder. As timegoes on though, the programmer analystlearns to deal with end-users, helpingthem to see things from an automatedstandpoint, and assisting in require-ments specification. He or she begins tounderstand the concepts behind struc-tured analysis and design and realizesthe importance of following establishedpractices in software design and de-velopment. Programmer Analysts maynot be engineers, but that does not meanthat they can't apply sound engineeringprinciples to produce high-quality soft-ware products.

In short, the effectiveness of anyprogrammer analyst involved not onlywith naval tactical applications, but anysizable software project, should be


measured by the way in which that per-son puts his or her experience to gooduse. Software engineering in today'snavy is a career, and the people withinthat career stream work long and hardto become proficient at what they do.It is not a function that can be carriedout as a secondary duty by somebodyjust because their job description con-tains the word "engineer."

Conclusion

Software maintenance is a verydifferent activity than hardware main-tenance. In some cases, software main-tenance may require the wholedevelopment life-cycle of a system fromanalysis through testing be completelyredone. The programmer analysts andsystem designers that the navy producestoday in the Canadian Forces FleetSchool are capable of taking a system

from its inception as an idea through tothe final phases of testing and documen-tation, regardless of whether thesepeople are MARS officers, marineSystems Engineers, or Combat SystemsEngineers. The necessary requirementsfor a person to be successful in this typeof career are aptitude and willingness tolearn.

The greatest problem facing Canadi-an naval software applications is a lackof personnel to handle the ever-increasing workload. If we continue toperceive Canadian software specialistsas "career-limited" and "lacking therequisite engineering skills or tacticalexperience to adequately produce ormanage software," then we will con-tinually fail to attract the professionaland dedicated people that the Canadiannavy requires to meet the software crisishead on.

Lt(N) Conrad is the Advanced ProgrammerAnalyst Course Officer at the CanadianForces Fleet School in Halifax.

Naval Combat Trades Structure -Changes now would be prematureBy LCdr B.H. Grychowski

It is commendable that the MAREJournal provides a showplace for newideas. This forum is essential to thehealth and growth of the entire MAREcommunity including the technicians.When a controversial idea is aired, theJournal also forms the avenue for dis-cussing it.

I consider the concept put forward atCdr Cyr's article "A Proprosed NavalCombat Trades Structure for the 1990s"in the September 1989 edition to be verycontroversial. His argument maintainsthat the systems and equipment to beemployed in CPF and TRUMP will beextremely reliable and maintainable.With respect to that supposition, CdrCyr's article proposes to walk back onthe MORPS concept to that ofuser/maintainer. It is my understandingthat MORPS was developed in anticipa-tion of CPF. MORPS is the product ofeffort by representatives at all ranklevels and represents a "corporate plan"for the trades structure. In CPF thenumbers, trade specialties and ranklevels were assigned at some effort. Thatstructure has not yet been tested at sea;therefore, it seems premature to be con-sidering changes.

There are several problems foreseenwith Cdr Cyr's proposed restructure ofthe Combat Systems Department. Thefirst is numbers. No amount of skill canmake up for concurrent activity over anextended time period. The purportedskills of technologists will never over-come the problems of a lack of skilledmanpower to perform the duties re-quired in a warship on a 24-7 basis. Notonly are departmental staff required tobe technically competent but they arealso required to be sailors. As such theCombat Systems Department hasresponsibilities for seamanship evolu-tions and ship's husbandry duties. Thefull scope of ship operations and re-quirements must be taken into accountwhen considering any change in man-ning levels.

The plan proposed by Cdr Cyr onlydiscusses low- and medium-level main-tenance in passing. Bringing the opera-tors up to the skill levels necessary toproduce quality workmanship would re-quire a training course load equivalentto that of the current TQ5. Partiallytrained personnel could causemaintenance-induced failures. There ismore to performing maintenance than

reading an instruction set in PM sched-ules. Under the previous user/maintainerconcept untrained personnel were onlyemployed under the close supervision oftechnically trained supervisors. Asjunior technicians demonstrated moreknowledge and skill they were given in-creasing responsibility. They were re-quired to complete technical On JobTraining (OJT) Packages, which wastime consuming. They also require timeto learn to operate the equipment. In theCPF, learning to operate the equipmentis considered to be a full-time activitywith its own OJT requirements.

The next problem foreseen with thisproposal is the amount of faith placedin the ability of BITE, BIT andsoftware-driven testing. These facilitiesare an aid to the technician, not theanswer to the repair function. Much ofthe equipment in CPF, as mature equip-ment, is of older design. As such, thereremains a significant requirement forconventional fault finding.

With the extent of software used inthe new systems there is also a require-ment for Combat Systems Department


and the senior Combat Department per-sonnel to become intimately familiarwith the system software. Further, Com-bat Systems Department personnel mustbecome experts in their own equipmentand knowledgeable on other equipmentoutside of their discipline in order toshare the maintenance load. Keeping upwith the greater number of systems andequipment will require a more extensiveeffort by technical personnel than everbefore. With the requirement for oper-ators to be very familiar with the detailof software in addition to their opera-tional functions, there may not be timein their careers to train them in hard-ware repair action.

"There is more to perform-

ing maintenance than read-

ing an instruction set in PM

schedules."

The matter of control must now beaddressed. It is anticipated that it willbe difficult to coordinate and control theaction of the existing dedicated techni-cal staff. Complicating the issue by hav-ing to solicit support from anotherdepartment will make it more difficult.The Combat Operators have team andindividual training to perform in har-bour. At sea they will stand in the two-watch system. The ORS can be trainedto handle routine problems on the sys-tem, but the more serious problems willhave to be processed by the technicians.

With the spread of the system through-out the entire ship this becomes a man-power intensive task.

An area not examined in the pro-posed trade structure is career progres-sion. If all Combat System Personnelwere technologists, arrived at from anMETTP-like system, they would allhave to be of fairly senior rank. Withno junior personnel, who would do thecleaning stations and seamanship evo-lutions for the Department? Would allthis revert to the Combat Department?In either case serious dissatisfactionwould arise. The "technologists" mightfeel demeaned should they have to per-form menial tasks. The Combat Depart-ment would feel cheated if it all fell tothem.

To retain a Department comprisedsolely of technologists would be untena-ble. With highly marketable skills andexperience, the technologists will be indemand both in industry and in theofficer corps. Who will replace themshould they go? A working, functionalDepartment must be a cohesive organi-zation with all rank levels represented.It must have its own ordinary seamenand it must have its own chief and pettyofficers and officers to ensure that it actsas a viable organization. Our navy hasnot yet reached this enviable positionand already the winds of change areupon us. The proposed trade structurecould set the Combat System Depart-ment back to a point where there wouldbe no realistic department as was thecase in the early 70s.

In his second-to-last paragraph CdrCyr states that the Royal Navy isreevaluating their trade structure be-cause of the Falklands. It would be in-teresting to read about the system theyintend to reach and why they are mak-ing changes. We are now mature enoughas a navy to not change just because theRN changes. They might be wrong.

In conclusion, we, the Mare commu-nity should not attempt to change themake-up of the Combat System Depart-ment until there is sufficient documentedevidence that it is required. Then,changes may be made taking all aspectsof the current problem and future re-quirements into consideration.

LCdr Crychowski is the CSEO (designate)for HMCS Halifax.

Naval Combat Trades Structure -Some insight to the NET occupationsBy LCdr William G. Dziadyk

The article "A Proposed Naval Com-bat Trades Structure for the 1990s" byCdr Roger Cyr in the September 1989issue was read with interest. The articlewill serve well as a catalyst to generatefurther discussion on the subject ofwhich naval combat system technicianoccupation structures are required to ef-fectively maintain the next generation ofsophisticated CPF, TRUMP and SSK(?)combat systems. However, for such dis-

MARIT1ME ENGINEERING JOURNAL, JULY 1990

cussions to proceed effectively, thepaper should be put in its proper per-spective with respect to the currentproblems in the Naval Electronic Tech-nician (NET) occupations. Any changesto the trades structure must address theknown problems as well as the main-tenance needs of the next generation ofcombat systems. The readers should alsobe made aware of the mechanism whichhas been put in place to address andhopefully solve these problems.

It is unfortunate that the term "pro-posed" was used in the subject article.The term implies that the discussed oc-cupation structure might be an officialproposal. Such terminology has causedsome confusion and uncertaintyamongst members of the NWT and fourNET occupations. Rumours have start-ed, which were not based on fact.

31

The NWT occupation is relativelyhealthy and its Occupation Specifica-tions have been updated to reflect theneeds of CPF and TRUMP. However,few Combat Systems Engineers orsenior technicians would argue the ques-tion as to whether or not there are majorproblems in the NET occupations. It isdifficult to distinguish the NET"problems" from the "symptoms,"however the major areas of concern arebelieved to be:

a. Critical shortage of qualified tech-nicians - The major NET problemis a critical shortage of qualifiedtechnicians for ships' positions. Inthe three feeder trades, there is acombined shortage of 66% and88% respectively for the LeadingSeamen QL5 and Master SeamenQL6A journeymen technicians.These journeymen technician po-sitions at sea are thus being filledby personnel lacking the requiredqualifications. This shortage ofqualified journeymen causes otherproblems such as the misemploy-ment and overtasking of seniorqualified petty officers.

b. Attrition - The individual reasonsfor leaving the service are complexand it is not yet possible to generalizeas to what a primary common causewould be. The subject article's con-jecture that technicians are leaving"primarily because their profession-al qualifications as combat systemstechnicians are going unrecognized"is only one factor in a complexformula.

c. Delayed start of technician training- The prospective NETs are loadedon to their first technical course(QL5) after about five years' serv-ice as operators rather than after theMORPS ideal of about 30 months'service. Very little technicalknowledge and skill is gained by theNET during this five-year operatoremployment. This late initiation oftechnical training has resulted in:

(1) Waivers to promotion poli-cies to allow the use of theActing Rank / LackingQualifications anomaly,

(2) Very high failure rates,(3) Morale problems with

respect to the CombatDepartment operators. TheCombat Department opera-tors are getting their QL5

courses essentially on timewhile the junior NETs oftenstay on board to provideoperator continuity.

(4) Poor seasoning of knowl-edge, skills and leadership atsea due to resulting back-to-back coursing. (When a can-didate eventually gets hisQL5 qualification, he isoften already time-in-rankfor both promotion and thenext qualification course.)

d. Inadequate occupation specifica-tions - The Occupation Specifica-tions do not adequately reflect thecurrent requirements of the navy.Notwithstanding the CPF andTRUMP contractual requirementsthat the maintenance philosophyshall be repair-by-replacement tothe card level and that the appropri-ate BITE and ATE shall allow ap-propriate fault detection, isolationand repair, the real first-line main-tenance requirements are still quiteuncertain. The various system-specific maintenance plans and as-sociated level of repair analysis arenot yet fully visible to the navy. TheNET Occupation Specificationsmust eventually be updated toreflect the requirements of CPF andTRUMP.

"It is unfortunate that the0

term 'proposed' was used....Rumours have started,which were not based on

fact."

e. Inverse rank ratios of establishedpositions - The NET problems arebeing exacerbated by an inabilityof the trades to reach the steadystate MORPS structure of estab-lished positions. The occupationprofile progression has becomequite volatile due to the need toprovide replacement personnel tothe large number of senior techni-cian and shore infrastructure po-sitions from the present number ofjourneyman positions.

f. Delayed start of digital training- The QL5 courses do not present-ly provide the level of digital train-

ing which is required by CPF andTRUMP.

g. CPF maintenance workload - TheCPF CSE Department technicianestablishment of:

(1) one CSE coordinator(CP02 QL6B NET(S)or NWT),

(2) nine NWTs (fourQL3/4/5 OS/AB/LS,four QL6A MS/PO2and one QL6B PO1),and

(3) sixteen NETs (fourQL5 LS, eleven QL6AMS/PO2 and oneQL6B PO1)

may not be adequate for the realrequirements of the operationalCPF. The subject article proposesthat the three NWT and NET(S)QL6B systems level techniciansand the twenty QL3/5/6A elec-tronics and weapons subsystemtechnicians be replaced by nine"Combat Systems EngineeringTechnologists" possessing "a highdegree of technical knowledge ofthe total system and the interac-tion between its various sub-systems or components." Thedegree of required maintenanceeffort may be greater than thatoriginally expected and contractedfor. If this is the case, there willlikely be a need to rationalize theestablishment after the navy hasobtained a full understanding ofthe maintenance requirements ofthe individual subsystems. Thesubject article states that "with thetechnology incorporated in thesystems of our new ships, themedium-level maintenance skillsare no longer required." Such aconclusion cannot yet be drawnfrom the known maintenanceneeds of the individual sub-systems. To the contrary, there isstrong evidence that the NWT,NET(C), NET(T) and NET(A)QL5/6A journeyman technicianswill be essential resources on CPFand TRUMP.

h. Employ ability of QL6B systemstechnicians in shore infrastructure- The present QL6B training isnot appropriate for some 75% ofthe NET(SYSTEMS) taskings.The tasks in only 25% of the PO1Systems Technician positions can


be properly conducted by anysteady state Systems Technician.These tasks are those whichwould be performed in shipboardpositions. The remaining 75% ofthe positions involve tasks in theshore engineering and training in-frastructure. These positions re-quire specialized subsystembackgrounds and thus cannot beeffectively manned by any steadystate PO1 Systems Technician.

The present NET Occupationproblems (or symptoms) must be fullyinvestigated before any proposals for the1990s are developed to change our cur-rent naval combat trades structure. Anyproposals must be fully substantiatedand must reflect the real technical needsof the future fleet and shore infrastruc-ture. In October 1989 the NPPP con-vened an NET Occupation Review

Team under the sponsorship ofDGMEM to fully examine the NETproblems in detail and recommend so-lutions. The major activities in theOccupation Review are:

- Complete Problem Definition,- Review Occupation Specifications,- Establishment Review,- Develop Training Profiles,- Occupation Structure Analysis,- Training Analysis, and- Develop Implementation Plan.

As the NET trade adviser withinDMCS, I hope that I have met my ob-jectives of providing some insight to thecurrent problems within the NET occu-pation and provoking further discus-sion. This insight may assist thecommunity of Combat Systems En-gineers and senior Naval ElectronicTechnicians, through discussion andparticipation in the NET occupation

review process, to effectively developfurther perceptions of the problems andthe way ahead.

LCdr Dziadyk has NET trade adviserresponsibilities within DMCS.

Looking Back ^ ,DDH-205 Destroyer Towing IncidentIntroduction

Several years ago, a DDH-205 wasattempting to make her way to Halifaxafter refit in Montreal. It was the middleof winter and the St. Lawrence Riverwas heavy with slush, and both panand rafting ice. At 0735 on 30 Jan theship was moved off the jetty by tugswith the intention of proceeding downriver under her own power. Almost im-mediately, ingestion of ice caused theloss of seawater circulation to bothturbo-alternators, both main condens-ers, no. 1 diesel and three hull-and-firepumps. The machinery plant was shutdown and the ship was returned to herberth by tug.

On 5 Feb the ship was prepared to betowed. Ice conditions were still so severehowever, that the sailing was postponeduntil 0800 6 Feb.

Events

During the shutdown after the abort-ed 5 Feb sailing, the engine-room insideroundsman received a telephone callfrom the 2 i/c outside machinery advis-ing that "they wanted the steering mo-tors out." As the steering motors were

•


already off and the inside roundsmanwas no longer sure of what he hadheard, the senior man present (a PO1)decided they wanted the "turning gearout." The turning gear was removedwithout the Engine-Room Chief, CERAor the Engineering Officer being in-formed.

Prior to sailing on the morning of6 Feb the CERA received reports fromthe Boiler Room, Engine Room andOutside Machinery Chiefs that theirspaces were ready for sea including con-firmation that turning gear was in. (TheEngine Room Chief had last sighted theturning gear on the previous morningand had not made rounds of the engine-room on the day of sailing.) The CERAthen reported to the EO that the depart-ment was ready for sea.

The ship slipped under tow at 0755with "modified" special sea dutymen.The EO was certain that there would beicing of sea water intakes and had sta-tioned himself in HQ1 and the CERAin the Engineer's office to deal effec-tively with the imminent damage controlproblem. The CERA directed the EOOWto remain with him in the EO's office.At that point there was no one in theengine-room since all machinery wassupposedly stopped. The CERA in-structed the EOOW that the machinerystate notwithstanding, "a man was toobserve the shafts for any movementwhile under tow." The EOOW detailedthe job to the outside roundsman who,unfortunately, started his rounds for-ward and not in the engine-room. Wi-thin the next few minutes there wereseveral hull-and-fire pump failures dueto ice ingestion.

At 0805 the Engine Room Chief wentbelow and heard the shafts turning. Hestarted the electric forced lube oil pumpimmediately and notified the EO and theCERA. The ship continued down riverunder tow and the propulsion systembearings were inspected that night whilethe ship was secured alongside.

Machinery Damage

The main propulsion power trainrotated without forced lubrication from0755 to 0805 at a shaft speed from 0 to20 r.u.m. The cost to inspect themachinery and effect the necessaryrepairs was over $200,000. The damagewas as follows:

a. all four main turbine bearingswere scuffed and requiredreplacement;

b. both flexible couplings requiredcleaning to remove flaked metalparticles; and

c. the port-side after cruising gearwheel bearing was wiped and re-quired dressing.

Lessons Learned

A similar incident occurred in 1964so it is important to take note of the fol-lowing lessons learned this time:

a. clear orders are essential — theEO's night order book was notexplicit enough to prepare the shipfor departure and there were noEO's technical instructions ortemporary memoranda givingdirection in this peculiar situation.Verbal orders can be, and in thiscase were, easily misinterpreted.The order to shut down the steer-ing motors that resulted in theremoval of turning gear is a primeexample. Another is the CERA'sorder to sight the shafts whichlost its urgency by the time theroundsman received it;

b. engineering special sea dutymenshould close up in accordancewith a standard operatingprocedure;

c. constant supervision of shaftingmust be provided in a locked-shaft towing evolution;

d. the turning gear was removedunder unusual circumstances andshould have been reported tohigher authority; and

e. never assume that the machinerystate is as you left it a few hoursor days previous.

News BriefsBravo Zulu

Congratulations go out once again toLCdr Kevin Woodhouse of NEU(A).His article "The Trouble with Turbo-blowers" (MEJ Jan/Apr 90) will bereprinted in the summer issue of MarineEngineering Digest.

CIMarE Digest editor retiresRetired naval engineer Captain(N)

Hank Arnsdorf steps down this summeras editor of Marine Engineering Digest.Arnsdorf, 66, was among the first RCNcadet class at the newly opened RoyalCanadian Naval College in Victoria in1942. Following his retirement from thenavy in 1979, he joined The CanadianInstitute of Marine Engineering and in1981 became editor of the Institute'sbudding Digest.


706 Communication Squa-dron Reunion

On the weekend of 14-16 September1990, the 25th anniversary of 706 Com-munication Squadron and the 30thanniversary of Camp Borden SignalsSquadron will be celebrated at CFB Bor-den. All former members, their spousesand anyone with prior affiliations withthis unit are cordially invited to attend.

In order to facilitate planning, the or-ganizers strongly urge all those desiringto attend to make it known to the com-mittee as soon as possible.

For further information, or to confirmattendance, contact 706 Reunion PRChairman, 2Lt Peter Karagiannis at thefollowing address:

706 Reunion Committee706 Communication SquadronBorden, OntarioLOM ICOTel: 424-1200 extn: 84-7284

orCSN: 270-7284

Mixed gender crew accom-modation

The navy has done just about asmuch as it can for now to integratefemale crew in ships — at least from anengineering standpoint. Structural con-version shipalts to accommodate mixedgender crews are complete in Provider,Preserver, Protecteur, Cormorant andNipigon, as well as in the naval reservegate vessels and the PBs (minesweepers).The modifications consist of providingseparate sanitary facilities and mess-decks for male and female crew.

The only other steam destroyerscheduled for conversion is HMCSAnnapolis, and her shipalt will be com-pleted during refit in mid-1991. Accord-ing to John O'Connor, the DMES 5subsection head for habitability sys-tems at NDHQ, Annapolis will benefitfrom the engineering experience of Nipi-gon's 1989 shipalt for the navy's Com-bat Related Employment of Women(CREW) trial.

"There was a big rush to get the thingdone," O'Connor said. "We ran intosome hiccups with it." Most of theproblems have since been sorted out, headded.

CPF and TRUMP shipalts will haveto wait until the vessel design warran-ties expire. In the case of CPF thatmeans two years after delivery of HMCSHalifax and one year after each of thefollow-on ships. The TRUMP designwarranty expires one year after deliveryof the last ship.

The shipalts have been something ofa "design nightmare," as O'Connorputs it, but the results to date have beenlargely satisfactory. According toO'Connor, CPF and TRUMP will be thelast ships to bear the burden of late-stagedesign for mixed gender accommoda-tion. "All shipbuilding programs fromthis point on," he said, "will be capa-ble (from the outset) of accommodatingmixed gender. MCDV will actually bethe first ship that is designed for mixedgender crew."

Hydraulic Test Facility-opens at SRUA

A new state-of-the-art Hydraulic TestFacility capable of testing and certify-ing a full range of hydraulic pumps,motors, actuators and valves opened forbusiness at the Ship Repair Unit (Atlan-tic) in May. Designed by Basic Hydraul-ics Limited of Welland, Ontario, thefacility's four computer-controlled testbenches will allow diagnostic and post-overhaul testing of virtually all hydrauliccomponents existing in NATO ships.According to DGMEM Project ManagerMike Edwards, the advanced technologyavailable in this facility will make it pos-sible to test new and repaired hydrauliccomponents before they are installed onboard ship.

SRUA commanding officer Captain(N) C. Baker accepts the new HydraulicTest Facility from Boyd DeWaard of Basic Hydraulics Ltd. (CFB Halifaxphoto by Cpl P.L. Tremblett)


"Kootenay bow" updateIn our last issue LCdr Vern Archibald

and Lt(N) Doug O'Reilly told the storyof how a prefabricated bow unit fromthe decommissioned Chaudiere was usedto replace a damaged bow unit inHMCS Kootenay. By way of a postcriptto that article, LCdr Richard House-man, Naval Architect Officer at NEUP,answers the question, where did theKootenay bow go?

"With plans well under way for thedisposal of Chaudiere, the ship had tobe prepared for the possibility of a finalPacific voyage when disposed ofthrough Crown assets. Without a bow,however, the seakeeping and stabilitycapabilities of the ship would be com-promised.

"The most cost-effective "fix" wasto replace the missing section of bowwith the damaged unit from Kootenay.Repair specifications were prepared byNEUP, and the work was efficientlycompleted earlier this year by SRU(P).The photograph of Chaudiere alongsideCape Breton illustrates just how cost-effective this fix really was!"

Chaudiere wearing Kootenay's nose!

Maritime Environmental ProtectionHow the navy fits in

Coming up in October


national defense defence nationale maritime *t&

Documents