Self-Defense Test Ship Remote Combat System Operation

588 JOHNSHOPKINSAPLTECHNICALDIGEST,VOLUME22,NUMBER4(2001)

R. R. YORK and K. L. BATEMAN

T

Self-DefenseTestShipRemoteCombatSystemOperation

Rick R. York and Kirk L. Bateman

heCombatSystemRemoteControlSystem(CSRCS)wasdesignedanddevelopedbyAPLtoprovideremotecontrolcapability fortheweapons,sensors,andcontrolele-mentsontheU.S.Navy’sSelf-DefenseTestShip.Thesecomponentscompriseallofthecombat systemelementscurrentlyusedby theNavy for ship self-defense.TheCSRCSincorporatescustomhardwareandsoftwarewithavarietyofcommercialcomputerplat-forms and operating systems to provide real-time control of the shipboard systems viaconsole-representativegraphicaluserinterfacesataland-basedcontrolsite.ItenablestheNavytosafelyconductlivefiringtestsofshipself-defensesystemsonaseatestrange.

REQUIREMENT FOR A REMOTE- CONTROLLED TEST SHIP

On 10 February 1983, while conducting weaponstesting and training in the Norfolk area, USS Antrim(FFG20)wasstruckbyatargetdronethatskippedoffthesurfaceofthewater.Theaccidentcausedafireinthewardroomandintheelectronicspaces.Acivilianinstructoraboardtheshipwaskilled.Topreventsim-ilar accidents, the Navy imposed restrictions on testexercisesthatprohibittargetvehiclesfromapproachingwithin2.5nmiofamannedship.

Thisrestrictioncreatedanimpassetotestingshort-rangeweaponsystemsfirstaddressedbytheRollingAir-frameMissile (RAM)Block I acquisitionprogram. In1986,duringRAMdevelopmentaltest/operationaltest(DT/OT) planning, the Navy recognized that not alloftherequiredtestscouldbeconductedonamannedship. The final acquisition decision for the RAMBlock I system depended on demonstrated capabilityagainst a set of threats, which included low-altitude,supersonic anti-ship cruise missiles. Tests involving

mostofthespecifiedtargetscouldhavebeenconductedon either a Fleet ship or an existing test ship, but itwasimpossibletoconductarealistictestagainstasuper-sonictargetwhilekeepingthetarget2.5nmifromtheship. To maintain the safe distance, a target wouldeither have to fly in a straight line toward a 2.5-nmioffset point or fly toward the ship and turn towardanoffsetpoint.Ineithercase,itwouldlooklikeacross-ing target to the RAM. Because of the RAM’s rela-tively short engagement range, realistic—i.e., radiallyinbound—target profiles would require a much closerapproachtotheshipthanwasallowed.

To resolve the conflicting requiremements of con-ductingclose-inengagementswhileensuringpersonnelsafety, the Commander Operational Test and Eval-uationForce recommendedcreationof a remote con-troltest ship. In1987,theChiefofNavalOperationsselectedadecommissionedship,formerlyUSSDecatur(DDG 31), and designated it the Self-Defense Test

JOHNSHOPKINSAPLTECHNICALDIGEST,VOLUME22,NUMBER4(2001) 589

SDTS REMOTE COMBAT SYSTEM OPERATION

Ship(SDTS).FundingwasallocatedforconversioninFY1989,andbytheendofFY1994theshipwasreadytosupporttestoperations.

Although the SDTS was initially conceived as atestplatformforRAM,thePhalanxClose-InWeaponSystem(CIWS)BlockIAandBlockIBprogramsandtheEvolvedSeasparrowMissile(ESSM)programhavehadsimilarrequirementstoconducttestsagainst low-altitude,high-speedtargets.TheSDTShasthussubse-quently evolved into a test platform for all ship self-defensesystems.

ThefirstplanneduseoftheSDTSwastheDT/OTofthe AN/SWY-2 combat system, which combines RAMwiththeMk23TargetAcquisitionSystem(TAS).APLandtheNavalSurfaceWarfareCenter(NSWC),CoronaDivision (formerlyNavalWarfareAssessmentStation),were jointly tasked to develop a remote control system(RCS) for theAN/SWY-2.APLdeveloped thecontrolsystem,andNSWCdevelopedthecommunicationslinkconnecting the shipboard elements to the remote ele-ments.However,theAN/SWY-2RCSwasneverusedontheSDTS.Developmentwascompleted,butRAMtest-ingwasdelayedinordertoeventuallytestitinconnec-tionwiththeShipSelf-DefenseSystem(SSDS)Mk1.

Inthemeantime,thefirstactualuseoftheSDTSwasinsupportoftwophasesofCIWStestingduring1995to1997.Thefirstphasewastotestasoftwaremodifica-tiontotheBlockIAsystem,andthesecondwastotesttheBlock IB system.APLdevelopedRCSs forCIWSand the AN/SLQ-32(V)3 electronic countermeasuressystemforthosetests.

