Ship Self-Defense System Architecture - The Johns · PDF fileShip Self-Defense System...

536 JOHNSHOPKINSAPLTECHNICALDIGEST,VOLUME22,NUMBER4(2001)

L. S. NORCUTT

T

ShipSelf-DefenseSystemArchitecture

Larry S. Norcutt

he Ship Self-Defense System (SSDS) was devised to provide self-protection andcombatsystemcapabilitytonon-AegisshipsoftheU.S.Navy.Thisautomatedcombatdirectionsystemusesmanycommercialhardwareandsoftwareelementstoachievethefirst Navy distributed processing combat system, integrating already developed weaponandsensorsystems.TheSSDSarchitecturewasaninnovationandsomewhatofarisk,butwelljustifiedinlightofitssuccessfuldevelopmentandthecontinuedbenefitsithasshown.TheSSDSMk1iscurrentlyoperationalon11NavyLSDsanditsbiggervariant,Mk 2, is well under development for the Navy’s newest aircraft carrier and ship class.SSDSarchitectureconceptshavesucceededinadvancingboththestateoftheartandthetacticalcapabilitiesoftheU.S.Fleet.

INTRODUCTIONTheprimarymissionoftheLSD(landingship,dock)

class of Navy ships is to support amphibious assault–conveyingand–landingMarinetroopsontopotentiallyhostile shores. With the increasing capabilities of theanti-ship missile threat and the likelihood of Navycombat operations in the near-shore littoral regionscametherequirementtosignificantlyimprovetheself-defensecapabilitiesofthisshipclass.Ineffect,theshipsneededanautomatedCombatDirectionSystem(CDS),smaller inscalethanthatofprimarycombatants suchasdestroyers,cruisers,andcarriers,buthighlycapableofthedetect,control,andengagefunctionsnecessaryforself-defense.

Limitedbybudgetandtimeconstraints,Navyeffortsfocusedontheautomation,optimization,andintegra-tionofexistingweaponsandsensorstomoreeffectivelydefend the ship. The resultant automation and inte-gration, performed by a networked set of commercial

computers andoperatordisplays,wasnamed theShipSelf-DefenseSystem(SSDS)Mk1.

The new SSDS design incorporated lessons learnedfromover20yearsofexperience inNavy tactical soft-ware and sensor integration development, and appliedthoselessonstotheparticularcharacteristicsofcombatsystemdataandprocessingneedsinanopen-architecturedistributed-processingcommercial-off-the-shelf(COTS)environment.This included interfaces,processors,datadistribution,computerlanguages,operatingsystems,dis-plays, software design concepts, and sensor integrationconcepts.ThesoftwarearchitecturewasbasedonmanyyearsofexperiencedealingwithNavycombat systems,andonshipself-defensestudiesperformedbyAPLinthe1980saspartoftheNATOAnti-AirWarfare(AAW)Program.

SSDS Mk 1 formed the basis of the SSDS Mk 2systemcurrentlyindevelopment.Thislargervariantadds

JOHNSHOPKINSAPLTECHNICALDIGEST,VOLUME22,NUMBER4(2001) 537

SHIP SELF-DEFENSE SYSTEM ARCHITECTURE

to the baseline self-defense capabilities to encompassmore of the traditional shipboard combat system func-tions such as air control and tactical data links. TheMk 2 has a bigger role as the tactical combat systemfortheNavy’snewestaircraftcarrierUSSRonald Reagan(CVN 76) and the developing landing ship, platform–classUSSSan Antonio(LPD17).Thesamebasicarchi-tecturalconceptsapplytobothSSDSvariants.

EVOLUTION OF COMBAT DIRECTION SYSTEM SOFTWARE

The first Navy computer programs were developedintheearly1960sprimarilytosupportmanualoperatorfunctions(e.g.,trackplottingandtracksymboldisplay)and to send surveillance data to other ships (Fig. 1).Computerfunctionsprovidedbookkeepingandnumericcalculationtoassisttheoperator.Becauseofthemanualintervention needed for track maintenance, however,combatsystemcomputerloadingintheearlydayswasrelativelylow.Trackingaccuracywasalsohighlydepen-dentontheinterest,dexterity,andenergylevelofthecombatsystemoperators.Additionaloperatorsupport,such as the synthetic display of information, evolvedintocomputer-basedCDSs.

EarlyCDScomputersallowedcoordinationofmul-tipleshipoperationsforAAWbyautomatingship-to-shipdatatransferviatheradiotransmittersandreceiv-ersofthetacticaldigitaldatalink,Link11.Theyalsoprovidedthecontrolofreal-timedatacommunicationsandformatteddigitalinformationforexchange.Owingto the reliance on manual data input, initial digitallinkdatarateswererelativelylow,andship-to-shipdataaccuracyandconsistencywerepoor.Correspondingly,demands for sophisticated CDS processing were rela-tivelylow.

CDS automation needs were greatly acceleratedduring the late1960sowing tomore stressing tacticalenvironments and the introductionof sensor automa-tion using digital computers. Improved sensor perfor-mance made it necessary to account for more trackswithin the ship’s surveillance region. These largenumbers of tracks within the CDS area of interestaccentuated the need to acquire and maintain timelyandaccurateinformationoneachtrack.Naturally,moreinterfaces,functions,andoperatordisplaysandcontrolswereaddedtotheexistingcomputerstoautomaticallyprocesstheinformation.

