US NAVY 1957 - 1960: Uno degli argomenti che i detrattori avevano usato contro il Naval Tactical Data System (NTDS) era il loro convincimento circa la natura esotica delle nuove (per l’epoca) attrezzature digitali.

https://svppbellum.blogspot.com/

Si vis pacem, para bellum 

(in latino: «se vuoi la pace, prepara la guerra») è una locuzione latina.

Uno dei mezzi più efficaci per assicurare la pace consiste nell'essere armati e in grado di difendersi, possiede anche un significato più profondo che è quello che vede proprio coloro che imparano a combattere come coloro che possono comprendere meglio e apprezzare maggiormente la pace.

1960: Il sito di test terrestre della US NAVY di San Diego e il sistema che non ha mai navigato

Uno degli argomenti che i detrattori hanno usato contro il Naval Tactical Data System era la loro idea circa la natura esotica delle nuove attrezzature digitali. All’epoca si erano lamentati che sarebbe stato troppo complesso da capire e mantenere per i marinai. Il comandante Svendsen non poteva dire loro di aver visto i marinai padroneggiare prontamente i computer segreti della Marina, fino al punto di raccomandare miglioramenti ai circuiti. L'unica domanda nella mente di Svendsen era se i requisiti di conoscenza tecnica dei tecnici elettronici esistenti della US NAVY dovessero essere ampliati per comprendere le apparecchiature digitali e i loro programmi informatici di accompagnamento; oppure, se dovesse essere istituita una nuova classificazione di arruolato per mantenere operativi i dispositivi NTDS. Dopo aver discusso con gli specialisti della formazione presso il Bureau of Naval Personnel (BUPERS), Svendsen aveva raccomandato agli ufficiali del progetto OPNAV e al BUPERS di stabilire una nuova valutazione per il marinaio arruolato: la nuova classificazione fu denominata "tecnico del sistema di dati" o "DS" in breve.

Quale posto migliore per iniziare a formare il quadro iniziale dei nuovi tecnici del sistema dati se non il sito di test di ingegneria presso il Navy Electronics Lab? Ma c'era un problema. I DS sarebbero stati necessari a tutti i livelli degli arruolati, dal capo sottufficiale al marinaio e la Marina USA non poteva semplicemente rendere un capo o un sottufficiale tecnico dei sistemi di dati di prima classe in una notte. BUPERS aveva inviato avvisi a livello di flotta incoraggiando le valutazioni di alto livello ad offrirsi volontari per convertire la loro valutazione in tecnico dei sistemi di dati. Molti si offrirono volontari e BUPERS fu in grado di raccogliere di persona la crema del raccolto: avrebbero dovuto essere i migliori.

Cdr. Svendsen assegnò un compito a NEL per impostare corsi di formazione NTDS a livello di sistema per i nuovi DS; oltre a prendere accordi contrattuali per i tre appaltatori di apparecchiature NTDS per fornire corsi specializzati sulle loro particolari attrezzature. Una volta addestrati, avrebbero acquisito un apprendimento pratico aiutando a testare il sistema prototipo; in questo modo il progetto avrebbe ottenuto il beneficio della loro esperienza in marina. I volontari avrebbero facilmente imparato la tecnologia digitale e sarebbero diventati una delle ragioni principali dell'eventuale successo del Naval Tactical Data System. In tutto, circa 75 arruolati, a tutti i livelli, ricevettero incarichi per il progetto NTDS presso il Navy Electronics Laboratory e circa un numero uguale di ufficiali.

Compiti dei 77 ufficiali della flotta assegnati al progetto Naval Tactical Data System presso il Navy Electronics Laboratory - aprile 1960. 

Nell'ottobre 1956 BUSHIPS assegnò un compito problematico J1-6 al Navy Electronics Laboratory: era il compito NTDS più ampio del laboratorio e aveva il nome di "Strumentazione e valutazione NTDS di sviluppo". Aveva richiesto l'installazione del prototipo di apparecchiature NTDS dei tre appaltatori, in azienda con apparecchiature di bordo di interfacciamento, o simulatori, nel Centro di sviluppo e valutazione dei sistemi applicati del laboratorio. LCD. Alfred Bettis ricevette ordini di trasferimento dalla BUSHIPS Computer Design Section al laboratorio Navy Electronics a metà del 1957. Il suo nuovo lavoro era quello di gestire la costruzione del sito di test ingegneristico e poi supervisionare i test del sistema. Quando ebbe terminato i test tre anni dopo, si sarebbe trasferito al Cantiere navale di San Francisco per lavorare alla pianificazione dell'installazione dei sistemi di test di servizio NTDS in due navi di prova di servizio.

Nel frattempo, nell'aprile 1957, gli ingegneri e gli esperti della NEL avevano creato una suite di unità di equipaggiamento NTDS modello in scala di cartone in miniatura e costruito un centro di informazione di combattimento in miniatura per elaborare i dettagli delle posizioni delle attrezzature tenendo conto dei requisiti di spazio intorno a ogni unità per consentire l'apertura di cassetti e piani per l'accesso alla manutenzione. Quando furono soddisfatti del posizionamento delle attrezzature nel modello in scala, fecero costruire ai negozi NEL modelli in legno a grandezza naturale di tutte le unità installandoli sul piano di prova all'inizio di luglio per verificare il layout, elaborare procedure operative e per assicurarsi che gli aspetti ingegneristici umani del layout funzionassero al meglio. In questo furono assistiti dai marinai-tecnici che alla fine avrebbero gestito il vero prototipo delle attrezzature.

Sarebbe stato meglio commettere errori sulla carta piuttosto che nella gestione reale. Gli artisti NEL avevano fabbricato repliche di cartone in miniatura di tutti i tipi di apparecchiature NTDS. Questi furono utilizzati in un modello in miniatura del sito di prova ingegneristico per stabilire le posizioni delle apparecchiature. Si noti che i modelli mostrano anche archi di spazio per indicare dove i pannelli di manutenzione dovevano aprirsi senza interferenze da parte delle apparecchiature vicine.

Nel marzo 1958 Univac aveva consegnato il numero di serie 1 del computer AN/USQ-17 al sito di prova ingegneristico e due mesi dopo arrivarono i terminali di collegamento dati Collins e le radio HIGHCAPCOM. NEL aveva equipaggiato la sua nave da ricerca USS Rexburg con uno dei set di terminali dati e una radio ad alta frequenza HIGHCAPCOM corrispondente. Il Navy Electronics Lab aveva abbastanza attrezzature a portata di mano per iniziare a testare il collegamento dati tattico tra riva e mare. Invece di un computer NTDS, il sistema di bordo era dotato di una scatola logica che simulava un computer. Quando la scatola logica ha ricevuto un messaggio A-Link dal sito di test di ingegneria, ha semplicemente cambiato tutti gli uno in zeri, tutti gli zeri in uno e ha trasmesso il messaggio "immagine dello specchio" al sito di prova. Al sito di prova le parole di messaggio in uscita e di risposta a 30 bit sono state aggiunte insieme nel computer e il risultato è stato stampato. Una stampa di messaggi perfetta sarebbe tutta, e un errore di trasmissione sarebbe mostrato come uno zero - che sporgerebbe come un pollice dolorante.

I primi test NTDS A-Link dal vivo, da eseguire nella primavera del 1958, furono di grande interesse per il Comitato Tactical International Data Exchange (TIDE) composto da rappresentanti della Royal Navy, della Royal Canadian Navy e dell'U. S. Marina. La Royal Navy aveva denominato il loro sistema automatizzato di direzione del combattimento a bordo Action Data Automation (ADA). Aveva utilizzato la Ferranti per scopi generali, computer di programma memorizzati e un computer digitale per scopi speciali per il rilevamento e il tracciamento automatici dei bersagli. La Royal Canadian Navy stava lavorando a un sequel del loro Digital Automated Tracking and Resolving System (DATAR) che hanno chiamato CCS-280. I tre sistemi dovevano scambiare dati tattici tra loro, e quale momento e luogo migliore per avere una riunione del Comitato TIDE se non al Navy Electronics Lab all'inizio dei test NTDS A-Link.

Per aggiungere interesse all'incontro, il formato di trasmissione del collegamento era ancora un argomento molto controverso e indeciso tra le tre marine alleate. 

La Royal Navy preferiva un collegamento simile ad una telescrivente seriale ad alta velocità con una parola a 36 bit, che ritenevano sarebbe costato meno del collegamento USN, e con la parola più lunga poteva avere più funzionalità di rilevamento e correzione degli errori. Il problema era che, al fine di raggiungere la compatibilità operativa, o il RN avrebbe dovuto adottare l'U. S. formato link, o l'USN avrebbe usato il formato britannico. I primi test americani A-Link erano di tale interesse che l'ammiraglio della flotta, lo stesso Lord Louis Mountbatten, aveva scelto di partecipare alla riunione TIDE.

Nella primavera del 1958 Lord Louis Mountbatten, ammiraglio della flotta, e alcuni del suo staff della Royal Navy visitarono il sito di test di ingegneria del NEL per assistere al primo test dal vivo del collegamento dati tattico NTDS. Prima fila, da destra, Radm. Martin Comandante 11° Distretto Navale, Dr. Christianson NEL Direttore Tecnico, Ammiraglio Mountbatten, Cdr. H. S. Foote OPNAV. Seconda fila, da destra, Cdr. E. C. Svendsen NTDS responsabile del progetto, Cdr. USN non identificato, Cdr. P. E. Io. Bailey, RN, addetto navale Ambasciata britannica, Sig. Ian McCord Direttore tecnico Admiralty Surface Weapons Establishment, Portsmouth. U. S. Foto della marina

L'ammiraglio Mountbatten non era un principiante delle comunicazioni navali. La sua specialità nel RN era stata i "segnali" ed era esperto nell'ingegneria delle comunicazioni radio. È arrivato a NEL il giorno prima della riunione TIDE e ha chiesto di osservare i test A-Link. Si fermò alla stampante di linea e osservò le stampe - che mostravano un numero inaccettabile di errori di trasmissione. Ci si aspettava un certo numero di errori e sarebbero stati gestiti dalla funzione di rilevamento e correzione degli errori, se fosse stata attivata. Ma ci sono stati molti più errori di quanto dovrebbe esserci. Il comandante Svendsen non è stato in grado di convincere l'ammiraglio che molto probabilmente erano dovuti a un problema di equipaggiamento, che poteva essere corretto. Mountbatten era convinto che gli errori fossero dovuti a un difetto nel concetto di trasmissione parallela a 30 bit USN e che la trasmissione seriale RN a 36 bit fosse di gran lunga superiore. Non è stata una buona giornata per il progetto NTDS.

Cdr. Svendsen sapeva anche che l'ammiraglio Mountbatten avrebbe visitato il capo delle operazioni navali dell'USN, l'ammiraglio Arleigh Burke dopo l'incontro TIDE, e avrebbe sicuramente cercato di influenzare Burke nell'adozione del formato di collegamento preferito della Royal Navy. Anche il comandante Stan Foote dell'ufficio del progetto OPNAV NTDS aveva assistito ai test e Svendsen ha proposto di tornare a Washington il prima possibile per informare Burke sulla controversia in arrivo e per dirgli che Svendsen era sicuro che il problema fosse dovuto a un errore intermittente dell'attrezzatura che si aspettavano di trovare presto, e che avevano pianificato di scrivere un'analisi sotto forma di un documento di posizione che avrebbe dimostrato che l'approccio USN era tecnicamente superiore all'approccio seriale RN.

Quella notte Svendsen e Stoutenburgh procedettero a Lcdr. La casa di Bettis a Point Loma per passare oltre le stampe di prova del collegamento dati del giorno. C'era da aspettarsi che ci sarebbero stati errori di trasmissione occasionali distribuiti uniformemente tra tutti i 30 bit delle parole dei dati, ma dopo un paio d'ore di controllo, è diventato evidente che le posizioni di due bit stavano riscontrando più errori casuali rispetto alle altre posizioni dei bit. Quando gli errori extra in queste due posizioni sono stati esclusi, hanno visto che il collegamento stava andando estremamente bene. A quanto pare due dei risonatori sintonizzati nel set di terminali dati del Rexburg erano sul bordo irregolare della sintonizzazione.

Con la causa delle scarse prestazioni del collegamento bloccate. I tre hanno trascorso una sessione di tutta la notte a redigere un documento confrontando le capacità delle due tecnologie di collegamento dati concorrenti e costruendo un caso solido per l'utilizzo dell'approccio USN. Ognuno ha preso una sezione della bozza per scrivere, e mentre scrivevano la signora Bettis ha fornito loro snack e molte brocche di martini. LCD. Stoutenburgh ha notato che con il progredire della notte, la loro calligrafia è andata alla deriva verso l'incomprensibile, ma anche così, i segretari del NEL sono stati in grado di decifrare i loro scritti la mattina seguente. Il documento risultante divenne noto come Point Loma Multiple Martini Position Paper, e Stoutenburgh concluse che i martini apparentemente stimolano le cellule cerebrali creative e uccidono solo quelle non creative.