RAMtestingbeganontheSDTSin1998.ThetestconfigurationincludedRAM,CIWS,AN/SLQ-32(V)3,theAN/SPS-49Aradar,andSSDSMk1.APLdevel-opedremotecontrolcapabilitiesfortheradarandSSDSandfieldedthepreviouslydevelopedremotecontrolele-mentsfortheremainingsystems.IntheRAMtestcon-figuration,thecombineddatathroughputrequirementsoftheremotecontrolelementsexceededthethrough-putcapabilityof theoriginalcommunications link, soit was replaced with a new higher-capacity link, alsodevelopedbyNSWC.TheRAMBlockIDT/OTwassuccessfully conducted on the SDTS from September1998toNovember1999.

Currently,theSDTSisbeingusedtosupportESSMtesting.ThesystemconfigurationfortheESSMfiringsincludesaRearchitecturedNATOSeasparrowMissileSystem(RNSSMS),CIWS,AN/SPS-49Aradar,TAS,SSDS,andtheMulti-SensorIntegrationandTrackingSystem (MSITS). The MSITS has no operator inter-faceandthereforedoesnotrequireremotecontrol.TheTAS RCS, initially developed as part of AN/SWY-2test preparation, was put into service along with theotherexistingremotecontrolelements.TheonlynewremotecontrolelementthathadtobedevelopedfortheESSM DT/OT configuration was the RNSSMS RCS,

whichAPLfielded inearly2000.ThefirstESSMtestfiring on the SDTS was conducted on 4 April 2000.Elevenmorefiringsareplanned.

CONCEPT OF OPERATIONSTheSDTSisberthedatPortHueneme,California,

andmaintainedandoperatedbyNSWC,PortHuenemeDivision. Test operations are conducted at the NavalAirWarfareCenter(NAWC),WeaponsDivisionSeaTestRange,nearSanNicolas Island,which is oneoftheChannelIslandsabout56nmisouthofPortHuen-eme.TheSDTSdoesnothaveapermanentlyassignedcrew.Foraircraft trackingandfiringexercises thatdonotinvolveasafetyhazard,theSDTSismannedwithasmallcrewofNSWCpersonnelandcontractors.Withtheshipmanned,trackingexercisesareperformedunderlocalandremotecontroltotestthetrackingcapabilityandoperationofthevarioussensorsandtoverifyremotecontrol procedures and operation of the RCS beforeanunmannedtestevent.Theshipoperatesunmannedonlyduringfiringexercisesthatwouldpresentasafetyhazardtopersonnelonboard.

Figure 1 shows the SDTS concept of operations.Duringremoteoperations,shippropulsionandsteerageare controlled from the NAWC Range OperationsCenteratPointMuguviaacontrol systemdevelopedbyNAWC.ThissystemisbasedontheHulkIntegratedTargetSystem,whichhasbeeninuseforseveralyearsfor remotecontrolof surface targetson the sea range.Thesensorandweaponelementsandassociatedinstru-mentation are controlled from the Surface WarfareEvaluationFacility(SWEF)atNSWC,PortHuenemeDivision.VoiceanddatacommunicationbetweentheSDTSandSWEF is providedby a securedigital tele-communications link. Separate analog links are usedtotransmitseveralchannelsofvideofromtheshiptotheremotecontrolsitesatNAWC’sRangeOperationsCenterandSWEF.

ThecommunicationslinkincludesantennasitesatSanNicolasIslandandonLagunaPeakatthePacificMissile Test Center, Point Mugu. The San NicolasIsland site is used when the ship is on the outer testrange, west of the Channel Islands, where the firingtestsareconducted.TheLagunaPeaksiteisusedwhentheshipiseitherinportoroperatingontheinnertestrange, which is the area between the coast and theChannelIslands.

TheSDTSisnotatargetship.Duringfiringexercisesittowsatargetbarge(Fig.2)atadistanceshortenoughtoallowrealistictargetpresentationsbutfarenoughtominimizerisktotheship.

REMOTE CONTROL APPROACHTheremotecontrolelementsforthevarioussensors

and weapons on the SDTS are collectively known as



theCombatSystemRemoteControlSystem(CSRCS).However,largelybecauseofthesequentialwayinwhichtheseelementsweredeveloped,theyareactuallyacol-lectionoflooselycoupledsubsystems.Eachiscapableofoperatingindependentlyoftheothers,andtheycanbeusedinanycombinationrequired.

The remote control subsystems typically consist ofa remote control panel (RCP) at SWEF and a remotecontrolinterfaceunit(RCIU)ontheship.TheRCPsaresoftwareemulationsofselectedsetsofsystemcontrolsandstatus indicators running on UNIX workstations. TheRCIUs provide the physical interfaces to the combat

system elements through custom-built cabling and circuit boards.When a system is placed underremotecontrol,theRCIUretrievesstatusfromthesystemandpassesittoanRCP.Inaddition,theRCIUreceives commands from the RCPandexecutescontrolofthesystemaccordingly. Each RCIU and itsassociatedRCPexchangestatusandcontrolinformationviathenetworkcommunications link by messagepassing using Internet Protocols(IPs).ThisgeneralizedapproachtoremotecontrolisshowninFig.3.