Asmoresensorsandweaponswereautomated,addi-tional interfaces and processing software were addedto the CDSs. Building on central computer conceptsofthepast,wheresimplefunctionswereautomaticallysupportedandeasilyaddedtothesoftware,thegrowthof CDS computer processing software continued byexpandingthecentralcomputerprogram(Fig.2).Addi-tionalmemorywasaddedwhenrequired,andspeediermainframeprocessorswerephasedintohandleprocess-ing loads. Further evolutionspartitioned functionalityandprocessingloadsintotwoorthreemainframepro-cessors for improved performance and functional vis-ibility. However, while these fixes relieved individualdifficulties,theyresultedinnewandlargerproblemsinsoftwaredevelopmentandmaintenance.

CDSfunctionalitygrew,butthebasicsoftwareandcomputerarchitecturedidnot.Afteryearsoffunctionalgrowth, the large,centrallyorientedprogramsbecameverycomplexandfunctionallyinterconnected,asillus-tratedinFig.3.Afteryearsofmaintenance,functionaltweaking, and special fixes arranged among program-mersindifferentareas,softwarebecamelargeandcom-plicated. Software maintenance itself evolved into aspecializedart.Insuchenvironmentsitisverydifficult

Figure 1. Early computer use in Combat Information Centers involved a central computer performing calculation functions involved in manual tracking and providing operator displays. The computer also formatted tracking data for communication to other ships.

Figure 2. The CDS central computer architecture featured one or more computers that controlled data communications and began to provide automatic sensor processing and display. The hard-ware architecture remained simple; peripherals were attached to a core processor.


L. S. NORCUTT

tounderstandthewholeprogramorganizationandpro-videchangesorimprovementsinperformancewithoutincurring unpredicted degradations in other programfunctions.Thelargeprogramsbecamesubjecttoerrorduetonumeroususersofcommondatabasesandthedif-ficultyoftroubleshootingthecomplexfunctionalinter-action, data sharing, and program errors in unrelatedfunctionalcode.Softwaremaintenanceandconfigura-tionmanagementwerefurtheraffectedbytheprogramsizeandlogicalcomplexitiesthatexacerbatedthetrain-ing of new software support personnel and often pro-ducedunexpectedconsequencesofcodealteration.

CDS software development and maintenance alsobecameseverelyhamperedbytheuseofmilitarized,non-standardequipment(computers,displays, I/Odevices)and software language. Not only were the militarycomputers relatively expensive, but they had limitedavailability and were relatively inflexible. This subse-quently limited personnel productivity and increasedbothdevelopmentandmaintenancecosts.

Largecentralprocessorprogramsbecameeasilysatu-ratedinprocessingtimedemands.Logicalprocesseshadtobemoresophisticatedtoformproperautomaticeval-uationsandresponsestoalarger,morecomplicatedsetof information thaneverbefore.Thegrowing tacticalenvironment encompassed larger ranges and requiredlarger track capacities. Processing loads, from bothlogical complexity and data volume aspects, quicklyexceeded the capabilities of individual processors. Inshort,thesoftware/computerenvironmentofshipboardCDSs(including sensors,weapons,command support,andcommunications)becameaverycomplexproblem.

SuchwasthetypicalCDSenvironmentin1991,thebeginningofSSDSMk1.

SSDS EVOLUTION: THE SSDS OPPORTUNITY

From a computer system and software architectureperspective,theSSDShadthegoodfortuneofanabsent

past.Sincetheshipforwhichitwasdevelopedhadnoprior computerized CDS and no major combatant airwarfaremission,therewaslittlejustificationforinstall-ingexistingCDScomponentsandthentailoringthemto the LSD self-defense role. It was easier to providenewautomationforthiswell-definedneed.TheSSDScomputer,software,display,anddatadistributionarchi-tecturecouldusenewconceptsofsoftwareengineeringand computer science that were not available in theearlydaysof theCDS.Furthermore, theSSDSdesigncouldapplylessonslearnedfrompastCDSexperiences.

The opportunity to develop a new combat systemwasoffsetsomewhatbyalackofguidingspecificationsfor system functions, computer architecture, and soft-ware architecture.Asdescribed in thenext articlebyThomasetal.,thesystem’stacticalfunctionalrequire-ments were defined by flowing down top-level opera-tionalrequirements.Thisisarelativelystraightforwardprocess.Therequirementsforthesupportingcomputersystemandsoftwarearchitecture,however,werenotsowell defined. Typically, they had to be derived fromthetacticalfunctionalrequirementstoextractdatapro-cessingperformancerequirementsimplicitinthetacti-cal needs and the nature of the data available to thecombat system.For theSSDS,dataprocessingperfor-mancerequirementswerederivedfromdetect/control/engagereactiontimerequirements,fromthevolumeoftracks expected in the ship’s surveillance region, andfromtheobservedandpredicteddataratesoftheship’ssensors(themostdemandingofthedataproviders).

Additionalguidancecamefromhigher-levelrequire-ments of a programmatic and historic nature. SSDSsoftwareandcomputerarchitecturedesignersrecognizedthis ill-defined but critical feature of combat systemdevelopment.Thefollowinggeneralrequirementscon-tributedtotheSSDSarchitecture.Theyarealmostnon-quantifiable and largely historic—reflecting 20 years’observance of Navy tactical software—but significantnonetheless.