Nel frattempo, Stan Foote aveva preso un volo notturno "occhi rossi" di ritorno a Washington e all'atterraggio chiamato la casa di Bettis per apprendere che il problema era dovuto a un malfunzionamento dell'attrezzatura e pensavano di avere un caso rivestito di ferro che il sistema USN era superiore al sistema seriale della Royal Navy. Poi si diresse nell'ufficio dell'ammiraglio Burke nel pentagono. Burke gli disse che doveva salire a bordo di un aereo della Marina per New London, Connecticut, in pochi minuti, e se avesse avuto bisogno di informarlo, anche Foote avrebbe fatto meglio a salire sull'aereo. Foote gli ha parlato della situazione del collegamento dei dati e che Lord Mountbatten avrebbe sicuramente cercato di convincerlo a passare al sistema britannico. Gli aveva anche detto che il Cdr. Svendsen aveva la questione in mano e poteva dimostrare i meriti dell'approccio dell’US Navy. Aveva esortato l'ammiraglio a non arrendersi indipendentemente dalla sua esperienza nelle comunicazioni navali. Il risultato finale fu che la Royal Navy e la Canadian Navy alla fine adottarono il sistema parallelo della US Navy a 30 bit, che in seguito è diventato noto come NATO Link 11. 

Marinai di ferro e console di legno

Nell'estate del 1958 il comandante John F. Felter fu inviato a NEL per prendere in carico il contingente militare assegnato ad allenarsi e/o sostenere i test presso il sito di prova. Riferendo a Felter, il CDR Billy F. Brown si prese cura degli ufficiali e dei marinai assegnati per aiutare a valutare il nuovo sistema. Iniziarono simulando le operazioni CIC utilizzando le console di legno, e da questo lavoro contribuirono a preparare specifiche dettagliate per le apparecchiature di prova di servizio a bordo NTDS di follow-on.

2 luglio 1957. Il sito di test ingegneristico era progredito nei modelli in legno delle console. Questi furono utilizzati per verificare il posizionamento delle console effettive e per testare considerazioni di ingegneria umana e procedure operative nella progettazione di un CIC automatizzato.

Gli ingegneri della NEL avevano progettato una serie di dispositivi per simulare le apparecchiature di bordo collegate a NTDS come il giro-compasso delle navi, il verticale stabile e il registro della velocità subacqueo; e molti di questi erano guidati da computer specializzati per consentire loro di inserire input di cambiamento realistici. Il primo di questi iniziò ad arrivare dagli appaltatori e dai negozi NEL nel febbraio 1958. Erano necessari tre computer di unità AN/USQ-17 per replicare la più grande suite NTDS che sarebbe stata installata su di una portaerei, e questi tre erano in atto entro luglio 1958. La suite completa di apparecchiature per sottosistemi di visualizzazione era arrivata dalla Hughes Aircraft ed era stata installata nel marzo 1959.

L'appaltatore e gli ingegneri di NEL avevano imparato che era impossibile scrivere una specifica di interfaccia elettronica che non potesse essere interpretata diversamente da due ingegneri razionali e competenti. Ad esempio, la definizione ufficiale del progetto della parola "input" significava che i dati entravano nel computer centrale, mentre alcuni costruttori di apparecchiature periferiche avevano tradizionalmente interpretato "input" come dati che entravano nel loro dispositivo. Molte delle unità di apparecchiature prototipo stavano soddisfacendo le loro apparecchiature di interfaccia per la prima volta e le incompatibilità dell'interfaccia e l'errata interpretazione delle specifiche erano dilaganti. Era una buona cosa che questo sistema non fosse installato per la prima volta a bordo di una nave USN. Sarebbe stato molto imbarazzante per il progetto. Signor Robert P. McMannus, un ingegnere NEL, si è offerto volontario per assumere il compito di tenere traccia di tutte le incompatibilità e forzare loro soluzioni. Nell'aprile 1959 li aveva risolti e il sistema era pronto per i test formali.

Le combinazioni di pausa caffè

L'organizzazione della Marina che testava nuove attrezzature e sistemi in mare per l'idoneità operativa è chiamata Operational Test and Evaluation Force (OPTEVFOR). Nel caso di NTDS, anche se non era loro responsabilità farlo, OPTEVFOR aveva organizzato l'invio di un gruppo di ufficiali e uomini a NEL per assistere nei test al fine di avere un'idea di come dovrebbero testare il primo sistema digitale della US NAVY in mare e per cercare di avere una prima sensazione se il sistema avrebbe davvero funzionato come previsto. Avrebbero lavorato come operatori insieme al personale della marina assegnato al progetto.

Il laboratorio e gli ingegneri dell'appaltatore avevano portato i sottosistemi in linea una sotto-unità alla volta fino a quando un sottosistema completo non ha funzionato con i computer. All'inizio esercitavano ogni sotto-unità con programmi per computer "senza senso" che esercitavano ogni caratteristica dell'unità una alla volta, tenevano traccia di ogni risposta e stampavano le risposte mancanti sul teletipo. I programmi senza senso erano stati trovati così utili che furono successivamente perfezionati come programmi di test di manutenzione chiamati "Apparizioni funzionali operative programmate" o (POFAS). Quando l'attrezzatura di ciascun sottosistema: elaborazione dei dati, visualizzazione e comunicazione dei dati, era stata controllata separatamente con i computer, avevano portato l'elaborazione dei dati e i sottosistemi di visualizzazione contemporaneamente e elaborando più bug del programma. Alla fine avevano tutti e tre i sottosistemi che operavano insieme con uno speciale programma di test, ed era ora di testare il sistema con i programmi informatici operativi tattici. Prima il programma a due computer per le fregate lancia missili guidati, e poi la versione incrociatore d'attacco munita di tre computer.

Oltre alle apparecchiature specializzate di registrazione dei dati ideate da NEL, i programmi informatici tattici erano stati modificati per estrarre e registrare i dati operativi mentre il sistema era in funzione. Questi dati sarebbero molto utili nel tentativo di risolvere le cause degli arresti anomali del sistema, e c'erano molte. I tester hanno iniziato eseguendo ogni funzione tattica come il tracciamento della superficie, la navigazione superficiale, il monitoraggio dell'aria, la valutazione delle minacce, l'assegnazione delle armi e il controllo dell'intercettore, una funzione alla volta. Si sono verificati molti arresti anomali del programma e i programmatori li hanno risolti uno per uno. Poi hanno iniziato a eseguire funzioni tattiche in parallelo.

I crash erano continuati, o a volte il sistema non si era bloccato, o era semplicemente uscito di mano come se il programma per computer avesse preso il sopravvento sugli operatori. Altre volte avevano scoperto che il programma per computer si confondeva. Se un operatore premeva due pulsanti di azione rapida su di una console allo stesso tempo, o alcune volte una particolare combinazione o sequenza di pulsanti premuti avrebbe provocato un arresto anomalo. I marinai denominarono queste "combinazioni di pausa caffè" perché avrebbero avuto il tempo per una pausa caffè mentre i programmatori rimuginavano sulle stampe dei dati per trovare e correggere il problema del programma. O a volte trovavano un difetto nell'attrezzatura, con grande incredulità e infelicità degli appaltatori delle attrezzature.

Prototipo NTDS testato nel marzo 1960. 

Il conduttore di prova in primo piano era dotato di un sistema di interfono in modo da poter parlare con i singoli operatori e ascoltare le loro conversazioni. Le unità piccole e sottili accanto alle console utente erano indicatori di lettura ausiliari che mostravano informazioni dettagliate sugli obiettivi selezionati. Lo schermo quadrato sul retro era chiamato schermo SKIATRON. Su di esso un marinaio poteva tracciare le coordinate del bersaglio proiettate, un bersaglio alla volta, dal proiettore SKIATRON: la scatola nera sul pavimento davanti allo schermo. Uno dei computer dell'unità dirigeva la proiezione del raggio sul bersaglio. Fu un primo tentativo di un display a grande schermo, ma non riuscì a concludere il test di servizio.

Vennero trovati una serie di difetti delle apparecchiature, alcuni dei quali potevano essere "aggirati" dai programmatori, ma che dovevano essere affrontati nella successiva generazione di apparecchiature che sarebbero state installate a bordo delle navi per "test di servizio" in mare. I tester rilevarono molti cambiamenti e modifiche desiderabili che l'ufficio del progetto avrebbe poi lavorato nei contratti delle apparecchiature di prova di servizio. Il problema era che i test del sistema ingegneristico dovevano essere completati nell'autunno del 1961, mentre al fine di avere attrezzature di prova di servizio pronte per i test di servizio per soddisfare l'ambizioso programma quinquennale, il nuovo contratto di attrezzature a Collins Radio doveva essere locato entro maggio 1959 e alla fine del 1959 per le apparecchiature Univac e Hughes.

Il dilemma di cui sopra significava che i cambiamenti delle attrezzature dovevano essere determinati, concordati e scritti nei contratti in tempo reale. Inoltre, gli appaltatori delle attrezzature inseguirebbero un bersaglio in movimento durante la fase di progettazione. Per mantenere breve il processo decisionale, i responsabili del progetto e gli ingegneri della divisione di progettazione BUSHIPS avevano dovuto trascorrere molto tempo presso il sito di prova rivedendo le modifiche proposte e prendendo decisioni immediate. 

Questo è uno dei motivi per cui un progetto "normale" ha impiegato quattordici anni dall'approvazione all'attrezzatura pronta per il test di assistenza.

Anche quando il sito di prova ingegneristica era dotato solo di console in legno, il sito veniva utilizzato di notte per iniziare la formazione sulle procedure operative per i futuri operatori NTDS delle navi di prova di servizio. Più tardi, quando l'attrezzatura di prova ingegneristica era stata installata, il team di test valutavao il sistema durante il giorno mentre i marinai utilizzavano l'attrezzatura di notte per apprendere le operazioni e la manutenzione. In seguito, la scuola di un operatore NTDS sarebbe stata istituita presso la Combat Information Center School presso il Fleet Anti-Air Warfare Training Center proprio di fronte a Catalina Boulevard da NEL, e una Data Systems Technicians School sarebbe stata istituita presso l'U. S. Comando delle scuole navali, Vallejo, California.

Il piano di sviluppo NTDS prevedeva anche la creazione di un Fleet Computer Programming Center (FCPC) in un nuovo edificio presso il Fleet Anti-Air Warfare Training Center. Il nuovo FCPC avrebbe dovuto assumere i programmi informatici operativi delle navi di prova di servizio per modificarli e mantenerli, e avere nuovi programmi pronti per le navi NTDS della "prima produzione" che avrebbero avuto bisogno dei loro programmi per computer entro l'inizio del 1963. C'era un duplice problema, nel peggiore dei casi, NTDS potrebbe non essere mai "approvato dal servizio" e, nel migliore dei casi, l'approvazione del servizio non poteva avvenire fino alla metà del 1962. L'attesa dell'approvazione del servizio prima di iniziare la costruzione del nuovo edificio non ha permesso di avere abbastanza tempo per finire la costruzione e quindi avere i programmi informatici di produzione pronti. OPNAV ha dovuto correre un altro rischio calcolato per iniziare la costruzione a metà del 1959.

In concomitanza con la costruzione, OPNAV aveva chiesto che il Navy Electronics Lab istituisse una scuola di programmatori informatici NTDS per avere uno staff di programmatori di computer militari pronti ad astre il nuovo Centro. Con l'aiuto del contratto Univac, Cdr. Roberto E. Sink, dello staff di CDR Felter aveva la scuola aperta e funzionante entro dicembre 1959, e la prima classe di programmatori si laureò all'inizio del 1960. Questa prima classe di circa 20 ufficiali e piccoli ufficiali capo venne assegnata al gruppo di programmazione Univac che lavorava al completamento del sistema di test ingegneristico e dei programmi di prova di servizio. Avevano aiutato materialmente i programmatori Univac lavorando sulle realtà militari nei programmi per computer.

Troppi tipi di console

Il sistema di test ingegneristico aveva sette diversi tipi di console di visualizzazione, tra cui una console specializzata in altezza/gamma per l'uso con radar di ricerca dell'altezza, una console specializzata per l'analisi delle dimensioni del raid e cinque tipi di console convenzionali per indicatori di posizione del piano (PPI). Inoltre gli specialisti dei test militari avevano sviluppato argomenti convincenti per avere ancora più tipi di console. Allo stesso tempo i tester di ingegneria avevano fatto raccomandazioni per molti cambiamenti tecnici. Uno dei problemi più difficili con le console di prova ingegneristiche erano le forme irregolari dei cerchi, delle linee e dei simboli della gamma e la loro mancanza di precisione nel posizionamento sulle facce dei cannocchiali radar. Ciò era dovuto principalmente ai circuiti transistorizzati analogici che creavano e collocavano la simbologia.