The RCPs are implemented asX-WindowsGraphicalUser Inter-face(GUI)applicationsrunningonUNIX workstations. There are noactual consoles or control panelsat SWEF. Each RCP simulates tosome extent the console or localcontrol panel of the system it iscontrolling.Forexample,theRAMRCP simulates the RAM weapon

Figure 1. SDTS concept of operations. The ship operates from Port Hueneme, Califor-nia. Weapons and sensors are remotely controlled from the Surface Warfare Evaluation Facility (SWEF), and propulsion and steering are remotely controlled from the Naval Air Warfare Center (NAWC). Communication between the ship and the remote control sites is provided by radio and fiber-optic cable.

Figure 2. The SDTS tows a target barge during tests to minimize the likelihood that the ship will be hit.

controlpanel(WCP).TheTASRCPincludessimula-tionsof theTASconsoleand the systemstatuspanel(SSP).TheRCPsinvokeX-Windowsroutinestocreateagraphicrepresentationoftheactualconsoleorcontrolpanel(buttons,statusindicators,tracksymbology,andtextual message display) on the workstation. Systemoperation is entirely point-and-click. Thus, operatorsfamiliarwiththesystemrequirenospecial trainingtooperateitremotelyotherthanhowtoinvoketheRCPfromapulldownmenu.

ThespecificcontrolprovidedbyeachRCPisdepen-dentontheparticularsystemandontestrequirements.Itisusuallynotnecessarytoprovideeverysystemcon-trolfeaturetoaremoteoperator;however,thecontrolfeaturesprovidedaretypicallyalargesubsetofthecon-trol featuresavailableontheactual systemconsoleorcontrol panel. In many cases, the RCP also providescontrolfeaturesnotavailabletothelocalsystemopera-tor.SomeRCPsalsoprovidecontrolofancillaryequip-ment or instrumentation associated with the systemundercontrol.Forexample,theCIWSRCPprimarilysimulatestheCIWSlocalcontrolpanelbutalsoincludesnumerouscontrolsforCIWS-relatedinstrumentation.

TheonlyconsolesnotsimulatedaretheSSDSandRNSSMS consoles since they are AN/UYQ-70 con-soles—basically,UNIXworkstationsinruggedchassis.TheSSDSandRNSSMSconsolefunctionsarealreadyimplementedasX-WindowsGUIs.Remotecontrolofthese systems was accomplished by simply redirectingthe X-Windows displays from the actual consoles toworkstationsattheremotesite.



The RCIUs are VMEbus systems having 4 to 12VMEcards,dependingontheapplication.EachRCIUcontainsanMVME-167single-boardcomputerhostinga Motorola 68040 microprocessor and associated cir-cuitry.ThemicroprocessorrunstheVxWorksreal-timeoperatingsystemandservesasthecontrollinginterfaceto the functions in the RCIU. The other cards arecustomorcommercialinterfacecardsdesignedspecifi-callytocontroloneofthesysteminterfaces.

Generally,theRCIUsareinterposedbetweenactualsystemconsolesorcontrolpanelsandthesystemele-mentstowhichtheconsolesorcontrolpanelsarenor-mallyconnected(Fig.3).Theycontainswitchingcir-cuitrythatallowsthemtobeswitchedinoroutoftheinterface.Whenremotecontrolisselected,theRCIUisswitchedinlineandtakesovercontroloftheinter-face.Thesensororweaponelementisthencontrolledby the RCP for that system. When local control isselected, theRCIU is bypassed so that the sensor orweaponelementiscontrolled,asusual,bytheactualconsoleorcontrolpanel.

SYSTEM DESCRIPTIONThe main components of the CSRCS are several

UNIXworkstations,RCIUs,andremotecontrolpowerswitches.Figure4showstheCSRCScomponentsandtheirlocationsaboardtheSDTSorattheremotecon-trolsite.AninfrastructureconsistingofEthernethubs,radiosthatprovideaconnectionbetweentheshipandshoresite,andcryptologicequipmenttoensureasecureradiolinkunderliesandsupportstheCSRCS.Theinfra-structureprovides a secure and reliableEthernet con-nection between the control site local area network(LAN)andtheshipboardLAN.

The RCPs (e.g., Fig. 5) run on Sun workstations.BecausedevelopmentoftheCSRCSspannedseveral

years, theworkstationsareof sev-eral models: Ultra 1, SPARC 20,andSPARC2.Twooftheworksta-tions,anUltra1andaSPARC2,are locatedaboardtheSDTS;theremainder are located at SWEF.Other than the TAS display, theRCPs can run on any of the Sunworkstations. The TAS displaymustberunontheSPARC2com-putersbecausetheapplicationusescalls to SunView, a toolkit sup-portinginteractive,graphics-basedapplications running within win-dows. SunView is supported bythe operating system (SunOS4.1.3_U1) on the SPARC 2 butnotbytheneweroperatingsystem(Solaris 2.5.1)on theSPARC20

Computerworkstation

Controlconsole

RCIU

Sensoror

weapon

Communicationslink

Co

ntr

ol s

ite

LA

N

Sh

ipb

oar