OneofthemaincontributorstotheSSDSarchitec-turewasthedesiretosimplifythefunctionalrelation-shipsamongthesoftwaresoastologicallyandperhapsphysically decouple the complex interactions seen inmuchofthehistorictacticalsoftware.Inaddition,theNavy tactical processing architecture had to achievecostandperformancebenefitsderivedfromthequicklyimproving processing and data transfer performanceofferedbyCOTSproductsaswellasimprovementsincomputer languages;however, thearchitecturehad tobeeasilyadaptedtothebrieflifeofeachnewproduct.

Tactical software architectures must address thenatureofcomputerprocessingandthesysteminterfacesofthecombatsystem.Tacticaldataprocessingistime-critical and must address large volumes of data fromownship sensors and offboard platforms. The featuresfound in typical commercial operating systems such

Figure 3. Many unique logical and data transfer “interfaces” among functions within the central processor lead to complex interactions that are difficult and expensive to expand, modify, or maintain. The central processor is easily CPU- and I/O-bound, particularly with the high-order language requirement and increas-ing numbers of sensors and weapons. This organization is not well matched to the characteristics of combat system data flow or processing.



as UNIX do not support the critical response timesandpredictableperformanceneedsoftacticalprocess-ing. Tactical processing must occur in real time athighvolumeandlowlatency.Itmustalsoaddressthe“…ility” requirements that greatly affect system cost,developmentease,andgenerallong-termquality;e.g.,

Maintainability:Cansoftwarefixesandcorrectionsbemadeeasily?

Extensibility: Does the software architecture easilysupport growth in functionality, processors, inter-faces,andlanguages?

Understandability/visibility/comprehensibility:Isthesoft-waresystemconceptuallysimple,orareitsoperationscomplexandobtuse?

Reliability:Canthesoftwaresystemgivepredictableperformance?

Testability:Canthesoftwarebeeasilytested,andarethereconvenientmeasurementpoints?

The software must have a robust design to accom-modatetheunpredictablenatureoftacticalprocessingloadsandpotentialequipmentfaults;functioninaless-than-completeprocessingenvironment;notbesuscepti-bletocriticalsinglepointsoffailure;andbelooselycou-pledsothatfunctionscanberemovedoraddedeasily.Also, because of the frequent revision and improve-ment of COTS products, the software and processingelementsmustbeeasilyupdated,andachangetoonemustnotgenerallyaffecttheother.

These requirements, together with lessons learnedfrom past CDS efforts and APL’s sensor integrationexperience, resulted in an SSDS design that was newconceptually,physically,andfunctionally.

SSDS ARCHITECTURE DESCRIPTION

Architecture Concepts

Information-Oriented Design Concept The SSDS software architecture incorporated the

information-orienteddesign(IOD)conceptthatevolvedfromAPL’sNATOAAWstudies.Thissoftwaredesignconcept was specifically applicable to a distributedcombat system environment, satisfied all the “ility”requirements,andprovidedan“open,”looselycoupled,logical processing environment.Rather than focus onpoint-to-point functional and physical interfaces, theIOD concept recognized the continuous and concur-rentnatureofcombatsystemdataprocessing,andcon-centratedontheinformationthatwasbeingproducedandtheresponsibilityforitscreation.AsillustratedinFig. 4, IOD combat system functions do not interactwith each other, but rather with the flow of combatsysteminformation.

Functionsaresimplyassigneduniqueresponsibilitiestoproduceuniquesysteminformation,whichisbroad-castasmessagesthroughoutthesystem.Eachfunctionisofferedaccesstothesysteminformationflowfromwhichitwillperform itsownduties.For robustdesign, eachfunction must deal with potentially incomplete infor-mationandmust recognize system informationeventsthatareparticularlysensitiveorpivotaltothefunction’spurpose.Collectively,thisrobustinformationfocuspro-videsfunctionalindependenceandaloosecouplingofthesoftwareprocesses.

In general, information is only generated uponchange.Thisservestwopurposes:(1)thegeneralrevi-sion and minimal data loading of information poten-tially used by other system functions (i.e., databaseupdate),and(2) thepossible triggeringofother func-tion processes that are keyed to changes in particularinformation.

Fromasoftwaresystemdesign/developmentpointofview,thefunctionalindependenceoftheIODremovesthelogicalcomplicationsofsequentialfunctioncoordi-nationandcommunication.Fromanintegration/testingpoint of view, if a function is not available, its onlyimpact is the lack of its particular information in thesystem-wide database. Other functions must continueto operate to their best capacity on less information.Testing anddevelopmentof individual functionsmaybe performed in isolation, stimulated only by a con-trolledmessageflowandevaluatedsolelyontheirabil-itytogeneratetheirassignedinformation.

Given this form of functional independence, it iseasy todevelopphysical independence in the formofdistributedprocessorarchitectures.Thisallowsmassivecomputingpowertobe focusedonparticularly impor-tant functions, providing growth and change that arecompletelyindependentofothersystemprocesses.

Combat system information flow

Combat system functions and subfunctions

Not this:

But this:

Figure 4. The information-oriented software design concept decouples complex, highly interrelated functions and instead fea-tures independent functions with access to a common information source.