Gli ingegneri Hughes avevano detto a Lcdr. Stoutenburgh che i circuiti digitali al posto dei circuiti analogici avrebbero potuto probabilmente migliorare notevolmente l'aspetto e la precisione della simbologia, ma sarebbe stato tecnicamente difficile e avrebbe reso le console molto più costose. Stoutenburgh sentiva che il miglioramento digitale era essenziale, ma gli fu anche detto che i display migliorati sarebbero costati più di 100.000 dollari cadauno. Ciò avrebbe fatto sì che il sottosistema di visualizzazione costi di più rispetto ai sottosistemi di elaborazione dei dati e comunicazione insieme. C'era preoccupazione in OPNAV che il Congresso potesse rifiutarsi di dare loro un tale aumento.

Gli ingegneri Hughes avevano anche detto a Stoutenburgh di ridurre il numero di tipi di console di visualizzazione per diminuire il costo totale beneficiando di una produzione più ampia di ciascun tipo di console. 

Si decise di ridurre i tipi a tre: una console combinata di altezza/gamma e analisi delle dimensioni del raid, una console di input dati universale e una console utente universale. Le console avrebbero detto al computer quale funzione CIC stavano eseguendo tramite un'impostazione dell'interruttore di selezione.

Stoutenburgh ottenne il permesso del comandante Svendsen di trascorrere fino a due mesi nel sito di test di ingegneria NEL. Il suo obiettivo era imparare ogni funzione eseguita dai sette tipi di console e poi trovare un modo per eseguire quelle stesse funzioni con solo tre tipi. Partecipò ai test giornalieri e preso volumi di appunti. La sera aveva passato in riesame le stampe di prova del giorno e aveva letto i manuali tecnici delle attrezzature. Aveva anche organizzato incontri con gli specialisti operativi militari, come i controllori di intercettazione aerea, i supervisori di tracciamento e i controllori di ingaggio dei missili, e con gli ingegneri di visualizzazione Hughes.

Dalla sua raccolta di informazioni, Stoutenburgh aveva creato una tabella dettagliata per ciascuno dei sette tipi di console di ogni funzione di visualizzazione, azione del pulsante e impostazione di controllo, e quale risultato operativo ci si aspettava che ciascuno avrebbe portato, nonché la risposta del computer prevista per ciascuno. Poi ha scritto una specifica funzionale dettagliata per ciascuno dei suoi tre tipi di console che avrebbe soddisfatto ogni requisito. Poi aveva inseguito prima quello facile e la sua nuova console di analisi altezza/gamma/dimensioni.

Stoutenburgh aveva chiesto all'ingegnere espositivo di BUSHIPS Fred Russell e all'ingegnere McCown di progettare una singola console per ospitare le tre funzioni di cui sopra. Non fu troppo difficile per loro progettare una singola console che potesse funzionare con un radar di rilevamento dell'altezza per visualizzare l'altezza e la portata del bersaglio, o con qualsiasi radar per fare un'analisi delle dimensioni del raid. Il suo prossimo compito fu quello di ridurre i cinque tipi di console dell'indicatore di posizione del piano (PPI) in un input e un tipo di console utente. La sua console di input concettuale era in grado di comunicare al computer che doveva essere trattato come: un rilevatore, un tracker, un input di contromisure elettroniche o una console di identificazione; mentre la console utente era commutabile in controllo delle armi, controllo dell'intercettazione aerea, controllo del traffico aereo, valutazione delle minacce o funzioni di comando.

Poi giunsero gli incontri con gli specialisti tecnici. Stoutenburgh aveva sfidato ogni gruppo di specialisti a dirgli perché non potevano svolgere le loro funzioni con i due tipi di console PPI. All'inizio ci fu resistenza, ma con le sue settimane di analisi per sostenerlo, fu in grado di girare ogni argomento. Aveva anche detto loro che se il costo del sistema di visualizzazione non poteva essere abbassato, avrebbe potuto non esserci mai un sistema NTDS. Alla fine trovarono modi per eseguire tutte le funzioni richieste con i due tipi di console e tutti accettarono solo due tipi di PPI. 

Addio all’AN/USQ-17

A metà del 1959, i valutatori del sito di test del Navy Electronics Lab stavano scoprendo che le prestazioni del computer dell'unità USQ-17 erano appena adeguate per supportare i prossimi sistemi di bordo. Scoprirono che i computer avevano bisogno di più canali di comunicazione a 30 bit, lo schema di comunicazione inter-computer aveva funzionato, ma poteva essere reso molto migliore. Inoltre, i Q-17 furono trovati difficili da manutenere e l'affidabilità era marginale. R. J. Malone di Univac aveva rilevato lo sviluppo di computer dell'unità all'inizio del 1959 e a metà ottobre 1959 stava raccomandando a Cdr. Svendsen che un computer molto migliorato poteva essere costruito utilizzando transistor planari appena disponibili piuttosto che i transistor a barriera superficiale USQ-17. Anche Don Ream, l'ingegnere del progetto informatico dell'unità BUSHIPS, condivideva la raccomandazione di Malone. Il problema era che i transistor a barriera superficiale non potevano essere semplicemente sostituiti uno per uno da transistor planari. Sarebbe necessario un design totalmente nuovo.

Il programma del progetto prevedeva la consegna di computer di prova di servizio ai cantieri navali nel dicembre 1960, il che significava che il prototipo di un nuovo computer avrebbe dovuto essere pronto per i test a metà agosto 1960. Ciò avrebbe consentito appena abbastanza tempo per apportare correzioni e modifiche finali e produrre una piccola produzione di computer di prova di servizio. Estendere il programma del progetto NTDS era fuori questione; Svendsen sapeva che i molti critici del progetto avrebbero cercato di usare il ritardo come munizioni per screditare il progetto e ucciderlo, se possibile. Un prototipo di computer unitario di nuova concezione dovrebbe essere pronto per il test in meno di undici mesi a partire da metà ottobre 1959.