d L

AN

Figure 3. The remote control approach provides a console emulation at the remote site communicating with an RCIU connected to the system under control aboard the ship.

andUltra1workstations.The Ultra 1 workstation aboard the ship serves as

a software development system and as a host to eachRCIU.TheUltra1softwaredevelopmenttoolincludesacross-compiler,linker,loader,atoolforbuildingGUIs,andvariousUNIXtools (e.g.,vieditorandperl) thatare essential to the development environment. As ahosttotheRCIUs,theworkstationcontainsthebootupscripts,operating systemkernel,andexecutableappli-cationcodeforeachunit.WhenanRCIUispoweredup or rebooted, the boot code, residing in read-onlymemory installedon themicroprocessorboard, causesittologontothehostworkstationanddownloadtheoperatingsystemkernelandtheapplicationcode.

TheCSRCSalsoincludesfiveHPworkstationsthatserve as surrogates for the AN/UYQ-70 SSDS andRNSSMSconsolesaboardtheship.Twoofthese—theSensorSupervisor(SSUP)andtheWeaponSupervisor(WSUP)—areusedastheremoteSSDSconsoles.Theremaining three accommodate two remote RNSSMStracker/illuminatorconsoles(TICs)andoneRNSSMSsupervisor(SUP)console.

Eachsystem(weaponorsensor)undercontroloftheCSRCS has an associated RCIU. Some systems haveancillaryequipmentthatisalsocontrolledthroughtheRCIU.EachRCIUismountedinarackneartheequip-ment under control. The placement of each RCIU isnecessitatedbylimitationsonthelengthofcablescon-nectingtheRCIUandtheequipmentundercontrol.

TheRAMRCIUisconnectedtothemissilesystemvia an adjunct PC-based interface unit developed byRaytheon.Thisunit,inturn,isconnectedtotheRAMWCP.TheRAMsystemRCPhasanadditionalinter-face to its data extraction (DX) PC, which providescontrol of the RAM DX capability. Remote controlof theDXPC is accomplishedusingVirtualNetworkComputing(VNC),afreesoftwareproductdeveloped



by the Olivetti and Oracle Research Laboratory that displays the screenimage fromtheDXPC,operating inaWindowsenvironment,onaSunworkstationattheremotesite.

In a slightly different configuration, the SLQ-32 RCIU is connectedbetween the SLQ-32 digital display processing unit, which is the console,and the digital processing unit (DPU) and also between the DPUand the SLQ-32 power rack. The DPU/console interface is a digital serialinterfacewithauniqueprotocol.Whenremotecontrolisselected,switch-ingcircuitryintheRCIUconnectstheDPUtointerfacecircuitrythatrelaystheconsole interfacemessagesbetweentheDPUandtheRCP.TheRCIUisalsoconnected,viaanEthernetstub,totheSLQ-32DXPC.TheSLQ-32

RCPincludescontrolfortheDXPCandtheSLQ-32electroniccounter-measuressystem.

TheSPS-49RCIUisconnectedbetweentheradar’ssignaldatapro-cessor (SDP)and radar setcontrol(RSC) cabinets. The SDP drivestheindicatorsontheRSCandreadsthe RSC front panel buttons andswitchstates.WhentheRCIUisoffor in local mode, the signals fromthe SDP pass through the RCIUdirectly to the RSC. When theRCIUisinremotemode,thesignalsfromtheSDPareswitchedfromtheRSC to a set of custom interfacecards inside the RCIU. Relays ontheinterfacecards,whichcanbesetandcleared from theSPS-49RCP(Fig. 5), emulate the buttons andswitches on the front panel of theRSC. Other circuitry detects thestatesoftheindicatorsignals,whicharedisplayedontheRCP.

The CIWS RCIU includes acustom interface card supplied byHughesMissileSystems(nowRay-theon).ItisconnectedtotheCIWSWeapon Control Group computer

Figure 4. Block diagram of the CSRCS. Shipboard and remote site components and their connectivity are shown.

Figure 5. The SPS-49 RCP simulation contains many of the controls and indicators avail-able on the shipboard console.

Remotepower

switches

Sun Ultra 1RAM

workstation

Sun SPARC 20SLQ-32

workstation

Sun Ultra 1SSDS/SPS-49

workstation

HP-UXSSDS

workstations

SSUP

WSUP

HP-UXNSSMS

workstations

SUP

TIC1

TIC2

Sun SPARC 20CIWS

workstation

Sun SPARC 2TAS

workstation

CSRCSdevelopmentworkstations

Sun Ultra 1

Sun SPARC 2

Control site LAN

Test ship LAN

TASRCIU

Remotepower

switches

CIWSRCIU

Remotepower

switches

NSSMSRCIU

SSDSRCIU

SLQ-32RCIU

SPS-49RCIU

RAMRCIU

UYQ-70RNSSMSconsoles

SUPTIC1

TIC2

UYQ-70SSDS

consoles

SSUPWSUP

Switchunit

OJ-194TAS

consoleTerminal

unitSSDSRCP

SLQ-32DX PC

WCPinterface

unit

RAMDX PC