L. S. NORCUTT

The addition of a new system function in such anenvironment requiresonly thedefinitionof the infor-mation(if any) itwill add to the system information.Existingfunctionsneedtobechangedonlyiftheaddi-tionalinformationisdesiredtoimprovethequalityoftheircurrentoutput.Bydefinition,thenewfunctionhasaccess to all system information andwill be informeduponupdateofanyportion.Inthisenvironmentthereistotalindependenceoffunctionaldefinitionandimple-mentation.Newprocessesmaybeaddedtothesystemto analyze or extract system information on a com-pletelyindependentbasis.Informationdisplayfunctionsmaysimilarlybeaddedwithtotalindependence.

Information Attribute, Message, and Distribution Concepts

FollowingtheIODtheme,SSDSconceptsdescribethe system in terms of information “entities” havingnumerous “attributes” and relations among attributes.Furthermore,thedataarebroadcastuponchangetoallinterestedfunctionswithintheSSDStouseaseachseesfit.Inasense,thisisaformofobjectorientationwheretheobjectsareactiveratherthanpassive.

Itshouldbenotedthatthecombatsystemitselfmaybe considered an entity described by status attributes.Also,surveillancetracksmaybethoughtofasentities,having attributes of position, velocity, identification,engagementstatus,etc.Collectively,theattributedatadefinethestateofthecombatsystem.Itsfunctionscon-tributetothatstateandreacttochangesinit,asillus-tratedinFig.5.

Additionalfeaturesoftheseconceptsareasfollows:

• The responsibility for data entities and attributes is assigned to particular and unique functions within the SSDS. This method of segmentation allows a

clearseparationofthecontributionsfromeachSSDSelementandfunction.Systeminformationhasadis-tinctsource,directlyrelatedtoaspecificportionofsoftwareandtraceabletospecificmessageoutputtothedatadistributionarchitecture.

• System messages containing the entities and attri-butes are defined and broadcast.Messagesaremoreorientedtoattributeassignmentthantototalentitydescription.Thesumofsystemmessagesconstitutesthe total of the system information, which all theSSDS functions use as needed and contribute asassigned.

• Messages are filtered upon receipt.Uponinitializa-tion,eachprincipalfunctionwithintheSSDSregis-tersitsmessageneedswithdatadistributioncommu-nicationspackages(“infrastructure”software).Usingbroadcast and multicast techniques, the communi-cations packages transfer all function message out-putstoallotherrequireddestinationsandfilterinputmessagestoacceptonlythosedesired.

• Each function uses system data and records the data as needed locally. There is no central data manager.Eachfunctionoutputsitscontributiontothesystemintheformof(nominally)broadcastmessages.Dataare nominally sent only upon change. Aside frommeans to initialize functions that gain access to thedistributed system after steady-state operations areachievedandforsystemreconfigurationaftercasualty,datatransferistobeminimizedtooperationalneed.Datatransferisusedasmuchforchangenotificationasforstimulationofotherfunctions.

• Functions do not use the system messages as a coordination device.Thisincursfunctionalcoupling,whichistobeavoidedinfunctionaldesign.

• Most data transfers are expected to be broadcast “send and forget.”Thisminimizesoverheadinmes-

Figure 5. The SSDS functional examples shown are assigned entity and attribute responsibilities; their visible and physical mechanism of message generation and receipt allows simple, manageable function (process or processor) distribution. Processes may be as elaborate as necessary, but also may be totally independent of all other processes.

sage acknowledgment and log-ical dependence. Special casesmayrequireacknowledgmentforsafetyorcriticalevents,buttheseare expected to be relativelyinfrequentwithinthetotaldatadistributionenvironment.

SSDSfunctionsattachedtothedistributedarchitecture impact thesystem only through their messagecontributiontoentityandattributedefinition. Processing techniques,languages,anddatastructureswithina function are independent of theremainder of the SSDS. Responseto message receipt is totally theresponsibilityofthereceivingfunc-tion.Messagesmaybeusedtoupdatea function’s copy of track data

Messages ofinterest

Messages ofinterest

Messages ofinterest

Message stream: sensor tracks, system tracks, track positions, track ID,track engage order, etc.

Track identificationmessage

Track engageorder message

Track module Identification module Tactical actionmodule

System track existence messageTrack position, velocity message

Track emitter message



(organizedoptimallylocallyforthefunction’sneeds)ormaybeusedastriggersforfunctionalresponse.

TheflexibilityoftheconceptallowsSSDSprocessesto be totally distributed within the system as long asan underlying communication system is available. Toaccommodatesurvivabilityrequirements,duplicatepro-cesses are provided within separate enclosures to pro-duce a passive monitor of data flow and to providebackupintheeventofcasualtytoactiveprocesses.

Distributed Sensor Integration ConceptAnotherprincipalelementoftheSSDSconceptual

designisthepartitioningoftacticalfunctionsthatcol-lectively form and maintain the system’s surveillancetrackinformation.Theconceptrecognizesthecontinu-ity and accuracy benefit of frequent and complemen-tarysensordetections;theabilityofindividualsensorsto optimize their individual performance; the benefitof central track organization and flexible data access;the importanceofa priori information;and thepowerofprocessingdistribution. In theSSDS IODconcept,individualsensorstakewhatinformationtheyneedanddo their best to contribute their piece (Fig. 6). TheSSDSprovidescentralmanagement,feedback,andfalsesystemtrackcontrol.

