Joyce_History_of_the_AN_UYK 20_Sep76 Joyce History Of The AN UYK 20 Sep76
Joyce_History_of_the_AN_UYK-20_Sep76 Joyce_History_of_the_AN_UYK-20_Sep76
User Manual: Joyce_History_of_the_AN_UYK-20_Sep76
Open the PDF directly: View PDF 
.
Page Count: 123
| Download | |
| Open PDF In Browser | View PDF |
HISTORY OF THE AN/UYK-20(V) DATA PROCESSING
SYSTEM ACQUISITION AND ITS IMPACT ON
TACTICAL SYSTEMS DEVELOPMENT
Robert Richardson Joyce
NPS-36Jo7609 1
NAVAL POSTGRADUATE SCHOOL
Monterey, California
THESIS
HISTORY OF THE ~~/UYK-20(V) DATA PROCESSING
SYSTEM ACQUISITION Al'lD ITS IMPACT ON
TACTICAL SYS~EMS DEVELOPMENT
Robert Richardson Joyce
September 1976
Thesis Advisors:
S. Jauregui & E. Zabrycki
Approved for public release; distribution unli:nited
Prepared for:
Naval Electronic Systems Command (E4E-107)
Washington, D.C.
20360
T17 hn q 9
· UNCLASSIFIED
SECURITY CL.ASSIFICATION OF THIS
~A.GE
(ft . . Del. Knl.,.d)
READ INSTRUCTIONS
BEFORE COMPLETING FORM
R!PORT DOCUMENTATION PAGE
T.
~E~ORT
NUM.ER
2. GOVT ACCESSION NO
RECI~IENT'S CAT AL.OG NUMSER
1.
NPS-36Jo76091
••
TITL.E ( . . d Subtlt'.)
~£RIOO COVERED
Master's Thesis;
(September 1976)-
HISTORY OF THE AN/UYK-20(V) DATA
PROCESSING SYST&~ ACQUISITION AND
ITS IMPACT ON TACTICAL SYSTEMS
DEVELOPIIIlENT
7.
TV~F' Q.F-"'~PORT •
5.
••
~ERFORMING ORG. REPORT NU.UER
AUTHOR(.)
Robert Richardson Joyce
'0.
~ROGRAM ELEMENT, PROJECT, TASI(
AREA' WORK UNIT NUM.ERS
Naval Postgraduate School
Monterey, California 93940
'I.
12. REPORT OATE
CONTROLL.ING OFFICE NAME AND ADDRESS
Naval Electronic Systems
Washington, D.C. 20360
September 1976
Command(~4E-
107)
13.
~AGES
122
11.
Naval Postgraduate School
Monterey, California 93940
NUM.ER OF
IECURITY CL.ASS. (01 tlu. ~r1J
Unclassified
1S.. DECL.ASSIfI'ICATIONI DOWNGIIUDING
SCHEDUL.E
16.
OISTRI.uTIOH STATEMENT (01
th,.
Report)
Approved for public release; distribution unlimited.
".tree, ..'end 'ft .'00.30,
II d,II., . . , IPo.I RefHWf)
17.
OISTRI_UTIOH STATEMENT (01 tit.
18.
SUPPL. EMENTARV HOTES
't.
KEY WORDS (C«ttlnu. on , ...., •••'de II n.c ••• ~ end ldentl", bJ" IJ'oclr nu.tIJ.,)
Minicomputer
Standard
Data Processing System
Tactical Digital System
In 1972 the Chief of Naval ~aterial perceived a proliferation of small computer types in the Navy inventory. To
stem that prollferstlcn :l 3t3.G.iar·d.~lniccffi;uter W3.S ;:rocured,
to be used in all current and future tactical systems requiring a small digital processor. That standard was designated
the AN/UYK-20(V) Data Processing System. Lack of dedicated
DO I ~~=~1 1A73
(Page 1)
ED'TION 0" I NOV 81 IS O.SOL.ETE
SIN 0102-014- 6601 I
UNCLASSIFIED
SECURITY CLASSIfI'ICATION OF TMIS .. AGE (""'"
D.,••
I'I'erMJ
Unclas s ified
support forced the Chief of Naval Material to tax the users
of the system to obtain the necessary development and operational support funds. Premature delivery of the system to
meet user schedules resulted in highly unreliable equipment
being used in development efforts. A significant adverse impact on user project costs and schedules resulted. Examination of the standard minicomputer acquisition fosters a number of recommendations for future tactical digital processor
acquisitions.
DO
Form
1473
1 Jan 73
SIN 0102-014-6601
Unclassified
ABSTRACT
In
1972
the
Chief of Naval Material perceived a
proliferation of small
inventory.
To
computer
stem
that
types
in
proliferation
minicomputer was procured, to be used in
and
the
Navy
a standard
all
current
future tactical systems requiring a small digital
processor.
That
AN/UY K-20 (V)
dedicated
support
users
standard
Da ta
was
processing
appropriated
funds
designated
System.
for
the
Lack
procurement
of
and
forced the Chief of Naval Material to tax the
of
the
development
system
to
obtain
the
necessary
and operational support funds.
Premature
delivery of the system to meet user schedules resulted
in
highly
unreliable
development efforts.
user
project
equipment
used
in
A significant adverse impact
on
costs
and
Examination of the standard
fosters
a
number
of
being
schedules
minicomputer
recommendations
tactical digital processor acquisitions.
4
resulted.
acquisition
for
future
TABLE OF CONTENTS
..
GLOSSARy.......... •••••••••• •••••••••• •..• •••••••. •.••••
8
ACKNOWLEDGEMENT ••••••••••••••••••••••••...•••••••.•••••.
11
I.
II.
INTRODUCTION ••••••••••••••••••••••.•••••••.•.••••
12
A.
THESIS OBJECTIVE.............................
12
B.
METHODOLOGy ••••••••••••••••••..•••••••.•.••••
13
IDENTIFICATION
OF
THE
NEED
FOR
A
STANDARD
MINICOMPUTER •••••••••••••••••••••••••••••••••••••.••••••
14
A.
DEFINITION OF A MINICOMPUTER.................
16
B.
DEFINITION AND IMPLICATIONS OF A "STANDARDII..
17
C.
THE RANGE OF CAPABILITIES NEEDED •••••••••••••
20
1.
Packaging •• '. • • • •• •• •• •• • •• • • • •• • • •• • .•• .•
21
2.
Reliability and Maintainability ••••••••••
22
3.
Architecture.............................
23
4.
Input/Output ••••••••••••••••••••••.••••.•
25
5•
In t er r up t s. . • • • •• • • • • • • • • • • • • • . • • • • • . • • • •
27
6.
Control/Maintenance Panel ••••••••••••••••
27
7.
Software. • • • • • • •• • • • • •• • .• • • • •• •• •• • •• • .•
28
D.
CAPABILITIES 3F EXISTING NAVY COMPUTERS
TO
MEET
THE SPECIFICATIONS......................................
28
1.
CP-642B .•••••••••••••••••••••••.•••••••••
30
2.
AN/UYK-15(V) •••••••..•••••.•••.•..•••••••
30
3.
CP-890...................................
31
4.
AN/UYK-12(V) ••••••••••••••••••....•••••••
31
III.
DEVELOPMENT AND PRODUCTION HISTORy ••.••.•••••••••
3~
IV.
EVALUATION OF THE SySTEM.........................
54
A.
COMPARISON
PRODUCT
OF
SPECIFICATION
AND
FINAL
•. . .• . . . . . . . . . . . •. •. . . . . . . . . . . . . . . . .
B.
COMPARISON
OF
AN/UYK-20
DPS
WITH
THE
"OFF-THE-SHELF" MINICOMPUrER STATE-OF-THE-ART ••••••...•.
1.
Architecture •••••..•••..•••••••••••.••.•.
5
54
1972
57
57
c.
2.
Main Memory ••••••••••••••••••••••••••••••
60
3.
Instruction S e t . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4•
I n p u t/ 0 u t put. • • • • • • • • • • • • • • • • • • • • • • • • • • • •
63
5.
Interrupt Structure......................
64
6.
Construction.. • • • • • •• • • • • • • • • • • • • • • • • • • ••
64
7.
Support Software.........................
66
IMPACT
OF
AN/UYK-20 DPS ON DEVELOPMENT OF USER
SySTEMS............. •••••••••••••••••••••••••••.••••••••
67
1.
Establishment of AN/UYK-20 as a Standard.
68
2.
Hardware/Firmware Capabilities •••••••••••
70
3.
Availability of Support Software •••••••••
73
4.
Support Software capabilities ••••••••••••
76
5.
Availability of Peripherals ••••••••••••••
77
6.
Hardware and
Software
Reliability
.
" b'l"
Ma~nta~na
~ ~ty ••••••••••••••••••••••••••••••••
0
,7.
of
Dedicated
Appropriated
78
Funds
to
Su pport the AN/UYK -20 D P S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
V.
Lack
• • • • • • • • •
and
SUMMARY, CONCLUSIONS AND RECOMMENDATIONS •••••••••
82
Appendix A:
AN/OYK-7 SYSTEM DESCRIPTION................
88
Appendix B:
STANDARD MINICOMPUTER SPECIFICATIONS •••••••
90
Appendix C:
CP-642B SYSTEM DESCRIPTION.................
92
Appendix D:
AN/OYK-15 (V)
SYSTEM DESCRIPTION............
94
Appendix E:
CP-890 SYSTEM DESCRIPTION ••••••••••••••••••
96
Appendix F:
AN/UYK-12 (V)
98
Appendix G:
DESCRIPTION OF SYSTEM SOFTWARE ••••••••••••• 100
Appendix H:
AN/OYK-20 (1)
Appendix I:
BASIC
SYSTEM DESCRIPTION ••••••••••••
DPS DESCRIPTION •••••••••••••••
AN/UYK-20
HARDWARE
CONFIGURATION
105
AND
OPTIONS. • • • • •• • • • • • • • • • • •• • • • • • • • • • • • • • • • • • • • • • • • • • • • • •• 107
Appendix J:
ROLM 1602 SYSTEK DESCRIPTION...............
109
Appendix K:
HP2100A SYSTEM DESCRIPTION •••••••••••••••••
111
Appendix L:
DEC PDP-ll/45 SYSTEM DESCRIPTION......... ••
113
Appendix M:
VARIAN-73 SYSTEM DESCRIPTION •••••••••••••••
115
LIST OF REFERENCES ••••••••••••••••••••••••••••••••••••••
117
INITIAL DISTRIBUTION LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119
LIST OF FIGURES.........................................
7
6
LIST OF FIGURES
1.
Naval Material Command Organization ••••••••••••••••• 33
2.
AN/UYK-20 (V)
3.
Naval Electronic Systems Command Organization ••••••• 53
System Users ••••••••••••••••••••••••••• 34
7
GLOSSARY
AADC - All Applications Digital Computer
ADD - Alphanumeric Display Device
ADP - Automatic Data Processing
APE - Advanced Production Engineering Model - a
militarized
prototype
CDC - control Data corporation
CMTU - Cartridge Magnetic Tape Unit
CNM - Chief of Naval Material
CNO - Chief of Naval Operations
COMNAVELEX - Commander, Naval Electronic Systems Command
CVTSC - Carrier Tactical Systems Center
DCAS - Defense Contract Administration Service
DEC - Digital Equipment :orporation
DMA - Direct Memory Access
DPS - Data processing System
DRG - Design Review Group
ESA - Externally Specified Addressing
FCDSSA - Fleet Combat Direction Systems Software Activity
FDM - Functional
Demonstration
Model
a
non-militariz~d
prototype
GFCS - Gun Fire Control System
GFE - Government Furnished Equipment
IBM -' International Business Machines Corporation
ILS - Integrated Logistics Support
I/O - Input/Output
IOC - Input/Output Controller
ISADC - Interim Standard Airborne Digital Computer
LSI - Large Scale Integration
MATHPAC - Plug-in
module
of
floating-point,
~rigonometric
and hyperbolic functions implemented in microcode
8
MICROGROWTH - Plug-in module of user specified microprograms
MOS - Metal Oxide Semiconductor
MSI - Medium Scale Integration
MTBF - Mean Time Between Failures
MTTR - Mean Time To Repair
NAFI - Naval Avionics Facility, Indianapolis
NAVAIR - Naval Air Systems Command
NAVELEX - Naval Electronic Systems Command
HAVMACS - Naval Message Address Communications System
NAVHAT - Naval Material :ommand
HAVORD - Naval Ordnance Systems Command
combined with
NAVSHIPS to form NAVSEA
NAVSEA - Naval Sea Systems Command - formed by combining
NAVORD and NAVSHIPS
NAVSEC - Naval Systems Engineering Center
NAVSHIPS - Naval Ships Systems Command
combined with
HAVORD to form NAVSEA
NELC - Naval Electronics Laboratory Center
NESEC - Naval Electronic Systems Engineering Center
NTDS - Naval Tactical Data System
OMB - Office of Management and Budget
O&MN - Operations and Maintenance Navy Appropriation
OPEVAL - Operational Evaluation
OSD - Office of the Secretary of Defense
QA - Quality Assurance
RAM - Random Access Memory
RDT&EN - Research, Development, Test and Evaluation Navy
Appropriation
REiSON - Reconnaissance Electronic Warfare Systems Office
Navy
RFP - Request for Proposals
ROM - Read-Only-Memory
SECDEF - Secretary of Defense
SSA - Source Selection Authority
SSAC - Source Selection Advisory Council
SSEB - Source Selection Evaluation Board
9
TADSO - Tactical
Digital
systems
Office
of
the
Naval
Material Command
TADSTAND - Tactical Digital Standard
TALOS - long-range, surface-to-air missile
TARTAR - short-range, surface-to-air missile
TECHEVAL - Technical Evaluation
TERRIER - intermediate-range, surface-to-air missile
TTL - Transistor-Transistor Logic
UNIVAC - UNIVAC
Defense
Systems
corporation
WCS - writable Control Store
10
Division
of
Sperry-Rand
ACKNOWLEDGEMENT
I wish to thank the many personnel of Navy activities
and
private
contractor
firms who took time out from their
busy schedules to answer my questions.
two
thesis
advisors,
Professor
Edward Zabrycki, who waited
emerge
from my research.
also
to
my
stephen Jauregui and LCDR
patiently
for
the
thesis
to
Finally, special thanks go to the
Commander, Naval Electronic Systems
provided
Thanks
Command
(PME-107)
who
funds to make this thesis possible and to my wife,
Ann, who relieved me of many family obligations
final crunch.
11
juring
the
A.
THESIS OBJECTIVE
In 1972 the Navy began procurement of
computer
which
was
to
be
a
tactical system applications.
was
later
designated
standard
That
the
a
small
digital
minicomputer
standard
AN/UYK-20(V)
for
minicomputer
Data
Processing
System.
The
acquisition
strategy
employed
and
events of the first three years of production
concern
among project
m~nagers
the resulting
caused
great
who were required to use the
standard minicomputer.
At
least
one
user
project
manager
objective look at the standard minicomputer acquisition
necessary
to
prevent
recurrence
of
~n
believed that
those
events
was
which
adversely impacted on the development of tactical systems.
It
is
the
objective
of
this
thesis
to examine the
standard minicomputer acquisition process, to
system
the
in light of user needs and 1972 state-of-the-art, to
identify those
impact
ev~luate
events
which
contributed
to
the
adverse
of the standard minicomputer on development efforts,
and to offer some recommendations for future acquisitions of
standard tactical digital processors.
B.
METHODOLOGY
12
In order to obtain information
general
and
the
AN/UYK-20(V)
about
Data
particular, a literature search
was
minicomputers
Processing
in
System in
conducted.
Pertinent
references are listed at the end of the thesis.
To obtain
a
acquisition
complete
process
and
it
was
objective
then
also
personnel
organization.
in
The
the
standard
following
necessary
pr~ject
personnel at all levels in user
types
picture
of
to
the
contact
organizations
minicomputer
of
and
project
activities
were
contacted to obtain information:
*
checkout,
delivery
systems hardware
*
responsible
Navy field activities
Navy
and
maintenance
assembly,
of
tactical
software.
~nd
laboratories
for
- responsible for certain aspects
of tactical system development and testing.
*
Private contractors
software development
responsible for hardware and
of
tactical
systems
under
contract to Navy project offices.
*
Navy project offices - responsible for management
the
of
acquisition of tactical systems utilizing UYK-20
as a system component.
Additional
AN/UYK-20
information
User's
Group
was
obtained
meetings.
A
by attending two
minimal
amount
laboratory experience was gained on the UYK-20 itself.
13
of
The 1960's saw the
first
of
a
purpose
system.
This event precipitated the introduction of a large
of
shipboard
computer
employment
general
number
digital
successful
computers
manufactured by several different
different
below.
capabilities.
Others
in a shipboard tactical
into
the
Navy
companies
with
inventory
slightly
Some of these computers are "listed
existed,
particularly
in
avionics
applications.
Cognizant
~§~2!!!
!E.21!ca t i211
MK 74
NAVORD
TARTAR Missile System
MK 76
MK 77
MK 86
NAVORD
TERRIER Missile System
NAVORD
TALOS Missile System
NAVORD
Gun Fire Control System
AN/U5Q-17
NAVSEC
NTDS
AN/USQ-20
NAVSEC
NTDS
CP642
NAVSEC
NTDS
CP642A
NAVSEC
NTDS
CP642B
NAVSEC
NTDS
AN/OYK-7
NAVSEC
NTDS
AN/SYA-12
NAFI
Communications
AN/UYK-15 (V)
NAVSEC
General Purpose
CP890
NAVSHIPS
N~vigation
AN/UYK-12 (V)
NAVSBIPS
General Purpose
~Q!llput~£
This proliferation of tactical
processors
created
following tYFes of problems:
*
Small and uneconomical procurement programs.
14
the
*
*
Untenable naterial and logistics support posture.
*
System interface and integration problems.
*
*
Software incompatibility.
Increased scope of personnel training requirements.
Proliferation of support software.
Recognition
of
Naval Operations
(CNM)
to
a
shore
the
problems
prompted
standard general purpose computer for
applications.
Tactical
Digital
In
August
1975.
in
of
CNM
1971,
Offi~e
Systems
1MAT-09Y) to carryout this directive. Figure
position
the Chief of
(eNO) to direct the Chief of Naval Material
develop
shipboard and
created
these
(TADSO)
1 shows
the
TADSO in the NAVMAT organization as of January
The chart illustrates that the Director of TADSO
was
an influential postition, reporting directly to the Vice
Chief of Naval Material.
MAT-09Y has traditionally
been
a
Rear Admiral.
CNM, by
reference
1,
described
the
scope
of
TADSO
efforts:
11(1)
Inter-and intra- platform
compatibility
of
all
Standardization of tactical digital eguipment
and
tactical digital systems and equipment.
(2)
associated software.
(3)
Configuration and interface management of tactical
dig ital equipment and soft ware. "
On 3 November 1971 TADSO published
its
first
Tactical
Digital Standard (TADSTAND 1) [Ref. 2] which established the
AN/UYK-7 processor as the standard
applications
standard
production
systems.
deviation
and
the
high-level
of
high-level
language
operational
TADSTAND
from
CMS-2
1
also
computer
to
be
programs
provided
for
language
employed
for
that
a
shipboard
as
the
in
the
tactical
data
request
for
these standards could be initiated to TADSO
if it was thought to be in the best interests of the Navy to
15
use either another Navy computer or a computer not presently
in the Navy inventory.
In
response to TADSfAND 1 some requests to deviate from
the UYK-7 standard
justification
expensive
were
given
was
($720,000
application.
computer.)
(See
out
received.
that
of
A
this
cost)
for
the Navy standard
It
is
the
purpose
to
or
the
intended
a description of the UYK-7
need
for
a
smaller
Data Processing System
of
this
the
(DPS),
chapter to establish the
terms
"minicompu terl1
and
identify the capabilities needed within the
Navy in a standard minicomputer
whether
significant
m~nicomputer.
meaning and implications of
"standard",
for
identified
computer grew the AN/UYK-20(V)
most
the UYK-7 was too large and
average
App.
The
not
system,
and
to
establish
these capabilities could be met by a small
computer existing in the Navy inventory in 1972.
A.
DEFINITION OF A MINICOMPUTER
Commercially available computers in 1972 formed almost a
continuous
spectrum
Naturally,
it
in
size,
power
and
capabilities.
is is difficult to separate the minicomputer
from larger or smaller types.
The
possibility
of
a
small
computer
capabilities and memory capacity grew with
of
hybrid
and
integrated
1970 medium- and
tha
useful
development
circuits in the mid-1960's.
large-scale
more
with
integration
was
In
introduced,
allowing
even
package.
At the same time these advancements were
hardware
costs
decade.
The
advent
designed
for
use with minicomputers was the final addition
at
capability to be designed into a small
the
rate
of
of an order of magnitude ?er
mini-peripherals
to complete, low-cost mini-systems.
still
true
in
1976,
At that
software was the
such systems.
16
reducing
specifically
time,
predomin~nt
as
was
cost of
C.
weitzman [Ref. 11] defined the minicomputer as an 8-
to 18- bit word size machine with memory size from 1K to 32K
words.
costs
range
minicomputer is
accuracy,
low
operation.s
and
however,
from
generally
speed
no
$4,000
to
$100,000.
catagorized
as
having
for
double-precision
floating-point
The
limited
arithmetic
hardware.
By
1972,
many minicomputers had multiple Input/Ou t put' (I/O)
access features
allowing
and
extensive
implementation of
functions.
A
microprogrammable
instruction
floating-point
central
repertoires
and
processors
with firmware
special
mathmatical
more detailed discussion of the minicomputer
technology of the early 1970's may be found in
Chapter
IV,
section B.
B.
DEFINITION AND IMPLICATIONS OF A "STANDARD"
A "standard" could be defined as a specific entity which
will
be
used
in every application where an entity of that
general description is required.
The contents of the several TADSTANDS published by TADSO
imply the following Navy policy concerning a "standard":
The entity identified as a "standard" will be
all
developing
and
applications except
provided for,
References
future
where
tactical
deviation
digital
is
in
system
specifically
requested and approved.
3 through 9 are the standards promulgated by
TADSO as of May 1976. Tne impact of such standards
system
used
design
will
be
discussed
in
Chapt.
in
user
IV.
The
implications of establishing standards are summarized in the
following paragraphs.
Standardization allows realization of the
large
scale
production.
For example, as of
economies
~ay
AN/UYK-20 Data Processing Systems had been ordered
17
of
1976, 824
and
637
units delivered.
At that time there were 107 programs using
the system.[Fig.2]
the
estimated
At the outset of the UYK-20
production
acquisition
run was in excess of 4500 units.
This volume is over an oeder of magnitude greater
than
one
processor
program
would
acquisition.
realized
require
Clearly,
in
the
an
independent
economies
with such a program.
of
scale
any
would
Although it is impossible to
quantify the actual savings realized by using UYK-20 in
particula.r
be
any
project, the economies of scale are demonstrated
in the volume order prices for
an
AN/UYK-20(V)
DPS
basic
configuration in fiscal year 1974:
Quantity - 50 at $25,966 each
Quantity - 100 at $24,735 each
Quantity - 150 at $24,324 each
It is also interesting tJ note that
the
1976
configuration
order
price
for
a
similar
$25,000 each, approximately the same
as
Fiscal
the
Year
(FY)
is about
FY
74
price
despite inflation.
Standardization
support.
One
realizes
project
cost
manager
savings
in
material
estimated that the cost of
introducing one new part into the Navy Supply System at SPCC
is
about
$1500.
It has also been estimated
th~t
realizes $20,000 to $40,000 per year in Integrated
Support
(ILS)
cost
savings
the Navy
Logistic
through a standardized system
like UYK-20.
standardization
costs.
to
avoids
duplication of suppoct software
A project manager estimated a savings of
$2,000,000
$4,000,000 per year in software maintainance costs for a
project using a standard computer.
Standardization
reduces
the
scope
of
maintenance training. The Chief of Naval Technical
emphasized
this
required
Training
fact in a letter to the Director of TADSO,
pointing out that it was becoming increasingly difficult
fill
technical
traininj
to
billets, and that standardization
18
programs like AN/UYK-7 help alleviate this
It
is
estimated
that
about
problem.(Ref.10]
$409,000 per year savings in
technical training costs is realized through
the
existence
of
training
of UYK-20.
standardization
required
for
reduce
can
the
personnel.
operator
amount
Lack of standardization
may mean that as an operator is transferred from one command
to
another
he
equipment.
must
be
sent
back to school to learn new
such an occurrence has a direct impact on
readiness
and personnel training costs.
fleet
As an example, the
REWSON program faces this problem because some of its
installations
utilize
associated shipboard
DEC
PDP-11
installations
computers
employ
shore
while
the
AN/UYK-20
Data
Processing Systems.
Standardization saves the repetitive
of
procurements of unique systems.
acquisition
costs
These costs include the
recurring costs for ILS, software maintenance, etc. and also
the
one-time
development
costs. As an example, the OYK-20
acquisition required $1.3 million in Research & Development
funding
for
militarization of commercial hardware, support
software, documentation, etc.
Despite
these
strong
standardization,
there
is
standardization
program.
arguments
much
Mr.
in
favor
resistance
Howard
to
Gantzler,
of
any
Deputy
Assistant secretary of Defense (Installations & Logistics),
recognized
that
attitude when he stated at a seminar given
at the Naval Postgraduate School in January 1976,
"Everybody is in favor
of
it
[standardization],
but
nobody wants to adopt someone else'S standards."
Rear
E. B. Fowler, Vice Commander of the Naval
Admiral
Electronics systems COmmand identified another
standardization
in
an
address
to
of
the Naval Postgraduate
School chapter of the IEEE in April 1976.
19
drawback
lIyou have to standardize. You canlt afford
so.
not
to
do
But you must also get a firm grip on the half-life
of the thing you are
thought
at
currently
standardizing...
was
first to be a five year investment. We are
reprocurring,
fifteen years.
and
it
CP-6~2Bls
The
to
seventeen
like
have been
years,
Nimitz, the newest capital
looks
ten
to
[CP-642B computer (UNIVAC
1212). See Chapt. II, Sect. D.]
sixteen
AN/OYK-20
and
ship.
~round
for
we put them on the
This
is
a
systems
engineering problem."
In
that
statement
Admiral Fowler suggests that once a
standard is established, it may be used for many more
than
anticipated
unless
a
firm policy for replacement is
adopted at the
outset.
opposition
standardization
to
Understandably,
components
must
not
the
majo~ity
of
was found by this author in
the technical community, which
standardized
years
systems
desi9n
specifically
using
tailored to the
tasks required.
C.
THE RANGE OF CAPABILITIES NEEDED
In
January
1972,
a
Design
Review
Group
(DRG)
was
convened by TADSO to translate the requirements of the
for
a
Navy
minicomputer system into a specification which could
be used
as
the
significant
to
basis
note
for
that
competitive
the
bidding.
It
intent was not to fill the
entire range of size and power below the UYK-7, but only
fill
the
identified
the outset
the
prediction
of
current and future needs.
success
those
of
OYK-20
depended
needs by the DRG.
the DRG was most important, and it is
the
commands
represented:
Naval
Systems
Command
(AIR-5333F),
20
to
Thus, from
on
accurate
The composition of
interesting
to
note
Ordnance Systems Command
(ORD-532), Naval Ships systems Command (SHIPS-03524),
Air
is
Naval
Naval Ships 3ngineering
center (SEC-6178D and SEC-6172), H. Q.
AAM-4),
Fleet
Combat
Direction
Marine
Corps
(Code
System Support Activities
pacific and Atlantic, and Naval Weapons Laboratory Dahlgren.
The
Naval
Ordnance
Systems
Command
and
systems Command have since been combined
the Naval Ships
into
one
command
designated the Naval Sea Systems Command (NAVSEA).
the commands responsible for systems aevelopment
Thus all
were
well
TADSO
had
represented.
In order to save time and development costs,
conceived
an
"off-the-shelf"
procurement.
important decision, which implied that
procure
a
market-tested
computer
the
That
was
an
intent
was
to
system which would only
need to be militarized.
~nd
Since the computer was to be general purpose
serve a
wide range of diverse applications, a modular building block
approach
was
conceived.
A
basic configuration was to be
specified and plug-in modules
provided
so
priced
so
needed.
that
Add-on modules were
the
The following
user
the
processo~
could increase the size and power of the
individual needs.
that
to
be
user
up to his
individually
only paid for the capability ne
p~ragraphs
summarize
the
range
of
capabilities which TADSO and the DRG foresaw would be needed
to meet Navy systems requirements of
years into the
The
computer
would
electronic
be
the
more
required
shipboard,
systems.
airborne applications of
required
and
about
the
This
groundbased,
decision
computer,
stringent
and
to meet military
which
the
volume
of
production.
would
expensive
The
decision was the intention to produce
shipboard
computer
to
All-Applications Digital
be
an
eventually
Computer
21
(AADC)
and
precluded
have
MIL-E-5400
specification, but would have expanded the applications
thus
five
future~
specification MIL-E-16400 for
submarine
1972
and
reason behind that
interim
replaced
which
standard
by
was
the
then
"
under development by the Naval Air Systems Command
(NAVAIR).
The AADC never materialized, and as of 1975 the AADC project
had
been redirected to produce an Interim Standard Airborne
Digital Computer (ISADC).
Out of the ISADC project came the
AN/AYK-14 computer in 1976.
The computer was to be packaged in one enclosure
of
maximum dimensions 26 inches high, 24 inches deep, and width
suitable for mounting in a standard 19-inch
power
consum~tion
following
units
were
other hardware changes
of
8K-words
Maximum
was to be one kilowatt.
To achieve the desired
the
rack.
per
building
to
capability,
be strictly plug-in with no
necessary~to
module,
block
install: memory
modules
I/O channels in groups of two if
serial and in groups of four if parallel,
real-time
clock,
general registers, and microprogrammable control memory.
In accordance with MIL-E-16400, modular construction
was specified.
All assemblies with a cost of $200
would be throw-away components.
more
than
be
repairable modules.
would
be
less
only those assemblies where
it was. determined that repair would be
throw-away/replacement
or
would
cost-effective
designated
It was further specified
that
as
repairs
performed by the contractor, a factor which had a
later impact on the repairable turn-around time.
The
maximum
configuration
of
have a Mean Time Between Failures (MTBF)
Mean
Time to Repair (MTTR)
to Repair of 12D minutes.
which
had
been
the computer was to
of
hours,
a
of 15 minutes and a Maximum Time
The MTBF specified was
used
on
previous
military
specifications.
As far as the author of this
determine,
basis
the
2000
for
a
figure
computer
thesis
could
citing the 2000 hour figure was
historical rather than the result of calculation.
The
designed
modules
to
computer
was
facilitate
through
to be logically and electrically
the
diagnostic
isolation
programming.
22
of
malfunctioning
The
diagnostic
program was to isolate 93% of recurring
(non-intermittent)
active logic element failures to not more than three printed
circuit card modules.
3.
Architectur~
The
computer
was
to
employ
third
generation
technology with the use of medium-scale integration.
Perhaps
requirement
the
most
th~t
was
microprogram mabIe.
capability
was
architectucal
the
processor
was
rationale
for
requiring
possibility
of
The
the
significant
a
to
more
the
macro-instruction
set
contents of control memory.
therefore
for
at
least
by
or
add
modifying
the
requirement
was
simply
An additional
500 words
this
powerful
macro-instruction set and the flexibility to modify
to
be
(16-bit) of user growth
capacity in the control memory.
Other
required
length at least 16-bits including
parity,
random
attributes were: word
architecture
access
sign
but
not
non-volatile memory with a separate
high speed memory desireaole but not cequired,
read-restore
cycle
including
time
less
than
1.2
main
memory
microseconds,
asynchronous timing with at least one level of memory
fetch
instruction overlap to cceate an effective memory cycle time
of less than one
8K-words
microsec~nd,
expandable
addressable)
in
to
8K-word
minimum
at
storage
least
capacity
65K-words
increments,
a
of
(directly
minimum
of
four
general registers expandable to sixteen.
It was significant that no requirement was made
a
capability
to. expand
memory capacity beyond 65K-words.
Also significant was the absence of requirements for
checking,
memory
write
for
protection
parity
or executive mode with
privileged instructions.
The question of parity checking was a much discussed
attribute.
hardware
Those
errors,
in
favor
cited
particularly
attempting to debug software.
23
in
the
need
to
identify
memory
accesses,
when
In addition,
arguments
were
made
in
favor
of
identifying
operational programs to prevent
information,
misrouting
of
The
arguments
when
miscalculations
data
handling systems), mishandling
etc.
errors
logic)
of
classified
against
parity
digital
detection
equipment
since
had
this
little
and
affect~ng
whole
than
blocks
to
the
about
10%
It was argued
value
attribute
detect single bit failures rather
failures
target
information,
pointed
and extra memory bits per word.
that parity error
of
(particularly in message
significant cost in real estate (extra bits
more
executing
in
was
modern
designed to
catastrophic
logic
of addresses; the latter
type of failure characterized the type of failure most often
encountered
in
modern
equipment.
Operationally
it
was
thought undesireable to interrupt processing of critical
targ'et-~data to process pari ty errors in a comba t si tuation.
In
the
end
the
considerations
~emory
Although the question of
to the same extent as
cost
me~ory
prevailed.
protection was not discussed
parity checking,
similar
cost
and real estate savings could be realized by not including a
hardware memory protection feature in the design.
The
single
macro-instruction
and
double
multiplication~
word
stop
would
controversial attribute.
byte
operations
addition,
were
specified
a
non-dual-state
be
pLovided for
subtraction,
non-privileged,
jumps,
machine
making
the
it a
Only load, add, subtract and store
specified,
instructions were required.
operations
specified
division, logical operations, shifts,
and a programmable stop. In
programmable
set
It
and
is
no bit manipulation
significant
that
all
were arithmetic (recognizing the most
significant bit of a word as the sign)
so that no capability
for full 16-bit data manipUlation was required.
Instruction
execution times were specified as follows:
!~tr1!£ti.QQ
Regist~£=~2=Regi§i~£
~~mory-to-Register
Add,Subtract
1.2 microseconds
2.2 microseconds
Load,Store
N/A
2.2 microseconds
24
Multiply
9 microseconds
11 . microseconds
Divide
20 microseconds
22 microseconds
Shift(16-bit)
1 microseconds
N/!
The computer was to be capable of executing
500,000
instructions
per
second
not
for
less
the
than
following
distribution of memory-to-register instructions:
!!l2~r.~~ion !.ll~
Pe~:!:
Add, or equivalent
34
Logical or masking
34
Branch (Jump)
18
Multiply
5
Divide
1
Miscellaneous
Qt Hi!
~
100
The
choice
between
tvo's-complement arithmetic
despite
the
fact
that
was
most
one's-complement machines.
one's-complement
left
to
the
or
contractor,
previous Navy computers were
That decision
would
impact
on
future software compatibility and system integration.
The DRG specified
addressing,
indexing,
and
at
least
relative
single-level
indirect
addressing to a fixed
base which could be program modified.
A hardware (or firmware)
(bootstrap) was to be provided.
bootstrap
would
capability to
The
intent
lo~d
was
programs
that
the
be a plug-in option wherein the user could
obtain bootstrap capability for
the
particular
peripheral
and channel desired.
It
was intended that the 110 structure be such that
the I/O channels access memory through a second memory port,
eliminating
interference
with
processor operations.
requirement meant that an arithmetic unit,
25
data
This
registers,
etc.
were
required
for
each
channel
to
perform buffer
control functions, address calculations, interrupt control,
etc. In order to save on real estate, the channels (a total
of sixteen)
were to be grouped in
than
channels
four
serial mode.
control
increments
of
not
more
for parallel mode, or two channels for
Only one aider and set of data registers
plus
circuitry would be required per four channel group.
This requirement, while saving
several
significant
circuitry
restrictions
and
on
cost
placed
possible
I/O
configurations:
*
For
parallel
mode
transfe~,
data
each four channel
group was constrained to one type of interface.
*
Serial
and
parallel
channels
could
not
be mixed
within a group.
*
Double word (32-bit)
transfers, such as necessary for
interfacing with UYK-7,
from
would
require
one
channel
each of two adjacent groups, thus forcing eight
channels to be of the same type of interface.
requirement
stems
from
the
need
for
(This
separate
processing circuitry for the upper and lower
16-bits
of 32-hit parallel transfers.)
Direct
Memory
Access
(DMA)
was
desired
but not
required. Thus, a provision for direct memory
ac~ess
by
high
a disk)
could
speed
mass
storage
device
(such
as
somewhat compensate for the lack of provision for
a
expansion
of main memory beyond 65K-words.
Various types of interfaces were to be
options:
*
Parallel (MIL-STD-1397)
• NTDS Past (-3 volts)
• NTDS Slow (-15 volts)
• ANEW (+3.5 volts)
26
provided
as
.• Serial
synchronous
• RS-232C
speeds
• MIL-STD-188C
speeds
and
asynchronous
normal
synchronous and asynchronous normal
• MIL-STD-1397 (NTDS) 32-bit serial
sp~ed
• MIL-STD-188C high
(up to one
million
bits
per second)
All
parallel
types
were
to
provide
full duplex
operation in a normal data transfer (16- or 32-bit) mode, an
intercomputer mode, or an externally specified address
mode.
Asynchronous
serial
channels
were
to
(ESA)
provide
full-duplex operation at bit rates of 75, 150, 300, 600, and
1200 bits per second (baud)
with 2400, 4800
and
9600
baud
desir eab Ie.
A
priority
structure
of
interrupts was specified
with the following types of interrupts required (in order of
priority,
highest
to
lowest):
power
failure protection,
instruction fault, real-time clock overflow,
inte~nal
clock
interrupt, intercomputer time-out, external device interrupt
and I/O interrupts.
Despite
specification
simultaneously
the
usefulness
required
be
only
of nesting interrupts, the
that
nested.
interrupts
occuring
Furthermore, the specification
required that all interrupts of lower priority
be
disabled
while processing an interrupt.
The
specification
required
that
a
control/maintenance panel be provided that could be, but was
not required to be separate from the computer.
Nor~al
panel
displays, indicators and controls were to be provided (these
were
specified
in detail).
significantly, the panel could
27
be configured to display only one register
at
a
time,
or
more, as the manufacturer wished.
It
is significant that the question of software was
~pecification
not addressed in the
the
Request-for-Proposals
generated by the DRG.
(RFP)
only
an
assembler
In
was
required.
Ap~endix
B
summarizes
the
specifications for the
standard minicomputer system as determined by TADSO and
the
DRG.
D.
CAPABILITIES OF EXISrING NAVY COMPUTERS TO MEET THE
SPECI FIC ATIO NS
It is valid to investigate whether the perceived present
and
future needs of the Navy for a minicomputer, as defined
by the DRG, could be met
small
computer
an
by
existing
general
purpose
in the Navy inventory. If so, this computer
could be designated a standard just as the AN/OYK-7 had been
a year before.
The sections below discuss
some
of
likely
those
to
Appendices
Navy
fill
C
the
the
pertinent
features
of
computers
which woqld have been most
need
a
through
F
for
summarize
standard
minicomputer.
the characteristics of
those computers.
Comparing
the
existing
specification
with
the
standard minicomputer specification
computers
reveals
that
none
met
wi~h
the
completely, although two were good candidates
certain
microprogramming
exceptions.
The
AN/OYK-15 (V)
lacked
and relative addressing, but was otherwise
acceptable. It had additional features such as memory parity
checking,
memory
write
protection and multi-ported memory
banks to further recommend it. The AN/OYK-12(V)
microprogramming
and
also
lacked
did not meet all required instruction
28
execution speeds or memory capacity, but
had
an
extensive
support software package to recommend it.
The existence of UYK-12 and UYK-15 brings
the
decision
to specify a microprogrammed processor under close scrutiny.
As discussed in the
previous
microprogrammability
section,
the
advantages
of
are an expanded macro-instruction set,
ability to implement high speed floating-point, mathematical
and
trigonometric
add
high-speed
processing.
functions
user
The
as needed, and flexibility to
macros
to
disadvantages
enclosure (1) of a
letter
to
facilitate
were
best
TADSO
real-time
summarized
from
the
/Naval
in
Air
Systems Command (AIR-5333),
"The
latter
deficiency
micro-programmability],
feasible,
leads
configuration
that
a
to
been demonstrated and
qualified vendors.
NAVAIR's
to
the
unusual
potential
being
problems.
modifications
will
and
software
NAVAIR
believes
serve
only
to
eliminate
13]
about configuration management refer
user
set.
to
for
technically
hardware
capability
It
must
be
configuration control can be maintained
all
requirement
for micro-programmability has not
lie Ref.
comments
macro-instruction
while
management
requirement
(the
the
to
modify
pointed
by
the
out
that
requiring
that
macro-instruction set he upward
compatible with the basic set.
The
foregoing
comments
not-withstanding,
microprogrammability remained a requirement, and none of the
existing
Navy computers could meet the specification. It is
also interesting to note that a majority of the computers in
the
Navy
inventory were manufactured by the UNIVAC Defense
Systems Division of Sperry Rand Corporation
Rolm
and
Corporation manufactured AN/UYK-12(V)
there
minicomputer
were
others.
specification
Comparison
with
29
the
(UNIVAC).
Th9
is an exception,
of
UNIVAC
the
standard
manufactured
computers reveals that the DRG was
the
UNIVAC
design
specification.
which
was
For
not
philosophy
instance,
in
probably
in
the
accordance
influenced
producing
UYK-12
I/O
their
structure,
with the specification, was
simply another method of accomplishing the same end.
the
opinion
of
It
a
is
this author that the use in the RFP of the
detailed technical specification produced by the DRG
than
by
performance
specification,
rather
probably excluded some
candidate minicomputers from the competition.
This computer, a militarized version of
1212,
was
an
upward
compatible
U5Q-20/CP-642/CP-642A family.
in
the
Navy
heavy
quantities
of
complex
I/O comunication was required.
can
minicomputer
in
be
seen
that
capabilities,
unit than desired.
second
to
the
Tactical Data System (NTDS), its architecture
to App. C it
its
follow-on
UNIVAC
Designed specifically for use
optimized processing of large
where
the
although
it
data
with reference
CP-6~2B
was
was a physically larger
Its size and slow speed are a result
generation
a
architecture.
Lack
of
of
serial I/O
capability, lack of interrupts and limited memory were other
factors
which
made this computer unacceptable.
Appendix C
profiles the CP-642B.
2.
ANLQYK-15J!l
The shortcomings of
UNIVAC
1616,
have
been
this
computer,
previously
a
militarized
discussed. Additional
desireable features incorporated in the AN/UYK-15(V) include
optional
additional
parity checking
memory.
and
This
multiplexer
general
which
a
priority
latter
feature
provides
16K-word memory bank.
registers
up
to
structured,
64, memory
multi-ported
incorporates
four
access
ports
a
priority
for
each
Combined with separate IOC's for each
group of four I/O channels, this feature allows simultaneous
access
to
different
memory
banks
30
by the CPU and various
IOC's, thus improving throughput.
Appendix D
profiles
the
1289,
this
AN/UYK- 15 (V) •
Commercially
designated
computer was designed for
Although
of
second
reasonable speed.
standard
(program
and
protection,
hardware.
4.
navigation
generation
system
applications.
technology,
specification,
required,
executivet,
memory
it
featured
but
but
desireable:
programmable
parity
it
checking,
had
dual
memory
and
some
states
read/write
floating-point
Appendix E profiles the CP-890.
ANLQYK-12
That
tit
was designed from the ground up as a
computer
militarized Data General NOVA with
I/O
UNIVAC
It failed in a number of ways to meet the
minicomputer
capabilities not
the
structure
added.
a
Designated
military
the
application
1601, it was
Rolm
completely upward compatible with the NOVA
and
could
thus
run all software developed for that popular minicomputer.
The I/O structure was basically
with
the
facility
to
a
single
bus
I/O
address 61 different devices.
Each
device could independently interrupt the processor according
to
a
predetermined
priority.
configured with up to 16 110
The
computer
interfaces
and
could
be
backpanel
15
connectors.
package
extensive
An
well-documented
support
software
of
well-tested
was available.
were cross-assemblers and cross-compilers so
for
UYK-15
the
machine.
that
and
Included
programs
could be assembled or compiled on a larger
That feature recognized the constraints on using a
minicomputer for program development.
In this chapter the meaning and
standard
minicomputer
requirements
discussed,
for
and
a
it
have
been
minicomputer
was
concluded
31
implications
established.
system
that
in
The
1972
of
a
Navy
were
no existing small
computer
in
requirements.
the
In
Navy
Chapt.
inventory
III
could
meet
the history of the standard
minicomputer acquisition project will be discussed.
32
those
Public Aff OOD
•
•
-
Chief of
Naval
:v1a terial
(MAT-OO)
•
Dir. R &
~-1
OaR
Vice Chief
of Naval
Ma terial
(MAT-09 )
f---
Legal Off. 0ge
Spec. Asst.09E
•
•
•
TADSO
09Y
DE:?UTIES
Figure 1 -
NAVAL MATERIAL COMMAND ORGANIZATION
33
Lv
~
ADSCS
AEGIS
AS 39,40
AUSTRALIA
CANADA
CATC
COSON
COSSO
CFP
CLARINET MIRACLE
CLASSIC CALIPER
CLASSIC OUTRIGGER
CMSFT9
COAST GUARD
CSOS
CUDIXS
CVA-MSOP
CVAN 68/69
CUTSC
OASS
ESMDE
ESMSP
EWDR
EW-SUITE
FCDSSACT
GERMANY
27. HLT.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
43.
49.
50.
51.
52.
53.
54.
55.
HSDS
HWLS
ICAD
IOIC
IRR
ISCS
ISABPS
ITALY
JAPAN
LFAPLUS
LAMPS
MAGIS
MATCHLS
MCDV
MK48
MK68
MK86
MK541
NAVMACS
NCSL-CRY
NCSL-NIW
NCSL-SMS
NCSL-CME
NIPS
NOLTEST
NRLTEST
NSRDC-IBS
NSRDC-SSBCS
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
NSWSES
NTDS
KITTYHAWK
RANGER
LONGBEACH
NSWC DAHLGREN
OSP
OUTBOARD
OW75
PAIR
PF
POTS
PELSS
PMO 403
SAMAC
SCAMP
SOMS
SEAFARER
SEA NYMPH
SPS-58 FCIG
SPS-48C
SPS-52B
SH/HLS
SIAS
SLO-17
SOSUS
SORXX
SOS-26
Figure 2 - AN/UYK-20(V) SYSTEM USERS
81.
. 82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
SRD-19
SSAD
SSCCS
SSCDS
SSESKIT
SSIXS
SSN-688CL
SM2
SSO-72
SSSMP
SSTIXS
SSMA
STRATNAV
SURTASS
SURVSAT
SYS 1
TACINTEL
TAOC
TCDBM
TEMPEST
TPN-22
TPO-27
TPX-42
TRIDENT
VERDIN
WLR-8 (V)
WSC-2
The events leading to the publication of a specification
for a
standard
previous
minicomputer
chapter.
have
been
detailed' in
This chapter will relate the history of
the AN/UYK-20(V) acquisition from specification to
1976.
Much
of
the
the
information
mid-year
on events leading to the
contract award in May 1973 was derived from a research paper
by
Captain J. S. Sansone (Ref. 14], who was the Project and
contracting
officer
for
the
standard
minicomputer
procurement.
In June
standard
1972
the
preliminary
for
the
minicomputer was distributed for final review.
that time TADSO was well
TADSTANDS
on
acquisition
a
established
variety
strategy
commercial
of
and
subjects.
called
for
had
By
issued
six
2-8 ]
The
[Refs.
militarization
of
a
system requiring a minimum of system development
to meet the DRG specification.
$1.8
specification
million
It was estimated that
about
in Research, Development, Test and Evaluation
Navy (RDT&EN) appropriated funds would be necessary to cover
costs
of design and development, militarization, Government
Furnished Equipment
testing,
plans,
TEMPEST
development
(GFE),
environmental
testing,
of
Integrated
technical
and
celiability
Logisti~s
manuals,
Support
other
data
requirements, and support software development.
In late
Research,
August
1972
Development,
existance of the standard
the
need
for
proliferation
inventory.
of
prompt
CNM
advised
eNO's
Test and Evaluation (OP-098)
minicomputer
approval
commercial
to
Year
preclude
minicomputers
in
the
of
of the
specification,
and
further
Navy
OP-098 was also informed that the necessary $1.8
million in RDT&EN funds could be obtained
Fiscal
Director
by
reprogramming
1973 funds from sub-allocations to the various
35
projects who would use the standard minicomputer.
of
amount
million,
prior
(SECDEF)
and
be
reprogrammed
approval
the
committees of
could
to
funds
from
Armed
Congress
the
did
was· not
exceed $2
not
Secretary
Services
since the
of
Defense
and
Appropriati9ns
required.
Reprogramming
be carried out within the Department of the Navy with
the approval of the budget activity sponsor (OP-098).
was
sufficient justification for this plan -since the user's
funds would
anyway.
have
been
used
for
the
plan
raised potential user project
However,
manager objections.
development
of
First,
the
a
computer
control
over
office.
schedule.
all
design
and
minicomputer would be taken out of the
grea~
Second,
procurement
the
hands of the project managers and vested in
of
There
an
independent
risks were involved in the delivery
Third, ELEX-S60 could not have the specific needs
the
user
projects
at
heart when making tradeoff
decisions regarding cost, schedule and performance.
By
1972 the approval of CNO was assured.
mid-September
CNM taskod the Commander, Naval Electronic
(CCMNAVELEX)
COMNA1ELEX
to
handle
created
Acquisition
the
a
procurement.
(ELEX-OS)
The division was designated the
Equipment
Division
Command
In
response,
his
Material
to carry out this task.
Standard
(ELEX-S60). [Fig.
pr0curement plan specified a
procurement
~ithin
division
Directorate
Systems
Tactical
3]
formally
Digital
At this time the
advertised
two-step
based on the DRG specification and resulting in
a firm-fixed-price contract.
In
October
1972,
received a request from
(GFCS)
project
in
response
the
Mk68
to
TADSTAND
Gunfire
Control
1, TADSO
System
to deviate from the UYK-7 standard in favor
of a commercial minicomputer.
The request was
subsequently
denied, and the requirements of the Mk68 GFCS project became
the
first
systems.
firm
requirements
for
The constraints of the
standard
Mk6~
GFCS project schedule
were thus imposed on the standard minicomputer
The
new
minicomputer
procurement.
schedule constraints forced abandonment of the
36
formal two-step procurement in favor of an accelerated plan.
The
plan
called
paragraphs 2304 (a)
states
Code.
for
a
negotiated
(2) and (10)
Those
procurement in lieu
of Title 10 of
regulations
of
a
procurement
allowed
under
the
United
a
negotiated
formally-advertised,
sealed-bid
competition in cases where the exigency would not permit the
delay
incident
impractical
to
to
formal
advertising
obtain competition.
and
when
it
was
Significant milestones
adopted were:
*
Issuance
of
the
Request
for
Proposals
(RPP) by 1
December 1972
*
Award of the contract by 22 Pebruary 1973
*
Delivery of the first Functional Demonstration Models
(FDM - non-militarized prototype)
30 days after award
of contract
*
*
Commencement of testing by 22 September 1973
Delivery of the first Advanced Production Engineering
Models
(APE
militarized
prototype)
nine months
after award of contract
*
Delivery of the first production units by May 1974
Technical
evaluation
(rECHEVAL)
would be completed in the
contractor's plant and operational evaluation (OPEVAL)
be
would
completed concurrently with the OPEVAL of the first user
system.
A firm-fixed-price contract was
anticipated.
The
accelerated plan precluded detailed analysis of proposals to
determine which contractor offered the best performance
price.
It
among those
Thus,
little
was
found
per
planned to simply select the lowest bidder
responsive
improvement
on
to
the
the
DRG
specification.
DRG design was possible
through the acquisition process.
On
as
the
15 November 1972, CNM declared the DRG specification
Navy
standard
minicomputer
37
specification
and
constrained all projects planning or procuring minicomputers
to use the standard as Government Furnished Equipment unless
approval was obtained from TADSO to deviate. [Ref.
15] Three
projects in addition to Mk68 GFCS were specifically directed
to
switch to the standard minicomputer for their production
phase: the SPS-48 Radar Improvement Program, which had
through
development
with
the
AN/UYK-15 (V)
gone
computer; the
Carrier Tactical Support center project (CVTSC),
which
had
gone through development with the IBM SP-1 computer, and the
Satellite Communications program (SATCOM),
which
had
gone
through development with the Rolm Corporation 1602 computer.
This directive was probably
were
then
forced
to
premature
include
since
all
projects
in their production plans a
component that was only a piece of paper with
no
proposals
in hand to guarantee the feasibility of meeting the proposed
schedule milestones.
The
establishment
of
resulted in identification
minicomputer.
As
of
the
of
specification as a standard
more
projects
mid-November
requiring
1972
requirements for some 314 production units
a
estimated
(through
Fiscal
I
Year
1974)
had
been
expected to change,
ELEX-560
contract.
identified.
and
delivery
Since
dates
this figure was
were
not
known,
proposed an Indefinite Delivery, Requirements type
Competition would be based on unit price per
lot
quantity for a specified system configuration plus prices of
certain add-on modules.
By mid-November 1972, 25 firms
had
indicated a desire to submit proposals and none were thought
to be unresponsive.
A fully competitive procurement
seemed
assured.
The RFP released on 1 December 1972 cited the milestones
previously
listed
and
a
three year production run.
year's production was an option to be priced
that
the
ccntractor
Each
separately
so
could protect himself from inflation.
The RFP contained estimated production requirements for each
year
to
protect
the
contractor
from
bidding on unknown production quantities.
38
the
high risks of
Production
funds
would
be
obtained directly from the users at the time they
~he
placed orders under the annual Requirements contracts.
RFP
also
specified
technical
data
to
a
government option for rights to the
provide
for
a
competitive
follow-on
procurement.
At this point some comments should
acquisition
strategy.'
First,
be
be
price.
the
without it, there
little to choose from as far as system design and
Second, the
precluded
opting
reliability
desire
for
acquisition cost,
select
the
bidde~
lowest
a better design at a slightly higher
thus
and
to
achieving
possibly
better
performance
and
a lower overall life-cycle cost.
Third, uqless later funding for
project
about
a great deal of the success
hinged on obtaining adequate competition.
would
made
the
standard
minicomputer
forthcoming from Operations & Maintenance Navy
was
(O&MN) appropriated funds, the users would bear the costs of
support
software
maintenance
and
enhancements,
system
improvements, maintenance of documentation and other support
costs.
This was a point that worried user project managers.
Put simply, if the orders stopped the
funding
would
stop,
and the system would no longer be supported.
By the end of December 1972 the estimated award date had
slipped
Those
to
1
March
changes
because
1973
resulted
from
of changes to the RFP.
substitution
of
the
CVTSC
project requirements for the Mk68 GFCS requirements when the
latter project's funds were cut.
also
growing
restrictive,
consensus
time
there
were
complaints from interested companies that the
RFP closing date was too soon,
unrealistic.
At that
and
the
the
specification
delivery
Because of these
that
the
date
points,
specification
plus
favored
for
the
one
was
too
FDM's
was
unspoken
company's
design philosophy, about 19 of the original 25 interested
firms declined to submit proposals.
Included in these 19
were
IBM
Corporation
corporation,
Rolm
corporation,
control
Data
(CDC), and Digital Equipment corporation
(DEC).
The competition was rapidly vanishing.
39
The
options
open
the
to
Navy
at this point were as
follows:
*
Maintain the schedule despite the high probability of
a sole-source procurement.
*
Slip
user
project
schedules in order to extend the
proposal due date and gain more competition.
*
Cancel
the
RPP and restructure the procurement as a
development effort.
The decision was to slip the closing
proposals
to
for
receipt
of
2 April 1973 and extend the date for delivery
of FDM's to 120 days after date
schedule
date
might
not
meet
of
contract.
Since
this
some potential user schedules, a
risk of losing some firm requirements had been accepted.
prot~sts
During the month of February 1973 two formal
the RFP were filed with
(GAO) •
The
first,
the
from
Government
Control
Data
satisfied by the extension of the due
The
second,
from
Accounting
for
to
meet
UNIVAC, objected to the extension on the
the
original
dates.
An
that
that
effort
and
important point
brought out in this latter protest was that no
computer
was
proposals.
grounds that the company had spent considerable
funds
Office
Corporation,
date
on
firm
had
a
would meet the specification completely, and
substantial
design
necessary in all cases.
violation of procurement
and
~AO
development
effort
were
subsequently determined that no
law
had
occurred,
and
UNIVAC's
protest was denied.
Although not required for
estimated
dollar
value
a
procureme~t
Source
designated.
Selection
The
SSEB
such
low
($1.8 million), a Source selection
Authority (SSA), Source Selection Advisory
and
of
Evaluation
consisted
Council
Board
of
the
(SSAC),
(SSEB)
DRG
~ere
plus
representatives of NAVELEX, the Marine Corps and TADSO.
The
SSAC consisted of representatives of NAVELEX and rADSO
with
40
expertise
in
management
support, etc.
systems,
cost analysis, logistic
The 5SA was COMNAVELEX with
the
advice
and
consel:lt of CNM.
On 2 April 1973 proposals
CDC,
General
Electric and Raytheon.
firms
to
O~IVAC,
from
The S5EB proceeded to
~!i~2Y! knQ~lg~~
evaluate the proposals
all
were -received
£1
Eri£g~
and found
be responsive to the DRG specification.
The
S5AC determined that adequate price competition existed.
A
pre-award survey was conducted at each plant during the week
of 16 to 20 April 1973.
technically
and
All
offerers
financially
were
found
to
responsible and responsive in
accordance with Armed Services Procurement Regulation
1-903.
contract
on 27
April
plus
(ASPR)
award was made to the low bidder, UNtVAC,
1973.
requirements
be
The
an
contract
assembler
included
all
hardware
for a firm-fixed-price of
$673,000.
Soon
after
contract
award,
additional support software in
were
identified.
user
addition
requirements
to
the
second,
designated
1974.(App.
G]
I,
was
Level
NAVELEX
time to develop two
assembler
To meet this need, sole-source contracts
were let to UNIVAC for two self-hosted systems.
designated 'Level
for
The
first,
released
in November 1973.
II,
released
was
in
J
The
anllary
also contracted with UNIVAC at that
other
support
software
packages:
a
standard real-time executive later designated SDEX-20, which
was to provide users with basic software modules upon
to
which
build their operational programs; and a compiler for the
Navy
standard
generate
high-level
machine
code
for
language
the
(CMS-2),
OYK-20.
which
would
This high-level
language for the UYK-20 was designated CMS-2M and was to
a
subset of the CMS-2 language.
be
These additional contracts
were funded from the balance remaining of $1.3 million
RDT&EN funds reprogrammed for the UYK- 20 acquisition.
in
In May 1973 TADSO revised 'rADSTAND 1 to designa te the
UYK-20 as the Navy standard digital processor for those
applications requiring a minicomputer. (Ref. 3] As expected,
41
this action generated a few requests for deviation from that
standard.
Radio
Most were turned down.
Room (IRR)
The Submarine
Integrated
project, which was developing with the CDC
MPP computer and the AN/UYK-15 (V) , had a request to
denied
on
the
basis that the UYK-20 was upward compatible
with the UYK-15.
granted.
due to
The
size
deviate
Very
few
requests
for
deviation
were
VERDIN retrofit project was granted a waiver
problems
in
retrofitting
equipment
into
a
submarine, and the riecessity for compatibility with existing
equipments.
since
The SEA SCOUT
two
systems
were
AN/UYK-12 (V) , urgent
systems,
DEC
granted
already
requirements
a
deployed
existed
waiver
with
for
four
The BULLSEYE project was granted a waiver to
PDP-11
processor.
PDp·l1
was
the
more
and no more than a total of six systems were to be
acquired.
the
project
computer
as
Justification
was
currently
its
for
in
shore-site
that
use
at
waiver
use
cryptologic
was
that
the
shore sites, associated
engineers and support systems were available, and
shipboard
use was not anticipated.
On 27 March 1974 the UYK-20 received
A
major
milestone
in
any
service
program, this event also had a
profound impact on the funding of the project.
approval
was
Kaintenance
Navy
(O&MN)
the project, NAVELEX was
system
for
system
was
contract
allowed
which
Supplies
attached.
1155,
by
or
a
Services)
in
to
the
to
Operations
of
the
the following manner.
The
users
Indefinite
Delivery
users to purchase systems and
a
DD
ELEX-560
Form
with
1155
an
(Order
order
The user's funds were obligated via the
DD
for
form
Form
and the order form provided a detailed description of
the equipment and software requested.
funds
assess
Requirements,
transmitting
Since no
funds were available to support
forced
suppoct
UYK-20 contract
components
Once service
received, the activities of ELEX-560 could no
longer be supported with RDT&EN funds.
&
approval.
The
according to a published price list.
prices included a surcharge over the
42
fixed
user
obligated
These published
prices
in
the
contract;
it
was
this
surcharge
which
was used to fund
ELEX-560 support activities.
Occasionally
users
would require new system components
(e.g. bootstraps, I/O interfaces, and/or peripheral
software
routines
for
a
unique
handler
peripheral
device).
Naturally the requesting user had to provide funds
development
of
his
unique
requirement.
accomplished by submitting a DD Form 1149
for
This
the
was
(Requisition
and
Invoice/Shipping Document) to ELEX-560 with a description of
the needed
material.
ELEX-560
would
use
the
authority
transmitted by the DD Form 1149 to obligate the user's funds
on a sole-source
Time
and
Materials
type
contract
with
UNIVAC for the development effort.
Accounting
budget
appropriation
elaborate task.
was
the
for
surcharge
activities
Frequent liason
necessary
and
myriad
of
cited by the users was an
with
ordering
acti vi ties
to insure that surcharges were "p3.id" out of
appropriation catagories which could
ELEX-560.
the
For
the
be
properly
used
by
most
part O&MN funds were required to
system
concerned user project managers.
fund project tasks.
The
surcharge
Primary objections were (1)
above
t he
fixed
prices
realization that if no
support
for
the
the
on
the
orders
project
necessity
contract,
were
those
believed that the project requirements
Navy
budget
Defense
In
submission
by
prices
(2)
the
the
funding
Each year NAVELEX
support
funds were never forthcoming.
pay
and
received
would dry up.
requested sufficient O&MN funding to
but
to
the
project,
Project personnel
were
cut
from
the
the Office of the Secretary of
(OSD) or the Office of Management and Budget
(OMB).
September 1974 the first issue of "The Standard n was
pUblished.
This dccument vas, as stated in its
header,
Ita
bi-monthly newsletter published to inform AN/UYK-20 users of
current
status
AN/UYK-20 (V)
Standard" iias
and
computer
a
step
new
and
developments
its
toward
43
support
solving
that
involve
software."
the
the
"The
communications
.>roblem that plagues all bureaucratic organizations.
About that
)rganization
IN/UYK-20
same
vas
Group
Laboratory
neeting attracted
?rivate
the
idea
of
a
formal
user's
conceived, and in November 1974 the first
User's
~lectronics
time
Center
some
industry.
m~etitig
200
By
was
held
(NELC)
persons
at-
the
Naval
in
San Diego.
The
from
government
and
mid-1976 the AN/UYK-20 User's Group
las meeting semi-annually in the Spring and Fall and boasted
i
membership of close to 300 persons.
i
forum for ELEX-560 to transmit further information to
lsers,
but
~nd
the
more importantly for the users to present ideas
present~tions
in briefings and
asers.
Each meeting provided
which
would
benefit
other
The meetings also provided an opportunity for users
project cffice
personnel
to
meet
face
to
face
and
iiscuss problems.
At the November 1976 User's Group meeting at
Postgraduate
of
a
compiler
for
San
the
Diego
UYK-20
announced
computer.
compiler, designated CMS-2Y(20), operated under the
operating system on the AN/UYK-7 computer.
designed
to
capability,
provide
versatile
late-1974
the
Many
SHARE/7
The compiler was
program
development
in
UYK-20
the
computers
development
had
of
been
tactical
hardware failures were encountered in these
early computers.
the
This
(App. G]
first
received and were in use
systems.
the
since it utilized the powerful programming aids
available under SHARE/7.
By
Naval
School in Monterey, the Fleet Combat Direction
Systems Support Activity (FCDSSA)
release
the
The hardware problems were
compounded
by
fact that the diagnostic program package for the UYK-20
was not available to users until November 1974.
dependent
on
maintenance.
software
and
software.
solved
UNIVAC
the
were
field engineers to perform corrective
Errors were also encountered
in
Users
documentation
In general these
problems
in
for both
were
the
support
h~rdware
discovered
and
and
through trial and error, but with large expenditures
of user time and funds.
44
The
types of problems most often encountered during the
early period in late-1974 were: Memory Array Board failures,
Memory
pins
Control
on
Board
printed
supplies,
PC
failures,
circuit
cards
broken or bent connection
(PC)
not
cards,
seated
defective
properly,
and
power
software
documentation which either contained erroneous
descriptions
of
to
software
capabilities
capabilities
that
responsible
for
or
existed.
neglected
The
contractor,
who
(ECP's)
deficiencies.
a
Because
of
necessary
to
to NAVELEX
to
correct
clause in the contract which
required all production units to he
incorporate
identical,
the
approved
a
retrofit
Engineering
Changes into production units already in the field.
serial
number
350,
December 1975,
retrofit.
which
became
All
UYK-20
came off the production line in
the
baseline
unit
for
the
first
349 previous production units were affected
in varying degrees.
such
was
correcting many of the problems, submitted
Engineering Change Proposals
was
mention
RetLofit I consisted of
minor
changes
as replacement of screws, mountings, and fittings, and
major changes such
serial/numbers
as
replacement
of
supplies
in
1 through 12, replacement of PC cards which
had been redesigned, and modifications
The
power
to
existing
cards.
retrofit was performed in the field by UNIVAC engineers
during the period from January 1975 to September 1976.
Despite
the
deficiencies, by
production
exist.
mid-1975
units
Perhaps
suspected
discovery
the
signified
the
best
reliability
and
correction
frequency
of
of
many
failures
in
that a Leliability problem did
data
base
problems
attesting
came
from
to
the
the
Naval
Electronics Systems Engineering Center (NESEC) at San Diego.
This
activity
was tasked with assembly and checkout of the
Navy Message Address Communications system
was
one
fleet.
Diego
were
of
the
first
systems
(NAVMACS),
using UYK-20 to reach the
During the period late-1974 to mid-1975,
reported
received
that
which
NESEC
San
a high percentage of production units
inoperative
due
45
to
faulty
PC
cards
and
assembly
modules.
Spares
received
were
also defective,
making trouble-shooting with the
diagnostic
programs
difficult.
procedures
utilizing
(Trouble-shooting
very
the
diagnostic rcutines depended on substituting
spare
and
Some failures
difficult
to
PC cards for suspected defective parts.)
were
intermittant,
making
diagnose.
Records at NESEC San
period
60~
them
Diego
indicate
supplies,
Particular
during
the
significant
be
problem
areas
were
Memory Array Boards, seating of I/O cards,
and overheating in hot weather.
would
that
late-1974 to mid-1975 many modules were experiencing
to 70% failure rates.
power
extremely
modules
period
It was found
that
over
a
of operation, however, the failure rate
substantially
decreased,
indicating
that
a
"burn-in" period increased reliability.
In
response
to
the
reports
from
NESEC
San
Diego,
personnel from UNIVAC visited that activity and verified the
need to upgrade reliability.
UNIVAC
voluntarily
shut
In
June
down
and
the
July
of
production
1975
line
in
Clearwater, Florida to investigate the possibility of severe
Quality
Assurance
(QA)
problems.
Over the ensuing months
the contractor took the following action to up-grade
UYK-20
quality:
*
Personnel Improvements
• Established QA as an independent organization.
• Transferred added
capability
Minnisota
from
to
QA
the
the
technical
main
UYK-20
and
plant
in
production
management
st. Paul,
plant
in
Clearwater.
quality
• Hired
additional
inspectors.
engineers
and
• Added a program QA man in Clearwater.
• Transferred final testing to Manufacturing in
order to remove schedule concerns and increase QA
focus.
46
*
Documentation and Procedures
• Reviewed
and
updated
all
inspection
and test
procedures.
• Established
formal
procedures for resolving
Defense Contract Administration Service
(DCAS)
UNIVAC quality concerns and for implementing
corrective actions.
Reviewed and improved assembly processes.
Added automatic equipment.
Introduced new material handling containers for
PC cards.
Developed new fixtures for holding memory arrays
during assembly.
and
•
•
•
•
*
Training and Motivation
• Hired a full-time trainer.
• Established a dedicated training room.
• Instituted training
programs
for
manufacturing
and inspection personnel.
•
*
Establis~ed
certification
criteria
and
recertification time periods for all key skills.
Management Reviews
• Increased local aUdits.
• Established formal defect
trend
reviews
with
manufacturing and QA.
• Implemented corrective action
follow-up
on
key
defects.
• strengthened and increased management aUdits.
After the June
to
July
shutdown
and
the
SUbsequent
UNIVAC experienced a 66%
improvement in acceptance tests at the Clearwater plant.
These improvements were felt by the users in late-1975 when
a high percentage of computers received from the factory
(were in operational condition.
quality
imFrovement
program,
47
In
late-1974,
developed
in
response
to
user
demands,
a User's Handbook for the AN/UYK-20(V)
handbook
was
development
written
primarily
programmers
for
Univac
DPS.
operational
This
program
and contained a description of the
hardware and detailed descriptions of support software.
handbook
was
first
had undergone
The
released in early-1975 and by mid-1976
four
major
revisions
to
correct
numerous
errors and incorporate new software systems.
Early in 1975 SDEX-20
and
the
(the standard Real-Time Executive)
CMS-2M compiler were released.
Since eMS-2M was a
subset of the CMS-2 standard high-level language, it
a
standard also.
UYK-20 users were required to write their
operational programs in that language.
begun
development
using
other
FORTRAN, and were unwilling to
cited
schedule
became
impact,
A few
languages,
rewrite.
projects
predominantly
Their
objections
increased development cost and the
high risk associated with using an untested compiler.
held
a
firm
line,
had
and most projects still in
TADSO
~evelopment
were forced to switch to eMS-2M.
Up
to
the
existed which
tactical
beginning
were
of
1975
specifically
systems.
It
was
no
meant
peripheral devices
for
use
was
also
a
By May 1975, 76 unique peripheral devices were in
use with the UYK-20 computer.
two
Navy
rapidly becoming apparent that
proliferation of diverse peripheral equipments
problem.
in
contracts
were
let
In February and March of 1975
for peripheral devices which were
destined to become standards for use in Navy systems:
*
A
contract
North
with
Atlantic
Cartridge
QUANTEX,
Industries
Magnetic
Tape
Peripherals
Division of
Incorporated
unit
(CMTU)
for
which
a
was
eventually designated AN/USH-26 (V) •
*
A
contract
Device
with
(ADD),
UNIVAC· for an Alphanumeric Display
which
vas
AN/USQ-69 (V) •
48
eventually
designated
The
acquisition
strategy
identical to that
procurement.
for
utilized
these
in
the
Requirements,
peripheral units was
standard
minicomputer
Indefinite
Delivery,
firm-fixed-price contracts were awarded to the
among
bidders
those contractors found responsible and responsive to
the RFP.
The first
sched~led
were
low
As a
peripheral
production
units
to be delivered in october 1976.
result
eguipments
standard
of
its
diversification
into
peripneral
and other areas,_ at the beginning of Fiscal Year
1976 ELEX-S60 was redesignated the Automatic Data Processing
(ADP)
Systems
Division (ELEX-S70).
With the redesignation
came increased scope of responsibilities including:
*
Tactical ADP hardware development.
*
Tactical ADP software development.
*
Tactical ADP display systems development.
In
September
and October of 1915 the Disk File Manager
software and Machine Independent System
Generator
software
packages were released. [App. G]
In November 1975, at the AN/UYK-20 User's Group meeting,
it
was
announced
that
a
User's Group Software Directory
would be published quarterly by the Publications Chairman of
the
User's
users
of
Group.
the
This
directory was designed to inform
availability
of
operational
software developed by other users.
and
support
Although the =oncept was
good, by May 1976 there were no suppliers of information
their
software,
although
on
there were many requests for the
directory_
Also
announced
AN/UYK-20
program,
Test,
to
Dahlgren,
was
be
at
Analyse
the
November
and
Fix
1975
(TAAF)
meeting was an
program.
This
carried out at the Naval Weapons center at
designed
to
accomplish
the
following
objectives:
*
Perform a Navy conducted AN/UYK-20
49
reliability
test
to:
• Ensure
recently
impr~ved
retrofitted
field
UYK-20 operation.
• Detect any additional
changes
demonstrate a 2000 hour MTBF.
*
changes
required
to
Establish a UYK-20 field data collection program.
The test setup was to consist
of
four
machines
variously
A total of
12,000 hours of operation under steady-state temperature,
voltage and frequency conditions was planned. Two of the
machines were to be subjected to a total of 600 hours of
vibration testing.
In May 1976 the results of the TAAF
program were reported to the User's Group assembled" at the
Naval Underwater Systems Center in New Londoa:
configured
*
to
excercise
all hardware options.
Corrective Action Items Identified
• Memory
Array
Board fabrication popped resistors
and cracked cores.
• The master clock was overloaded.
• Miscellaneous logic gates were overloaded.
• A
certain
type
of
Read-Only-Memory
(ROM)
was
defective and should be replaced.
*
Corrective Action items Installed
to
Change
• An Engineering
eliminate
clock
overload.
• Increased QA inspection of
Memory
Array
Boards
'and Power Supplies.
*
Observations
• No £Q!ponen~ reliability problems were detected.
• Reliability agreed closely with
available
field
data.
• Failures
were
due
design problems and
50
to
fabrication
~~1
techniques,
component failure.
The
data
d~ring
gathered
during the
first
4000
the TAAF program shoved that MTBF
hours
of
operation
on
the
machines remained low at about 500 to 600 hours.
four
After 4000
hours a steady improvement occurred so at the completion
testing
(12,000
hours) the MTBF was about 1500 hours.
of
The
results of these formal tests essentially confirmed what had
been
suspected by users a year and a half previously - that
memory boards and power
supplies
failures,
signi~icant
and
that
a
were
a
major
"burn-in"
cause
period
of
was
necessary for reliable operation.
By
the
end
of
1975 many design deficiencies had been
corrected through Engineering Changes.
also
requested
waivers
on
thought too rare to warrant
two
of
those
requests
certain
The
ELEX-570
deviation
from
radiation)
test
Interference
results.
other
design
test,
(specifically
All
approved
the
specifications: circuit bLeaker trip under shock
Electromagnetic
had
deficiencies which he
attention.
for
contractor
and
magnetic
requests
had
been
refused, but by the end of 1975 the contractor had failed to
correct three deficiencies:
*
The NTDS serial I/O interface was experiencing signal
reflections when cable lengths of
150
to
225
feet
were used.
*
Under certain conditions the condition code
was
set
subtract
properly
during
double
precision
not
operations.
*
Under
certain conditions Floating Point Add/Subtract
oFerations resulted in errors.
As a result, the
government
stopped
accepting
units from December 1975 to February 1976.
production
This firm action
caused the contractor to submit ECP's to correct
the
three
deficiencies.
Computer
serial
number
550,
51
which
was
pLoduced
in
February
1976,
became the base-line for a second retrofit.
Retrofit II implemented the Engin@.ering Changes
the
to
correct
three design deficiencies listed above plus six others.
(About 90 Engineering Change Proposals had been submitted by
that time.)
Naturally,
behind
the
two
schedule.
shutdowns
put
UYK-20
production
At the User's Group meeting in May, 1976
it was reported that 824 units had been
ordered,
but
only
637 delivered.
At the same User's Group meeting ELEX-S70
establishment
of
reported
an AN/UYK-20 Support Software Repository.
The. purpose of the repository was to collect and
as
required
to
D.
S.
Government
the
first
This effort
was
to reduce software development redundancy and thus
reduce development costs.
was
distribute
UYK-20 users, software
developed by other U. S. Government users.
designed
the
impending
majo~
Also reported to the User's Group
release
of a new technical manual, the
revision of this document.
This chapter has related the growing pains of a computer
system from development tprough initial production.
the
problems
were
to
Many of
be expected in such a project.
unfortunate part of the UYK-20 history was
that
The
throughout
this growth Feriod users were dependent on the computer as a
component in tactical systems under development.
unreliability
of
this
component
compounded
encountered in developing those systems.
will
discuss
the
impact
of
the
systems during this period of growth.
52
The
The
early
the problems
next
chapter
UYK-20 computer on user
Commander
(00)
Vice Commander
Commanders
DeDutv
I
I
f
t
Plan.
Prog.
&
Res.
Manag.
Contracts
01
02
R&T
Mat'l
Acq.
Logis.
04
03
05
Cost
Estimate
Coord.
05Y
T&E
Coord.
05E
I
Syst.
I
?rog &
Syst.
I
Eng.
Integ.
I
Tele-
ATe
comm.
Div.
Surv.
&
t
C&C
Div.
YIar
Corps
530
Amphib.
Div.
C;40
Nav.
Div.
520
5 10
Figure
3 -
N~VAL
504
503
501
{
I
Prod.u.
Sec.
Eng.
Div.
53
Std.
Tac.
Dig.
~q1:lip.
&
ELECTRONIC SYSTEMS
t
Div.
550
COM~AND
560
JRGANIZATION
The previous chapters have been historical in nature,
relating the events which ~arked the development and initial
production run of the standard minicomputer.
It is the
purpose of this chapter to evaluate the system itself and
the impact of UYK-20's growing pains on the development of
those systems which used it as a system component.
A.
COMPARISON OF SPECIFICATION AND FINAL PRODUCT
Chapter II, section C and Appendix B d~scussed the
specification upon which the AN/UYK-20 DPS acquisition was
based. To complete the historical picture presented in
previous chapters, it is necessary to briefly discuss the
actual product which resulted from the standard minicomputer
acquisition.
For ease of comparison, App. H summarizes the
characteristics of UYK-20 as it existed at mid-year 1976.
Appendix B summarizes the DRG's specification. Appendix I
lists the basic
hardware
configuration
and
options
available.
Appendix
G
describes the system support
software. References 16 and 17 provide further d=tails.
By comparing Apps. Band H it can be seen that the
OYK-20 system met or exceeded the specification in all major
areas except reliability and maintainability. As discussed
in the previcus chapter, MTBF to 2000 hours has never been
demonstrated.
No empirical data on MTTR was available. It
must be remember9d that MTTR included localization of the
problem, correction, alignment and calibration, and system
checkout. It could be p~stulated that meeting an MTTR of 15
minutes presumed that the diagnostic programs were ready to
load (via magnetic tape or paper tape), that the technician
54
was familiar with the diagnostic procedures published in the
Technical
Manual,
available.
If
and
the
that
a
complete
spares
kit
was
trouble was isolated to a module which
was missing from the spares kit, the MTTR would
necessarily
include time to procure the part.
The
UYK-20
specification
registers,
represented
in
the
areas
inst"ruction
consumption.
improvement
of
repertoir,
Weaknesses
were
in
scheme and interrupt structure.
structure
were
speed,
weight
the
and
memory
power
addressing
Some weaknesses in the
I/O
In addition, the
central Processor (CP) and the liD Controller (IO:)
sharing
the
number of general
Chapt. II.
discussed. in
over
ended up
the
same memory port, with the IOC having priority
over the CP.
An optional Direct Memory Access (OMA) channel
was
provided, which accessed memory through a second memory
port.
This minimized interference between
the OM! device, but the
65
about
additional
nanoseconds
CP/IOC
of the OMA capability added
to
memory
the
cycle
time.
are
sequential, . the
device from memory.
documentation,
a
connection
CP/IOC
modified to give the
and
Since many
lock-out the DMA
could
CP
Although it was not
jumper
An
that the CP /IOC had priority over
the OMA in accessing any particular memory bank.
accesses
and
~ddition
was
drawback
the
mentioned
the
in
on a pc card could be
OMA
memory
ports
equal
priority.
There was no provision
to
expand
main
memory
beyond
65K-words.
Although multi-level indirect addressing
the
procedure
for
was
possible,
implementation was awkward and involved
setting indirect control
bits
in
a
status
register
and
storing information in an Indirect Word.
Sixty-four page registers existed so
CQuld
be
divided
into
inadvertant
unauthorized programs.
memory
64 blocks of 1,024 words each.
memory protection existed, however,
prevent
m~in
that
access
to
~hich
was
pages
necessary
in
memory
!lso missing was a provision
55
for
No
to
by
a
privileged state
(i.e. a se~ of pri7ileged instructions
which could be reserved for use by a designated ezecuti7e
program.
The
lack of those latter tvo capa=ilities
prevented the efficient
algorithms
i~ple~entation
of
multi-progra~ming
for
program
s-apping
T~e
applications.
usefulness of the page registers was thus limited.
The interrupt structure weakness primarily in701ve1
t~e
inability to nest interrupts.
one
class
was
interrupted
(there
an
If
interrupt
by an interrupt from anothe=
priority
class
priority
interrupt would be saved while the
vere
interrupt was processed.
saving
status
capabilities
of
incorporated
fro~
the
upward
interrupt
~eused
lo-e=
p=iority
~igher
s~o=age
registers ani
and the
an
designated the
reper~oir
-as
?rev~ous
ar~a
fo=
~eal-ti~e
?rogra~
s~a~~s
com~atible
cont=ol.
optior.al
~ATH?AC.
words of user specified
the Microgrowth.
~~e
Ins~~~=~ic~s
.e~e
i~st~uction
with
specification,
~athe~atical
reflectin;
ex~ensi7e,
the AN/UYK-15(V)
for floating-point,
t~at
~onths
~as
ma~~
!1~~o~0t
caFability
si;ni£ica~t
t~igo~o~etri~
f~nCtio~s
of
mic=oFrog~a~
rQ~ti~es
~o1ule
Also available as an
mic=oprogram
the fact
~o
~achine.
~hat
ex~ensi7e
M~3?
than the 1500 hou=s
oF~i~~
=o~ti~es,
software [App. G], but it ~ust be remembered
systems only had an assembler
software
was developed over ~3e e~suing
Significant also
se~
and
By 1976 there vas available an
the early
the
class.
If
an
i~ter=u?t
of ~he same class, tne sa~e
microprogra~me1
not required by the
existed in
classes),
hig~er
forev~r.
The instruction
UYK-20
prograo
interrup~
storage area would be
would be lost
three
Eowever, only one
registers,
clock existed per
pre-empted another
from
was
set
-as 512
~es~;~a~9d
J:
t~a~
5~??O=~
~he
fi=s~
rest
mach
de~ons~=a~ed
verse
i~
in
1;76.
This section has briefly com?arei ~he !5/1!l-2G :?S ~~~~
tbe DRG's s?ecifica~ioc.
!~ general =o=~ ca?ajili~! eX~5te~
in the final prod~ct ~ha~ was originally req~es~ec, .~~~
56
some important exceptions.
the UYK-20
with
minicomputer
the
"off-the-shelf"
design
discussions will
Ensuing discussions will compare
in
provide
state-of-the-art
late-1972/early-1973.
further
insight
into
in
The
the
true
capabilities of the AN/UYK-20 DPS.
B.
COMPARISON OF AN/UYK-20 DPS WITH THE 1972
"OFF-THE-SHELF" MINICOiiPUTER STATE-OF-THE-ART
It
has
been
minicomputer
stated
previously
specification
may
embodied
guided
product
a
by
may
difficult
have
to
the
performance
looked
much
postulate
the
scope
of
the
this
best
prices
cost
of
to
eventually realized.
late-1972
and
state-of-art
production
Request
early-1973.
which
about
for
was
the
the final
It
would
system.
predict
be
any
It
is
what
the
funds
and
se~tion
This
possibilities
will,
available
in
The intent is to consider that
through
time
proposals
the
militarizing
computer
thesis
however, discuss the technical
for
specification,
proposals would have been, given the development
production
strategy
system
different.
particular commercially marketed
beyond
acquisition
design-to-cost concepts, for example, so that
the proposals could work toward
money
standard
have been too restrictive.
If given the funding constraints, the
had
the
that
of
(RFP).
development
and
into
the
standard minicomputer
The
assumption
is,
as
previously stated, that the Navy wanted to minimize time and
development effort and so would look for a system which
ready
further
for
market.
means
information,
of
four
The
discussions
evaluating
the
minicomputers
will
was
also provide a
AN/UYK-20
representing
DPS.
the
For
1972
technology are profiled in Apps. J through M.
Certainly the microprogrammed processor was the most
57
common
architecture
in
1972
examples, only the Digital Equipment
was
not
microprogrammed.
Microprogramming- permitted
and electrical power consumption.
of microprogramming were used.
utilized
a
long
controlled
a
Varian
with
73
while
a
minimizing
Basically two types
Horizontal
micro-instruction
specific
PDP-11/45
Corporation
reasonably powerful instruction repertoir
size
Of the four
minicomputers.
microprogramming
word
where
register-transfer
each
bit
function.
The
a 64-bit micro-instruction word was a good
example of that design concept.
The Rolm 1602 with a 32-bit
micro-instruction
border line case.
word
was
microprogramming utilized
which
required
process.
The
some
Hewlett
micro-instruction
word
microprogramming.
The
more .high-speed
memory
horizontal
case
hardware
micro-instruction
decoding
Packard
and
vertical.
microprogrammed
the
and
WCS
a
24-bit
a
of
16-bit
vertical
between the two types was
simpler
A
hardware
logic
'\
convenient
memory
memory
in
encountered
in
capability
place
allowed
storing
programs
of
the
microprograms or add his own routines
for
in'
a
with
WCS
in
to
alter
the
same
the
ease
Random Access Memory
involved
storage which were unalterable.
allowed a mixture of ROM and
Read-Only-Memory
user
in
By contrast, many ROM designs
program
control
with
examples
tradeoff
the
with
UYK-20
words
processor resulted from the use of writable
Control store (WCS)
(RAM).
in
2100A
are
Vertical
versus less memory but more complex logic in the
of
(ROM).
shorter
word
microinstruction
a
methods
of
Some minicomputers
the
control
memory.
This feature was totally lacking in UYK-20, even in the User
Microgrowth section, which had to be factory
produced.
To
circumvent this problem, FCDSSA San Diego developed a device
called GENRAM which plugged into the User Microgrowth module
slot
of
the
UYK-20.
This device, along with a microcode
assembler, facilitated development and test of
microprogram
routines for the UYK-20.
By contrast, the DEC PDP-l1/45 achieved
58
a
powerful
instruction
SO
set
through hardware implemented logic.
DEC sacrificed size
high-speed
bipolar
:lnd
power
logic
much
possible
with a microprogrammed architecture.
0.75
instructi~n
usee
By
using
and Large-Seale-Integration,
achieved
an Add
faster
consumption.
To do
instruction
execution
required only 0.3
usee
speeds
DEC
than
For example,
contrasted
with
for the same operation in UYK-20 or 1.96 usee in
HP2100A.
feature
architecture
Another
available
minicomputers in 1972 was register "push-pop"
PDP-11/45
had
an
on
Th~
stacks.
extensive stack manipulation capability,
but it was also available in a more limited way
machines like the Rolm 1502.
on
smaller
A "push-pop" stack was a group
of registers configured so that if a value was stored in the
registe~,
top
all
previously
stored
values
automatically "pushed" down to the register "below".
stack
was
referenced
by
an
were
If the
instruction, the "top" value
"popped" off and all values previously
stored
Actually
through the use of a
the
stack
was
implemented
stack pointer register which always
register on the stack.
operation.
be
pointed
moved
to
the
"up".
"top"
rhis was a last-in-first-out sort of
stacks were useful for storing data
that
would
used in a preset order, such as nesting interrupts where
the last machine
status
state
registers
and
(values
other
of
the
program
important data)
onto the stack, to be "popped" off when the
finished processing.
Another
particularly
architecture
where
attribute
interrupt
cap~bility.
was
useful
programs had to be swapped on and off a
mass storage device as in a
That
were "pushed"
last
The UYK-20 had no stack
counter,
multi-programming
attribute was a Privileged State.
environment.
Basically, a set of
instructions was provided which could only be executed while
in
that
special state.
Instructions which stopped program
execution, altered memory assignments of
memory
protection,
instruction set.
etc.
would
be
part
programs,
of
altered
a privileged
Combined with features like memory protect
59
and
paging
hardware,
the
existence of a privileged state
allowed powerful and efficient program
to
be
implemented.
swapping'
algorithms
A privileged state was generally found
only on larger machines like the PDP-l1/45.
Main memory generally was available in'thcee
magnetic
core,
~ore
semiconductor.
from
0.6
Metal Oxide Semiconductor
usec
memory ranged in
to
1.5
usec
(MOS) and bipolar
memory
was
that
semiconductor
requiring additional
Power
failure
power
would
to
were
non-volatile
long periods of time.
expensive
lowering
than
the
the
refresh
volatile~
were
the
The
data
stored.
Core
was
Core
provided.
and would retain data for very
memories
were
generally
less
semiconductor, although LSI techniques were
73,
Communications
of
offered
semiconductor
with
a
memory
mix
were
asynchronous (speed independent)
of
memories
memory
parity
were
not
types.
purposely designed to be
to allow future plug-in
speed memories as they became available.
utilized core memory only.
memory
usec.
Many minicomputers, such as the Rolm 1602 and
Varian
higher
0.3
memories
source
cost-per-bit
drastically.
speeds
result in the loss of all stored data
unless a backup battery power
memories
cycle
while semiconductor memories
realized memory cycle speeds down to about
tradeoff
types:
of
The UYK-20
Memory protection capability and
incorporated
reasons discussed in Chapt. II,
Sect.
in
the
C.
UYK-20 for
Those
features
were available on some minicomputers (HP2100A and Varian 73)
and almost always incorporated on larger computers like
PDP-l1/45~
Memory
parity
was
usually implemented by the
addition of two bits per memory word
each
a-bit byte).
the
(one
parity
bit
for
Memory protect'in minicomputers could be
implemented by a single register of one bit per memory block
or by one or more boundary registers which would contain the
address of the upper and/or lower boundary
memory
alock.
Most
minicomputers
60
of
offered
a
protected
at
least t.o
memory ports (i.e. channels)
The
through which to access memory.
most common arrangement was for the CP to access memory
through one port and a DMA
Both
the
channel
another
port.
CP and the device on the OMA channel could access
memory at memory cycle speeds.
(two
through
DMA
HP2100A featured three ports
channels plus CP).
Access speeds of 1,OOOK-words
per second were typical.
A
feature within the minicomputer state-of-the-art,
but not often implemented,
was
memory
placed
addressing
scheme
interleaved
memory.
This
consecutive addresses in
different memory banks to eliminate one device locking out a
particular
memory
address accesses.
bank
with a large number of consecutive
PDP-l1/45 featured interleaved memory
an option.
The PDP-ll family of
architecture
attribute.
computers
DEC
featured
connected
all
a
(CP, memory banks, I/O channels, DM! channels)
single
data/address
called a UNIBUS.
unique
functional
devices
bus
to
UNIBUS
independently.
as
a location with an address.
all devices
realized
were
on
In the PDP-11/Q5 every general
register, memory location and I/O register was
status
a
Each functional
device was independent and could access any other device
the
as
multiplexed
on
given
equal
Signals to and from
the
UNIBUS.
PDP-11/45
data rates up to 2,SOOK-words per second with that
scheme.
As previously discussed, the size of the instruction
set
was
highly dependent on architecture.
minicomputers featured far more
than
purely
hardware
implemented
minicomputers offered single and
The
HP2100A,
instructions
instruction
minicomputers.
PDP-11/45
as
an
speeds
For
powerful
Microprogrammed
instruction
architectures.
double-word
sets
Most
manipulation.
and UYK-20 featured floating-point
option.
were
UYK-20
medium
example,
61
for
floating-point
compared
a
to
floating-point
other
Add
instruction
the times were HP2100A: 23.5 usee to 59.8 usec:
UYK-20: 7.7 usec to 17.4 usec; PDP-11/45:
2.4 usec
to
5.5
usec.
Bit manipulation capability was extensive
minicomputers
designed
for process control.
the Texas Instruments CP-960A was
than
a
word
oriented,
a
bit
machine.
on
those
For instance,
oriented,
rather
general
purpose
Some
minicomputers like the HP2100A and PDP-11/45 offered several
bit manipulation instructions (Test and Set, Compare, Reset,
etc.) •
UYK-20
functions
featurea
except
Test
very
instructions
Byte
environment.
those
basic
and
awkward
bit
manipulation
set
which
a
real-time
in
required
two
programming
manipulation was a necessary capability
for real-time processing, expecially for data communications
applications.
and
Index,
Index).
UYK-20 possessed some capability (Load, Load
store,
Add,
Subtract,
Compare,
Compare
and
The use of those byte manipulation instructions was
necessarily awkward since the UYK-20
rather
than
consecutive
necessary
a
byte
address
to
oriented
was
a
machine.
referenced
a
full
word
oriented
That
is,
each
It
was
word.
indicate by.setting a bit in a register which
of the two bytes in the word addressed
manipulation
instructions
were
was
not,
desired.
however,
Byte
a
common
feature of commercial general-purpose minicomputers.
Another
was
the
feature not commonly found on minicomputers
implementation
of
trigonometric
functions as machine instructions.
and
Through MATHPAC a useful
set of such functions was available on UYK-20 as
Some
available
microprogrammed
machines
control storage capacity where users
functions.
A capability available on
totally
lacking
instructions.
on
data
in
on
could
some
UYK-20,
hyperbolic
~n
option.
featured
extra
implement
minicomputers,
was
such
but
memory-to-memory
That is, the capability to perform operations
memory and return the result to memory without
.first loading the data
into
a
62
register.
Varian
73
and
PDP-11/45
both
featured
but in UYK-20 all
data
some memory-to-memory capability,
had
to
be
first
loaded
into
a
register to perform further operations.
The
most
popular
I/O scheme in 1972 minicomputers
featured a single I/O bus.
machine,
data
In a single I/O
bus
structured
transfer was generally controlled by the CP.
Data rates were
slow
(300K-
to
400K-words
per
second).
Generally a number of peripherals could be interfaced on the
I/O bus.
the
The Rolm 1602 could support up to 61 devices,
HP2100A
only
14.,
structured machine.
one
DM!
channel.
Varian 73 was also a single I/O bus
Such machines usually featured at least
The Varian 73 featured a priority Memory
Access (PM!) channel which
3,300K-words
per
but
allowed
second
when
data
transfers
semiconductor
up
to
memory
as
A typical DMA channel data rate was l,OOOK-words
installed.
per second.
The processor independent IOC featured on the UYK-20
made
that
I/O
minicomputers.
scheme
more
powerful
The IOC acted as
an
than
found on most
independent
processor
with its own control memory and instruction set.
of four channels
registers
and
so
contained
its
could
operate
transfer was initiated by the
the
own
roc.
that
arithmetic
all
unit
and
independently
once data
One
was
drawback
IOC shared a memory port with the CP.
four channels shared an arithmetic
Each group
unit
that
Another was that
and
registers
so
channels of one group had to be of the same type.
The instruction set implemented
in
the
IOC
was
minimal.
Data manipulation had to be performed by the CP.
Again, the PDP-11/45 UNIBUS structure was
approach.
was
a DMA channel.
controller.
Thus,
the
UNIBUS,
every
I/O
In addition, each device could
communicate independently with another device.
on
unique
Each peripheral device was interfaced to the bus
through its own independent
channel
a
includin'g the CP, was assigned
63
Every device
3.
priority.
Communications were handled according to priority by a
UNIBUS Priority Arbitration unit.
By that system, liD
transfers were
Thus,
every
handled
indentically
to
memory
accesses.
instruction implemented on the PDP-11/45 could
be used in an I/O program to manipulate data.
Some
1972
minicomputers
interrupt structure.
with
stack
featured
generally
interrupt nesting capability.
featured
for each interrupt line.
for
The first involved
memory
assigned to the interrupt,
allowed
a
the
interrupt
direct
branching
service
status
to
~hich
a
specific
contained the
routine.
The
second
branch to the interrupt service routine.
The latter method was faster,
logic.
machine
Two methods of handling interrupts
were common.
of
multi-level
On other machines nesting was
accomplished by providin; storage area
address
priority
As previously discussed, minicomputers
architecture
word
a
but
required
more
hardware
UYK-20 implemented the former scheme.
On
UYK-20,
as
previously
discussed,
only
three
storage areas were provided to store machine status (one per
interrupt class) so that
nesting
capability
was
severely
limited.
The
term
"modular
construction"
connotations with different manufacturers.
had
different
The most
common
scheme featured a simple backpanel which provided only power
lines, data and address buses, etc., which
all
printed
circuit
(PC) card modules.
were
common
All PC cards were
the same size and could be plugged into any slot.
on
a
particular
PC card related to functional
there being one PC card for the CP, one for
circuits,
one
for
device interface.
each
Circuits
~a~agories,
memory
control
memory bank, and one for each IIO
HP2100A, Rolm 1602
configured in that manner.
to
and
Varian
73
we~e
The PDP-11/45 also was similarly
configured, although backpanel wiring was more
to
the UNIBUS structure.
complex
due
PC cards were generally large and
were structuraliy reinforced for strength.
UYK-20
featured an entirely different approach.
card modules were utilized, but cards were
hardware
. For
type
oriented
instance,
accupied
and
were
rather than functionally oriented •
control
four
small
memory
and
associated
circuitry
PC cards, the master clock occupied another,
interrupt storage
anothe~,
and
each
general
register
(two sets of 16 registers each) occupied a card.
available
[App.
different
types
of PC cards utilized.
plan where a majority of
modules
(i.e.
the
PC
cards
were
"throw-away"
those cards could be discarded wheL found to
containing
to discard.
number
The maintenance
be defective) also depended on that scheme.
card
that
I], but created a complicated wiring
situation on the backpanel and greatly increased the
of
set
The UYK-20
scheme facilitated the installation of plug-in options
were
PC
Naturally, a PC
an entire processor would be too expensive
The repairable PC
cards
in
the
UYK-20
those few that were large and functionally oriented -
were
Memory
Array Boards, Memory Control Boards and I/O Interface cards.
Those
generally
were
inadequately
reinforced,
bend, and were extremely difficult to
Interestingly,
oriented
the
cards
requirements
computer was
Rolm
and
met
including
s~rvice
1602
app~oved
and
install.
featured large functionally
all
shock
remove
tended to
military
specification
and vibration testing.
That
and designated AN/UYK-19 (V) •
A significant achievement by Rolm in the 1602 design
was a demonstrated MTBF of -11,000 hours.
experienced
significant
informative to investigate
computers.
a
detailed
reliability
the
Since
UYK-20
problems, it would be
differences
in
those
two
It is beyond the scope of this thesis to present
analysis
impact
machines
of
Some major points can be made,
was
a
65
on
the
reliability.
itself
two
the
of
design
the
of
construction
logic
the
design
and
their demonstrated
contributor
however.
to
The
UYK-20's
r~liability
problems.
For
example,
the
TAAP
program
conducted at Naval Weapons Center Dahlgren revealed that the
master clock and certain logic
overloaded.
A
user
gates
reported
that
'asynchronous, serial I/O interface
that
the
channel
would
basic
logi~
cards
the
MIL-STD-188C
both
was inadequate in UYK-20.
runs
and
backpanel
wiring
assurance
measures
unnoticed.
such
connection
risen
rhose
were
could
errors
of
wiring
could
larger
All such occurrences
lack
allow
of
jumper wires, printed
In
a
complex
adequate
quality
errors
to
procedures
utilizing
diagnostic
Over the three years after contract award,
to only 1500 hours.
pass
appear as circuit failures
had corrected many of those sorts of problems.
had
and
With frequent handling
pins.
situation,
troubleshooting
software.
in
leading
Construction and reinforcement
created circuit failures which lowered MTBF.
under
were
defective
pulse.
such cards suffered broken components,
circuit
UYK-20
was
on
signal
the
design problems and would directly contribute to
module failures.
PC
card
interrupt
trailing edges of an interrupt
in
UNIVAC
Yet the MTBF
The reason for that may lie
in the selection and integration of components.
rhe ability
for a manufacturer to control the quality of components used
in producing computers would directly impact on reliability.
In
producing
the
Most components
specifications
1602, Rolm corporation had that control.
in
UYK-20
were
procured
under
military
(with the exception of integrated circuits).
such components must be procured from a Qualified Parts List
(QPL)
vendor under military specification control.
situation UNIVAC had
Hardware
engineers
no
control
interviewed
components procured under military
over
component
In that
quality.
generally agreed that many
specifications
probably
exhibited MTBF's in the hundreds of hours.
It
is
beyond the scope of this thesis to present a
detailed analysis
of
the
available
66
minicomputer
support
software
in
Some
1972.
minicomputers
of software.
compatible
package
most
with
of
software.
take
In
cases
advantage
of
a
about
J through
minicomputer
models,
tested
soft~are
New
made
M,
generally featured a complete set
earlier
well
be
can
As indicated in Apps.
availability, however.
commercial
comments
and
was
upward
so that each inherited a
fully
documented
support
modules could be added at leisure to
the
added
capabilities
of
the
more
agreed
that
advanced machine.
Host
adequate
software
operational
engineers
testing
interviewed
was
difficult
Complete debug of a software module
use in the field.
achiev~.
to
depended
on
extensive
Naturally, any software package inherited
from a market-tested computer had that advantage.
The /UYK-20
computer
did
not have that advantage.
Although upward compatible with the AN/UYK-15(V)
that
machine
UYK-20
was
contract award.
SDEX-20
stage.
D],
did not possess a complete package of support
software and had not had extensive
for
[App.
use.
Support
software
developed during the three years following
As of
real-time
mid-1976
the
CMS-2M
compiler
and
executive were still in the "user debug"
All software was
still
receiving
enhancements
to
upgrade capability as funds became available.
The foregoing material in this thesis has
the
events
which occurred in the AN/UYK-20 DPS acquisition
history and the technical advantages and
system.
discussed
drawbacks
of
the
The final section in this chapter will discuss the
impact of those events, advantages and disadvantages on
the
users and their tactical system development efforts.
c.
IMPACT OF AN/UYK-20 DPS ON DEVELOPMENT OF USER SYSTEMS
The events of the
which
have
been
significant impact
three
referred
on
the
years
to
a
efforts
67
after
contract
"growing
of
pains",
users
to
award,
had a
develop
tactical
systems
utilizing
UYK-20
as a system component.
This section will discuss the various ways which that system
component
aided
or
complicated
those development efforts
during the period mid-1973 to mid-1976.
The implications of establishing a "standard" system
component
were
discussed in Chapt. II, Sect. B.
For those
programs well into development with another minicomputer and
lor programming language, the impact on
~cquisition
schedule to switch to UYK-20 was significant.
reported
a
two
year
schedule
system
for
the
cost
UYK-20.
8K-words
were
needed.
minimum
configuration
A
UYK-20
of memory and unit cost of $24,OQO.
project reported a four to five month slip and
$500,000
Since
processor with 4K-words of memory and unit cost
of $15,000 was replaced by a
with
project
involved primarily data-handling, only limited
processing power and core memory capacity
lower
One
slip and software costs of
$350,000 to $400,000 to reprogram
that
cost and
cost
to
reprogram
with
eMS-2M,
Another
$400,000
the
to
standard
high-level language.
The
trade-off
for
life-cycle costs through
costs,
etc.
as
those
savings
previously
immediate
concern
was
schedule,
and performance.
projects
in
I1S
discussed.
always
was
costs,
to
lower
training
Unfortunately, the
initial
acquisition
cost,
While life-cycle cost was given
lip-service, a project's success was ultimately measured
success
in
those
three
areas.
Thus,
by
imposition of the
standard on a system well into development impacted directly
on the measure of the project's success.
Because
of
the
necessity
to
identify
firm
requirements for UYK-20 production units, and to obtain O&MN
funds through the surcharge scheme, NAVELEX
was
forced
to
require those projects to switch to UYK-20.
The technical drawback of adopting
that
the
UYK-20
might
not
be
68
a
standard
was
specifically suited for a
particular applica tion.
system
control
and
monitoring
personnel
found
application.
100
capability.
the
be
engine
a powerful bit
That project would be
the
of
minimal
Interestingly,
UYK-20
an
where
manipulation capability was needed.
required to use UYK-20 regardJ..ess
manipulation
might
example
An
totally
no
unsuited
bit
project
for
their
It has been reported that as of mid-1976
projects
were
utilizing
UYK-20.
over
Tasks included the
following diverse sorts of requirements:
*
Message Processing Systems
• Low memory capacity (8K- to 16K-words)
• Low computing power
• High I/O capacity
(12 to 16 channels)
• High data rates
*
Navigational Systems
• Medium memory capacity (16K- to 32K-words)
• 32-bit (double word) I/O transfer
• 32-bit data manipulation
• Floating-point
trigonometric
and
hyperbolic
functions
• High
accuracy
(up
to
24-bits
per
data
word
• Large storage capacity (65K-words of memory
plus
preferred)
• Low I/O capacity (4 to 8 channels)
*
Signal Analysis Systems
high-speed
mass
storage
device
(disk)
on
channel
• Multi-programming capability
• Powerful mathematical capability
• High throughput (instruction execution rate)
• High I/O data rates
• High IIO capacity (8 to 16 channels)
*
Target Tracking and Fire Control Systems
• 32K- to 65K-words of storage capacity
69
D~A
• 12 to 16 I/O channels
• Mass storage device (disk)
on OMA channel
• Floating-point and trigonometric functions
• High throughput (instruction execution rate)
• Special
user
functions
implemented
through
Microgrowth
It
vas a significant accomplishment, and spoke well for the
DRG specification, that UYK-20 was able to handle those
and
many other diverse tasks.
w~s
The conclusion
by
impacted
imposition
Unfortunately,
that
that few projects
of
statement
a
were
standard
could
not
severely
minicomputer.
be
made
about
UYK-20, the compater that became the standard.
2.
~~~biliti~2
Hardware/Firmware
Users
found
generally
the
powerful enough for their needs.
and
UYK-20
Local Jumps,
architecture
Lo~d
Multiple
store Multiple instructions not common on minicomputers
were very useful.
The availability of 32 general
registers
was a powerful programming aid.
IIO structure was versatile
and powerful with the processor
independent
IOC.
Certain
attributes caused some inconvenience, however.
The awkward byte addressing scheme discussed in
the
previous section would add an additional instruction to byte
manipulation operations in order to set the upper/lower byte
indicator.
Execution
time for the byte operation would be
incr~ased
about
doubled.
One solution was to write self-modifying code, to
modify
This
the
byte
50%
and
program
manipulation
storage
instructions
requirements
"on-the-fly".
created programs which were very hard to debug.
such code was non-reentrant; i.e. it
without
reloading
the
original
device, and it could not be shared
could
program
in
a
not
from
be
~n
Also,
reused
external
IDulti-programming
environment.
Lack of memory-to-memory instructions added Load and
70
store
instructions
to those operations because of the need
to put the data in registers.
the
execution
time
for
About 1.5 usec was
memory-to-memory
program storage requirements were tripled.
and
set
instruction
(that
instructions in UYK-20)
interrupt
occurred
between
performed
Lack of
operation
was
was
the
being
invalid.
two
a
Test
required
two
then
an
which
the
test
The routine executing the
Test and Set instructions would not be aware of
and
If
instructions,
tested,
to
operations, and
could cause major problems.
changed the value that
already
added
the
change
would proceed on the basis of the original test results
when the interrupt finished processing.
The solution was to
lockout
the
and
Set
instructions and to restore interrupts after completing
the
Test
interrupts
and set.
before
executing
Test
That solution added two to four instructions
and 3.3 to 4.8 usec to a Test and set operation.
There
UYK-20.
would
were
no
absolute
compare
instructions
When comparing two words, the most significant
always
be
considered the sign.
requirements
were
thus
bit
To compare a 16-bit
absolute word a double-word operation was needed.
storage
in
again
added
Time
and
to the user
program.
The
sum
total
significantly decreased
requirements.
The
of
those
throughput
solution
was
sorts
and
of
deficiencies
increased
storage
to implement the missing
capabilities in the User Microgrowth area of control memory.
Such
a
development
effort had to be user funded, however.
As an example, one activity received a quotation of
to implement four instructions in Microgrowth:
*
Increment and Store Memory
*
Literal Add to Memory
*
*
Add to Memory
Literal store to Memory
71
$50,000
In
addition, an extra $1,000 was added to the price of each
production unit.
Many
projects
preferred
to
suffer
the
inconvenience rather than pay the price.
For those systems with
and
a
large
number
simultaneously,
the
multi-programming
of
tasks
lack
was
large
a
of
storage
requirements
could
be performed
which
proper
serious
tools
to
drawback.
registers existed, there was no privileged
implement
Although page
instructions
or
memory protection with which to implement sophisticated page
swapping algorithms.
and
tied
up
The alternatives
valuable
storage
reguired
space,
more
both
time
expensive
commodities in time-critical, real-time applications.
The
storage
capacity
relieved in some cases
beyond
if
a
problem
provision
65K-words had existed.
additional
processing
exp~nd
to
been
memory
Alternatives involved adding
additional UYK-20's to the system, which
the
~ave
could
power
was
was
expensive
if
not also needed, or
adding a mass storage device on the DMA channel, which would
often
not meet speed requirements.
To solve the dilemma in
one case, a semiconductor memory disk emulator was conceived
which
would
interface
to
the
computer
through
the DMA
channel.
Ability to utilize semiconductor memory
of
memory would have alleviated some similar problems
core
in
place
if that capability had existed.
A capacity problem also plagued some projects in the
I/O area.
Although the processor independent
powerful
with
IOC
provided
I/O capabilities, only 16 channels were available,
the
type
discussed.
configuration
constraints
previously
To get more capacity required multiplexing on a
channel, which sloved down th
data
rate,
or
adding
more
UYK-20's to the system.
Certain IIO configurations would have benefited from
complete
independence of the two sides of a duplex channel.
However, both
cleared
sides
shared
independently.
registers
Several
users
and
could
stated
be
the need to
write extra routines to pLevent losing data on one
72
not
side
if
the need arose to clear the other side of a channel.
A characteristic of
channels
synchronous
interface
was that the first few characters transmitted were
"garbage" due to
This
serial,
situation
the
need
to
establish
synchronization.
could not be tolerated on a radio
channel where good data would be lost.
(RF) data
The solution was
to
alter the RF Data Channel hardware.
progr~mmers
A common complaint from development
the
inadequacy
debugging.
of
the
Lack
Maintenance
of
I/O
Panel
status
and
as drawbacks.
The
displays
were
cited
maintenance panel
had
much
capability
troubleshooting,
hardware
for
program
solution would have been to reduce
the
capability
panel.
panel
not
for
enough
maintenance
but
software
indicators
multiple-register
too
for
and
provide
The lack of I/O
problem
since,
there was no
with
way
a
status
was
plug-in
indicators
debug.
of
A
the
software debug
was
a
serious
the laC independent of the processor,
to
determine
if
an
I/O
transfer
was
actually taking place after it was initiated.
Lack of interrupt nesting
concern
to
development
capability
programmers.
was
Care
a
major
had
to
exercised so that multiple interrupts occuring in one
would
not
preventing
solution
store
a
was
over
return
the
to
usually
to
virtually
nullified
the
Real-time
programs
were
loss
of
priority
original
the
class
machine status, thus
interrupted
lock-out other
priority
be
routine.
The
inte~~upts,
interrupt
which
capability.
generally interrupt driven, thus,
interrupt
capability
was
a
serious
drawback.
The awkwardness of
capability
caused
some
using
the
programmers
indirect
addressing
to abandon its use in
favor of direct addressing with indexing.
in
The support software for the AN/UYK-20 DPS was slow
coming.
Those programs in development in late-1973,
73
which were forced to switch to UYK-20, had
capability
assembler.
only
a
As a result, many created their own
program development capability.
Doing
that
time
since
operational
and
cost
of
a
system
development would cease while
assemblers,
editors,
programmers
debug
added
wrote
routines, etc.
on
its capability.
to
the
program
monitors,
As an example,
the cost of developing an assembler was $5,000
depending
limited
to
$100,000
It was cheaper and faster to
write your own, however, than to wait for the
Level
I
and
Level II systems to be released and debugged.
eMS-2M
(early-1975)
caused
two-fold problems.
Many early operational programs for
UYK-20 had to be written in assembly language.
Since it
took the same time fOL a programmer to code one line of
assembly language as to code one line of a high-level
language
(with a ratio of about six assembly language
instructions to one high-level language instruction), the
cost was significant. Those projects which electad to sta~t
development with another high-level
language
(usually
FORTRAN)
faced the prospect of reprogramming in eMS-2M when
that compiler became available.
The whole question of program development facilities
for a minicomputer is worth some discussion.
It wa5
generally not possible to configure a small computer for
efficient program development. Level II operating System,
The late
which
delivery
was self-hosted on the UYK-20, could SUPPOLt only one
programmer at a time.
modes
were
Although both interactive
provided,
compile
facilities were minimal.
larger
~ith
computer
programmers could
would
of
feature
times
What was generally
and
ba~ch
slow and debug
needed
was
a
a time-sharing monitor so that several
work
simultaneously.
cross-assemblers
and
object code for the small computer.
storage
were
and
An
ideal
system
compilers to generate
Adequate
memory,
disk
a number of program development aids such as a
text editor, debug utilities, data conversion routines, etc.
would
be
a
necessity.
A
program
74
to
emulata th9
s~all
computer
would
be
for
useful
debugging
initial
of
operati~nal
software.
A few activities which were to do extensive
development
for
the
UYK-20
program
did create such systems.
Electromagnetic Systems Laboratory in
Sunnyvale
set
The
up
time-sharing system on a Hewlett Packard 3000 computer.
a
The
system featured a direct link to a
UYK-20
special intercomputer I/J channel.
Source code generated on
the HP3000 could be loaded
assembly
or
compiling.
American Rockwell
PDP-11/45
directly
set
The
up
computer.
into
the
via
UYK-20
a
for
Autonetics Division of North
a
similar
FCDSSA
system
San
CMS-2Y(20) compiler for use on an
the
computer
Diego
AN/UYK-7
based
on
developed
computer
a
the
under
SHARE/7 time-sharing system as an aid to their software
development and maintenance efforts.
Such
In
systems
addition,
interface
the
the
hardware
system
developed in-house.
had
to
were understandably costly to set up.
provide
as~ociated
and
directly
to
a
the funds.
development
UYK-20
had
The project sponsoring the
to
to
be
davelopment
The dilemma facing the projact
manager was whether it was more cost
program
software
facility
or
effective
to
fund
a
to provide a self-hosted
system for the UYK-20 and suffer the inefficiencies.
As
an
example, the price of a self-hosted system with Level I I and
CMS-2M would be about $150,000
including
peripherals.
At
the other end of the price spectrum, the UYK-7 hosted system
would cost about
$800,000.
Commercial
systems
would
be
priced in between depending on capability.
To provide program development facilities
projects
the
cost
of
Laboratory
and
was conceived
Center.
computer based time-sharing
compilers
system
That
was
with
an emulator for UYK-20.
by
the
a
cross-assemblers,
The system could be
nationwide
network
lines.
by
leased
telephone
75
Naval
commercial
accessed via the ARPANET, a commercial
linked
save
support software and peripherals, a
System Design Laboratory (SDL)
Electronics
and
computer
Anticipated
drawbacks of that scheme were
possible
demand
beyond
the
system capacity, and the fact that classified programs could
not be developed on the system.
In fact,
projects
self-hosted
depended
on
non-availability of
program
a
development
the
major~ty
the
system.
well-tested,
complete,
system
the
at
of
The
self-hosted
outset
impacted
significantly on both cost and schedule of projects.
It is beyond the scope of this thesis to
detailed
analysis
capabilities
on
of
the
program
impact
of
development.
present
a
support
software
However,
certain
points brought out by development programmers are worth some
discussion.
A
II.
dynamic
debug
capability was needed under Level
As of mid-1916 the development of this
planned,
but
funds
were
not
capability
available.
capability would allow programmers to perform
executing program without
inte~fering
was
Dynamic
debug
an~lysis
on an
with its execution.
CMS-2M listings of source code and object code
not
were
produced side-by-side, making cross-referencing awkward
and time consuming.
CMS-2M
depended on the trigonometric and hyperbolic
functions provided through MATHPAC.
insufficient
in
some
useful functions and
language
like
Accuracy
applications.
routines
FORTRAN
not
for
available
a
with
Because that language anticipated restricted usage,
library
of
development
needed.
In
routines
would
programmer
recognition
to
never
write
was
The large variety of
developed
were
provided
well-used
CMS-2M.
such
a
be created, forcing the
his
own
routines
when
of this problem, the User's Group
in
Chapter III were an attempt to prevent redundant development
of such routines.
eMS-2M was not an optimizing compiler.
Because many
operational programs are time-critical and have
large
Software Directory and the software Repository mentioned
16
storage
requirements,
it would have been useful to have an
mini~ize
optimizing version of the eMS-2M compiler to
use of
those assets.
Like
SDEX-20
any
general
required
too
much
spent in executing the
useful.
executive,
real-time
purpose
core and system overhead (time
executive
software)
to
be
widely
Those applications with time-critical routines and
large storage requirements were forced to
,
real-time
By
mcnitors.
could be optimized
for
writing
the
write
own
an executive in-house it
particular
minimizing storage and overhead.
their
application,
thus
Many programmers felt that
a general purpose real-time executive would be useful if the
source
code were available to programmers as a reference to
aid in writing their own.
the
question
of
the
The low usage. of
SDEX- 20
raised
cost-effectiveness of supplying that
type of support software.
The peripherals problem is actually divided into two
catagories:
peripherals
peripherals
standard
for
tactical
militar ized
purchase,
for
except
systems.
had
years.
units
were
minicomputer
been
installation.
no
available
for
and
generally
too
and
mid-1976
tape
paper
existance
in
Even
to
were
keyboard/printers
which
development,
Up
peripherals
reader/punches
Those
program
for several
large
for
a
with the introduction of
the Alphanumeric Display
Device
Magnetic Tape Unit
in mid-1976, important peripherals
were
still
lacking,
(reel-to-reel),
display
a
terminal.
militarizaiori
same
sort
(CMTU)
of
of
such
disk
(ADD)
as
a
storage
Projects
their
own
and
magnetic
device,
were
problem
Cartridge
tape
and
forced
pe~ipherals,
proliferation
the
a
unit
graphics
to
fund
which created the
encountared
with
minicomputers in the early 1970·s.
During the early
only
production
period
in
late-1973,
UNIVAC peripherals could be interfaced with the UYK-20
77
for program development.
too
large
and
expensive
projects began acquiring
peripheral~
to
Those peripherals
for
a
their
generally
minicomputer
own.
costs
system, so
of
procuring
included development of device software modules
interface
with
acquisition
of
the
UYK-20
operating
peripherals
to
be
systems.
used
development was costly, especially since
would
were
for
those
The
program
peripherals
in general not be used in the tactical system itself.
Projects
were
peripherals
wise
to
configured
retain
for
a
UYK-20
program
s1stem
development
provided as Government Furnished Equipment
with
to
(GFE) for
be
future
development efforts.
JI.2f:g!!ll~
6•
MaiBtai!l~iliiY
The
experienced
III.
acute
in
quality
reliability
problems
AN/UYK-20 DPS were reported in Chapter
the
It was those
and
problems
that
had
the
most
profound
impact on user development efforts.
The programs
forced
to
use
developing
in
mid-to-late-1973
Functional Demonstration Models (FDM's) and
Advanced Production Engineering Models
meet
not
develoFment
ready
for
schedules.
release.
(APE's)
in
The
numerous
deficiencies
to
and
Projects were forced
to purchase two computers and cannabilize one
to
keep
the
Early production units had similar problems.
Software debugging on faulty hardware was
time-consuming
order
That hardware was essentially
failures caused significant down time.
other running.
were
task.
a
difficult
and
One activity reported expending three
man-months of labor trying
to
debug
a
program
when
the
problem was actually in the interrupt hardware.
Efforts
to
troubleshoot
faulty
hardware
hampered by faulty spares in the spare parts kits.
were expensive ($13,000 each)
so that project
unwilling to purchase sufficient numbers.
The kits
man~gers
were
Project personnel
estimated that one spares kit per computer was necessary
78
were
to
ensure
parts
availability.
Memory
Array
Boards,
which
experienced very high failure rates, were repairable modules
and were not included in the spares kits.
Since the time to
ship the repairable modules back to UNIVAC
return
was
running
six
to
forced to purchase extra
eight
Memory
activities,
like
repair
and
weeks, activities were
Array
each) to minimize down time.
It was more timely and
for
cost
Boards
(at
effective
$1,300
for
some
NESEC San Diego,' to do their own hardware
trouble-shooting and repair,
rather
engineers.
software and documentation was
The
diagnostic
not well suited to this
could
isolate
circuit
problems which plagued
turned
effort.
The
board
the
than
call
diagnostic
failures,
earlier
in
but
UNIVAC
routines
not
machines.
design
Activities
to logic circuit diagrams, but found that those also
contained errors.
It was
up-to-date
of logic circuit diagrams since no formal
files
difficult
to
maintain
accurate
system existed for procuring them.
Early
errors.
were
releases
of
the
support
User activities attempting to
hampered
inadequate
by
Source code was not available
efforts.
After
repeated
operating systems was
compilers
was
information.
made
withheld
software had many
debug
the
software
and erroneous documentation.
initially
demands
a
aid
in
their
the source code for the
available,
as
to
but
matter
code
of
for
proprietary
Most software engineers interviewed
the opinion that the support software source code,
expressed
including
compilers, should be purchased outright by the Navy so
it
could
be
made available to users.
that
That was especially
true when the support software contained so many errors
the documentation was inadequate.
the
and
In many cases programmers
had to resort to the source code to determine the details of
system
software
was once
assembler
forced
operation.
to
capability
documentation.
One activity reported that it
reprogram
which
to
was
take
not
advant~ge
mentioned
A basic problem with software
79
of
in
an
the
documentation
was that no detailed discussions of software philosophy were
presented.
problems
Adding the problems in the software
in
the
hardware
made
an
situation for programmers attempting
on
extremely
to
debug
top
of
difficult
operational
software.
7.
Lack of
~di£g.~~g !EI!rQ£ri~!.~~
FU!lds
!Q
1he
§.!!£.EQ!:!
AN/UYK-2 C DP§
It is significant that a majority of
corrected
problems.
Given
when
usage
was
sufficient
to
problems
isolate
were
those
Given time the support software became available.
time the standard peripherals would be available.
If
NAVELEX could have waited until the system was adequately
tested before release, much of the inconvenience caused to
users would have been eliminated.
The reason that NAVELEX
could not wait was lack of funding.
It was necessary to
identify specific requirements for production units and to
receive orders for the system in order to get the surcharge
that paid for project support.
NAVELEX was thus forced to
require the use of the system before it was ready.
An
obvious solution was to wait until funding for the entire
acquisition cycle was reasonably assured (another year at
best). Then wait until the system was complete,
including
software and testing,
before releasing it (another two to
three years). Of course, a three to four year delay would
have brought proliferation of minicomputer types in the Navy
inventory to an unacceptable level.
Some of that delay
might have been saved by purchasing a "market-tested"
computer system,
then militarizing it.
At least
the
reliable commercial equivalent would have been available for
use in development until the militarized version
was
available.
Certainly computer systems existed which could
meet Navy performance requirements.
The lack of dedicated funds has thus been identified
as the prime-mover in many events in the history of the
AN/UYK-20 DPS acquisition.
The final chapter will summarize
80
and present some recommendations which might prove useful in
future tactical processor acquisitions.
81
In 1972, when proliferation of minicomputer types in the
Navy
inventory
was
perceived to be a significant problem,
the Tactical Digital systems Office
the
Naval
Command
standard
minicomputer.
required
in all tactical systems requiring a small computer
sufficien~
conceived
of
Material
unless
(NAVMAT)
(TADSO)
Use
of
the procurement of a
that
minicomputer
was
justification was given to use a different
computer.
Although no funds
had
been
appropriated
for
such
a
procurement, NAVMAT, with the approval of the Chief of Naval
Operations (CNO)
action
proceeded
I
to
initiate
procurement
by reprogramming a minimum of Research, Development,
Test and Evaluation Navy (RDT&EN)
anticipated
user projects.
appropriated
drawn
software
up.
funds
A Design Review Group
convened, and a fairly restrictive
was
the
technical
from
(DRG)
was
specification
With the exception of an assembler, support
requirements
specification.
At
were
that
missing
point
entirely
the
Navy
from
was
the
procuring
one-half of a minicomputer system with no funds appropriated
for
future
support.
The
necessity
to get support funds
forced NAVMAT to require projects still in their ievelopment
phase
to
include
the standard minicomputer immediately in
their program and to assess
a
surcharge
on
purchases
of
standard minicomputer hardware and software.
The contract award went to
Defense
Systems
Division
the
lowest
of Sperry-Rand
bidder,
Corpor~tion.
DRG specification appeared to be influenced
design
philosophy,
owing
to
the
large
UNIVAC
by
the
The
UNIVAC
number of UNIVAC
computers in the Navy inventory.
Although the original acquisition strategy intended that
the
minicomputer
system
be
a
82
militarized
off-the-shelf
commercial
system,
UNIVAC
won
the competition with a new
design that had never been in production and was not
upward
compatible with any veIl-established family of computers.
In order to meet user project development schedules, the
first
Functional
Development Models
(FDM)
prototypes)
were delivered within 120
days
award
the first Advanced Production Engineering Models
and
(militarized
(APE)
contract
award.
prototypes)
Although
potential for
good
FDM's,
APE's
and
tested
and
the
in
aftec
nine
hardware
capabilities
a
contract
months
design
after
held the
minicomputer,
the
early production units were inadequately
debugged.
maintainability
within
(non-militarized
Reliability
suffeced
was
from
very
low
inadequate
programs, poor documentation, faulty spares,
and
diagnostic
and
excessive
turnaround time on repairable modules.
Initially software was non-existent;
was
inadequately
tested and debugged.
when
raleased
it
User efforts to use
the software were hampered by poor documentation.
Thus,
lack of dedicated funding forced users to utilize
the standard minicomputer as a system
was
ready.
component
before
it
The result was significant labor costs to cope
with the problems and increased risks in the development
of
operational programs.
It was
before
mid-1976,
the
system
three
years
after
contract
award,
was sufficiently reliable and possessed
adequate support software to be considered a
viable
system
component in a developing tactical system.
It must be recognized that follow-on
digital
processors
may
standard
not be minicomputers.
tactical
Perhaps the
design will be a distributed microprocessor system
architecture
not
state-of-the-art
possibilities
yet
conceived.
of
digital
endless.
The
and
processors
events
recommendations
makes
connected
the
with
however,
pertinent
acquisitions of tactical digital processors,
83
some
The rapid advance in the
standard minicomputer acquisition do foster,
conclusions
or
to
the
some
future
regardless
of
architectural philosophy.
logistics
support.
cost
and
life-cycle
The
considerations make adoption of standards necessary.
1•
2.
The decision as to how often to
involves
a
tradeoff
-between
reprocure
two
a
standard
alternatives:' (1)
reprocuring rapidly enough to keep up with advances
state-of-the-art,
and
The
tolerance
account.
That
large-scale
of tactical system development
engineers for using an "old fl standard
into
the
producing a particular standard
(2)
long enough to maximize the economic benefit of
production.
in
must
also
be
taken
decision must be made on the basis of
factors such as availability
of
funds
and
how
well
the
current standard is performing at the time.
3.
The
primary
acquisition
goal
strategy
minicomputer
types
was
in
of
the
to
stem
the
standard
the
minicomputer
proliferation
Navy inventory.
of
That goal vas
accomplished at the expense of significant adverse impact on
the
costs
and
schedule
author's opinion that
outweighed' the
the
benefit
should be
the
primary
processor
acquisitions
of
user
projects.
"cost"
of
of
minimizing
goal
of
would
management
4.
The
be
a~d
on
impact
tactical
It
digital
to deliver a highly reliable system
accurate
documentation.
Integrated Logistics Support policies.
minicomputer
user
projects
operational suppo;rt funding.
reason
adver:se
simply applying current systems engineering
standard
dependent
is this
proliferation.
future
complete with support software and
That
the
It
procurement
for
both
That fact was
was
totally
development
the
and
underlying
why projects were forced to use the system before it
was ready, accounting for: most of the events which
adversely
on those user projects.
RDT&EN and O&MN funding
for
a
84
impacted
The availability of both
standard
tactical
digital
processor
acquisition should be reasonably assured prior to
contract award.
minicomputer
Based
on
experience
acquisition,
with
the
standard
contract award should be planned
for two to three years prior to
required
delivery
of
the
militarized version to the fleet.
5.
Since
it
would
between contract
be
award
desirable
and
to
delivery
minimize
to
the
the time
fleet,
the
acquisition strategy should strongly consider procurement of
an off-the-shelf,
strong
market-tested
heritage
from
a
system
successful
Availability of software should be
It
is
which
exhibits
a
family of processors.
a
major
consideration.
this author's opinion that the strong competition in
the digital equipment industry assures that
systems
push
the
state-of-the-art
new
commercial
while at the same time
exhibiting reliable hardware and software performance.
strategy
just
The
suggested should thus suffer minimal risk of
early obsolescence.
This strategy
would
also
insure
the
immediate availability of FDM's for use in development.
6.
Award
of
contract
in
the
procurement was based on two
responsiveness and
(2)
lowest
standard
minicomputer
factors,
(1)
technical
price proposal.
Such a
strategy precludes consideration of which proposal
the
best reliability and performance for the price.
acquisition strategies should
procurement
based
on
require
flexibility
to
a
fully
Selection
since
such
negotiated
consider
both
systems
have
Such a
Evaluation
design
proposals offering market-tested systems could
heavily
Future
a performance specification.
strategy would give the Source
the
presents
usage
and
be
data
Board
price.
weighted
to
prove
reliability and performance.
7.
Despite the fact that
companies
a
pre-award
survey
found
all
submitting proposals to be responsive, the winner
experienced immediate and severe quality assurance
85
proble~s.
T~ose
QA problems had a profound impact on user development
efforts.
the
Future pre-award surveys should
potential
product.
should
establish
contractors' abilities to produce a reliable
Careful evaluation of
be
firmly
made
quality
control
standards
to assure that those standards will insure
delivery of a reliable product.
8.
in
The Requirements, Indefinite Delivery contract
awarded
the standard minicomputer acquisition was well-suited as
a production contract
and
should
be
utilized
in
future
procurements of standard equipment.
9.
The
imposition
of
military
specifications
on
a
commercial design creates some risk in the development area.
Future
acquisition strategy should consider awarding a cost
type development contract
Funds
permitting,
the
for
the
militarization
effort.
award of such a contract to several
companies would permit a "fly-off", ensuring competition for
the production contract.
10.
As
tactical
digital
processors become smaller due to
advances in Large Scale Integration techniques, the need for
non-self-hosted
important.
program development facilities becomes more
Future
processors
should
acquisitions
digital
tactical
digital
consider award of a separate fixed-price
contract for a program development
standard
of
processor.
system
Certain
to
support
digital
companies specialize in design, integration, and
the
equipment
production
of
such
specialized systems from off-the-shelf components,
so
that
adequate
competition
should
exist
fo~
such
a
procurement.
11.
The
maintenance
and
control
panels on the AN/UYK-20
computer did not provide adequate capabilities for
test
and
debug.
Future
software
systems should include a plug-in
software debug console to provide this capability.
86
12. A generalized real-time executive may occupy too much
core, and require too much ~ystem overhead to be widely
such software
useful in a tactical system environmen t.
could be better optimized in designs tailored for the
specific application.
Future acquisitions
should
not
include a standard real-time executive with the support
software, but should provide some means
(such as the
software Repository)
by which projects are made aware of
such software developed by other users.
13.
software development engineers interviewed stated
source
cod~
for
the
various
assemblers and compilers,
debugging
code would
operation
design.
operational
allow
of
the
Future
the
was
support software, including
a
programs.
developer
software
and
acquisition
that
useful
tool
Knowledge
to
to
aid
in
of the source
determine
the
exact
the philosophy behind its
strategies
should
include
outright purchase of the data rights to all software as well
as hardware so that source code may be supplied to
87
users~
APPENDIX A
AN/UYK-7 SYSTEM DESCRIPTION
Manufacturer
Construction standard
Maximum Physical Dimensions
Maximum Weight
Maximum Power Consumption
Architecture
Word Size
No. of Registers
Inst. Execution Time
Add/Sub/Load
Ml;lltiply
Dl. vl.de
Microprogrammable
Technology
Privilegea State
Stack
Main Memqry
.
Maxl.mum Sl.ze
Speed
Wor d-size
Memory Pa~ity Checking
Memory Wrl.te Protect
Technology
Multiported
Instruction Set
Double Precision
Byte Ma nipula tion
Bl.t Manipulation
Floating Point
Math/+rl.g Functions
Neqatl.on
Arl.thmetic Complement
Stack Manipulation
UNIVAC
MIL-E-16400
41"Hx24 I1 Dx20"W
527 to 1,139 Ibs.
1,720 to 6,000 watts
32-bits
or 16 (accumulators)
6.5 usec
10.0 usec
17.0 usec
No
Third Generation/MSI
Yes
No
8
256K-words (16K/module)
1.5 usec
32- bits
No
Yes
Magnetic Core
8 ports/16K module
Yes
Yes
Yes
Hardware
Software
One's Complement
One's Complement
No
Addres~ing
D~rect
Indirection
Indexing
Paging Hardware
262K-words
1 or 14 index registers
No
-M ul ti-level
88
I/O controller
No. of Channels
Typ~s of Channels
Max~mum Data Rate
Processor Independent
Maintenanc~/Control
Locat~on
16
Serial/Parallel
167,000 words/sec
Yes
Panel
Remote
No
Multi-register displays
Firmware
Initial Program Load
Reliability & Maintainability
Unknown
15 minutes
Firmware/Software
MTBP
fiTTR
Diagnostic Programs
Yes
Modular Building Blocks
support Software
Assemblers
Compilers
L'oader
Editor
Librarian
Debug Routines
Operat~ng systems
Real-T~me
Yes
FORTRAN/CMS-2
Yes
Yes
Yes
Yes
SHARE/7
Yes
as
Interrupts
Pr~ority
Structure
Nesting Capability
Yes
No
89
APPENDIX B
STANDARD MINICOMPUTER SPECIFICATIONS
Manufacturer
?
Construction Standard
MIL-E-16400
Maximum Physical Dimensions
26"Hx24 t1 Dx19 I1 W
Maximum Weight
220 lbs.
Maximum Power Consumption
1,000 watts
Architecture
Word Size
No. of Registers
Inst. Execution Time
Add/Sub/Load
Multiplv
Divide Microprogrammable
Technology
Privileged State
Stack
1.2 usec
9.0 usec
20.0 usee
Yes
3rd generation/MSI
Not regld
Not regld
Main Mem9ry
.
Maxl.mum Sl.ze
speed
Word-size
Memory Pa~ity Checking
Memory Wr~te Protect
Technology
Multiported
65K-words (8K min.)
1.2 usec {f.O usec effective)
16-bits m~nimum
Optional
Not reqld
RAM, non-volatile
Two (Processor/I ~C)
Instruction Set
Double Precision
Byte Manipulation
Bl.t Manipulation
Floating Point
Math/~rl.g Functions
Negatl.on
Arl.thmetic Complement
Stack Manipulation
Yes
Yes
Not req'd
Not regld
Not req'd
Onels and Twols Com·plement
Onels or lWOIS Complement
No
16-bits minimum
4 expandable to 16 (general)
Addres~ing
65K-words
To at least one level
All general registers
Yes
D~rect
Indirection
Indexing
Paging Hardware
90
I/O controller
No. of Channels
Typ~s of Channels
Max~mum Data Rate
Processor Independent
Ser/Par/DMA
190K-words/sec
Yes
Maintenance/Control Panel
Location
Multi-register displays
Optional
Not req'd
Initial Program Load
Hardware or
16
Beliability & Maintainability
MTBF
2000 hours
15 minutes
Yes
MTTR
Diagnostic Programs
Modular Building Blocks
Yes
Support Software
Ass embl ers .
Compilers
Loader
Editor
Librarian
Debug ~outines
Operat~ng Systems
Real-T~me
Firmwar~
Yes
Not
Not
Not
Not
Not
Not
Not
as
Interrupts
Pr~ority
req'd
req'd
req'd
req1d
req'd
regld
req'd
Yes
Four levels-one per group
structure
Nesting Capability
91
APPENDIX C
CP-642B SYSTEM DESCRIPTION
Manufacturer
UNIVAC
Construction Standard
MIL-E-16400
Maximum Physical Dimensions
72"Hx37 n Dx38"W
Maximum Weight
2,400 lbs.
Maximum Power Consumption
2,000 watts
Architecture
Word Size
No. of Registers .
Inst. Execut10n T1me
Add/Sub/Load
M\;ll1:iply
D1v1de
Microprogrammable
Technology
privilegea State
Stack
8-12 usec
8-12 usec
8-12 usec
No
Discrete Components
No
No
Main Mem9ry
.
MaX1IDum S1ze
Speed
Word-size
Memory Parity Checking
Memory write protect
Technology
Multiported
32K to 262K-words
4 usec
32-bit
No
No
Magnetic Core
No
30-hi ts
3 (accumulators)
Instruction Set
Double Precision
Byte Ma~ipulation
B~t
Yes
Yes
No
Software Implemented
Software Implemented
One's Complement
One's Complement
No
Man~pulat10n
Floating Poin t
Math/+r~g Functions
Negat10n
Ar1thmetic Complement
Stack Manipulation
Addres~ing
D1rect
Indirection
Indexing
Pag ing Hardva re
32K-words
No
7 Index Registers
No
92
I/O Controller
No. of Channels
Typ~s of Channels
Max~mum Data Rate
Processor Independent
16
Parallel
Unknown
No
Maintenance/Control Panel
Location
Multi-register displays
Front of Cabinet
Yes
Initial Program Load
Firmware
Reliability & Maintainability
liTBF
MTTR
Diagnostic Programs
1500 hours
Unknown
Yes
Modular Building Blocks
No
support Software
Assemblers
Compilers
Loaaer
Editor
Librarian
Debug ~outines
Operat~ng Systems
Real-Time as
Yes
CS-1
Yes
Yes
Yes
Yes
No
No
Interrup ts.
Yes
No
structure
Nesting Capability
Pr~or~ty
93
APPENDIX D
AN/UYK-15 (V) SYSTEM DESCRIPTION
UNIVAC
MIL-E-16400
21"Hx17"Dx19"W
200 lbs.
500 watts
Manufacturer
Construction Standard
Maximum Physical Dimensions
Maximum Weight
Maximum Power Consumption
Architecture
Word Size
No. of Registers .
Inst. Execut~on T~me
Add/Sub/Load
M\lltiply
D~v~de
Microprogrammable
Technology
Privilegea State
Stack·
Main Mem9ry
.
Max~mum S~ze
Speed
Word-size
Memory Pa~ity Checking
Memory Wr~te Protect
Technology
Multiported
Instruction Set
Double Precisio n
Byte Manipulation
B~t Manipulation
Floating Point
Math/+r~g Functions
Negat~on
Ar~thmetic Complement
Stack Manipulation
Addres!?ing
D~rect
Indirection
Indexing
Paging Hardware
16-bits
64 (general)
0.75 usec
3.8 usec
3.8 usec
No
Third Generation/MSI
No
No
65K-words
0.75 usec
18-bits
Yes
Yes
Magnetic Core
Four ports/16K-word bank
Yes
Yes
Yes
Software Implemented
Hardware Implemented
Two's and One's Complement
Two's C..omplement
No
65K-words
No
All General Registers
No
94
I/O Controller
No. of Channels
Typ~s of Channels
Max~mum Data Rate
Processor Independent
16
Ser/Par
190K-words/sec
Yes
Maintenance/Control Panel
Location
Multi-register displays
Front of Cabinet
No
Initial Program Load
Firmware
Reliability & Maintainability
MTBF
M+TR
.
D~agnost~c Programs
2000 hours
15 minutes
Firmware/Software
Modular Building Blocks
Yes
support Soft ware
Assemblers
Compilers
Loaijer
Editor
Librarian
Debug Routines
Operat~ng Systems
Real-T~me
Yes
Unknown
Yes
Unknown
Unknown
Unknown
Unknown
Unknown
OS
Interrupts
Pr~ority
structure
Nesting Capability
Yes
Four levels-one per class
95
APPENDIX E
CP-890 SYSTEM DESCRIPTION
Manufacturer
UNIVAC
Construction Standard
MIL-E-16400
Maximum Physical Dimensions
74"HxlS"Dx22"W
Maximum Weight
700 Ibs.
Maximum Power Consumption
1,675 watts
Architecture
Word Size
'No. of Regist ers .
Inst. Execut~on T1me
Add/Sub/Load
M':lltiply
30-bits
2 (accu mula tors)
1.S'usec
8.8 usee
15.0 usee
No
2nd Generation/Discrete
Yes
No
D~v~de
Microprogrammable
Technology
Privilegea State
Stack
Main Memry
.
MaX1mum S1ze
Speed
Word-size
Memory Pa+ity Checking
Memory Wr1te Protect
Technology
Mul tiported
65K-words
1.0 usec
16-bits
No
No
Core or Semiconductor
Two (CP /DMA)
Instruction Set
Double Precision
Byte Ma nipula tion
81 t Manipulation
Floating Poin t
Math/+r1g Functions
Negat10n
Ar1thmetic Complement
Stack Manipulation
Yes
No
Yes
Yes
Firmware
Two's Complement
Two's Complement
Yes-
Addressing
Direct
Indirection
Indexing
Paging Hardware
1,024 words
Multi-level
Two accumulators
Yes
16-bits
(accumulators)
4
109
usec
usec
usec
(3.5K-words growth)
generation/MSI/LSI
I/O Controller
No. of Channels
Types of Channels
Maximum Data Rate
Processor Independent
61 devices on I/O bus
Serial/Parallel
1,000K-words/sec
DMA only
Maintenance/Control Panel
Location
Multi-register displays
Attached or Remote
No
Initial Program Load
Firmware
Reliability & Maintainability
MTBF
MTTR
Diagnostic Programs
11,000 hours
28.6 minutes
Firmware/Software
Modular Building Blocks
Yes
Support Software
Assemblers
Compilers
Loader
Editor
Librarian
Debug Routines
Operat~ng Systems
Real-Tl.me OS
Self-hosted and crossBASIC/ALGOL/FORTRAN
Yes
Yes
Yes
Yes
Disk-based
Yes
Interrupts.
Prl.orl.ty Structure
Nesting Capability
Yes
Yes
110
APPENDIX K
HP2100A SYSTEM DESCRIPTION
Manufacturer
Hewlett Packard
Construction standard
Commercial
Maximum Physical Dimensions
12.3"Hx26.0"Dx16.8"W
Maximum Weight
111 lbs.
Maximum Power Consumption
800 watts
Architecture
Word Size
No. of Registers .
Inst. Execut~on T~me
Add/Sub/Load
M':1 l tiply
D~v~de
Microprogrammable
Technology
Privileged State
Stack
Main Mem9ry
Max~mum
.
Sl.ze
Speed
Word-size
Memory Pa~ity Checking
Memory Wr~te Protect
Technoloqy
Multiported
Instruction Set
Double Precision
Byte Manipulation
B~t Manipulation
Floating Point
Math/+rl.g Functions
Negat~on
Arl.thmetic Complement
Stack Manipulation
Addres!?ing
Dl.rect
Indirection
Indexing
Paging Hardware
~
16-bits
Two (accumulators)
1.96 usec
10.7 usec
16.7 usec
Yes (Writable Control store)
MSI/LSI
No
No
32K-words
0.98 usec
17-bit
Yes
Yes
Folded Planar Core
Three (CP/DMA-l/DMA-2)
Load/Store only
No
Yes
Yes
No
One's and Two's Complement
Two's Complement
No
2,048 words
Multi-level
No
No
111
I/O Controller
No. of Channels
Typ~s of Channels
MaX1mum Data Rate
Processor Independent
Serial/Parallel
Maintenance/Control Panel
Location
Multi-register displays
Front of chassis
No
Initial Program Load
Firmware
Reliability & Maintainability
MTBF
MTTR
Diagnostic Programs
14
1~OOOK-words/sec
D~A only
Unknown
Unknown
Software
Modular Building Blocks
Yes
Support Software
Assemblers
Compilers
Loader
Edi tor
Librarian
Debug Routines
Operat~ng Systems
Real-T1me as
Yes
FORTRAN/ALGOL/BASIC
Yes
Yes
Yes
Yes
Yes
Yes
Interrupts
pr10rity structure
Nesting capability
None
None
112
APPENDIX L
DEC PDP-l1/45 SYSTEM DESCRIPTION
Manufacturer
Construction Standard
Maximum Physical Dimensions
Maximum Weight
Maximum Power Consumption
Archi tec ture
Word Size
No. of Regis~ers .
Inst. Execut10n T1me
Add/Sub/Load
M':lltiply
D1v1de
Microprcgrammable
Technology
Privileged state
Stack
Main Mem<;>ry
.
MaX1mum S1ze
Speed
Word-size
Memory Pa~ity Checking
Memory Wr1te Protect
Technology
Multiported
Instruction set
Double Precisio n
Byte Manipulation
B1t Manipulation
Floati ng P"oin t
Math/~r~g Functions
Negat10n
Ar1thmetic Complement
Stack Manipulation
Addres~ing
D1rect
Indirection
Indexing
Paging Hardware
Digital Equipment Corporation
Commercial
71. 5" Hx 30. 0 II Dx21. 7" W
300 Ibs.
2,300 watts
16-bit (la-bit 'addresses)
16 (general)
0.3 usee
3.3 usec
7.5 usec
No
MSI/LSI
Two - Kernal & Supervisor
Yes
128K- words
0.3 to 0.98 usee
16-bit (18-bit for parity)
Yes
Yes
Core/MOS/Bipolar
Single - UNIBUS structure
Yes
Yes
Yes
Yes
Software
One's or Two's Complement
Two's Complement
Yes
256K-bytes
Yes
All general registers
Yes
113
I/O Controller
No. of Channels
Types of Channels
Maximum Data Rate
Processor Independent
Multiplexed UNIBUS
Serial/Parallel
2,500K-words/sec
Yes
Maintenance/Control Panel
Location
Multi-register displays
Front of chassis
Yes
Initial Program Load
Software
Reliability & Maintainability
MTBF
MTTR
Diagnostic Programs
Unknown
Unknown
Software
Modular Building Blocks
Yes
Support Softwar.e
Assemblers
Compilers
Loaaer
Editor
Librarian
Debug Routines
Operat~ng Systems
Rea l-T~me as
Yes
BASIC/FORTRAN/C
Yes
Yes
Yes
Yes
Yes
Yes
Interrupts.
structure
Nesting Capability
Pr~or~ty
Yes
Yes
114
APPENDIX M
VARIAN-73 SYSTEM DESCRIPTION
Manufacturer
Varian Data Machines
Construction Standard
Commercial
Maximum Physical Dimensions
14 n Hx20.5"Dx19"W
Maximum Weight
120 lbs.
Maximum Power Consumption
900 watts
Architecture
Word Size
No. of Registers
lnst. Execution Time
Add/Sub/Load
Ml;1ltiply
D~v~de
Microprogrammable
Technology
Privileged state
Stack
Main Mem9ry
Max~mum
.
S~ze
Speed
Word-size
Memory Parity Checking
Memory Write Protect
Technology
Multiported
Instruction Set
Double Precision
Byte Ma~ipulation
B~t
Man~pulat~on
Ploating Point
Math/+r1g Functions
Negat~on
Ar~thmetic
Complement
Stack Manipulation
Addressing
Direct
Indirection
Indexing
paging 8ardwa re
16-bit
16 (general)
0.66 usec !MOSI
4.95 usec MOS
5.61 usec MOS
Yes (Writaole Conteol Store)
MSI/LSI
No
No
262K-words
.33 usec(MOS)/.66 usec(Core)
16-bit
Yes
Yes
MaS/Core
Two (CP/DMA)
Yes
No
No
Software
Software
One's or Two's Complement
Two's Complement
No
2K-words
Multi-level
Yes
Yes
115
I/O Controller
No. of Channels
Types of Channels
Maximum Data Rate
Processor Independent
Multiplexed I/O Bus
Serial/Parallel
3,030K-words/sec
OMA only
Maintenance/Control Panel
Location
Multi-register displays
Front of chassis
No
Initial Program Load
Firmware
Reliability & Maintainability
MTBP
MTTR
Diagnostic Programs
Unknown
Onknown
Software
Modular Building Blocks
Yes
support Software
Assemblers
Compilers
Loaner
Editor
Librarian
Debug Routines
Operat~ng Systems
Real-Tl.me OS
Yes
BASIC/FORTRAN/RPG
Yes
Yes
Yes
Yes
Yes
Yes
Interrupts
pr~ority
structure
Nesting Capability
Yes
No
116
LIST OF REFERENCES
1.
Naval Material Command Instruction 5230.5A MAT-051/JBJ,
Qigi!g!
Ta£ti£~!
Subject:
~y§te~
QtfiQg
l!ADS Ol i
!!is§i2!! gnd fY..!!£tiQns QI, 8 October 1974.
2.
Naval Material Command TADSTAND
2~,
3.
1
MAT-09Y:EWC
Serial
Subject:
Naval
Material
Command
MAT-09Y:JER Serial 130,
~igital
.£2:£tical
TADSTAND
(Revision
~tand~rd
Subject:
~£Q.£~~Q£§
1
1)
Shi£Boa££
~g f.£Qg~ ~!ngua~,
29
May 1973.
4.
Naval
Material
TADSTAND
Command
MAT-09Y:JDC
Serial
~§cif~cation
12£
2
(Revision
1)
(Revision
1)
Subject:
299,
!g£ti£~b
Qocymen!atiQB, 1 November 1974.
5.
Naval
Material
Command
TADSTAND
MAT-09Y:JDC Serial 304, Subject:
!Q~
3
standard
R~guir~~ts
Inter-DiEital R£Q£~§§Q.£ !gte£!~£~ ~~~lltation, 5
November 1974.
6.
Naval
Material
113, Subject:
~y~!~~,
7.
Command TADSTAND 4 MAT-09Y:CFH
ll~!!g~Eg
Qefinitiol!
Subject:
2!£!!dard
~Q£ ~igital £2~ba! ~I§1~~
8.
Naval
Ta£!!£a!.
Qigitgl
MAT-09Y:CFH
Serial
6 April 1972.
Naval Material Command TADSTAND 5
134,
Qf
Serial
Material
148, Subject:
R~~£ve ~gEacity Regui£~~!l!§
gE2£§§§2£§, 9 May 1972.
Command TADSTAND 6 MAT-09Y:EWC
CO!Q~! 2Y§~~~ Desi~§
117
Serial
Employ!~g ~~1tiEle
Al!LUYK-l
9.
PrQ£~£2'
5 June 1972.
Naval Material Command TADSTAND 7
207,
~!~gsrd
Subject:
MAT-09Y:HLW
Serial
Di2~lal £Q!!..§21~,
Digital
25
July 1974.
10.
Chief
of
Serial
Naval
173,
Technical Training letter Code 314:JW
~tanda~dizatiQn,
11.
Weitzman,
~at~
Subject:
~!:oc~ssing
5 June 1974.
l1in!£Q!!ID!~~f:
C.
Im~!~~~ll!atiQQ
~@iE~nt
~~g
~I§~~~
lEE1!£ation,
~!!:.!!ctur~L
Prentice-Hall
Inc.,
1974.
12~
Naval
Electronics
Specification
ELEX-C-135,
Dai~L £Q~ba~ ~Y§te~,
13.
Systems
Command
Contract
£ompu!~£L
Title:
27 November 1972.
Naval Air Systems Command letter AIR-5333F3:ATS
~~~gsrd ~in!=UYli
unknown, Subject:
Qigital
Serial
Digital R£Q£g§§Q!:,
1 December 1972.
14.
Sansone,
Ih~
S.,
J.
!1!!!i-Digi!~! Pr~§Q.!:
ttQg~!
§.ianda£,g,
!~ctic2!
PrQ.£~!:~nt:
JANLQYK-2QlY1J..
~uty!:~
for
l!S!Y~§
Acguisit!Q!!§,
Research
Paper,
Industrial college of the Armed Forces, Washington,
e.,
15.
D.
1974.
Chief of Naval Material letter MAT-09Y:JER
§.tand~!:g
Subject:
November 1972.
16.
A
Department
~i!!i=Q!li
Qigi!~1
Serial 217,
PrQ~2§§Q£,
15
-
of
0967-LP-598-1000,
the
Navy .Technical
Q~ts
Proc~~sirrg ~~!
Manual
NAVELEX
AN/UYK-2QlYL'
v.
1-6, 1976.
17.
Department
of
the
Navy
Handbook
0967-LP-598-2000, Q~g£~§ li~!!gboQk
SUE..EQ!:!
Soft~£~,
v.
I-IV,
Systems, April 1976.
118
!liLYYK-2Q1YL
Sperry-UNIVAC
NAVELEX
Compu~~f
Defense
INITIAL DISTRIBUTION LIST
No. Copies
1.
2
Defense Documentation Center
Cameron station
Alexandria, Virginia 22314
2.
Library, Code 0212
2
Naval postgraduate School
Monterey, California 93940
3.
Department Chairman, Code 62
2
Department of Electrical Engineering
Naval postgraduate School
Monterey, California 93940
4.
Department Chairman, Code 54
2
Department of Administrative Sciences
Naval Postgraduate School
Monterey, California 93940
5.
Dean of Research, Code 023
1
Naval postgraduate School
Monterey, California 93940
6.
Assoc. Professor S. Jauregui, Code 62Ja
10
Department of Electrical Engineering
Naval Postgraduate School
Monterey, California 93940
7.
LCDR E. Zabrycki, Code 54Zx
Department of Administrative Sciences
Naval Postgraduate School
Monterey, California 93940
119
1
8.
LCDR Robert R. Joyce, USN
3987 Hischier Court
Napa, California 94558
1
9.
Commander, Naval Security Group Command
Naval security Group Headquarters
3801 Nebraska Ave., N.W.
Washington, D.C. 20390
ATTN: CDR H. Shoemaker, G82
LCDR F. Cleary
2
10.
Commanding Officer
Naval Electronic Systems Security
Engineering Center
Naval Security station
Nebraska Ave., N.W.
Washington, D.C. 20390
ATTN: Mr. D. Webster
1
11.
Commander, Naval Electronic Systems Command
Naval Electronic Systems Command Headquarters
1
ELEX-01
Washington, D.C. 20360
ATTN: RADM G. Smith
12.
Commander, Naval Electronic Systems Command
Naval Electronic Systems Command Headquarters
4
PME-107
Washington, D.C. 20360
ATTN: CAPT H. Leavitt
Mr. R. Materazza
LCDR R. Todaro
Mr. P. Lowell
13.
Commander, Naval Electronic Systems Command
Naval Electronic systems command Headquarters
PME-106
Washington, D.C.
20360
120
1
ATTN:
14.
CAPT J. Pope
Commander, Naval Electronic Systems Command
1
Naval Electronic Systems Command Headquarters
ELEX-570
Washington, D.C.
ATTN:
15.
20360
CAPT C. Hager
1
Chief of Naval Material
Naval Material Command Headquarters
NMAT-09Y
Washington, D.C.
20360
ATTN: CAPT Reiher
16.
Commander w Naval Electronics Laboratory Center
2
San Diego, California 92152
ATTN:
Mr. R. Eyres
Mr. B. Burris
17.
Director
1
National Security Agency
Group W
Ft. George G. Meade, Maryland 20755
ATTN:
18.
Mr. J. Boone
Electromagnetic Systems Laboratories, Inc.
1
495 Java Drive
Sunnyvale, California 94086
ATTN:
19.
Mr. B. Barr
Sanders Associates
1
95 Canal Street
Nashua, New Hampshire 03060
ATTN:
20.
Mr. W. Zandi
Naval Communications station, Rota
NAVSECGRU Department
FPO, New York 09540
ATTN:
CDR R. Shields
121
1
21.
Commanding Officer
Fleet Combat Direction System
2
support Activity
San Diego, California 92147
ATTN:
LCDR J. Roudebush
Mr. V. Khosharian
22.
Commanding Officer
1
Naval Electronic Systems Engineering Center
P.O. Box 80337
4297 Pacific Highway
San Diego, California 92138
ATTN:
Mr. C. Benson
122
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37 Create Date : 2014:01:31 15:40:05-08:00 Modify Date : 2014:01:31 15:20:32-08:00 Metadata Date : 2014:01:31 15:20:32-08:00 Producer : Adobe Acrobat 9.55 Paper Capture Plug-in Format : application/pdf Document ID : uuid:6ccc0551-79de-4b00-a001-3ac6b79c4fbb Instance ID : uuid:8bb4f3cb-c211-46b9-9c15-d2493b53cbc5 Page Layout : SinglePage Page Mode : UseOutlines Page Count : 123EXIF Metadata provided by EXIF.tools