RAMSPS-49A

SLQ-32 SSDS LANaccess units

RNSSMS LIPand TIPs

Camerasand

VCRs

CIWSTAS

SWEF

SDTS



via a systembus,which is alsoused for the interfaceswiththeSSDSandtheCIWSdatacollectionsystem.The interface card transfers data between the CIWSbus and the VME bus, allowing the Weapon ControlGroupcomputerandthecontrolprocessorintheRCIUtoexchangecommandsandstatus.Inadditiontocon-trollingtheCIWSradarandgun, theRCScontrolsathermalimagerandseveralcamerasandVCRsusedtomonitorandrecordCIWSengagements.Thecamerasareconnectedtoavideochannel-selectswitch,whichisalsocontrolledviatheRCP.

TheTAS iscontrolled through two separateunits:anAN/UYA-4consoleandanSSP.Theconsolehasaninterface to the TAS computer and provides for thedisplay and control of system functions controlled bytheTAScomputerprogram.TheSSP interfaceswiththe TAS SDP and controls a small set of radar func-tionsnotcontrolledbythecomputer.TheTASRCIUisconnectedtotheconsoleinterfacethroughanexter-nalNavyTacticalDataSystemswitchunitandtotheSSPthroughcustom-switchingcircuitry.TheTASRCPincludes simulationsof theconsoleand theSSPonasingleworkstation.

Remote control connections to the SSDS andRNSSMS are different from the other systems. TheRCIUsforthesesystemsdonotconnecttothecon-soles.Instead,theconsolesareconnecteddirectlytothe shipboard LAN via the onboard Ethernet portsof their internal processors. HP workstations, actingasremoteX-Windowsclients,provideremotedisplayandcontrolof these systems. Inaddition, theSSDSandRNSSMSincludesystemelementsnotcontrolledby the consoles, for which RCIUs and RCPs arerequired.

TheCSRCSalsohas aDXcapability formonitor-ingandtroubleshootingitsapplications.TheDXsystemresides in a separate chassis connected to the systemnetwork.Although it isnot typicallyusedduring testoperations,theDXsystemcanrecordmessagessenttoitbytheRCIUs.Thesetime-taggedmessagesareavail-ableforoff-lineanalysisandcanaidintroubleshootingproblemsthatmightariseintheCSRCS.

REMOTE DISPLAY TECHNIQUESTheuseof thenetworkcommunications linkallows

great flexibility in implementing remote display andcontrol systems. Any remote display technique thatcan be implemented on an Ethernet connection canbe implemented between the SDTS and the remotecontrol site, constrained only by data through-put limitations. Three different techniques have beenimplementedontheSDTS.Inthetechniqueusedwiththe RCIUs and RCPs, display and control are imple-mentedintwoseparatesoftwareapplicationswhichcom-municateusing standard IPs.TheSSDSandRNSSMS

consolesuseremoteX-Windows.TheVNCsoftwareforthe RAM DX PC is based on a remote frame bufferapproach. Several commercial and public-domain soft-warepackagesareavailableforthispurpose,buttheyaregenerallyonlyapplicabletoWindows-basedPCs.

The selectionof a particular technique for eachoftheRCSswasdrivenprimarilybyconsiderationsofnet-workbandwidthuseanddifficulty(cost)ofimplemen-tation.Thenetworkcommunicationslinkhasanamplethroughput capacity of about6Mbits/s (fourT1 tele-communicationlines).Evenso,itspurposeistosupportreal-timeoperationofweaponsystems,soitisimportantto restrictusage towellwithin the theoretical limita-tionsinordertominimizenetworkcollisionsandlatentmessagedelivery.Onlythemessagessentfromtheshiptotheremotesiteneedtobeconsideredindeterminingthroughput.Theamountofdatasentfromtheremotesitetotheship,consistingmainlyofoperatorcontrols,isrelativelyinsignificant.

The RCIU/RCP approach is used most often. Itrequires the leastamountofdata tobeexchanged. Inthis approach the messages sent from the ship to theremote site contain only the information to be dis-played.TheRCPhasalloftheinformationandinstruc-tionsfordisplayingthedata.IntheremoteX-Windowsapproach,thecontrolpanelsaregeneratedbytheship-boardconsole,andthedata sent fromtheship to theremotedisplayincludetheinstructionsfordrawingthepanels. This is usually a much larger volume of data,but theapproach isused for theSSDSandRNSSMSbecauseofthedifficultyofhostingthosedisplayappli-cations at the remote site. The remote frame bufferapproachisverysimpleandinexpensivetoimplement,and because the commercial software used to imple-ment it is designed to work over telephone modems,it does not require much data throughput. However,because these applications are designed for low datarates, they typicallyupdate thedisplaysonlyoncepersecond,whichisinsufficientforreal-timecontrolofthecombat system. Consequently, they are used only forcontrolofinstrumentation,whichisnottimecritical.