Robust Common Time and Time-Tagged Data ConceptsThe use of time is critical to the architecture and

technicalprocessingperformanceofadistributedsystem.Althoughcomputersareveryfast,therelianceonper-forming a process quickly so that the results have anepochof“now”isveryrisky,subjecttodatainaccura-cies,andintolerantoftherandomnessofprocessorload-ingandexternalevents.Tomaintainaccuracyindatacalculations, the data must be time-tagged when it ismeasuredorcreated.This“validtime”thenmaintainstheepochintegrityofthemeasurement,whichallowslaterprocessingwithnolossincalculationaccuracy.

Anotherelementoftimeanddataislatency,whichmay be thought of as the delay from data measure-menttothesubsequentprocessingof thedata. In itsmost general terms, latency is the time between anytwoeventsofinterest.Itiscriticalinparticularsitua-tionssuchasthreatdetectionaswellasinresponseandtracking loops. Latency within 10% of measurementperiods is generally necessary for reasonable trackingmaintenance.

A robust common time is a particular requirementof the SSDS. In the interest of system independenceandtheavoidanceofsinglepointsoffailure,theSSDSestablishes a time base within its own collection ofdistributedprocessors, initialized andmaintainedoverthenetworkconnections. Inkeepingwiththis systemindependence,thefirstprocessingnodetobepowereddistributesitsinternalclockforallsuccessorstoreceive

andacceptasthetimebase.(Eachnodelistensbrieflybeforeitassumesitisthefirst.)Afteranodereceivestheinitialclockvalue,subsequenttuningofthenetworkedtimeismaintainedthroughthefunctionsofNTP(Net-workTimeProtocol)implementedintheinfrastructuresoftware.Inthismanner,thereisnorequirementontheorderofstart-upofSSDScomponents.

Another important function and element of theSSDSdistributedsystemconceptisitsfeatureofbroad-castingsystemtrackinformationinaminimumperiod.Normallythefrequencyofsensorupdatescausessystemtrackinformationtobebroadcastwithintheminimumperiod(about5s),butabackgroundprocessensurestheminimumforalltrackswithinthesystem.ThisfeatureallowseachfunctionwithintheSSDStostartupatanytimeandabsorbthetrackpicturewithinafewseconds.

Figure 6. Conceptually, the SSDS provides each sensor with current system track information. If the sensor can associate a sensor observation with the track, it provides the system with the measurement data, forming an Associated Measurement Report (AMR). A central SSDS function uses this measurement to cal-culate an updated estimate of system track position and velocity and broadcasts this updated attribute information throughout the system. Special functions, such as custom filters, may selectively use measured data in the AMRs for particular needs.

New localtracks, AMRs

Systemtrack state,new system

tracks



tracks



tracks



tracks

Customfilter(s)

Compositetrack

management

Centraltrack

update

AMRs

New localtracks

New systemtracks

AMRs

Systemtrack state


L. S. NORCUTT

Tomaintaintherobustnatureofthefunctionalandphysicalarchitectureandtoaccommodateindependentstart-upofprocessors,eachapplicationprocessorispro-videdwithcommoncodetoreceivesystemtrackdatamessagesoverthenetworkandpopulate itsownlocaldatabase.Thiscodecanbetailoredtoretainonlytheinformationofinteresttothelocaluser.Animportantfeatureof thiscommoncode is its logic to“age”eachtrackanddeleteit fromtheuser’s localdatabaseifnoupdateshavebeenreceivedwithinareasonableperiodoftime(longerthanthenominalsystemupdateperiod).This process, when coupled with the nominal systemtrack broadcast feature, ensures that the user’s localinformation is consistent with the remainder of thecombatsystem.

TheSSDSdatabroadcastfeaturealsocomplementstheSSDSconceptofdistributed,independentoperatordisplaysupport.ThisconceptusesCDK(CommonDis-play Kernel) software within each console to renderthe majority of operator displays. By operating totallyfrombroadcast systemmessages, multiple displays canbeadded to thecombat systemwithvirtuallynonet-workload.Uniquedisplaysandcontrolsareappendedto the CDK software as specific application code tosupportparticularuserneeds,withportions replicatedindifferentconsolesasequipmentcasualtybackup.A

successivevariantoftheconcept,incorporatedinSSDSMk2, retainsacommondisplaycore ineachdisplay,efficiently supplied from the network broadcast. Thelow-demand,tailoredoperatorcontrolsanddisplaysareimplementedinCORBAandaserveroverthenetwork.This hybrid display implementation provides consoleandoperatormodeindependencewhilematchingeffi-cientprocessinganddataloadswithflexibilityofsoft-waredesignandimplementation.

Physical ArchitectureCDS history, derived and implicit requirements,

NATO AAW studies, the rapidly emerging COTScomputerandnetworkingenvironment,andIODsoft-warearchitectureconceptsallcontributedtothedesignoftheSSDSphysicalarchitecture.Beingtheship’sonlycombat system and having a critical self-defense role,theSSDSmustbedependable,robust,andabletosur-viveatleastlimitedbattledamage.Itsprocessorshavetohandlefulltrackandsensordataloadingandmustbeabletoadapt.