Le uniche caratteristiche dell'AN/USQ-17 che sarebbero state riportate sul nuovo computer sarebbero l'architettura del set di istruzioni (in modo che il nuovo computer possa eseguire i programmi scritti per l'USQ-17) e la specifica dell'interfaccia di input/output (in modo che i sottosistemi di interfacciamento e le apparecchiature periferiche non dovessero essere ridisegnati). Svendsen aveva posto la domanda a Univac. Potevano progettare e costruire un computer totalmente nuovo entro questi vincoli di tempo immobili? La risposta di Univac era che se Svendsen li avesse autorizzati in due mesi ad elaborare un progetto preliminare, avrebbero saputo abbastanza per assicurargli se avrebbero potuto avere un nuovo prototipo pronto nei restanti 9 mesi e mezzo.

In quel momento, Univac stava producendo il computer di guida a terra ATHENA dell'Aeronautica Militare per il missile balistico TITAN I. 

Anche Athena era transistorizzato e, sebbene avesse meno capacità di calcolo rispetto al computer unitario, aveva un rigoroso requisito di affidabilità simile al computer NTDS. A causa di queste somiglianze, la direzione di Univac aveva scelto Vernon Leas, responsabile della produzione dell’ATHENA per guidare il team di progettazione preliminare per il nuovo computer. Leas aveva portato con sé un piccolo contingente di ingegneri che avevano lavorato sui dettagli di ATHENA, e a metà dicembre avevano abbastanza maniglia sul nuovo computer dell'unità che Leas ha detto alla direzione senior di Univac che avrebbero potuto avere un nuovo prototipo di computer dell'unità pronto per il test nei 9 mesi e mezzo richiesti. Cdr. Svendsen rispose emettendo un contratto che copriva la progettazione e la costruzione dettagliate del prototipo e una piccola produzione di nuovi computer unitari NTDS. Esamineremo come Univac ha portato a termine questo impegno apparentemente impossibile in una sezione successiva.

Il Navy Electronics Lab e i rappresentanti della Operational Test and Evaluation Force completarono tutti i test presso il sito di test ingegneristici nel novembre 1961. Molti problemi e difetti del sistema erano stati trovati e corretti in un ambiente a terra ragionevolmente realistico e il contingente OPTEVFOR riteneva che il Naval Tactical Data System fosse abbastanza solido da continuare a testare il servizio in mare. Fin dall'inizio dei test, le modifiche alle apparecchiature si erano alimentate ai tre principali appaltatori per l'incorporazione nella progettazione delle apparecchiature di prova di servizio; il più radicale dei quali fu la completa riprogettazione e ricostruzione del computer dell'unità.

In un progetto dal ritmo normale tutti questi cambiamenti si sarebbero accumulati per andare davanti a una commissione di revisione che avrebbe esaminato i risultati dei test e rivisto uno per uno e approvato o disapprovato ogni modifica. Il processo avrebbe potuto aggiungere un anno al programma del progetto; che il progetto NTDS compresso non poteva permettersi. Invece i responsabili del progetto BUSHIPS e OPNAV avevano mantenuto un processo di revisione e approvazione delle modifiche in corso in modo che i progetti dettagliati delle apparecchiature di prova di servizio fossero costantemente aggiornati man mano che i test del sistema ingegneristico progredivano.

Ottenere le navi di prova del servizio

Vuoi un vettore di attacco? Pensi di stare scherzando?

Il test di servizio fu il test acido per un nuovo sistema della Marina. Doveva essere fatto in mare in un ambiente il più realistico possibile, e sarebbe stato condotto da un'attività indipendente della US NAVY, la Forza di test e valutazione operativa che riferiva direttamente al capo delle operazioni navali. OPTEVFOR sapeva come sottolineare un nuovo sistema ai suoi limiti e trovare ogni difetto e debolezza. Per testare il collegamento dati tattico in mare, sarebbero state necessarie almeno due navi di prova di servizio, e dovevano essere navi della flotta del Pacifico in modo da poter lavorare con il Navy Electronics Lab di San Diego. Inoltre, una delle navi dovrebbe avere un NTDS a due computer e una nave doveva avere un sistema a tre computer. La nave a tre computer poteva essere un incrociatore pesante o un vettore d'attacco. Almeno una delle navi doveva avere installato un sistema missilistico di superficie e cannoni per testare la funzione di direzione delle armi. Questa nave poteva essere una fregata lancia missili guidati con un sistema a due computer.

A metà del 1959 la fregata missilistica guidata BUSHIPS "tipo desk" nominò due fregate, King e Mahan (DLG 10 e 11) in costruzione nei cantieri navali, i cui programmi avrebbero permesso l'installazione di NTDS subito dopo la messa in servizio. OPNAV aveva confermato che il progetto poteva usare entrambi, ma questa era la parte facile. 

OPNAV era incline a offrire un incrociatore pesante per testare il sistema a tre computer, ma gli ufficiali del progetto NTDS erano particolarmente desiderosi di ottenere un vettore di attacco per dare al controllo dell'intercettazione aerea del sistema e alle caratteristiche di controllo del traffico aereo un allenamento realistico. In effetti avevano in mente una portaerei d'attacco specifica, la USS Oriskany (CVA 34). Questa portaerei non era solo basata sul Pacifico, ma era anche l'unica portaerei della flotta del Pacifico con un grande centro di informazioni di combattimento modulare che poteva facilmente ospitare l'attrezzatura NTDS.

C'era molta resistenza nella flotta, e in OPNAV, per togliere dalla circolazione uno dei 13 vettori di attacco della Marina per quasi un anno per installare e testare un nuovo sistema che la maggior parte degli alti ufficiali navali non voleva. Nemmeno il sostenitore del NTDS, l'ammiraglio Burke, era incline ad andare al punto di dire che l’Oriskany fosse messa a disposizione del progetto. Sembrava che avrebbero dovuto accontentarsi di un incrociatore più datato.

Quando, all'inizio della seconda guerra mondiale, l'U. S. Navy acquisì la proprietà del Mount Vernon Seminary for Girls a Northwest Washington D. C. per diventare la casa dei codebreaker della Marina, la cappella della scuola giunse con la proprietà. L'attraente cappella in stile coloniale venne ribattezzata "Chapela della Marina" ed era un luogo ricercato per i matrimoni della marina. Assistente responsabile del progetto NTDS T. Erick Swenson e il suo amico Sandy Hopwood hanno fatto il viso nella maggior parte delle domeniche e in molti dei matrimoni. Il padre di Sandy era il viceammiraglio H. G. Hopwood, comandante in capo della flotta del Pacifico, e nell'autunno del 1959 partecipò a un matrimonio nella cappella.

Per qualche motivo, la persona che doveva riportare l'ammiraglio al suo hotel non si è presentata, ed Erick ha trovato Vadm. Hopwood aspetta nel parcheggio. Offrì all'ammiraglio un passaggio che fu gentilmente accettato, e lungo la strada Erick, che non era esattamente una viola che si restringeva, disse all'ammiraglio del progetto NTDS e di quanto fosse importante ottenere una portaerei di attacco come una delle navi di prova di servizio. Quando raggiunsero l'hotel, Hopwood invitò Erick e continuò il suo briefing entusiasta per altre due ore, durante le quali sottolineò le ragioni per ottenere specificamente Oriskany per il test di servizio.

Tornato al suo quartier generale di Pearl Harbor, Hopwood rivide il progetto NTDS con i quattro alti ufficiali del suo staff. Poi ha detto loro che voleva un voto sul fatto che dovessero offrire Oriskany per il test di servizio NTDS. Era quattro a uno contro il sostegno al progetto NTDS; tuttavia l'unico voto favorevole fu quello di Hopwood, e aveva detto loro che erano stati votati e di scrivere un messaggio al CNO che offriva Oriskany per il test di servizio e le ragioni per cui quella particolare nave era necessaria. Il 30 marzo 1961 la USS Oriskany entrò nel cantiere navale di San Francisco per iniziare una revisione di cinque mesi che includeva l'installazione del Naval Tactical Data System.

Improvvisamente, Altre due navi di "Test Di Servizio"

I radar del cartellone

Il posto migliore per montare un'antenna radar di ricerca era nella parte superiore dell'albero in modo che abbia una visione chiara e non distorta intorno alla nave. Il problema era che la maggior parte delle navi moderne utilizzava un solo albero, e molti dispositivi elettronici competono per avere la loro antenna situata nella parte superiore di quell'albero, e il risultato finale è che molti radar non ottengono la posizione migliore; e la pena è la perdita di potenza irradiata e distorsione angolare quando il raggio è costretto a cercare di guardare attraverso alberi, altre antenne e pezzi della struttura della nave. Era stato un sogno irrealizzato degli ingegneri radar costruire un'antenna radar che non ruotasse, ma piuttosto potesse essere "avvolta" attorno alla struttura di una nave.

Per anni gli ingegneri radar avevano saputo come "sterzare" elettronicamente un raggio radar da una serie piatta di elementi di antenna. Un modo per far emanare un raggio radar ad angolo da un array piatto è alimentare ogni elemento dell'antenna attraverso un shifter di fase in modo che ogni elemento in una linea di elementi dell'antenna rilasci il fronte d'onda in un momento leggermente diverso rispetto all'elemento accanto ad esso, con conseguente fronte d'onda inclinato da una perpendicolare all'array piatto. Questa è chiamata scansione di fase.

Un altro modo per dirigere il raggio da una serie piatta di elementi dell'antenna consiste nell'alimentare tutti gli elementi in una matrice lineare attraverso una guida d'onda che è stata piegata ripetutamente in una forma serpentina; con un rubinetto per ogni elemento dell'antenna nello stesso punto sulle pieghe sequenziali. Si può apprezzare che se la distanza tra i tocchi è esattamente uguale alla lunghezza d'onda del segnale che alimenta la guida d'onda, un raggio emanerà ad angolo retto rispetto al piano dell'array. Ma, se la lunghezza d'onda è resa leggermente più lunga o più corta della distanza tra il tocco, il fronte d'onda lascerà l'array ad un angolo rispetto alla perpendicolare. Questa è chiamata scansione di frequenza.

Il problema, tuttavia, era che era necessario un qualche tipo di dispositivo di controllo molto veloce e abile per cambiare rapidamente i sfalsa, o la frequenza, se un raggio radar doveva essere rapidamente spostato da una matrice di antenne planari. Semplici schemi di scansione di fase e frequenza erano in circolazione da anni, utilizzati principalmente nei radar di controllo del fuoco di artiglieria che si concentravano su un bersaglio e in cui il raggio non doveva essere ripetutamente e rapidamente girato per tracciare molti bersagli come faceva un radar di ricerca scansionato elettronicamente.

Ciò di cui un radar di ricerca a controllo elettronico aveva bisogno per programmare e controllare un radar di ricerca a scansione di frequenza o in fase era un computer digitale, e infine a metà degli anni '50 stavano iniziando ad apparire sulla scena. Ciò spinse il Bureau of Ships Radar Design Branch a rilasciare un compito al Navy Electronics Lab per indagare sull'uso di un computer digitale per il controllo di un radar di ricerca a controllo elettronico. Parte del compito del laboratorio aveva chiesto al laboratorio di emettere sollecitazioni all'industria radar per proporre le loro idee per un tale radar.

La Hughes Aircraft Company aveva proposto un'idea che era stata appena respinta dall’US Air Force per un radar di allarme rapido a missile balistico fisso a controllo elettronico che doveva essere guidato in cuscinetto e in elevazione da sollevatori di fase controllati dal computer. L'USAF aveva respinto l'idea per preoccupazione per il livello di rischio tecnologico e incertezza, ma la Hughes aveva modificato le loro idee nella proposta della Marina controllando lo sterzo nel cuscinetto mediante scansione di frequenza e l'elevazione mediante scansione di fase. Ciò aveva notevolmente ridotto la complessità del sistema e il Radar Branch aveva ritenuto che valesse alcuni dollari di ricerca e sviluppo. Diedero alla Hughes il via libera per la progettazione preliminare di un radar sperimentale di ricerca a bordo.

Il progetto in realtà prese forma come due radar che lavoravano come una squadra, e con ogni radar che utilizzava quattro array planari fissi che sarebbero stati montati su quattro lati della sovrastruttura di una nave - ad angolo retto l'uno rispetto all'altro. Il primo radar era un radar bidimensionale di ricerca aerea a lungo raggio che è stato scansionato in frequenza nel cuscinetto. Fu designato AN/SPS-32 e il suo scopo era quello di trovare obiettivi aerei a lungo raggio e visualizzarli su cannocchiali radar dove potevano essere raccolti manualmente dagli operatori radar umani. Gli operatori avrebbero quindi alimentato questi obiettivi verso un computer che controllava il raggio di un radar di ricerca tridimensionale che è stato scansionato in frequenza in elevazione e scansione di fase nel cuscinetto. Questo radar venne designato AN/SPS-33 e il suo raggio veniva controllato da un veloce computer digitale a programma fisso chiamato "tracker di computer". 

Long Beach ed Enterprise

I due radar si sono rivelati essere i più grandi radar di bordo mai costruiti. Le antenne SPS-32 misuravano 25 piedi di altezza e 20 piedi di larghezza, e l'intero radar con elettronica pesava oltre 48 tonnellate. Le antenne SPS-33 erano ancora più grandi a 40 piedi per 20 piedi di altezza per ciascuna delle quattro antenne. Non c'è da stupirsi che fossero chiamati i "radar da lavagna". Inoltre, l'SPS-33 pesava 120 tonnellate. Alla fine degli anni '50 c'erano solo due navi al mondo che potevano trasportare un peso così elevato in termini di sicurezza: le prime due navi di superficie a propulsione nucleare della Marina statunitense, la portaerei d'attacco Enterprise e l'incrociatore pesante Long Beach.

Il primo incrociatore a propulsione nucleare della US NAVY USS Long Beach. 

Due delle sue antenne a pannello furono montate sulla struttura del ponte. L'array più alto a sinistra era l'antenna radar di ricerca bidimensionale a lungo raggio AN/SPS-32 che alimentava i radar. La matrice più ampia a destra era l'antenna AN/SPS-33 il cui "raggio agile" era controllato dal computer e i cui ritorni venivano controllati dal computer. La nave aveva sistemi missilistici Terrier e Talos invece di cannoni nelle sue batterie principali. 

Oltre al peso e alla grande quantità di strutture in altezza necessari, c'era ancora un altro problema da risolvere per rendere praticabili questi radar: il radar tridimensionale SPS-33 non inviava segnali video grezzi ad un condotto radar. Le coordinate dei suoi bersagli erano note solo nel tracker del computer che, quando notificato della portata e dell’altezza di un nuovo bersaglio, avrebbe programmato un modello di fasci di ricerca attorno alla posizione del bersaglio data fino a quando non riceveva un segnale di ritorno. Quindi avrebbe programmato i raggi secondo necessità per mantenere il bersaglio in rilevamento. Queste informazioni sulla traccia venivano semplicemente mantenute come informazioni numeriche nel computer. Una stampa al computer di queste informazioni andava bene per una dimostrazione di laboratorio, ma per rendere i radar militarmente utili avevano bisogno di una qualche forma di display operatore/utente che potesse mostrare non solo il video analogico dell'SPS-32, ma anche le informazioni sulla traccia digitale dell'SPS-33.

Il Radar Branch aveva due scelte per il sistema di visualizzazione: vi era uno sviluppo di un nuovo sistema di visualizzazione digitale, o si potevano utilizzare i display del sistema di dati tattico navale modificati. Quest'ultimo sembrava quasi essere un matrimonio fatto in paradiso, perché la Hughes stava anche sviluppando il sottosistema di visualizzazione NTDS, e i display NTDS modificati sarebbero costati molto meno di un nuovo sviluppo. Il problema era che il sottosistema di visualizzazione NTDS non era un sistema operativo completo in sé. Aveva bisogno del sottosistema di elaborazione dei dati NTDS per renderlo lavorabile; ma a metà del 1960 l’NTDS era ancora solo un progetto di ricerca e sviluppo, e anche rischioso.

Il programma NTDS prevedeva il completamento della valutazione operativa a metà del 1962, mentre l’Enterprise avrebbe avuto bisogno della consegna delle sue attrezzature NTDS entro la metà del 1961 e il Long Beach necessitavao della sua entro l'inizio del 1962. Ciò avrebbe significato ordinare altre due suite di apparecchiature di prova di servizio NTDS con largo anticipo rispetto all'approvazione del servizio. C'era solo un uomo nella US NAVY che aveva l'autorità di scommettere l'efficacia militare di due delle risorse future più preziose della Marina sul successo del sistema di dati tattici navali non provato. Quello era l'ammiraglio Arleigh Burke, e nel settembre 1960 aveva piazzato la sua scommessa ordinando che altri due sistemi di test di servizio NTDS fossero messi in ordine.

Il piccolo e carico ufficio del progetto NTDS era ora nella posizione di dover acquisire e gestire l'installazione di cinque piuttosto che di tre suite di apparecchiature di prova di servizio quasi contemporaneamente. C'era un lato positivo nella nuova nuvola di tempesta. Le corse di produzione ampliate avrebbero contribuito ad abbassare il costo delle singole unità di apparecchiature NTDS. Hanno fatto le loro migliori stime dei costi delle nuove attrezzature e avevano segnalato a OPNAV quanti fondi "Ships Construction" sarebbero stati necessari per la costruzione del Long Beach e dell’Enterprise. Gli appaltatori fecero anche meglio del previsto, e Cdr. Joe Stoutenburgh fu lieto di confermare che il progetto NTDS è stato il primo progetto di ricerca e sviluppo della Marina statunitense a risparmiare sui fondi stanziati per la costruzione di unità navali. 

Preparazione per il test di assistenza

Un nuovo computer in 9 mesi e mezzo!

A causa delle differenze tra la vecchia barriera superficiale e i nuovi transistor planari, nessuno dei circuiti originali AN/USQ-17 poteva essere utilizzato. Elettronicamente, oltre che meccanicamente, il nuovo computer avrebbe avuto un nuovo design in tutto riutilizzando la vecchia architettura del set di istruzioni e le specifiche dell'interfaccia. Anche così, alle interfacce di input/output ci furono ancora dei cambiamenti. Invece dei 12 canali di uscita e 18 canali di ingresso del Q-17 di larghezza variabile, il nuovo computer avrebbe avuto 12 ingressi e 12 uscite, tutti a 30 bit, più due coppie di canali intercomputer a 30 bit. A causa dei cambiamenti, il nuovo computer ricevette una nuova designazione di equipaggiamento dell’esercito/marina: AN/CP-642.

Al direttore ingegneristico dei sistemi di dati di Univac, Arnold P. A Hendrickson venne assegnata la responsabilità dello sviluppo del CP-642 e delle serie di produzione di apparecchiature periferiche di supporto che includevano: unità di nastro magnetico, unità di nastro di carta, set di tasti manuali, set di tasti centrale, pannello di controllo del sistema, pannelli di interruttore digitali interconnessi, teletipi modificati, generatore di motori e controller per l'alimentazione del computer, un processore video radar automatico sperimentale e un nuovo dispositivo delle dimensioni di un frigorifero chiamato convertitore da digitale a analogico interconnesso - o IDAC in breve.

Ogni suite di bordo NTDS aveva un pannello di monitoraggio del sistema che forniva agli operatori lo stato dei computer dell'unità e consentiva agli operatori di avviare e fermare i computer, nonché di caricare e leggere programmi o dati da e verso unità di nastro magnetico e di carta dal CIC senza dover andare nell'area dell'attrezzatura incustodita che si trovava in uno spazio diverso dalla CIC. Questo pannello di monitoraggio del sistema venne configurato per controllare tre computer di unità.

I sistemi missilistici di superficie a bordo includevano un'area di controllo delle armi nel centro informazioni di combattimento che includevano console radar per il tracciamento aereo e il controllo delle armi, (di solito cinque) e un computer analogico per scopi speciali che conteneva negozi di binari per obiettivi selezionati ad alta priorità (di solito otto) che gli operatori sceglievano dalle console radar. L'ufficiale di controllo delle armi potevano assegnare questi obiettivi a missili o cannoni di bordo inviando coordinate bersaglio selezionate, sotto forma di tensioni elettriche analogiche, ai computer di controllo del tiro dei missili o delle armi.

Il sito di test di ingegneria NEL aveva utilizzato una banca di convertitori digitali-analogici non militarizzati per inviare coordinate di destinazione e segnali di stato dal computer NTDS al computer del sistema di direzione delle armi, ma i veri sistemi di bordo avrebbero avuto bisogno di un dispositivo completamente militarizzato per convertire e trasmettere questi segnali analogici. Mentre è stato assegnato al sito di test ingegneristico, Lcdr. Edwin L. Ball, un ufficiale di linea con una sotto-specializzazione in sistemi di armi e missili, aveva elaborato i dettagli della comunicazione che doveva avvenire tra NTDS e i sistemi di pistole e missili. Da questo scrisse le specifiche contrattuali per il Bureau of Ordnance per stipulare un contratto con Univac per lo sviluppo del necessario convertitore da interconnessione digitale ad analogico. Il flusso di dati numerici era in una sola direzione, dal computer digitale ai sistemi d'arma analogici con feedback del segnale di stato a NTDS per far sapere a NTDS quando un bersaglio era stato assegnato a un sistema di controllo del fuoco, quale bersaglio e quando il sistema di controllo del fuoco era bloccato e tracciato.

Arnie Hendrickson scelse un team di quattro persone per elaborare i dettagli di progettazione elettronica per il nuovo computer. L'attrezzatura elettronica di una nave da combattimento deve operare in un ambiente con estremi di shock meccanico, vibrazione, temperatura e umidità oltre ad essere esposto agli effetti corrosivi dell'aria carica di sale. Va quindi apprezzato che l'imballaggio meccanico e il raffreddamento di un computer completamente militarizzato erano altrettanto impegnativi quanto la progettazione elettronica, ed è significativo che Hendrickson abbia assegnato a 20 ingegneri meccanici per lavorare sull'imballaggio meccanico CP-642. La configurazione verticale in piedi dei computer A/N/USQ-17 seriali sei e sette è stata il punto di partenza per il loro design meccanico.

Il team di progettazione elettronica di quattro uomini era guidato da Herman Osofsky, che non era solo un matematico esperto nella progettazione logica, ma un ingegnere elettronico esperto nella progettazione dei circuiti. Ha lavorato sulla sezione di controllo centrale del computer. L'ingegnere elettronico Glen Kregness avrebbe progettato l'unità aritmetica, Findley E. McLeod la memoria del nucleo magnetico, e Robert L. Burkholder la sezione input/output. Le sezioni di controllo, aritmetica e input/output di un computer funzionavano in modi molto complessi tra loro, quindi Osofsky, Kregness e Burkholder erano in un cubicolo comune in modo da poter lavorare a stretto contatto tra loro; poiché non avevano tempo da perdere.

Fu deciso che il CP-642 avrebbe utilizzato una serie di schede di circuito stampato standardizzate per tutti i circuiti elettronici. Le schede sarebbero state relativamente piccole, misurando 1 5/8 per 2 5/8 pollici, e avrebbero contenuto da due a cinque transistor discreti e da 15 a 30 diodi, condensatori e resistori. Va ricordato che la metà degli anni '50 era prima dell'avvento dei circuiti elettronici allo stato solido integrati, quindi ogni transistor era montato all'interno della propria "lattina" protettiva che misurava circa un quarto di pollice sia in diametro che in altezza. A differenza dei circuiti stampati multistrato di oggi, le schede CP-642 utilizzavano un singolo strato con il cablaggio del circuito stampato sul lato opposto ai componenti elettronici. I fili stampati correvano verso un connettore standardizzato a 15 pin fissato a uno dei bordi lunghi della scheda.

I quattro progettisti misero a punto i loro progetti di circuiti completati a Lee Granberg, capo progettista di circuiti di Univac, che aveva confezionato i loro progetti sulle schede standardizzate ed elaborato i cavi tra le schede nei grandi cassetti scorrevoli che componevano il telaio elettronico. Gli ingegneri di Granberg escogitarono 49 diversi tipi di carte standardizzate e ogni computer di unità utilizzava 3.810 schede.

Uno dei 49 tipi standardizzati di schede a circuito stampato utilizzate nel computer unitario CP-642. Ogni unità di computer era composta da 3.081 di queste schede e ogni scheda conteneva da due a cinque transistor discreti.

Il nuovo computer dell'unità sembrava qualcosa come un grande frigorifero, infatti molti pezzi di equipaggiamento che comprendevano il Naval Tactical Data System avevano circa le dimensioni di un grande frigorifero perché questa era la dimensione massima di attrezzature che potevano essere maneggiate e spostate all'interno dei confini di una nave con porte stagne di dimensioni standard. Se l'attrezzatura fosse stata più voluminosa, sarebbe stata suddivisa in due o più unità. Oggi l'elettronica della maggior parte di queste unità di apparecchiatura sarebbe condensata su di un circuito integrato di dimensioni miniaturizzate.

La parte anteriore dell'armadio del CP-642 era composta da due porte che si aprivano verticalmente e consentivano ai manutentori di far scorrere i cassetti orizzontali del telaio elettronico per l'ispezione e il cambio della scheda. Centinaia di punti di prova si trovavano sul bordo anteriore di ogni cassetto. I pannelli di manutenzione e controllo del computer, con le loro centinaia di luci lampeggianti e pulsanti, erano montati sulla superficie interna delle porte, quindi le porte dovevano essere aperte per visualizzare e far funzionare i pannelli. Questa si sarebbe rivelata non essere una buona idea.

Gli ingegneri Univac completarono la progettazione elettronica e meccanica CP-642 nella primavera del 1960, ed entro la fine di giugno gli addetti alla produzione avevano completato il set di schede per il nuovo prototipo di unità di computer, designato CP-642 (XN-1). A questo tempo il nuovo armadio, il suo alimentatore e i cassetti elettronici erano pronti a ricevere le carte. Il team di progettazione elettronica di quattro uomini aveva inserito le schede un cassetto alla volta; e non appena il cassetto fu fatto scivolare di nuovo nella sua banca di connettori, applicarono l'alimentazione. Quindi monitorarono i punti di prova per cercare anomalie che indicassero un errore di progettazione o di assemblaggio. Quando trovarono ogni errore, interruppero il test per elaborare la causa e il cambiamento di progettazione necessario; e avrebbero notato il cambiamento necessario sui piani del circuito. Questo processo aveva richiesto sei settimane fino a quando la nuova macchina non fu completamente operativa senza errori. Avevano raggiunto il loro obiettivo di progettare e costruire un nuovo computer in 9 mesi e mezzo.

Nel test, trovarono che la nuova macchina aveva eseguito le istruzioni a circa il doppio della velocità dell'USQ-17, o circa 100.000 istruzioni al secondo. Due dei nuovi computer unitari che lavoravano insieme avevano quindi circa la stessa potenza di elaborazione di un computer SAGE a tubi che occupava 20 mila piedi quadrati e consumava 1,5 milioni di watt di potenza. Per confronto, due unità di computer avevano consumato 5.000 watt.

L'accendisigari non ce la fa

L'ingegnere delle installazioni navali di BUSHIPS Harvey G. Klohen non fu contento quando vide la scheda tecnica che chiedeva un accendisigari e che richiedeva 60 Hertz di potenza in ogni nuova console dell'operatore di test di servizio. Le console funzionavano con una potenza di 400 Hertz e l'accendino era l'unico elemento a 60 Hz nella console; richiedeva una fonte di alimentazione separata. Con una rapida chiamata all'ufficio del progetto NTDS aveva eliminato l'accendino. Le console di prova ingegneristiche erano state principalmente dispositivi di prova del concetto e non erano completamente militarizzate. Oltre alla conversione di numerosi circuiti da analogico a digitale e all'abolizione del numero di tipi di console da sette a tre, il più grande cambiamento nelle console di prova di servizio sarebbe stato quello di "indurirle" per superare tutti i requisiti di specifica militare dell'elettronica di bordo.

Anche se i test del sistema di test ingegneristico presso il Navy Electronics Lab non furono completati fino al novembre 1961, già nell'autunno del 1958 BUSHIPS aveva emesso un contratto alla Hughes Aircraft per iniziare a progettare l'imballaggio delle specifiche militari per le console di prova di servizio e le attrezzature di supporto come il generatore di simboli e i convertitori di azimut radar. Poi, nel gennaio 1959, l'Ufficio di presidenza emise il contratto di produzione di apparecchiature di prova di servizio alla Hughes, che iniziò a incorporare nuove modifiche al design elettronico dai risultati dei test di ingegneria in corso da parte di NEL.

Il nuovo design del generatore di simboli non solo incorporava la sostituzione di circuiti analogici con circuiti digitali che rendevano i simboli sui cannocchiali più coerenti nella forma, più puliti e più chiari, ma includeva anche due generatori di simboli completi nell'armadio. Ciò aveva permesso ad un generatore di simboli di servire tutte le console se l'altro generatore si fosse guastato, o aveva permesso di suddividere le console in due gruppi in modo che un gruppo potesse essere utilizzato per la formazione, i test o la manutenzione utilizzando un computer; l'altro gruppo forniva le normali funzioni CIC mentre era guidato dall'altro computer.

La prima destinazione per un sottosistema di visualizzazione dei test di servizio fu un nuovo sito di test a terra NTDS presso il Fleet Anti-Air Warfare Training Center, Pacific, a San Diego, proprio dall'altra parte della strada rispetto a NEL. Entro la fine di dicembre 1960 Hughes stava preparando le prime unità di visualizzazione per la spedizione al nuovo banco di prova. Per illustrare il programma altamente compresso del progetto NTDS, ribadiamo che i test sarebbero continuati presso il sito di test ingegneristico del Navy Electronics Lab fino a novembre 1961. Già nel marzo 1961, Hughes iniziò a consegnare unità di visualizzazione per le navi d'attacco Enterprise a Newport News Shipbuilding e Oriskany al San Francisco Naval Shipyard.

Sottosistemi di comunicazione dei test di servizio

Anche se aveva quasi causato un incidente internazionale nella primavera del 1958 quando due dei risonatori sintonizzati nel set di terminali di dati Collins AN/SSQ-29 della USS Rexburg (modem) ebbero un malfunzionamento intermittente durante la visita dell'ammiraglio Mountbatten al sito di test ingegneristico, l'SSQ-29 passò attraverso i test a pieni voti. La versione di prova del servizio aveva richiesto così poche modifiche mantenendo la sua nomenclatura originale: AN/SSQ-29 (XN-2).

Anche la radio ad alta frequenza Collins KWT-6 HIGHCAPCOM fece bene e BUSHIPS raccomandò a OPNAV di utilizzarla non solo come radio NTDS A-Link, ma anche per comunicazioni generali ad alta frequenza a bordo. Venne rinominato il set radio AN/SRC-16 e quattro di queste radio sarebbero state installate in ogni nave equipaggiata con il sistema NTDS.

L'UFFICIO, nel luglio 1958, stipulò un contratto con Collins Radio per otto sistemi radio di prova di servizio AN/SRC-16. Il primo per il nuovo sito di prova a terra presso il Fleet Anti-Air Warfare Training Center, San Diego. Altri per i cantieri navali per le tre navi di prova di servizio, per Long Beach e Enterprise, e altri due siti a terra. Più tardi, nel maggio 1959, Collins fu incaricato di spedire otto set di terminali SSQ-29 agli stessi destinatari. 

Anche il collegamento dei dati di controllo dell'intercettore fu testato durante la valutazione operativa. A tal fine, il Bureau of Ordnance acquisì sette set di terminali di controllo dell'intercettore AN/SSW-1 di prova di servizio dalla Western Electric Company. Questi set sarebbero stati consegnati alle tre navi di prova di servizio, Long Beach, Enterprise e due siti a terra. Furono acquisite anche sette radio UHF Manson Laboratories AN/SRC-17 per supportare il collegamento di controllo dell'intercettore. Queste radio erano collegate al sistema di bordo in modo che potessero servire alternativamente come radio di controllo dell'intercettore o un collegamento dati tattico UHF chiamato C-Link.

L'UHF C-Link sarebbe stato un'alternativa al collegamento dati primari Link-11 basato su radio ad alta frequenza. Avrebbe avuto una portata prevista di circa 150 miglia e il suo vantaggio tattico sarebbe stata la trasmissione radio della linea di vista ad alta velocità dei dati che contribuì a ridurre la vulnerabilità di una task force a rivelare la sua posizione tramite intercettazione radio. A metà del 1959 BUSHIPS stipulò un contratto con Univac per lo sviluppo di un set di terminali dati C-Link a cui venne dato il nome di "logica delle apparecchiature terminali" o (TEL). Il Bureau acquisì sei unità TEL per il collegamento dati tattico secondario di 13.000 bit al secondo.

Un altro test basato a terra

Subito dopo la prova del computer XN-1, Univac completò il computer CP-642 numero di serie due nell'estate del 1960 e lo spedì immediatamente al nuovo sito di prova terrestre. Il sottosistema di visualizzazione del test di servizio Hughes e l'apparecchiatura di collegamento dati Collins erano già stati installati. Questo sito sarebbe stato eventualmente utilizzato per la formazione degli operatori NTDS e lo sviluppo di programmi per computer, ma il suo primo utilizzo doveva essere quello di testare un assemblaggio completo di apparecchiature di test di servizio, per la prima volta.

Il nuovo computer dell'unità non aveva mai funzionato prima con gli altri sottosistemi di test di servizio NTDS e questo test sarebbe stato fondamentale. Il cablaggio era già stato fatto per il computer, e tutto ciò che rimaneva era rimontare il computer dal suo furgone, collegare il cablaggio e accendere il sistema. I rappresentanti senior erano a disposizione dei tre appaltatori delle attrezzature, così come gli ingegneri NEL e gli ufficiali di progetto NTDS, ed erano più che un po' ansiosi. I tecnici collegarono i cavi, trovarono e corressero alcuni errori di cablaggio e alimentarono l’apparecchiatura caricando un semplice programma di prova; iniziarono a controllare metodicamente le funzioni del sottosistema, una per una. Tutti i presenti furono molto sollevati quando, nel giro di tre ore, tutti i sottosistemi avevano superato i loro test. Il progetto era ancora in pista! Univac fu indirizzata a iniziare a costruire altri quindici computer CP-642 e nel dicembre 1960 Univac stava spedendo i nuovi computer ai cantieri navali.

Il computer dell'unità CP-642 numero di serie n. 2 installato presso il Fleet Anti-Air Warfare Training Center, San Diego, sito di test a terra. Questa macchina era stata completamente "militarizzata" per soddisfare tutti i requisiti ambientali di bordo della nave per l'elettronica. I pannelli di manutenzione e di controllo potevano essere visti all'interno delle porte, che normalmente venivano tenute chiuse.

Univac era stata incaricata di costruire i nuovi programmi informatici di prova di servizio, che dovevano essere consegnati al Fleet Computer Programming Center del FAAWTC dopo il test di servizio. Il programma del computer di test ingegneristico era stato scritto nel codice automatico nativo del computer USQ-17, ma il programma di test di servizio era stato scritto con il nuovo sistema di compilazione NTDS CS-1, un sistema di codifica "di alto ordine" in cui le istruzioni formalizzate in lingua inglese e il programmatore numerico erano state automaticamente convertite in codice macchina. Era quindi un programma completamente nuovo, e aveva i suoi "bug" che i programmatori Univac, assistiti dai nuovi programmatori della Marina USA, pazientemente corressero. Dopo alcuni mesi avevano il programma in esecuzione bene nell'ambiente del sito di prova e non c'era motivo di credere che non avrebbe funzionato altrettanto bene nell'ambiente di bordo. Si stavano preparando per un brusco risveglio…

Installazione di apparecchiature digitali in un mondo di cantiere navale analogico

Il cantiere navale di Puget Sound aveva intenzione di installare la suite NTDS di test di servizio nella fregata FFG di nuova costruzione King, e il cantiere navale di San Francisco doveva fare lo stesso per la portaerei d’attacco Oriskany e la fregata Mahan. Questi cantieri non avevano mai visto un sistema digitale prima, ma avevano comunque solo sei mesi per installare i sistemi e controllarli.

Dalla sua esperienza in cantiere navale, il capitano Svendsen sapeva che ci sarebbero stati problemi imprevisti e crisi che avrebbero potuto uccidere il progetto se non risolti rapidamente. Quindi fece in modo che i coordinatori del progetto degli ufficiali navali fossero assegnati a ciascun cantiere navale; avrebbero dovuto avere una linea di comunicazione diretta verso l'ufficio del progetto BUSHIPS. Si assicurò che questi coordinatori del progetto fossero già tecnicamente esperti in NTDS, oltre a conoscere la US NAVY e l'organizzazione del progetto dell'appaltatore e le persone coinvolte. Svendsen aveva anche incaricato i tre appaltatori di apparecchiature NTDS di inviare ingegneri nei cantieri di installazione per assistere nell'installazione. Forse ancora più importante, OPNAV aveva organizzato per i futuri tecnici del sistema dati delle navi, che avevano imparato la manutenzione NTDS presso il sito di test ingegneristico NEL, per essere a bordo delle loro navi prima dell'inizio dell'installazione in modo da poter dare ai lavoratori del cantiere navale il beneficio della loro esperienza.

Il tenente comandante Alfred Bettis ricevette quindi l'ordine nel 1960 di procedere dal Navy Electronics Lab al Cantiere navale di San Francisco per assumere la carica dell'installazione dei sistemi di test di servizio a Oriskany e Mahan. Ufficiale capo H. A. Cain ricevette ordini simili per procedere da NEL al cantiere navale di Puget Sound per prendere in consegna l'installazione di King. Quando LCD. Bettis lasciò NEL fu sostituito dall'ufficiale di ingegneria Lcdr. Stanford R. Wilde che aveva assunto il test dei collegamenti dati. Lo fece fino alla metà del 1961, quando fu trasferito al cantiere navale di Filadelfia per supervisionare l'installazione dell’NTDS sull'incrociatore nucleare Long Beach.

I siti di prova terrestri a San Diego avevano funzionato così bene che BUSHIPS emise compiti a ciascun cantiere navale per creare un luogo a terra dove i set di apparecchiature NTDS della nave potessero essere assemblati, completi dei loro cavi di interconnessione a bordo della nave e testati prima di installare a bordo delle navi. I connettori sarebbero stati poi tolti da un'estremità dei cavi prefabbricati in modo che i lavoratori dei cantieri navali potessero tirare i cavi delle dimensioni di un polso; in alcuni casi, erano più lunghi di 300 piedi sul Long Beach e sull’Enterprise.

I tre programmi di installazione delle tre navi di prova di servizio, Oriskany, King e Mahan, richiedevano il completamento dell'installazione e del check-out di NTDS entro la fine di settembre 1961, cosa che Puget Sound e San Francisco Naval Shipyards fecero senza grandi difficoltà. La portaerei Enterprise non era dotata di sistemi missilistici, quindi la sua configurazione NTDS era più semplice delle navi dotate di missili, ed era in grado di utilizzare il programma a tre computer della Oriskany con solo piccole modifiche per ospitare i suoi due radar "bardboard". Inoltre, Newport News Shipbuilding, che stava costruendo la Enterprise, era abbastanza vicino a Washington D.C. da consentire a un rappresentante dell'ufficio del progetto BUSHIPS, il tenente Hal Morris, di guidare settimanalmente per rivedere i progressi e i problemi sul campo. Newport News ha poi consegnato la Enterprise nel gennaio 1962 con il suo NTDS attivo e funzionante.

Nel marzo 1963 la rivista National Geographic pubblicò un eccellente articolo sulla USS Enterprise. Le pagine 442 e 443 sono una diffusione di foto scattate nel centro informazioni di combattimento di Enterprise. La metà inferiore delle due pagine è una foto dei cinque operatori di tracciamento del radar di ricerca bidimensionale a lungo raggio AN/SPS-32 sulle loro console NTDS. Il video di ciascuno dei quattro quadranti delle antenne del cartellone può essere visto sui loro cannocchiali radar. 

Il lavoro di Stan Wilde era tagliato per lui. La USS Long Beach fu il primo incrociatore della Marina a non avere cannoni nella sua batteria principale; era armato esclusivamente con missili guidati e 2 cannoni 127/38 a metà nave. Aveva due batterie missilistiche Terrier a doppia guida in avanti e una batteria Talos a doppia guida a poppa. Il suo NTDS avrebbe dovuto avere un'interfaccia complessa con i due sistemi missilistici attraverso il nuovo edito Weapons Direction Equipment Mark 2. Il Long Beach fu costruita dalla Bethlehem Steel Corporation di Quincy, MA, ed entrò Ion servizio nel settembre 1961. Tuttavia, né il radar tridimensionale Hughes AN/SPS-33, né il suo NTDS erano stati installati dal costruttore navale.

La Hughes aveva avuto problemi tecnici con l'SPS-33 e li consegno in ritardo; il programma dell'attrezzatura di prova del servizio NTDS non corrispondeva al programma di costruzione della nave. Entrambi questi sistemi dovevano essere installati dal cantiere navale di Filadelfia a partire dalla primavera del 1962. Wilde arrivò in cantiere nell'estate del 1961 per iniziare a pianificare l'installazione a tre computer, le sue interfacce con i sistemi missilistici e le sue interfacce con i sistemi radar dei cartellone pubblicitari, nonché il test di una serie di nuove funzionalità del programma informatico NTDS relative ai sistemi missilistici. L'installazione e il checkout richiesero otto mesi e terminò nei tempi previsti alla fine del 1962.

Operational Test and Evaluation Force, l'avvocato dei consumatori della Marina

La Forza di test e valutazione operativa (OPTEVFOR) è un comando separato in debito con nessuno tranne che con il capo delle operazioni navali. È indipendente dalle forze operative, nonché dagli uffici e dalle organizzazioni che sviluppano e procurano materiale per la Marina. La sua missione è quella di testare ogni nuova attrezzatura o sistema acquisito per l'uso della US NAVY in un ambiente realistico in mare e raccomandare l'approvazione o il rifiuto del servizio. Nella maggior parte dei casi ha scoperto cose sbagliate con il nuovo prodotto e ha consigliato i rimedi tecnici per renderlo riparabile.

Nel 1960 il contrammiraglio William D. A Irvin fu nominato all'Ufficio del Capo delle Operazioni Navali, dove era stato sponsor del progetto NTDS, di prendere il comando di OPTEVFOR. Una delle sue prime azioni nel nuovo lavoro fu quello di trovare il tenente comandante Chandler E. Swallow, che aveva appena terminato un tour come CO di una scorta di cacciatorpediniere di picchetti radar e che prima era stato nell'ufficio del progetto OPNAV NTDS. Irvin aveva fatto in modo che Chan Swallow fosse ordinato al distaccamento del Pacifico di OPTEVFOR a San Diego per prendere in carico la valutazione operativa NTDS (OPEVAL).

Questo accordo, per avere due ufficiali che erano ovviamente sostenitori del nuovo sistema, incaricati di testare "imparzialmente" poteva sembrare un conflitto di interessi, tuttavia, in realtà, era un'indicazione di quanto seriamente i livelli di gestione senior della Marina fossero impegnati nel successo dell’NTDS. Questo nonostante l'altro 95% degli alti ufficiali navali che si opponevano categoricamente. Il sentimento del più alto livello di gestione era, se c'è qualcosa che non va con l’NTDS, troviamolo e sistemiamolo, e il modo per farlo è testarlo. C'era anche la possibilità che l'NTDS potesse effettivamente essere trovato morto in un ambiente operativo realistico e irrisolvibile. Dopotutto, il mare era conosciuto da OPTEVFOR come "il mostro che ha mangiato la scienza". Nonostante i siti di prova a terra, c'erano ancora molte incognite.

La valutazione operativa sarebbe iniziata nell'ottobre 1961, e Lcdr. Swallow era arrivato al distaccamento del Pacifico di OPTEVFOR un anno prima di iniziare a preparare il piano di test. OPTEVFOR non aveva mai testato un sistema digitale prima, tuttavia fu ritenuto che sarebbe stato molto importante sapere cosa stava succedendo nei programmi per computer mentre erano in fase di test. Quello che Swallow voleva era un modo per estrarre periodicamente i dati dai computer mentre erano in esecuzione. Trascorse molto tempo con i programmatori Univac di NEL cercando di ideare routine di estrazione dei dati scoprendo che poteva essere fatto e che i dati potevano essere stampati quasi in tempo reale dai teletipi NTDS, ma c'era un intoppo: le routine di estrazione dei dati avevano preso una memoria preziosa e fu scoperto che per essere di uso pratico, la quantità di memoria necessaria avrebbe richiesto la cancellazione di uno o più moduli tattici del programma operativo; il che era inaccettabile. Oggi, grazie principalmente all'incredibile crescita della memoria dei computer a basso costo, la registrazione degli eventi è una parte standard di qualsiasi sistema di combattimento navale della US Navy.

Il meglio che potevano fare era allestire il terminale A-link nel sito di prova ingegneristico del Navy Electronics Lab per ascoltare e registrare su nastro magnetico le trasmissioni di collegamento dati delle tre navi di prova di servizio. Ciò avrebbe permesso loro di ricostruire ciò che stava accadendo in mare in una discreta quantità di dettagli, e si è rivelato molto utile. Oltre a questo, Swallow e i suoi tester sarebbero stati limitati a prendere appunti e parlare nei registratori vocali per ricostruire cosa stava succedendo con circa 90 operatori e sette computer digitali su tre navi. Avevano voluto fare filmati delle attività nei centri di informazione di combattimento, ma non riuscivano a trovare alcuna tecnologia che avrebbe supportato la fotografia nei CIC oscurati.

Il Pacific Missile Range a Point Mugu, CA, aveva radar di precisione che potevano tracciare e registrare le tre navi e gli obiettivi aerei quando erano nel raggio d'azione dei radar Mugu, e Swallow prese accordi per farlo. Ciò consentì il confronto delle coordinate di collegamento dati di navi e aerei con misurazioni simultanee effettuate dai radar Mugu.

La prima fase dell'OPEVAL sarebbe stata una valutazione tecnica (TECHEVAL) in cui i sistemi sarebbero stati principalmente sotto il controllo del capitano Svendsen supportati da ingegneri dei tre appaltatori di attrezzature e NEL. Alzavano i sistemi un po' alla volta. Per prima cosa avrebbero inserito tracce simulate nei sistemi per vedere come i computer le elaboravano e dipingevano simboli artificiali di tracce sulle console radar. Poi avrebbero fatto la stessa cosa usando video in diretta dai radar della nave, un radar alla volta, fino a quando tutti i radar non fossero stati attivati contemporaneamente. Successivamente avrebbero acceso i collegamenti dati tattici delle tre navi e i dati di tracciamento commerciale tra loro sotto il controllo principale del set di terminali dati basato sulla costa di NEL. Infine avrebbero esercitato il collegamento dati sotto il controllo netto di una delle tre navi. Questo non era mai stato fatto prima. Gli osservatori di OPTEVFOR sarebbero stati in piedi prendendo appunti e osservando le registrazioni di collegamento dati durante questa fase.

La fase successiva sarebbe stata sotto il controllo di OPTEVFOR e solo i marinai della nave avrebbero gestito il sistema. Va notato che il capitano Svendsen aveva già deciso che, come misura della sua fiducia nella loro formazione e capacità, i tecnici del sistema dati della nave avrebbero mantenuto l'attrezzatura NTDS dall'inizio di TECHEVAL - senza alcun aiuto o intervento da parte di ingegneri appaltatori, e lo fecero a pieni voti.

La fase OPTEVFOR avrebbe esercitato il sistema NTDS in operazioni di task force realistiche, inclusi attacchi aerei che replicavano le capacità e le tattiche sovietiche. Gli attacchi sarebbero iniziati con alcuni aerei della USN alla volta e, con il passare del tempo, sarebbero aumentati fino ad attacchi di saturazione di massa fino a 20 gruppi di attacco che arrivavano a varie altitudini e da molte direzioni contemporaneamente. OPTEVFOR avrebbe valutato le prestazioni NTDS registrando il numero di aeromobili rilevati e tracciati, il numero di lanci di missili simulati e gli impegni con le armi, nonché il numero di intercettori addestrati con successo nelle posizioni di tiro sui loro obiettivi. Questa prestazione sarebbe poi stata confrontata con le prestazioni del tracciato manuale delle squadre CIC in passate esercitazioni aeree simili. Gli osservatori tentarono anche di registrare la quantità di sforzo, attività e confusione in corso nei tre centri di informazione di combattimento. La confusione si verificò, ma risultò che la principale fonte di confusione non erano stati gli aggressori aerei, ma sarebbe stata auto-inflitta dai nuovi programmi per computer. 

Incubo in mare

Il capitano Svendsen sapeva meglio che aspettarsi che l'OPEVAL andasse liscio senza problemi emergenti. Semplicemente non riusciva a prevedere quali problemi e dove sarebbero spuntati. Quello che fece è stato stabilire un sistema e una persona il cui compito era trovare problemi, tenerne traccia e metterli in campo per la risoluzione. Il Tenente comandante James E. Radja fu ordinato a NEL a metà del 1960 per assumere quel lavoro. Il suo compito era quello di cercare di trovare ogni difetto incipiente nel sistema di test di servizio e inviarlo sulla sua strada per la soluzione; se possibile, prima dell'inizio di OPEVAL. Era un risolutore di problemi irrisolvibili, e un'altra parte del suo lavoro era quella di tenere traccia di ogni guasto dell'apparecchiatura e della sua causa in modo da poter costruire un record statistico dell'affidabilità delle apparecchiature.

Giacomo E. Radja vebbe assegnato come Troubleshooter dell'ufficio del progetto NTDS. Qui lui e un tecnico del sistema dati sollevarono un cassetto elettronico di un computer AN/USQ-17 per esaminare una scheda di circuito stampato. Sollevare un cassetto Q-17 era un'operazione per due uomini ed era uno dei motivi per cui il computer dell'unità CP-642 era progettato con cassetti orizzontali.

A metà del 1961 il capitano Svendsen organizzò il proprio cambio di ordini di stazione da BUSHIPS al Navy Electronics Lab in modo da poter essere sul posto durante l'OPEVAL. Si sarebbe personalmente preso in carico della parte iniziale di "valutazione tecnica" dell'OPEVAL. Techeval iniziò nei tempi previsti nell'ottobre 1961, con i marinai sulle tre navi che entravano in tracce simulate nei computer. Le cose funzionarono bene a bassi carichi di tracciamento, proprio come il sistema presso il sito di prova a terra. Ma man mano che il carico veniva aumentato, e soprattutto quando venivano attivati altri sistemi di interfacciamento a bordo, le cose iniziarono ad andare male. Era come i primi giorni al sito di prova di ingegneria. I programmi per computer si guastarono più e più volte. Le cose peggiorarono quando i marinai fecero deliberatamente applicazioni di controllo errate come potrebbe accadere nella vita reale operando in mare. 

Ogni notte i programmatori di computer Univac lavoravano presso il sito di prova del Fleet Anti-Air Warfare Training Center analizzando e correggendo i difetti del programma informatico e consegnavano programmi "corretti" alle tre navi ogni mattina. Il capitano Svendsen iniziò a rendersi conto che spostare un programma per computer ben testato in un nuovo ambiente era l'equivalente di avere un programma nuovo di zecca che aveva bisogno di alcuni mesi di "test e correzione" prima di poter essere dichiarato stabile. Gli sarebbe piaciuto molto avere quei pochi mesi per trovare e correggere tutti i nuovi errori, ma il programma di operazione non lo avrebbe permesso. Estendere l'OPEVAL avrebbe significato cambiare i successivi programmi di distribuzione della nave e avrebbe dato ai critici le munizioni che volevano per affinare il progetto. Decise di far andare le navi in mare indipendentemente dalla continua comparsa di nuovi bug del programma.

Uno dei test più critici in mare fu quello di avviare il collegamento dati tattico su tutte e tre le navi ed eseguirlo sotto il controllo della rete di Oriskany. Il collegamento non aveva mai eseguito indipendentemente dal controllo principale del collegamento presso il sito di test NEL e il test era previsto per il venerdì dopo la festa del Ringraziamento del 1961. Probabilmente erano marinai nervosi che inserivano assegnazioni di rete errate, o impostavano le frequenze radio sbagliate: per le prime ore tutti i tentativi di avviare la rete fallirono. Finalmente una chiamata radio da un capo sottufficiale su una delle fregate di missili guidati, "Penso che stiamo sincronizzando!" Than chiama dalle altre due navi "Siamo sincronizzati!" Gli allarmi risuonarono in tutti e tre i CIC. Gli ambiti nelle CIC iniziarono a mostrare le nuove tracce bersaglio provenienti dalle altre navi. Il sistema stava finalmente iniziando a funzionare. 

Anche dopo settimane in mare, nuovi bug di programmi per computer continuavano a spuntare quando le nuove funzionalità venivano attivate per la prima volta. Le informazioni sui nuovi bug furono trasmesse al sito di test FAAWTC ogni notte e i programmatori di Univac lavoraronoo febbrilmente per tutta la notte. Ogni mattina nuovi nastri del programma sarebbero volati a Oriskany. I programmatori iniziarono ad apprezzare l'attenta documentazione del programma per computer che gli era stato richiesto di mantenere - nonostante qualche protesta. Svendsen avrebbe voluto molto più tempo per continuare TECHEVAL, ma si stava muovendo nel tempo in cui erano stati programmati ampi servizi aerei per OPEVAL e accettò di continuare contemporaneamente TECHEVAL e allo stesso tempo avere il Cdr. Swallow iniziò l'OPEVAL.

Gli attacchi aerei erano iniziati e ogni giorno si erano accumulati numerosi aerei. Ma a volte sembrava che ci fossero più simboli di bersaglio sui cannocchiali radar che nell'aria. Sembravano proliferare e Svendsen iniziò a sospettare che la causa dei simboli extra della pista fosse dovuta a errori di posizione delle navi. Quando le posizioni precise della nave venivano inserite all'inizio di ogni giorno, il problema non era così grave. Ma sembrava che mentre la posizione morta di una nave trasmittente iniziasse a divergere sempre di più dalla sua vera posizione, i simboli del bersaglio trasmessi cadevano a miglia di distanza dalla posizione effettiva del bersaglio e altre navi interpretavano il blip radar senza accompagnare il simbolo del bersaglio come un nuovo bersaglio e iniziassero la propria traccia su di esso. Le registrazioni dei radar di precisione a Point Mugu, rispetto alle registrazioni dei collegamenti dati NEL, confermarono che a volte il sistema conteneva tre tracce separate sullo stesso bersaglio. Una traccia diversa da ogni nave.

Il Global Positioning System non era nemmeno un sogno a metà degli anni '50, e le correzioni di navigazione di navi e aerei potevano essere meno accurate di un ordine di grandezza rispetto alle misurazioni radar. Questa mancata corrispondenza di precisione avrebbe potuto essere un killer del progetto se non fosse stato per una routine di calcolo che i programmatori Univac avevano ideato in fretta per sfruttare la relativa precisione delle misurazioni radar. I responsabili del progetto battezzarono la routine "ingorgo". Ogni volta che le navi in una task force erano abbastanza vicine da vedersi sul radar di ricerca superficiale a lungo raggio, gli operatori NTDS potevano stabilire posizioni relative accurate rispetto alle unità partecipanti utilizzando misurazioni radar. La nave di controllo della rete era generalmente impostata come nave maestra e tutte le altre navi partecipanti potevano utilizzare le misurazioni radar internavi per ricavare una posizione di navigazione relativa accurata basata sulla nave maestra. Il modulo del programma di blocco consentiva agli operatori di eseguire la funzione di blocco in pochi secondi e i molteplici falsi obiettivi andavano via.

Verso la fine della valutazione di sei mesi, Lcdr. Swallow riferì che il sistema stava finalmente rimanendo in piedi per tre o quattro ore senza guasti al programma, e quando funzionava, funzionava molto bene. Tuttavia, di solito dopo un massimo di quattro ore iniziavano ad apparire i “gremlin”, soprattutto nelle routine di segnalazione e aggiornamento della pista. Nel normale funzionamento, quando un bersaglio si muoveva dall'area operativa, il supervisore di tracciamento della nave avrebbe dovuto eliminarlo per evitare che i negozi di pista si riempissero di vecchie tracce. Si è scoperto che i negozi di pista si stavano riempiendo di obiettivi che i supervisori avevano mancato prima che scomparissero dai cannocchiali. Poi, quando il computer non riusciva a trovare più spazio nei negozi, non riusciva a farcela. Una delle raccomandazioni finali di OPTEVFOR era una routine di cancellazione automatica della traccia.

Un certo numero di alti ufficiali navali erano abbastanza curiosi dell’NTDS da visitare le navi durante la valutazione. Furono tutti invitati a sedersi alle console ed esercitare il sistema, in particolare la funzione di valutazione delle minacce e assegnazione delle armi (TEWA). LCD. Chan Swallow osservò che di solito erano a disagio riguardo al TEWA, e lo esprimevano come una rinuncia al loro giudizio e alla flessibilità decisionale a una macchina. Ciò che Swallow alla fine si rese conto che li infastidiva era il fatto che quando avevano tolto il dito dal pulsante, il sistema stava mostrando loro la sua raccomandazione. Si sarebbero sentiti molto più a loro agio se il computer avesse masticato i dati per un po' prima di sputare la risposta. Ha anche dovuto continuare a ricordare loro che il computer stava dando raccomandazioni non ordini, e che potevano sempre aggiungere nuovi dati o condizioni e far riprovare il computer. 

Nella primavera del 1962 l'ingegnere Univac David Lundstrom era a bordo di una delle fregate missilistiche di prova nel porto di San Diego. Gli capitò di sentire Lcdr. Jim Radja, il responsabile della manutenzione NTDS della nave sui dati sui guasti delle apparecchiature. Disse che stava ricevendo molti dati su quasi tutte le apparecchiature tranne i computer dell'unità. Il capo stava salvando i rapporti di guasto del computer che non aveva ancora consegnato? Radja confermò che ne aveva davvero bisogno per la sua analisi. Il capo pressato disse di aver consegnato tutto quello che aveva, e poi per spiegare la scarsità di dati di guasto del computer riferì con enfasi: "Diavolo, non fallisce quasi mai signore". Radja si scusò e confidò al capo che anche le altre due navi avevano avuto pochissimi guasti informatici.

Sopravvivenza

L'OPEVAL terminò il 1° aprile 1962 e il successivo rapporto di OPTEVFOR notò che, sebbene i programmi per computer avessero fallito almeno una volta al giorno, e a volte tre e quattro volte al giorno, l'apparecchiatura NTDS si era trovata molto affidabile. A causa della ridondanza deliberata integrata nel sistema e della sua graziosa capacità di degradazione, in nessun momento nessuno dei tre sistemi della nave era stato inoperabile a causa di guasti alle apparecchiature. Lo studio di affidabilità di otto mesi di Radja confermò questa scoperta; i computer unitari, a cui era stato assegnato un obiettivo di 200 ore di tempo medio prima del guasto (MTBF) avevano effettivamente sperimentato 1.500 ore di MTBF.

Analisi dell'affidabilità delle apparecchiature di prova di servizio NTDS di Jim Radja.

Il rapporto di Radja notò che i sette computer unitari sulle tre navi avevano un totale di 26.670 schede stampate, di cui solo 25 schede avevano fallito negli otto mesi. Inoltre, sette di questi guasti erano intermittenti ed erano stati causati da pin del connettore che occasionalmente perdevano il contatto. I restanti 19 guasti erano dovuti a componenti elettronici guasti. Radja calcolò che per tutti i sottosistemi NTDS il costo annuale di consumo delle parti di riparazione NTDS per le tre navi sarebbe stata inferiore alla metà dell’1% del costo dell'attrezzatura originale. Questo era incredibilmente basso. Tutti e tre gli ufficiali di comando della nave raccomandarono di potersela cavare con un minor numero di tecnici del sistema di dati NTDS.

L'unica attrezzatura deludente era il collegamento dati tattico UHF secondario ad alta velocità (C-Link), e ciò non era dovuto al guasto dell'attrezzatura di per sé, ma piuttosto alla vulnerabilità delle trasmissioni UHF all'umidità nell'aria. In alcuni giorni il C-Link non poteva comunicare a più di 20 miglia, piuttosto che al suo obiettivo di 150 miglia. Questo link è stato eliminato dal requisito operativo NTDS. Il C-Link è rimasto comunque utile in un altro modo. Nei futuri layout di installazione NTDS della nave, l'ingegnere delle installazioni NTDS William C. O'Sullivan lasciò uno spazio tra i due computer dell'unità per un mitico terminale C-Link. Si sarebbe scoperto che quando OPNAV aveva ordinato che un computer di terza unità fosse rimontato in quelle fregate lancia missili, il peso, lo spazio, la potenza e le riserve di acqua di raffreddamento per il terminale C-Link, per sorprendente coincidenza, erano esattamente le stesse del computer dell’unità.

I programmi per computer erano il vero problema. Swallow era sicuro che i programmi non potessero usurarsi con l'uso, e nemmeno si stavano modificando durante il funzionamento, quindi ciò che stava causando i guasti. In lunghe discussioni con i programmatori era diventato evidente che ogni nuovo bug sembrava verificarsi quando il programma stava attraversando un percorso che non aveva mai eseguito prima durante tutti i test. 

Un esempio di uno di questi bug nascosti era quello che si verificò ogni pochi giorni nel programma di Oriskany: successe un paio di volte proprio durante gli attacchi di saturazione dall'aria quando fece abbattere l'intero sistema della nave. I programmatori di computer a terra indagarono sul problema per settimane fino a quando non scoprirono che si trattava di un'istruzione sbagliata in una parte del programma che raramente veniva eseguita. Ma quando questo ramo del programma era stato attraversato, l'istruzione errata aveva impostato l'orologio in tempo reale a zero in uno dei tre computer che non solo aveva fermato quel computer, ma anche gli altri due. Era diventato chiaro che nessuna quantità di test a terra poteva replicare tutto ciò che poteva accadere quando si era nel sistema della nave reale. Fu anche chiaro che un nuovo programma per computer dovrebbe essere ampiamente testato nella prima nave effettiva di una nuova classe prima di essere certificato.

Subito dopo la fine di OPEVAL Radm. Carlo K. Bergen prese il sopravvento su OPTEVFOR da Radm. William D. Irvin e Cdr. Chan Swallow prepararono le loro raccomandazioni finali di OPEVAL per il nuovo ammiraglio. Swallow riferì che quando l’NTDS funzionava, funzionava molto bene; un ordine di grandezza più veloce e più accurato dei team di tracciatura manuale. Il sistema non era mai stato sopraffatto durante alcun attacco aereo, tranne quando il programma per computer si era guastato. L'attrezzatura NTDS era stata estremamente affidabile e l'unico vero problema erano stati i programmi che erano riparabili senza grandi spese; il tempo era il principale ingrediente necessario. Propose che al sistema fosse data una "approvazione provvisoria del servizio" in modo che il progetto potesse procedere e che a BUSHIPS fosse permesso di continuare a pulire i programmi prima di consegnarli ai Fleet Computer Programming Centers. 

Radm. Bergen concordò nella lettera di presentazione al rapporto finale OPEVAL che se l'attrezzatura NTDS si fosse comportata così male come i programmi operativi, non avrebbe avuto altra scelta che dare al sistema una valutazione negativa. Il capo delle operazioni navali concordò con la raccomandazione di OPTEVFOR e l'ufficio sponsor dell'OPNAV organizzò un piccolo contingente di valutatori di OPTEVFOR e programmatori di computer Univac per rimanere sulle tre navi di prova di servizio durante il loro successivo dispiegamento nel Pacifico occidentale nel giugno 1962.

Oriskany, King e Mahan tornarono a San Diego nel dicembre 1962 con programmi per computer notevolmente migliorati. Nel marzo 1963 il capo delle operazioni navali approvò il Naval Tactical Data System per l'utilizzo in servizio operativo e designò l'equipaggiamento NTDS come equipaggiamento standard della Marina statunitense. Il presidente John F. Kennedy ispezionò l'installazione NTDS della Oriskany durante una manifestazione della flotta del Pacifico il 6 giugno 1963.

Il costo totale di ricerca e sviluppo (R&S) del progetto fino al test di fine servizio era stato di 136 milioni di dollari, inclusi non solo il costo dell'appaltatore per sviluppare e produrre le attrezzature e i programmi informatici, ma anche tutto il personale militare e i dipendenti pubblici coinvolti e le indennità, le attività di laboratorio e i costi di progettazione e installazione del cantiere navale. Per fare un confronto, il costo della costruzione della USS Enterprise, in dollari del 1961, era di 451,3 milioni di dollari. Del costo totale di R&S NTDS 14,4 milioni di dollari era stato per l'acquisizione e l'installazione delle apparecchiature di prova di servizio nelle tre navi di prova di servizio. L'attrezzatura NTDS di prova di servizio era rimasta in uso a bordo di queste navi con solo piccoli cambiamenti e modifiche sul campo fino alla disattivazione delle navi molti anni dopo. Quindi, oltre a sviluppare un nuovo sistema radicale che ha dato all'U. S. NAVY una spinta quantistica nella capacità tattica, la Marina ha accumulato un investimento di capitale utile a lungo termine di 14,4 milioni di dollari rappresentato dall'equipaggio delle navi di prova di servizio.

Anche se la valutazione operativa non fu completata fino all'aprile 1962, già nel dicembre 1961 OPNAV aveva autorizzato il Bureau of Ships a rilasciare contratti per procedere con la progettazione dettagliata delle apparecchiature di produzione NTDS. Le modifiche di progettazione si sono basate sui risultati di OPEVAL che sono stati immessi in tempo reale ai tre appaltatori delle attrezzature. Poi nel marzo 1962, con il test di servizio ancora in corso, OPNAV ordinò all'Ufficio di iniziare a pianificare l'acquisizione di attrezzature di produzione NTDS per equipaggiare diciassette navi. Sette principali unità combattenti esistenti e dieci fregate lancia missili guidati di nuova costruzione erano stati impegnati a ricevere il nuovo sistema. Non c'era ancora tempo da perdere e non ci sarebbe stata tregua per gli ufficiali del progetto NTDS.

All'inizio del 1964 le prime tre navi di superficie a propulsione nucleare della Marina: USS Enterprise, USS Long Beach e la fregata lanciamissili USS Bainbridge (anch’essa dotata di NTDS) fecero una crociera intorno al mondo senza rifornimento. Quando tornarono alla base, il comandante del gruppo di attività di "Operation Sea Orbit" Radm. Bernardo M. Strean, riportò quanto segue sull’ uso dell’NTDS: 

“Ho avuto il privilegio di utilizzare il Naval Tactical Data System come strumento di comando e controllo. La sua efficacia è tale che considero la valutazione di questo sistema come il più grande passo avanti nella direzione tattica dall'invenzione dei Radar. L'affidabilità delle apparecchiature è di altissimo livello. Il tempo "down" negli ultimi anni viene misurato in minuti invece che in ore o giorni”.

Si vis pacem, para bellum 

(in latino: «se vuoi la pace, prepara la guerra») è una locuzione latina.

Usata soprattutto per affermare che uno dei mezzi più efficaci per assicurare la pace consiste nell'essere armati e in grado di difendersi, possiede anche un significato più profondo che è quello che vede proprio coloro che imparano a combattere come coloro che possono comprendere meglio e apprezzare maggiormente la pace.

L'uso più antico è contenuto probabilmente in un passo delle Leggi di Platone. La formulazione in uso ancora oggi è invece ricavata dalla frase: Igitur qui desiderat pacem, praeparet bellum, letteralmente "Dunque, chi aspira alla pace, prepari la guerra". È una delle frasi memorabili contenute nel prologo del libro III dell'Epitoma rei militaris di Vegezio, opera composta alla fine del IV secolo.

Il concetto è stato espresso anche da Cornelio Nepote (Epaminonda, 5, 4) con la locuzione Paritur pax bello, vale a dire "la pace si ottiene con la guerra", e soprattutto da Cicerone con la celebre frase Si pace frui volumus, bellum gerendum est (Philippicae, VII, 6,19) tratta dalla Settima filippica, che letteralmente significa "Se vogliamo godere della pace, bisogna fare la guerra", che fu una delle frasi che costarono la vita al grande Arpinate nel conflitto con Marco Antonio.

Blog dedicato agli appassionati di DIFESA, 

storia militare, sicurezza e tecnologia. 

La bandiera è un simbolo che ci unisce, non solo come membri 

di un reparto militare 

ma come cittadini e custodi di ideali.

Valori da tramandare e trasmettere, da difendere

senza mai darli per scontati.

E’ desiderio dell’uomo riposare

là dove il mulino del cuore non macini più

pane intriso di lacrime, là dove ancora si può sognare…

…una vita che meriti di esser vissuta.

Ripensare la guerra, e il suo posto

nella cultura politica europea contemporanea,

è il solo modo per non trovarsi di nuovo davanti

a un disegno spezzato

senza nessuna strategia

per poterlo ricostruire su basi più solide e più universali.

Se c’è una cosa che gli ultimi eventi ci stanno insegnando

è che non bisogna arrendersi mai,

che la difesa della propria libertà

ha un costo

ma è il presupposto per perseguire ogni sogno,

ogni speranza, ogni scopo,

che le cose per cui vale la pena di vivere

sono le stesse per cui vale la pena di morire.

Si può scegliere di vivere da servi su questa terra, ma un popolo esiste in quanto libero, 

in quanto capace di autodeterminarsi,

vive finché è capace di lottare per la propria libertà: 

altrimenti cessa di esistere come popolo.

Qualcuno è convinto che coloro che seguono questo blog sono dei semplici guerrafondai! 

Nulla di più errato. 

Quelli che, come noi, conoscono le immense potenzialità distruttive dei moderni armamenti 

sono i primi assertori della "PACE". 

Quelli come noi mettono in campo le più avanzate competenze e conoscenze 

per assicurare il massimo della protezione dei cittadini e dei territori: 

SEMPRE!

….Gli attuali eventi storici ci devono insegnare che, se vuoi vivere in pace, 

devi essere sempre pronto a difendere la tua Libertà….

La difesa è per noi rilevante

poiché essa è la precondizione per la libertà e il benessere sociale.

Dopo alcuni decenni di “pace”,

alcuni si sono abituati a darla per scontata:

una sorta di dono divino e non, 

un bene pagato a carissimo prezzo dopo innumerevoli devastanti conflitti.…

…Vorrei preservare la mia identità,

difendere la mia cultura,

conservare le mie tradizioni.

L’importante non è che accanto a me

ci sia un tripudio di fari,

ma che io faccia la mia parte,

donando quello che ho ricevuto dai miei AVI,

fiamma modesta ma utile a trasmettere speranza

ai popoli che difendono la propria Patria!

Violenza e terrorismo sono il risultato

della mancanza di giustizia tra i popoli.

Per cui l'uomo di pace

si impegna a combattere tutto ciò 

che crea disuguaglianze, divisioni e ingiustizie.

Signore, apri i nostri cuori

affinché siano spezzate le catene

della violenza e dell’odio,

e finalmente il male sia vinto dal bene…

Come i giusti dell’Apocalisse scruto i cieli e sfido l’Altissimo: 

fino a quando, Signore? Quando farai giustizia?

Dischiudi i sette sigilli che impediscono di penetrare il Libro della Vita 

e manda un Angelo a rivelare i progetti eterni, 

a introdurci nella tua pazienza, a istruirci col saggio Qoelet:

“””Vanità delle vanità: tutto è vanità”””.

Tutto…tranne l’amare.

(Fonti: https://svppbellum.blogspot.com/, Web, Google, Ethw, Wikipedia, You Tube)