The RCIUs and RCPs exchange messages througha standard client-server protocol using TransmissionControlProtocol(TCP)/IPsockets.TheRCIUsactasthesocketservers.Uponinitialization,theywait forarequest for a socket connection from their associatedRCP client. After a socket is established, the RCIUandRCPcommunicatebyexchangingpredefinedstatusandcontrolmessages.Thismessage exchange is facil-itated by packages of message passing and socket-handling software routines known as common sockethandlers. One set of socket-handling routines, whichruns under the VxWorks real-time operating system,was developed for use with all of the RCIU software.Anotherset,whichrunsontheSunworkstations,wasdevelopedforusewithalloftheRCPapplications.Each



RCIUapplicationwillacceptonlyoneclientapplica-tion,soitisimpossiblefortwoinstantiationsofanRCPtoinadvertentlysharecontrolofasystem.

Inadditiontothedisplayandcontrolmessages,theRCIUs and RCPs also periodically exchange “wrapmessages.” These are used, in the absence of otherdata, to ensure that messages are still being passed.If anRCPdoesnot receiveawrapmessage from itscorrespondingRCIUwithinafixedtimeinterval,anindicationisgiventoalerttheoperator.Thiswilltypi-callyoccurbecauseofamomentarydisconnectinthecommunications link but could also be because of afailureoftheRCIU.Itisimmediatelyapparentwhichis the case because if there is a disconnect in thenetwork link,allof theRCPswillprovide the sameindicationsimultaneously.TheTCP/IPsocketproto-colensuresthatmessagesaredeliveredcorrectlyandin sequence. Thus when communications are inter-rupted, the status and control messages are bufferedandretransmissionisattempteduntileithercommu-nicationsarereestablishedorthebuffersoverflow.

TheremoteX-WindowsapproachusedfortheSSDSand RNSSMS required virtually no software develop-ment for either the shipboard consoles or the remoteworkstations.Only the start-upscripts for theconsolesoftwareweremodifiedsothatoneoftheremotework-stations, rather than the console itself, was identifiedasthedisplayserver.Remotecontrolisinitiatedbyanoperator logging in to one of the shipboard consolesfromaremoteworkstationusingacommandshellandinvoking the modified start-up script. When the con-solesoftwarestarts,thedisplaysaresenttotheremoteworkstation rather than to the console, and input istakenfromtheremoteworkstationkeyboardandmouseratherthanfromtheconsolekeyboardandball-tab.

TheX-WindowsclientandserveralsocommunicateviaTCP/IPsockets.Thuswhenmomentarydisconnectsin the communications link occur, messages are buff-ered,aswith theRCIU/RCPapproach,untilcommu-nication is reestablished or buffers overflow. No alertisgiventotheoperator,butbecausethesedisplaysareveryactive,adisconnectisusuallyimmediatelyobvious.However,becauseofthevolumeofdatabeingsentoverthe link, thebufferscanoverflowmuchmorequickly,causingtheremotedisplaystobedisconnected.Whenthisoccurs,theconsoleapplicationshavetoberestartedto reestablish remote control. This makes the remoteX-Windows approach somewhat less robust than theRCIU/RCPapproach.

The remote frame buffer approach is implementedin the CSRCS using the free VNC software applica-tion. VNC is also based on client and server compo-nents which communicate over the network. Severalversionsoftheclientandserverapplicationsareavail-ableforWindowsPCsandvariousUNIXworkstations.The server application captures the raster scan data

comprisingthescreenimageofthePCorworkstationonwhichitisrunningandsendsittotheclientappli-cation.Theclientapplication,runninginaremotePCorworkstation,displaysthescreenimageoftheserverPCinawindowonitsowndisplay.Mouseandkeyboardcommands executed on the client machine are trans-mittedtotheserver.Theclientandserverapplicationsdonothave tobe the same typeofplatformoroper-atingsystem.WithVNC,itispossibletouseaUNIXmachineforremotecontrolofaPCorviceversa.

COMMUNICATION AND WEAPON SAFETY ASSURANCE

In addition to providing remote control of thenormalcombatsystemfunctions,theCSRCSincludesfeatures for handling the inevitable lapses in commu-nicationbetweentheshipandtheremotesiteandforensuring system safety, particularlywhencommunica-tion is lost. Although the communications link pro-vides fairly robust connectivity, as with any wirelesssystem,uninterruptedcommunicationcannotbeguar-anteed.Interruptions,therefore,mustbemanaged.Thetwo principal requirements for the control system areto ensure that the shipboard systems, particularly theweaponsystems,reverttoandremaininasafecondi-tionwhencommunicationislostandtoresumeopera-tionsoncecommunicationisreestablished.

When momentary lapses in communication occur,thecombatsystemcontinuesoperatingasnormal,basedon the last input received from theoperator.Becausealloftheactualcombatsystemelements,includingcon-soles,areontheship,onlytheoperatorisdisconnectedfromthesystem;thesystemitselfremainsintact.Indica-torsontheremoteworkstationsalerttheoperatortoalapse incommunicationwith the shipboard system. Iftheoutageisrelativelybrief,themessageswillberetrans-mittedandthedisplaysupdatedaccordinglywhencom-munication is reestablished. If theoutage exceeds thecapacityofthecontrolprocessorsorshipboardconsolestobufferthedata,theremotedisplayshavetoberein-itialized. This typically requires an outage of severalminutes, with the actual duration depending on thesystemactivityatthetime.Ifcommunicationislostformorethan5min,theTASandSPS-49RCIUswilldis-ableradiationandantennarotationoftheirrespectiveradars. If those systems are rotating or radiating, theywillbeshutdownasasafetyprecaution.