The SSDS physical architecture, shown in Fig. 7,consistsofa localareanetwork(LAN)connectionofclusteredVME-basedsingle-boardcomputersandinter-facecardsthatformLANaccessunits(LAUs)forthevariousfunctionalelementsoftheSSDS.

Figure 7. The LSD 41/49 combat system consists of sensor systems, SSDS components, and weapon systems, all connected to the fiber-optic LAN via similar LAUs.

AN/SPS-67radar

AN/SPS-49Aradar

AN/SLQ-32ESM IFF

SensorSupervisor

Console

TAOWeapon

RAMsystem (2)

PhalanxClose-In Weapon

System (2)

ECM

(IFFantennas)



LAUs typically contain single-boardcomputers andinterfacecardstoprovidetacticalprocessingandtocom-municate with specific shipboard systems such as sen-sors,weapons,datalinks,andoperatordisplays.BecauseofthebroadcastnatureofSSDSsystemdata,computerprogramsthatdonotserviceaparticularphysicalexter-nal interfacemayexecute in anyprocessor, anyLAU.Those functions that handle interfaces and integratewithparticularexternalsystemsareplacedinthesameLAUandVMEbackplaneasthecorrespondingphysicalinterfaceboards.Figure8illustratesagenericLAUcon-figuration,whichcontains aLAN interface,numerousgeneral-purposesingle-boardapplicationcomputers,andan external interface. LAUs, connected via the LAN,may be placed anywhere on the ship. SSDS messageinfrastructure softwareoperateswithintheLANinter-faceandwithineachgeneral-purposeapplicationcom-puter to provide message distribution, board start-up,andcommontimesynchronization.

SSDS single-board computers are general-purpose,COTS,andnon-proprietarytocapitalizeoncost,avail-ability,languagesupportability,growth,andsimplicityofsoftwareprogrammingconstructs.Multipleindividualpro-cessorsalloweachprincipaltacticalfunctiontohaveitsowncomputer,withtheintenttooperateatminimalCPUloading.This simplifieddistributedprocessing environ-mentisaparticularlyeffectivemeansofavoidingresourcecontention problems among multiple programs sharingthesameCPU,addingfunctionality,andallowingmorepredictablesoftwareprocessingperformance.Italsomoreeasily accommodates the processing of data bursts thataretypicalofthetacticaldataflowenvironment.

Figure 8. The LAU concept provides both physical independence as well as functional and physical adaptation to particular interface and integration needs. While operating within the overall SSDS integration and broadcast information-oriented architecture, LAU components can support processors, languages, functions, and physical interfaces that are unique to a particular interface. This prototype LAU consists of a commercial VME card cage popu-lated with LAN interfaces, device interfaces, application single-board computers, and tape drives.

Requirementsforsystemsurvivability,easeofgrowth,andflexibility led to thenetworkingofSSDScompo-nents.Networkarchitectures,supportedbydatabroad-castcapabilities,alsoformedaphysicalcomplementtotheIODconceptsofconcurrentprocessinganduniver-salaccess/contributiontosystemdata.Furthersupportedbygeneral software infrastructure that facilitatedmes-sagedistribution,theSSDSarchitectureacquiredboththephysicalandfunctionalopen-accessnatureintendedfortheIOD.ThephysicaldistributionofSSDScompo-nents,combinedwithredundanciesofthechosennet-work,alsoprovidedadegreeofsystemsurvivabilityintheeventofbattledamage.

Commonnetworkmiddle-layerprotocolsoftheIP(InternetProtocol)familyprovedmorethanadequatefor efficient data transfer and were universally avail-able for software development. The ease, efficiency,and independence of the UDP (User Datagram Pro-tocol)broadcastandmulticastprotocolswereusedtoconveythebulkofSSDSnetworkdata,suchassensortrack updates. In a few critical cases, data transferacknowledgment was implemented to help ensuredatareceipt.Ingeneral,minimalnetworkloadingwasdesiredtoensurethereliabilityandaccessibilityofnet-workcommunications.

Despite thedesire touse aminimal amountof thenetworkdatabandwidth, it is interesting tonote thattheEthernetCSMA/CD(carrier-sense,multipleaccess/collisiondetect)physicallayerprotocolwasnotthoughtatthetimetobepredictableenoughforuseastheSSDSnetworkbackbone.Thecombinationofnumerous,fre-quent contributors of data (e.g., the numerous dis-tributed processors and the characteristics of tacticaldatawithinthecombatsystem)andtherandom,pro-gressively longer back-off and retry characteristic ofEthernet could disastrously delay critical SSDS datatransfers.Foritsautomaticreroutingfeatures,morepre-dictablephysicallayertoken“ring”protocol,100-Mbitperformance, and commercial software support, theFDDI(Fiber-DistributedDataInterface)waschosenasthe physical network. The glass fiber for data transferwas selected for its performance, low weight (Fig. 9),andlowelectromagneticsusceptibility.

TheSSDSnetworkusesadualhomestar topologyincorporatingnetworkhubsthatarepositionedindif-ferentregionsoftheship.Networkstartopology,illus-trated in Fig. 10, uses a hub to connect to eachnetwork node. This provides ease of troubleshooting,simplified COTS growth, and ease of reconfiguration.InthecaseofFDDI,thehubavoidedtheproblemsofopticalbypassrelayswhenreconfiguringaroundbreaksorinactivenodesintheFDDItokenringarchitecture.(Conversionofthenetworktoanothertechnologysuchas ATM or high-bandwidth Ethernet would use thesametopologybutdifferenthubequipmentand inter-face cards at the network nodes.) Dual hubs provide


L. S. NORCUTT

Figure 9. The 144 copper cables for CDS parallel channels on the left are compared with a single fiber-optic cable containing 144 individual glass fibers. The change in physical media, resulting in a potential cable plant weight reduction from 35.3 to 0.05 lb/ft, was only part of the technology challenge. To exploit fiber optics, an evolution in equipment interfaces was also required.

Hub

Hub

LANaccess

LANaccess

LANaccess

LANaccess

LANaccess

LANaccess

Figure 10. SSDS use of a double star topology provides significant network reliability and battle damage survivability by automatically reconfiguring data flow in the event of damage to any node interconnection or to the alternate hub.

battle damage resistance and automatic communications redundancy forsystemreliability.

Common Infrastructure ConceptCommon infrastructure software (middleware)developedbyAPLpro-

vided message distribution, time synchronization, and processor start-upcoordination services, inaddition toofferingcommonAPI(ApplicationsProgrammer Interface) functions that facilitated development of tacticalcode within the multiple processors. This software, like the concepts ofsensor integration,evolved inperformanceandmaturityovermanyyearsofuseintheNATOAAWexperiments,CooperativeEngagementCapabil-ity(CEC)development,andSSDSdevelopment.SynergismwasachievedbycombiningthenetworkconceptsoftheSSDSwiththeVMEbackplane

messagedistributionfeaturesoftheCEC(Fig.11).

COTS Refresh ConceptRecognizing the rapidly chang-

ing(andthegenerallyperformance-improving) nature of commercialproducts, SSDS design and imple-mentation focus on the use of themost common commercial hard-ware, software, and network stan-dards;theavoidanceofproprietaryproducts; and the adaptability ofitsinterfaces.AlthoughearlySSDSdevelopmentfollowedthestandardDoD language of Ada, the subse-quent COTS commonality of theC and C++ languages and theirfamiliarity to software developershave since led to their use in theSSDS. The CORBA language isalsoemployedinlightlyloadeddis-playinterfacesoftwareowingtoitsflexibilityandproductivity.

TheSSDSLANdesign,throughits fiber star topology and its reli-ance on the common IP middle-layerprotocols,allowsflexibilityinthechoiceoftheunderlyingphysi-calimplementation.BecauseSSDStacticalsoftwareusestheTransmis-sionControlProtocol(TCP)/IPandUDPcommunicationsoftwarecom-monly provided by network inter-facevendors,minimalchangesarerequired toaccommodatedifferentphysicalnetworkimplementations.

Becausethecommercialmarketnormally provides upgraded com-monlanguage(suchasC)compil-ers to complement upgraded pro-cessorboards,theimpactofrefreshon SSDS tactical code in suchevents is typicallyminimal.Sinceitsinception,theSSDShasexpe-rienced COTS refresh twice, pro-ceeding from Motorola M68020processorstotheM68040,andnowthePowerPC.

COTSrefreshhasminimaleffecton SSDS software and no effecton the conceptual architecture.Theflexibility of thenetwork andLAUstructureallowsadaptationtohandleexceptionstoprocessorsandlanguagesineachnodeifrequired.



Functional ArchitectureInclassicNavycombatsystemterms,theSSDSper-

formsthefunctionsofdetect,control,andengage.IntrueIOD context, these may be shown as any combinationof functional bubbles in a “flat” representation (Fig. 4)andcouldbeimplementedatvariousplacesthroughoutthenetwork.Afunctionalflowrepresentation,shownin

NATO AAWSystem

governmentprogram of work

experiments

LAN/softwareconceptdemo.

SSDSat-seademo.

SSDSproduction;

engineering andmanufacturingdevelopment

SSDSdevelopment

and operationaltests

SSDSMk 2

Mod 0, 1, 2

CooperativeEngagementProcessor,

backplane busdevelopment

CECdemo.

90

VXworks

CEC demo.

94

Enhancedpower PCbus control

CEC 2.0/2.1

1988 1990 1992 1994 1996 1998 2000

LAN software concepts

LAN/buscommonality

LAN/buscombination

SSDS Mk 1production (12 ships)

CommonGenealogyArchitectureInterface 3.0

Backplane messaging concepts

SSDS

CEC

Figure 11. Common infrastructure software synergistically evolved over multiple programs, benefiting performance and development productivity.

Figure 12. SSDS software functional architecture (sensor focus example). SSDS functions that collectively provide the detect, control, and engage combat system functionality are dispersed throughout the network, providing ease of extension, adaptation, and growth.

theIODcontext,isillustratedinFig.12.Thisorientsthefunctionsinaleft-to-rightmanner,illustratingthedetect-to-engage sequence of operations that may occur. Tap-pingontothestreamof systeminformation,andshownabovethenetworkflow,arethedisplayfunctionsoftheSSDSMk1SensorSupervisor,WeaponsSupervisor,and

Tactical ActionOfficer

WeaponsSupervisor

SensorSupervisor

System information and time message stream

Alignment

Identification

Sensorintegrationand control

Weaponsintegrationand control

Weaponsdirection

and control