Ifanyoftheweaponsystemsareinthe“arm”state(or“weaponsfree”stateinthecaseoftheRNSSMS)when communications are lost, they will be forcedbacktothe“safe”state(or“weaponstight”inthecaseof the RNSSMS) after a given time. This is accom-plishedbyapairofrelayswithassociatedtimercircuits,referredtoas“arm”and“armlock”timers,whichareineachoftheweaponsystemRCIUs.Thearmandarm



locktimersworkintandemtocontrolthestateoftheirrespectivefiringcircuits.

Thepurposeofthearmtimeristoforcetheweaponsystemtoasafe(weaponstight)conditionifcommu-nication is lost while the system’s firing circuitry isenabled. To enable a system’s firing circuit, an armcommandmustbesentbytheweaponsystem’sRCP.Whenanarm(weaponsfree)commandisreceivedbytheRCIU,thearmrelayisclosedandthearmtimerisstarted.This1-mintimerisimplementedbyacoun-ter circuit. When it times out, the relay is openedandtheweaponsystemrevertstosafe(weaponstight).However,whileinthearmcondition,theRCPauto-maticallycontinuestosendarmcommandsat0.5-minintervals, reinitializing the counter and maintainingthearmstate.Ifcommunicationisinterruptedformorethan 1 min, the counter will time out and the relaywill open, forcing the weapon to the safe (weaponstight)state.

Thepurposeofthearmlocktimeristomaintainthearm(weaponsfree)stateforashortperiodoftime,evenifcommunicationislost.Typically,duringatestevent,arm lock is set after the test range is cleared and justbeforelaunchingthetargetattheship.Thisallowsthesystemtocompleteanautomaticengagementofatargetif communication is lostafter theengagementbegins.When the operator sends an arm lock command, thearmlockrelayissetandthearmlocktimerisstarted.This 4.5-min timer is also implemented in a countercircuit.Thearmlockrelayoverridesthearmrelay,sothatevenifthearmcountertimesout,thesystemwillremainarmeduntilthearmlockcounterexpires.

WEB-BASED INTERFACES

Remote Power ControlTo facilitate the operation of the shipboard equip-

mentfromtheremotesite,eachRCIUissuppliedpowerthrougharemotelycontrolledpowerstrip.EachpowerstripisconnectedviatheLANtotheUltra1worksta-tionaboardtheship.TheUltra1hostsaWebserver,allowingthepowerstripstobeaccessedfromanywork-stationontheCSRCSnetworkviaaWebbrowser.Thebrowserinterfaceprovidesindependentcontrolofeachof theeight socketsonthepower strip.Theavailablecontrolsare“off,”“on,”and“reboot.”Rebootcyclesthepower,turningitoffforafewsecondsandthenturningitbackon.Thisisparticularlyusefulwhenitisneces-sarytoremotelyperformahardrebootofanRCIU.

Network UtilitiesTheCSRCS incorporatesWebPing, aWeb-enabled

utility,toprovideoverallsystemstatusaswellasasurveyof all the nodes on the CSRCS network by using agraphicalred/yellow/greenstoplighttoindicatewhethereach element of the CSRSC is down, unavailable, or

up, respectively. This information is summarized on asingleWebpage,allowingaquickglancetodeterminetheavailabilityoftheCSRCSelements.

A data reduction utility is also available via a Webbrowser.ThisutilitycanbeusedtoanalyzeanymessagedatarecordedbytheCSRCSDX function.Itemploystwocommongatewayinterfaceprogramstoobtaininfor-mation from and provide results to the user. The userspecifiesafilenameandthedesireddataproduct,andthedatareductionutilityproducesthedataproductandpres-entsittotheuserinabrowserwindow.

Inaddition,somedocumentationisprovidedonline.DocumentsdescribingsystemcomponentsareprovidedinHTMLformat,makingthemreadilyaccessiblefromvariouscomputingplatforms.Otherdocumentationpro-vided online includes procedures for managing theCSRCSsoftwareconfiguration,backinguptheCSRCSworkstations,andinitializingandoperatingthevariousCSRCScomponents.

TESTING ABOARD THE SDTSTheSDTShasbeenused to support the testingof

CIWS, RAM, ESSM, and other systems. These testshaveincludedremotecontroloperations,bothmannedandunmanned.

FromApriltoJune1997,CIWSBlockIBwastestedaboardtheSDTS.ThemostsignificantupgradestotheBlock IBvariantwere theadditionofa forward-look-ing infrared imaging system and the capability to usethesystemagainstsurfacetargets,e.g.,smallboats.TheCIWSBlockIBinstallationaboardtheSDTSisshowninFig.6.Theforward-lookinginfraredimagingsystemis mounted on the right side of the radome. BlockIBunderwentseveralremotelycontrolledtestsinclud-ing operations against seaskimming and diving anti-shipmissiles(ASMs).Asuccessfulremotelycontrolledengagement of a seaskimming ASM is shown in theinsetofFig.6.