Localcommandand control

Sensorcoordinatonand control

Track/management

update

Sensor,identificationcontrols

Weapon,local commandand control

Sensortracks

Padalign-ment

Com-positetracks

Conflictidentification,systemidentification

Sensorcues, trackconfidence

Engageorders

Weaponschedule,orders

Weaponsstatus,engagestatus

SensorsWeapons


L. S. NORCUTT

Tactical Action Officer. The display functions absorbwhatever information isneeded fordisplay andprovideoperatoractionsbacktothenetworktobeinterpretedbytheinterestedfunctions.

SSDS DEVELOPMENT HISTORY

Prototype Demonstration PhaseThe SSDS began as a proof-of-concept demonstra-

tion for the Quick Response Combat Capability Pro-gram in 1991. Incorporating some APL software reusefromtheNavyAuto-IDandCECprogramsandexperi-mental network IOD demonstration software from theNATO AAW effort, the new SSDS distributed archi-tecture was formed. Under Navy direction, APL pro-videdleadsystemarchitecturedesignanddevelopedthesensor integration,displays,andinfrastructuresoftware.ComplementingtheteamweretheNavalSurfaceWar-fareCenterandHughesAircraft(nowRaytheon),whodevelopedweaponsschedulingandcontrolandweaponinterface software, respectively. This trio of softwaredevelopers,buildingcodeatthreeindependentsites,pro-videdanearly“ility”testoftheSSDSarchitectureandintegrationconceptsthatprovedquitesuccessfulthroughcarefulmanagementofsystemmessagedefinition.

In June 1993, following land-based testing andshipboard installation and integration aboard USSWhidbey Island (LSD 41), SSDS—automatically inte-gratingsevenshipboardsensorsandthreeweaponsys-tems—performedasuccessful,near-simultaneous, fullyautomatic and coordinated detect-to-fire live engage-mentoftwotarget“threats”(atoweddecoyunitandaremotelypilotedjetdrone)usingtheRollingAirframeMissileandPhalanxgunsystem.

Production PhaseAfterthesuccessfuldemonstrationefforts,theSSDS

Mk1softwareandCOTScomponentswereruggedizedfor shipboard operational use by Hughes Aircraft.

Production-qualityLAUequipmentandmultipleLAUenclosuresweredevelopedtohousetheCOTSproces-sors,andadditionalintegrationsoftwarewasdevelopedby theLaboratory to incorporate theAN/SPS-67 sur-face search radar and the AN/UPX-36 Identification,FriendorFoe(IFF)sensors.ThefirstproductionSSDSMk 1 was developed for USS Ashland (LSD 48), onwhichthesystempassedformalNavyoperationaltest-ing and evaluation in the summer of 1997 in its firstattempt.

The low cost and short schedule of SSDS Mk 1developmentearnedittheU.S.government’sHammerAwardforefficiencyofgovernmentprocurement.

Current StatusTheSSDSMk1isnowinstalledandoperationalon

11ofthe12shipsintheLSD41/49class,withthe12thnearingcompletion.TheSSDSMk1successor,SSDSMk2,iscurrentlybeingdevelopedfortwomoreshipsandclasses,USSRonald ReaganandUSSSan Antonio,wherethesystemwillprovidefullcombatsystemfunc-tionality.IntheMk2configuration,muchofthesur-veillancesensorintegrationisprovidedbytheinstalledCEC, which incorporates the same shipboard sensorintegrationconceptastheSSDS.

SUMMARYTheSSDSarchitecturewasaninnovationandsome-

what of a risk. But the risk was well justified for thesuccessof itsdevelopmentand thecontinuedbenefitsthearchitecturehasshown.SSDSarchitectureconceptshavesucceededinadvancingboththestateoftheartandthetacticalcapabilitiesoftheU.S.Fleet.

SSDSMk1developmentandcapabilitiesareasuc-cessstory,duelargelytothecontributionsofmanytal-ented system and software engineers, the experiencebase of those people, new software design paradigms,andtheeffectiveuseofCOTSsoftwareandcomputercomponents.

THE AUTHOR

LARRYS.NORCUTTisamemberof theAPLPrincipalProfessionalStaff.HereceivedaB.S.E.E.fromMichiganStateUniversityin1969andanM.S.E.E.fromTheJohnsHopkinsUniversityin1972.HejoinedAPLin1969andhasanexten-sivebackground in the integrationandautomationofNavy surveillance systemsinthereal-timecombatsystemenvironment.Hewasaprincipaldesignandsoft-ware engineer on the development of the AN/SYS-1 and AN/SYS-2 integratedautomaticdetectionandtrackingsystems,ledthedevelopmentandintegrationofsurveillancesoftwarefortheNavy’sACDSBlock0,andwasAPLcombatsystemarchitectleadfortheNATOAAWProgram.RecenteffortshaveincludedconceptsforintegrationofpassivesensorsandimprovingNavySurfaceFleetinteroperabilityandcombatsystemtraining.Mr.NorcuttwastheleadengineerfortheSSDSMk1systemarchitecturedesign.Hise-mailaddressislarry.norcutt@jhuapl.edu.

Ship Self-Defense System Architecture - The Johns · PDF fileShip Self-Defense System...

Documents

Transcript of Ship Self-Defense System Architecture - The Johns · PDF fileShip Self-Defense System...