In1998and1999, theSDTShostedbothmannedand unmanned RAM tests. The RAM launcher, asinstalledaboardtheSDTS,isshowninFig.7.Seaskim-minganddivingASMs,bothsubsonicandsupersonic,werepresentedastargetsduringthetests.AninterceptofasupersonicseaskimmingASMisshownintheinsetofFig.7.

ESSMtestingontheSDTSbeganin2000andisexpectedtocontinueinto2002.TheESSMtestsched-ule calls for 12 remotely controlled missile engage-mentsfromtheSDTS.ThefirstESSMfiring,inApril2000,isshowninFig.8.

TheSDTShasbeenusedforcriticaltestingofshort-range self-defense systems againstASMsaswell as lessstressingtargets,e.g.,small,slowaircraft;jetaircraft;andsmall boats. It has proven invaluable for testing thesevarioussystems.WithouttheSDTS,testingsuchsystemsagainstrealistictargetsinrealisticscenarioswouldnotbe



Figure 6. CIWS Block IB installed aboard the SDTS. Inset illustrates the successful engagement of a seaskimming ASM.

Figure 7. RAM launcher installed aboard the SDTS. Inset illustrates RAM successfully engaging a seaskimming supersonic ASM (inset courtesy of Raytheon).

possible.AsummaryofoperationsduringwhichASMswere engaged by systems aboard the SDTS is given inTable1,whichindicatesthevarioustypesandnumbersofASMsflownagainsttheSDTS.

CONCLUSIONThe SDTS and the CSRCS allow the Navy to

safelyconductrealisticandeffectivetestingofitsshipself-defense weapons against targets representative ofexpectedthreats.

The CSRCS incorporates a variety of commercialandcustomhardwareandsoftwareelementstoprovideremoteoperatorcontrolof several sensor,weapon,andcommand and control systems, as well as many associ-ated instrumentationsystems,allhavinguniquesystemarchitectures.Italsoappliesavarietyofremotecontrol

Figure 8. The first launch of an ESSM from the SDTS in April 2000.



Table 1. Summary of operations in which ASMs were engaged by SDTS systems.

1995 2

1996 3 2 2 1

1997 1 1

1998 1 1 1 2 1

1999 1 3 2 3 2 3

2000

2001 2

Total 2 1 6 6 2 4 3 3 3 3 1aRepresentsactualnumberoftargetsflown,notnumberofscenarios.

HA

RM

SETT

-8A

VandalStream

a

VandalD

iver

VandalEER

VandalER

HarpoonStream

a

Harpoon

BQ

M-74E

MM

-38

BQ

M-34S

Year

KIRKL.BATEMANbeganhiscareeratAPLin1986andisamemberoftheSeniorProfessional Staff assigned to the Air Defense Systems Department’s CombatantIntegrationGroup.HereceivedaB.S.degreein1986fromtheUniversityofCol-orado and an M.S. degree in 1991 from The Johns Hopkins University, both inelectrical engineering.AtAPLMr.Batemanhasworkedonvarious radar, sonar,andnavalcombatsystemsprojects.Mostrecently,hehasprovidedsystemengineer-ing support for the Ship Self-Defense System Mk 2, particularly in the areas ofcombatsysteminteroperabilityandsensorintegration.Mr.Bateman’[email protected].

THE AUTHORS

RICKR.YORKisamemberofAPL’sSeniorProfessionalStaffandaprojectman-agerintheAirDefenseSystemsDepartment.HeholdsaB.S.degreeinmathematicsfromtheUniversityofMaryland,UniversityCollege.SincejoiningAPLin1982,Mr.Yorkhasworkedprimarilyonintegration,test,andevaluationofsurfaceshipanti-air warfare systems including the NATO AAW System, Ship Self-DefenseSystem,andRearchitecturedNATOSeasparrowMissileSystem.HewastheleadengineerforthedevelopmentoftheSelf-DefenseTestShipCombatSystemRemoteControlSystemandcurrentlymanagesAPL’sNATOSeasparrowandEvolvedSea-sparrowMissileprojects.Hise-mailaddressisrick.york@jhuapl.edu.

techniques.Theuseofadigitaltelecommunicationslink,whichsupportsstandardIPsforinterprocessorcommuni-cation,providestheflexibilitytoselectappropriatetech-niquesforeachsystem.TheCSRCSprovidesoperator-intuitiveinterfacesofalargesubsetofcontrolsforeachsystem in a uniform X-Windows environment. It alsoprovides controls, necessitated by the remote aspect of

system operation, for ensuring system safety, managingcommunicationslinkfailures,andrebootingsystemele-mentsifrequired.

TheSDTSCSRCShassuccessfullysupportedCIWSBlockIAandBlockIBtestingandRAMDT/OT.ItiscurrentlybeingusedtosupporttestingoftheRNSSMSandESSM.