AD-A145 697 PRgjEDINGS PAPF S OF THE AFSC (AIR FORCE SYSTEM /

A0..SAN
WRIGHT-PATTERSON U ARNATICLSYTM
AFB OH DIRECTORATEC~ND I

UNCLASSIFIED C A PORUBCANSKY NOV8 F/G 1/3 N

I mmeeEUEEEml
if illiili
IIIllflIfflfflfIIlfllf
EEEEEEEIhIIIEE
EllEEEllEEEEEE
Sllflfllllflfllflflfl

IIEEEIIIEIII
 1-

12 1-
 2nd AFSC
STANDARDIZATION
r CONFERENCE
COMBINED PARTICIPATION BY:
I DOD-ARMY-NAVY-AIR FORCE-NATO

30 NOVEMBER -2 DECEMBER 1982

TUTORIALS: 29 NOVEMBER 1982

DAYTON CONVENTION CENTER

DAYTON, OHId

SPONSORE By: POSTED mY

ADDENDUM
To The .
PROCEEDINGS. (

Approved for Public Release Distribution Unlimited

84 09 05 095
 NOTICE

When Government drawings, specifications, or other data are used for any purpose
other than in connection with a definitely related Government procurement operacion,
che united States Government thereby incurs no responsibility nor any obligation
w atsoever; and the fact that the government may have formulated, furnished, or in
any way supplied the said drawings, specifications, or other data, is not to be re-
garded by implication or otherwise as in any manner licensing the holder or any
3:her person or corporation, or conveying any rights or permission to manufacture
Luse, or sell any patented invention that may in any way be related thereto.

This report has been reviewed by the Office of Public Affairs (ASD/PA) and is
releasable to the National Technical Information Service (NTIS). At NTIS, it will
be available to the general public, including foreign nations.

This technical report has been reviewed and is approved for publication.

JEFFERY L. PESLER ERWIN C. GANGL

4 Vice Chairman Chief, Avionics Systems Division
,nd AFSC Standardization Conference Directorate of Avionics Engineering

MMANDER

ROBERT P. LAVOIE, COL, USAF

O;rector of Avionics r;ngineering
eputy for Engineering

: io z address has changed, -f you wish co be re.oved from our mail=; , 4r

. ressee s no longer employed by your organization please not-fV ASD/ENAS
'-=AF3, :H 45433 to help us aintain a current ,aiing list".

:-'i* repor: should not be returned unless return is required bi sec -=I-

3n : era :ons, crntractual obligations, or notice on a specific document.

.N-
 UNCLASSIFIED
SECURtT'V CLASSIFICATION Of THIS PAGE fWhIen DOt Entered)
READ INSTRUCTIONS
REPORT DOCUMENTA.TION PAGE BEFORE COMPLETING FORM
I RE*OR- NUMBER 2. G TA.J NO RECIPIENTIS CATALOG N MIER

SD(ENI.)-TR-82-5O31, VOLUME X/7_____________

4 TITLE (and Subtitle) S, TYPE OF REPORT & PERIOC COVEr'E.
Final Report
Proceedings Papers of the Second AFSC Avionics 29 November - 2 December 1982
Standardization Conference PERFORMING 010. REPORT NuMRLR

4 7 AUTtOR~s) I. CONTRACT OR GRANT NUMBERfs)

Editor: Cynthia A. Porubcansky

9. PERF RMING ORGANIZAT-ON NAME AND ADDRESS 10 PROGDAM ELEMENT.PROJECT TASK

AREA & WORK UNIT NUMBERS

HQ ASD/ENAS
Wright-Patterson AFB OH 45433
11 CONTROLLING OFVICE NAME AND ADORESS 12. REPORT DATE
HO ASDIENA November 1982
Wright-Patterson AFB OH 45433 13. NUMBER OFPAGES

14 MONITORING AGENCy NAME & ADDRIESS(aI different

t ra
e Controllinj Office) 15. SECURITY CLASS. (ol this report,.

Same as Above Unclassified

15a. DECLASSIFICATION DOWNGRADING

SCHEDULE

16. DISTRIBUTION STATEMENT (of this Report)

Approved for public release; distribution unlimited.

17. DISTRIBUTION STATEMENT (of the absetrat entered in Block 20. if dillerent from Report)

N/A

Is. SUPPLEMENTARY NOTES

N/A

IS. KEY WORDS (Contiue on revese aide It neceseary and identify by lock umuber)
Computer Instruction Set Architecture, Muttiplexing, CompiLers, Support Software,
Data Bus, Rational Standardization, Digital Avionics, System Integration, Stores
Interface, Standardization, MIL-STD-1553, MIL-STD-1589 (JOVIAL), MIL-STD-1750,
MIL-STD-1760, MIL-STD-1815 (ADA), MIL-STD-1862 (NEBULA).

20. ABSTRACT (Cminue n reverse side It neceosary and identify by block malmbner)
This is a coLection of UNCLASSIFIED papers to be distributed to the attendees
of the Second AFSC Avionics Standardization Conference at the Convention Center,
Dayton. Ohio. The scope of the Conference inctudes the complete range of DoD
approved embedded computer hardware/software and related interface standards as
wetL as standard subsystems used within the Tri-Service community and NATO. The
theme of the conference is "Rational Standardization". Lessons learned as well
as the pros and cons of standardization are highlighted.

DD 1JaN 1473 EOITION OF INOV 03 ISOISOLETE CLASSIFIED

SECURITY CLASSIFICATION OF THIS PAGE (Woen Data Cnlered)
 This Is Volume 10
Volue
u
1 Pr g Ipp. 1-560
Vo me 2 Pcomed~ins pp. 561-1131
V0liin 3 QWn0dM rnaNWit
Volume 4 MZL-SD-1553 Tutorial
Volume 5 -I.SM-1589WtbriAl
Volm 6 MLL-M"?o-1679 Tutorial
Volume 7 KU,LSM-1750 trji-iaa
Volumea 8 Ml,-STM-1815 TItonal
iVolum Volum 910 Navy
AdfxCase toSt14-
te Tutorial
knomUnps

PROCEEDINGS OF THE

2nd AFSC
STANDARDIZATION CONFERENCE

30 NOVEMBER - 2 DECEMBER 1982

Aooession For
NTIS MR&I
DTIC TAB
DAYTON CONVENTION CENTER uffianno d ,Qe
Just ification
DAYTON, OHIO
Distribution/
Availability Codes
~Avail and/or
Dist Special

Sponsored by: Hosted by: a,.-

Air Force Systems Command Aeronautical Systems Division

-- 9
------- .\--t ots Jf
 FOREWORD

THE UNITED STATES AIR FORCE HAS COMM4ITTED ITSELF TO "STANDARDIZATION."

THE THEME OF THIS YEAR'S CONFERENCE IS "RATIONAL STANDARDIZATION," AND WE
HAVE EXPANDED THE SCOPE TO INCLUDE US ARMY, US NAVY AND NATO PERSPECTIVES
ON ONGOING DOD INITIATIVES IN THIS IMPORTANT AREA.

WHY DOES THE AIR FORCE SYSTEMS CONMMAN D SPONSOR THESE CONFERENCES?
BECAUSE WE BELIEVE THAT THE COMMUNICATIONS GENERATED BY THESE GET-TOGETHERS
IMPROVE THE ACCEPTANCE OF OUR NEW STANDARDS AND FOSTERS EARLIER, SUCCESSFUL
IMPLEMENTATION IN NUMEROUS APPLICATIONS. WE WANT ALL PARTIES AFFECTED BY
THESE STANDARDS TO KNOW JUST WHAT IS AVAILABLE TO SUPPORT THEM: THE
HARDWARE; THE COMPLIANCE TESTING; THE TOOLS NECESSARY TO FACILITATE DESIGN,
ETC. WE ALSO BELIEVE THAT FEEDBACK FROM PEOPLE WHO HAVE USED THEM IS
ESSENTIAL TO OUR CONTINUED EFFORTS TO IMPROVE OUR STANDARDIZATION PROCESS.
WE HOPE TO LEARN FROM OUR SUCCESSES AND OUR FAILURES; BUT FIRST, WE MUST
KNOW WHAT THESE ARE AND WE COUNT ON YOU TO TELL US.

AS WE DID IN 1980, WE ARE FOCUSING OUR PRESENTATIONS ON GOVERNMENT

AND INDUSTRY EXECUTIVES, MANAGERS, AND ENGINEERS AND OUR GOAL IS TO
EDUCATE RATHER THAN PRESENT DETAILED TECHNICAL MATERIAL. WE ARE STRIVING
TO PRESENT, IN A SINGLE FORUM, THE TOTAL AFSC STANDARDIZATION PICTURE FROM
POLICY TO IMPLEMENTATION. WE HOPE THIS INSIGHT WILL ENABLE ALL OF YOU TO
BETTER UNDERSTAND THE "WHY'S AND WHEREFORE '5" OF OUR CURRENT EMPHASIS ON
THIS SUBJECT.

MANY THANKS TO A DEDICATED TEAM FROM THE DIRECTORATE OF AVIONICS

ENGINEERING FOR ORGANIZING THIS CONFERENCE; FROM THE OUTSTANDING TECHNICAL
PROGRAM TO THE UNGLAMOROUS DETAILS NEEDED TO MAKE YOUR VISIT TO DAYTON, OHIO
A PLEASANT ONE. THANKS ALSO TO ALL THE MODERATORS, SPEAKERS AND EXHIBITORS
WHO RESPONDED IN SUCH A TIMELY MANNER TO ALL OF OUR PLEAS FOR ASSISTANCE.

ROBERT P. LAVOIE, COL, USAF

DIRECTOR OF AVIONICS ENGINEERING
DEPUTY FOR ENGINEERING
 DEPARTMENT OF THE AIR FORCE

A'Q=R--%S AIR =e-RCZ z: z1?4I

Z::s

2 8 AUG 11932
%%:%B.VTO C
;T"* Off

Second WSC Standardization Conference

-o ASD/CC

1. Since the highly successful standardization conference hosted by ASD in

1980, significant technological advancements have occurred. Integration of
the standards into weapon systems has become a reality. As a result, w have
many *lessons learned* and cmt/benefit analyses that should be shared within
the tri-servioe community. Also, this would be a good opportunity to update
current and potential "users.* Therefore, I endorse the organization of the
Second WSC Standardization Conference.
2. This conference should coer the current accepted standards, results of
recent congressional actions, and standards planned for the future. We should
provide the latest information on policy, system applications, and lessons
learned. The agenda should accmmodate both governent and industry inputs
that criticize as well as support our efforts. Experts from the tni-service
arena should be invited to present papers on the various topics. r AFSC
project officer, Maj David Hamond, I AFWSC/ALR, AUm0 858-5731, is prepared
to assist.

ROBERT M. BOND, Lt Gen, USAJE

Vice Ccmmander

iv

,L111: .rr.,,,,,, ., ,, ,,.., , ,..a .;, <. . .N ,&. ,%.. 1

 2nd AFSC STANDARDIZATION CONFERENCE

ORGANIZATION COMMITTEE

EXECUTIVE CHAIRMAN
Erwin C. Gangl

EXECUTIVE VICE CHAIRMAN

Jeffery L. Pesler

PROGRAM CHAIRMAN
Jerry L. Duchene

CO-CHAIRMAN CO-CHAIRMAN
Harold J. Alber Maj Lee Cheshire

CO-CHAIRMAN CO-CHAIRMAN
David J. Krile John Slivinski

EXHIBITS CHAIRMAN PUBLICATIONS CHAIRMAN

Lt C.W. (Bud) Meyaard Cindy Porubcansky

SPECIAL ARRANGEMENTS CHAIRMAN PROTOCOL OFFICER

Lt Dennis A. Shoulders Capt Francis A. DeCurtis

ADMINISTRATIVE CHAIRMAN TREASURER

Marie P. Jankovich Richard H. McBride

CONFERENCE MANAGER
Systems Productivity & Management Corporation

V
 Table of Contents Volume 10

Luncheon Speakers PAGE

A Reflection on Standardization, Major General Marc C. Reynolds 5

Commander, Air Force Acquisition Logistics Division, WPAFl, OH

A Major Tri-Service Contractor's Viewpoint on Military 10

Standardization, A.M. Lovelace, Corporate Vice
President, Productivity and Quality Assurance,
General Dynamics

The Teocmplegy Vector, Charles P. Locht, President, 23

Lecht Sciences, Inc.

xecutM Session

Opening Reathr to the 2nd AISC Standardization Conference, 37

Lieutenant General Tboms N. eNeullen, Commander,
Aeronautical System DlvLsion, WPAFB, O

The Department of Defense Perspective on Standardization, 51

William A. Long, Deputy Under Secretary of Defense for
Research and Engineering (Acquisition ManaSement)

P
V4
 Table of Contents

PAGE

The Air Force Perspective on Standardization, Major General 57

Jasper A. Welch, Jr., Assistant Deputy Chief of Staff,
Research and Development

Embedded Computer Standardization in the Navy: An Overview, 85

Rear Admiral Wayne D. Bodensteiner, Deputy Chief of
Naval Material for Acquisition

The Army's Perspectives on Standardization of Computer 147

Hardware and Software, Brigadier General Robert D.
Morgan, Deputy Commanding General for Research and
Development

UK MOD Activity In Airborne Digital System Standards, Dr. 157

A.A. Callaway, Royal Aircraft Establishment

Polcy Session and Panel Discussion

Understanding DoDs Standardization Objectives for Mission 165

Critical Computers, D. Burton Newlin, Jr., Office of
Under Secretary of Defense (Research and Engineering),
Defense Materiel Specifications and Standards Office

Air Force Standardization Activities, Colonel Edward T. 175

Akerlund, HQ AFSC/ALR

Vii

- '% - ~~% ~. , ]
Table of Contents

PACE

Embedded Computer Standardization in the Navy - Policy and 183

Practice, Captain David L. boslaugh, HQ NAVMATCOM

Army Standardization Activities, Colonel J. Frank Campbell, 197

HQ DARCOM

Joint Logistics Commanders Joint Policy Coordinating Group 211

for Computer Resource Management, Colonel John J.
Marcinlak, RADC/CO

Managing Tactical Embedded Computer Resources (TECR) In 221

the Naval Sea Systems Command, CDR John Stewart and
T.L. Wallis, NAVSEASYSCOM

MIL-STD-1589 Jovial (J-73) High Order Language

Jovial Standardization, Austin J. Maher, The Singer 237

Company - Kearfott Division

MIL-STD-1760 Standard Store Interface

Opening Remarka and Air Force Overview of MIL-STD-1760, 245

Major L.S. Dougherty, RQ USAF/RDPV

Navy Perspective on NIL-STD-1760, Gerald E. Kovalenko, 255

ATASISCMViii
Table of Contents

MIL-STD-1815 Ada High Order Language

PAGE

-Use of ADA in System Design: A Case Study, Hal C. 267

Ferguson and Michael B. Patrick, General
Dynamics, Ft Worth, TX

Standardization Issues - Near Term

Successful Development and Supply of Standardized 287

Computer Hardware and Software During a
Period of Rapid Technological Change, K.B.
Dixon, Ferranti Computer Systems Limited

The AN/UYK-43(V) and AN/UYK-33(V): A Program 303

Overview, Captain James P. O'Donovan,
NAVSEASYISCOM

AN/AYK-14(V) Standard Airborne Computer, Henry R. 326

Mendenhall, NAVAIRSYSCOM

Advanced Systems Architecture

B-lB Avionics Applications of Military Standards, 341

L.M. Carrier and G.A. Kinstler, Rockwell
International

ix

Lim - . .. . .
 Table of Contents

3PAGE

Standards Application to B-lB Avionics Program, 359

l.L. Ernst, Boeing Military Airplane Company

The Digital Interface Chalenge

HH-60D Advanced Avionics Architecture, Ira Glickstein, 381

IBM Federal Systems Division

Fairchild's Data Transfer System - Utilizing the 389

Latest Military Standards, Stephen L. Belechak-
Becraft and George D. Farmer, Fairchild Space
and Electronics Company

The Fairchild MIL-STD-1553 Serial Multiplex Bus 423

Tester, Alan M. Dunn, Fairchild Space and
Electronics Company

Software Engineering Series In the Federal Government, 435

Gwendolyn E. Hunt, Systems Technology Office,
Pacific Missile Test Center

Standardzation Issues of the Future

The Application of Standard System Specification

Techniques to the Design of Very Large Scale
Integrated Circuits, David Jordan, Marconi
Avionics Limited

x
Table, of Contents

Advanced Standardized Systems/Subsystems

PAGE

Computer Standardization In the Submarine Advanced 467

Combat System (SUBACS), Ronald L. Ticker,
NAVSEASYSCOM

Computer Standardization in the Swedish Air Force, 477

Gosta Elg, Sweden Defense Materiel Administration

Navy Real Time Signal Processor Development: Second 501

Generation Planned Service Standard, C.B. Robbins,
5NAVSEASYSCOM

Standardized Software Development

Status of MIL-STD-1679A: An Overview, William Egan, 517

Naval Materiel Command

xi
 1*MM ME91P W73.

Authors Index

hkerlund, Edward T., 175 Lecht, Charles P., 23

Long, William A., 51
Lovelace, A.M., 10

Belechak-Becraft, Stephen L., 389

Bodensteiner, Wayne D., 85
Boslaugh, David L., 183 Maher, Austin, 237
Marciniak, John J., 211
Mendenhall, Henry H., 326
Morgan, Robert D., 147
Callaway, A.A., 157
Campbell, J. Frank, 197
Carrier, L.M., 31
McMullen, Thomas H., 37

Dixon, K.B., 287

Dougherty, L.S., 245 Newlin, D. Burton, 165
Dunn, Alan M., 423

O'Donovan, James P., 303

Egan, William, 517
Elg, Gosta, 477
Ernst, H.L., 359
Patrick, Michael B., 267

Farmer, George D., 389

Ferguson, Hial C., 267
Reynolds, Marc C., 5
Robbins, C.B., 501

Clicketein, Ira. 381

Stewart, John, 221

Hunt, Gwendolyn E., 435

Ticker, Ronald L., 467

Jordan, David, 455

Wallis, T.L.. 221

Welch, Jasper A..'
Kinatler, G.A., 341
Kovaleiko, Gerald E., 255

Xii
± . F A A

EXHIBITORS

ARINC RESEARCH RAYCHEM

BENDIX RAYTHEON
BOMAR INSTRUMENTS RCA
CIRCUIT TECHNOLOGY ROLM
CONTROL DATA CORPORATION SANDERS ASSOCIATES
DELCO ELECTRONICS SCI SYSTEMS
FAIRCHILD CAMERA 8 INSTRUMENTS SEAFAC
FAIRCHILD SPACE & ELECTRONICS SINGER KEARFOTT
GARRETT SMITH INDUSTRIES
GENERAL DYNAMICS, FT. VORTH SOFTECH
GENERAL ELECTRIC SPECTRAL SYSTEMS
GRUMMAN AEROSPACE SPERRY UNIVAC
HARRIS SEMICONDUCTOR STC COMPONENTS
IEEE SYSTEM PRODUCTIVITY & MANAGEMENT
ILC/DATA DEVICE CORPORATION SYSTEMS RESEARCH LAB
INTELLIMAC TELEDYNE SYSTEMS
INTERMETRICS TELEFONAKTIEBOLAGET LM ERICSSON
KAISER TEST SYSTEMS
LITTON TROMPETER
LORAL TRW
McDONNELL DOUGLAS ASTRONAUTICS UTC/MOSTEK
NORTHROP WESTINGHOUSE DEFENSE

xiii

....
......
 LUNCHEON SPEAKERS

00
Tuesday Luncheon
Keynote Speaker

Major Gensal Marc C. Reynolds

Major General Marc C. Reynolds is Commander of the Air Force Acquisition

Logistics Division, and Deputy Chief of Staff for Acquisition Logistics,
Air Force Logistics Command, Wight-Patterscn Air Force Base, Ohio.

General Reynolds was born in (unbeerlain, S.D., on June 2, 1928, and

graduated from Chamberlain High School in 1946. He subsequently attended
Dakota Wesleyan University and the University of Denver until the outbreak
of the Korean War. He holds a Bachelor's Degree in Political Science
from the University of Rhode Island and is a graduate of the Air COmmand
and Staff College and the Naval War College.

General Reynolds entered the Air Force as an aviation cadet in January

1951 at Perrin Air Force Base, Texas, and was cummissioned upon graduation
from pilot training at Vance Air Force Base, Okalahma, in February 1952.
He then attended jet interceptor training at Moody Air Force Base, Georgia,
and Tyndall Air Force Base, Florida.
In July 1952, General Reynolds was assigned pilot duty with the 83rd
Fighter-Interceptor Squadron at Hailton Air Force Base, California, and in
September he moved with the squadron to Paine Air Force Base, Washington.
In March 1953, he was transferred to the 4th Fighter-Interceptor Squadron
at Naha Air Base, Okinawa, where he continued to serve as a fighter-interceptor
pilot, flying the F-94B.
His next assignment, in September 1954, was Otis Air Force Base, Mass.,
where he served with the 437th and 60th Fighter-Interceptor Squadrons as a
tactical and training flight cuumander, flying the F-94C and F-101B, and
with the 602d Consolidated Maintenance Squadron as a maintenance officer.

General Reynolds was transferred to Europe in November 1961, assigned

to the 10th Tactical Reconnaissance Wing, with duty at RAF Station Brunting-
thorpe, England, as a Flight Commander, and later at Toul-Rosieres Air Base,
France, as Chief of the Wing Standardization Evaluation Branch.
After Command and Staff College at Maxwell Air Force Base, Alabama,
General Reynolds was assigned to the 22d Tactical Reconnaissance Squadron,
Mountain Home Air Force Base, Idaho. In November 1966, he mroved to the
460th Tactical Reconnaissance Wing at Tan Son Nhut Air Base, Republic of
Vietnam, and flew 230 cambat missions over North and South Vietnam in RF-4C.

(over)

3
IS -BlAN
IItVIOU PAGE E ]
 Following his Southeast Asia tour, he served in Japan as Deputy Chief
of the Reconnaissance Division, Headquarters Fifth Air Force, Fuchu Air
Station. In April 1970, he moved to Misawa Air Base as mmrkander of the
16th Tactical Reconnaissance Squadron.
General Reynolds returned to the United States in February 1971, assigned
to Shcw Air Force Base, S.C., where he served as Assistant Deputy Coniander
for operations in the 363d Tactical Reconnaissance Wing. He attended the
Naval War College at Newport, R.I., in 1972-73 and was subsequently assigned
to Ogden Air Logistics Center, Hill Air Force Base, Utah, initially as the
Director of Distribution and later as Director of Maintenance. In July 1976,
he was transferred to McClellan Air Force Base, California, as the Director
of Materiel Management, Sacramento Air Logistics Center. In March 1978, he
became the Center Vice Coaunander. He transferred to the Air Force Acquisition
Logistics Division in May 1980, where he served as Vice Commander until
October 1981, when he assumed his present duties.

General Reynolds is a command pilot with more than 5,200 hours flying
time, including 475 cumbat hours. His military decorations and awards
include the Distinguished Service Medal, Legion of Merit, Distinguished
Flying Cross, Meritorious Service Medal with one oak leaf cluster, Air Medal
with 15 oak leaf clusters, and Air Force Camindation Medal with two oak
leaf clusters.

e was promoted to Major General Sept 8, 1980, with date of rank July 1, 1977.

General Reynolds was married to the former Judy Coppage of Falmouth,

Mass., who died in February 1982. Their children are Barbara and Scott.

4
MAJOR GENERAL MARC C. REYNOLDS

COMMANDER

AIR FORCE ACQUISITION LOGISTICS DIVISION

WRIGHT-PATTERSON AIR FORCE BASE, OHIO

-L

LUNCHEON SPEECH TO 2D AFSC STANDARDIZATION CONFERENCE

STOUFFER'S DAYTON PLAZA HOTEL
30 NOVEMBER 1982

"A REFLECTION ON STANDARDIZATION"

,1.

" r"' .. r' r, r 5 ~, C ' ''M ,? ?.

*6'""
*,
 It's a pleasure to be here today. As some of you know, I have more
than~ a passing interest
in standardization. So the opportunity to be one of your speakers is
welcome.
I've looked over the schedule of events for this week. It's quite evident
you'll be getting a
concentrated dose of standardization. You've already had a day of tutorials
since it gives all of us a chance who don't specifically work which I endorse
in the area to get at
least a baseline of understanding. This morning you heard the
General McMullen, who set the stage for keynote speech by
this conference. By the time the conference
completed, you'll have covered a variety of service perspectives, as well
international level. In addition, you will have covered a session on as the DOD andIs
policy
working sessions specifically addressing the various architectural standardsand a number of
that we in the
avionics and armament community deal with daily.
Clearly, the last thing you need from me today is yet another dissertation
on the details of
standardization. So, rather than preach to the choir, I ask you to step back
and share my perspective on standardization. Simply stated, we're for the moment
increase the effectiveness of our combat wings, and I think standard always striving to
potential in this arena. Reduced cost of operation is certainly a factor; izatiion ol fer.
however, combat
effectiveness is the first prize.
There are many -facets to standardization. There are techical issues, policy issues.
budgeting issues, programmatic issues, logistics support issues and,
not to be forgotten,
cultural blocks. They all come into play.
Then of course there is the basis for standardization. From a military
most recently from our Vietnam experiences. sense, it's rooted
There is no doubt that the lack of
standardization complicated an already complex and stretched logistics
undoubtedly resulted in reduced sortie rates. Another factor thiat has become pipeline and
the standardization scenario, however, more subtle, is that we have dominate in
an aging inventory of
airplanes, an inventory where three-fourths of the force is over 9 years
30 years ago, only 14% of our fleet was over 9 years old. Further, the old. By contrast,
will continue and be compounded. By the early 1990's our force structure aging of the fleet
will
its current size. We'll be keeping some aircraft as long as 40 years. Avionics be two-thirds
ago stayed for the life of the airplane now must be changed out every few that not long
trends verify this and, in my opinion, point directly to an opportunity for years. Rerent
those of w;~ who
are standardization advocates to excel.
Another factor that points to standardization is our people problem. If
we allow systc, -! to
profilerate without standard patterns, it is doubtful that our training
Architectural standards, like those being discussed at this conference, andsystem can ctipe.
function standards permit us to build and sustain combat skills faster and form, fit, and
more effect i"v ..
Again, however, standardization should be applied when and where it makes sense. Tyat"
the reason for the term "rational standard ization"--the theme of this conference.
for a standard is that it be transparent to technology. We need to be able to One test
introdu. - *e
technology when needed as soon as we can.

6
 Standardization injects discipline into the acquisition and support process. It's the
discipline that's important here. Manufacturers have historically depended upon this
discipline in their operations. In the commercial arena, as well as in military markets,
companies use their own standards. They expect their suppliers to meet these as well as
industry standards in the production of their products. The production line is nothing more
than the application of a standardization policy. The whole process is geared to save time,
save money, and preclude individual handcrafted parts. Industry approaches
standardization for at least two reasons. First, its sameness. Each product is
interchangeable with another. Second, it's a guarantee that the product meets a certain
4 property.

The airlines, too, offer an example of rational standardization. They devise standards for
their own use. They voluntarily sign up to use them--because they make sense. They
standardize as much as possible. About 50% of their equipment meet ARINC standards.
The mission and traffic control equipment which includes radios, inertials, and weather
radar is standardized in upwards of 90% of their fleet. The rest do not meet standards
because each carrier has peculiar needs or finds no compelling economic reason to do so.
This is rational standardization at work. In the military environment there is no
comparable economic reason for standardization. The closest financial measure is oriented
around the annual budget exercises. But, the true measure is combat capability and, as you
might imagine, this is sometimes difficult to measure.

4 Standardization has to be a conscious effort on the part of all those concerned--the user,
the acquisition and logistics support communities, plus the aerospace and avionics industry.

We understand that introducing standards is no easy task. The acquisition process is geared
around optimal acquisition of individual weapon systems--not always optional acquisition of
a force structure. Therefore, it places the aerospace companies in a peculiar position.
Going a standard approach exposes the primes to potential loss of follow-on procurements
and modification programs. Our policy is to maintain competition--but we recognize that
industry performs when the profit incentive works, and the potential for profit is evident.
We can ill afford to allow our aerospace industry and its subtier vendors to erode any more.

The requirement as I see it is quite clear. We neeNJ the standards like the ones you're
working on here at this conference. We also need F standards to facilitate transition of
new technologies as they come along, and we shouldn't rest on those laurels. We have to
work on future aircraft and the requirements of our current aircraft to operate against
future threats. This may necessitate new standards.

The challenge is varied. If we seriously intend to support a combat ready and combat
capable force, then we need your support. For those of you from the using commands, it's
necessary for you to not only identify your needs but make it abundantly clear the role and
need for standards in your operations. You cannot afford aircraft down for long periods
A because of mod work that otherwise could be shorter had the new equipment been
standardized. Software is beginning to emerge as a prime issue in the mod business. A
standard higher order language alleviates many problems--but maybe we can do more.

7
The programmatic area needs more emphasis. Unfortunately, the acquisition process
optimizes on single weapon systems. Its emphasis on project management, with its focus on
cost, schedule, and performance, tends to shift away from standards. The focus being
narrower than the overall Air Force sometimes leads to non-optimum decisions.

For our industry participants, we need your support in making the use of standards a
reality. Work with us and show us how to make standardization possible without
jeopardizing your markets and ultimately the industrial base. As I've said, we need
standardization for combat capability, but we won't get there without your help.

Finally, to all the participants, both government and industry, I personally appreciate your
efforts. What you're doing in your day-to-day efforts is being felt and is making our force
structure more productive.

I see this conference as a productive effort. Again, thanks for inviting me.

8
 - - 7, -. ~

Wednesday Luncheon
Keynote Speaker

Dr. Alan M. Lovelace

4 Effective 1 Sep 82, Dr. Lovelace was namled VP, Productivity and Quality
Assurance.

Dr. Lovelace joined General Dynamics Corpora~tion as Vice President,

Science and Engineering in July 1981. He had served as Acting Administrator
of the National Aeronautics and Space Administration since January of 1981.

Dr. Lovelace joined NASA in 1974 as Associate Administrator for the

Office of Aeronautics and Space Technology. He was named Deputy Adminis-
trator in June 1976 by President Ford.

Since entering federal service with the U.S. Air Force in 1954, he has
held many research management positions. He served at the Air Force
Materials Laboratory, Wright-Patterson Air Force Base, Ohio, from 1954
through 1972, having been named Director in 1967.

From 1972 to 1973, he served as Director of Science and Technology

with the Air Force Systems Commnand, Andrews AFB, Washington, D.C. From
1973 to 1974, Dr. Lovelace was Principal Deputy Assistant Secretary of the
Air Force for Research and Deveopnen&t.

Dr. Lovelace retired as Deputy Administrator of NASA in December 1980,

but stayed with the Administration through the first flight of the Space
Shuttle Columbia and the appointmnt of a new Administrator.

Born in St. Petersburg, Florida, in 1929, Dr. Lovelace received Bachelor's,

Master's and Doctoral Degrees in Cheidstry fran the University of Florida.
Awards he has received include the Presidential Citizens Medal, the Depart-
mrent of Defense Exceptional Service Medal, the Air Force Decoration for
Exceptional Service, the National Civil Service League Career Service Award,
and the Office of Aerospace Research Award for outstanding Contriubitons
to Research.
fie is a Fellow of the American Institute of Aeronautics and Astronautics
and the American Astronautical Society, and is a merrber of the National
Academry of Engineering', Air Force Association, Sigma XI and Phi Beta Kappa.

9
 LUNCHEON SPEECH
2ND AFSC STANDARDIZATION CONFERENCE
"A MAJOR TRI-SERVICE CONTRACTOR'S VIEWPOINT
ON MItITARY STANDARDIZATION"
A. M. LOVELACE

1 December 1982

%'~-II
Will.
MY REMARKS TODAY WILL EXPLORE STANDARDIZATION FROM THE POINT OF
VIEW OF A MAJOR DEFENSE CONTRACTOR, A CONTRACTOR THAT INTER-
FACES WITH ALL OF THE SERVICES AND WITH THE DEPARTMENT OF DEFENSE.

I WILL BE ADDRESSING THIS SUBJECT BY (1)OFFERING SOME OBSERVATIONS

ABOUT THE NATURE AND APPLICATION OF STANDARDS, (2)BY OUTLINING
THE APPLICATION OF STANDARDS IN THREE EXAMPLES OF GENERAL DYNAMICS'
PRODUCTS THAT WERE, OR ARE BEING, DEVELOPED BY DIFFERENT DIVISIONS
FOR DIFFERENT DOD CUSTOMERS, AND (3)AFTER TAKING THIS LOOK AT
STANDARDS IN PRACTICE, I WILL OFFER SOME GENERAL IDEAS ABOUT THE
IMPACT OF STANDARDIZATION ON THE DoD CONTRACTOR COMMUNITY. FINALLY,
I WILL CLOSE WITH SOME COMMENTS ON THE RELATIONSHIP BETWEEN STANDARDS
AND TECHNOLOGY. MY REMARKS TODAY, OF COURSE, WILL BE DIRECTED AND
LIMITED TO THOSE DIGITAL PROCESSING, COMPUTER LANGUAGE, AND INTER-
FACE STANDARDS OF PARTICULAR INTEREST TO THIS CONFERENCE.

I'VE DEALT WITH PROS AND CONS OF STANDARDS FOR SOME TIME NOW AND
HAVE SEEN THE ISSUES FROM A VARIETY OF PERSPECTIVES. CURRENTLY,0
IAM WORKING TO IMPROVE PRODUCTIVITY AND QUALITY THROUGHOUT THE
CORPORATION.
MANY PRODUCTIVITY AND QUALITY IMPROVEMENTS ARE, OF COURSE, TIED

TO STANDARDIZATION, STANDARDIZATION IS A PREREQUISITE TO VOLUME

PRODUCTION, LET ME CLARIFY, HOWEVER, THAT STANDARDIZATION AND

COMMONALITY ARE NOT THE SAME THING,

STANDARDIZATION TS THE RESULT OF A TECHNICAL DECISION THAT

PROVIDES A BASIS OR OPPORTUNITY FOR COMMONALITY. COMMONALITY,

HOWEVER, IS THE RESULT OF A PROCUREMENT DECISION, IN OUR COMPANY,

WE MAKE PROCUREMENT DECISIONS FAVORING COMMONALITY AND THEREBY

REALIZE THE LOGICAL OUTGROWTH OF STANDARDIZATION. CONSEQUENTLY,

FROM A PRODUCTIVITY AND QUALITY ASSURANCE STANDPOINT, STANDARDI-

ZATION AS A BASIS FOR COMMONALITY IS UNBEATABLE. COMMONALITY

ALLOWS VOLUME PRODUCTION WITH ASSOCIATED IMPROVEMENTS IN TOOL:NG

AND AUTOMATED PROCESSES AND LETS US HONE QUALITY CONTROL MEASURES,

PREVIOUSLY, AS GENERAL DYNAMICS VP OF SCIENCE AND ENGINEERING, i

SAW THE STANDARDIZATION ISSUE FROM A DIFFERENT PERSPECTIVE, iN

OUR BUSINESS, GENERAL DYNAMICS IS ALWAYS FACED WITH TECHNOLOGY

ISSUES VERSUS THE ADVANTAGES OF STAYING WITH A KNOWN AND PROVEN

APPROACH. OUR ENGINEERS MUST BALANCE THESE ISSUES TO OFFER A

PRODUCT THAT MEETS REQUIREMENTS AND IS PRODUCIBLE. I RECOGNI:ED

THEN THAT EVEN IF COMMONALITY DIDN T OCCUR, OR PERHAPS WASN T
DESIRABLE, THE STANDARDS DID FREE OUR ENGINEERS FROM REPETITI'E,

SIMILAR DESIGN TASKS AND FREED THEIR ENERGIES AND TALENTS T 2R:':"

THE NEXT LEVEL OF TECHNICAL ISSUES. WHY DO MULTIPLE DESIGN,,

DO THE SAME FUNCTION?

12
 IHAVE NOT ALWAYS VIEWED THE WORLD FROM GENERAL DYNAMICS CORPORATE
HEADQUARTERS. MY EARLIER POSITIONS WITH NASA AND THE USAF SHOWED
ME ANOTHER SIDE OF STANDARDS. IN PARTICULAR, I WAS SENSITIZED
TO THE BUDGETARY TRADE-OFFS THAT ARE MADE BETWEEN SUPPORTING AND
MAINTAINING FIELDED SYSTEMS VERSUS DEVELOPING NEW SYSTEMS.
RECOGNITION OF THE COSTS AND LOGISTICS OF OPERATING EXISTING SYSTEMS
WAS A PRIME DRIVER IN INITIATING NEW STANDARDS. AND THE RESULT OF
THESE INITIATIVES BRINGS US TO THIS CONFERENCE, TO TAKE THE PULSE
OF THE STANDARDIZATION EFFORT AND TO ASSESS AND, PERHAPS, INFLUENCE

ITS FUTURE.

BASED ON THESE EXPERIENCES AND DIVERSE PERSPECTIVIES, TWO OBSER-

VATIONS WERE CONSISTENTLY APPARENT. FIRST, A SERVICE GETS THE
DEGREE OF STANDARDIZATION THAT IT WANTS.- THAT IS, THE PRODUCT iS
A SORT OF MIRROR REFLECTING THE ATTITUDE OF THE PROCURING S;ni'E
TOWARD STANDARDIZATION, RECOGNIZE THAT THE DEFENSE INDUSTRY IS
SOPHISTICATED IN ITS ABILITY TO ASSESS THE CUSTOMERS'I REAL
INTENTIONS WITH RESPECT TO THE CRITICAL PROCUREMENT DRIVERS.

IT UNDERSTANDS THE PROGRAM REQUIREMENTS.

IT DETERMINES CUSTOMER SENSITIVITYf TO THE

VARIOUS DRIVERS AND STANDARDS.

IT KNOWS THE FUNDING CONSTRAINTS.

13

E M.ed1tiohaakI.it,~rt,.
09*~ q .N
OUR SOPHISTICATED DEFENSE INDUSTRY TAILORS THE PRODUCT TO BE

THE ONE THE CUSTOMER WILL BUY. THIS PRODUCT INCORPORATES THOSE

SOFTWARE, HARDWARE AND PROTOCOL STANDARDS THAT SELL THE PRODUCT.

SECOND, STANDARDS WILL BE APPLIED BY CONTRACTORS WHEN IT IS TO

THEIR COMPETITIVE ADVANTAGE TO DO SO. WE WILL RESPOND TO THE

REAL EVALUATION CRITERIA'IN TERMS OF INITIAL PROCUREMENT COST

VERSUS LIFE CYCLE COST.

14
 IFOUND IT INSTRUCTIVE TO VIEW HOW STANDARDIZATION HAS BEEN
. IMPLEMENTED IN GENERAL DYNAMICS PRODUCTS. As PREVIOUS SPEAKERS
HAVE MENTIONED, THE F-16 REPRESENTS A PRODUCT WHICH ALTHOUGH
A TECHNICALLY CONCEIVED IN THE EARLY SEVENTIES, IS ACHIEVING FULL

STANDARDIZATION THROUGH THE AGGRESSIVE ACTIVITIES OF BOTH GENERAL

DYNAMICS AND THE AIR FORCE.

ON THE OTHER HAND, THE TOMAHAWK CRUISE MISSILE WAS INITIATED IN

A LATER PERIOD ('76-'77) AND THESE SYSTEMS INCORPORATE VERY FEW
OF THE COMPUTING AND INTERFACE STANDARDS. THIS IS BECAUSE A
CONSCIOUS DECISION WAS MADE BY THE SERVICES AND DOD TO USE OFF-
THE-SHELF EQUIPMENT TO REDUCE THE TIME TO FIELD THE SYSTEM.
HOWEVER, LATER VERSIONS OF TOMAHAWK, FOR EXAMPLE MRASI, ARE
INCORPORATING ALL THE STANDARDS THAT ARE ALSO BEING INCORPORATED
IN OUR F-16'S AND AS WITH THE F-1.6 WE ARE-ALSO STANDARDIZING
IN OUR SUPPORT EQUIPMENT ARENA FOR OUR LATER MISSILES.

THE M-1 ABRAMS MAIN BATTLE TANK TO SOME MIGHT REPRESENT A STARK

*
CONT RAST TO FIGHTER AIRCRAFT AND CRUISE MISSILES. ALTHOUGH THE
M-1 WAS INITIATED IN THE EARLY 70'S AND WITHOUT BENEFIT OF THE
MORE MATURE STANDARDS OF TODAY, THE TANK GROWS MORE SOPHISTICATED
WITH EACH GENERATION.

IF I WAS TO PLACE YOU IN THE CREW COMPARTMENT OF THE TECHNOLOGYI

DEMONSTRATOR BEING BUILT TODAY YOU WOULD BE HARD PRESSED TO

1~5

N~
DISTINGUISH IT FROM THE COCKPIT OF A MODERN AIRCRAFT, IT IS
FORTUNATE THAT AS WE SEE THE SAME TECHNOLOGY SOPHISTICATION

EMERGING IN THIS CLASS OF SYSTEMS THAT THE STANDARDS TO SUPPORT

THEIR INCLUSION ARE COMING ON LINE. I AM SURE THAT IN ANY

MAJOR UPDATE OF THIS CLASS OF VEHICLE, STANDARDS WILL BE CLOSELY

EXAMINED BY GENERAL DYNAMICS AND THE ARMY,

RECOGNIZE THAT GENERAL DYNAMICS IS VERY ANXIOUS TO INCORPORATE

THE SAME STANDARDS IN FUTURE HEAVY FIGHTING VEHICLES AS WE ARE

APPLYING IN THE F-16 AND IN THE NEWER FAMILY OF CURISE MISSILES,

WHILE THIS HAS OBVIOUS BENEFITS TO EACH SERVICE, THE DoD AND
THE AMERICAN TAXPAYER, IT IS ALSO DIRECTLY BENEFICIAL TO THE

CORPORATION, THE SYNERGISM OF COMMON STANDARDS AMONG MULTIPLE

PRODUCTS PUTS US IN A VERY STRONG COMPETI'TIVE POSITION, IT IS
EXACTLY THE KIND OF BUSINESS INCENTIVE THE SUPPORTORS OF THIS

CONFERENCE ARE STRIVING FOR' AND I SEE MUCH GREATER POSSIBILITIES

IN THE FUTURE, VLSI AND VHSIC WITH THEIR SMALL SIZE, LOW POWER
AND COOLING REQUIREMENTS WILL ENABLE THIS SYNERGISM TO BE EXTENDED

TO OUR SMALLER SIZED TACTICAL MISSILES.

THE IMPACT OF VLSI AND VHSIC COMBINED IN THE STANDARDIZATION

INITIATIVES WILL GO BEYOND THIS SYNERGISM. As I SEE IT, VLSI AND

VHSIC WILL ALLOW STANDARDIZATION TO REACH THE HIGH PAYOFF AREA

NAMELY, COMMONALITY, SMALL SIZE, LOW POWER AND COOLING CONST!-jTE

A "LEASE COMMON DENOMINATOR" THAT WILL ALLOW THE SAME FUNCTIO.

:N DIFFERENT PRODUCTS TO BE ACCOMPLISHED BY CCOm% .,:A:,

16
 FRANKLY, BECAUSE OF THIS, I FORESEE THAT GENERAL DYNAMICS'
COMPETITIVE POSITION WILL CONTINUE TO IMPROVE AS EACH PRODUCT
SUPPORTS THE OTHER. As I MENTIONED, THE DOD AND EACH SERVICE*
WILL ALL CONTINUE TO BENEFIT.

LET ME COMMENT, HOWEVER, THAT THIS MAY NOT BE TRUE IN ALL FACETS
OF THE INDUSTRY. MAJOR SYSTEM HOUSES WILL LIKELY BE IN SIMILAR
POSITIONS AS GENERAL DYNAMICS. SUBSYSTEM HOUSES MAY VIEW THIS
AS A NEGATIVE TREND. THEY PROBABLY VIEW STANDARDS AS REDUCING
THEIR UNIQUENESS AND PROPRIETARY POSITIONS AND, OF COURSE, THE
APPLICATION OF COMMON HARDWARE COULD CERTAINLY BE VIEWED BY THEM
AS LIMITING OPPORTUNITIES. IN THIS REGARD, I WOULD COMMENT THAT
TECHNOLOGY COUPLED WITH STANDARDIZATION WILL (OR AT LEAST SHOULD)
HAVE A PROFOUND AFFECT ON THE DEFENSE INDUSTRY. COMPANIES THAT

STAY WITH CLASSICAL PACKAGING AND PRODUCT DEFINITIONS WILL LIKELY

LOSE MARKET SHARE. THERE WILL BE SOME VERY SUCCESSFUL UPSTARTSf
THAT'S THE WAY IT ALWAYS IS WHEN NEW TECHNOLOGY SUCH AS VLSI AND
VHSIC START TO BE IMPLEMENTED. COUPLED WITH STANDARDIZATION

THIS TECHNOLOGY OFFERS NEW BUSINESS APPROACHES AND OPPORTUNITIES

- FOR BOTH SUCCESS AND FAILURES.

WHEN I FIRST STARTED TO PREPARE THIS TAL PLANNED TO MAKE A

PROFOUND AND FEARLESS ASSESSMENT OF THE DOD AND TRISERVICE POSTURE

ON STANDARDIZATION. HOWEVER, IT'S NOT FEARLESS AND NOT PROFOUND, i

MERELY IT'S TO SAY THAT THEIR POSITION AND INDUSTRY'S IS THE

171
SAME - THE BEST PRODUCT AT THE LOWEST COST,
LET ME NOW TAKE JUST A MOMENT TO LOOK AHEAD AND TO MAKE SOME

RECOMMENDATIONS, As YOU WILL RECALL, I MENTIONED EARLIER THAT

STANDARDIZATION IN HIGH TECHNOLOGY AREAS GENERALLY COMES UNDER

HOT DEBATE AND CLOSE SCRUTINY. STANDARDIZATION SCARES MOST

TECHNOLOGISTS SINCE STANDARDIZATION, TO MANY PEOPLE, IMPLIES

BEING STAGNANT, WHICH LEADS TO OBSOLENCEj WHICH THE MILITARY

CANNOT STAND, AN EXAMPLE OF THIS IS DoD 5000.5X, WHETHER CORRECT

OR NOT, THE OPPONENTS OF 5000.5X USED THE POSSIBILITY OF TECHNICAL

OBSOLESCENCE AS THE BASIS FOR THEIR POSITION, THIS INEVITABLE

DEBATE LEADS TO MY FIRST RECOMMENDED TEST FOR ANY NEW STiANDARD.

WILL THE PROPOSED STANDARD INHIBIT TECHNOLOGY? To PASS THIS

TEST, STANDARDS SHOULD BE TECHNOLOGY TRANSPARENT. THIS IMPLIES

THAT WE SHOULD NOT STANDARDIZE ON PROCESSES OR HARDWARE, BUT

SHOULD STANDARDIZE ON INTERFACES AND FUNCTIONST

ANOTHER VALUE TEST FOR A STANDARD IS THAT STANDARDS SHOULD HAVE

A REASONABLY LONG LIFETIME. OTHERWISE, THE TIME INVOLVED IN

GOVERNMENT PROCUREMENT, CONTRACTOR IMPLEMENTATION AND SERVICE

APPLICATION WILL EFFECTIVELY EITHER VOID THE STANDARD OR INHIBPT

ITS EFFECTIVENESS. THE LONGER THE LIFETIME, THE GREATER THE

OPPORTUNITY THAT THE STANDARD WILL RESULT IN COMMONALITY OF

EQUIPMENT, WHICH IS THE BIG PAYOFF. THIS IS MY SECOND

RECOMMENDED TEST. WILL IT HAVE A REASONABLE LIFETIME?

2
4.

rq
MHS PAME I'r BLWN MqrITNAMIY
 N. 7- . . . . . . --

ALONG WITH THIS TEST, WE MUST ALSO RECOGNIZE THAT, WHILE

STANDARDS' LIFETIMES MAY BE REASONABLE, THEY CERTAINLY WON'T

BE FOREVER. THEREFORE, STANDARDIZATION POLICIES SHOULD INCLUDE

PROCEDURES FOR REGULAR REVIEW AND ?HASE-OUT. WHEN NEW STANDARDS

SUPERSEDE OLD STANDARDS, THE NEW STANDARDS SHOULD BE DOWNWARD

COMPATIBLE, MY THIRD RECOMMENDED TEST IS THAT NEW STANDARDS

SHOULD BE DOWNWARD COMPATIBLE WITH THE STANDARD OR PRACTICE

THAT IT IS REPLACING.

SIMILAR TO THE TIME DIMENSION ARE THE DIFFERENCES BETWEEN PROGRAMS.

PROGRAMS ARE EACH DRIVEN BY UNIQUE SCHEDULES, MISSION REQUIREMENTS,

SYSTEM CAPABILITIES, PRODUCTION COSTS AND LIFE CYCLE COSTS,

STANDARDS MUST BE TRANSPARENT TO THESE DIFFERENCES OTHERWISE THE

APPLICATION WILL BE VERY LIMITED. THIS IS MY FOURTH RECOMMENDED

TEST: DOES THE STANDARD TRANSEND PROGRAM UNIQUENESS?

I MENTIONED EARLIER THAT STANDARDS BENEFIT BOTH CONTRACTORS AN'D

DoD. LET ME KNOW REPHASE THAT INTO A FIFTH RECOMMENDED TEST: WILL

THE STANDARD BE BENEFICIAL TO BOTH GOVERNMENT AND INDUSTRY?

AND MY SIXTH, LAST, AND PERHAPS MOST IMPORTANT TEST IS A BUSINESS

ISSUE. DOES A VIABLE BUSINESS PLAN EXIST TO SUPPORT THE STAN ARD?
HAVE FUNDS BEEN AUTHORIZED TO IMPLEMENT THE STANDARD? HAS THE

MILITARY MADE IT A REQUIREMENT, AND WILL THE PROCURING ACTIVI v

MAKE IT A CRITERION IN SOURCE SELECTION? STANDARDS DE\ LOME' :

IS A TECHNICAL ISSUE, BUT IMPLEMENTATION 1S A £L T!'< -

20
Si IN CLOSING IWOULD LIKE TO OBSERVE THAT THE SIZE OF THIS
AUDIENCE TODAY' AND THE OVERALL SCOPE AND SUCCESS OF THIS
CONFERENCE IS A MEASURE OF THE INROADS THAT STANDARDIZATION
IS
MAKING IN THE DEFENSE BUSINESS. TO DATE THESE INROADS
HAVE
BEEN AT A PROGRAM AND PROJECT LEVEL. IN GENERAL DYNAMICS
WE
ARE NOW ELEVATING THIS ACTIVITY TO A CORPORATE LEVEL
TO THEREBY
ACHIEVE THE FULL SYNERGISTIC BENEFITS. IN A NUTSHELL, STANDARD-
IZATION IS JUST GOOD BUSINESS AT GENERAL DYNAMICS.

THANK YOU,

211
Thursday Luncheon
Keynote Speaker

Charles P. Lecht
Mr. Ledit is President of Ledit Sciences, Inc., a research and think-
tank recently established in New York City.

Mr. Ledht is founder and former President/Chairman of the Board of

Advanced Computer Techniques Corporation (ACr), a computer softwaree
consulting firm.
He holds a B.S. Degree in Mathematics from Seattle University and
a M.S. Degree, also in Mathematics, from Purdue. His involvement in the
compzte field stretches back to 1951, making him an "old-timer" in a
very young industry.

Among his earliest professional activities were programming for TBM's

Service Bureau and for the MIT amnity's Lincoln Laboratory/MPTRE
organizations on a variety of scientific and military simulation projects.

Fran 1960 to 1962, Mr. Lecht served in the U.S. Anrmy Ordnance Corps,
first as Chief of its Programming Division and subsequently of its
Mobilization Application Division; Ordnance Industrial Data Agency.

Mr. Lecht came to New York City in 1962, where he founded ACT. In
the 17 intervening years, the Ccmpany has grown fra a one-man show to
an international complex employing over 450 persons and deriving more
than 50% of its revenues fran operations in Europe, Canada and the .Middle
East as well as the U.S.

In addition to building and presiding over iCT, Mr. Lecht has found
time to hold a number of technical posts, author five books and innumerable
articles and maintain a heavy schedule of speaking engagements in the
U.S. and abroad. In addition to THE WAVES OF CHANGE, his books include
three on camputer languages and one on project management.

He is a member of the Young Presidents Organization, The Hudson

Institute, the Data Processing Management Association, the Association
for Computing Machinery and the New York Academy of Sciences.

In 1976, Mr. Lecht was designated by "The Gallagher Presidents' Report"

as one of the "10 Best Businessmen in the USA" representin acmpanies wit-h
income below $1 billion. Profiles of Mr. Lecht have apooeared in '-Be N
Yorker and Dataation, among other publications.

22

~p
P - . + +
 If you thought change in compLter systems techni IcjLy was

acceleratir q in 1982, you haven't seen anything yet. By this

t ime next. year- January 1984, 1982 will be remembered as a period

of relative calm in comparison to what we are to witness in 1983.

So :intense will such change be that we will be compelled to

al ter our most fundamental views of the nature of computer-

svstems and their roles in our lives. New and improved methods

of acquiring the powers engendered by computer technology are

emerging swiftly and these powers, reapplied to this same

technology, are fueling its capacity for change in ever more

efficient ways. However unsettling this may be to computer

systems users, the net effect of 1983's change should be

dramatically positive.

For all the ferocity of its drama, we still have the

delicious luxury of exploring this phenomenon and speculating on

its meaning in a relatively tranquil state of mind.

While it has been true all along, we've only recently

accepted the fact that computer systems impart to their users

extraordinary powers in memory, logic and computation

unavailable in our natural world. And sewn together like beads

into strands and strands into lattices, computer systems have

envolved to become at once their own repository of such powers, a

part of yet another's, and a portal to still others of lesser or

greater consequence. This came about as a result of the

synthesis of computer and communications systems technologies in

the 1970's. It is as though the once clear ideas that made a

computer system so readily distinguishable from a communication

system have been swept away in a tidal wave of change. All the

23
substantial attributes of either are found i n the other: .s

ci. rcui try, swi tches, terminals., si gnal processor s, bu fer,

mI-emor i es., c onver s i on devices, sof tware, even wave

t ransini t ters/recei vers. This has caused us to redef ine OL-

concept of a Computer system to mean a network of device!.- Who(se

ommunii cations veins and arteries may vanish into the m cr. Co 1K

world ard e-.:tend into the macroscopic world. Since all moder,

sstems are col ecti ons of proc::essors, some of which may po

loc at ed r-emotel y, ad-hoc, run-time system conf i gur-at ions are

possible. We send data between devices to be proc essed and

rec-ei ve the results through massive lattices of wire whose

organizational complex-ities are mind- boggling and whose cross-

sectional dimensions vary from micron to meter. This has led.

not unreasonably, to a blurring of our perceptions of a spec.i1

computer system and its limits, especially with regar d to

conventional concepts of temporal and spatia. dependencieci.

As if this were not enough to handle, c.ontemporary s .te-.

linking wi.del y dispersed locations are involving an incrf Asr ,r

b r-oad(-: ast (omponent. Thus our very c.unrept of syst er* r

enough to "domesticate" on terra firma, now externds i nto

heretofore alien, dimension, complete with it. own net of -

c(oipassabl e peculiarities. With .ts use no longer r-?etri

mere -hi pment of data, broadcast is becominq practical

storage medium for massive files humming soundlessly som .. h-

between the moon and New York City.

Under development in the past few years have been , s.

24
 c-ornputer systems referred to in Bell Labs literature as

Integrated Services Digital Networks. The appearance of these

Titans urnderscores our commitment to create ever larger

repositories of computer systems power, and to distribute this

power in ever more effective ways. I visualize such systems in

the form of massive ships suspended in artificial intelligence

space. Possessed of their own intelligence and augmented by

exogeneous intelligences docked at their ports, they, and the
promise of that ISDN technology from which they spring, present a

sipectacle (and capability) of breathtaking beauty and scale.

As such systems are created in the macroscopic world, so

identical systems are aborning in the microscopic world of chips,

* wherein magnetic field fluctuations invoke device operations and

carry niessages. In this world, too, are satellities, transmitters,

and receivers. The satellite is suspended in a space whose

"ether" is silicone, sapphire, metal oxide and exotic, other-world

compositions. However flat the world of the silicon chip may

seem to the naked eye, some of its elements are separated by

distances proportional, within their physical frame of

reference, to those separating us from our own space satellites.

Peering through a microscope, we are astounded to see a network

of cables and devices more complex than their nearest

C:ounterparts in, say, some vast, sprawling, tentacular chemical

plant. Not only are we surprised that a third dimension appears

hitt that the distances traversed laterally on some chips, however

confining their edge sizes may seem to us to be, rival those in

whcs? terms we conduct our lives in the macroscopic world.

The ratu of announcement of technological breahthrouqhs by

25
 t hE wor Ld !stientific community and the ne~quos ~~
s4u c h c::
k )fi C)Lt I C C f') t h as been not hi nq sh or-t- Off--RSt0tndci n q in t.'

pt -f eLwv I'.rS. It h as been responsi biI F fo:r- thePcurr ent

Lii d e spr-E-a d p ro.if+e r-at io n of peF-r so naI comnp u t e rs. Lut n: Cr-
imnpc)r t an t stil 1 1 COinmunicati ons improvements have vi r- tu-alI I

el ufniated the practioner' s need to visit a computer, person Al or-

*.) other wi se, to share in its powers; access to them is obtau niibl ii

v ir t u: 11 eve-.rywhere. The once discrete concepts of perconna!

computer -And terminal are in the process of synthesiz ing. Th i

phenomenon, along with communications improvements, provide usIr-

wi th fantastic processing potential requiring very little ro t -er 1d

investment. As every Such device fulfills the role of being Ja

functional locus in a strand of companion devices, unified b~y LAN

technology, its usage provides us with the capacity to ignite: the

strand, energize the lattice of which it is a part, and, i+ only-

fo(:r- an- : nst ant, i n vo)k e the power of A co n qrer.s s nof

(7RgIY s, CYEIER' s, -11084' s and others. The Output of this

eve&n t c:o3ulI d va~ry from the mani pul ati on of a1 qi q aby.

datbaeto: forecasting weather, to a few mi cr0-coded

r ealI --t i me c-omputer instructions fed I epablIurn tri r

batby mnicro: gti dance processor embedded i n the bell ] c*+ a

bomb. Electrnnic mail dispa-.tched by Jupiter And carried h,-

Mefr cu-r hi ms el r:ould do no more.

So what does this all have to do with standardsl A

lot. Choosing standards which serve the intentions of

governmental directives in today's swiftly chanigino

technological climate is a more demandinq tas : tlian

eve- been. For these directives were cast at a time w'iFr

our technology was very different than I've 2ust Joscrrihd.

26

. ... .....
 J ; I - .. £ ° - . -. - ' ' ' SL .- ' '.' . .

There are so many hardware and software standards with

which our government must be concerned. And the concern is

one of legitimacy, nay, duty. One cannot help but empathize

with those who must ultimately make the choice; the

probability of error is increasing.

While contemplated product life cycle durations of

computer systems haven't changed too much, the rates at

which compelling alternatives arrive have. This causes

perfect reasonable life cycle plans to suffer premature

obsolescence with ever-shortening regularity. These

alternatives are new systems with such price performance

improvements that conversion brcomes worthwhile; if

conversion is required at all. Today's systems managers

trained, say, in the 1960's and 1970's and shell shocked

from the trauma of having lived through but a few

conversions, are appalled at the thought of doing so every

few years. Yet, with burgeoning requirements and limited

budgets, those in position to take advantage of the new

alternatives are compelled to do so. Thus, for example,

those users who acquired Honeywell DPS/5 systems only a few

*yrars ago may find it cost effectve to enter the conversion

process needed to upgrade to a DPS-8/70 even though the

DPS/5 was forcast to last, say, 5 to 10 years. This may

even be the case despite the fact that the users work load

is not burgeoning, so improved in price performance is the

new system. The phenomenom of upgrading while down-costing

is not new in our industry, but its increasing appearance

27
signals radical change. It further reveals that we are

inex:orably drifting toward an ever faster stream of product

announcements. Remaining operational at the terminus of

this stream will involve hooking into a massive ISDN and

hanging on for life.

No one has achieved the capability to upgrade and

down-cost better than IBM without much conversion at all.

Especially if the user is willing to buy more. The stream

of this kind of IBM hardware flows ever more swiftly to the

marketplace as IBM wisely readies its own massive ISDN.

Fancy lease to purchase plans; purchase, rental, even

trade-in and other financial plans abound. Thus, if not

propelled by technological change, economic incentives alone

may trigger a systems change.

"When the stream is flowing swiftly, tubing becomes

proportionately hazardous. The wise tuber avoids white

water and sticks to the center. Not that thrills aren't to

be had in the diversionary whirlpools of peripheral

tributaries. It's just safer." This advice was given me by

a wizened old tuber on Arizona's Salt River. "It's hardly

worth it to express your opinion," he said. "The river

expresses it for you."

Back to choosing standards in today's technological

climate. As the tuber must learn to respect the river"'

28
flow, our standards choices are being affected by equally

powerful overriding forces.

So very serious persons like those attending the USAF

standardization conference in Dayton this week meet to

discuss their plans to cope with these forces. The Dayton

meeting addresses DOD's needs.

I assume Dayton was chosen to underscore the somber

nature of DOD's problems; Miami or New Orleans appearing to

jovial. Bent upon reviewing, amending, proposing and

adopting standards which meet the various intentions of DOD

directives; this group faces an awesome task.

INTERLUDE

In my mind's eye I conjur the mischievious image of a

secret cult meeting in the most laid back place possible;

the Grey Temple of Dayton. The high priests of JOVIAL

(Jule's Own Version of the International Algorithmic

Language) venerate ALGOL while linguists, metaphysicians,

and MENSA members sing cantos to complexity. And ALGOL

begat JOVIAL which begat JOVIAL II which begat JOVIAL 3

which begat JOVIAL 3B and JOVIAL 73. JOVIAL 3B begat JOVIAL

3B2 which with JOVIAL 73's decendent, Jovial 73/I, begat

JOVIAL 73(not to be confused with JOVIAL 73/I's progenator

JOVIAL 73.) ADA novitiates swarm about. Before ordintion

29

~ -'. % ~ ~ % , V J% %'.
 they must convert at least one COBOL-caholic to SHORTHAND,

and obscure dialect known only to K. Gibbsian scribblers.

The holy ark is opened and when ALGOL speaks, everyone

listens. He makes his ten statements and declarations as

the cult mumbles I/O protocols and code for STRECH and LARK.

The ceremony ends as an ADA novitiate is confirmed.

END OF INTERLUDE

Back to standards. Reviewing yesterday's choices made

at a time when things were moving far more slowly, we can

conclude that todays usefullness of these is questionable.

The FIP I/O standard is a case in point. Discarded by most

manufacturers in planning new technology, its utility seems

limited to gaining approval to bid on government contracts

and sustaining the PC industry. And what about JOVIAL?

When DOD Directive 5000.31 specified JOVIAL as the

cross-compiler for USAF embedded weapons applications, who

could have faulted it's intentions; to minimize assembly

*. language programming, minimize maintenance, and discourage

proliferation of new higher order languages.

Did JOVIAL do this? It doesn't seem so to me. And if

my perception is correct, what should we learn from 0-?

No one could argue with the underlying reasons for

30
wanting standards like JOVIAL, or what JOVIAL was supposed

to be. And not all JOVIAL events missed the mark; J3B's

role in the F-16 and B-1 programs has been significant.

When JOVIAL was chosen, no one, in or out of the

government seemed to have a clue that swift and enduring

change in computer technology was to take place. Crippled

at the onset as a language wanting of definiton, its

subsequent history tells a tale of heroic struggle, by

implementers and users alike, to conform to the USAF

decision. Evolving to be an encyclopedic language, intended

to be all things to all people, its complexity masks its

usefulness. So does its size. Except in erudite examples

in some scientific journals, its usage is a dead giveaway to

the Russians that an embedded weapons system is involved;

nobody else uses it.

And now ADA! I predict it will suffer the same fate.

Overly complex, over sized, it's another software

development dream that will course the river of accelerated

innovation out of its mainstream.

Prudence would have sugested FORTRAN's immediate

descendants, or PASCAL-like dialects like MODULA II.

Everyone with an Apple, IBM, etc. personal computer, who

zt.n't snlely playing games with it, knows something like

it. S;cientists programming the big stuff were brought up on

it. And while usage of a dialect like MODUL4 II might

31

Y ~ tq"
 require a bit more assembly language programming than we'd

like, savings in other aspects of the intention of DOD

Directive 5000.31 would more than compensate for this

extravagance. With versions already available on just about

every micro-to-macro processor, the well of available talent

would be virtually unending. Chips running MODULA II could

be manufactured and supplied to virtually every computer

systems company for inclusion in their offerings, all using

the same language repertoire and syntax. Easy to implement,

this standard could be promulgated with euphoric ease. The

net effect on productivity in the short term would be

stupendous; no new higher order languages would be

promulgated, maintenance would be a breeze.

It's quite daring to question the utility of JOVIAL,

not to speak of ADA, these days. So much money and time has

gone into their creation and usuage that in doing so, I fear

retaliation from America's DOD; planes, bombs and all. And

I don't pretend to know all that went into JOVIAL's and

ADA's selection decisions. Nor the politics of these

decisions.

What I do know is that our technology has undergone

dramatic change since AF Directive 5000.31 and our standards

selection methodology hasn't. Nor does it appear that

5000.31 intentions have been reviewed in light of this

change.

32

LM
M M ~ .... . C ~ ~ -,
 With fifth generation processor capability providing

scientists with picosecond (range) computational speeds and

* gigabyte memories we've entered a new dimension where the

languages we use are less important than we think. Truly

mobile software becomes possible when differences in

operating speeds occur in the picosecond world. When

redundant multiprocessors are commonplace, maintenance is

conducted remotely, replacement is cheaper than repair, and

back-up is always available through network communications,

a score of earlier premises for standardization dissappoar.

We need the most modern technology possible in a world

where its manufacture is widespread. In order to get it,

we'll have to abandon preconceived notions of computer

systems software and hardware and get on with it.

33I
EXEICUTIVE SS

SESSION CHAIRWM Jffery L Peshr

ASDASNAS

MODERATOR : Col. R. P. Lavoie

ASD/ENA
OPENI 1C REMRI
TO THE
2NDAFSC STNI4ARIATIO14 COWFEREc
DAYOitL OHIO

LMW . RERONA SYSTEMS DIVISION

373Z
ON BEHALF OF THIS CONFERENCE SPONSOR, THE AIR FORCE SYSTEMS
COMMAND, AND ALL OF US IN THE AERONAUTICAL SYSTEMS DIVISION WHO
ARE YOUR HOSTSi IT GIVES ME GREAT PLEASURE TO WELCOME YOU TO THE
2ND AFSC STANDARDIZATION CONFERENCE.

FOR SEVERAL YEARS NOW, WE'VE BEEN WORKING WITH OUR SISTER SERVICES,
OUR NATO ALLIES, AND INDUSTRY TO REALIZE THE BENEFITS OF
STANDARDIZATION. I'M HAPPY TO SEE THAT KEY PEOPLE FROM EACH
OF THESE PARTNERS IN STANDARDIZATION ARE HERE WITH US TODAY.

WE'VE TRIED VERY HARD TO TARGET THIS CONFERENCE TO YOQU, THE

EXECUTIVES, THE MANAGERS, THE SYSTEMS INTEGRATORS AND THE ENGINEERS,
BOTH IN GOVERNMENT AND INDUSTRY. WE WILL PRESENT A LITTLE BIT OF
EVERYTHING: FROM EXECUTIVE OVERVIEWS TO DETAILED VISIBILITY INTO
OUR NEW STANDARDIZATION INITIATIVES.

THIS MORNING WE WILL PROVIDE SOME INSIGHT INTO THE CURRENT DOD
VIEWS ON STANDARDIZATION; AND WE WILL ADDRESS STANDARDIZATION FROM
THE PERSPECTIVES OF ALL THREE SERVICES' AS WELL AS A NEW PERSPECTIVE
FROM NATO. FOR THE NEXT TWO DAYS, THE CONFERENCE WILL CONCENTRATE
ON THE HARDWARE AND SOFTWARE AVAILABLE TO SUPPORT STANDARDIZATION
INITIATIVES WE HAVE ALREADY IMPLEMENTED. THIS GIVES US THE
OPPORTUNITY TO TELL YOU ABOUT THE BENEFITS WE EXPECT FROM THESE
INITIATIVES, THE KEY EFFORTS SUPPORTING THEM AND THE LESSONS LEARNED
FROM ACTUAL PROGRAM APPLICATIONS.

38
 v".i .

THIS SYMPOSIUM AFFORDS YOU THE OPPORTUNITY TO LEARN ABOUT OUR

CURRENT STANDARDS, TO SEE WHAT IS BEING DONE TO SUPPORT THEM,

AND TO VISIT THE EXHIBITS TO SEE SOME ACTUAL HARDWARE RESULTING
FROM THESE STANDARDS. IN JUST THREE DAYS, YOU CAN GATHER A
LOT OF INFORMATION HERE WHICH MIGHT OTHERWISE TAKE A LOT OF TIME
AND EFFORT TO COLLECT. I HOPE YOU'LL TAKE ADVANTAGE OF IT--
ESPECIALLY THOSE OF YOU FROM WRIGHT-PATTERSON. ENCOURAGE YOUR
BOSSES TO COME TO THE EXHIBITS ON WEDNESDAY NIGHT. I'M SURE
THAT EACH ONE OF THE EXHIBITORS WOULD WELCOME YOUR INTEREST
AND YOUR QUESTIONS.

39
Now, TO THE THEME OF THIS YEAR'S CONFERENCE -- "RATIONAL

STANDARDIZATION." WE ALL KNOW THAT EVERY STANDARDIZATION

ACTIVITY IS AN EXERCISE IN COMPROMISE: TO GAIN SOME BENEFITS

WE ARE WILLING TO SACRIFICE OTHERS. THE TRADE--OFFS WE HAVE

TO MAKE ARE NOT ALWAYS INTUITIVELY OBVIOUS--NOR ARE THEY ALWAYS

CREDIBLY QUANTIFIABLE. OUR ULTIMATE OBJECTIVE IS INCREASED

EFFECTIVENESS IN BOTH COMBAT AND PEACETIME TRAINING--AND GREATER

AVAILABILITY TO EACH WEAPON SYSTEM IN OUR FORCE STRUCTURE. WE

INTEND THE TERM "RATIONAL" TO BE USED SYNONYMOUSLY WITH THE
PHRASE "COMMON SENSE." WE RECOGNIZE THAT OUR RECOMMENDATIONS OR

DECISIONS IN THIS AREA HAVE TO BE BASED ON ANALYSIS--SO THAT IS

WHAT I'D LIKE TO DISCUSS WITH YOU TODAY-- "THE ELEMENTS OF THE

THOUGHT PROCESS THAT SHOULD GUIDE OUR STANDARDIZATION DECISIONS."

OUR FIRST ELEMENT IS "RETURN ON INVESTMENT." WE MUST BE ABLE TO

IDENTIFY WHAT THE REAL BENEFITS ARE. WE LOOK FOR FINANCIAL,

TECHNICAL AND OPERATIONAL PAY-OFFS--AND; IF WE DO IT RIGHT, WE CAN

GET A COMBINATION OF ALL THREE. BUT THE "PAY-OFF" EQUATION HAS

TWO SIDES TO IT--BENEFIT AND COST , IT IS SOMETIMES EASY TO

CONFUSE THE TWO--AND ONE MAN'S BENEFIT CAN EVEN BE ANOTHER'S COST.

WE ARGUE THESE ISSUES OUT AND TRY OUR BEST TO QUANTIFY ALL ASPECTS.

THAT ISN'T AS EASY AS IT SEEMS WHEN YOU MUST "ASSUME" WHAT THE

MARKET FOR THE STANDARD IS, AND "PROJECT" WHAT THE LONGER TERM

BENEFITS MIGHT BE. THE JOB IS A LOT EASIER WHEN YOU KNOW WITH

SOME DEGREE OF CERTAINTY HOW MANY SYSTEMS WILL BE INVOLVED.

40
Sir,1
 THE SECOND ELEMENT IS VERY CLOSELY RELATED TO PAY-OFF--IN FACT.-
WE REALLY DON'T KNOW HOW TO SEPARATE THEM. THE SECOND ELEMENT IS,
"THE APPROPRIATE LEVEL OF STANDARDIZATION." OUR CHOICES USUALLY
RANGE FROM STANDARDIZATION OF PIECE PARTS, OR EQUIPMENTj TO

STANDARDIZATION OF EQUIPMENT INTERFACES. THE KEY ISSUES HERE

INVOLVE LOGISTICS COSTS, REALIZABLE TECHNICAL PERFORMANCE ANDi

OF COURSE, THE VERY REAL THREAT TO PROGRESS ACCOMPANYING A FREEZE

OF TECHNOLOGY INFUSION. IN THE RECENT PAST, WE BELIEVED THAT

USING STANDARD PIECE PARTS WOULD BENEFIT US A LOT, BUT THE

ECONOMIC HALF LIFE OF DIGITAL MICROELECTRONIC COMPONENTS IS SO

SHORT THAT WE'VE HAD TO RESTRUCTURE OUR THINKING IN THIS AREA.

WE ALSO HAVE TO BE VERY CAREFUL WHEN WE PICK AN EQUIPMENT OR

"BLACK Box" STANDARD WHERE THE TECHNOLOGY IS MOVING VERY RAPIDLY.

OUR BEST BETS FOR HARDWARE LEVEL STANDARDS SEEM TO BE WHERE

NEITHER OUR REQUIREMENTS NOR THE TECHNOLOGY ARE CHANGING TOO RAPIDL

ONCE WE HAVE SOME AGREEMENT ON THE FIRST TWO ELEMENTS OF

STANDARDIZATION, WE FACE A DECISION ON THE THIRD--THAT IS--

THE "FORUM WE USE TO DEVELOP AND MATURE THE STANDARD." WE KNOW
THAT BROAD ACCEPTANCE OF A STANDARD REQUIRES MAXIMUM PARTICIPATION

OF ALL THOSE AGENCIES THAT WILL BE AFFECTED BY IT. WE TRY VERY

HARD TO ESTABLISH BOTH THE ENVIRONMENT AND THE OPPORTUNITY FOR ALL

INTERESTED PARTIES TO PARTICIPATE IN THE TECHNICAL DEVELOPMENT

PROCESS. HERE TOO, WE ARE FACED WITH COMPROMISE AND MUST CONSIDER

SACRIFICING TECHNICAL PERFORMANCE OR PERFECTION FOR ENGINEERING

PRACTICALITY. WE TRY TO USE OPEN FORUMS AND ENCOURAGE INDUSTRY

44
 *~~1 - -t1- - V.-. -

TO JOIN "USER GROUPS" FOR EVERY MAJOR STANDARD WE CONSIDER.

SO FAR, IT SEEMS TO BE WORKING AND IT'S THE BEST APPROACH WE'VE

BEEN ABLE TO COME UP WITH.

AFTER WE'VE IDENTIFIED THE PAY-OFFS, SETTLED ON THE APPROPRIATE

LEVEL OF STANDARDIZATION, AND OBTAINED AS BROAD A CONSENSUS AS

POSSIBLE ON THE TECHNICAL CONTENT OF THE STANDARD -- WHAT'S

LEFT? WELL, A NUMBER OF KEY QUESTIONS ASSOCIATED WITH

"RATIONAL STANDARDIZATION" STILL HAVE TO BE ADDRESSED, LIKE:

--HOW ARE WE GOING TO IDENTIFY WHAT WE MUST DO TO MAKE IT

A MATURE STANDARD? OR,

--How ARE WE GOING TO BUY IT SUCH THAT IT WILL ACHIEVE ALL OF OUR

FORECASTED BENEFITS?

THIRD - HOW ARE WE GOING TO SUPPORT IT, ONCE WE'VE BOUGHT IT?

ANDFT3NALLY -- HOW ARE WE GOING TO INSURE.THAT THE ."STANDARD" STAYS

VIABLE OVER TIME?

THE FIRST QUESTION - HOW TO TAKE A STANDARD FROM A PAPER CONCEPT

TO A STANDARD THAT IS VIABLE, WELL-UNDERSTOOD, AND EASILY IMPLEMENTED

IS NOT ONE WE CAN ANSWER OFF THE TOP OF THE HEAD. WE HAVE TO

ANALYZE IT, TRY IT, FIX IT, DEVELOP SOME APPLICATION GUIDES BASED
ON THIS EXPERIENCE, AS WELL AS SOME FORM OF COMPLIANCE OR

VERTIFICATION TESTING -- ALL OF THIS IN TIME TO MEET THE FIRST

APPLICATIONS FORECAST FOR THE STANDARD. UNFORTUNATELY, FUNDING

TO DEVELOP A STANDARD IS DIFFICULT TO GET; BUT THE MONEY TO DEVELOP
S.
THE "THINGS NEEDED TO INSURE ITS MATURATION AND EVENTUAL SUCCESS"

42
IS ALMOST IMPOSSIBLE TO GET. NOT EVERYONE IN THE BUDGET PROCESS

UNDERSTANDS WHAT IT TAKES TO PRODUCE A wMATURE STANDARD."

QUESTIONS TWO AND THREE ARE SO CLOSELY RELATED THAT I HESITATE

TO SEPARATE THEM LET ME TRY. WE MUST SETTLE THE QUESTION OF HOW

WE INTENDED TO SUPPORT THE STANDARD VERY EARLY IN ITS CONCEPTUAL

PHASE AND TWEAK THAT DECISION AS WE GO ALONG. THE SUPPORT

REQUIRED WILL SURELY CONSTRAIN SOME OF THE TECHNICAL PERFORMANCE

EXPECTED OF THE STANDARD--AND SHOULD BE A FACTOR IN THE BUSINESS

STRATEGY DECISION OF "HOW WE BUY IT." FOR EXAMPLE, WE HAVEN'T

ALWAYS RECOGNIZED HOW SENSITIVE AND CLOSELY RELATED THE SPECIFICS

OF THE HOW-TO-BUY FORM, FIT, FUNCTION (OR F3 ) .

ARE TO THE LOGISTICS SUPPORT CONCEPT WHICH ENSUES. SO THAT IS

THE ESSENCE OF QUESTION TWOS NAMELY, "HOW DO WE BUY THE STANDARD

IN A MANNER THAT PRESERVES THE FORECASTED BENEFITS?" MANY OF

THE COST BENEFITS WE FORECAST FROM A DECISION TO BUY A STANDARD

CAN BE COMPLETELY WIPED OUT BY A DUMB PROCUREMENT STRATEGY.

WE HAVE TO BALANCE COMPETITION, ECONOMIC ORDER QUANTITIES, AND

AN OFTEN UNCERTAIN TOTAL MARKET. WE MUST COME UP WITH A CONTRACTING

APPROACH THAT YIELDS COST BENEFITS TO US AND REASONABLE PROFITS

TO INDUSTRY. A POOR DECISION HERE CAN HAVE A LONG TERM IMPACT

ON ELEMENTS OF OUR FORCE EFFECTIVENESS AS WELL AS OUR INDUSTRIAL

BASE.

GIVEN THAT WE MANAGE TO PROPERLY ANSWER THE FIRST THREE QUESTIONS

AND THEREBY ACHIEVE AN EFFECTIVE, VIABLE STANDARD, WE STILL HAVE TO

43

mI
I 4ADDRESS THE FOURTH QUESTION: HOW WE KEEP A STANDARD VIABLE
OVER TIME. A NUMBER OF THINGS ARE FIXED AT A POINT IN TIME

WHEN A STANDARD IS ADOPTED BUT PASSAGE OF TIME BRINGS CONTINUING

CHANGES. THE THREAT GROWS, OUR REQUIREMENTS CHANGE, THE
TECHNOLOGY EVOLVES -- HOW DO WE DEAL WITH THIS IN THE "FIXED
STANDARDS" ARENA? WELL--HERE AGAIN, WE MUST COMPROMISE. WE NEED

TO BALANCE THE FIXED SOLUTION A STANDARD REPRESENTS WITH THE CHANGES

OCCURRING IN THE WORLD AROUND IT, WE NEED TO "UPDATE" WHEN IT'S
SMART AND CHANGE TO ANOTHER STANDARD WHEN THAT MAKES SENSE.

THIS - IN TURN - MEANS THAT BOTH SYSTEMS COMMAND AND LOGISTICS'

COMMAND MUST SHARE A LONG TERM INVOLVEMENT IN BOTH PRESERVING

AND ADAPTING THESE STANDARDS TO CHANGE. THE POTENTIAL IMPACTS OF

UNADAPTABLE, INFLEXIBLE STANDARDS ON THE SERVICES AND INDUSTRY

ARE TOO GREAT TO DO ANYTHING LESS.

WELL--RATIONAL STANDARDIZATION IS A LOT EASIER TO SAY THAN TO

ACHIEVE. YET I AM GRATIFIED AT THE PROGRESS WE HAVE MADE. LET ME

ILLUMINATE WITH SOME RATIONAL STANDARDIZATION EFFORTS NOW UNDERWAY.

OUR CURRENT TRIAD OF DIGITAL AVIONICS STANDARDS ARE EXAMPLES OF

RATIONAL INTERFACE STANDARDIZATION. THEY HAVE NOT, TO DATE.,

INHIBITED THE TRANSITION OF TECHNOLOGY INTO WEAPON SYSTEMS.

IN FACT, WE THINK THE PRESENCE OF STANDARDS HAS ACTED AS A CATALYST

TO ACCELERATE TECHNOLOGY TRANSITION AND INSURE COST-EFFECTIVE AVIONIC

SYSTEMS.

44
J "'.,a, ,. l *a % V .V:". ~ %
MIL-STD-1553, THE MULTIPLEX DATA BUS STANDARD, IS THE MOST

MATURE OF THE GROUP AND PROVIDES THE BEST INSIGHT INTO THE
EFFECTIVE USE OF STANDARDIZATION. BECAUSE "1553" IS AN INTERFACE
STANDARD, IT IS INHERENTLY TECHNOLOGY INDEPENDENT. DATA BUS
INTERFACES MAY BE DESIGNED USING DISCRETE-SEMICONDUCTOR,
INTEGRATED CIRCUIT, MICROPROCESSOR, OR EVEN VHSIC TECHNOLOGY,
IF DESIGNED TO THE STANDARD, THEY ALL WORK TOGETHER. THE FIRST
"1553" BUS INTERFACE DESIGNS EMPLOYED A MIX OF DISCRETE COMPONENTS
AND MEDIUM SCALE INTEGRATED CIRCUITS. BUT AS THE STANDARD MATURED
AND USAGE INCREASED, INTERFACE CIRCUIT VENDORS RESPONDED TO THE
MARKET WITH THICK FILM HYBRIDS AND LSI CIRCUITS--AND V-LSI CIRCUITS
WILL SOON BE INTRODUCED. A CONTINUOUS STREAM OF NEW TECHNOLOGY
DESIGNS HAS BEEN MADE POSSIBLE BY THE PRESENCE OF THIS FIRM
INTERFACE STANDARD. WITHOUT IT, MANY VENDORS WOULD NOT HAVE
MADE THE FINANCIAL INVESTMENT NECESSARY TO IMPROVE THE TECHNOLOGY.

MIL-STD-1750, THE COMPUTER-ARCHITECTURE-INSTRUCTION-SET STANDARD,

IS A RELATIVE NEWCOMER TO THE STANDARDS SCENE. IT TOO REPRESENTS

AN INTERFACE, BUT IN THIS CASE IT IS THE INTERFACE BETWEEN THE
AVIONICS COMPUTER HARDWARE AND THE SUPPORT SOFTWARE (THE COMPILER,
ASSEMBLER, LINKER, LOADER, ETC.). EARLY ON IN THE DEVELOPMENT
OF "1750," WE GOT LOTS OF PRESSURE FROM SOME SOURCES TO DEFINE
A STANDARD PIECE OF AVIONICS COMPUTER HARDWARE, AND THUS HELP
ATTACK THE SPARES ELEMENT OF THE SUPPORTABILITY PROBLEM.

45
WE CAREFULLY THOUGHT ABOUT IT, BUT ULTIMATELY REJECTED IT

BECAUSE IT WOULD INHIBIT TECHNOLOGY TRANSITION IN AVIONICS

COMPUTERS--INHIBIT IT BEYOND THE PAY-OFF WE COULD SEE.

INTERESTINGLY ENOUGH, THE U.K. IS ADOPTING "1750" AS A DEFENSE

STANDARD JUST AS THEY DID "1553." WHILE "1750" DOES NOT ADDRESS
THE HARDWARE ASPECT OF SUPPORTABILITY, IT DOES DEAL WITH THE

SOFTWARE ASPECT. USE OF "1750" PERMITS STANDARD SUPPORT

SOFTWARE TOOLS TO BE EMPLOYED IN THE DEVELOPMENT AND MAINTENANCE

OF AVIONICS SOFTWARE. AN AIRCRAFT USING "1750" BASED PROCESSORS

IN ITS HUD, INERTIAL SYSTEM, STORES MANAGEMENT SET, RADAR, AND

SO FORTH, AND AS THE MAIN INTEGRATING COMPUTER, NEEDS BASICALLY

ONE SET OF SUPPORT SOFTWARE TOOLS, AND ONE TEAM OF SOFTWARE

ENGINEERS TO DEVELOP AND MAINTAIN THE AVIONICS SOFTWARE. THIS

SUPPORTABILITY SIMPLICATION IS ACCOMPLISHED WITHOUT INHIBITING

TECHNOLOGY SINCE IT MAKES NO DiFFERENCE WHAT TYPE TECHNOLOGY IS

USED IN A "1750" COMPUTER--ONLY THE "SOFTWARE INTERFACE" MUST

BE OBSERVED. FURTHER, RECENT ACQUISITION PROGRAMS, SUCH AS THE F-111

UPDATE, HAVE SHOWN THAT THE STANDARD HAS FOSTERED INCREASED

COMPETITION WITH A CONSEQUENT REDUCTION IN ACQUISITION COSTS.

MIL-STD-1589, THE JOVIAL HIGH ORDER LANGUAGE IS THE THIRD MEMBER

IN THE TRIAD OF AVIONICS STANDARDS, IT DEFINES A STATE-OF-THE-ART
LANGUAGE WHICH ENCOURAGES USE OF "MODERN" PROGRAMMING TECHNOLOGY--

SUCH AS STRUCTURED PROGRAMMING--AND MODULARi TOP-DOWN DEVELOPMENT

IN AVIONICS. MIL-STD-1589 COMPLETESTHE INTERFACE BETWEEN THE

AVIONICS COMPUTER PROGRAMMERS, THE SUPPORT SOFTWARE AND THE

MIL-STD-1750 COMPUTER. SOFTWARE DEVELOPMENT IS OFTEN ON THE

46
 4-~~~~~ -- - -. 7--

CRITICAL PATH FOR NEW WEAPON SYSTEMS, AND THESE TWO STANDARDS

TOGETHER WILL PROVIDE THE ABILITY TO BEGIN DETAILED SOFTWARE

DESIGN AND DEVELOPMENT INDEPENDENT OF HARDWARE AVAILABILITY.

IN CONJUNCTION WITH MIL-STD-1750, 1589 PROVIDES THE STABILITY

IN COMPUTER LANGUAGE AND HARDWARE INTERFACE NEEDED TO

STIMULATE INVESTMENT IN COMPLEX SUPPORT SOFTWARE SYSTEMS.

THESE SYSTEMS, SUCH AS OPTIMIZED COMPILERS AND "INTEGRATED

SOFTWARE DEVELOPMENT ENVIRONMENTS," WILL PROVIDE DESIGNERS

WITH EASY TO USE, PROVEN-"TOOLS," AND MANAGERS WITH INCREASED

VISIBILITY AND CONTROL, THIS EXAMPLE OF "TECHNOLOGY INFUSION,"

RESULTING FROM USE OF THE STANDARDS-CAN ULTIMATELY CONTRIBUTE

TO THE SOLUTION OF PROBLEMS SUCH AS SOFTWARE RELIABILITY. CODE

PRODUCTIVITY AND OTHER DIFFICULT SOFTWARE PROBLEMS WE ALL FIND

ON OUR PLATES,

I THINK THE F-16 MULTI-NATIONAL STAGED IMPROVEMENT PROGRAM (MSIP)

IS A GOOD ILLUSTRATION OF DIGITAL AVIONICS STANDARDS BEING

IMPLEMENTED ACCORDING TO PLAN. ALL OF THE NEW COMPUTERS WILL BE

"1750A" TYPES, PROGRAMMED IN THE SAME HOL - "1589" AND WILL USE
THE SAME SOFTWARE SUPPORT PACKAGE. THE ENTIRE SYSTEM WILL BE
INTEGRATED USING THE "153" DATA BUS, THIS WILL BE THE FIRST TIME

A MAJOR WEAPON SYSTEM INTEGRATOR HAS ASSEMBLED ALL THESE AS INTENDED--

AND GENERAL DYNAMICS IS DOING IT BECAUSE IT MAKES SENSE.

47
 Now, THE AIR FORCE'S HARDWARE STANDARDS ARE NOT QUITE'SO
* TRANSPARENT TO EASY TECHNOLOGY INSERTION. SOME OF THESE, LIKE THE
F3 INS, COULD RESPOND TO COMPETITION AND TECHNOLOGY INSERTION IF
WE HAD AN APPROPRIATE BUSINESS STRATEGY AND LOGISTIC SUPPORT
PHILOSOPHY THAT WOULD NOT PENALIZE ALL BUT THE ORIGINAL WINNING
CONTRACTOR. THE COMBINED ALTITUDE RADAR ALTIMETER AND THE
STANDARD CENTRAL AIR DATA COMPUTER ARE LESS COMPLEX SUBSYSTEMS
AND DIRECTED PRIMARILY AT A LARGE RETROFIT MARKET. THEY ARE,
THEMSELVES, TECHNOLOGY INSERTION EFFORTS IN AN AREA WHERE CHANGE
HAS BEEN SLOW TO COME, AND THE NEED FOR FUTURE CHANGE UNCERTAIN.'
WE MAY BE ABLE TO. PERFORM THESE FUNCTIONS ANOTHER WAY IN THE
NEXT GENERATION AIRCRAFT.

WE THINK OUR DECISION TO FOCUS OUR STANDARDIZATION EFFORTS PRIMARILY

ON THE INTERFACES RATHER THAN ON HARDWARE, HAS PROVEN TO BE A GOOD
ONE. OUR DIGITAL AVIONICS STANDARDS, CREATED TO ASSURE THE
POSSIBILITY OF CONTINUOUS TECHNOLOGY INFUSION, HAVE NOT, TO DATE,
INHIBITED THAT PROCESS. AS A MATTER OF FACT, THESE STANDARDS
HAVE HELPED ESTABLISH-AN ENVIRONMENT WHICH EXPEDITES THE TECHNOLOGY
TRANSITION PROCESS. ON THE OTHER HAND, OUR HARDWARE STANDARDS
HAVE BEEN FOCUSED PRIMARILY ON CURING EXISTING LOGISTICS SUPPORT
PROBLEMS, AND HAVE BEEN DIRECTED AT LESS COMPLEX SUBSYSTEMS IN THE
"COMMON" AVIONICS AREA. WE DID THIS BECAUSE IT IS POSSIBLE TO USE

4.8
TV7 . i ..
": -3 . . "77.......,

THEM ACROSS A NUMBER OF WEAPON SYSTEMS. THE "NEED" FOR

TECHNOLOGY INFUSION INTO THESE BLACK BOXES IS LOW AND IS

OUTWEIGHTED BY THE IMMEDIATE LOGISTICS SUPPORT ADVANTAGES AND

LOWER TOTAL LIFE CYCLE COSTS. EACH WAS SELECTED AS A CANDIDATE

BECAUSE OF THE VERY HIGH SUPPORT COSTS OF THE CURRENT SUBSYSTEMS

THEY WILL REPLACE.

IN CONCLUSION, I BELIEVE OUR TRACK RECORD HAS BEEN GOOD SO FAR,

BUT THAT DOESN'T MEAN WE CAN REST ON OUR LAURELS. WE SPONSOR

THESE CONFERENCES SO THAT ALL OF YOU WHO ARE INVOLVED IN THE

STANDARDIZATION EFFORT CAN CALIBRATE AND TRACK US. YOU NEED TO

KNOW WHERE WE ARE COMING FROM AND WHERE WE ARE HEADED. WE, ON

THE OTHER HAND, HAVE A GREAT NEED OF YOUR FEEDBACK AND CRITIQUE.

TODAY'S SESSIONS SHOULD SHOW YOU THAT THE DOD's EMPHASIS IN

STANDARDIZATION IS INCREASING AND THE CROSS TALK AMONG THE SERVICES

IS EXPANDING. YOU CAN EXPECT MORE JOINT STANDARDIZATION PROGRAMS

IN THE FUTURE. WE'VE ESTABLISHED A NUMBER OF COMMUNICATION

CHANNELS FOR YOU TO BE HEARD. IF SOME QUESTIONS ARE STI'LL

UNANSWERED AFTER THE NEXT THREE DAYS OF DISCUSSION, THEN GET IN

TOUCH WITH MY STANDARDIZATION TEAM AT ASD: MY CONSCIENCE -- THE

DEPUTY FOR AVIONICS CONTROLJ AND MY STRONG TECHNICAL EXPERTISE-- THE

DEPUTY FOR ENGINEERING. IF WE ANSWER JUST ONE FUNDAMENTAL QUESTION

FOR EA OF YOU, WE'LL LOOK UPON OUR INVESTMENT IN THIS CONFERENCE AS

HAVING AMPLE RETURN.

THANK YOU.

49
1wa
 DOD PERSPECTIVE ON STANDARDIZATION

Mr. WILLIAM A. LONG

DEPUTY UNDERSECRETARY
FOR
ACQUISITION MANAGEMENT

Let me first tell you how delighted I am to be here to address this group
on the DoD perspective. It is a real delight to me as an OSD representative
to see the enthusiasm for the standardization program, both within the
Department of Defense and the contractor community that the crowd here
evidences.
- This is the second AFSC conference on standardization. It evidences the
growing support for, as General McMullen properly puts it, "Rational
Standardization". The concept is here to stay, what I'd like to do as a
starting point is to spend a few minutes talking about the role of standar-
dization within the planning and policy process of OSD and I want to do that by
talking about three basic points. First of all, the Acquisition Improvement
Program of which most of you have some familiarity; particularly Initiative 21
which is the standardization initiative. This, as many of you know, calls for
the Department, overall, to use standard operation and support systems to the
maximum practical extent and I emphasize the word practical because as we know
the standardization process in theory and in practice is not an end in itself
but rather a tool to be used to improve the quality and the cost effectiveness
of the weapon systems and support systems that we acquire. That is the ultimate
goal. I also want to focus a little bit on how the standardization efforts
throughout the Department have a very positiveeffect on other elements of our
Acquisition Improvement Program and ouir attempts to rapidly implement that
program. Finally, I would like to address briefly some recent changes in the
Department of Defense Standardization Program both as to substance and emphasis.

The first point, the Acquisition Improvement Program and the role of stan-
dardization within that program. A little bit of background, as many of you
know when Messrs. Wineberger and Carlucci came into office in January of last
year, they recognized that even though the Department of Defense acquisition
process system and people are probably the finest in the world, we still had to
take effective steps to do a better job throughout the acquisition process. We
had a mandate as the polls reflected to rearm America, to commence a defense
buildup, to reverse a course of the prior few years. But in order to maintain
the mandate, if you will, the balance in favor of the defense buildup, which was
a fragile balance and always will be, we had to do the best possible job in
making effective use of the taxpayer dollar. So, given the recognition of the
need to improve the acquisition process, the question is how to go about it.

one of the early and easy decisions that Carlucci and Wineberger made was
that we would not as a Department engage in a new in-depth study of the acquisi-
tion process. It has been studies to death. The Commission on Government
Procurement in the early 701s, the Defense Science Board Task Force of the
tnid-70's, and on and on and on. What they really decided to do, which I think
in retrospect was a very wise and effective decision, was to put together a
steering rgoup, or a task group to look at the studies of the past generation,
draw out of those studies the principal practices and phjilosophies of acquisi-
tion that made sense, tie them together in a package and set about implementing
them.

51
 This all came to fruition in March, 1981 when the task group presented to

Mr. Carlucci a re~port entitled "Improving Defense Acquisition Systems aiid Re-
NO ducing systems Cost". the steering group which had reviewed literally hundred,
of recommendatis brought up within the Department and through substan1tial
industry participation, the steering group synthesized this body of Suggestions
0. diwb ti thirty-one elements. One of these recognized the need to consolidate
requirements, to develop single standard items either interface or in more
detail depending upon how the standardization p ogram itself were to evolve. It
recognized that there was tremendous payoff and~ benefit here if we do the right
thing in a smart way. The thirty-one recommendations resulted in Mr. Carlucci's
famous (or infamous) April 30, 1981 memo called the "DoD Acquisition Improvement
Program". By way of a footnote, as many of you know, there are 32-elements to
the program now; the thirty second one on competition was added several moths
later. But in that April 30th memo again the notion of the contribution that
effective standardization can make in reducing overall acquisition cost was
recognized and is embodies, embraced in Recommendation or Initiative Number 21
in that memo. I hasten to point out that there is no prioritization in the num-
bering system of that memo. It is not to be inferred that because standar-
dization or the standardization philosophy is in Number 21 that the precede ing
20 are more important. There is no prioritization in the arrangement of the
.4N elements within that memorandum.

In that recommendation or in that initiative, Mr. Carlucci directed that

standard subsystems and related support equipment be identified and developed to
meet projected weapon system needs, with the view to achieving significant bene-
fits in the areas of reducing acquisition cost, reducing develpment time,
reducing the maintenance, supply and operating costs and saving substantial time
and money by using previously tested, reliable and proved equipment. Now let me
emphasize those four points because they really reappear and they will
throughout this conference as well as throughout the entire program of
s tandardizat ion.

The four points; reducing or lowering acquisition costs; reducing develop-

ment time; cutting the maintenance, supply and operating costs; and using pre-
viously tested, reliable and proved equipment. There are lots of different way
to say that but those are, I guess, the four points that really drive the
program.

As I indicated earlier and as General McMullen indicated, standardization

is not again in and of its self, but its a program that can lead to positive
benefits in these four areas. Now one could expand that and put suebsets thor,
* but I think those really are the fundamental underpinnings of what we are trying
to accompish. Now, progress toward implementing the Carlucci Initiative Number
21 is, I think we have to acknowledge, satisfactory. It is slower than we would
4 like but it is coming along. General McMullen indicated or identified several
programs; we're always impatient, there are others that I could mention; he men-
tioned 1750; there is the multi-role radar, the Joint Tactical Information
Distribution Systems which they call JTIDS, the next generation IFF system;
* these may not be quite as far along as some of the programs that General
McMullen identified, but they are major programs that have significant involve-
ment in the standardization process or major programs in which the standar-
dization process is playing a significant role. So we are coming along. I
guess we're always impatient adn we ought to be impatient, we like things to
move along faster, but Rome wasn't built in a day and we're not going to change
in a day, or a week, or a month the basic way we do business.

52
We move it along slowly doing the best job we can to make certain our decisions
and our implementation programs are effective and in essence, that we do the
right thing.

In all of these systems, the ones the general mentioned, the ones that I
mentioned and others that are too numerous to mention, we really are recognizing
and beginning to see the tangible benefits in cost, time supportability and, of
course, readiness; the four tiems I mentioned earlier perhaps stated in slightly
different words. As a part of our DoD Standardization effort, we set up a cross
services or tni-services DoD panel to examine ways that contractors and program
managers can better identify and develop and use standardized systems and sub-
systems. Some of the results of this panel have now come into our defense
material standardization and specifications board and are being evaluated. As
time goes on, you will see new ideas coming out of the field, to the community
which you represent, in a large part, the people who really make it happen.
You'll see these ideas evolve out of the panels and the boards; we'll dialogue
it with the entire community and come up with new and better and more effective
ways to keep the program moving both philosophically, from a policy standpoint,
and practically, from a program implementation standpoint.

Let me move to the second point now: how standardization can help the
acquisition process in other ways. One of the examples that is most indicative
of the broad role of standardization is the area of capital investment. As you
know, we have a variety of initiatives designed to stimulate capital investment
within the defense industry for a whole variety of reasons stemming from or
starting with program instability and running the gamut to a hundred other
contributinp factors. We have seen a defense industrial base in the last 10 or
15 years substantially under-capitalized. New investment just hasr't flowed
into the defense Industry the way many of us would like it to have flowed in
order to keep a strong industrial base. And I'm not being critical of the
industry, I think the system of which we are all a part has really inhibited
investment.

One of the things that standardization does is play a significant role in

reversing that trend and stimulating investment. As we move into areas of
multipurpose support equipment, for example, this would permit the contracting
community to engage in longer production runs and this is a very natural stimu-
lus attractive for capital investment if the contractor knows he is going to
build a thousand widgets over three years rather than 250 widgets this year and
maybe none next year; then he's really in a position to make the investments in
producibility enhancing equipment and other kinds of equipment to Just do a
better more efficient job. that's one of the cross fertilization benefits of
standardization and there are others. Running throughout the entire Acquisition
Improvement Program you will find varioua initiatives directed to readiness and
support. There are at least half a dozen that bear directly on readiness and
support. Standardization is a program that can, independent of the six specific
initiatives, enhance readiness support. Our standards bear parts-related sup-
port equipment, training devices and related technical data, Flowing out of the
standardization program can go a long way to improving readiness and support.

Effective competition can be enhanced when properly planned and executed.

Standardization encourages technical improvements, and in view of many of us,
will permit greater competition in development and in production. There are
naysayers, of course who dispute this and say that standardization stifles inino-
vation and stifles competition, this, of course is neither the desired result

53
-ior the necessary result, and, as General McMullen pointed out, if properly c.,
Ladardization can enhance innovation or technology transition and can and :-
in face enhance competition.

Training is simplified as i mentioned since the need for knowledge and

skills are reduced at least to the extent that there is a cross-utilizatLion of
common equipment.

Some of the changes in direction and emphasis: the third point I wanted to
mention briefly within OSD abd tge policy activities throughout the services.
The Defense Material Standardization and Specifications Board which I mentioned
earlier is a board that was a bit dormant for a number of years until about
mid-1981. It is made up of, as many of you know, flagrank or equivalent civi-
lian representatives from all of the services, from the Defense Logistics
Agency, from Research and Engineerig and from the logistics arm of MRA and L.
The board's responsibilities include developing defense standardization
guidance, which I'll come back to in a moment, recommending through the
Acquisition Management Office to Dr. DeLauer cost effective standardization
programs reviewing progress on the standardization programs. The board itself
is now considering how it can better work with a couple of service panels, one
is the Joint Services review Committee on avionics, which the folks here at
Wright-Patterson are very familiar with and the Joint Logistics Commanders Panel
on ground support equipment. There is a natural fix between the Board, the
Review Committee and the Panel not that the activities of the Review Committee
and the Panel are going to be diminished but rather there will be an enhanced
opportunity to speed along the process by the interaction between the Board and
these two groups.

The Board is also looking at a very important matter, a better way to

ahndle the budgeting and funding aspects of defense wide standardization
programs. Specifically, can we do a better job of supporting the programs
manager's upfront needs for standardized material as a prt of ne systems equip-
ment developments. That's a problem that we've got to face up front and I want
to come back to that because it seems that that is one of the big challenges for
this conference.

I know that you have a lot of activity related to specific programs, but I
think while the standardization community is collected here, it is entirely
appropriate to look at some of the basic underpinnings to the overall program
well as the specific elements and funding it seems to me is one of those general
issues that out to be addressed. Within the department and through the auspiccc
of the Standardization and Specifications Board as well as others, there has
been a substantially increased emphasis overall in the standardization process.
The services and their implementing organizations are following this lead or
maybe they're leading and we're the followers but it's plain to see throughou
the military departments that the commitment to rational standardization and
achieving the benefits of a successful standardization program is really coming
to the full.

The Air Force for example, has increased the level of authority and resp,1-
sibility fo its standardization office in the Secretariate, IL now report,
directly to the Deputy Assistant Secretary for Logistics, Lloyd Nos"-i-r'. .
the services are looking for ways to enhance the stature, if you wi..1, c, t'
't;andardization activities. I mentioned earlier the guLdnn :-

54
 Standardization Board and Dr. Delauer's office issued the 1982 Defense
Standardization Program Guidance. Many of you perhaps have seen that and read
it in detail, but let me just mention briefly some of the things that it
addressed.

The development and implementation of standardization plans for identified

high payoff product and technology areas. Areas such as VHSIC, fiber optics and
embedded computer resources. The reduction in the proliferation of material to
satisfy similar generic kinds of operational requirements. Optimizing the use
of commercial products which meet military requirements in lieu of products
designed specifically for DoD use.

The '83 guidance is well into preparation and should be out shortly. I
would guess it would be out earlier in '83 than the '82 guidance was. At least
I hope this one come out before March of '83. Again, we are going to be
focusing on ways in whioch the standardization program, rationally applied, can
reduce acquisition life cycle cost, reduce the acquisition risk, reduce lead
times and improve readiness and supportability of our defense equipment. The
challenges that we, as a Department and we, as the standardization community,
face are geat. We're looking particularly at standardization issues involved
with embedded computers and avionics as well as a broader range of programs that
will be alluded to throughout the course of the three days.

Let me urge you as you approach your technical sessions in this conference,
to keep in mind the broader issues - again standadization is not an end in
itself but it is a way to achieve greater eficiency and effectiveness in the DoD
systems and material acquisition process. The big challenge 'Which I mentioned
earlier of a general nature, that we need to wrestle with is funding. All too
often the program manager has a legitimate concern as the standardization pro-
cess for a particular subsystem commences with his program that it is going to
cost his program greater dollars than it would if he simply went forward with
his program on a unique basis. The upfornt funding, how do we properly allocate
that up-front funding, those up-front dollars among not only the initial
program which out not to bear the total cost but all the successive programs
that benefit from the standardization effort. There are a variety of ways to
handle this but so far we seem to get hung up in our internal budgeting and
accounting process and we haven't found an easy way to escrow those funds, if
you will, or an escrow account to spread those funds over successive programs.
This community is a community made up of very bright people and I would
challenge it to spend some time individually, in small groups and in large
groups to work that problem and to come up with some suggested solutions.

the big caution that I would urge upon you, and which General McMullen also
alluded to, is to incorporate in the program philosophically and practically a
sufficient amount of flexibility so that we don't stub our toes within a struc-
ture that is too rigid. All too often throughout the history of the Department
of Defense and other big institutions, this is not a foible unique to the
* Department, but a policy comes down without the flexibility that the executors
need to do the right thing. And I think as this rational standardization
program evolves, we have to be careful not to let ourselves fall into that pit.

55
 The need for flexibility in a humorous note is best exemplified by
,.hat many of you from Wright-Patterson perhaps have heard, that perhaps th..
your from elsewhere haven't. It involves a subject near and dear to the hea:.
of many Ohioans; namely the Ohio State Michigan football game. Some years arn,
Michigan late in the game, which was tied to 20-20, had just gotten a first do-r,
at its own 30 yard line but in the proces its second string QB had been knocked
unconscious. The first string QB had been injured earlier in the game, so Be
Schembechler looked down the bench and he sees his 3rd stringQB, a kind of lum-
bering, ponderous chap who hadn't played much during the year. He sends hip: ;

with the instructions to run three plays and punt. So lo and behold the QB goes
in and on the first play he startles Schembechler by throwing a pass that's
complete for 25 yards. The next play he runs a double reverse that picks up 20
yards. The third play he completes another pass down to the 10 yard line, and
of course, on the fourth play he punts. Schembechler is going quite beserk as
the QB comes back off the field and he grabs him and says, "What in the world
were you thinking of when you punted?" This ponderous QB looks into
Schembechler's eyes and he says, "I was thinking we got the dumbest coach in the
world".

So, let us as we evolve the rational standardization program, let's build

into it sufficient flexibility, so that the executors, the people who are really
charged with getting the job done, that they have sufficient flexibility to do
the right thing.

I think that if it is not clear to the community yet, it will become

clear as time goes on, that the Secretary of Defense and his staff are very much
committed to the program that is so important to you folks that you are working
on a daily basis. Let me tell you that if ther is anything that we can do to
help ypou, either in a positive way or in a negative way, in the sense of
removing something that we've done that yopu see as inhibiting you, don't hesi-
tate to contact us; because we are simply a support organization her to support
you folks in doing the job that you do so well. But if we can be of any help to
you, let us know.

I wish you a successful and productive conference and as I say, if there Is

anything we can do, please let us know and "thanks" for the invitation to come
here and share with you some of the thoughts on the OSD perspective.

William A. Long took office as the Deputy under Secretavy of Defense for
Research and Engine ring (Acquisition Management) tn 1981.
Hr. Long ya born In Cincinnati, Ohio In 1937. S graduated from Xavier
University to 1959. Mr. Long's college education was Interrupted for a
two-year period during which he served on active duty vith the U.S. Army.
Following hie graduation, Mr. Long attended the University of Pennsylvania.
Wharton School of Business and received his M.B.A. degree in 1961. Several
years later, Hr. Long enrolled in the Bostos Collqe Law School where he
was awarded a degree in 1967.

Prior to hia appointmst,. Hr. Lonwus a Partner in Lathem & Vatkims. Sis
activities were concentrated on business matters including securities.
financing and goverlment contracts. We haa had extenstve experience with the
gover t acquisition Process, including vork an contracting for major
system. in his position a Deputy Under Secretary, Hr. Long serves as the
principal advisor to the Under Secretary of Defense for Research end
ZogLneerLog to all matters concerning management and policy for the
Department of Defense acquisition process. Hr. Long is the Chairmn of
the DoD Acqoisttion laprovecent Program Steering Group which is responsible
for implementing mJor improvements both in wespons acquisition phlorophy
end the acquisition process itself. Under his guidance, many of the poliri
decisions required for implementetfon of improvemenrs hav been mace an
put inte effect. Hr. Long is also responsible for making prom-er ,t , ,"
imrovere.ts in accordance with Evecutive Order 12352 of errN + ',17
Federsl Proc.urment Reform and is the DoD member of the tC ..
Couaittec. on Procurevent Reform.
Mr. Long and his wife. Jeaney. bae six iiAtrean,andToeA a, I -

56
 .P-E7 .' 7 OM

Speech To 2nd AFSC

STANDARDI ZATION CONFERENCE
30 November 1982
Dayton Convention Center

by

MAJOR GENERAL JASPER A. WELCH

Assistant DCS/RD&A
HO United States Air Force

Good morning! I have come this morning to talk about what

some see as a double edged sword; on one side technology -- on

the other side standardization. We are in the technology

business, but without some standards the diversity and complexity

of technology is threatening to stall our progress in applying our

technology to systems.

There are some who are convinced that complexity is all bad.

They would have us go back to the weapons of World War II. If you
can get these people to sit still and listen, I have some facts for

you to tell them:

In World War II, ou'r fighter aircraft averaged one combat

mission every four days. In Korea, the rate had increased to one
mission every three days. By the Vietnam War, USAF fighters were
averaging nearly one mission a day and current planning rates are

even higher. Surge tests with F-15 units in Europe have demonstrated

rates of better than four per day. Now you can't do that with
piston engines and tube type radios. Technology and complexity
have brought us a long way.

57 1
I%
 We do have some problems though: in Vietnam we found ourselv-

with aircraft grounded for lack of spare avionics while we had all
sorts of spare avionics that would not fit the aircraft.

Following the Airlines Lead in F!2 Standardization

This problem stimulated us to look at how the airlines had

solved their very similar problem. We found that they had two thinql3
going f or them:
first, the concept of form, fit and function (or F3 )

standardization, and
second, the process for development of standards.

The concept of F 3 standardization has been abstracted slightly

to meet our needs and in its more general form goes by the nam'e of
"Interface Standardization."

Having looked at the airlines' success story, and after

some study on how to adapt the essence for our use, the first

thing we did was to try it out. We looked around for a susbsystem

that might have a fairly wide application and one where we had a

lot of non-interchangeable equipment in existing aircraft. The

system couldn't be too close to the state-of-the-art, and should
have a number of potential vendors.

The standard medium accuracy Inertial Navigation System was

the choice. The first industry open forum was held in 1976 and a

year later the spec was completed. A contract was awarded to Lit',

In 1979 for INS's for the A-10. First deliveries were taken in
1981 so that after five years we got our first system.

58
R -77XZM T U -C IT-1 -7 R-. r. A - -7 iW-10Z-r UN . -. - ;.... " -q

Interface Standardization As We Know It Today

In 1974, the Avionics Lab had become deeply involved in the

Digital Avionics Information System or DAIS program and in 1975

began to advocate the adoption of interface standardization as we

now know it. By this time, the Aeronautical Systems Division had
enjoyed good success with the MIL-STD-1553 multiplex bus during

the F-16 development. In 1975, the Avionics Laboratory identified

a version of JOVIAL as the preferred higher order language for

avionics and in 1976 began pursuing a computer instruction set

architecture standardization effort in cooperation with the Aero-

nautical Systems Division. These efforts put into place the

standards for a computer programming language and a computer

instruction set architecture which eventually became MIL-STD-1589B

and MIL-STD-1750A.

Establishment of the Deputy for Avionics Control

At about this same time an Air Force Scientific Advisory Board

study identified the avionics acquisition process as something that

needed attention. After additional study, discussion, and corre-

spondence Dr. Martin, then Assistant Secretary of the Air Force

for Acquisition and Logistics, approved a joint AFSC/AFLC plan and

charter creating the Deputy for Avionics Control.

We put out a regulation (AFR 800-28) titled "Air Force Policy
on Avionics Acquisition and Support.' This regulation described in
detail the responsibilities of the Deputy for Avionics Control.

59

e: M-4
Actions Speak Louder Than Words

Since we established the DAC we have put out a joint RD/LE

policy letter requiring the use of JOVIAL J73, MIL-STD-1750A, and
MIL-STD-1553B for avionics, and we have encouraged their use in

other applications.
We have written the requirement to use these standards into

just about every avionics related PMD we have issued over the last

three or four years.

We have begun the process of putting a common bus-oriented

avionics architecture into almost every aircraft in the Air Force

inventory.
We have issued (jointly with the Army and the Navy) MIL-STD-

1760 as our aircraft-to-stores electrical interface. We are requiring

that all of our new weapon developments use this interface, and we
are developing plans to incorporate it into our aircraft at the

earliest opportunity.

Joint Service Review Comittee

We have established a tri-Service group called the Joint

Service Review Committee for Avionics Subsystems and Components or

JSRC for short.

The Air Force representative on this committee is the Deputy

for Avionics Control. The JSRC was established by a joint memo-
randum of agreement between the Army, Navy, and Air Force Assistant

Secretaries for Research and Development to look for opportunitie

60
to achieve joint Service avionics standardization and to execute

Joint developments when a common requirement exists. They also

serve to document cases where a joint development is not
prudent.
we already have one joint program in
development with the
Navy -- the Standard Central Air Data Computer which the
Air Force
will put on the F-4, F-Ill, C-SA, C-141, and B-52 over the next

few years.
Other projects in various stages of program formulation and

planning are a Digital Audio Distribution System to replace

many
of our antiquated aircraft intercom systems, a crash survivable
flight data recorder, a heading/attitude reference system, and a
ground proximity warning system. The heading/attitude reference
system will be an Army/Navy funded development while the rest will
be tri-Service efforts.

.
'
w
8
,
.'
..
r
,
L,
l
,,
t]
.1
"."
p,.
'.
""'
,.
'X,
''," ,",.," --I
,, ' ,,-'
61
 Rational Standardization Benefits

CARA
o Replaces five high and eight low altitude
radar altimeters
o 4000 inventory aircraft retrofit (TAC, SAC,
MAC), plus F-16 MSIP
o ;riced options 2700 (additional) (AF, USN, USA)
o Nuclear Hardened
o S5800 (ea) (Est $123M cost avoidance) 15 yrs LSC

F. INS
o 525 hours (fighter) MTRF (guaranteed)
o Acquisition/support cost avoidance -
minimum S60M

CDU for F.2 INS (A-10 Aircraft)

o Modern technology (CRT and Keyboard)
o SlIM cost avoidance

1750A Processor for F-1ll

o 2000 hour MTBF (guaranteed)
o $46K/Unit (estimated cost avoidance S20-40M)

C/KC-135 Update
o Specifications/standards - saved $20M
o MUX Bus/Architecture - saved $600M - 18 yr LCC

MRR (Multi-Role Radar)

o F-16 and B-lB Commonality (3 of 4 LRU's)
o Acquisition - S114M savings
o Shared production manufacturing - S130M
savings (additional)
o Support equipment/training/data TRD (EST $10-15M)

SCADC (Standard Central Air Data Computer)

o USAF and USN commonality (5000 aircraft)
o First product of Joint Service Review Committee (JSRC)
o Estimated acquisition cost avoidance - S30M
(4 standard CADCs vs Six unique CADCs)

GPS
"o F3 specification for receiver/processor unit
o NATO wide commonality
o Estimated $200M cost avoidance to USAF and NATO

Common Radios (ARC-164, 186, 190) and TACAN (ARN-1i1)

o USAF wide commonality
o LCC savings - $71M per year minimum

62

V V .W..
 Our Record Speaks Loud and Clear

Overall, I think we have a very good record of successes

in avionics standardization. Successes which have come from'
* three main thrusts:

First, adopting as standard items those subsystems that

were reliable, m'aintainable, and simple enough to be adapted

to many different installations. Examples are the ARC-164 and

ARC-186 radios, and the ARN-118 TACAN.

Second, developing standard subsystems when none of the
existing equipment met the criteria for adoption as a standard

item. The Standard Central Air Data Computer, Standard INS,

and the Combined (high/low) Altitude Radar Altimeter (or CARA)

are good examples of this type of standardization.

Third, where technology was changing rapidly, or where an

aircraft unique piece of hardware was required, we have insisted

only on adherence to the standard interfaces to enhance supportability,

reduce future aircraft modification costs, and increase competition
up front. Examples can be found in the F-111 digital computer
replacement program and in both the F-16 and P-15 MSIP programs.

The results are impressive:

CARA will produce a $123 million cost avoidance over

15 years.
The F3 INS will produce a S60 million cost avoidance; and that
will increase as we buy more of them and put them into more aircraft.

63
 The control/display unit for the F 3 INS in the A-10 will yielO

a cost avoidance of Sll million.

The new computer for the F-ill will yield at least a S20

million cost avoidance -- and because we had the forethought to put

a MIL-STD-1553B rultiplex bus interface into the computer, much

larger savings will accrue as we proceee with the F-ill Avionics

Modernization Program.

Inclusion of the multiplex bus architecture in the C/KC-135

update program will save $600 million over a 10 year life cycle,
and the use of the interface standards will save about S20 million
in acquisition costs.

Commonality in the F-16 and B-i radars will save S244 million

in acquisition costs with an additional saving of at least S10

million from common support equipment, training, and data.

Wide use of the ARC-164, 1R6 and 190 radios and the ARN-118

TACAN is saving about $71 million per year in reduced maintenance

expense.

The standard CADC will save us another S30 million and NATO

adoption of an F 3 specification for a Global Positioning System

receiver/processor is anticipated to save at least S200 million

dollars. I think it is clear that we are already reaping substantia-

benefits from our standardization program!

64
Reliability Efforts are Closely Related
There are other areas of electronics that we are interested in
which complement our standardization efforts. First and foremost
is our campaign for avionics reliability. You can read more about
this campaign in the upcoming December issue of Electronic Business,
but I would like to take a moment to touch on the highlights since
they are so closely coupled to our standardization program.
I will make three claims about reliability:
1. You can get as much as you want
2. It costs less than you think
3. The payoff is greater than you expect
At the line replaceable unit level we need about 2000 hours mean
time between removals. For a wing of 9Ei aircraft, this corresponds
to about one removal of a particular LRIJ per month at peacetime
flying rates, and under a wartime maximum sortie surge situation a
box would have a 90% chance of no failure in 30 days. That's the
real requirement and your Air Force leadership is determined to
put on a full court press to meet it. This past summer the Air
Force Scientific Advisory Board, with major support from the

electronics industry as a whole, looked into the promise of the

*New Electronics." They came away with the firm conclusion that

very significant reliability improvements are possible and would

be facilitated by current technological advances. They also observedI
that existence of a technology does not guarantee it will be correctly

applied or will solve the right problem without proper management

attention and direction.

65
Key Role of the Design Engineer

But to make these opportunities come to fruition requires hardI

work, innovation, and serious goals. In my view the key to success
is a fired up design engineer with solid backing from his industrial

organization and his government program office.

If I were given the job of evaluating whether a piece ofI
equipment was going to be reliable, I would go to the design engineer

and ask the following questions:

Does your design want to work?

Are you using robust components?

Do you have confidence that your test procedures will

discover faults in design and manufacturing?

Will your design tell the operator when it's broken?

will your design keep on working even when it's broken?

aeIabepout
believe you will
ewlfind aerayafraieases-
that if your engineer is on his wayn toI
artiale thatct
wil wista srtiny. Iffiryouiget angled oran

patronizin lookwil gettaourslf tantey nne. If you get

lzdo
a
neatoiive relyk thetou youyourf poghr oficneiner afogt of

i
trouble.

Software Reliability
Software reliability is another area that clearly needs work.

Programm'able digital avionics are here to stay. Unfortunately,]

66
most industrial managers and all too many Air Force managers view
software management as a mystery world. Having written more lines

of code than most people, and having designed and supervised many

times more, let me assure you that standard management approaches

work just fine.

In fact it is pretty easy to lay out a few analogues to

illustrate: coding errors are like wiring errors -- an error prone

craftsman cannot he tolerated in either case. Top Down Structured

Programming is strictly analogous to the Work Breakdown Structure.

,Software Development Tools perform the same function as an

oscilloscope and other bench testing apparatus for functional

checking. In both cases, testers and designers must have a proper

arms length relationship. overall design architecture errors are

as fatal as ever. Finally, make or buy decisions remain the first

responsibility of management.
The underlying difficulties in software at the present time

are three-fold:

1. The hardware is subject to rapid technological change

so that detailed reapplication of prior accomplishments are scant;

2. The field is rapidly expanding and thus attracting a lot

of marginal performers at both the individual and organizational level.

3. Managers still don't give software the attention it merits.
The software problem is real and its causes are fundamental,
but it will yield to solid management attention. Some companies do
a good job -- we intend to get them on our team.

67
 Our emphasis on reliability and quality will increase very

* visibly in the near term as the new Deputy for Acquisition

Logistics at Systems Command Headquarters begins to focus on this

subject.

Lessons Learned

Coming back to standardization, I would like to turn for a

moment to the topic of "lessons learned." Perhaps as much as

anything else, we have learned that standardization is a continuing

process of education and evolution. Education because the engineer

that doesn't know about the standards will always invent a different_
way -- and evolution because the engineer that does know about the

standards can invent a better way.

we must continually be alert to counteract the first case and

to encourage and support the second. For everyone of you in this

audience there are at least ten that need to know more about the

standards -- not just that they exist, but how and when to use they"
well, how to avoid their misuse, and when not to use them at all.

A standard that doesn't evolve is a dead standard. The lack

of evolution indicates a lack of interest. No interest, no educati

no education, no utilization; no utilization, no standard! The

reason for a lack of interest doesn't really matter. It may be

that there is no need for the standard or that technology has

passed it by because the standard was not adaptable to change -

the result is the same.

68
rN
E~L
4 1 .- h * ~ ~ ~ ~ ~ ~ V''~-.*

Now a standard is most useful if it has a long life.

So we must be careful when developing new standards and

modifying our old ones to assure that we don't make the standards

obsolete unnecessarily soon.

Future Directions

Now a word about what I see as our future direction in

standardization.
Right up front, let me tell you that interface standards

are still our main thrust. They allow us to put the pieces in
place today that will shorten development schedules, reduce

modification costs, and increase competition.

They also allow products developed with company funds to be

brought to us in a form that is compatible with both our aircraft

and our logistics systems.

I am not aware of any cases where we have completely eliminated

a government funded engineering development phase (with the possible

exception of the F3 INS). But I do think that there are opportunities

for innovative products to be brought to the military avionics

market that will fit our aircraft and work the first time out.
Current Standards Have a Good Record
We have an excellent history with our current set of our avionics]
architecture standards. For those of you who came for the tutorials
yesterday, I am going to ask for your indulgence for a few minutes.

For those of you who didn't, I want you to know why I think we

have a success on our hands.

69
 Avionics Interface Standards

Current

MIL-STD-1553B Multiplex Data Bus

MIL-STD-1589B JOVIAL J73

MIL-STD-1750A l6-bit Computer Instruction

Set Architecture

MIL-STD-1760 Aircraft-to-Stores Electricf I

Interface
MIL-STD-1679 Software Development

Future
MIL-STD-1815 Ada - DOD Standard Program'
Language for Embedded
Computers

MIL-STD-1862 Nebula - 32 bit computer

instruction spt
architecture

MIL-STD-XXXX High Speed Multiplex Bus

MIL-STD-YYYY Packaging Mounting and Ce&

for Airborne Electronics

70
 a
T-

USAF Application of the Avionics Interface Standards

MIL-STD-1553

F-5G A-10
F-15 MSIP B-52
F-16 R-lB
F-ill C-5B
KC-135

MIL-STD-1589

F-4G HH-60D
F-5G MX
F-15 MSIP Satellite Control Facility
F-16 MSIP GPS Ground Segment
F-ill Advanced Cruise Missile
B-18 F-15 Radar
LANTIRN Pods Wide Angle Raster HUD
F-16/B-lB Radar MATE

MIL-STD-1 750

F-4G LANTIRN Pods

F-SG Wide Angle Raster HUD
F-15 MSIP F-16/R-lB Radar
F-16 MSIP F-15 Radar
F-Ill MATE
B-la Advanced Cruise Missile
HH-60D

MIL-STD-1760
F-15 MSIP Common Strategic Rotary Launcher
F-16 MSIP Advanced Cruise Missile
A-10 AMRAAM
B-la WASP
B-52 MSER
LANTIRN Pods 30mm Gun
ASRAAM Conventional Standoff Weapon
MRASM

7'
 -- = -- - .7 -- - i- -FV 'W

MIL-STD-1553

MIL-STD-1553 defines our digital multiplex bus. It has been

around since the start of the F-16 development program. Industry

is familiar with it, we have lots of systems that use it, you can

buy off-the-shelf parts to implement it, and there is commercially

available test equipment for it.

MIL-STD-1750

MIL-STD-1750 defines our standard 16-bit computer instruction

set architecture. Anybody can build to it, and almost every computei

vendor selling into the military market is building a product that

implements this standard.

There are MIL-STD-1750 computers going into LANTIRN, F-16,

F-15, F-ill, F-5G, MATE, A-10, B-52 and B-1, as well as other

programs that you may be aware of, Over the period from 1980 to

1984 brassboard performance for comparable computers will increase

by about an order of magnitude while size, weight, power and cost

will go down by over an order of magnitude. Individual machines

will push one or more of these parameters by additional factors of

from two to ten. It is this kind of dynamic performance improvement

that makes a technology-independent standard so desirable, and in

this case I think we have good evidence that 1750 really is technolo(.

transparent.

72

- . U, *W!,% *'
.4

We probably have a fair number of people in the audience today

who have helped make it happen. To those of you who are here today,

and to the rest who are not -- well done!

Congressional Language on 1750

I am sure that many of you are aware that the Congress put
language into the Defense Authorization bill which directed OSD

to relook at issuing DOD instruction 5000.5X and directed the Air

Force not to fund any new developments of MIL-STD-1750 computers

without a determination from USDR&E that it was essential.

I don't think that the language will hurt us in the immediate

future, and in fact it offers some guarantee to industry that the

Air Force is not likely to fund a development program in direct

competition with a known company funded effort. Meanwhile there

are some 20 existing variants out there, many of which have passed

through the SEAFAC certification process here at ASD.

The Arguments Against 1750

There are two principal arguments that have been offered

against the widespread application of MIL-STD-1750.

First comes the claim that standardization inhibits progress

in technology, and
Second, it is said that Ada can assure transportability of

software so that instruction set architecture standardization is

not needed.

73
 I think we have adequate evidence that computer technology is
progressing quite nicely. The performance growth of various 1750
implementations over the past two years and the promise of VHSIC

performance in the next two years leads me to question the motives

of those who raise this as an issue.

In the second claim however, there may be some merit. There

would certainly be major benefits to both our computer hardware and

software efforts if Ada were the only language required -- that is,
if we could do away with all assembly language programming. But so
far as I know, nobody has yet demonstrated that this is really
possible. However, I think that it has enough potential to be

looked into in more depth.

MIL-STD 1589

MIL-STD-1589B defines JOVIAL J73, the Air Force standard

higher order language for programming avionics embedded computers.

It is being used in conjunction with MIL-STD-1750 computers on all

of the programs I previously mentioned as well as on a number of

ground based applications in support of MX, GPS, and the Satellite

Control Facility.
As more users come on line, improved support software for J*73

is in great demand and the Language Control Facility here at ASD

has a key role to play. I note that the Embedded Computer Resource

* Program Office is developing a compiler for the VAX computers.

This should help to provide a relatively low cost stand-alone

development facility.

74
 In the past, it has always been less expensive to retarget the
J73 compiler than to buy a machine for which an operating compiler

already existed. There was, of course, a delay of 12 to 24 months

to get the retargeting accomplished, and then there was the problem

of residual errors. I think we may have finally reached the point

in this case where it is cheaper and faster to buy a computer for

40 which software already exists than to retarget existing software.

MIL-STD-1760
MIL-STD-1760 defines the electrical interface between an air-

craft and a store. That store can be a bomb, a missile, a rack,

a fuel tank or a pod of any type. This standard is the newest of

our avionics architecture standards and is currently only one

third of what it will eventually he. The current standard defines

the wires for the two connectors associated with the electrical
interface, but does not define all of the logical behavior of a

loaded store. The connector design has been selected and a draft
specification is available, but we have not yet definitized the

fiber optic option that was left open in the first version of '-he
standard.

MIL-STD-1760 is being used on AMRAAM, the Multiple Stores

Ejector Rack, the 30-mm gun pod and WASP, and will be used on

the Conventional Standoff Weapon, the Common Strategic Rotary

Launcher, and the Advanced Cruise Missile. with a connector change
or an adapter, both MRASM and LANTIRN will interface with aircraft

equipped with the MIL-STD-1760 interface.

75
 V. - ... A• ~ 'F - •* • % %- %.

NATO !a actively supporting the use of this standard since it

*will allow the NATO nations to buy and use US weapons, and also tn

sell compatible weapons to the US. We are installing MIL-STD-1760

as part of the F-16 MSIP program and we are looking for the best

way to install it on the rest of our combat aircraft.

The pre-existence of MIL-STD-1760 on an aircraft should

significantly reduce the cost of integrating a new weapon with that

aircraft. It will also eliminate the three to four year delay that
we currently experience in modification of aircraft to carry and

employ new weapons.

How Do We Know We're Doing the Right Thing?

We are doing very well in the implementation of these four

interface standards, but there are some important questions to ask:

First -- how do we know that interface standardization

is the right way to go?

and second -- how do we know which interfaces to standardi-?

I claim that the best designs maintain the independence of their

functional requirements. That is -- when part of the requirement

changes, only part of the design changes. Of course this necessitat -

that the requirement be stated in such a way that it identifies

the minimum set of independent specifications which bound the

acceptable solutions. A system architecture must allow the design

to meet its requirements. So, if you will agree that a set of

76
interfaces implies an architecture, then I challenge you to find a

more appropriate set of interfaces than those that define the

natural boundaries between functions!

Our four avionics interface standards do define natural

boundaries between functions:

JOVIAL is the interface between the programmer and the

software.
MIL-STD-1750 is the interface between the software and the

computer hardware,
MIL-STD-1553 is the interface between the hardware sub-

systems, and
MIL-STD-1760 is the electrical interface between the aircraft

and a store.
We are firmly set on continuing to standardize interfaces, and

in the process we both need and want industry involvement.

Commercial Standards

We would like to adopt or adapt commercial standards when we

can - for many reasons. We adopted some in the automatic test

equipment area-when the MATE program selected the IEEE-488 General

Purpose Interface Bus and the ATLAS language for writing test

programs.

We are also willing to consider changes to uniquely military

interface standards to make them commercially viable. This might

he something for you to think about as we develop new standards for
a high speed multiplex bus and VHSIC packaging for subsystems.

77
 -7 - .W 7_r:: 7 ib -. W- -%I -:

New Standards
Speaking of new standards, I need to tell you where we are

going with some specifics on the high speed multiplex data bus, our

transition to Ada, the future of NEBULA, and our feeling about MIL-

STD-1679.

High Speed Multiplex Bus

It has been clear for over two years - since the Scientific

Advisory Board made its recommendations on the new bomber - that we

need a multiplex bus that is much faster than MIL-STD-1553.

The PAVE PILLAR program was directed over a year ago to work
with the SAE AE-9 subcommittee to produce a standard. Two VHSIC
contractors have add-on contracts to look at the problem. The AE-9
high speed bus subcommittee has had a meeting or two, and there is

some thinking going on -- but it is time to really get serious about

building a new standard. Come on gentlemen - let's get with it!

JOVIAL/Ada Transition
Our plan for transitioning from JOVIAL to Ada involves a

staged effort. We intend to take a lesson from our history with

JOVIAL and assess the maturity of the production compilers and

language support tools in a laboratory environment before we insist

that industry use them for schedule critical full scale development

programs.

78
 I should point out that there are two steps between assessing
the maturity of compilers in a laboratory environment and insisting

that industry use them for schedule critical full scale development

programs.

These steps are:

4First - parallel operational system developments, where we

identify schedule critical full scale development efforts that are

being done in a mature language (such as J73 or FORTRAN) and fund
parallel de elopments of the same software in Ada from completion

of the A-spec to the start of preliminary system tests. This type

of effort will get both Air Force and contractor experience using
Ada on full scale development programs without putting those programs

at risk.
and second - allowing programs to volunteer to use Ada where
the program office and contractor feel comfortable with Ada; the

tools are sufficiently mature; and the risks are low.

79

W Pill,
 We are looking for opportunities to try out Ada in a wide

variety of different functional areas so that we can get a feel for

what changes or additions should be made to our Ada introduction

program. Early applications of Ada to realtime systems, command

and control, parallel processing and fault tolerant systems will

be useful steps on the way to a policy of universal application.

In the interim, there is a set of rules for JOVIAL developed

by Aerospace Corporation which should ease the conversion to Ada

if that proves to be desirable. We also have begun to use Ada as

a design language to facilitate later conversion.

NEBULA

As for NEBULA, I don't think we see any near term requirement

for a 32-bit avionics processor. But, when one does arise we intend

to use the NEBULA architecture just as we have used the MIL-STD-

1750 architecture: as a language transparent basis for competition

and technology insertion.

MIL-STD On Software Development (MIL-STD-1679)

Our approach to the use of MIL-STD-1679 in the software

development process is somewhat different. We intend to use it!

You will start seeing it in the requirements that we lay on in

our contracts, but you will see it tailored to the needs of the

individual program. It is not an interface standard, it is a

process standard--and as such it is more readily adjusted to meet

special case conditions.

80
 PC%-
At[ wi - ~ -4 IV 7- '-.o .

Automatic Test Equipment Situation is Similar

As an aside, I would like to say a few words about our

standardization efforts in the automatic test equipment arena.

Some of you may be familiar with the Modular Automatic Test

Equipment (or MATE) program. It represents standardization in a

somewhat different dimension than the avionics I have been talking

about, yet the details of the standardization are quite similar--

MIL-STD-1750A computers, JOVIAL and ATLAS software, the IEEE-488

interface bus, a standard user interface, technology transparency

and increased competition.

But MATE is important for another reason. MATE will allow us

to define and require a level of test equipment compatibility that

has not been possible in the past. We will be able to mix F 3

avionics equipment from multiple vendors at the depot and run them

all across a set of test equipment that is minimally different from

what would be required to test a single vendor's equipment.

In the past, competition has been reduced in second round

procurements of F 3 avionics where the Air Force has purchased test

equipment from the winner in round one. In round two, there was

an entry cost for any new vendor equal to the cost of the test

equipment for his system.

With MATE we think that we will be able to reduce and perhaps

eliminate this cost by appropriate testability and interface

requirements written into the F 3
specification.

81
 New Avionics Support Options
If we can make this work, then it opens a whole new range of
avionics support options that the logisticians have not been willing

to sign up to in the past.

For instance, we could mix F 3 equipment from multiple vendors

in the field, buying spares instead of intermediate level support
equipment and rewarding the vendor of the most reliable system by

buying more systems from him.

We might plan on a shorter life cycle for some equipment and

buy lifetime maintenance from the vendor, or insist that the factory
test equipment conform to the MATE guides and make the test equipm'ent
deliverable to the depot after some long warranty period.

MATE is an important piece of our overall standardization

program, and it will play a role in opening up new options for

supporting the avionics of the future.

£ What Should Industry be Doing?

Before I step down 'off my soapbox I want to provide some further
guidance to those I haven't put to sleep.

For those of you who have not been involved with our standard-

ization activities -- we welcome and encourage your participation,

both here at the conference and at the users group meetings for

those standards that affect you.

Every company wants their product to be the standard. Work

with us, and with the rest of the- industry participants -- you have

82
 . . . , L - * -. - - - n . . : . . .; .- ,-, . ---.
_ .....- .-.... - . .. o - - . ,-

an opportunity to explain t,) a 'er coipet -. "

oxactly why your design is the best. Your prr -, > .

if you don't have a product yez -- T .,c..

come and bring your very best engineers to t '- roup r,,,

And when you get home, I would strongly recommend that you bua1d

your marketing strategy for the Air Force arcun< 0-,e of

,se th'

standards in high quality products.

The standards are here, they will be aroin: - r ' -

1r-m

they are useful. We intend to insist on their in proluc :E

we buy from you.

We need and want your inpUts on how the standards should evo,,
and what new standards will be needed.

The progress that is being made is very impressive. Keep up

the good work.

.8

83

E
in m ' M -,%""" / 1.
' " '% "...
: ",4', '' t;'.....
..........., . "'
*
"
.. . -', % %*
" .4 .4. * %9
4.

* I..
,,.arttJ. t at qL.sttts, l.tq .t.t.l u. Air Fate..

Ito. Uatsriit 7 ttgh Schofl. itC* 111110t Wr IO". dtata. trKet' t

Cr~isil~tiqsssbarsJit. .......... t. t' tJ.s~
sn
1u , tI id.ssitirsotclscs
h-ds.td'ttsin . l
pi~yslcrsLa ti9h ft tti* Umli ristcllfsrL/ots. SitrkIlsy. N
a d ttsktai cd s~liitart Irtaii of thts sRIt.~ Olti+ass t-s~it'" Ct'tpi
5

11 tt 1, ""-i
l, Ciff stlithe it tis A chtsrL..tt J. -. 1s

Cafno
+ .*v,W ' hisAir Fce- imsilllve of Tshnolo" p,. .r.....

Alttn ist-It ir si Any st ths Air Fore S-i-i W s C.rli- attill-a A,, ie
Etntr. N.+M. Gtiisrst Welch rots suiqiad an t ,lbtttr hil5 ts ii- Ittitlitit L,ar,tie
Latiatitlisit itI the A tasrit I titegy osnititisssi Or Ll-n- l. (.lft it. 1,,1 in
estieni mite tt$ir s stf slmh rA1snord ft4 basic dstqo ca',< tllI ,1 i
Ut 0ittii tistn_. ilhtl O 'sMi ta Liressr L astr hit ttiltti l fu'otni
'st l iiwt Lais
It.sll W.Faltt
Atnsrs,.
I

f
Tt i l
il -'csBI olsd i-ttllic saris I.tt
'O It
I, tlr-t.r the tot i.e
Pait- 'attt east. he ted is I s t istrittt' the etfeiti at tstitat weotca+ Oitrltat. c, I
Lists tenth-i nt the t1rrttathsee ta Iii tstse. Dart'sshi.settics i>'i.tl AnnaIc
tatiaa+,tstl i
n- t t-4.lts of hI. gis
1t lpt rirts sinitlfi. tr,sii ii, tt.-e r-
ti ttt
citititt l tat-'i A ll,-'
O+i''let',it aOtitaral tlt~ottatlrtiat sl.rittus la nep,t tZtro ast'.'j'-i to'ni'r'ii

+lr ,lI..-tit %iv s lir.Its -rth this lttsteqir I t,.l rinr 51

olil,f

Iits' lasit IsA? rirrarat Wsts+.55 stars ti tmststtn Ai rt+ rc.tet.,- n t-'.i.,
Otliinr ti tirs tasf M Dia l i t ta ass isaoydir-
it
A., F', fl'l, lhi, ,1,1--

+ i ' OI -niiit+t .mli l lrru teislhcei tliie .rlih'll Arsiot.o hi l&i ht e , o t i-

,.+,in P.7++, to SA , C.iertt. Welc sat,+;, ii 't'ti'. i- it' t+-aort ,,.

annt'aa t..e i..i
it.tatt,.,.e..t,ni,,.wtnhists, .itri+., o -nt i. nta,t. tt
, aiioiir no' , ,c . "l iat. At
Ateti ii=st+,st tl,+i At~t
.I l tite litqaiiratia.... l.,it-ar irma+ ,,m
i As r rs liseectr
+ , ii*+

t'tet'r'
Scntli +'rt,
I,,'slnot+,i, ~ ~
'' A1
Ptetidsstt.. e~ii A ctisat
1ScI+
.aRa, a,-el; S1--as.1',is
t1
l'il 'i te.titwt
. in
[o+. l r- t's-tit,.s
ir it

-ii
tt

a-si~~te.A
m tte' ioet''i'ntt. .
a ll
is 'es , 'nl
l ntt ' l n h-alt. 'Itt' Attm I h m i¢tt

saciet. ,+ e .n,,,i lota' t ltttai' isi the.+I it'uI 'tea

,,,ttsuu rhest
, ., o P
#°r,.str+ titaiitI Gr
ie4111 t t erterni ,l,
Alit.ia~ Ss.stsst
erobIsl a-lo wi-sd'
Ho't1t', IS.
A ', t1. laIn ts alt r u t'.,nai ts it i<ra Ct- , tst$. 1- At,,

ai isa-a
+ l a titri th e ts. ast 5t t , j ,wirl'e tonErnuiitpm+trrt t rt
itnnr l +
'tt'IS

GSt. itu t-ti,

$ treri,e- tt.+ir o fSt antt i tt~l1
l,''t Is
li it +, "Y ,in, t tII
Amr ,+ y -O

phn ms dust
t'lernitt
11. Wll
ta. fceo
Ia
e'tur
'I~
I ft
tl
l, ....... 1)r,,f
(e.t+Irsl cleici ot'
l ~
it+ iist-tu
+ 11 4
tat't
+ ~ s~
sIj Attr
m +
i
Osustm et€itt
ac a tlt Its~l rtts, sit Otoers alto itt Aursli, eaitttr uorina
i+ .,
It titl . hir it olit w- l.
t 0
h4~
r tlata rti s tc tituia
stri ii's tol psr i eiial,uit, '-a+1+I ilti +e rl S-',t'tt aea
Ata tlwra(01
sinS a~l ntt u akl n'tluo lfrtta tl* .Iottnt.t'ten taitrf lSAi.ti>it'e 4.,
Hla aI.l'a Fatri'$,.t sft dia-t, oi aile 1- 1, t t'l
l .

ll *,1 +,+,,l~lml r+,w,.1++t. -i Illbs G1. + 1 11-d , - l.f, n I- d,,," IS

,u ... ... , , Io .l f W.
nst ts II.i A,,- 1---- - -

i
RD-Ai45 697 PROCEEDINGS PAPERS OF THE AFSC (AIR FORCE SYSTEMS 2/6
COMMAND) STAND.. (U) AERONAUTICAL SYSTEMS DIV
AVIONICS AFB
WRIGHT-PATTERSON OH DIRECTORATE O__
UNCLASSIFIED C A PORUBCANSKY NOY 82 F/G 1/3 NL

EIIEIIggEllEEEE
EEEEEEIIEEEEE,
EEEIEEEEDEEE
 w.s

112511-14 11*6

N-O-
 I,,, Z w
0o mu.
A.0 z0

13, 4Z z
owui 0
*zz cc
1c*414c

0
- WOOds zo-
 o9-

E=
" -0 .0 4v
a)
U'- -

0-) "- -- ) 0 4-) >

4- :.)r (1) r 0- ED0
a) ot 0 4- 0- " . .
>., ",- ( 0 E
a) *a0- .4-)
0, -
CL)
S- a (A D u-U
Sj --

0 -' - E -3 4a) 4-'

C u, go-0 0 = V) 4-) ."
0 4-3 4E (A .0 00 41 m
Eu- (a =3- 0n u. 05
Wt to J o
'a ro cmj 4-3 S-I S-
4- In U •e1-

Lii 4-~) D a)). 0 aflO

a) -0 0 41 4- to 4-) "-
' 4-'> 0.W 4Ca ut S.- CL o Z 0
EOJ
,,4- CO J &-r
S .-,- -% c. o
*j.
0Z J-
:3 a) x > 4-
*'r-- rx 4n(
C d) E3: . u- >
0 m 0 M"U- 4- -- 4-)
or-4-3 U -m 0 0 (D- 4 r-

4-- . -- M 0

-0I--"o"to r-- S- . - r- U" c

Sr- "a E ,-- 4-c 0 c
-0 >
UU o a- 0

C---
MW.= (-
>1 u a-o 14-- .
to= ro"a 0
4 OC '0-. -4-- V o C
0 (> r-'E"
O #l4 4 sO 0r "U

rd 4-
4-3 ( r- -3 .--to L.
. to ,'-
' a) I
3- w W- -
,,,= ,
L .,-0
=
-W ::a-
I
o
CCD. C4-C 4-N
0 4--
" O-
-."0 00 E 0 a) 0
- LU .e(U )i 4-
43
- ~-C9-i3
-
O) 00-1ta
+ 4- u-
.4-
0)
c
4-
0
:
u
-- O

Ul;
-0..- 0 "0 0 0 r t-
0at a 0-l 00 0- t
I-.,-. --- (
m)sC
t 1-a >
4-)f r-tO
u ca-

86
V ~ .JL.J

= Cm

< - i C0LL
V)~~~
=-jC< - =.

=4 0- cc-

~LLJ X:

o : L~ to)(<0 ) c

X C>

>LLI C 00 < c

-C LJ Z

In ()V~- UJ 0D L&.

I- -Jr 0
X 2!: -1 CDJ

LLJ -o L

wi z - 4n~
CL

0zt 2cLJ . u L

$. - = ) V

LiJL
LL. 2!:

G87
J.6 ~ - -7 7 -: . - P" i. - -17 -- S 5

I--

40.u
p 2J
CL
0

0~ COWur
z IN MO
* I C~O I
I- .0@

33
 .-. 7

-L (Z ) I.

OrJ C = L-) ~- - ~ -
A, CDOLUJ L-~ *0V2'
tn-
C L ~Lw
4LU u ) LU JLU
CD W Li- LU)LCD co
- ) c
( c#1 = . 0. LLU e -

U.- L Jc-
CD . J C = L c-

2c LUJ M LLU - u .1 -
~~ =- C = (-u 1 C)
-c => (- V) .-u J>

-- = a-- < LU J _jP- LU

>-II-O
41LJ LUL
S LLU d
C.DCD
= ~ LLJ Lj
* =-
D C

=Z~- C CDLJ
w =- .
< . a* )
e (fd C) LUJ

LU OJL. _ja *z D V 9

*1 0 =L L~- -Z

Laij- *- - p =- n 4 .a.I LJ .. WU>- LU

4C LUJ C LAL a-0 Z - D-CC -

Q w 0-
. LA. ax a I.-
.. J..i
_j~ ~~ 0 AJ LL -12.-CC
:No =L = U
(MQLJ
V) ZwLC0L U LA-
I- an z -

= W = - - z 'mgaC -J 319aL~
^C n-m - - )L
4cc
IAJ0 3- =W Li ac 0iD

L D I- LA 41~ 2. c 4 Cz C) "M
ZL)ww 3- 3c-1oz . e
LUj Z~ a - 1i c w - LU * a
Cc~ La:;
LAI. i .1
-- .cI-
0D0 CDK

CK WACL *0A4&w 0cL L doi me

MUIA -j CA IN ccLU

CD9 ) - w L" 1-- 0 c CD I. -

LU
CD0-V) Z9 C j 0- 0.
I-- nC go dc c -1
ac~~. - w. C i -'

cc C 6 a -(N.0 %JCL4

,- I L *c - 4c.~ -c . . . . . . S EU -* *. *.~
 -* - ~ . - .,' -~ - -- -

- ~ .'

9.

9.'

9.

a'

a'

U'. 4
.5

:2 ii
a,
 CD

- Li..i LJ
LJ- LLIC

ON~ L~j~U LL L
CD
LL -4 = LJJ

C)-o x'L cz M -*

. C\J0 OLI.

LL1C%i ko I X V V) L
I le - LJ p

xJJ
LLLJ Cc I V.- =-
C-) ~ L ~
CDM
=C . a- o
0A >LJV I-.-
LLh LL) ~

0~~ -- LL I
L
111 0J - I = uU

= L~ -j LU, COL
o - aC.am-0 ~LA 0
VL usV ()La.J
G~

LL X..J~a Lai JX 0L i
9= L)cn =..d W
<a. =L~- U L- Vl 2:LI
=~ ~ I0Z - w i

LL I--aJ 0 A C-La-J LS1

04 V)
Qa.I-n (m
4cL~. L
CoJUn

o '.O = La. L'J 4cc

M.. Qn ) VOC a. =- 0
CO- CL LN C

0 .) CD La) ~
LU LJJUi- CM Ac cm

in ) CCD. u
com Ln CD U.o)UP'
z
LAJ.
ZLA.i LA.
--
L&a.
>. =O e-1
C.) ~ 0 .
4 LJU 4C =-ZL' S O
-j -j~. 0.- V) ac= 9
dc.L40 CLJ~ LLJ)I
- *J0 >-~2C . C3 )
I(-- L& L')O
-- QO0

I.-~ =

91

LS
 CO) M
CC U)C

1CO0 L
0Z
wowwo. 0
0 0 a m

oh cOoz mz am z
>-
< - M0 CO)c
ao CozF aoL
II0 cc

m Z~LL

0 .4 LU

L0 Co I 0 :. CO)O
M-i (.)
0O LU C 4 C~ LL
(0 I
W~~~oU L I uoNiI

-L 0 ' *.- S
 I-

-Z

o& co.

I i IN-.I=&.=

cx .J in

3c LLAJ -cc

CI *LJ-cc

ILJ

-~ I.- Lu

-ca LaJ LLJ a.J

LL -.
LLJ

* LI)
=- CD,

>- UJ VJ

).- -z z
W- LJ

-M)

-- .. 0.aJC.

' - m-&jZ

C-
o. C)uc

LI- u. CD) ~)Li

LA. -i u m .

:m- I c
)-

== C LiA-.J

a. z . F-.-

0 e-

93
 TIIi

~-s---0-M

M.O

4eom

.. M NOI A

I U mmumm ~ .4..( . %%%~ '* V %

 Li

00(t

ZLi
LiJ 2!

LAJO

rLLJ C

-i-

-L-J

LiZ

CD - L) <

Ct) LJ CD

Liiu
(V) C)
om V

- - LAi

oo
~
LiON t LLJ

CDJ 0 M Li

ill
 4A 6
CL1

00
> CL

16-A

z
II. 0 o
 b- LAJ

3c -
3c C) a-

00

oX
-4w

CID
CD
M Q- -

I CNJ~

wu
U- LI-

LL u

IJ LA Z

CO W

>- LA. -
Q (5~
-~ 0LJ
>- >- co
cc c
Lh o C) CD
0-
Nd Zci
qt 2- J

M. ZLLJ

)LLJ
CD V

97
9%

V
S.
*1

.1

I.

ii

'I.

I
*4 F

S.'

5%

I
5%

I'

5%

1
- A ~tQs ~ :yr;- -
 IL-

C,

Ca LJ LX
p.-

LLJ
LL a
-.- LJ (/

o L AJ~

I- 0O- .

C) LU 2C -

C-)
C-) L&JJ

U-- u

ILUJ V)-MX

oi co LL

InJ li I.-4L

co LAJ
* Z-
0 ID C)
C.~~
ZZZI
CLLD-

~C0
I- ~ 9L
 CIC,

* 00
V.P
Da

-
16

z3 c
 (I,'-C)

LU
J

0 :
CD~ V)

C)~

m CD

I 0

LIJ LLI

V-

CD (0)LL.
-oC

CD- =)

o -)

t 2t
S >- -

~~ -V )

I-LU

>-J

o- QLLJ

- U- !r
Q

LU

LU

101
I

.4

02

Ser . . . S -

a- a- ~aV
 LuLJ

Luk I.u. Lw Li-

0 Luj
9=~ CD~u~

LAJ

= Lu0LJ-
LL - III- Lu.

- uu 1---

LLJ
t
o) CD )-
C)I-
u LC C -
91 -C
o> lb oc

IN) 0- JO
-4 )CCL
2C Lu)x )
LL -cc 0Lu >
CD 0. = W-W

CJI 1
Zo- %0 a

LA - V 2M

i Lu
GO) -c
o43
~sL
Q

0. :a co ~C-)

< C.)
Q 00

CD u -
U- =1I-r2 ~= -

-D - LU 49
ca = V)

0uui

103

"1~~- 1
 MEW

(NP

oa 0

UU
0

44
z
00
_ _ > _ _

- a)
mU .< ~

014

G CJ~ I
 L)I.-

I-- 2 I

LLP)

W c~o 0A

~LLJC -

z 0 C0
"i LI

~L6)LAJI Lh-

0L W Q
CC~ LI.)

WWV -

L&J LA I-

b- )0 LIJ

C.)u C Lij

CL LaJC-

Zc 49 0 (n

4~~ LA.. I()

= LLJ

0. 0ON

105

.. .......
44'
 b-I -DLL

0-4 C) 0
< m-

I~LLJ~

a (5
0.. LLJ M

)Z0
0 LC-
Cm (^ CL
w WE M 1
LUz 0iuiw

Z.-4 V) LU
CDZV
0.-
=~
I ~~

0U) I 0.j

(LAJ < L

0-. LL I-..

c -j _j 4- W q LL

. i <J z V) (D
LA- ;C Z

- - Lo

SLLU . o.-4 C

LA- 0D a.-. = LU

LU CD

LO V-. WV)

LAJ
b p- C-)
.~~ LA-

LULe)
=C L)O

CJ~ ~ ~= ( C. u0

i 06a.
 - - 7 -7 77 76 -7i-i
7 . . . . . . :*
. . . . . . . .

00

z
I- LU
00
>4 l
o 2

0 0

010
 >- . r -L -c -. -

CD M: Lu Z - C) 4

LU W ~~U-i L. n
-< == :LU

C LU LLU2!
LU

-x LLZ
V) O .
*~V L).-~C)0
- = -4 C) -
t-)C. fm<C)L =L
LL < C L.
LL. LLJ u D) cm L

LL - LnLJL
A--i = = - L C -
LL) < LL C-OX: J U-
V)
V" = C) = <
1-LL<
LL. Ln
LUn LLVLU-) >-L

LU)C)O cC-
< C)
L ULU -j C
V) LLU 3c L
(M CI >- C) coC
oV)O.C 0o< -i U
C-) LL. V) I-

- C.LL.. C/) 2C=*

< ck: C) w
-j

-j - C: J 0L L L m L
Lr- CZ~

-i Cc V0 C/) 2: -
<U - _j < LL-

>.) ca =U C) VI < >. LuOI-

LA a).C- <d < <. 0L CL = 1
-i LL -j w C) C/) -LV u0 C
_j Ln -j C> CLX
<U cc M.~ C.D V) i V)0 C: -

<C =)'~U 0. ' == =

Z~ -jU *) cz0rLj < 0 LU -
.. i L)O. I M/- 1- cn . CD >.

- C< - < - = L C' .~ O-

-- CC0- V) l<Z
LU
<D C C~ <-C/0
aC- LU O
o) Ln 2:CC/)* LUj LU LU UJ .)
u4 0: -U LU L C O w

< LU ~ CD LL.J VUOC

<- LnC
V) ) < < <U wU1

V) cn j uj j1M08

*L .'. ,- ~ * w. < ~ *
 0

-,z
C,
1n 0

00

M p r >LUL
a a8~ U L
zzI U CL
20
a.0 UJ
UL

C4W
IC- L .. 0
01 IN U) 00CC I Y. 0
00 0 0
0 U0R

109
 I-I

Q ~ ~ ~ ~
I--Gc L- i

* LUD ~ LU 0
0 r Q. a D C LU

0~ LU I.-

-0 = (7 <

UJ LAJ C L)C
CZ Cc -
LU LIM

X: I(

LI~~ ~LL - -
L LUj LL wM CC

50 OLU <- LU-

C/ : - <i i
La -
LL)O.

0C 01 - bZ '

o: LL oLJ I L
40U LLJ - LLU LC

o LUJ LA X:)~
0)
cm) - 4J I- <
0 = =~ (DC )L Dc

LL LUI L-L Q c.
-- -I*-J, I:- = V)
oL MCD = CD0V)0J

~
C. cC - L C.%

0- LU LUZJ 3c =~ LL
4/) CD <~ (A 3Z
LU C < U I-I .J 0

5-iO
CC U. ui a.
co~ - 5-L' =L
C> C) I--
U - Co COU)

a_ C#) C) V)0.

- J~-. LU~fl O..)0

 IZ 0
4) o.a 0) L

OI CCDZg
4 @0 0 S

16 0 - _ _ _ _ _ _

LLg

U) 0

zS4 d 0

4 tu. CS

O6 O
C-

00 44
U 0
LAA j CL> 0.M CZ
0
X.0 CO OccC.
 LLLU
2M c_
C..) u )2
W W - L LU
ZL= = 44Cd
LLZLLUVu-I _
* j
LUJ LU ~ -- L/. >- LU (V
LL) cm C . I-I- -.
4< -cc -
= ;-C:>-CmLL Cd) = < V)C

LU *- LUI- =O :x. < u

V)UL
V) V) mD ) 00

LL= .-.
<~> ::..
-
0CD, I UO
_j') <Z 0 j

u-i V4 ULn LC)>0 -4-...i

C) CD D Z LL L. <LLw wLLU C-) C)

= - LU
0> 0LUV
I-- Lm Cd-) m
CL L) = -j U CL ) uccm=-InC
<
XU U LU fL) LL . L)J..-Z 3 j =0
C) L- )V JI-I L- = < LLJ LA w.r- CD x0-Iw--
= L) 0-- <C <(1 = L - ~ =U = . -
< LLU < F-UL~ V-). = a-U

LU LAJUi r n V)V K CD a.
2:
a_ I-->< LULU =CD ) LUJu : :

0 -. U) X C) VX L-J = .I-i-- <I = -LUC) .J

L-LU L -C ui 0' CL ~ . CDu
LL-
CD ~ L. n ~ UCLU
V) = z U c
V/) <V) 4c LUi V) 0D U LLU C) U =w . .)Z
I- CL L I LI-- I- -')
V)0C LU
L/) %LU'
(4I V = c
0~~ L ~~~
UCLj L~O w >-V
>.) CDI- LUJ F- X LUJV) XOI-Im

LL- < or ) C-) wULw

C)zoC) L-- c-.LL- - X
LUJ 0 co 0C ) co l I.- )0-
VCD LUL W L
I.- =-= z = )0LLL a.< mL& _jZ.
2! - -
LUJ w L.)c L) <-LLU X: CL .J 0'CD
>.L = a. <=D LA- C- CD C-0L <U-W
2C Y CO a a.. CD w J< LL- ZL. L>- u)0=
C )) V ) x) CX 0 C ...) L
zL.) CDLU
(M XC.. L/)O.. L/)LUK L
>< 0) mi- < i2

CLI LUJ LUI C00LLLjJ

C ) Lu cl
(sl = = I-~ =.cc LUJ V)
CC-~- V) ... V) =X .- LUiV)OO~pLU

0~ - V)LL0 CDL) 0 :3U

cI-/
*L ~) C C)J X.C LL.(-L) 2:I-.JL
C) V)) ) U)uLUU C 0 LUZU
OKIC) .V
=0- =)I0.. Q.C .KLJ
0D C..) C) C/) LL I- LU C LL. >-
* L- P- LU LJ a. I JZo-C. .. J

I-I= >- U- - =-~L- - =

LUCL Ln~d LKoLU-c 7 -- :

112

% - -' - - -
 27 -r - -
*a -7~ r7 C

LU

C.)

C.4 0 1 i0 0
oj >0 ca
o______
z>*Z
I-a I--

0M - m -r

zU 4 z 11 11

0 CC

A. z ) .
U,

C0 . Lw 4 zj

mc z
~0

113

1%e

111111111111111- w .- *IIII
 4n4

= u

39 = u C : L j

Eij Ou x u1

) CD 21Z
-K ociJ

.b44

Wl u _j 4

LiLJ Co =2c Z
_j OKjUJ=_

o CL I Lhu LU LA
ciL =D I-Z)C

M, <OV 0- =

:I- LJ~ - O Cc:b.

_j LUJ (4 Q = =

K LL~ w -.

iCD-C u 00 w _j
1j La..J.JuP-4 cz <

C~
Oz
Q- L-I- = c

K= 0 ~- CoI

I.--< 2c _4 O O
Cu - ( LI =V -4

49 -Lai
LJ0 9~~1 - 49 '-oL C,
Lu= CL~ _C 2

LU_ LJ - LZ- >-

C) -a.JZ.-. = - 2c

V) . U_.ZW - =
49C Z: -
CDO- U0

=~~~ =-mI-OI-4

0 D uZ u u( iu

Cm = CD COOZ

CD. U. zuu

'-'.4 '114
 LLA

CO 4 U cc
o COZ to L
oc 000 0 1
111 ix i 4c
0< 4 .

IL No 0
%Z
z 0
WusU (

L0
LI I
00L 4c 2
55~f2 x
urn (
@00 Z*ee. F
4UIg
3-c@
q 'hEaJU
16 cr.ul fAz
. Z5

z U .- 'u
 -LJ

0N C) 0 L&L w
CJa- cc0cn co0 Ne3cL
L00 = :-0 . Z CL =
Cd) CJO 0D &jV)~= ~V)CV)
=-
LL.j xC. u-i Z- C) co-
LJ f-) CL Lka.JZL -
*-U C) < . CI'L.
I- =- Q. LLU *I Ljj M:4A-
Z-Cd WuL) PjV)d -ccJ LLJJ u- 4cI-C
LJ L& Z. G) in = Z >Z = w
K LU
h LLL -10D Z>- - LL L-C)
ULU
-j = -) - I- . 0: 0L )J C, L

u.j X . Zi. V) =~ u- LA LZi -

Z- jc LU -4 ~ tn )0 . ~C
LAJ U 1LUI C-.. CLLI I LLJ
0-D CL 0 W-I_ V) C)Kcc --
zO'L 0.~ =o = -1 0- -
2M X CY - CD O A . LUC-
LO&J

LU 0 . LL LA- im LU- LL O- -L
(n- CD..J <W < 2C-. * ~ Vd)<
=WL<U u. W0 I.-KW- L- -I CM )~
0 . =U- i I - C. .
2 C. CL Z C- L & V
C-) Z WJ C-) 0 XC-) J 04 0 U *
D :1 - W .D. u( 1=)
L2C ' UJW
La- ~
CD LV4 = d
LLJ u Ii 1- -JacL- d) U x )C
Cdu
I= a..P- 2M 0.'LUJ CL~ = i
K3 Z i Co 1-1. LLaJCC) 0-4 3tOC.)- 0C
= a)-
nI- V) - :10K ::.
CD 4n->-LLL b i= =0 ac~ u MC) = LL X V
GDJ ELE
2!JZ =G CD 1 C. CA- -
Cd) 0c
= -I-
X *- UJW 4L-0=
I. >- Lai CD CD l-C. LCd=70U JOE
cm V)-J2 = cz GZ= =).L = =L& 0. = Cd< )L
CD ZCD 2M <0 GD LICD
U'-
LuU .-0 ...a Cm -i CD x C Le)-
LC
CDuLU- ~ C -=LI 0C .)~ <d Lai LJ cm4nuC.
K W.cc AV) =~1 = uI- 2 r 5LJv
=. L O) or~ CD cm 1LU LU L2
2C LZJ LiAJ. 4Cd- Cd) W z64
K- L) A )Q
LLJ 3OW
= LU(~ U
Zo. W) -M
4cC uC
0 LU1 -~ .. 3 V)) 41-GCQ- 1--- 39%c W' A
CD W 2M w- - co) CD Co :. uLa
LGJ 2Cl O*
X UCD0 )" cde) -L AIW
41 2CW 3
1- CD-J U LL ( C"l
ud) CDjLL 90 >- L-.C
LA. - * - LU Z0 cc.J CL)W -LL .!

KL -Z - I Lu CL- d) 0 =-- le C-
OWc
V) (D VI-O D I atOfl V o0 Wac LLJ V

Q. ui D
C.j 90
M O~ i W) V)
I =) I--j M C>
w CI) LA.0w =-)C-J U LOKJ ZLU LL0 U 1) 1
-D K LL Lm LU CD cn La.I
z C-) CJ
V) M- *0O K L0
I.- 0. =- LUG. V) VO L0. x I- V
4CC
-i 3t-=0 a.-wOO I-o.
V) LL )C) -C I

ILLI
it, ZOO :N i mC =M
0LJ .) 0L LI - . L *L )Z C l V
0.J)
w -- cp- C-) L)0 -U 0 L.

CD zow )Co z
2M - X C V) j

115

.* ~ V %
 a. uLJ wi -j
o cc
.
OI
0 0
00 0I-
-L C- 0L cc>-.x 2
-U 0 4LI .0 %w
Zm a. 4 4 Zj 0JW

U- W W
CL 4 ~~ 0U
0q U CL0 0
z. V UZ4 Z 0
o 5 0 wz zI 4c 00
L0 04
w Zu 0
20
w -'
-4 2
J
soi 0
ftm
_ ow m
>
4.
1-
I.
-
_
- -
5
-3U
Z . dc c 0 zC.

s0 cc-
3 0

0*:
u-.00 0 w
o00 Z
w. :: 0 0 .
ui uj I

,%No

(5 z CL Z6

*C5~ -. CL~ Uj LL- V

 L~J

2! L&J
9- z ccLAJo

o I--~~J

Q I>- L = LJ O

LLJ~ cc Li.j0
(D CL 0

z ) 9-1-

iAJ L0 CLjJ

u I-- = LL
. CL LL.

>- LL C j( m

Mn- Ln J

~LLJ_j C. L J

ui L&JJ IOV

~ > - M - (

o .ILU C(D.
(iD LjJ z

LaJ Q4# - w
Sz~ou = 3W
Z LUI LULLU LA. -

a. U. _

4-

>- CD uCDU- )I-

M

z .- U = ~-

CD Z-fL

117
 a C6
z r z
4 0
a-L
o CI) zCC
ongIe,, LU 0(WCo
xw z zaZ
4u
00 4 Z I- -

mz(o -O)j o
%two~l C .- m
0 Z 0 0U
w0~0

1 0C 0
0
-40 >-

~~cr t w o$
u4
1. 0 44 C)I-- 4
zJ
ww

GW Co< Co. -Jj4 I

0- 0 0 *

W<0'

%%% 4
i JV** * -
a***p. UL
 V)

-LJ

C,

u-i

I-

LAj

-LiJ

-)
L.

CDc
cn u~

co 0
_j

.A- 0)-A
LwI

C 0)

~LL.
o -

LA-ig

c~%
4.:
S...,

4'4
I

A
'ii

SW

4,,

".4 <'.,~

U - - p * ~. W '9~ V * - - - - -M
 LAJ

(V)

-J

LLU

C.D

a-4L
cn C

LU

ix LLJ

LUO

-) LU-

=L
C.,LL

CD CD-

*4*1 ~.- L

12
>R h.

.....
 C)

CL -o C Lu

V-U -c Lu ~LJL9
WuV) c- WLu>-
FI-
Lu CC -j C-
m
U--j
C
j
)

L 9-2-- J L

C u MLu A

-- U-
C) C C >< =
LLu.-j

u0 =- ) Lu
x~ - C) Lu __

LuL u Lu I

V) L/) Z u

=D c)OZ:mcdre
Z~
Lu C) 44t V)

LL - )- U -. JL

U- E9 V) )
<LuZ
* J at i -
Lu
LL - -
=NJ ZL U
= Z-

Ju- Z - CL
LL L
I~ >- V) -JLuJ
-j z>- L z 0u

44P CD<0 nQd

I _Ww wtnuI

Lb J - Ad--*
)
2!: Lu'-W-(D

Cfl~OZ~V)

- ul = .e p
 z 0 C

cr z
w4 0 LU
Z C 0 Co
J ( LUWM CL LU-
CO)-UO LLzZ
C) 0 DZ-
LLUc
01 Lu~ ca O
40 cc -
COW L m Im ca c
to i LL~ 0 C L
Cao U
w0 - CP
M .Im aCO V C-41- CNCam

0 cr. m :

T) t- 4
UJ LU L j 1-L
CC CO0 0 0g z O)Z am
wc
4L 0.> N- 4 . 0 :3 OZ
40> m c o-Jo< 1 -r 4 CC
LU u
1 Lu 0u UZ - 0 coLuZL
'TL1 az: <= uj amCC

Ii i I

124~
 j,13-T3

U-

0-

LiL.

LAJ

0)
Lz
Ck:

I--

0. q

1125
N

I
N
N

* *11

I,

A
A
p

'a
A-

'a
A-
A-

C.

'a

26

. . .~ 'C. A ~ ~ * AW' %~VA.% % * -v*:-,- -~*~-.*~- ~* a ~

nen
,4
'127

'- K

127
 744

U .q .. ""W!-
~
 C-

S. C-) W .
C4 ) gW

4 0 -4 C~L)
LA-1 -Z- CO LUJ
CDz~
=
A - ~ I--

UV MLUL- 0- =LJ.<

cc -. L = - V f-

(7) C\ LLJ .V)

A~ A

Ln - 0 n V)I-

~ C...)
Z - LLJ V)

LA I I - C) 2

LUJ L.- I.-LL C c

= C) '0 x 01-
LL.D LC) CD i

=~ - 0.Wm= o o
-IV LU Z
Li. 0.. 2!: - -a *a

3c L C) . .. D,

- - ~a
=~

-iC) w. c)
'<a V)-.CD LAJ0I-4
co A- -DZ I
4c LLU 0) C~ 0
CD)-.0
=LU-~ = D ZU

mLO C)UI

LUW LW0
I CL. -J L L L LI
LU =UI
ca -

= I-4L LU MLLU 3

129
 If4f 0
z4 zI-sa
z U.0 cc
-z zoo0
W 0 W

U) 0W:
Z 0
0 0 c
0 Ix Cc
0~Mi--~0 OZ
Ym - CC L
a. 0 4(0
a: o I~. - .. u

CO,
5

00->
LUu 0@

130
0 0

ALL
CC,

IL
CD

C>

C-,
"kU

~131
 -L 0
C0
0-
0 0 C

* LAJ

0 z uj

CLI
 ...j C\J

CD C)<L I C
~V-, .

L LU V, U
~J - - LUJ LU

(z 0.LLJ

CL C)- *nLJX

L/I
-- IU Cy-
LU

0V~ CL -

LLJ~ >-Co LU 2
>.- LUJ C,

C) =I-. LU0.

0.1 C -1 co 0

U a- -i s.=U =
Cl jj w=U
>-= MC - C)uj

-) LL 0 CD
CD LAJ .j V) Z
o 0 -/) LU L.
C

CD LU LU
V) - . (
im Ln JeLJ
C) LL V

< LLJ - -.j Lu LUJ

_O -j CO il. C
LU L

=' = L

C14 1* CL. -LUJ L

/) Ln C) C
=/ -)- c0 M
2 0 I- Z J D

Ci L 0)J U cm)

CA.

133
 .7 77 T. 7,7
. 7
. . .
- . .
-7

0
4
z 0
VI zO

0 Z
a 00-

IL
'(j IL~

4E .4 ( 0

omi > .ii. XM I c c

.0a 0 mW
'(0E
0 0. Cc
Lp4.O 0 Z- a.
4~ 2 cc0(

: D.CL ,

NOM0.l 0=

OOZ
0

X
00

M134
V) L
 4 EMSP
ENCLOSURES-

;zI 001

Fixed Cage Cabkwt

'.4"
Water cooled

ADrawer Cage Cabinet4

A Air Cooled

Encloe

136
 LUJ

I
C'4LL
V-

0=

L&U
I- c

C.D V) i L

L:
L
LL OLi
D

3c C -4

MC LA- = 9
Li..
Co uj
V)

Li Lu in

1-4 =u

oL w

I-w- c I-

ujV)

39 u-WV)
La. 0o - 09-
V* )U=
V) V) 0) 3E
I- Li Li

I- 0V) V) =i

V). >i.-V- C..

LI0- VO-4)
'o
c cm. 0

LI (.) LU *

I-. U- ce
=4 Q %
S.J V) V)La. %

C~JCo

136 a.I
 irx -*.- -ur
~
VI

A I-
'1
(

0 z

>u 0
I. z0 0
I
a
0 cc I-
o3 cm (O
o0FZ 0

Z0 Z

40C (0Z

o*0
>00

137
 LLJ

2!:

C:)
LLJ
C-- CD
u uj CD
tj -4 cz
tm dl:r. CL 404
= -j M LLJ X:
V) <,- a. C> LLJ =
L.) -j L:
2m -i
cm
CM 4CC bz Uj V)
;m V) LLJ U =I. LLI
" - co < cx =
Ni co LLJ CD
cn a- a
= V)
0
u
m C) LA cr_
2= LL. CD Ln

LLJ V) LLJ LLJ a-

C) M: LLJ -i
V) LLJ = CIO CD
V :c CZ LLJ 2Z Uj
Cn Lu = LL- -j
LLJ Lw -cc LL. = cm
X Cp cc =
CL LLj
(n cn cn
LLJ
C CD I
CMcr I-- LL. =
= a. C) LAJ
Uj C-) LL) LLJ co
V) C) LLJ Lr) =
< 2: CD
:x C>
CD U- V) CD Lu - P-
Co ui -i LL- -j
to,) m CD -j
u LO) cc Q. CC (n
=> V) LLJ
Ln LLJ : ,& V) V)
V) t-) acc = w Cl
LLJ m LLP C> Lc)
CL 40! LU
CK V)
LLJ LL. < X:
co ul C) :3c ui
>. C> -j LL.
f-- I= - LL. V)
LLJ V) w V) CD >-
LU = = < CD V) V)
LM cc co I= u
U L.) V) LL.
LLJ LLJ = CD
-j Ln LLJ =
Co (4 LLJ cr V)
M Lw nc cn
- = < LLJ
LL- L.) x
0 0 CL
Ln I-- -i -j C>
Ln L> = ui = -3
LLJ LLJ LLJ ::B- CD a. LU
= - X: - = = LLJ - < :w
w < Ln CD - tm LLJ
C Loo) a CL. V) I AM

im LAJ L.) m = C6 LU LLJ tm >- LLJ

wi Q LLJ CL LAJ C) = >. = = -j =
LLJ = = = u VI = < -j
2C C) LLJ CD -CCLLJ

C) LL-M
cl-i = uj ui i
C> ix
U- CX
LLJ C) U- (=> CD
V)

138
 ~i0 LUCl)

a.-.
40 0 CLj Co

0O0 001-0
r. 0a . cc
< IL w 0

0 m0<0040
139
 Lui*

-j < 01

LL I-- L

VLu L-.0- *
ZL = -LL ) f
0- LL I-
CC 1 .

-i L- le
ILu -" 2C >-

0-. 0- C I-

CD 01.~(1L

a- I 0L mC
-

Uf) u) LU -i C\i CL
u 0) Lu I- -

CC 1- = -j = I-- -J
SL) -J = -j

01-- -

I- L Lu -

I- C) Z:u(f i)L

CD u
u u) m u

CDV)- :- .4) -L&

hl- C>

0 1- 0. < C

0 - -
V) -
U~~ --

U- w V) - I

Ci)

w Lu- 14 -O1u

I 0J

" u Li) wA I\ I-
C)
N LU -
= >- U1- >< LA-

Ca. < CD w :m L

140
Z A-JIU -,l w % %- 11 - I- -. QAL

now Zc
rn-A.
I-- <- z
0 o >- c

C) ~ ~ ~ E CCC .rf

ccc
Z4 . Oei
cU Z

1-Z- I-w () 4c

t iUrlILN ILL
 LUJ
LU LI
ct CD LU0C

V)~c . Cc L) L
CcolCD cci

imC 0 - C) C
cc CD ~- 01

C) = LJCuD~J LLJ V)

-LUZ ~ ui L)
CDC Cc- = U

X LJUL. LU)

~ LU ~ ~I-4L > V)L

~LD
C: LL L 0

LL -i

= ---- - M ~ L i LU-
>.0~ w ~ Z
L=z CZ- j zujLjC

I.- ~ Vl.x
LI= c

coWLU 00 C)~ O cc0

M
V) (L ::3.
J -39
-4 at LUJ U
O *-)

-j - <U lU
CUUJ

CD 0

I,. ~~U3- I U~C).J 0

V) <~ =0L = w V7VLC.

3c < = - V a LU~
CD CDc
3- C LLU ::-J 0A cl) "

LULL
- LU L
*L I-OL I--
CD LW or UC.<

=U~0- <L~ wu ( i= L
3- =D LL.J= C. In( 0 -uW
.4

L" = < = - *. 2 3-CL

CD Lu LU en~ (
U0-.U ~ z~

2:a. w D 142

*k ui U- CD - **i~(*
 X OC
0c 0 0
1- LI)W
0~ U. z 0
42 IL 0 Z L C L
LL zzU u I 4CU
ca
~ ~ ~ (a0 0 o.
0C
.0O4 4 M C

z L.4 0 a!O) CI)C 41<M

W OF.. W~ 0=! ML
W0j
zO z 0iCO
I- = Z40z ~ i
o
n'MZ

IL cc P- Za. 04<
(Aw~
0 cc2m 1(3i
0) )I= 0
LU m
z-. ZZ CLCC
C 4LL.0 IL3 0ca
02 IO .C5z
45GO 1.. 4- 0 0 < >0 ~ i m

40.O4040ZLL0I 0 m-WU >

z-~II.~~ I. w wZI
ccO.. o WWZ
L OA W
0O X 3 ) U I.. c 4 CA'

Ge l4P 0 02
Z 2 L143
 ~Li
V) I (D
('LLIJ j
Ln -j.. C w -

.-
w LJ
X: CC C4.J&.C- LULJ~ W-~ tLi (n Z
(L*C...)...=J=
LLJj. LL Pl, 00 0C )
>. w V) w = iJ (,- J~ - =g L.
0.. >- ~cc CEI- ) V) w w w V) w
Li.L.J W~ CC-4 .. J: =0 ~ jJ 0
C) uI0j--.
C-LJ- L!=< = >< >-
=-- -C
=- ~ 'L~ X:DLI-- (D ~ - C ) xn C/)-.)f aL

m w w= = ) =- L)--V) CLi
CD ~C..-) = (:L

:K ca Cc L LiJ c -e LC I.-0V :.)- ccJLV)L

>--~ =Q.I-JL0.J
cm =: D=m 0uL 0. MU n

= X- j 2! 4 C).. LJd) Li0n 1- J LiJ O o -

LLJ 0-- r- ()..J.JLij-.zLi
c co... --j LLJr ) *- = -: LL

-0 W< L.
VL)00. CO C3 U- >-Cc0L-i~ 0 - IL 0 .J V) V
u >.) < = -
=0ex Li :.. L NiC~ Li 0

C- I C) c - V) X L
CDLi.rLL u.. . c wt L

w x~' Li-i
= V) 0 = CpI- a-C Li -
L fL- =-0 Lu ~ )- Cd'
= ).-) .. J .. I- ~LL
C,.O LA 0LiCj<-- - < ' 1--,..--
u9-01-mX-C w 1 L.X:=-j <

= .A >-4 =Q = = - Li

u~ OCDJL X.U'Z
:i C) C) =V LJ: -
>- CD Lin
CL L QI)<=0O J iG
~~c . 0
CL-Li
w- < w < D O L -I-<L

4 L. I- * LiJ '>-t LL. ...

J ) AJ (.== - =C L LI -j =
CDiJV')
9= < - = %< LiL ===0.t
Zct- L I U-LL
L.f)

OD Li V) -D~j~ w - n j - a--- I- Li :I=Ci I.

oxC c > < wJ = I-i Li *--Cd)
.>- C) 0. 0Z LA-U-
>iV -- c) L.0
LI- =i.. C> . 0
ctC)-
L eMiLU ZZ LJ O) I--
= UL L~L- C - -0L L L -
.mL I-.4) 1-0I) C L - L - LL 0>- le-C L J Cc C>
LLI = - X0. U V MZI. D = M. C.-)-Li 49C- 0 -j i-
-(-I LL LL 0L _jf) I.
M 0- M C L - Li c ~L J
aCCD J CD >< Ci

LIJO
(D= If <Lu- in ccLL)0 .J X

-j C -c V "4r _ - LJ c 1144-
 .j.

LL. 0
-J

wu 4 <
0 Z
0
0 41--
z ccc
<4W LU
LL 00
Ecu
4 ~ z I y

0 LUi

LL 0 4 U UL

z ~~Elu4~~ 4
oi U. 4c
u ow a.U -
0 UJ(I

Ow w~ __
U 0 -
CO)a
ma v4U 0WzI FUz

14
Biography

RADM Wayne D. Bodensteiner, Deputy Chief of Naval Material for Acquisition,

NavAl Material Command, Washington, 0. C. 20360

BS Southern Methodist University 1954

MS Naval Postgraduate School 1963
PhD University of Texas 1970
Naval Aviator Designation 1956
Graduate - Test Pilot School, Naval Air Test Center 1959

Experience

28 years with the U. S. Navy, including the following assignments:

VP-40 Squadron,
Flight Instructor, NAS Corpus Christi
Flag Lieutenant, Naval Forces Philippines
VS-41 Squadron
VS-29 Squadron
Commanding Officer, VS-33
S-3A Test Director, Naval Air Test Center
Executive Assistant, ASW & Ocean Surveillance Programs (OP-095)
Commanding Officer, NAS Jacksonville
Director, Undersea & Strategic Warfare & Nuclear Dev Div (OP-981)
Commander, Fleet Air Mediterranean

Current Assignment: Deputy Chief of Naval Material for Acquisition

Responsible for Navy material acquisition process; program evaluation; system

engineering; production; test and evaluation; ranges and targets; acquisition
and project management policy (including embedded computer standardization
policy)

146
 THE ARMY'S PERSPECTVES CN
STANDARDIZATICN OF
OOMPLMER HARUWARE AND SOFTWTARE
4 Brigadier General Robert D. Morgan

US Army Catmmication-Electronics Corand, (CE00M)

Fort Monmouth, New Jersey

The Army has recognized the need for standardization of computer hardware and
software on battlefield automated systems by promulgated policies on computer
resources management and standardization of embedded computer resources.
CECOM as DARCOM's delegated systems engineer for C2 has developed an
approach to meet the major requirements for battlefield automation including;
software and hardware standardization, maintenance of competition, reducing
technological obsolescence, increasing survivability, providing for technology
upgrade, maximizing affordability while minimizing proliferation of computer
resources.
The program is based upon development of a standard Military Computer
Family (M(C) and peripherals, the standard Ada* Language System and support
software, interoperability standards between systems, a multi-level secure
operating system, distributed processing research and an effective Post
Deployment Software Support (PDSS) approach, all developed using Computer
Resource Management (CR4) principles and techniques.

The Army is concerned with Battlefield Automation Systems for each of the
five functional areas of the Army's Tactical Forces, i.e. Maneuver Control,
Fire Support, Air Defense, Intelligence/EW and Combat Service Support.
The development and implementation of systems for these applications has
resulted in an inordinate amount of proliferation in the computer resources
area.

Problems caused by proliferation are as follows:

* Impedes survivability during battle.
. Increases cost and complexity of production, logistics,
maintenance and training.
* Impedes growth and evolution of systems.
• Increases cost and complexity of software development and post
deployment support.

* Ada is a registered trademark of the Department of Defense (AJPO).

147
 It is clear that the Army will not be able to fund or support all of
these systems unless some degree of standardization is achieved in common
hardware, common software, common support facilities and tools, and common
hardware and software documentation formats are adopted. There is also the
need to define interoperability standards between these systems.

The DOD has recognized that the control of the proliferation of computer
resources can only be accomplished by standardization. Two Computer Resource
policies have been issued, namely DODD 5000.29, Management of Computer
Resources, and DODI 5000.31 which limits the number of high order languages
(HOL's) in DOD systems.

On 9 August 1982, the Under Secretary of the Army updated a policy for
"Standardization of Embedded Computer Resources", which states that the
standard high order language Ada* must be used in all Army Battlefield
Automated Systems (BAS) after January 1983 and the standard Military Computer
Family (MCF) will be used in all BAS after the completion of FSD critical
testing of MCF in about 1986. This policy memorandum also assigns DARODM the
responsibility for coordinating of all computer resources planning to minimize
software development environment and to minimize the use of assembly language
programming. The Army requirement for Ada and MCF is documented in AR 1000-1
and DARCOM R 70-16.

The Army monitors and raiiews actions in the development of Battlefield

Automated Systems (BAS) Aor C and communications at the Command and Control
Syste W Program Review (C'SPR). The first of which was held in November 1981.
The C'SPR at this review identified action items in the following technology
product areas:
Information Processing
Input/output Devices
Information Networks
Survivable Ccmunications

Army standardization efforts as applied to computers and software for

Battlefield Automated Systems (BAS) are addressed in the Information
Processing technology product area. Included are: a standard Military
Computer Family (MCF), a standard high order language Ada and support tools,
a multi-level secure operating system and the use of distributed processing
architectures.
* Standardization as applied to the Input/Output Devices technology product
area, includes the development of advanced computer peripherals technology,
the development of standard MCF peripherals including smart friendly
terminals, soft copy imagery, tactical displays and an all electronic mass
memory.

148
..

In the Information Networks technology products area programs have beer,

established in the following areas:

Distributed Data Camunications

Broadband Switching (Tandem)
Battlefield Spectrum Management
Fiber Optics Technology
' VHSIC Exploitation
Dispersed Cammid Post Networks using millimeter wave and VHF
technology.
JINTACCS (Army interoperability)
In the Survivable Communications technology product area programs
established include:
Anti-Jam modulation techniques
Multi-level secure networking using the Mobile Subscriber Equipment
Caouunications Security technology
Fiber optics cable
Tactical Satellite Ccmmunications
Tactical Multi-channel Coumunications
The DARCOM responsibility for systems engineering for tactical command
control and communications (C?) in the battlefield has been assigned to the
US Army Communications-Electronics Command (CEOOM) at Fort Monmouth, New
Jersey.
CEO)M in undertaking this systems engineering responsibility for C3 has
addressed the following major requirements for Battlefield Automated Systems:
* Must have both computer hardware and software standardization
• Battlefield camputers must be survivable
* The approach must consider cost factors and be affordable
* The approach must insure continuing cmpetition
* Must keep pace with rapidly advancing technology
* Must accomodate evolutionary upgrade of Battlefield Systems
CECOM's approach in consideration of these requirements has been to
develop a survivable cost effective standard family of computer equipment
(MCF) and peripherals, supported by appropriate software, including a standard
high order Ada language system and support tools, a secure multi-level
operating system, interoperability standards between systems and making use of
the latest developments in distributed processing architecture.
MILITARY Cr IE FAMILY (KF)

The development of a standard Military Computer Family (MCF) as a

solution to the proliferation problem and to meet all Army requirements is
based on the development of the following family members:
A Super mini-carputer AWM-41
A Micro Computer AN/UYK-49
A Single board micro computer and chip sets.

149
 - 7 777777-7. . . . -. -.J... J.

The MCF family will be based on a single instruction set architecture,

MIL-STD-1862 (NEBULA) and will be based on use of the standard high order
language Ada and Ada support tools including a secure operating system and
will include three standard interfaces
CECOM in its approach to developing the Military Computer Family has
addressed all six major requirements for battlefield automnation.
The approach to standardization while maintaining real competition is
based on the following approach:
" open solicitation for Advanced Development
" Awarded four contracts for competitive advanced development
" Select two AD contractors to compete
Full Scale Development (FDS) and ILS.
" Competitive FLY off for production
" Production Award for five years
" Repeat above cycle for next phase, every five years
The problem of reducing technological obsolescence is taken into account
in the first MCF phase by requiring technology insertion of 1984 technology
f or the 1986 first five year production.
Thef concept of initiating a new phase of development for MCF every five
years will provide the opportunity to insert new technology for each phase via
competition, while providing a balance between technology and logistic support.
The program will provide f or upward compatible evolution of the NEBULA
instruction set, the Ada language and interfaces.
The approach to assure maximum survivability is based upon the concept of
a fault tolerant design using VISI technology which is inherently reliable,
built for the military specification environment and which will include built-
in test features to assure maintainability.
The approach to providing for evolutionary upgrade is based on an
approach which will: Provide initial capabilities in excess of known
requirements; permit interfaces to support expansion via distributed
processing; permit successive generations of products to be software plug
compatible; provide improvements to NOMUA and will support improvements to
Ada and will provide for higher computation speeds, memory, power and
reliability.
The approach to affordability or reduction of life cycle costs includes
the following:
" Extensive comptition, competitive life cycle cost analysis
* All cost. competed including f ixed prices based on quantities
ordered during 5 year production.
" Large production under single production contract will result in
lowest unit cost.
" Simplified logistics-fewer spare parts in the pipeline.
" Emphasis on high reliability and maintainability will reduce ILS
costs.
" Potential for software and plug-compatible upgrade to more cost-

150
 geerto ndsotwr

effective units that emerge from each phAse.

. Common Ada-NEBULA compiler, code generator and software
environment-use
Reduced costs for ofPost
commercial hosts.
Deployment
. Software Support.
MCF PERPHERAS
As part of the Military Computer Family (MCF) program, CECOM has
initiated an MCF peripherals program to develop a family of standard MCF
compatible militarized peripherals for Army wide use in battlefield systems.
This is intended to reduce proliferation of types of terminals/peripherals,
enhance battlefield survivability, reduce logistics, maintenance and training
and simplify software development and support.
No technical barriers exist to the initiation of development of a family
of standard peripheral devices under the MCF program. The role of the MCF
program is to ensure that such peripheral devices are properly interfaced to
MCF computers and can serve in multiple applications. The MCF program will
only address the development of peripheral devices that contain significant
risk so that no Project Manager need risk the success of his system. Examples
of such devices are Large Screen Display using thin film electroluminescent
(WEL) technology (to be initiated under the MCF program in Advanced Develop-
ment in FY-85) and an all electronic mass memory (to be initiated in FY-88).
In addition, work will be initiated in FY-83 to interface high technology,
commercial peripherals to MCF as models for the purpose of test, evaluation
and demonstration.
TNE A r w SYRT

CE0X 4 is committed to the development and validation of the Ada Language

System for use in MCF and other battlefield automation system.
The approach in developing the Ada Language has been to provide the
following:
" Language optimized for Eubedded Cmpite Reource needs
" Redue needs for assemly languages
SReal-time capabilities
" Parallel processing
" Separate -qilationfacilities
. Error resistant features
Potential benefits of the Ada language lies in commonality in training;
transportability; coummuication; and support software tool focus.
CBIWN initiated the development of an implementation of the Ada Language
System and supporting tools in 1980 for introduction into operations in 1983.
This program is called the Ada Language System (ALS) develoment.
The Ada Language System development includes a complete programming
environment. The ALS is a system of tools required to develop and implement

151
Ada Applications programs. The tool set includes the following:
Cmnand Language Interpreter Pretty Printer
Data Base Management System Text Editor
Configuration Management System Text Formatter
Ada Compiler File Comparator
Linkers Symbolic Dynamic Debugger
Assemblers Test Coverage Checker
Stub Generators Timing Analyzers
Set-Use-Static Analyzer Loaders
The ALS, as currently being developed, can generate machine code for five
target environments. These are the Digital Equipment Corporation VAX I/780
(VMS), the VAX 11/780 (Bare), the ROLM 1602B, the Military Computer Family
(MCF) and the Tactical Computer System (TCS). These capabilities will be
introduced during the January - August 1984 timeframe.
The ALS is the developer's and maintainer's interface to the computer.
Its aim is to provide an efficient implementation of the Ada Language as well
as to provide a beneficial environment for programming in Ada. The ALS is
written in Ada and will be placed under configuration management control via
its own configuration management tooling. It is planned to use the ALS in all
DARCOM Software Support Centers to maintain Army weapons systems utilizing
Ada. It is expected that many Army development efforts will utilize the ALS
during original development. This will be effected via making the ALS
available to the industry. To this end current planning includes making ALS
early versions available on a friendly site basis to selected ompanies during
1983. During this period the ALS will continue development toward forward
introduction and use in 1984.

Another major area for consideration of software standardization is in

the intra-Army interoperability between battlefield automated systems in the
five Army Tactical Forces fumctional areas. Interoperability development is
based upon the following documents: the Battlefield Automation Management Plan
(BAMP), the Automated Battlefield Interface Concept (BIC), the Battlefield
Interoperability Management Plan (BIMP) and the Technical Interface Design
Plan (TIDP).
The impact of interoperability involves every segment of a system such as
system design, interface characteristics, computer programs, data base, and
communications. Externally it impacts upon the operator, the communication
media, management and, because of its evolutionary nature, doctrine. The
impact upon the management structure is great because it forces a higher
degree of centralization and control due to involvement of two or more
systm.
Key software interoperability consideration is involved in the following:
ma/machine interfaces, software versus firmware, flexible message generation
capailities, software interoperability training, provision of adequate multi-
level security for joint Army/NATO interoperability and considerations for
continuity of operations, and survivability of automated systems in the
battlefield.

152

!N
?7•~zv 5. ' . ~~-rr*- * ... i .~ 'r r~ . ~ . . o . Y *
oo_- " , . °*9 . -°. . -.
•
- •"

Security considerations, in the view of interoperability, cause increased

complexity due to the number of systems and levels of security required within
each system. There is need to provide a common security module that will
provide adequate multi-level security for Joint Services and NATO
interoperability in a hostile environment.

The approach to interoperability for the Army is to provide a common base

f or interoperability across all systems including design of standard
software/firmware module, scenarios for interoperability testing, on-line and
off-line software training routines, standard documentation and procedures.
DJ.!I L3M. REIIRI

A major aspect of CEODN's program for standardization of Battlefield

Automated Systems is the design and development of a set of multi-application
real-time operating systems for both multi-level and dedicated secure
omputer-bamed applications which utilize the Military Computer Family (MWP),
the W7 peripherals, and the M Language System.
The goals of this program are to develop operating systms which:
a. satisfy the broad rmouroe control requirements of the entire
range of Army puter system, both dedicated mcr (systems
high) and multi-level secure aplicatios.
b. are developed in Ada utilizing the Ada Language System (ALS)
and compatible with qpplications dweqied in Ada using the
ALS.
c. are modificable, espandable, maintainable, and easy for
applications desigmrs to utilize.
d. are efficient, i.e., do not incur a high overhead and allow for
the development of real-time, high performance, embedded
computer systems, as well as stand alone computer systems for
the Army.
e. employs the current state-of-the-art in formal verification
methodologies and tools, security mathematical models, and
secure operating systems designs. A dedicated secure operating
system for applications which do not require hardware/software
security features.
The technology exists for the development of trusted computing systems
wherein hardware and software security features are incorporated which can be
certified and trusted to run in the multi-level secure mode. This technology
consists of formal mathematical models of computer security, computer
architecture features to support security, formal verification methodologies
and tools, and Kernelized operating systems. The MCF Operating System (KC(OS)
program will include an operating system for those applications that require
the system for dedicated secure and systems high applications because there
are many applications which can be naturally and appropriately operated in the
dedicated mode without loss of performance, and because the security

153
protection required for the multi-level mode requires a higher overhead with
respect to performance.
D ~

New Army tactical C2 systems for the late 1989 early 1999 time-frame must
put a premium on survivability, availability, and mobility of their system
designs The achievement of these objectives requires the implementation of
new tactical systems which provide enhanced continuity of operations (CCNOPS),
survivability, and mobility through the utilization of distributed processing
architectures and techniques, as well as the standardization of hardware and
software (Ada and MCF).
ECOWM is conducting research in the mathematical modeling of distributed
systems, the use of Ada in a distributed processing environment, and the
exploration of survivable systems. The mathematical modeling research is to
develop mathematically precise models of distributed processing algorithms and
techniques, and study and extend their properties in a precise mathematical
setting. The Ada research projects are concerned with providing a support
environment (development and maintenance) for distributed systems implemented
with a Higher Order Language (liQ, and to examine those mechanisms that will
allow Ada programs to be engineered to run on a distributed computer system.
The research in the area of survivable systems is to define and explore issues
in distributed processing that relate to tactical command and control
functions. CEflM will provide a means to develop, evaluate, improve, validate
and demonstrate state-of-the-art distributed processing techniques, including
data replication and location, update synchronization, and error recovery to
assure a consistent data base and fast accurate access to battlefield
information.
An experimental distributed processing facility which will include six
processing elements/nodes is under development to provide a flexible test bed
for the integration of local and remote network distributed processing
techniques. these integrations will be programmed in Ada and will be directly
transferable to KCF. This facility will also provide a vehicle for
investigation of distributed processing techniques as applied to the tactical
battlefield, to support the requirements for more survivable Army tactical
systems in the future.

The Army Program for standardization of BAS and C3 systems can only be
successful if concurrent development of plans are initiated for effective
support of these systems when fielded.
A study of the Army's Post Deployment Software Support (PESS) problem was
initiated in 1978 by an Army task force and working groups. A concept plan
for PDSS was completed in May 1981.
7he key feature of the plan are the establishment of eleven PDSS centers,
each providing central management for a functional/mission area. The
establihment of only eleven P1SS centers was a consolidation of resources for
all Army requirments.

154

S - . . . . . . . . . . . . . .
 mF7

The PD6S centers will use both commercial and military computers with
commercial computers as the host for development and support, and the
military computers as the target system for test and debugging of fielded
saftware. To be effective, a PDSS must have a role in all life cycle phases
of a battlefield automated system.
In the conceptual and developmental phase, its role is to insure that
management and technical decisions are compatible with support needs and to
acquire design knowledge. In the deployment and support phase the PDSS role
is to maintain, modify, and control all system software.
PDSS must be involved in the complete BAS software life cycle to deal
with new and changing requirements, interface changes, and insertion of new
technology. In its maintenance role, it is concerned with technical changes
and correction of latent errors.

These major programs will be implemented using Computer Resource Manage-

ment ((RN) principles as per DOD and Army Directives. CEMM, as well as other
DA=M M&A(X)S, has taken action in the formation of Computer Resource Working
Groups (CJf and the preparation of Computer Resource Management Plans ((CRP)
for each program. To educate and train system developers in (RM, a series of
CRN Guidebooks have been prepared and a standard set of data item descriptions
(DIDs) developed to coordinate decumentation. IUKON and CE0WM has also been
participating on a DOD basis with the efforts of the Joint Logistics
Commander's Joint Policy Coordinating Group on Computer Resource Management
(JL-JPCC-M) since its formation in 1977.

The Army and (CWDM's approach to standardization of computer hardware and

software is based upon meeting the major requirements for battlefield
automation, including: maintenance of competition, reducing technological
obsolescence, increasing survivability, providing for technology upgrade and
maximizing affordability while minimizing proliferation of computer resources.
The program is based on development of a standard Military Computer
Family (MCF) and MCf peripherals, a standard Ada high order language system
and support tools, a multi-level secure operating system, interoperability
standards between systems, distributed processing research and effective Post
Deployment Software Support (P1SS).
All of this development effort based upon use of Computer Resource
Management principles and techniques.
This standardization approach is planned to result in a survivable cost
effective approach to providing automation in the battlefield in the late
1980's and 1990's.

155
 - . "4 -.. . . . . °

BRIGADIER GENERAL EGBERT D. MORGAN

Brigadier General Robert Daniel Morgan, Deputy Commanding General for

Research and Development, US Army Communications-Electronics Command
(CECO1I), Fort Monmouth, NJ and Comnander of the CECOM Research and
Development Center, was born in Buffalo, NY, on March Z, 1934. He
attended Lackawanna High School, NY, graduated from Canisius College,
Buffalo with a bachelor's of science deqree and earned his master's
degree at Troy State University, Troy, Ala.

General Morgan is the recipient of the Legion of Merit, Bronze Star

Medal, Meritorious Service Medal with 2 OLC, Air Medal with 6 OLC,
Army Comnendation Medal, National Defense Service M~edal, Armed Forces
Expeditionary Medal and the Vietnam Commendation Medal.

During his 26 years of military service, General Morgan's assignments

have included Battalion Commander, 40th Signal Battalion, 1st Signal
Brigade, Vietnam; Chief, Technology and Applications Directorate, Audio
Visual Agency, Washington, DC; Deputy Project Manager for International
Conmunications Systems, Communications Systems Agency, Fort Huachuca,
Ariz. and Project Manager for Position Location Reporting System,' Fort
Monmouth, NJ.

)56

................ i
 UK MOD ACTIVITY IN AIRBORNE DIGITAL SYSTEM STANDARDS

by
Dr A A Callaway
Procurement Executive - Ministry of Defence
Flight Systems Department
Royal Aircraft Establishment
Farnborough, Hampshire
United Kingdom

1 INTRODUCTION
This paper covers a range of Ministry of Defence (MOD) activity concerned with
the development and establishment of standards for both the hardware and software
aspects of airborne digital systems. It considers the multiplex data bus and
related digital interface standards, standards for programming languages and
software development methods, and computer instruction set architecture (ISA)
standards.
The formal recognition of a standard in the UK MOD is through its publication as
a Defence Standard (Def Stan). The successful drive in UK towards airborne
digital system standards is evidenced by a number of published Def Stans, which
will be discussed within the paper.

One of the driving forces in airborne system standardization is the need to retain
an international perspective. This has been recognized for many years, through
MOD involvement with the Working Parties of the Air Standardization Coordinating
Comittee (ASCC) and the various NATO standardization committees, and has led
in turn to fruitful cooperation between RAE and, in particular, USAF/ASD, who are
the joint project authorities in a digital avionics Information Exchange Project.
This cooperation has been notably valuable in the development of Nil Std 1553B
and Nil Std 1750A.

Since the majority of the audience for this paper will not be familiar with the
role and purpose of the RAE (Royal Aircraft Establishment), it is convenient here
to say a few words concerning it. RAE is the largest of the UK OD's research
and development establishments. It is principally based at Farnborough, about
5 miles south-west of London.

'RAE is at the centre of research and development into military (and some civil)
aviation and space activities in the UK. Its primary function is to advance
aerospace technology and to use it to assist Government agencies, the Armed Forces
and industry in a variety of projects, evolving new operational techniques and
solving problems which arise in the equipment when in service. Throughout,
particular emphasis is placed on the rapid and effective transfer to industry
of the knowledge and expertise stemming from the RAE work. This facet has beer,
particularly important in our standardization work.

Section 2 of this paper, then, addresses interface and data transmission standards,
Section I covers zoftwarc and programming languages, and Section 4 discusses
inrtruction set architecture standardization.

157

_ OMAw
Ra.%[~~* ~**~%
2 DATA TRANSMISSION

RAE has been involved with the development of Mil Std 1553B, in collaboration
with USAF, since 1975. The history of this involvement was presented in a pipl
:'or Lhe first AF'SC Standardization Conference (Ref i), which also detailed wor'
done in UKC in sup..JX / 1h*. adoption of the multiplex data bus in airborne
systems.

The paper states that in consideration of such adoption and its impact on futur,
avionic systems architecture, it became clear that, in addition to the data bus
itself, other digital interfaces would still be required, and it was decided tbt
the publication of the data bus standard in UK would be as part of a compendium
of compatible interface standards.

In order to ensure that such standards would be universally acceptable, and to

make use of the knowledge and expertise of industry, MOD formed the Data Trans-
mission Standards Committee (DTSC) under the chairmanship of the DANav (Director-
ate of Air Navigation & Reconnaissance Development) branch of MOD Procurement
Executive, with RAE acting as the technical authority and with extensive member-
ship from both airframe and avionic system companies.

The vehicle for standards emerging from the work of DTSC is Def Stan 00-18,
which is, in effect, the compendium referred to above. Def Stan 00-18 caters for
the transmission of serial digital data through specification of an electrical
multiplexed data bus and both electrical and optical single-source interface
systems. The transmission of discrete signals is also catered for by both
electrical and optical interfaces. The Def Stan is published in a number of
parts, as will now be discussed.

It was clear from the outset that in order to support the introduction and
maintenance of the standards, guides would be necessary. The guides have been
produced, and they form Part 1 of the Def Stan. They give an official inter-
pretation and amplification of the clauses in the standards, where experience
suggests this is necessary, and also contain information to help the designer
avoid known difficulties in implementation.

The Mil Std 1553B serial time-division command/response multiplexed data bus has
been incorporated into the family of standards as Def Stan 00-18 (Part 2).
This is technically identical to 1553B, but has been re-written in order to
conform with the accepted Def Stan format and to 'anglicize' some of the phrase-
ology. UK MOD has also supported the ratification of 1553B as NATO STANAG 3838
and ASCC Air Standard 50/2, and Def Stan 00-18 is the instrument by which tbh-at
agreements are implemented.

Although there is wide experience in the United States of developments incorpo:xting

former versions of the Mil Std, UK has adopted the 'B' version from the outset.
YISC has, therefore, sought to rationalise the implementation of the standard )y
providing a focus for both UK Government and Industry development efforts, and
this has resulted, for example, in the chapters in the guide (Part 1) on the
definition of preferred remote terminal responses and on testing. MOD has als
funded the development of devices to perform the remote terminal function, whi:-
has resulted in the products now available from Marconi and Smiths Industries.

'of Stan 00-18 (Part 3) defines a single-source, single/multi-F;ink seriil di

.. '
transmission interface system for applications which do nt r",P.!o -tlp,

158
 data sources or that wish to implement a simpler interface to the multiplexes
data bus. The salient features of the interface are that it retains the resilient
electrical parameters, hardware configuration and data encoding of the multiplexda
data bus whilst simplifying the interface protocol in a well-defined manner
appropriate for point to point applications.

Def Stan 00-18 (Part 4) rationalises discrete signalling to three types of

interface that meet the majority of aircraft requirements. Discrete signalling
is dvided by functional constraints intot
a. those which require fast response times (critical timing signalling),
b. those which are not particularly constrained (non-critical timing
signalling), and
c. those which need to supply power with the signal (low power switching).
The development of Part 4 represents the first attempt on a national basis to
standardize discrete signalling, and is aimed at ensuring electromagnetic and
functional compatibility whilst reducing costs through simplification and
opt imisat ion.
Both Part 3 and Part 4 of Def Stan 00-18 are receiving attention in the Avionic
Systems Working Party (AVSWP) of NATO-MAS and in ASCC Working Party 50 as potential
international standards for data transmission.

Def Stan 00-18 (Part 5) contains four fibre optic single-source data transmission
systems for use in aircrafts two serial data transmission interfaces, at 1 MHz
and 10 MHz, respectively, a fibre optic stub for the multiplexed data bus and a
discrete signal interface. The development of this standard posed problems due
to the immaturity of the technological field, which were overcome by creating a
hierarchical structure to system specification that allows scope for, and guides,
continued development. On the topic of fibre optics, DISC were also responsible
for commenting on, and contributing to, the fibre optic version of Mil Std 1553B
drafted by SAE A-2K.
To sumarise, then, Def Stan 00-18 currently comprises five parts:
Part 1 - Application guide.
Part 2 - Multiplex data bus.
Part 3 - Single-source, single/multi-sink interface.
Part 4 - Discrete signalling.
Part 5 - Fibre optic interfaces.
These standards have been shown to satisfy the majority of existing requirements
Por digital signalling and to meet the aircraft physical and electromagnetic
*. compatibility requirement. They have also served to focus both component and
system development resources within the UK, to the benefit of both MOD and
Industry.
Current considerations in P1SC include planning for updating the guides and for
development of further testing and evaluation techniques, plus discussion of
new options for standardization, such as high-speed buses, video distribution
and standard data word formats. In such areas as these it is anticipated that
cooperation with the United States through the established channels of the IEP,
the iUrSC/SAE dialogues and through common support of the NATO and ASCC comiittee6
will be as fruitful in the future as it has been in the past.

159

----------------------------------....
.* , ~~*~** %~-*~~q~%* ~ %~%q : ~ ~ !
 3 SOFTWARE DEVELOPMT AND HIGH ORDER LANGUAGES

MOD has operated a standard high order language (HOL) policy since 1970. This
is a tri-service policy and is based on the language CORAL 66. CORAL is an
acronym for Computer On-line Real-time Applications Language. The original
version of the language was specified in 1964 and the current version was spec-
ified, as its name suggests, in 1966, at the MOD establishment which is now
known as 1M (the Royal Signals and Radar Establishment).
The first Official Definition of CORAL 66 was published in 1970 (Ref 2), as was
the first general users' guide (Ref 3), and the use of CORAL as a standard was
ratified by the
had operated publication
from of Def
1970, the Def Stan
Stan was 05-47. Although
not published the standard
until 1977. policy

CORAL 66 is based on Algol 60, with developments to make it more suitable for
the embedded on-line task. Technologically it is a similar level language to
Jovial J73. Since its adoption as a standard, many MOD development programmes
have utilised the language in land, sea and airborne applications, and it has
been implemented on many host and target processor types. There is, therefore,
in UK a considerable body of knowledge and experience, not only in the technical
application of the language but also in the problems and details of operating
a standard language policy.

CORAL 66 is a sequential programing language; is, it provides no facilities

for such real-time concepts as process synchronisation and scheduling. It was
originally designed to operate in conjunction with the operating system or
executive extant on whatever the target machine happened to be. Thus, although
this makes for an implementation-independent language definition, it inevitably
leads to machine-dependent implementations, and this was one of the early prot-
lems encountered with the use of the standard. Also, with the trend towards
host-target software development methods and standard software support suites,
it became increasingly important to standardise on a particular software
development and executive technique.
The method chosen for this purpose is MASCOT, which was also developed at RSRE.
MASCOT is an acronym for Modular Approach to Software Construction Operation and
Test. An Official Definition of MASCOT (Ref 4) was published in 1980, and the
following extract drawn from that document describes its function. MASCOTI
a. defines a formal method of expressing the software structure of a real
time system which is independent of both computer configuration and
programming language;
b. imposes a disciplined approach to design which yields a highly modular
structure, ensuring a close correspondence between functional elem:r.ts
in design and constructional elements for system integration;
c. supports a program acceptance strategy based on the test and veri-
fication of single modules and larger collections of functionally
_ related modules;
0. d. provides for a small, easily implemented executive for the dynamic
control of program execution at run time;
e. provides for a straightforward and flexible method for system buil: n.T!
f. can be applied through all stages of the software life c-cle from
design onwards;

16o

kaw W
 g. can form the basis of a standard system for software procurement
and management.
MASCOT is a design method supported by a programming system. It is neither a
language nor an operating system although it includes elements that are related
to both these aspects of programing. It brings together a coordinated set of
tools for dealing with the design, the construction (or system building),
operation (or run time execution) and testing of software.
A powerful standard facility now exists in UK MOD for the development of soft-
ware for embedded computer systems, consisting of MASCOT used in conjunction
4 with CORAL 66, and extensions to CORAL have been designed which facilitate its
interface with MASCOT. This combination is significantly different from, say,
conventional languages with parallel processing features, which allow the creation
of parallel processes and their intercommunication data areas within the context
of a program. CORAL/MASCOT inverts this order, in that the expression of
parallelism and intercommunication is placed at the highest point of software
design, and programing, in the conventional sense, has a subordinate role,
being used to express individual system components. This method, therefore,
promotes a very high level of structured modularity in the applications software.

The principal problem with the use of CORAL 66 in future airborne systems,
however, is that it is a national standard, whereas many of the programmes with
which we are concerned are, or will be, international in nature.* Also, CORAL
is based on development which started nearly twenty years ago, and does not reflect
modern thinking in language technology. These two factors are among the principal
reasons for MOD's long term interest and participation in the US DOD's Ada
l.anguage development programa.
There is little doubt that MDD will adopt Ada as a successor to CORAL 66 when
this becomes practicable. One of the important factors to be considered in this
respect is the nature of the Ada Programming Support Environment (APSE), to
which considerable attention is being given in the DOD. MOD effort, coordinated
by RSRE, has been responsible for certain investigations about APSE requirements
and XDD is currently putting together a programme in conjunction with other UK
agencies to develop a UK Ada environment which also supports the CHILL language.
It should be noted, however, that Ada will not be adopted in an uncritical way.
There are clearly still imperfections which must be addressed, and it is certain
that there will be restrictions imposed for the use of the language in, for
* example, safety-critical areas. UK is currently involved with other NATO nations
in an AGARD Working Group studying the potential impact of Ada on aircraft
guidance and control system programming, and this is just one example of the
type of activity under way.
* It should also be noted that there is an intention to carry forward the MASCOT
type of development philosophy into the Ada era, and consideration is currently
being given to the publication of certain aspects of the MASCOT approach in a
Def Stan.

4 INST'RUCT ION SIT ARCHITECTURES

UK MOD currently operates a computer policy for embedded systems which pf-
two UK proprir~tary processorss the Ferranti Argus M700 and the GCO 4000 sieries.
 The Argus U700 architecture has been specified in Def Stan 00-21, and both the
present policy architectures have been used in a variety of land, sea and air-
borne applications. MOD is currently funding a VLSI version of the 700, known
14 as the M700/40.
As was mentioned in the Introduction and in the discussion on CORAL 66, however,
the air side, in particular, needs to keep an international perspective and to
operate with standards which are internationally acceptable. This is particularly
so when considering the requirements of international collaborative projects and
the compatibility of home and export markets for avionic equipment, and is the
reason for RAE participation in the US Mil Std 1750A exercise.

Again, the history of this participation is detailed in Ref 1. Suffice it to

say here that RAE (and certain UK companies) have attended and contributed at all
1750A User Group meetings and RAE has also occupied a seat on the USAF Control
Board. In addition RAE was responsible for construction of what is believed to
have been the first single card 1750A processor.

Since the 1980 Conference, RAE has been responsible for the contract on Ferranti
to provide two flyable 1750A prototypes with full 1553B bus control capability,
and these are scheduled to be delivered by the end of 1982. RAE has also placed
a contract on Systems Designers Ltd (SDL) for the development of a 1750A target
to their CONTEXT (CORAL/MASCOT) development, hosted on VAX 11. This will provide
full CORAL 66 and MASCOT facilities for 1750A, and will be ready in about the
same timescale as the prototypes.

RAE has also run the McDonnell-Douglas assembly level package and has been
responsible for distributing it to a number of interested firms in the UK.
The Acceptance Test Program is now being run successfully at RAE.

On the policy front, RAE has written the case for 1750A to be adopted in the
M)D policy, and this is currently under consideration. RAE is also in the process
of drafting 1750A as a possible Def Stan. Internationally, MOD is currently
supporting the introduction of 1750A as a draft ASCC Air Std and is also con-
sidering under a NATO AVSTP Study.

REVERNCES
1 Callaway, A A United Kingdom Systems Application of Nil Std 1553B
with Additional Discussion of 1il Std 1750 Activity.
APSC Standardization Conference, Dayton, 1980.
2 Woodward, P I The Official Definition of Coral 66.
et al ENS 1970 & 1973.
3 Callaway, A A A Guide to CORAL Programing.
RAE TR70102, 1970.
MSCOT
A4 Suppliers The Official Handbook of MASCOT
Association 1980.

( Controller, HM Stationery Office London

1982

162

,dIle
 V-7 .77.7

POLICY SESSION AND PANEL DISCUSSION

SESSION CHAIRMAN: J. M. Hoeferlin

IASD/ENAS

MODERATOR : Col. Eric B. Nelson

Chief of Staff
HO AFSC
 Understanding DoD's Standardization Objectives

For Mission Critical Computers

D. Burton Newlin, Jr.

Defense Materiel Specifications and Standards Office

Office of the Under Secretary of Defense (Reseach and Engineering)

Introduction

The Military has placed increased emphasis on computer standardization to

improve interoperability and reduce the acquisition and life-cycle cost of
computer systems. With the accelerating advances in electronic technology,
hardware costs are decreasing while software costs are escalating. Today
the majority of DoD's costs associated with computer resources now involve
the computer software associated with weapon systems. Management
attention has been directed towards standardization as a management tool
that can be used to help reduce these costs and prevent a software crisis.

To address this problem the Department of Defense has proposed a three-fold

approach to achieve computer standardization. The first element is to
strengthen the management attention directed to oversee defense-wide
software standardization efforts.() The second element is to standardize
on a common computer high level language called Ada*, which is designed to
reduce DoD's increasing costs for the generation and maintenance of
software for its increasing number of computer systems. In the interim
until Ada is available, the Air Force has standardized on Jovial J-73 while
waiting for Ada to mature. The third element of the plan is the
implementation of DoD Instruction 5000.5X - a policy directive that defines
the computer Instruction Set Architecture (ISA) levels which established a
family of hardware-software interface standards. This minimum set of
standards is to be used by Services to achieve increased interoperability,
interchangeability and reduce the escalating cost of generating and
maintaining software.

Evolution of Computer Policy

A series of Directives and Instructions were issued and others updated to

formalize the policies, assign responsibilities and delineate authorities
within the Services to address computer acquisition and standardization
policies. The major Directives and Instructions are:

o DoDD 5000.29, "Management of Computer Resources in Major Defense

Systems. ,,(2)
" DoDI 5000.31, "Interim List of DoD Approved High Order Programming
3
Languages (HOL).",( )
DoDI 5000.5X, "Instruction Set Architecture (ISA) Standardization
Policy for Embedded Computers." Draft.(4)

o Ada is a trademark of the U.S. Department of Defense.

165 • v AO 9 -
J,, tiAN

!2QNVPM1V
The objective of DoD Directive 5000.29 is to assure that computer resources

are treated as important subsystems throughout the development, acquisition

and support phases of the life cycle of defense systems. This Directive
mandates that software developed for defense systems be developed in a DoD-
approved High-Order Language (HOL) specified in DoDI 5000.31 of which one
of the languages is the Air Force's Jovial J-73.

The objective of DoD Instruction 5000.31 is to reduce the proliferation of

machine assembly languages and imperfect HOL's used in defense systems and
to ensure that the preferred HOL's are used. The policy of moving to the
minimum essential number of such approved languages was established and the
search for a single language which would serve the broadest spectrum of DoD
applications was undertaken. This activity has become the Ada* Program
managed by the Ada Joint Program Office (AJPO). The Ada programming language
is specified in MIL-STD-1815.( 5 )
Although use of an HOL in software development and standardizing on a minimum
number of HOLs are helping to reduce life-cycle costs and improve the overall
software process, there is still required a considerable specialization of

the development environment. The computer program still must be tailored

to the specific host/target combinations of interest and thus, the reusability
and portability of both support tools and applications programs are attenuated.
For these and other reasons, consideration has been given to reducing the
number of unique environments within which HOL-based applications programs
must run. This can be done by controlling the interface between software
and the target environment, i.e., the Instruction Set Architecture (ISA) of
the target machines.

DoD Instruction 5000.5X

What DoD has attempted with DoD Instruction 5000.5X is to control the inter-
face between software and computer hardware by limiting the number of distinct
sets of allowed operations that the software can be called upon to perform.
Something like establishing a dictionary of words from which the programming
language can be constructed. This dictionary or limited "set of instructiow"
would form the standardized architecture with which a computer program co?)!
be developed. This set of instructions that form the architecture interface
for the hardware has been termed "Instruction Set Architecture" or ISA.
The objective of DoD's policy is to standardize and limit the number of
interface designs with which the software must be designed to perform and
to improve software transportability from one machine to another and to
enable, where mission dictates, hardware standardization. We are also hoping
that the use of a minimum number of ISA's will reduce costs for software
support tools. Standardization at the ISA level is the basis of a Proposed
DoD Instruction 5000.5X.

The Establishment of a Standardization Area for Embedded Computer Resources

The recommendations made by the Defense Science Board Task Force on Specifi-
cations and Standards( 6 ) and a GAO Study( 7 ) has led to the establishmert. 0.
a new standardization area for Embedded Computer Resources Standards (EGCS
An overall standardization document program plan has been developed
the coordinated management program for standardization effortr i, tE 2a
ompiter Resources Standards Area.(8) This plan, which i: c ..

1 66
'N with both government and industry, is the principal source of' management
information and identifies the various services, NATO, and industrial activ-
ities -- either planned or underway --that involve embedded computer resources
standardization issues. This plan also outlines objectives and establishes
priorities, milestones and resource allocations consistent with the identified
work backlog. The program plan is intended to promote conformance of stan-
dardization documents and associated data requirements with DoD policy, and
ensure the elimination of duplication and overlapping requirements and pro-
mote more uniform technical requirements documents. DoD's standardization
initiatives addressed in the Embedded Computer Resources Standards program
plan are concentrated primarily on the standardization of software high
order languages, architectures, software support tools, software documenta-
tion, quality control and configuration management.

The plan also identifies tasks being conducted by the Joint Logistics Commanders
to minimize the types and kinds of data requirements and ensure that data
requirements and applicable Data Item Descriptions can be selectively applied
* and tailored to match the technical requirements that are contractually
imposed through standards.
Tasks are also identified within the program plan to review nongovernment
specifications and standards for adoption, as well as identifying projects
being accomplished by industry associations as they relate to software prob-
lems and opportunities which have been identified that are of interest to
the Department of Defense.

Advantages of a Standard Instruction Set Architecture

The advantages of standardizing on a minimum set of Instruction Set Architec-

tures (ISAs) is that it accrues cost benefits during the acquisition and
support phases of the system life cycle. The reuseability of available
support software such as compilers, editors, linkers, assemblers, and instruc-
tion level simulators, etc., significantly reduces program risk because the
software development can be independent of the hardware development. Imple-
menting a standard ISA on programs allows program managers to start coding
efforts prior to the receipt of actual hardware and to use a common set of
proven reliable software support tools. The first benefit mentioned should
allow us to decrease software development time. The military can save many
millions of dollars in life cycle cost across the forces, while enjoying
shorter schedules, and fewer surprises during development. But most impor-
tant, a standard ISA will allow the military to exploit the explosion in
hardware technology without locking in on a single vendor's proprietary
computer architecture.

4 Comparing Standardization Approaches

E~ach of the Services has chosen a separate ISA standardization approach.
The Army has chosen to develop a military computer family (MCF) of computers
k and introduce a new government-owned, non-proprietary 32-bit architecture
called Nebula under MIL-STD-1862, principally for ground-based command and
control systems. The Navy has a large existing software base on just three
types of computers, while the Army is faced with over 50 different types in
the inventory. The Navy is attempting to inject the most modern technology
as replacements for the AN/UYK-7, AN/UYK-20 and, to a lesser extent the

167

-
ilk*
 AN/AYK-14. The principal rationale for holding to these ISAs for the Navy
is the conservation of the existing software investment. For the Navy,
this investment is connected with CMS-2.

The Air Force has a very different maintenance and logistic situation than
do the Army and Navy. The Air Force is standardizing at the computer
architecture level by adopting its own set of instructions as defined in
MIL-STD-1750. Under this approach, the computer manufacturers, will build
these instructions into their computer equipment in a manner best suited by
their manufacturing techniques and technology. The Air Force MIL-STD-1750
is a 16-bit architecture suitable for airborne, missile and ground-based
real-time systems. Recent growth to MIL-STD-1750A, as a result of broad
-industry and user-group input, will add extended memory management and
hence render 1750A germane to a wide range of applications as well. MIL-
STD-1750A processors are being implemented in the F/FB-III, F-16, F-5G
Tigershark, B-lB, LANTIRN, and is projected for a few other applications.

It may never be practical to go to a single ISA for all three Services,

however, steps must be taken to minimize the number of ISA's that must be
supported by DoD. Despite this objective, multiple sources for the hardware
will be assured as will the injection of the very latest advanced
technology. As one can see, the strategy which has been developed has led
toward a significant reduction in both architectures and languages. By
coupling the Ada Program and ISA standardization policies, we believe we
have demonstrated an effective and efficient degree of control in a very
rapidly changing technical and business environment.

Appropriate Level of Computer Standardization to be Achieved

Because of Congressional opposition to DoD's ISA proposed standardization

policy, the DoD has been unable to provide central direction as to the
level of standardization to be achieved. The Military Services are using
different standardization philosophies and concepts, although a unified
approach may accommodate most of their automation requirements. The
purpose of the proposed DoD Instruction 5000.5X is to provide this central
direction.
To assure that industry had an ample opportunity to review the proposed
policy, under DoDI 5000.5X an "Open Forum" was held at the Andrews Air
Force Base on November 2, 1979. This forum was announced well in advance
in the Commerce Business Daily (CBD). The proposed policy was also
provided to the major industry associations for comment. As a result of
this open forum, numerous comments were received from those in industry who
supported and opposed the proposed ISA standardization policy.

Many of the computer manufacturers and vendors who voiced opposition to

DoD's ISA standardization approach to reduce escalating software costs,
stating it will negatively affect hardware competition and that modern
technology will resolve the related software transportability issue. An
example is a new programming method called function-level computing, which
is being developed with the capability of linking computers of radically
different architectures and ostensibly simplifying software development
tasks.(9) But function-level computing is still in its inf.ncy and ni-nv
theoretical and practical problems remain to be solved before it cnm -
a reality.

168

-R~
 Since industry agreement was not reached on the proposed ISA standardizationI
policy -- as a result of a few dissenting industry votes --the Under Secretary
of Defense (Research and Engineering) decided that a review by the Defense
Science Board would be appropriate prior to any further processing of the
Instruction. A special Defense Science Board Task Force on Embedded Computer
Resources Acquisition and Management was chartered in September 1981 with
representatives of both government and industry to review the ISA and other7
embedded computer standardization issues. The task force met between Sep-
tember 1981 and January 1982 to advise the Secretary of Defense and the
Under Secretary of Defense for Research and Engineering an overall research,
engineering, acquisition and management issues and to provide long-range
guidance in these areas. Although the major issue which spawned the Task
Force was DoD's concern over the need for DoDI 5000.5X and Industry's resis-
tance to it, there were many related issues which the Task Force was also
specifically asked to address.
Following completion of the DSB Task Force Study, a series of GAO reports
were written and Congressional hearings conducted to review this entire ISA
issue.
Congressional Research Service Report
I' The Congressional Research Service issued a report on February 3, 1982,
entitled "Military Computers in Transition: Standards and Strategy".(1 0 )
This report outlined the evolution of DoD's computer standards policy up to
the point in time the Defense Science Board Task Force on Embedded Computer
Acquisition and Management had completed their study. This report openly
questions the "integrity and professionalism" of the members selected to
serve on the Defense Science Board's Task Force.
4, GAO Investigation of Charges "Favoritism"

In March 1982, Congressman Jack Brooks requested that the GAO undertake an
immediate investigation to determine the validity of the charges raised by
theCoressional Research Service Report. The Congressional Research Service
Report('' stated:
"While it is recognized that it is difficult to get
knowledgeable professionals who are not involved in
some aspect or other of this specialized subject, the
selection of task force members who have a recognized
14 1 interest in the outcome of the subject may be open to
criticism. For example, in some instances, members of
the Board were from companies that were participating
in related Defense programs and therefore might have
biased views of the problem and therefore may be deemed
to lack objectivity."

Congr.ssional Hearings on Favoritism in Computer Procurements Within DoD

The Subcommittee on Legislation and National Security of the House Committee

on Government Operations held hearings on July 21, 22, and August 4, 1982,
on possible favoritism in computer procurements within the Department of
Defense. These hearings addressed the Department's proposed policy (DoD

169
 m_771

Instruction 5000.5X) to design and develop its own computer systems and the
Defense Science Board's review of this instruction requested by the Under
Secretary for Research and Engineering.

GAO Report on Objectivity of DSB Task Force

The GAO issued a report (10) 22 July 82 on the objectivity of the Defense
Science Board's Task Force on Embedded Computer Resources Acquisition and
Management. This report criticizes the DoD:

o For not taking adequate steps to form a balanced task force.

o For not properly reviewing the financial disclosure forms to prevent

the appearance of conflicts of interest.

o For providing the task force with information drawn primarily from
sources supportive of DoD's position.

DoD Directed to Table Issuance of DoDI 5000.5X and Restudy ISA Issue for
the Armed Services Committees

The Armed Services Committees have expressed concern that standardization

at the ISA level may adversely affect the options available to the depart-
ment for achieving maximum effectiveness in new weapon systems.

Because of their concerns, the committees have directed DoD to postpone

issuing DoDI 5000.5X pending the completion and submission of a study to
the Committees on Armed Services of the Senate and House of Representatives
that addresses the following issues:(1 3 )
(a) A full assessment of the applicability of commercial computer
technology.
(b) The desirability of standardization at ISA level.
(c) The degree of software transportability that the various ap-
proaches permit and how each approach would affect DoD's
hardware/software logistics support requirements and the cost of
computer system ownership.
(d) An assessment of the relative merits and liabilities involved
in the incorporation of each approach into Department of Defense
weapon systems.
(e) A justification for all on-going service computer development
projects.
(f) A plan to reduce the proliferation of these computers.

The committee believes that this report would provide a necessary blueprint
for Executive branch management and Congressional oversight of the DoD's
efforts to streamline its computer logistics situation while laying the
ground work for an approach that provides vigorous competition and, to the
maximum degree possible, preserves the option for technology insertion.

Without ISA Standardization, Life Cycle Costs Will Continue to Escalate

Even with the development of the Ada* High Order programming langia', ' r:r
programs must still be written, tested, corrected and maintpined fc t-
unique instruction set of architectures of a selected am. ly of ra:-1:

170
 ILI to . .

The costs of maintaining these compilers and other support tools will pro-
liferate as the languge becomes more widely accepted and as more companies
develop compiler programs in order to implement Ada on the unique ISA of
their machines. The same ISA software problem that is facing DoD will also
be facing the software used within the Federal Government. The magnitude
of the DoD's problem is greater than the rest of the Federal Government
since DoD buys 70%, in quantity, of all government computers.

To address the software problems with general purpose computers facing the
Federal Government, the General Services Administration established the
Automated Data and Telecommunications Service. Under this organization
*- four offices have been established: Software Development Office, Federal
Compiler Testing Center, Federal Conversion Support Center and Federal Soft-
* ware Exchange Center. The Office of Software Development is concerned with
reducing the costs spent on both the development and maintenance of general
purpose software used within the Federal Government. The Federal Compiler
Testing Center provides assistance to the private sector to meet the Federal
Information Processing Standards (FIPS) by providing compiler validation
systems and services to a wide variety of clients.

The ISA Stifling Technology Fallacy

It has been alleged that if DoD standardized on a minimum number of Instruc-
tions Sets it would result in DoD using stifled technolgy, but this is a
fallacy since in the case of the Air Force's MIL-STD-1750 it does not dictate
the technology which should be used to comply with the ISA. To prevent
this from happening and provide documents for DoD to use on its current
contracts; standards are constantly being revised, updated and developed to
meet the requirements of the new technologies. Under the Defense Standard-
ization program, it is mandatory that all standardization documents be re-
viewed every five years and either be revised, updated or cancelled. Under
the proposed DoDI 5000.5X DoD would continually review proposed ISA that
should be added to the list approved for new designs, just as obsolete ISA
designs would be removed from this list for new designs.

Program Assessment

The major objectives of standardization within the DoD are to improve opera-
tional readiness, and reduce costs. Through the standardization of high
order languages, instruction set architectures and improved computer software
documentation, the efficiency of logistics support should be improved and
life cycle costs should be reduced.
In the development of our standardization program for embedded computer
resources, we are seeking to obtain participation and input from as wide
and diverse a group as possible. An objective of the embedded computer
resources standardization program is to ensure an orderly development of a
cadre of standards. An effective standardization program in the computer
technology area will require a close working relationship both within the
Government and with industry.
Conclusion:
* The standardization of ISA's is still a highly controversial issue, both

171
from a technical and political point of view, since it will affect competi-
tion for hardware procurements. Several companies who opposed MIL-STD-
1750A are not in the process of developing 1750 processors on their own
funds. The Department of Defense is convinced that, because of advances in
hardware technology and the advent of very high speed integrated circuits
technology, standardization of hardware should be both vendor and
technology transparent and that our computer standardization requirements
should be expressed through a very limited number of instruction set
architectures,

It is believed that more effective use of software interface standards

which define a standard set of computer instructions or Instruction Set
Architectures can significantly improve software productivity and
transportability by reducing software proliferation and therefore reducing
the costs for development and maintenance of computer programs and
documentation. To attain this objective, we must have effective management
controls in the acquisition process.

References

(1) Proceedings of the Twenty-First Annual Technical Symposium on

Computing and Government, National Bureau of Standards,
Gaithersburg, MD, DoD's Embedded Computer Standardization
Initiatives, D. Burton Newlin, Jr., June 17, 1982.

(2) DoD Directive 5000.29, Management of Computer Resources in Major

Defense Systems, dated 26 April 1976, (Being Revised).

(3) DoD Instruction 5000.31, Interim List of DoD Aproved High Order
Programming Languages (HOL), dated 24 November 76 (Being
Revised).

(4) DoD Instruction 5000.5X, Draft, Instruction Set Architecture

(ISA) Standardization Policy for Embedded Computers.

(5) MIL-STD-1815, Notice 1, Ada* Programming Language, 10 June 1981.

*Ada is a trademark of the U.S. Department of Defense.

(6) Defense Science Board Report of the Task Force on Specifications

and Standards, 21 April 1977.
(7) GAO Report, LOD-80-69, The Department of Defense's
Standardization Program for Military Computers -- A More Unified
Effort Is Needed, 18 June 1980.

(8) Standardization Document Program Plan for Embedded Computer

Resources Standards (ECRS) Area. Draft, Defense Materiel
Specifications and Standards Office, Dated 15 September 1982.
(9) IEEE Spectrum, Function-Level Computing, John Backus, AIgust
1982.
172
(10) The Library of Congress Congressional Research Service Report,
Military Computers in Transition: Standards and Strategy, Dated
February 3, 1982.

(11) Ibid.

(12) GAO Letter Report, GAO/FPCD-82-55, Objectivity of the Defense

Science Board's Task Force on Embedded Computer Resources
Acquisition and Management, 22 July 1982.

(13) Department of Defense Authorization Act, 1983, Congressional

Conferenoe Report No. 97-749, August 16, 1982.

173
 -

NWR U
o
-

SN

' )•

175

. . . . . .,.
 NJu

CDL

m NJ2
itL
oc nf
m

-0-

0 02

04
Lq n I-Wost
r1. N a0r
mig
cu

to U) 9) cc (1 X CL

176
 LJmJ

aw
mL
c
LIJ

UnLL

CoC )
E - cc

C.39

C..3 r- a

V)a

U17
L W d

Fo's I- il
P-*2 U) w
0 ! i r
cc am2 It
2l 20
W2
LO)

Uw
CCW
00 CC

-a 00

178
 7 :- S Z-.. -..

Cc 0
40 LI
go U)
0 W1 01 cc CL
C-5-
M L

~nu %% Wii I L
00

a0 2 0 a~
0 c

1 b19
 RD0-R145 697 PROCEEDINGS PAPERS OF THE AFSC (AIR FORCE SYSTEMS 3/6
bLIH-ATROAVIONICS STAND_.(U)
F HDRCOAECOMMAND)
AERONAUTICAL SYSTEMS DIV
UNLSIID CA PORUSCANSKY NOV 32 F/6li/3 N

I
EEEEEE|h|h|hEI
fllfll|fflfflfflfflf
EhEEEEEEEEEEEE
IIIIEIIEEEEEEE
lfllflflflflflflfllflfll
EEElhEElhEEEEE
 -- -
- - - .-..- d.

10 _

U2*2
__
a... 1345
liiiI~ *3*5

IIIII 1.1
till,-
mm ~ ~1*8
U-
11125 Ifl1*4 El i.s
90

C72 w U.1

0 0
L isw 0

00
Z
ch
Ewl 0

0 2

180
-6 -- U.- % 7~-.-
~ . - .

0 U
cc

NJ 0
3- S
ww
LL

o 2LI 5
<I C3 0 Isw
Cu CL0 m3mC

0~, EDw

00

181
 IRIMR
WM WTWII 4,W -77,. . - - F .0- 7 - 7 -2 7

00

00
00
0 C)

0%k..

E 4c4C mN

tow
0 00

182-
 EM4BEDDED COMPUTER STANDARDIZATION
IN THE NAVY -- POLICY AND PRACTICE

Captain David L. Boslaugh, USN

Director, Tactical Embedded Computer

Program Office
Naval Material Command Headquarters
Washington, D.C. 2036
(202) 692-3966

ABSTRACT

The Navy has 5000 standard embedded computers in 450 types of warfare
systems using over 50 million lines of computer program source code. Some of'
these machines are approaching obsolescence and are experiencing speed and
memory saturation in many applications. In mapping out a program for
successors to these computers the Navy has considered a number of
constraints, and has established a number of goals and policies which will be
reviewed in this talk. The Navy organization which plans, develops, and
enforces embedded computer standardization will be presented; followed by a
short overview of the Navy thinking about the future beyond the the new Navy
standard machines being developed today. The Navy's goal to reduce future
software costs through transitioning to the new Ada programming language will
also be reviewed.

INTRODUCTION
The initial introduction of shipboard digital computers some twenty one
years ago in the Naval Tactical Data System (NTDS) was met by the first
seagoing users with a form of enthusiasm. For example "No damned computer is
going to tell me what to do" was an oft heard quote by the workers in the
Bureau of Ships NTDS project office. Furthermore, the "outlandish" project
office claims of 300 hours mean time between failure for such complex
machines was viewed with skepticism and derision; and the makers of analog
weapons computers went so far as to publish small treatises in their
instruction manuals "proving" the impossibility of using digital computers
for weapons fire control.
Twenty one years later the controversies still rage around the military
use of embedded digital computers. The controversies have even risen to the
halls of' Congress. The issue, however, is no longer whether embedded digital
computers will be used. They are fully accepted now--even an absolute
necessity. The issue rather, is standardization of embedded computers and
there are tens of billions of computer acquisition dollars at stake in the
Navy alone. Likewise, battle effectiveness and billions of dollars in
savings and cost avoidance are also at stake. Because of the very large
coming market for embedded computers and because of the large and diffuse
number of computer suppliers and Navy embedded computer users there are great
pressures against standardization. The rapid change of technology also

183
 IM V! V2M9-TX'w'wT
-%.. .

millitates against standardization. It is, therefore, absolutely essential

that any viable service embedded computer standardization program have not
only a line Of state-of-the-art equipment and standard support software
readily available for Users, but also there must be an organization to manage
and enforce the use of the standard product line. Additionally, the product
line can not be allowed to become stagnant therefore, continuous long range
requirements determination and planning for technology upgrades becomes an
essential part of this organization.

POLICIES FOR STANDARDIZATION

Just what is an embedded computer? The concept of embedded computers

means different things to different people. To some it involves processors
(particularly microprocessors) physically embedded in, and a part of, some
larger containing functional equipment such as a radio, display terminal, or
a PAC-MAN. To others it is a stand-alone computer which serves as the heart
of a larger combat system composed of a number of separate equipments--such
as a gun system, command and control system or a missile system. The Navy
definition of embedded computer embraces both of the above. Specifically,
for Navy purposes an embedded commputer is:

"a computer that is an integral

component of any system or subsystem
contributing to the combat capability
of operating forces. This includes:

o ship, submarine, and shore

applications
o non-militarized computers when
used in combat systems."

SCOPE OF NAVY EMBEDDED COMPUTER MANAGEMENT POLICIES

All Navy warfare systems, and direct warfare support systems, using
embedded computers are subject to the Chief of Naval Material's embedded
computer resources management policies. System types covered include:

o weapons
o communications
" commnand and control, and
o intelligence
All platforms--ship, submarine, air and shore are included. Because of the
wide variability of computer applications ashore, and because some warfare
systems ashore can use embedded non-militarized computers, (because of beningn
environmental conditions) application of informed judgement is sometimes
required to distinguish between warfare support and non-warfare support
systems using non-militarized computers. As specific examples of
non-militarized computer applications ashore, Navy elements of the World Wide
Military Command and Control System (WWMCCS) and the Ocean Surveillance
Information System are classified as warfare support systems and are subject
to CNN embedded computer standardization policies. On the other hand,
logistic support systems, laboratory scientific computers, and software
support facilities, inter alia, are not so subject.

184

nmP ogle Mr 6rb* 9MME00n

 The Navy ECR standardization policies do cover all life cycle phases of
warfare systems development and acquisition, commencing with concept
formulation and progressing through major upgrade and life cycle maintenance.
The unique nature of computer software causes the requirement for coverage in
the very early development phases. It has been found that the investment cost
for prototype software even for "breadboard" conceptual systems is so high
that it is usually not economically feasible to "throw" this software away
when progressing to more advanced R&D. Rather, the software evolves from an
initial conceptual base which is usually expensive. Thus, original very
expensive software done in a non-standard language, for a non-standard
computer, and not documented in accordance with standards can "lock" a system
into continued use of non-standard equipments because of unacceptably high
cost of re-working the software to meet standardization requirements. Thus,
the requirement to start early on with standards. In addition as much as 70%
of total software cost is in post delivery support. This has shaped Navy
standardization policies which require "up front" software planning and design
investments which will hold down overall life cycle software maintenance costs.

Standardization areas covered by Navy embedded computer policy include the

following:

o Hardware, including:
the
-- a line of computers and microprocessors (currently
AN/UYK-7 "mainframe" and the AN/UYK-20 minicomputer--to be
succeeded by the AN/UYK-43 mainframe and the AN/UYK-44
minicomputer/microprocessor which are both nearing the end of
development.

-- special purpose signal processors

-- display and operator terminal subsystems

-- magnetic tape handlers, and

-- rotating mass memories.

o Standard support software, including:

- operating and executive systems for the standard computers

-- basic software development "environments" called Machine

Transportable Support Software (MTASS). (MTASS is hosted on
a number of large commerical computer systems.)

o Software Development Methodology, in accordance with MIL-STD-1679

(Navy) Weapon System Software Development.

o Software Documentation Standards, as required in Secretary of the

Navy Instruction (SECNAVINST) 3560.1

o Software Configuration Management, as required by NAVMAT Instruction

'4130.2

185

5~~~~ .N.( C W S **S ,

 0 Life cycle support of software, as required by NAVMAT Instruetion
5200.27 which requires, inter alLa, the assignment. )F I, Nivy !;uofwar',
life cycle support activity for teach embedded computer app!i,'itL(on:
or support program.

0 Standard High Order Programming Languages - CMS-2 supports the

standard general purpose computers and SPL/I (Signal Processing
Language/I) supports the AN/UYS-1 and AN/UYS-2 signal processors.
Ada will begin to replace CMS-2 for new system starts in 1986.

All of the above "Navy Standards" must be used in all Navy weapons systems
developments and acquisitions or a formal waiver must be obtained from the
Chief of Naval Material (CNM) in advance of applying funds for acquisition or
use of a non-standard. CNM policy on use of the standards is specified in a
series of documents called Tactical Digital Standards (TADSTANDS) and is
reiterated in periodic CNM policy letters and in Chief of Naval Operations
(CNO) instructions and notices. More about the TADSTANDS will come later.

CURRENT EMBEDDED COMPUTER DEVELOPMENT POLICY

The Navy is in the final stages of developing computers to succeed the
obsolescent AN/UYK-7 and AN/UYK-20 computers and the AN/UYS-1 Advanced Signal
Processor (ASP). One of the controlling policies in these developments has
been a requirement for industry-wide competition and a public statement that
the winner of each competition will be awarded all Navy standards production
in the applicable performance category of each standard equipment for a
specified length of time. The Navy acquires all rights and data for these
standard equipments in order to support possible second sourcing or
recompetition; and central Navy configuration management/control is
established for each equipment type.

Other specific policy guiding these developments is as follows:

o Provide for logistically Identical Computer Modules (within a given

equipment type) for Lowest Life Cycle Support Costs - The cost of
at-sea maintenance (including inventories of spare parts) is the
one largest compelling factor for Navy computer resources
standardization. One generation of standard computers can be
supported with a fleet-wide inventory of spare parts costing about
$60 million; whereas the shipboard spares for a proliferation of 35
logistically different computers would cost over one billion
dollars. Thus, until failure-free, and consequently spares-free,
computers are developed the Navy will require families of
logistically identical computers.

o Ensure Software Transportability from UYK-7 and UYK-20 Systems -

The large Navy investment in weapon systems applications software
(approximately $5 billion in replacement value) and in standard
support software (valued at $100 million) has required that
successor computers be able to upward "emulate" the instruction s.'t
architectures (ISA) of existing standard computers in order that
software can be reused and "upward" transported as necessary. Th
ISAs of the new computers not only support the software of their
predecessor computers but contain extended instruction sets wi t

186
. ... . ... ,J *- . ' --o~-I-
J* - - - 4 *- -- t. . _ b . .- - ' '

new and more powerful instructions for new applications. For example, it is
planned that production UYK-43 and 44 computers will also include Ada
optimized instructions.

o Improve Reliability and Maintainability - Current developments will

have unprecedented improvements in reliability, maintainability,
automated trouble shooting, fault isolation, and automated system
reconfiguration and recovery. The developing agencies have been
directed that these improvements must take precedence over
performance improvements if compromises should become necessary.
Thus far, both types of specifications are being met, or exceeded,
and no compromises have been necessary.

o Support Rapidly Expanding Microprocessor Applications - The Navy

has not previously had a standard shipboard embeddable
microprocessor for direct use inside other equipments; however,
microprocessor applications are expanding more rapidly than any
other computer class. To stem a potential proliferation of "16
bit" embedded microprocessors, the AN/UYK-44 standard electronic
module (SEM) card set and the AN/AYK-14 card set will be available,
and required, for use in embedded microprocesor applications.

o Support Expanding Programmable Signal Processor Applications - The

current standard Navy signal processor, AN/UYS-1, is being used in
applications which tax its full speed and memory. One application
even requires packaging three units in one cabinet, which is the
economic limit for multiple packaging approaches. Thus,
competitive development of a successor signal processor, AN/UYS-2
Enhanced Modular Signal Processor (DISP), has commenced. The
AN/UYS-2 support software environment will be compatible with the
AN/UYS-1 level allowing graceful transition of software. The
AN/UYK-44 will be used as a general purpose control processor for
the AN/UYS-2.

POLICY FOR AIRBORNE APPLICATIONS

The Navy standard AN/AYK-14 airborne computer has entered production

within the past two years and will remain the airborne standard, with
technology upgrades, for the remainder of this decade. Specific elements of
policy regarding development and use of the AN/AYK-14 include the following:

o Modular Expandable Versions - Aircraft weight and space

requirements levy demands that a computer be no larger or heavier
than need be for a specific airborne application. Thus, AN/AYK-14
versions are built from a common set of electronic modules and
placed in different packaging to accommodate differing amounts of
memory, power supplies, processors, etc. Four versions currently
exist.

o AN/AYK-14 emulates AN/UYK-20 ISA (with extensions) - Emulation of

the Navy standard "16 bit" ISA was required in order to reuse the
existing $50 million investment in standard AN/UYK-20 support
software.

187

* - p.
 0 AN/AYK- 1 4 or AN/UYK-44 Card Sets for Embedded Microprocessor
Applications - The AN/UYK-4 Standard Electronic Module card set is
both ship and air qualified. Thus, airborne embedded microprocessor
applications are required to use either of these, or obtain a
formal waiver.

EMBEDDED COMPUTER SOFTWARE POLICY

Software investment is projected to become the dominant life cycle cost in

embedded computer systems, and is thus a very appropriate target for cost
reduction and productivity improvement initiatives. Navy policies in support
of these goals include the following:

o Support Software - The $100M existing base of AN/UYK-7 and

AN/UYK-20 support software (such as Machine Transportable Support
Software (MTASS) Systems) will be built upon and extended to
support new upward compatible ISA hardware developments. The MTASS
systems and other elements of "compile time" support software will
eventually be incorporated into a complete Navy standard software
engineering environment (SEE) which will also evolve to incorporate:

-- the Ada programming language, and the Ada programming support

environment (APSE).

-- software requirments analysis and design tools

-- programmer productivity and software quality enhancement tools

o Applications Software - In addition to upward compatible computer

instruction set architectures, and software policy already
discussed, the Navy will place new emphasis on reuseability of
applications software from project to project. Key elements
supporting software reusability will include:

- Design of a highly accessible SEE data base containing

applications module libraries.

-- Interface and module design standards for reuse of

applications software modules

-- Heavy emphasis on software module reliability and

maintainability

-- Rigorous configuration management of all applications

software.

o Ada Plans and Policy - The DoD Ada Joint Program Office was
established in December 1980 and the Navy was the first service to
provide a permanent service Deputy Project Officer in February
1981. The Navy is fully committed to transitioning embedded
computer software to the Ada language and, in accordance with
current plans and funds availability, production quality Navy Ada
products will be available to Navy user systems for "new starts"
and major upgrades in early 1986. The Navy Ada Language Systei

188
will use the Army Ada compiler and the Army Ada Programming Support
Environment (ASPE) with minimum changes and additions. Initial Navy-unique
Ada products will include Ada oriented runtime operating systems for the
AN/UYK-43 and 44 and the AN/AYK-14 computers, and Ada target code generators
for all these computers.

NAVY ORGANIZATION FOR EMBEDDED COMPUTER STANDARDIZATION

The Navy has a single command, the Naval Material Command, responsible for
development, acquisition, and life cycle support of all warfare related
platforms and warfare systems. The Chief of Naval Material, a four star
admiral, who reports to the Chief of Naval Operations is responsible for
managing the Naval Systems Commands through a relatively small Naval Material
Command Headquarters staff. The Navy Systems Commands in turn have the
"muscle" to provide full material support to the fleet. Some of the systems
commands such as the Naval Supply Systems Command and the Naval Facilities
Engineering Command are not direct users or developers of embedded computer
resources, however the three "platform" systems commands--the Naval Air
Systems Command, the Naval Electronic Systems Command, and the Naval Sea
Systems Command both use and develop/acquire the Navy embedded computer
standards; and are integral parts of the Navy ECR standardization
organization. This organization, which is depicted in Figure 1. is brought to
a focal point at Headquarters Naval Material Command in the Tactical Embedded
Computer Program Office (TECPO) which is code-named MAT 08Y. The TECPO office,
headed by a captain USN, reports to the Naval Material Command's Deputy
Commander for Acquisition (MAT-08), a rear admiral. Each of the three
platform systems commands (SYSCOMs), in turn, has an office responsible for
managing the use of the standards within the SYSCOMS, and in two cases these
offices also develop assigned standard hardware and/or software.

Figure 1.

NAVY ORGANIZATION FOR .EMBEDDED COMPUTER

STANDARDIZATION

AOM (ES

FI-1 COOROI
OP-MS

NATOO
OP°-
S l

SPONSOR

GNM
v~M

MAT 8l/CNN MAT 08 r SC/ICR

rOONP 240 -- - -. M t I C JPCG CRM
TEHT1CP8 AJPS-NAVY DEPUTY

€OMNAVSIA I L COMNAW~tlx L COMNAVAIR ''

Su
of*" 0 IE AI 0 ,5

189

. ... 189.....
THE TACTICAL E4BEDDED COMPUTER PROGRAM OFFICE

Major functions of the NAVMAT Headquarters Tactical Embedded Computer

Program Office are listed in Table 1. which factors them into three areas:
long range planning, policy development & enforcement, and program management.

Table 1. Tactical Embedded Computer

Program Office (MAT 08Y) Functions

o LONG RANGE PLANNING

o Master Plan for Embedded Computer Resources

o POLICY

o Formulate and implement ECR policies (TADSTANDS) and procedures for

the CNM (TADSTAND approval/disapproval authority)

o Review acquisition documentatin for Navy Systems

o Monitor CM and Life Cycle Support of all Navy standard ECR products

o PROGRAM MANAGE4ENT

o Program director for NAVMAT R&D related to Navy Standard ECR

o Manager Navy 6.3 and 6.4 ECR RDT&E Program Resources
o PDA for:
--UYK-43 and UYK-44 Standard Embedded Computers
--Standard support software
-- Ada HOL development and implementation
o Assign DA's for Navy standard ECR products
o Direct CM of Navy standard HOL definitions, compilers, and ISA specs

Long Range Planning - The most tangible product of the long range planning
function is the Navy Master Plan for Embedded Computer Resources. As shown in
Table 2., this plan treats the future as near term, up to 1989, and long term,
from 1989 to the turn of the century. It is updated yearly after Navy-wide
review and comment to reflect new developments, suitations, and needs; and is
issued over the signature of the Chief of Naval Material. It contains
descriptions and plans not only for approved projects, but also goals and
objectives not currently in the approved Five Year Defense Program (FYDP).
The plan treats all aspects of embedded computer resources including computer
hardware, peripherals hardware, support software, programming environments,
applications software, manpower, training, and life cycle support issues.

Policy Functions - MAT 08Y develops ECR policies for the Chief of Naval
Material which are written and disseminated in condensed documents called
Tactical Digital Standards (TADSTANDS). The TADSTANDS cover such subjects as
standard definitions, lists of standard hardware, and authorized programming
languages. Each TADSTAND also delineates the conditions under which a waiver
might be granted. The TECPO office conducts the waiver review and
approval/disapproval process for the CNM; and as a part of the enforcement

190
 Table 2. Summary of Master Plan Strategies and Objectives

Near Term Long Term

(Pre 1989) (Post 1989

CP-642 obsolescence AN/UYK-7, AN/UYK-20,

AN/UYK-43, AN/UYK-44
NAVY
AN/UYK-7 obsolescence AN/UYK-43 EMBEDDED
COMPUTER
AN/UYK-20 obsolescence AN/UYK-44
_____________________PROGRAM

Lack of standard AN/AYK-14

airborne computer

Lack of standard AN/UYS-1 (ASP). AN/UYS-2 (EMSP)

signal processor Develop AN/UYS-2

Standard disk system Develop high technology High technology

obsolescense mass memory mass memory system

Proliferation of Develop standard medium Standard medium scale

non standard medium scale modular display modular display sub-
scale displays subsystem system

Upgrade current Navy

Programming support standard programming Ada compatible
deficiencies support systems; develop standard Software
Ada based software Engineering
engineering environment Environment

Proliferation of Navy Phase out divergent Implement Ada as

programming languages dialects; develop Ada single Navy standard
and dialects language capability programming language

191

-~~~ . . . N
function, reviews all acquisition planning documents for all Navy system
acquisitions to verify and/or require adherence to the TADSTANDS. As a
further followup on Navy wide application of TADSTANDS, the TECPO office
provides personnel to logistics review boards and project acquisition reviews.

o Program Management - The designated SYSCOM ECR project offices

develop and acquire standard hardware and software products as
assigned by the Chief of Naval Material and under "overview
management" of the TECPO office as the Program Director for all
NAVMAT TECR related research and development. For the most critical
of the multiplatform standards such as:

- UYK-43 and UYK-44 development

-- Standard support software, and
-- Navy Ada products

TECPO also serves as Principal Development Activity--meaning funds

and final technical management authority remain at Naval Material
Command Headquarters level for these programs.

THE SYSTEMS COMMANDS' ECR OFFICES

In addition to day-to-day management of assigned standards

developments, performing commodity management, and ordering agent functions
for their production programs, the SYSCOM ECR project office act as the first
line standardization management agents for CNM. This latter function includes:

o assessing user requirements for new ECR needs

o monitoring and advising SYSCOM weapon system (user) projects

o enforcing CNM standardization policies including initial

technical review of all waiver requests
Specific assignments of the SYSCOM project offices include the following:
o Naval Air Systems Command - Code AIR 543 (Avionics Systems and
Embedded Computer Resources Division)
-- AN/AYK-14 standard airborne computer

o Naval Electronic Systems Command - Code ELEX 814 (Computer

Resources Division)
-Development of standard software management procedures and
practices (primarily Navy contribution to Joint Logistics
Commanders software management initiatives)

o Naval Sea Systems Command - PMS 408 (Shipboard Tactical Embedded

Computer Resources Project Office)
- AN/UYK-7 and AN/UYK-20 production acquisition
-- AN/UYK-43 and AN/UYK-44 development
-- AN/UYS-2 Enhanced Modular Signal Processor Development
--Standard support software development and life cycle
support

192
 - Navy Ada products development
-- Standard shipboard peripherals acquisition (numerous
types)
-- Standard shipboard display and operator terminal
subsystems acquisition
-- Standard Navy compilers and associated support software

Even though a standard ECR product is developed and acquired by one SYSCOM
it is universally used by all systems commands. Other users of most of the
Navy standards include the U. S. Marine Corps, U. S. Army, U.S. Air Force,
U.S. Coast Guard, and the navies of seven allied nations. Table 3. shows the
developers and users of the standard computers.

Table 3. Navy Standard Embedded Computers

Who 'Acquires/Supports and Who Uses?

Computers Acquisition/Support Users

UYK-20 NAVAIR Australia
UYK-44 NAVSEA NAVELEX Germany
UYK-7 (PMS-408) USMC Italy
UYK-43 USAF Japan
UYS-2 Army Spain
Coast Guard Netherlands

AYK-1J4 NAVAIR

UYS-1 NAVAIR NAVSEA

(PA-264) NAVAIR
NAVELEX
USAF
In some cases the acquiring SYSCON is not the major user of a given
standard. A case in point being the AN/UYS-I Advanced Signal Processor which
is acquired by the Naval Air Systems Command where it is used in airborne
acoustic signal processing applications; however its dominant use is in a
shipboard versions for surface ship and submarine acoustic signal processing.

THE PROCESS
Major elements of the Navy's ECR standardization process have already
been reviewed. This section will serve to tie the process together by
elaborating on the use of the Tactical Digital Standards (TADSTANDS).
Approximately 400 Navy warfare systems are now using over five thousand
standard Navy embedded computers; however there have been, and will probably
continue to be, oases where the use of the standards might be:

-technically infeasible
--economically prohibitive, or
--operationally impractical

193
 If either the using system or the standard cannot be adapted or modified
to suit such situations, a waiver will be considered by the Chief of Naval
Material. In addition to standard equipments, there are other areas of Navy
ECR standardization policy coverage. Table 4. lists the full set of
currently effective TADSTANDS.

Table 4.
Current NAVMAT Tactical Digital Standards (TADSTANDS)

TADSTANDS
A Standard Definitions
B Standard Computers, Peripherals, and I/O interfaces
C Standard Programming Languages
D Reserve Capacity Requirements
E Software Development, Documentation, and Testing Standards

Table 5. summarizes the required contents of a waiver request. It should

be noted that the justification must emphasize why a standard can not be used
rather than why a non-standard should be used. Also total life cycle costs
and other life cycle considerations of standards vs. the proposed
non-standard must be articulated.

Table 5. TADSTAND Waiver Requests

o CNM (MAT 08Y) via Appropriate Cognizant SYSCOM Office

o Justification to include:
o System Name
o Platform(s)
o Embedded Computers
o Storage, I/O Requirements
o Software Constraints
o Environmental Requirements/Constraints
o Why Standards Cannot Be Used
o Proposed Substitutes(s)
o Plans, Schedule Cost Data on Proposed Substitutes (ILS)
o R&M Requirements
o Cost Comparisons

CHALLENGES AND OPPORTUNITIES

The Navy has excellent ECR standards, workable policies for

standardization, and effective procedures in place for carrying them out. We
should be able to lean back and relax--but such will never be the casel
Technology and operational needs are advancing so fast that technology
upgrade programs must start even before new standards enter production in
order for new standard equipments to remain competitive with the general
industry state of the art. Technology infusion studies and planning for the
AN/UYK-43 and AN/UYK-44 are already under way even though they will not be
delivering in large production quantities until 1984. Ada oriented
instruction set extensions and VHSIC technology are being considered as well
as "conventional" VLSI and memory density upgrades. Also, even with

194

. . .< -4s r#,-..,

"e .,.;,j,,.r-. -e ".---------* j ' .*';' ".,*%* " S -.. '"" .. .;
F
 WT.WT WT S-.

technology upgrades the new computers will reach the economic limits of
upgrading in not too many years, and new next generation high technology
successor competitive computer developments will be required. The Navy
currently intends to start a next generation computer advanced development
programs in 1985, and already next generation computer architecture studies
are in progress. One of the objectives of these studies is to ascertain the
best architecture (i.e., highest performance for lowest hardware and software
life cycle cost) for run-time execution of Ada compiled programs. Another
general objective of next generation Navy ECR standardization is the
elimination of at-sea maintenance and repair through acquisition of
"failure-free" machines. Such form, fit and function) (F) machines could
potentially be acquired from a number of supplies without the need to have a
prohibitively expensive proliferation of at-sea inventories of repair parts

Considerable Navy effort will also go into software quality,

reuseability, and programmer productivity enhancement. This work will be
centered around implementing Ada, and the Ada Programming Support
Environment. Software engineering tools of all types will be integrated with
ASPE and this entire body of support software will be evolved into a standard
comprehensive modular software engineering environment which will form the
basis for Navy "software factories."

Navy embedded computer resources management must remain forever sensitive

to new operational needs, new technological capabilities, and continuously
implement the same in order to retain a viable Navy ECR standardization
program. The challenges will never cease.

CAPT David L. Boslaugh, USN, Director, Tactical Embedded Computer Program

Office, Naval Material Command, Washington, D. C.

CAPT Boslaugh exercises overview management of the development and

acquisition of standard embedded computers and associated peripherals for use
in Navy warfare systems. For the most critical Navy multiplatform ECR
products he is assigned as principal development activity. His office also
performs long-range planning for standard computer developent and acquisition
requirements, including both hardware and support software, and carries out
the development-distribution-enforcement of related standardization policies
throughout the USN.

Previously, CAPT Boslaugh was Assistant Project Manager for C 3 Software

Development and Support, C3 Systems Project Office, Naval Electronic
Systems Command. He has also served as Director, Communications Research and
Development, for the Naval Electronic Systems Command. Other assignments
have included five years in the Naval Tactical Data System Project, three
years at the NASA High Speed Flight Station, Edwards, California as an
aeronautical research engineer, and command of the Naval Electronic Systems
Security Engineering Center.

CAPT Boslaugh is a member of AIAA, IEEE, ASNE and Sigma Xi. He holds a
BS degree in Aeronautical Engineering from the University of Minnesota, and

195

. ... ,. . , - . . ,, ,-,,-r,p-,t, u e p.p, . ".. , :

S;: , . * ,
Pt- , , S
an MS degree in Engineering Electronics from the U. S. Naval Postgraduate
School.

196
 ORGANI ZATIONAL OVERVIEW

Policy, Regulations, Status,

Implementation Plans:

US Army

BY: Col J. Frank Campbell

197
 1- U

Ui LLJ

0D LL

Umi 0C -
0) LZJ - L'

CM LL.J

I~~J LUO Li L.7

.1=C =o- C
cm
cm LLJ
c

CD -D CD.
C) CL =
 _LU LU

_i E
LU. L. L
LU
LU LU L

CL C
LU LU C
oi LU3 o

LU CD LU

LM C- rn
0 C
LUJ
_A Co0 COLU
I- LU- Co3
CD,

199
 C D- *i - - - - * .-

cm, Im
LU L.
CDO
= -LJ
Cmm

COD
tm C
LL

o LLU
zo

Cm,200
 C)

CP~LLJ S
0LA.

LU

m j m. = -
E c~UJ
LU -

LU 0

IL UUJ COD I

C.30
04 01 C'3 I.- CO
LLJ OD>
=U
=*
Ul
C LJ
D a1 L0

201
 L.
u

Cui .j
WA

LUi

LU LLJ

1= LU '

m
LU LJ
cir-
LUJ

OD CDL I

= >- j CL) -A

I- ~LU COD

Se -L m-m

LU LU x
.j
CL C L

202
 -J zJ
LUJ

L
UJu
C~s

0C~) CZ Cm

am. zD =

~Lu

U -

LOU

20
 0OD U.'
Co L.0

z Ia
0 ccc
LU I-

LUCm~E L

Co LL.

20
-------------------------------------

05
 07

L- U* LU
L 0'LL I L L

co
LLJ fo

L~LA-

__ IC.7 LU
CO ccZ
Zi 0iw
-D :z J

0u
LI.I
= =.g~ =

L C CDLLII~
~ ~ -

CL

206
 um LL

COD CO
LU LUI zi
cc.. LU
Cm =i
~wum

LuJ z
00 LUjC
COD LLJCL
CODUc~
Ck LJLU LJ u
L'> :MN
< co.

LU
U cm
Z1-Col = j -

LO Lu.
U C3C
- C) Jc

W LU X~ d
LLL. coia.

207c

Em- CO iu
 m Cl

zD
C=O~
M
C C
- ~In~-cm 0 0

ULU

LULOS
mmml ui .LU C

0D 04 Z U

LUC. cc~oLI
=i =.3= =T
COD Co I%..UCO
CLo

I ~ A L3(J)L 2L
 .N7

Ao

m----- m - mm m D

-J Ca c

inJ IJ0

zIU Lu C.
* Cm
u-i

ui
I-a-

CC~ C3 C-, C
02C
CO

U-

ULJ
cc

209
bI : COLJ. IlANE CAMS9LL
WaTRYso ACIvIa ITI: 2 Jun. 1959
&Al OF SAMe: 2 Ouese 100
SmUm: 26 U57 1922. sIm. woth Carslia
VIM: Pat J. Cqbe.l
IIIZN: Sabert 9 Nlrth 196l msid. I May I1n

ILTt* KwOmOLING:lnntry officers Bsic Course. sp It

Arborae School. Oct S9
bSer school. bIe St
lltriy Advaned Cours. Jue 4
Conned aud General StaffI Couree 1

WILIIAIl *ShhI NSS (Pent IS teest)

in OFFICE OR MT 901 LOCATION WEARS

C CD. 8-3 All 3d de lot Div Li sb.. 1 Jum66 - JUN 67

lIom etnutt Sup of U SW Set point. PT JOB 67 - N87 10

-udet am Ft Leaves- Ams 70 - Noy 71
Worth. U
Opun dv Sink Sweet PreLag. W3-3 Viete Jun P1 - Jun 72
0 loth f. 20 An wde Pt Jackson. SC Ft Jkom Sep 73 - Jan 76

-3 2d Al Sd Ft Jackon it Jacks" Jan It - Dec 74

Div chief Inspector central Ft Jackon ft Jackson ec 74 - Dec I

Cuoamder 15th DR. 4th AtT de It Jackson Ft Jnckiem Doc 75 - guy 7?

Chief
.iv Autmatite TeN. CSC. IOSM Sm Sash. K Nay It - Sov 50
liv chief Bttlefield Auto it Div WA 01tCom Ales, WA kv SO -

AIAMDS/IKCORATIOS
LogIo of Mi t. Sinus. $ta Model 41), Amy CinndutLou Usdal (3). Meriterious Vuit Citatise (1). tinal aute.@
Ssrice idal. Vietnam service Ndal %S). IN Gollitry Ceea-SI3UI Gallantry Cress Suit Citatle/W1 Civil Actions
hit Cittion. sa.r paraebutit. $as.e Cbot lIfeatr Sade.

210
 JOINT LOGISTICS COMMANDERS
JOINT POLICY COORDINATING GROUP
FOR
COMPUTER RESOURCE MANAGEMENT

Colonel John J. Marciniak, USAF

Rome Air Development Center

Griffiss Air Force Base, New York 13441
AC (315) 330-2165
BIOGRAPHICAL SKETCH

Colonel John J. Marciniak is the Chief of the Command and Control

Division, Rome Air Development Center (RADC), Air Force Systems Command,
Griffiss Air Force Base, New York. In this position he is responsible for
emerging software technologies for application throughout the Air Force with
special attention to command, control, communications and intelligence (C31)
systems. Current activities under his cognizance are the development of the
Ada support environment, knowledge based systems, the PAVE MOVER program, C3 CM
Technologies, and Decision Aids. Col Marciniak was the Chief of the
Information Sciences Division at Rome Air Development Center until a recent
reorganization at RADC constituted the Command and Control Division. He came
to RADC from HQ AFSC as the Director of Computer Resource Development Policy
and Planning, where he was responsible for Air Force higher order language
policy, implementation of computer architecture strategies, Air Force planning
for the introduction of computer architecture strategies, and Air Force
planning for the introduction of Ada. Previous assignments were with
Headquarters United States Air Force, the Air Force Satellite Control Facility
and the Electronic Systems Division. Col Marciniak received his BEE degree in
1957 from the City University of New York, and his MEE in 1969 from the
University of Oklahoma. He is a graduate of the Air Command and Staff
College, Maxwell Air Force Base, Alabama, 1973.

ABSTRACT
An overview of the Joint Logistics Commander's panel on Computer
Resources Management is provided. The Computer Resources Management panel was
organized to examine computer resource issues that are critical to the
acquisition and support of defense systems. The past efforts of the panel,
its current organization, and the current effort of the Computer Software
Management subpanel to develop tri-service software policy, a Software
Development Standard, a set of standard documents (Data Item Descriptions or
DIDs) and changes to existing standards are detailed. The current
industry/government review and implementation status of this effort is
discussed. The author assesses the impact that these standards will have on
industry/government and describes possible monetary savings that are possible.

211
INTRODUCTION
The Joint Policy Coordinating Group (JPCG) for Computer Resources
Management (CRM) is a formally constituted panel under the management of the
Joint Logistic Commanders (JLC): the four service commands; Air Force Systems
Command, Air Force Logistics Command, U.S. Army Material Development and
Readiness Command, and Naval Material Command. The activity of the JLC's is
to insure cooperation and coordination of programs, eliminate unnecessary
duplication and take advantage of mutual programs. There are currently 40
active panels dealing with subjects such as Automatic Testing to Simulators
and Training Devices. Panels may be short term, dealing with an Ad Hoc issue,
or continuing in nature dealing with longer term issues (of either a technical
or policy nature) as long as the issue is of interest to the JLC's. The JLC's
meet four times a year, at defined points, to review the progress of the
panel's efforts. Each set of JLC's imparts their own collective personality
on JLC activities. The current JLC's are extremely concerned with technology
cooperation (they have just reconstituted the Joint Director of Laboratories
panel) and meeting the Carlucci initiatives. They routinely meet with the
Deputy Secretary of Defense after each quarterly JLC meeting.

The Computer Resources Management panel was formed to provide a focus for
the JLC's on numerous embedded computer resources issues. The Charter, signed
by the JLC's on 6 December 1977, provides that the JPCG-CRM coordinate policY
procedures, guidelines, and standards to implement effective management of
computer resources in support of defense systems. Specifically the mission -
to:

a. Provide a focal point for CRM activities within the JLC.

b. Coordinate and insure consistency in the preparation of new or

revised regulations and standards to implement DOD Directives and Instructions
on CRM.

c. Provide recommendations to the JLC on critical resource areas in CY''.

d. Provide a JLC focal point for coordinating service computer resour
standardization programs.
Since its formation in 1977 the JLC has had some notable achievements.
It prepared a JLC policy on the nterservicing of operational software -- t '
is the utilization of common support resources in joint programs. That polir:y
is presently being incorporated into the JLC joint software policy presently
under review and discussed in more detail later. The CRM prepared a JLC
position on a Government Services Administration action to reclassify severW
Federal Supply Code (FSC) equipment groups as Automated Data Processing (AD,
Equipment (FSC Group 70). The effect of this action was to place FSC group
66 and 74, dealing with such items as test equipment, optical equipment, el.
under the procurement practices governing ADP and removed from normal suopp
acquisition practice. The JLC's got involved and the JLC-CRM drvel:)ed 0
joint position which was forwarded to the Service Chiefs. The anlioj it.<
s en deferred.

212
 Perhaps the most significant action was the study of an Ad Hoc CRM panel
on the acquisition of general purpose ADP integral to, or in direct support
of, Defense Systems. The Ad Hoc group studied the acquisition procedures of
the three services and developed recommendations for special acquisition
procedures of ADPE integral to Defense Systems. These recommendations,
presented to the Office of the Secretary of Defense (OSD), were timely since
several key Policy Directives were under revision. Members of the CRM Ad Hoc
.0 group worked directly with members of the OSD drafting a new DODD 5000.29,
Management of Computer Resources in Defense Systems. The policy provided that
the acquisition of ADPE integral to Defense Systems be integral to the overall
weapon system acquisition and not broken out for separate approval and
procurement. Notably it was a short time later that the Warner Amendment was
passed by the Congress providing for the above.

The current organization of the CRM is shown in Figure 1. Of the four

panels, the Computer Software Management (CSM) subpanel has been in existence
the longest, and it is the activity of this panel that is the primary emphasis
of this paper. The Professional Development Subpanel objectives are to
evaluate current professional development programs within the JLC's, provide
recommendations for new and existing programs, and in general to propose
better methods to enhance professional development of computer resource
management personnel. The Technology subpanel was created with the objective
of providing tri-service cooperation and even coordination of technology
issues common to the services. Of particular interest are those areas that do
not enjoy major interest or funding in any one service. It is believed that
cooperative programs in these areas could produce a critical mass of
technology effort that any one service is currently not able to sustain.
Examples of such technologies are Direct Execution of Higher Order Language
Machines and Software Requirements Management. Once an area of cooperation is
identified, the panel would provide for cooperation either through arranging a
formal tri-service program or insuring cooperation amongst the services.

The Terminal/Peripheral Standardization panel arose from a JLC initiative

to evaluate potential ideas for further Joint Services Cooperation. The
commands were canvassed and the JLC-CRM was tasked to evaluate nine issues.
Of these nine the CRM decided that the issue of standardizing on terminals and
peripherals used in tactical environments deserved further study and organized
an Ad Hoc panel to investigate the issue. The panel is chaired by Al Selgas
of the NAVMAT and the effort is expected to conclude with recommendations to
the CRM in September 1983.

THE COMPUTER SOFTWARE MANAGEMENT (CSM) PANEL.

The most successful effort of the JLC-CRM, and perhaps the most
significant, is under the responsibility of the CSM, that is the preparation
of a standard tri-service software management policy and acquisition
procedures. The effort took genesis in a very successful workshop on software
quality sponsored by the JLC-CRM in April of 1979. Termed Monterey I, since
it was held at the Naval Post Graduate School, Monterey, California, a group
of 100 selected personnel from government and industry (80/20% mix) organized
into four panels to discuss software quality, software acceptance criteria,
software documentation and software acquisition/development standards. Their
recommendations to develop a common software acquisition-development policy, a
single unified set of acquisition and development standards, a comprehensive

21

213

*1
 set of documents (Data Item Descriptions) and software acceptance criteria,
and to define government practices, procedures, methodologies and
responsibilities for software quality assurance were documented in a JLC
report, briefed to the JLC's and approved by them for implementation.
Since that time the CSM has been arduously at work carrying out their
charge. A draft tri-service software development policy exists, and has beer
circulated amongst the JLC commands for comments. Those comments have been
incorporated and the policy is ready for coordination. An early 1983 date is
* scheduled for implementation. While the policy will be binding on the JLC's
only, it will be submitted to the respective services with the recommendation
that it be issued as a joint service policy. The policy modifies the existing
development cycle in a notable way by introducing several additional
milestones (Figure 2). A preliminary design review will be held, ligitimizig
a practice already in existence, and backed up with a document which will fold
into the B-5 specification (Software Detail Design Document). The area of
requirements will receive more attention. Called out as a special problem
area in every major study of the "Software Management Problem" it is hoped
that this special emphasis will solve the problem of requirements creep and
maintain configuration control of requirements. It is important to realize
that this software development "waterfall" represents an evolutionary change
to the present lifecycle and not a completely new methodology.
The lifecycle will be backed up by a set of standard documents (Data Item
Descriptions), a new Software Development Standard, a new Software Quality
Standard and commensurate changes to existing standards such as MIL-STDS 483,
Configuration Management Practices for Systems, Equipment and Computer
Programs; 490, Specificatibn Practices; and 1521, Technical Reviews and Audits
for Systems, Equipments and Computer Programs. Action has already been taken
to coordinate these changes with the appropriate Offices of Responsibility.
The area has been given special emphasis by the DOD through the Defense
Material Specification and Standards Office (DMSSO) in the preparation of a
new standardization area for embedded computer esources. An Embedded
Computer Resources Standardization Program plan has been prepared
incorporating the planned changes currently under preparation by the CSM.

BENEFITS.

The overall effort is expected to not only make improvements in the

computer resource management process, but through streamling and standardiziPo
the computer resource acquisition process achieve cost savings. While thesc
are always difficult to quantify, we believe that we can make some projecti-r
based upon studies that have been conducted of the software development
process and associated costs. It is estimated that approximately 3-7 billior
dollars a year are spent on embedded systems software development. Assuming
that documentation costs are about 25 percent of overall software developmer'
costs and based upon an expected savings of 5-10 percent of documentation
costs, we forecast that we can accrue a savings of at least 40 million doll,3rs
per year. 3 Increased emphasis on requirements also portends cost savings.
Wolverton, in 1977, postulated the cost of fixing errors at different lifc
cycle phases to be:

214
 Requirements Definition - $ 195
Design - $ 489
Coding and Checkout - $ 977
Test and Integration - $ 7,136
Extrapolating these figures into 1982 with an inflation rate of 10 percent per
year we can show that an error in the requirements definition phase which
costs $380 to fix would cost $13,906 to fix in the Test and Integration phase.
The JLC tri-service standards have been subjected to a broad industry and
government review. Between now and the end of the year comments will be
incorporated into the drafts and the formal process of coordination will take
place. We hope to start using the products in 1983, and believe it feasible
to use the drafts even earlier.

SUMMARY.
The JLC and the CSM are not sitting still resting on past laurels. In June of
1981 a second workshop, termed Monterey II, was conducted. While in part the
workshop reported on the implementation status of the ongoing effort of the
CSM, other issues were studied. Five panels looked at Documentation,
Hardware/Software/Firmware Configuration Item Selection Criteria,
Standardization and Accreditation of Computer Architectures, Estimating
Software Costs, and Software Rouseability. A report was produced and some
follow-on actions are planned.6 Specifically, Hardware/Software/Firmware
Selection Criteria will be studied and the CSM will prepare a Software Cost
Estimating Guidebook.

The CRM is working an area that is important to the JLC's and one that
can benefit fromn increased services cooperation from technology to management.
Past accomplishments, notably the preparation of the new DOD Directive
5000.29, attest to the success of CRM activity. With the introduction of the
tri-service software policy and standards an important milestone will be
reached--for the first time the DOD will have achieved commonality of practice
in a critically important systems area.

215
 CD~

LUL

~LJ
LJ Lu I.- i= CeD

CSCD

21!~

IIN

__ CaC.

cm

L-U
UJ I-
cr- cn 2

~
4ce ~ 00%5 a

216=

L~i~.k~MMUa A %'
 lic (-VC2u

L)Z z 0

0z

0.C

00
UL
I.-.
w=

oi

LL
oZ
4c

-, Ze

ILI

217S
 DEFINITIONS

SRR System Requirements Review

SOR System Design Review

SSR Software Specification Review

PDR Preliminary Design Review

CDR Critical Design Review

TRR Test Readiness Review

SSS System/Segment Specification

SRS Software Requirements Specification

IRS Interface Requirements Specifications

STLDD Software Top Level Design Document

STP Software Test Plan

SDDD Software Detail Design Document

IDD Interface Design Document

DBDD Data Base Design Document

STD Software Test Description
STPR Software Test Procedures

SPS Software Product Specification

STR Software Test Report

FQR Formal Qualification Review

PCA Physical Configuration Audit

FCA Functional Configuration Audit

2VB
 REFERENCES

1. Joint Logistics Commanders: Proceedings of the Joint Logistics Commanders

Joint Policy Coordinating Group on Computer Resources Management, Computer
Software Management Subgroup Software Workshop; 21 Aug 1979; NTIS AD 103485.

2. Department of Defense: Draft Embedded Computer Resources Standardization

Program Plan; Directorate, Defense Material Specification and Standards
Office, Falls Church, VA 22041; June 81.

3. Wolverton, Ray W.: The Cost of Developing Large-Scale Software, 1977

Annual Software Life Cycle Management Workshop; Aug, 1977, pp. 131-152; DTIC
AD-A053014.

4. Joint Logistics Commanders: Proceedings of the Joint Logistics Commanders

Joint Policy Coordinating Group on Computer Resources Management Computer
Software Management Subgroup Second Software Workshop; 1 Nov 1981; NTIS ADA
109441.

1%

0!

219

~ ~ AXA~WVC~ AX* -.
 MANAGING TACTICAL EMBEDDED COMPUTER RESOURCES (TECR)

IN THE NAVAL SEA SYSTEMS COMMAND

J. C. Stewart

4 and

T. L. Wallis

Naval Sea Systems Command

Washington, D.C. 20262

(202) 692-8204

Abstract

The Naval Sea Systems Command (NAVSEA) is charged with cradle-to-grave

support of over 300 separately nomenclatured TECR items, employed in virtually
all combatant classes to support signal processing, communications, naviga-
tion, and command and control. The wide variety of equipment supported, and
variation in the requirements of over 150 different users poses a significant
management challenge.

This paper will address the challenges associated with the management of
TECR in NAVSEA, the techniques used to meet these challenges, and some of the
lessons learned.

INTRODUCTION

Experience has confirmed that standardization of Tactical Embedded Com-

puter Resources (TECR) results in the improved operational availability of de-
ployed US Navy systems because of the commonality of spare parts and the
availability of trained maintenance personnel; for similar reasons, hardware
standardization reduces overall system life cycle cost. However, the limi-
tations of current TECR may result in increased system life cycle costs for
the following reasons:

a. A more complex system architecture is needed to overcome performance

and capacity limitations.

b. Complex software designs are necessitated by the complex system arch-

itecture, thus adding significantly to software support costs.

c. Nonstandard computers are often needed to meet user system require-

ments resulting in higher costs for acquisition, maintenance, and logistics
support. This practice also results in proliferation of nonstandard program-
ming languages for software development and invariably increases software life

221
1RVOS A1~i

~ '~ 'I % % S.%

 cycle support costs.

To realize the benefits of a standards program, the Chief of Naval

*Material (CNM) has initiated policies and procedures covering all aspects of
the use of embedded computer resources in Navy systems. They have been pro-
mulgated in the form of CNM Tactical Digital Standards (TADSTANDs), instruc-
*tions and notices, military standards, and letter directives/guidance as
appropriate.

Further, the Navy has embarked on a major program to develop and acquire
state-of-the-art successors for the AN/UYK-7, AN/UYK-20, and AN/UYS-1 stan-
dards. The replacements will be capable of meeting embedded computer system
requirements into the 1990s. As successor computers are developed, the Navy
must take advantage of technological advancements on a competitive basis,
while maintaining the significant investment in support and operating soft-
ware. In addition, as the Navy improves upon and replaces standard embedded
computer resources, technology upgrades must be introduced in a controlled
evolutionary manner to best meet Fleet requirements.

BACKGROUND

In the 1950s, most of the computers used aboard Navy ships were special-
purpose, analog computers designed to solve specific information-flow pro-
blems. In 1958, the Bureau of Ships designed a solid state shipboard digital
computer to handle and manipulate the operational data that had previously
been disseminated and displayed manually. This was the start of the Navy
Tactical Data System (NTDS). These computers were complete units as they
stood and could be configured in variable quantities to meet the differing
mission profiles of several classes of ships. Most of the initial NTDS com--
puters (CP-642) are still in the Navy inventory today.

From this modest beginning, the spread of the digital computer aboard ship
proceeded rapidly, first with the expansion of NTDS and then into many other
shipboard systems. By 1970 it was recognized that a proliferation of dif-
ferent types of digital computers in the Navy would have to be controlled in
the interest of efficiency in logistics, training, reliability and maintain--
ability, configuration control, system interoperability, and software suppor-.
As an initial effort, the AN/UYK-7 computer, the CMS-2 High Order Language
(HOL), and certain NTDS operator consoles were designated as standards. Thf
was followed by the competitive acquisition of a standard minicomputer
- a (AN/UYK-20), cartridge magnetic tape unit (AN/USH-26), Alphanumeric display
(AN/USQ-69), computer display set (AN/UYQ-21) and the development and control
of standard HOL compilers and other support software. Standards were also d,?-
veloped and promulgated for embedded computer systems software documentation
and quality assurance in SECNAVINST 3560.1 and MIL-STD-1679. These steps
provided an initial respite from the proliferation problem. In recent years
additional action has been taken to strengthen the Navy's management of Tact'-
cal Embedded Computer Resources (TECR).

In 1978,the Chief of Naval Material established the Tactical Embedded C-

puter Program Office (TECPO), MAT 08Y, as the NAVMAT program Tsnager for er
bedded computer resources in the Headquarters, Naval Material Command. ir
"Q.MA OSY assutxmd the additional policy and standardtzRtl- %n'"
',rmer Tactfral Digital Systems Office (TADSO), MAT 09Y . .

222
the Deputy Chief of Naval Material for Acquisition [DCNM(A)j, MAT 08Y is the
Navy's Principle Development Activity (PDA) for research, development and
acquisition of standard embedded computers, support software, and related
digital equipment. MAT 08Y is also responsible for establishing NAVMAT
policies concerning development and use of embedded computer resources, as-
signing SYSCOMS as Development Activities (DAs), controlling budget resources
for standard embedded computer resource R&D projects, and appraising project
results.

The Navy Shipboard Tactical Embedded Computer Resources Project Office

(PMS 408), in the Naval Sea Systems Command, was formally established by
NAVSEA Instruction 5400.59 on 14 November 1979. PMS 408 is the Development
Activity responsible to the CNM for development, acquisition and life cycle
support of standard embedded computer resources assigned to NAVSEA by MAT 08Y.
This currently includes the AN/UYK-43 and AN/UYK-44 computers (successors of
the AN/UYK-7 and AN/UYK-20 computers) and associated support of software;
acquisition, configuration control and life cycle management of existing and
future computers and peripherals for shipboard applications; and implemen-
tation of Ada (DOD standard HOL) for Navy use. PMS 408 responsibility also
includes commodity management functions for the AN/UYK-7 and AN/UYK-20 stan-
dard computers and associated support software, and all standard shipboard
tactical displays and peripheral equipment. Development Activity responsibil-
ity for the AN/UYS-2 Enhanced Modular Signal Processor (EMSP) has also been
assigned to PMS 408. The PMS 408 Project Manager reports directly to the De-
puty Commander for Combat Systems (SEA 06) who has the designated authority
and responsibility for shipboard embedded computer systems.

POLICY/PHILOSOPHY

It is Navy policy to require the use of designated standard TECR unless

use of a nonstandard can be shown to be in the best interest of the Navy.
Presumably this means that if the designated standard TECR cannot compete in
the DOD marketing arena, its use will not be required. NAVSEA, therefore, has
adopted an operating plan of expending its efforts towards ensuring that Navy
standard TECR is competitive rather than acting as a policeman for Navy
policy. Figure 1 shows the types of effort which must be expended to support
the user of a Navy standard during the four phases of his system. If the sup-
port provided in any phase is inadequate, then the user has legitimate cause
to pursue the use of nonstandard products.

INFORMATIONAL SUPPORT

The chances that a given system will not use a standard product is
greatest during the conceptual phase of the program, and once that decision is
made it becomes virtually impossible to change that decision later due to
"sunk costs." Programs may choose to use nonstandard equipment for any of the
following reasons:

a. An unawareness that policy applies to him: The advent of the micro-

processor has resulted in the automation of many systems outside the tradi-
tional electronics and weapons area. For instance, controllers for aircraft
elevators and missile tube environment now use embedded computer resources.
These project offices have no prior experience with TADSTANDS and are somewhat
incredulous at the idea that TADSTANDS are applicable to them.

223
 0

cc
U

>4

I
m

PU0

I>ICC
co - --

iU
wwOE
-

00 >>xco'

I.

uus
& X~
OIL
ju cc I

lu 0

m 0.2L
 b. A lack of awareness regarding the capability of Navy standards: Many
projects simply do not know what the performance characteristics are for Navy
standards. There is a general belief that standards must cost more since they
are general (vice specific) in nature, or are unable to meet commercial
performance standards.

c. A lack of awareness of the hidden cost of using nonstandards: During

the conceptual phase, system requirements tend to be "pie-in-the sky" and de-
mand the use of future technology. In many cases, standards are dismissed out
of hand as being of obsolete technology and unable to meet planned or per-
ceived requirements. During the development phase, as a result of production
delivery requirements, there is a tendancy to utilize the readily available
current technology. An explanation of the added ILS costs associated with the
use of a nonstandard may hasten this retreat to the real world.

The support, therefore, which must be provided during the conceptual phase
of a project is largely educational. Users of embedded computer resources
must be made aware of policy. They must be made aware of standard TECR per-
formance capabilities, and, finally, they must be made cognizant of the
logistics cost penalty associated with using a nonstandard TECR. At present
the three major mechanisms used to provide information to users are listed as
follows:

a. As part of the course provided to NAVSEA employees on Integrated

Logistics Support, PMS 408 conducts training regarding the Navy policy re-
quirements and the logistics penalties associated with the use of non-
standards.

b. An annual Navy Standards Users Conference is held to determine future

users' requirements and to acquaint users with plans to improve or introduce
new standards. The next conference is planned for Spring 1983 in Washington,
D.C.

c. Harketing by Navy TECR suppliers is often the most effective edu-

cational method. If a potential DOD user's prime contractor can be convinced
that the use of a standard TECR is in his best interest, it is not too dif-
ficult to convince the potential user.

The introduction of the AN/UYK-43 and AN/UYK-44, with the attendant high
visibility competition, transition planning requirements, and competing market-
ing organizations, has significantly raised the awareness of TECR policy in
the Navy.

DESIGN SUPPORT

The functions which must be provided under design support can be cate-
gorized into two areas, Project Design Support and TECR Design Support.

a. Project Design Support: New standards developments such as the

AN/UYK-43, AN/UYS-2, AN/UYK-44 MRP and the Ada language, will have significant
impact upon how Navy Combat Systems are designed. In the past, the user was
presented with a package of installation control drawings for the hardware and
a user's manual for the software. In most cases that proved sufficient. How-
ever, there were some problems:

225

1. v I
 (1) Restrictions on memory, processor speed and I/O ports led pro-
ject managers to allow their contractors to program in assembly language in
order to reduce memory usage or to accommodate special timing or I/0 require-
ments. Although assembly language usage may allow more efficient use of
available memory and performance capabilities, it increases the complexity and
cost of programs during development and increases software maintenance costs
throughout the system's life cycle. Further, unless your programmers are very
experienced, you may well pay an efficiency penalty without realizing it.

(2) Interoperability among shipboard systems has often been con-

sidered as an after-the-fact element. As a result, costly modifications to
operational software have been required, and ad hoc solutions have been de-
veloped for intersystem digital communications. Protocols developed in such
situations have often been costly to implement and difficult to maintain and
extend for new interoperability requirements. Intercomputer bus communica-
tions and protocol standards must be established.

(3) Imperfect understanding of TECR capabilities caused poor system

designs, further hampering the user's ability to produce a viable, efficient,
cost-effective system.

The AN/UYK-43, AN/UYK-44, and AN/UYS-2 TECRs provide a solution to the

first of these problems by their very nature, and a potential solution to the
second because of their flexibility and design for growth. However, they also
enhance the opportunity to make design mistakes. The necessity to provide
information and assistance to the user in his design efforts is well under-
stood. A critical portion of the Ada development effort will be the procure-
ment of a training package which teaches not how to code in Ada, but how to de-
sign based on Ada. The AN/UYK-44 MRP will have two technical manuals: the
traditional maintenance-oriented manual and an equipment designer-oriented
manual to facilitate its embedding. In the case of the AN/UYK-43, AN/UYK-44,
and AN/UYS-2, laboratories supporting the development of these equipments alsc I
provide support to major potential users. Finally, TECR contracts are de-
signed to provide technical engineering support upon request.

b. TECR Design Support: The march of technology is the most significant

challenge facing the Navy standards program. Many think that standardizatie",
and technological advancement are incompatible. While standardization com-
plicates the influx of technology into Navy systems due to the necessity to
meet new users needs without perturbing old users, these two objectives are
not mutually exclusive. The lack of prior planning and funding have caused
most problems in the past.

The shortcomings of the AN/UYK-7 and AN/UYK-20 computers were recognized

in the mid-70s. The lack of a continuing budget line following the initial
development precluded any action. Attempts to establish this needed fundin!'
for product improvement ran afoul of sole-source problems resulting in the
competitive procurement of the AN/UYK-43 and AN/UYK-44. This is not to say
that there is anything wrong in the procurement of this new equipment, how-
ever, improvements to the AN/UYK-7 and AN/UYK-20 were delayed pending the
introduction of their successors.

The AN/UYK-43 and AN/UYK-44 will not eliminate AN/UYK-Ts and ANtYK-''
riot economically feasible Lo replace some 4500 cxs4s.tii ",

226
 -- - -- ----.--
--..- - -.- :- - -w'~-r ~ - ~-

Future improvements to the AN/UYK-7 and AN/UYK-20 will be the cost-effective

method of meeting the emerging requirements of systems which utilize the cur-
rent standards. However, funding remains unbudgeted for this effort. It is
expected that transition planning results will provide the justification
needed to obtain these funds.

Similar problems with the AN/UYK-43 and AN/UYK-44 will, hopefully, be

avoided. Funding is currently budgeted to begin definition of successor com-
puters, and funding has been requested to provide for preplanned product
improvements.

The designer of TECR is constantly on a knife edge. He must choose

between the newest technology and potential impact upon existing users. Thus,
the initial design of the TECR must be sufficiently flexible to allow the in-
fusion of state-of-the-art technology without impact to existing systems and/
or their software. In the case of the AN/UYK-20, the Navy has had great suc-
cess in ensuring modifications which are upward compatible, less so with the
AN/UYK-7. This relative degree of success reflects a difference in the
modularity of the design with respect to growth. The AN/UYK-43 and AN/UYK-44
are specifically designed to capture existing software and a major concern of
design reviews was to ensure that the flexibility existed to insert future
technology.

ACQUISITION ENGINEERING SUPPORT

The TECR commodity manager must ensure that users are delivered the equip-
ment they require in a timely manner. Further, he must ensure that cost to
the user remains relatively stable with increases being lilaited to inflation.

a. TECR Availability: TECR are procured through firm fixed price, pro-
duction requirements type contracts. In many cases the contracts cover
multiple years of procurement. This means the contractor is required to
deliver an unspecified quantity of equipment over the life of the contract.
Normally, delivery is required within a specified time after an order is
placed. To date no contractor has defaulted with respect to a delivery. When
the product is delivered late it is the result of Navy problems. In many
cases, the user waits until the llth hour to place his order. Sometimes this
is beyond his control, but the result is still such that it is impossible to
meet his needs. The delivery times, After Receipt of Order (ARO), for the
AN/UYK-7 and AN/UYK-20 computers are approximately 12 months and 6 months
respectively - extremely good for a DOD procurement action, but a finite time
none-the-less.

Another reason which causes an inability to meet a required GFE date

results from delays introduced in cost negotiations which preclude the placing
of the order in a timely manner. This occurs when contracts come up for
extension.

b. TECR Costs: Standardization leads to a sole-source situation. This

does not necessarily mean that TECR costs could be significantly reduced by
open competition. There are other factors involved which tend to limit inter-
est in TECR contracts, primarily the fact that off-the-shelf commercial equip-
ment is not acceptable. The AN/UYK-43 and AN/UYK-44 were open competitions,
yet only two contractors chose to bid. TECR costs are controlled through the
contract negotiation process. The initial competition for the contract pro-
duces reasonable base prices. By requiring the contractor to justify

227
increases over this price in the negotiation process, unreasonable cost in-
creases are prevented. Of course, these negotiations are not always easy, and
delays in the delivery of GFE can occur. The object, therefore, has been to
reduce the number of negotiations which must take place.

Our oldest standing contracts have been for AN/UYK-7(V) computers and for
tactical displays. These contracts must be negotiated yearly and are highly
dependent on quantities being procured. Therefore, fluctuation in user re-
quirements affect build rate and thus cost; thereby making these contracts
very difficult to negotiate. The AN/UYK-20 contract, on the other hand, is
fixed on a five-year cycle. The first two years are bid and negotiated at a
fixed price with automatic adjustment factors for inflation and ordering
quantities. These adjustments are always for future orders and never retro-
active to existing orders. At the end of the first two years, prices are re-
negotiated to adjust for any factors not taken into account by the automatic
features, and then a fixed price is set for the remaining three years of the
contract. At this point the cycle is repeated. The AN/UYK-43 and AN/UYK-44
contracts are patterned after the AN/UYK-20 contract.

IN-SERVICE ENGINEERING SUPPORT

The In-Service Engineering Support function can be described in two words:

Correct and Control.

a. Correctional Support: The use of TECR is predicated on the proposi-

tion that it improves system availability, reliability, and lowers cost. Pro-
gram Managers tend to be skeptical of these claims. Thus, any problems whirh
occur are blown out of proportion. It is vital to the success of the Navy's
standardization policies that rapid and effective correctional action be taken
in response to reported problems. The early AN/UYK-20s suffered greatly fro,
intermittent problems. Analysis indicated these problems resulted from the
design of some circuits improperly accounting for worse case situations and
the lack of sufficient margins testing. The designs were corrected and im-
proved testing procedures were implemented, but, most important, the defict,-r
units were replaced at no cost to the users. This example demonstrates the
type of support which must be provided. Unfortunately, the Navy's ability
provide this type of support for all TECR does not exist.

By NAVSEA charter, PMS 408 is tasked with providing equipment-level en-

gineering support in the following areas: design, safety, test support,
technical documentation, performance and maintenance data analysis,
maintenance engineering, installation, fleet engineering support, training
manning, integrated logistics support, configuration management, data
management, test equipment supply support, and repair facilities. To
accomplish this task, NAVSEA requires personnel resources far exceeding its
headquarter's staff, specifically an In-Service Engineering Agent (ISEA).
ISEA's, however, do not work without pay and no funding line exists for the
life cycle support of TECR.

How, then, has the Navy's TECR standards program managed to survive the
past decade? The answer is fairly simple. Major system userpt have assuu,'
equipment-level support engineering functions and contractor support has ,-
bought within the funding provided for hardware procurc e,*. ...
" :on significantly undermines the logistics savings ac. ,ve,

228

NN .......... IWAVSi i" I i li

TECR standards. The latter becomes impossible when the equipment is no longer
being sold. The establishment, therefore, of a life cycle support funding
line for TECR is the highest priority for PMS 408.

b. Control Support: The TECR manager must provide for the users a pro-
duct which is stable and cannot change without their knowledge and approval.
Any process implemented must be sensitive to the potential of causing cost in-
creases on user systems. Conversly, the process cannot be so rigid as to
preclude the injection of new technology to meet the requirements of new
users.

The consolidation of life cycle responsibility for shipboard TECR products

into one NAVSEA systems command organization has assisted in configuration man-
agement of TECR by allowing the establishment policy and a set of standard
procedures for the communication and coordination of CM within the entire com-
munity of TECR users. It has facilitated the review of requested engineering
changes to ensure that all aspects of impact are considered including mainte-
nance, training, software, and other TECR configuration items.

The establishment of a rigid standard policy on when to approve an en-

gineering change is impractical. Each request must be considered on its own
merits. General guidelines include:

(1) The change should be upward compatible or implemented as a non-

mandatory change.

(2) The change should be of demonstrable benefit to performance,

maintainability, or reliability.

(3) The change should benefit more than one user.

The approval of engineering changes based upon the desires of only one
user should not be undertaken even when the user is willing to fund the
change. Since these changes are not likely to be purchased by other users,
the result is a unique configuration which not only results in increased life
cycle cost, but produces no general benefit to the Navy as a whole. When a
user's requirements cannot be met by a design which is beneficial to all
users, or the user's requirements cannot be adjusted to meet the common de-
sign, then it is appropriate to use a nonstandard. In the past it has not
always been possible to separate the greater benefit from the individual user
need because the individual user has been funding the development or mainte-
nance of the TECR. The establishment of sound configuration management re-
quires the TECR agent to be financially independent of the user project.
While NAVSEA has achieved this goal in the development of the AN/UYK-43 and
AN/UYK-44, the Navy's inventory of standard displays and peripherals also re-
quires updating. The identification of a first user or group of first users
wii! assist in achieving the needed redevelopment funds, however, control of
the funds must continue to be placed in the engineering hands of a single TECR
cmumodity manager to ensure that standardization objectives are met.

229
SOFTWARE LIFE CYCLE SUPPORT

When the first Navy solid state general purpose digital computers were
introduced, hardware costs still outweighed software costs. The result has
been a slower recognition of the advantages of and the need to provide stan-
dard support software to reduce system software development and maintenance
costs. The support software that PMS 408 manages can be classified as Compile
Time and Run Time.

a. Compile Time Software: This classification, by PMS 408 definition,

includes compilers, editors/librarians, system generators, simulators, debug-
gers, and some utility software. It is this software that is used to generate
applications software. In the early 1970s, the Navy developed an interactive
real-time program generation system, known as Share-7. It executes on the
AN/UYK-7, the target computer for the software it generates. This develop-
ment, in its time, represented a major step forward from the batch processing
program generation centers that it replaced. However, Share-7 still suffers
some major drawbacks:

(1) It can only run on the AN/UYK-7. Since most contractors do not
own this host, it is a GEE cost to the user.

(2) Contractors do have extensive commercial computer program

generation facilities. Their personnel are familiar with the use of these
commercial systems and therefore, requiring the use of Share-7 often involves
an extensive learning experience.

(3) The tools available to assist programmers on commercial systems

tend to stay a step ahead of those on Share-7 because of industrial
competition.

Concurrent with the introduction of the AN/UYK-20, the Navy took an-
other step forward with the introduction of Machine Transferable AN/( ) Sup-
port Software/Medium (MTASS/M). This set of program development components
is transportable across a wide range of commercial computers. This then al-
lows contractors to utilize the development support environment with which
they are familiar and to utilize the tools they have available on these sys-
tems. The MTASS/M system is being upgraded to support the AN/UYK-44. An
MTASS/L system is being developed to support the AN/UYK-43 and AN/UYK-7.
Machine Transferable AN/( ) Support Software/Large (MTASS/L) will have the
same attributes as MTASS/M with one addition. Those features of the system
which are unique to the host computer are being developed as a set of Common
Interface Routines (CIR). This provides two benefits: first, the rehosting
time has been reduced from several weeks to a few days; and second, by
following the CIR interface specification, the user can add to the MTASS/L
system any special tools he feels necessary for his development. Once the
MTASS/L CIR designs are tested, they will be incorporated into MTASS/M.

b. Run Time Software: Run time software consists of executives, oper--

ating systems, and utilities. Here again, the predominance of hardware in ..
mind of the Navy has caused problems. In the 32-bit world, the hardware wa
developed and released before any standard run time software was avalUable.
The result has been the multiple development of executives are operarin-
le',. Learning from experience, the AN/UYK-2C had a s'4vida ....

230

,-',n ?7,c w', '

-. *NL'Iv.
--Z"
U, ',-- ., .,*."
available on release (SDEX-20). This executive is in use on over 100 systems.
A second standard executive now exists as a result of competitive procurement
to support the AN/AYK-14. This newer executive (SDEX-M) is the currently pre-
ferred executive and to this end, as part of the AN/UYK-44 upgrade, it has
been restructured to better allow the user to build an operating system around
it. The lack of a 16-bit operating system has prevented the 100 percent ac-
ceptance and use of the 16-bit standard executives. While it was intended to
provide a CMS-2 operating system for the AN/UYK-43 and AN/UYK-44, this funding
has now been diverted to develop an Ada based system.

THE FUTURE

Two major issues face the Navy's Shipboard Tactical Embedded Computers
standardization. In the near term, the Navy must come to grips with trans-
ition from current standards to planned standards. In the longer term the
Navy must establish a policy with respect to the control of microprocessors.

a. Transition: Navy planning calls for all tactical systems requiring

standard computers after FY83 to use the AN/UYK-43 or AN/UYK-44 or to submit
justification as to why the continued procurement of AN/UYK-7 or AN/UYK-20
computers is required. At no time has the backfitting of current AN/UYK-7 and
AN/UYK-20 computers been a consideration. In consonance with this line of
reasoning, there exists four reasons why transition should take place:

(1) Accommodate expanded operational requirements.

(2) Improve Reliability and Maintainability.

(3) Achieve significantly lower life cycle costs.

(4) Avoid logistics obsolescence.

For tactical systems that currently use standards, the issue of a short-
fall in capacity to meet operational requirements is the only true motivator.
The cost of logistically maintaining a tactical system with two different com-
puter configurations outweighs any economic benefits that might be achieved by
transitioning to the new computers in mid-project.

It is hoped that Navy planners will accept the fact that procurement of
AN/UYK-7s and AN/UYK-20s will continue into the late 1980s, and will provide
the resources necessary to refurbish and maintain these computers until their
true operational demise in the 21st century.

b. Microprocessors

The AN/UYK-44 Militarized Reconfigurable Processor is the low end of the

Navy standards product line. It is not a microprocessor. In today's tech-
nology, microprocessor-based systems can be designed and built that will out-
perform the AN/UYK-44 and, at the same time, will cost less. The distributed
design of these systems with microprocessors performing small dedicated tasks
makes the use of the AN/UYK-44 impractical. This is not a condemnation of the
AN/UYK-44(V). It does mean that a substantial hole remains in the Navy

231
Standards Program. A significant penalty is being paid in software develop-
ment and maintenance costs because no effective policy exists for micro-
processor applications.

It has not yet been fully ascertained whether microprocessors represent

only a software cast problem or pose a logistics problem as well. If the
problem is purely one of software support costs, then the answer lies in Ada
program support environmental development in conjunction with the accredi-
Set Architecture (ISA). At the present time, the concept of "accreditation"
has not been accepted because it does not resolve the logistics supportabil-
ity, maintainability, and training issues faced by the current and planned
Navy TECR. However, these problems tend to be eliminated or are significantly
reduced when the processor element is confined to a single replaceable unit
that is so reliable debilitating failures seldom if ever occur and the unit is
inexpensive enough to be discarded when such errors do occur.

It is not clear that state-of-the-art microprocessors or TECR system de-

signs have reached the level required to say that the logistics aspects can be
ignored. However, the march of technology is certainly in that direction. In
the interim, the Navy requires a policy to control the proliferation of micro-
processors in deployed systems.

232
 - * .W.
W__ .?.o~o..7-

GLOSSARY OF ABBREVIATIONS

ARO After Receipt of Order

CIR Common Interface Routines

CNM Chief of Naval Material

DA Development Activity

DCNM(A) Deputy Chief of Naval Material for Acquisition

DOD Department of Defense

EMSP Enhanced Modular Signal Processor

HOL High Order Language

ILS Integrated Logistic Support

ISA Instruction Set Architecture

ISEA In-Service Engineering Agent

MRP Militarized Reconfigurable Processor

MTASS/L Machine Transferable AN/( ) Support Software/Large

MTASS/M Machine Transferable AN/( ) Support Software/Medium

NAVMAT Naval Material Command

NAVSEA Naval Sea Systems Command

NTDS Navy Tactical Data System

PDA Principle Development Activity

R&D Research and Development

SYSCOMS Systems Commands

TADSO Tactical Digital Systems Office

TADSTANDS Tactical Digital Standards

TECPO Tactical Embedded Computer Program Office

TECR Tactical Embedded Computer Resources

233
-- I

ML-STD-1589

JOVIAL (J-73) HIGH ORDER LANGUAGE

*SESSION CHARMAN: Donna K. Gant

General Dynamics Corporation

MODERATOR: Me vin R. Barlow

VP & General Manager of General Dynamics
Data Systems Division

| PREVIOUS PAGE m '

 JOVIAL STANDARDIZATION

Austin J. Maher

The Singer Company-Kearfott Division

150 Totowa Road
Wayne, New Jersey 07470
(201) 785-6607

ABSTRACT

MIL-STD-l589B defines the JOVIAL (J73) high order

programming language, the most recent dialect of a long
line of AF languages in the JOVIAL family. Some highlights
in the development of the JOVIAL language family and J73
in particular are reviewed as an introduction to this
session.

At the present time, the J73 language is the only AF

standard language for embedded computer systems. Some
technical highlights of the language are presented as well
as a review of its current use in AF systems. The key role
played by the JOVIAL-Ada Users Group (JUG) in the evolution
and use of J73 is reviewed as well as the procedures for
handling proposed language changes and compiler validation.

With the apparent imminent availability of Ada*, some

have questioned the wisdom of continued JOVIAL development
and use. To help clarify this situation, the relationship
between JOVIAL (J73) and Ada is discussed in the framework
of the recently released AF plan for phased introduction of
Ada as the replacement for its current standard language, J73.

INTRODUCTION

Dialects of the JOVIAL Language have been in use for

computer software embedded in USAF weapon systems for over
twenty years. At the present time, the JOVIAL (J73) language
has been designated by the Air Force as the preferred imple-
mentation language for all operational weapon delivery
software. As such, it is one of only seven high order
languages accepted by the DoD as standard languages during
this pre-Ada time period. This paper reviews some features

*The Ada Joint Project office asserts that Ada is a registered

trademark of the U.S. Department of Defense.

237
IpltEvIOUS PAG r

Iv I%*
INTRODUCTION (Continued)

of the JOVIAL family of languages and highlights of their

development. The role of JOVIAL as a precursor of Ada will
also be covered. Subsequent papers will cover development
of the J73 dialect, and its use in current systems and
associated software support tools.

HISTORY

The origin of the JOVIAL programming language family

dates back to the early 1960's. The name "JOVIAL" is a rather
curious acronym representing: Jules Own Version of the Inter-
national Algebraic Language, where "Jules" refers to Jules
Schwartz, one of the language's principal original designers.
The International Algebraic Language was Algol, of course,
and the influence of this block-structured language has been
felt in all subsequent JOVIAL language dialects.

Many dialects of the JOVIAL Language were developed in

the 1960's. Probably the most widely used one being J3,
which was adopted by the AF as a standard language for
Command and Control applications (MIL-STD-1588).

In the early 1970's, two new dialects were developed.

The Rome Air Development Center (RADC) conducted a study
which culminated in the development of a much expanded
dialect of JOVIAL designated as "J73". A simplified sub-
dialect of this language (J731) was subsequently implemented
and used for the DAIS project at WPAFB. The full "J73"
language was never implemented, falling victim to its own
size and complexity.

At the same time, the B-1 avionics project was getting

under way. Prior projects of this type had typically been
implemented in Assembler language, due to the high efficiency
requirements of the avionics environment. Since both the AF
SPO and Boeing, the responsible contractor, were convinced
that the use of High Order Language (HOL) for avionics was
long overdue, and since their schedule did not permit waitinc
for the results of the "J73" committee's deliberation, a
JOVIAL compiler was developed by Boeing and SofTech for the
SINGER-Kearfott SKC2070 computer based upon an adaptation
of J3. It was designated J3B. This pioneering use of HOL
for avionics was eminently successful and the J3B language
was subsequently used successfully to implement the F-16
Central Avionics Software on a Delco computer and the B52G
Offensive Avionics Software on an IBM computer. JOVIAL (J3B)
appeared to be on its way to becoming the de facto standard
for large AF avionics projects.

At this point (approximately 1976), the DoP Pich "> e-

>-.iguaq- Working Group (HOLWG) issued Directiv
it proliferation of different HOL's in we.,

238
 11L7i-- a. 77 *.lll . . -

b
HISTORY (Continued)

The list included two JOVIAL dialects: J3 and J73. Since

the full IIJ7311 language had never been implemented, the AF
for B-1, F-16, and B-52G) with the best features of J731
(used for DAIS) and to call the result J73*.

This was very effectively accomplished with the support

of many industry representatives who united to form the
JOVIAL Users Group (JUG) for this purpose. The resulting
language has been widely implemented and has since become
the only JOVIAL dialect permitted by DoD Directive 5000.31
(supplanting J3 in a recent update). The JUG organization
proved to be such an effective vehicle for communication
between the AF and inaustry on embedded computer software
issues that it continues to be a viable entity, recently
changing its name to the JOVIAL-Ada Users Group (JUG) as4
its scope expanded to address the introduction of Ada which
will eventually supercede and obsolete JOVIAL (J73).

For further detail on the development of the first J73

compilers, see the paper by J. Pepe in this session.

JOVIAL LANGUAGE FEATURES

While JOVIAL language dialects differ from each other

in some features, the JOVIAL family resemblance is provided
by certain features which are typically common to all JOVIAL
compilers. The principal JOVIAL family characteristics are
outlined below:

0 COZ4POOL - From the earliest dialects, JOVIAL

languages have contained a COMmon POOL of
information to be shared among subroutines.
This CO!4POOL may contain shared data and
shared subroutine definitions. This permits
JOVIAL compilers to check type consistency
between subroutine argument definitions and
their invocation.
0Strong Typing - The type of a JOVIAL data nameI
must be explicitly declared and its precision
(minimum word length) can be stipulated. J73
permits a wealth of data types including: -
floating values, signed and unsigned integer
values, fixed values, bit strings, character
* strings, status values, and pointers.

*In this paper, J73 refers to the modern JOVIAL dialect -

defined by MIL-STD-1589 A and B, while "J73" refers to the
language defined by the RADC committee in 1973 (approximately).

239
 . . .. . ... . . . . . . . .......... " '" .. ".. .. """""""

JOVIAL LANGUAGE FEATURES (Continued)

o Rich Data Structures - The memory layout of

data can be explicitly defined in JOVIAL and
complex tables of data can be defined to
represent vectors, matrices, arrays, etc.
J73 permits tables and blocks to be defined.

o No Hardware Dependent Facilities - JOVIAL

dialects typically have no provision for
input/output or interrupt handling. It is
presumed that these capabilities (which are
strongly dependent upon the target computer
hardware) are provided by procedures written
in assembler language with an interface which
permits their invocation as JOVIAL subroutines.

o Status Type - A non-numeric representation is

permitted for variables which distinguish between
a finite number of states, an early predecessor
of the enumeration data type in Ada.

o Separate Compilation - Subroutines may be

separately compiled. There are two types of
subroutines, procedures which are invoked in
a call-statement and functions which return a
value and are invoked in a formula (expression).

o Block Structured Flow Control Facilities.

The J73 dialect, faithful to its lineage, contains each of

these generic JOVIAL characteristics. For a complete definition
of the language see MIL-STD-1589B.

JOVIAL VS ADA

The energy devoted by the AF to JOVIAL in recent years

has been perceived by some as a dilution of effort that might
be better spent on Ada-related activities. Some even perceive
J73 as a competitive language to Ada with some potential for
undermining Ada's support. Is Ada therefore threatened
by JOVIAL?

Occasional attendance at the quarterly JUG meetings

should convince any observer that this is far from the case.
That segment of industry which engages in the use of HOL's
for embedded computer systems is clearly united in the drive
to eliminate the proliferation of languages used with embedd.''
-* computers. Moreover, many of those user organizations suppor
all the DoD services, so a single DoD-wide language is much
preferred over service-dependent "standards". T-''i int.-usion
of a number of powerful new language features in Ada (wbicl.
iriise to facilitate the developrment of more ,r
-tdable code) serves to further strenathur :...1,
iir attraction to Ada.

240
JOVIAL VS ADA (Continued)

More importantly, though, Ada language processors are

not yet developed to a level useful for embedded computer
systems. The J73 language processors have been developed
to fill this gap in timely fashion. Many projects are
currently under way using the J73 language which could not
have waited for Ada developments to be completed. A partial
list of such projects includes: F-Ill avionics update, F-16
avionics, DIS, LANTIRN, MRASM, MATE, MX, etc. So compilers
for J73 have matured (there are now at least four viable
suppliers) while the compilers for the more complex Ada
language are still in their gestation period.

Just as it took several years for the JOVIAL (J73)

compilers to mature, the Ada language processors can be
expected to have some growing pains also. This is espe-
cially true for avionics applications, where the reliability
and efficiency requirements are very stringent. Compilers
for avionic systems must incorporate object code optimization
algorithms which squeeze the utmost in efficiency out of the
target computer's architecture. Such algorithms are under-
standably complex and troublesome. Often they are being
refined for a year or more after the initial delivery of a
full working compiler.

Since the Ada language is even more complex than J73,

we can expect a similar (if not longer) period of refinement
before production quality compilers are available. In a
sense, the J73 development process serves as a preview of
the Ada development process. AFSC is determined to apply
all the lessons learned in the J73 developments to improve
the Ada development process. Toward that end, a four-phased
Ada Introduction Plan has been announced which introduces
Ada deliberately, not hurriedly, into AF systems. The intent
is to avoid the problems that a hasty introduction of the new
language would create, no matter how well intended. The four
phases have been identified as follows:

1) Laboratory Developments - Ada compilers and

tool sets are developed and used by AF
laboratories to gain initial experience
and develop the necessary tools.

2) Parallel Development - AF Product Divisions

choose project(s) whose software is developed
both in a mature language (such as FORTRAN 77
or JOVIAL J73) and in Ada, without introducing
any risk into the project since the Ada effort
does not detract from the original project plan.

3) Selected Use - Programs would volunteer to use

Ada to implement their operational software
with Headquarters making the final selection.

241

L.ZO"LK.Co4iii
l:-zzeo,&it,: ,
 JOVIAL VS ADA (Continued)

4) Mandatory Use - AT regulations would be changed

to discontinue the stated preference for J73
and require the use of Ada, unless a formal
request for waiver is approved.

Having learned from some of the more painful 373 experiences,

explicit criteria are defined for making the transition from
each phase to its successor. In short, Ada will not be
prematurely mandated onto a project before the necessary
maturity level has been accomplished. This prudent strategy
is a valuable legacy from the 373 era which promises that
the transition to Ada will be a smooth one.

CONCLUSION

The current AF standard language, JOVIAL (J73), is a

!worthy successor to the long line of JOVIAL dialects.
Developed as it was by distilling the best features of its
*predecessors, it undoubtedly is the most powerful member
of the family. While it will see widespread use in AF systems
over the next few years, it will be only a matter of time
before this JOVIAL dialect is superceded by Ada. thus
transforming this best JOVIAL Cialect into the last JOVIAL
dialect.

Mr. Kaher has been active In the field of avionics for

over 20 years. Currently, he Is the Manager of the Computer
Software vngineer~ng Departnent at the Kearfott 'ivision of
the SiUaER Ccp;any. 'iis epartent Is the focal point for
cc-puter software technology at Rearfott, fncludlng the
development of realtime software for avionic Froducts and
associated automatic test equipment, support softwire for
computer products an6 general purpose computa;ion facilities
for Engineering applications.
Recent activities have Included significant contributions
to the support of DoD standardization activities, Including the
AF standard architecture (NIL-S9)T-1Th0A). AF standard language
(MIL-STr-3589s) and the Ada standard language development.
SMr. Xaler was selected to participate In the Monterey Workshop
*sposored by the Cc-b-.uter Sztware F:age..ent zbrvup of the
loint Lors-,cs
Vcmputer M!anrcment.*Io~rit
Co%-a2nderz'
ne o4rce He rccently c, rieted aGroup
Folcy Coord~ating on
two ycar
tUrn as C,21r,.an of %..C .7V!-A'a V~ers tr' 3),a very
active s ncep lon of
S!ce ItoeCar.!:at4o-n ]-a Industry
197E. tbe and i.E~nt;rzie,;:ants.
JUG ties tt'-=;aed a high #vel
of co7.un~catior and cooperation anoag Its ;.arzle1ants on com;.u-.er
m software Etandard!:ation Initiatives.
Mr. Kaber received a Bs PhysicS degree from Roly Crcs College
and an MS Ccn.puter Science d Grce frzr. Stevent 2 tute of -ec .scogy.
the proferr'cnil
Hit affliations
Ada TEC. S)Gr'A and S-ICA --',cude the I. wttin Lhe so toclion
OrEaniat#on ec'cit- rnd
for Ccmputing Xachnery.

242
 MIL-STD- 1760

STANDARD STORES INTERFACE

SESSION CHAIRMAN: Claude Conmell

AD/DLJA
Eglin AFB

MODERATOR: Major Lewelen Dougherty

HO USAF/RDPV
 Opening Rem~arks and Air Force

Overview of MIL-STD-1760
by

Major L. S. Dougherty
(Session Chairm~an)

Armament and Avionics Division

Operational Requirements Directorate
DCS/PD&A
4., HO USAF, Washington DC

prepared for
MIL-STD-1760 Session

2nd AFSC Standardization Conference

Dayton Convention Center

1 December 1982

245 \osA fZ

% .,.* GE
 Good afternoon ladies and gentlemen. Before we get to the
detailed papers today I would like to review how we got to
where we are today and some of the assumptions that underlie

the current version of MIL-STD-1760. I will talk for a moment

about the kinds of questions that I am getting on the use of

the standard from both program offices and industry, and I will

tell you what questions I think we should be asking ourselves

about the future of MIL-STD-1760.

What Problem Were We Solving

First, I would like to answer the question "What problem

were we solving when we invented M4IL-STD-1760?0.

Back in the good old days of analog airplanes and analog

weapons, there was a need to optimize the aircraft-to-store

interface to minimize the cost of the weapon system. Signals

were unique to a weapon both in terms of voltage levels and

types of signals. Displays were unique to a combination of

aircraft and weapon, and the control of a weapon was unique to

a particular aircraft. It was occasionally possible to reuse

a power line or a discrete, but the basic architecture of the

avionics/weapon control system was so inflexible that adding

wires to an aircraft for each new weapon became a way of life.

Because of the uniqueness of a particular aircraft/weapon

combination it was almost impossible to do much effective

planning for future weapons other than simply running some

spare wires between accessible splice areas.

246

I)...
....
 -- : 7 -7-777%

7 8 :

The evolution of smart weapons increased the amount of

wiring required in an aircraft to near the limit of physical

space available. The wire bundle behind the F-4 wing leading

edge is a classic example.

Multiple adapters were required to make a particular weapon

fit on multipic aircraft types. This was a maintenance and

supply burden and a significant cost factor in some cases.

What Did We Decide To Do

It became clear to a few smart guys at Eglin and China

Lake that somebody needed to solve the general problem of
integrating new weapons with aircraft.

The first try looked at a single connector for all weapons.

The result was a huge connector with something like 500 pins if

It was to be 100% backward compatible -- clearly an unacceptable

answer.

An alternate approach took into account the evolution of

digital systems and multiplex technology, and limited the scope

of the problem to new weapons and new aircraft. The solution

that we settled on would put one new connector on existing

aircraft for all new weapons, and would require that only that

connector could be used on new weapon developments and new

aircraft developments.

247
 I
Under this approach, old interfaces would slowly disappear,
and after 15 or 20 years would he about as useful as tonsils,
at which time the old aircraft would be gone, hopefully replaced
with new ones.

What Have We Done?

The strategy that we pursued called for three phases:
In phase one, we issued a draft MIL-STANDARD that only
defined the signal set and basic wiring characteristics for the

interface. We found out that there was a need for an auxiliary

power connector for such things as ECM pods and external sensors
such as LANTIRN.
We included extra wires for wideband signals over and

above what was required for current systems. We built in

provisions for possible future growth to DC prime power and
fiber optics.
In order to meet the safety related requirement for two
independent series switches to activate critical functions, we
define the "critical store power" line.

This line, combined with a multiplex bus message, would

provide two independent means to enable critical functions.
Because the dual redundant multiplex bus is so flexible
and reliable, MIL-STD-1760 implicitly requires all discretes to
be sent over the multiplex bus -- the implementor can define
the way' the discretes are sent and the level of checking that i.P
accomplished,

248
 In phase two of our strategy for introducing MIL-STD-1710
we will add the connector specifications to the standard.

The insert arrangement has been agreed to and published as

annex 25-20 to MIL-STD-1760 (insert arrangements for MIL-C-

28999 and MIL-C-27599 electrical, circular connectors).

This insert arrangement has been reviewed by the nuclear

community who found no fault with it.

Eight other slash sheets for pins, sockets, and tooling

have been published including the triaxial pins for the 1553 mux

bus and the coaxial pins for both video and high bandwidth lines.

The fiber optic pins will be developed by PAVE PILLAR.

Notice 1 to MIL-STD-1760 which specifies the intermatability

characteristics of the common armament connection is in

coordination with approval expected by 15 December 1982.
Phase three of the MIL-STD-1760 introduction strategy

calls for the development and coordination of the logical

(functional) element of the STD which will define protocols and

common data formats for use of MIL-STD-1760.

International Adoption
MIL-STD-1760 has been proposed to NATO and to the Air

Standardization Coordinating Committee nations as a basis for

future air armament interopsrability.

249

* - S %~=
-. Wb ..V. S. -- . -- -- -. -- - --- j. - - - - - - - -- . . . . . . . .

Programs to use MIL-STD-1760

The Air Force has committed to putting MIL-STD-1760 on all

of our new weapons and retrofitting our aircraft as soon as possible.

Programs Using 1760

AMRAAM
LANTIRN adapter required
MRASM
30mm Gun Pod - in PMD
ASRAAM - NATO implications
WASP
CSW
SAW
F-15 - study complete
F-16
A-10 - study about to start
B-52
B-lB
Advanced Cruise Missile
Common Strategic Rotary Launcher - provisions for

Most Often Heard Concerns

In the course of normal business, I get some questions

about how to use and interpret MIL-STD-1760. It is probably

useful to go over some of the concerns for which I have answers.
Then I would like to show you a list of questions that need to

be answered.

Concern: There is not a requirement for all of the wires

called out in MIL-STD-1760.

250
 Answer: In the conventional sense you are right.
However, a lot of the very best (and by that I mean

far-sighted) people in the weapon and pod design

g. business feel that there is a high probability that

they will need all the pieces that make up the signal

set. This is not to say that one system would use it

all (though LANTIRN comes close) but that all of it

will probably get used.

Concern: How do I make provisions for fiber optics?

Answer: Since we don't have a spec on the fiber optic

cable, I would suggest putting in some small thin

wall conduit at those places where it would be

expensive to string fiber optic cable later.

Concern: We need more discretes!

Answer: The MIL-STD-1553B miltiplex bus that is part
of the standard is just full of discretes. Every
weapon I have looked at has internal digital logic

anyway - the real choice is between adding something

to the weapon to decade the bus, or adding wires to

the connector, aircraft, pylon, rack, etc., increasing

the size of the connector, and forcing the other

users to deal with another pin that they don't use.

251

. . , .
 ..7

Concern: The high bandwidth cable is too big.

Answer: Generally this is a misinterpretation of the

intent of the standard. There are coaxial cables

available that will meet the bandwidth requirements

and are less than one quarter of an inch in diameter.

They will not transmit a kilowatt of power, but that

was not why the 50 ohm and 75 ohm lines were included

in the standard. They were intended for relatively

low voltage and low power signals that were pre-

conditioned to drive the line.

Concern: How come the video lines are 75 ohm coax when

MAVERICK and GSU-15 use 91 ohm coax (triax)?

Answer: The mismatch between 75 ohm and 91 ohm cables

is too small to worry about for the video bandwidths

of MAVERICK and GRU-15. The NATO STANAG that covers

video displays requires a 75 ohm impedance, and

some of our current displays already have a 75 ohm

input impedance.

Concern: Do we have to put in the auxiliary power

connector at all store stations?

Answer: Not unless you expect to need it. Generally

the heavy weight carrying stations or those that

would carry ECM pods or sensor pods are good candidates. .

252

I2
.M

V \~~** ~ V
 Concern: Do we have to power all stations simultaneously
at full current load?
Answer: No. Whatever limitations exist in terms of

available current will simply have to he a constraint

on simultaneous operation of multiple stores. I view

it as similar to the situation in our office -- we

have one 20 amp circuit that feeds about 10 outlets.

)
We can operate three word processors on 3 outlets but

don't plug in a 10 amp heater at the sa'e time or

your will have a clotch of angry secretaries, a popped

circuit breaker and maybe even a messed up work

processor disk.
Now I have a short list of questions for which I have no answers.

How will the avionics system get access to data

on the stores management system multiplex bus?

How will video (RF) and power switching be controlled?

How many different video/RF channels will be needed

in a particular system and how will they be divided up?

How will MIL-STD-1760 be adapted to a future video bus?

How can the high speed multiplex bus be incorporated

into MIL-STD-1760?

253
 What is the story on subsetting?

How can weapons that must fit old aircraft with

existing interfaces be made to also fit aircraft

that only have MIL-STD-1760 interfaces?

Can some aircraft (like the F-4 and F-ill) use

existing wiring to implement parts of MIL-STD-1760?

How is the Air Force going to control MIL-STD-1760

and certify aircraft and weapons?

If anyone in the audience has any ideas, I will be available

after this session to discuss them with you.

254
• a-

a,
-. - - -. . .. .' z ..w zw . _ f U. ' _UX
. . -.- - - :_ .%

NAVY PERSPECTIVE ON MIL-STD-1760

PRESENTED TO THE SECOND AFSC DOD EMBEDDED

COMPUTER STANDARDIZATION CONFERENCE
(30 NOV - 2 DEC 1982)

BY GERALD E. KOVALENKO
NAVAL AIR SYSTEMS COMlAND
AIR-323B, RFM. 472, JF-l
AUTOVON 222-2522
WASHINGTON, D.C. 2036

Abstract

Prior to MIL-STD-1760, an aircraft and the stores which it carried were

typically developed independently of each other or were developed exclusively
for each other. This usually resulted in new aircraft/store electrical
interface requirements and the general proliferation of overall store
interface designs. The lack of standards within DOD for the aircraft/store
electrical interface led to low levels of interoperability and costly aircraft
modifications to achieve required, store utilization flexibility. Application
of this standard to new aircraft and stores will serve to significantly reduce
and stablilize the number and variety of signals required at the
aircraft/store interface, and increase store interoperability among the
services, and within NATO. The Navy is supporting the development of the
standard aircraft to store interface with the advanced aircraft armament
system advanced developmen; program.

255

4* .*4p
 INTRODUCTION

Interoperability is presently precluded by a set of obstructions. Withitn

this set, a primary obstruction is nonstandard aircraft-to-store and
store-to-aircraft interfaces. Interfaces between aircraft and stores are
becoming increasingly sophisticated and complex. At the same time, there is
an increasing desire on the part of the Department of Defense to increase
service and allied nation interoperability between aircraft and stores. The
Air Force and Navy have an on-going Joint Service program that address the
problem of interoperability. Objectives of the Joint Service program are:
1) a validated Aircraft Armament Interoperable Interface Standard and
Specification, 2) a demonstration of the interoperability of the
armament-to-store interface by Navy and Air Force aircraft armament test beds,
3) examination of the feasibility of modifying representative existing
aircraft and stores to enable compliance with the developed standards, and 4)
a provision for a joint aircraft/store data base which may be efficiently and
effectively used by the services.

BACKGROUND

Aircraft and munition systems are rightfully designed and built to

accomplish limited and often very specialized objectives. In addition to the
constraints imposed by these objectives, there are many other constraints such
as overall physical envelope, weights, aerodynamic characteristics, etc.
There has been a notable lack of constraint, however, on the configuration of
the physical and functional interfaces between store and aircraft. Interface
configurations have tended to be optimized around weapon systems, with little
attention given to applications outside a specified, usually narrow list of
aircraft and stores. This philosophy unwittingly leads to a lack of
aircraft/store interoperability with those not on the original armament list.

As a new store is developed, it must be compatible with a specified set of new

and old aircraft. And as a new aircraft is developed, it must be compatible
with a specified set of new and old stores. The net effect has been a
proliferation of interface designs and costly modification to achieve any
degree of interoperability. This intertwined and increasing spiral of unique
aircraft and store systems is at the root of the store interoperability
problem, and contributes heavily to the high cost of ownership. Other factcrs
affecting and contributing are:

a. Rapid advances in technology

b. Trend toward sophisticated stores
c. Acquisition management processes with cost and schedule
constraints being of primary importance
d. Requirements for new stores to be compatible with old aircraft
systems configurations and vice versa

Until recently, there has been little emphasis or requirement for general
store/aircraft interoperability. The recognition that interoperability
between countries' weapon systems would significantly enhance the NATO defer"
posture has led to decisions to correct the growing interoperability problen.
Recently, the requirement for interoperability has been included as part or
system development direction. This kind of direction and emphasis will
rqifre designers to give more attention to the problem whil --ik r:.
'orns, but it will not of itself produce total tnterie:;tn'K I L
3 on, and/or aircraft system modifications is one approach, u' . * ',

256

t4 01_
-
n prah
ytmmdfctosi
,', nlrarrf
L
rule these are inordinately expensive. The military service headquarters has
concluded that the long term solution to this dilemma requires that
concentrated armament system research and development be conducted leading to
a set of standards and specifications which will support a physical and
functional interoperable interface.

STATEMENT OF PROBLEM

Interoperability is presently prevented by a number of obstructions.

Within this set, a primary obstruction is the nonstandard electrical
aircraft-to-store interface. The electrical interface between aircraft and
stores is becoming increasingly sophisticated and complex. At the same time,
there is an increasing desire on the part of the Department of Defense to
increase service and allied nation interoperability between aircraft and
stores.

The number of different types of stores is large (more than 100) and
continues to grow as a result of development and acquisition programs. Stores
include conventional general purpose bombs, guided bombs, missiles (air-to-air
and air-to-ground), nuclear weapons, sensor pods, dropped sensors, camera
pods, countermeasure pods, fuel tanks, sub-munition dispensers, guns, rockets,
etc. The elcctrical interface between aircraft and stores is only partially
guided by standards and, therefore, has tended to evolve into system peculiar
adapters/connectors, electronic signals, power connections, and other armament
assemblies which make interoperability impossible without major modifications
to aircraft/and or stores on a case-by-case basis. The trend toward more
complex store function which require increasing amounts of avionics data from
aircrft systems is causing the problem to become increasingly acute. Examples
of this situation are AMRAAM, HARPOON, PHOENIX, HELLFIRE, ATLAS POD, ALCI., etc.

On the aircraft side of the interface, stores management systems are

unique to each aircraft type and sometimes each model. Old aircraft Stores
Management Systems (SMS) are generally hardwired, not integrated, not
automated, and reflect outmoded state-of-the-art in electronics and electronic
design. Although new aircraft SMS designs reflect current technologies in
electronics and communications, they are still tailored to a specific store
list and are not designed for growth. Invariably, the store list changes
requiring modifications almost as soon as the aircraft begins its operational
life. The adoption of acquisition methods which result in aircraft systems
with SMS's which are tailored to handle a specified list of stores has limited
weapon system capability growth and flexibility. The methods yield weapon
systems which are well defined within themselves, but are inflexible and
costly to modify.

Two examples of aircraft weapon update costs are the A-7 and F-18. The
A-7 being an older aircraft one would asume that this aircraft would naturally
require costly modifications with the new modern F-18 requiring only minor
modifications. The F-18 is more compatible with the new weapons because of the
digital data bus, etc. However, significant modifications are required for
the F-18 also. Fig. 1 shows armament changes and their associated cost for
the A-7. Fig. 2 and 3 shown armament changes and their associated costs for
the F-18.

257
CONCEPT OF SOLUTION

Standardization of interfaces between aircraft and stores is one major

determinant of the amount of interoperability which may be achieved. The
ultimate solution to the interoperability dilemma will depend to a large
extent upon the removal of the nonstandard interface obstruction and the
establishment of a standard which will govern all future aircraft/store
interfaces and serve as a guide for the appropriate conversion of selected
existing equipments.

Prior to ML-STD-1760, an aircrft and the stores which it carried were

typically developed independently of each other or were developed exclusively
for each other. Application of this standard to new aircraft and storeb will
serve to significantly reduce and stabilize the number and variety of signal
required at the aircraft/store interface, and increase store Interoperability
among the services, and within NATO. The Navy is supporting the development
of the standard aircraft to store electrical interface with the advanced
aircraft armament system advanced development program.

MIL-STD-1760 addresses the electrical interconnection system and specifies

the parameters required to obtain electrical compatibility between aircraft
and stores.The complete aircraft/store electrical interconnection system is
comprised of three hierarchical elements: electrical, logical, and physical.
The electrical element specifies the aircraft-to-store interface signal set.
The logical element defines the communications architecture, message content
and formatting, and data transfer protocol. The physical element specifies
the aircraft-to-store wiring system including connectors, umbilicals and their
terminations. Requirements for mechanical, aerodynamic logistic, and
operational compatibility are specified in other existing or in development
DOD documentation. Another MIL-STD being deveoped under the auspices of the
Hoint Technical Coordinating Group, Working Party 6 - Aircraft/Stores
Compatibility will address the relationships of these documents and their use
in the overall system level compatibility process. That MIL-STD will be
titled Aircraft/Store Interconnection System Standard. Figure 4 shows the
hierarchical relationship of the proposed MIL-STD with MIL-STD-I760 and other
documentation. Figure 5 shows the MIL-STD Interface Definition for various
aircraft carriage modes.

258
j 9%"r
Mq

cc UR ":1 - "7
-

Cm - nCA"zj-

44

0~C 0 r

0U
7-

U, 4,
M 0

LU U)

_ _ _ _ _ _ _ _ _ _ 44I

- - . U6

ca cm-Wt
Lei *A re -c4

ca 'L3 ;; a

CL.~ 00)toL
't.. C) CD 219c C

-e _L
Sjc c . . 45C-

S2C ow C c

uj 259 LAJ

'. c3 :S .r C3 La CA c -c
.9 uV . ''3
 CD CDCD

<-. >-

cnU

LU w =Q =LU
G
cnC. C3 3LU~ Cl,
<L C,, "
C~J -2

0 - -

ci ~ -~ I-
LUn
C3 C

E-
C-, ____
____ ___
___ ____ ___ ____ ___

~LLI LI_

C:) I- -C

I
4w.U LLJ

_DC CD,

-. Cl

260
 .

-x CD Lr '.0
C)
(/11
0: (- ~ c4r-4
IL LnJ) 4

*L CL') LL. C>

I CD < 44~ 4A4

= C - I--a L ..)

o~
oo ~ 4<
Lii CY.. LJ C) *a C)~

Zj r- 4:CDi. 0L

444: F- to .0 U
Co

CdC,
00

LUi

LLii
C,

U.' CD -J 00:y

ax z 3E z-: 2 :: c L C
LLI
-~ 0 0
IL Lii04 Lm

~ Z &l ~ 0C~ -

LiL.
CLi7
00 CV
cc %0 CC 4:
;r cogm
com en ui i

I I I
Ne l be1 Ie 2 55 MD: LLJ r,- 0-0 1 111
m co

261:
~v-~ - ~ U- ~~.-L~. cc ~ ~ ~ - . ~~ - -- - .

uys
NCin
P-I~

(J o
Mae
ma m
c~cr.
C4u u(

C.3
cc

11111E-4
Q z

Ia E4

d-t
t;4

lU.~

262
 alll
p

--- "L * * -- ~--- ~- o -. * -- ~

a SO
aE-4

UU a11

I-A

263
BIOGRAPHY
Mr. Gerald E. Kovalenko graduated from North Dakota State University
in May 1960 with a BS degree In Mechanical Engineering. Mr. Kovalenko has
continued his education through graduate school extention courses in
Engineering and Management from University of California at Los Angeles and at
Santa Barbara, University of Southern California, and University of Michigan
with specially short course training through the Governments continued
training program. In May of 1960, Mr. govalenko accepted a position with the
Corps of Engineers in Omaha, Nebraska ahere he worked In the Design Groups
and the Atlas "E" Missile Installation and OAHE Dam Construction Sites. In
January 1962 Mr. Kovalenko accepted a position with the Naval Weapons Center,
China Lake, California. During his 17 years at the Naval Weapons Center,
Mr. Kovalenko worked on a variety of Air and Surface Launched Armament
Subsystem Development Projects. The Exploratory and Advanced Development
Projects included: Surface Weapons Fire Control Exploratory Oevelopment
Program, Point Defense, Sidewinder, AGILE, SHRIKE, HA., HARPOON, Aircraft
Survivability, Aircrft Armament Equipment, Liquid Propellant Gun Technology,
20mm General purpose projectile, and Gunfire Control System Technology.
During the 17 years at the Naval Weapons Center, Mr. Kovalenko was head of the
Mechanical Design and Analysis Branch for 7 years. In November 1978
Mr. Kovalenko accepted a position with the Naval Air Systems Command,
Washington, D.C.. As an Armament Engineer, the Technology responsibilities
included Gun System Technology, Pyrotechnics Tehnology, Air Armament System
Technology and Cartridge and Cartridge Actuated Device Technology. The
responsibility as Program Manager is primarily for the "Advanced Aircraft
Armament System" (AAAS) Advanced Development Program which includes Stores
Management and suspension and release equipment. The "AAAS" program is a
Joint Service (Air Force/Navy) development program which Is developing the
aircraft store electrical interconnect system. As a technology administrator
and program manager interacting with international groups for technology
coordination is required. The two International groups are NATO and Air
Standardization Coordination Committee (ASCC) Air Armament Working Groups and
Inter-Service JTCG/MD working party for aircraft/stores compatibility and
working party for guns and ammunition.

264
 dd

4 I

MIL-STD-181 5

ADA HIGH ORDER LANGUAGE

I.

a'

SESSION CHAIRMAN: Paul wood

Sperry Univac Corp.

MODERATOR: Clyde E. Allen

Vice President, Product Engineering
 USE CF ADA* IN SYSTEM DESIGN: A CASE STUDY
Hal C. Ferguson and Michael B. Patrick
i General Dynamics P.O0.
Data Box
Systems
748,Division,
M.Z. 5400 Central Center
Ft. Worth, Texas 76101
(817) 731-0741

Since Ada has been adopted by the Department of Defense as the

standard programming language for efbedded ccmputer systems, it is vitally
important that government and industry personnel understand the consequence
of using Ada in system development. A case study was recently completed in
which Ada was used throughout the development of a large digital message
switch. Prior to the start of system design, personnel were trained in the
use of da and a methodology incorporating Ada compatible requirements and
design techniques was developed. With judicious application of the method-
ology, a system design was produced. One major component of the systmn was
progragmed in Ada. In this paper, the case study effort is described.
Examples of system design structures and Ada code are presented. Lessons
learned and conclusions regarding the use of Ada are discussed.

The Ada Capability Study was performed by the Data Systens Division
(DSD) of General Dynamics Corporation, Fort Worth, Texas, under contract
with the Department of the Army Communications - Electronics Ommind (CEC24),
Fort MormOuth, New Jersey. The purpose of the contract was to provide a docu-
mented case study and analysis of the use of Ada in the design, development,
and implementation of a large scale digital system. An existing real time
system, the AN/TC-39 message switch, was selected by the Army for this case
study and the actual "A level" specifications were provided to General
*Dynamics.

This task involved the performance of four subtasks: (1) develop a

methodology for the use of Ada in the specification of requirements, the
.design, and the implementation of a digital system; (2) train personnel in
*the use of the Ada language and the methodology; (3) use the developed
methodology to design a system for the AN/TYC-39 message switch; and (4)
program one selected module of the designed system.

*Ada is a registered trademark of the U.S. DOD (AJPO)

Copyright 0 1982 by General Dynamics Corporation
All rights reserved

267
 ORGANIZATION AND PERSONNEL
A project organization was established with the group divided into
three teams: methodology development, system design, and training. Con-
sultants from industry and academia were used to support methodology
developrent, to provide expert consultation, and to review the entire case
study effort.
The methodology team was ozrosed of three General Dynamics employees
and two consultants from North Texas State University. A total of seven
employees were assigned to the design team during the contract effort, with
a maxinun staff of six at any one time. Personnel with varied backgrounds
were chosen so that the case study effort would be accomplished in a real
world environmt. Two of the people had Master's degrees in comuter
science; five had Bachelor's degrees, three in mathematics and two in elec-
trical engineering. The leader of the design team was chosen because he had
specific experience in communications and telephone switching syst s. Other
tean members had varied backgrounds which included real time systems pro-
grammting, compiler development, and business data processing. Four of the
people had experience in assembly language and Fortran; three had used
structured higher order languages including Pascal.
TRANG
The training of personnel was an integral part of the Ada Capability
Study. Early in the program, the project management sought effective Ada
training in the form of books, video tapes, short courses, and tutorials.
It soon became evident that the availability of training materials at the
level required for the Ada Capability Study was limited, and that it was
necessary to develop a training curriculum to meet the training requirements
of the project.
In-house training of Ada project personnel was conducted in two
phases. The first phase consisted of ten 2- to 3-hour presentations given
to the original members of the Ada project team by a consultant frm North
Texas State University (NT'). These presentations were given in seminar
fashion, in the form of lectures with accompanying viewgraphs and hanuts,
and with free class discussion. All features of the Ada language w re
covered in this phase. Because of time constraints, most topics were
*covered rather quickly.
The second phase consisted of a reprise of the first phase given
primarily for new team members, but open to anyone on the Ada project. These
sessions covered fundanentals of the language in more detail (in seven
2-hour meetings). Attendees in this phase had, on average, less broad
experience in higher order languages than those in the first phase. Special
emphasis was given to overall program structure, data types, packaging, and
tasking. Phase I experience was useful in identifying and anticipating
student difficulties.

268
 MErHDOOGY DEELVM

The methodology tem conducted a study of existing methodologies and

published an Ada Integrated Methodology (AIM). It is coqirised of two
main parts described in more detail below: (1) the Ada Requirements
.Methodology (AM) and (2) the Ada Design Methodology (M). It integrates
several existing methodologies and some important design concepts with the
power of the Ada language.
The purpose of the requirements phase of the software life cycle is
to prcurvte an understanding of the problem at hand by clearly (unambiguously)
and succinctly specifying the functional and non-functional goals and oj ec-
tives of a project. AFM accomplishes this purpose in a four-part process
as follows:
PART I - Develop Functional ezruments in four steps:
1. Create a data flow diagram (DE) model of the system
to be developed;
2. Develop and maintain a data dictionary of all data flows
on the DFD model;
3. Develop a logical data structure model;
4. Write functional requiremnts using an Ada-based
structured English.
PART II - State the Non-Functional Requirfments (reliability, per-
formance, accuracy, etc.) in Eglish narrative format.
PART III - Develop Concurrency Requirements using conrrency charts
and/or English narrative.
PART IV - Formulate and organize the Ada Requirements Document
which is primarily an aocumulation of the outputs from
PARS I, II, and III.
Collectively, the components of the ARM output are used to state and
graphically illustrate system requirements (both functional and non-func-
tional). It is not intended to constrain or limit the designer, although
the functional decclposition and creation of DFDs in the requirements phase
is considered by scme as moving toward design. However, the intent of ARM
is to produce a requirements document that will aid and facilitate the
design process. The inclusion of functional decomposition and MrDs in ARM
is consistent with a trend in contemporary systen development to incorporate
more planning, discipline, and decision-making up front (prior to program
development). From experience gained in this project, the researchers feel
that AM could replace the old military A-specification document, which
proved unsuitable in adequately documenting the message switch modified by
this project.

269
 I

ArM is a design methodology that converts the output of ARM to a system

design expressed by graphic models and Ada PDL. Several methodologies
(including Structured Design, the Jackson data structure approach, and ob-
ject-oriented design) and design concepts were combined with the Ada langu-
age to form AfM. Therefore, the designer that applies ALM shuld be
equipped with a design tool bag. This tool bag approach was favored by the
design team as it attempted to achieve the two-fold purpose of AI24 - (1)
produe a design that satisfies the requirements in the Ada Requirements
* ~..Document and (2) produce a design that exhibits maintainability (flexibility
* for design changes during development and after implementation). ADM achieves
its purpse in three parts as described below:
PART I - Architectural Design

a. Identify data structures

b. Perform object-oriented design pre-analysis
c. Develop concurrency requiremnts
d. Generate structure chart
e. Validate "goodness" of design
f. Validate correctness of design
g. Document system interfaces graphically
h. Perform prelhrinary design review
i. Develop Ada Unit Specifications (beginnings of Ada PDL)
j. Perform hardware/software partitioning
PART II - Detail Design

a. Express system design in Ada PDL

b. Perform a final design review
i. Design Walk-Thru
ii. Preprograwming Ada Evaluation
iii. Requirements-to-Design Traceability
iv. Design Philosophy Review
PART III - Compilation of the Ada Design Document
In summary, the application of AL4 facilitates the development of
prograriing requirements and design documentation. This is normally within
the scope of a design methodology. However, because ADM is an Ada-based
methodology, there is a tendency toward using the Ada language as much as
possible during design. Also, the nature of the Ada language requires the
designer to function somewhat like a chief programmer during design. For
example, the designer must evaluate the overall design in terms of data types,
overloading of unctions, etc. Any encumbrances created by improper data
typing or improper overloading of functions should be eliminated before
actual program development begins. ADM's use of Ada as a PDL for developing
programming specifications is another example of the impact and use of the
Ada language during design.
There are many elements of existing methodologies which are beyond the
scope of this methodology development effort. Specifically, this methodo-
lo~y excludes the following:

270

06
 * - -.........- - ~ ~ .A.

I
g5

MO

4
1'

S
I.1
p..
U
S

p.. a. -

0-.

I - z
4

I.
di -

S
U
I
S.
a.

p... b -

iii
I
- - - - - - - - -

aIM
I

*'1

27j

6,

** ".. *'.* -' % 4 ~

 w° ~ - W ~ A1. ~ rC - ~ ~ .Lw.~°-'- - -' ~... . . o

- Development of docuuentation and plans in support

of the implementation of a new system such as (1)
user guide, (2) operations guide, (3) test plan,
(4) new procedures, and (5) training aids and
courses.
- Survey of the present systeI
- Conversion fru present system
- Implementation phase (does rnt address prcgramuing
and testing - goes through design only)
- Constraints such as time, money, and personnel
- Detailed explanations of contributing methodologies,
concepts, and the Ada language (provides only basic
guidelines and examples for the requirerents analyst
and designer).
The AIM project life cycle concept can be used to help illustrate the
scope of AIM (See Figure 1). The dotted lines indicate where AIM begins and
ends. Although there is no implementation methodology within AIM, one chap-
ter does provide some Ada development standards.
REQUIRMENM DEFINITION PSE
The message switch requirements definition began simultaneously with
the methodology development at the start of the contract in July 1981. The
requirements analysis team then consisted of three persons, a chief systes
engineer, chief programmer, and an assistant. The major problems confront-
ing the team were (1) to understand the message switch application (2) to
apply the appropriate methods during requirements that would facilitate Ada
oriented design and coding phases and (3) to determine the appropriate
limit to the scope of the project so that cumpletion could be accomplished
in one year. An additional uncertainty, the lack of understanding of the
Ada language, was to be resolved by training, as previously discussed.
The solution to limit the scope of the project was to set up a neeting
with the Arny representatives to discuss the matter. It was determined
that certain complicated I/O devices would be eliminated, and minimal effort
would be spent on the operator interface and duplication of similar message
format processing. Ordinarily, there would be frequent meetings with the
custarer to resolve misunderstandings and incongruities in the specifications;
however, the message switch application is a standard part of the anrm
equipment inventory and the requirements are essentially static. For the
purposes of this contract, any conflicts between wording of specifications
was evaluated in the requirements group and the most practical approach was
taken. This undoubtedly expedited the requirements phase.

272
COD
LUS

ac

LL.
C2
2C

C
U.'

9L.

LU

CD

CD 0

Figure 2. Exaiiple of a Data Flow

Diagrm (MD)

273
 The understanding of the message switch application was gained by
studying the "A level" specifications provided by the custater. Within
these, many other specs were referenced. All specifications ware in narra-
tive form, and the "A level" spec described an additional system not re-
lated to this contract.

Because of the organization of the specifications, understanding of the

message switch, a large complex system, came in fragmented parts, and the
whole learning process was iterative. Therefore, a graphical approach
utilizing data flow diagrams (DFD) was used to represent the team mntbers'
understanding as it evolved. A new data flow diagram (DFD) could be quickly
sketched out with any radical change in thinking. Minor refinements could
be easily added to the existing diagrams. Since the chief engineer had prior
experience with structured analysis (SA) techniques, the structured analysis
and design technique (SADT*) was used until the methodology group formulated
a requirements methodology. SAMr has the benefit of shing the separation
of data and control elements, considered by the chief engineer to be impor-
tant for real time system design. An example of a modified top level SADT
diagram for the message switch is shon in Figure 2.
This diagram is the final requirements version and supplerental infor-
mation prcwided by the methodology team has been added. The rectangles
represent traditional SADT processes, whereas the large circles, taken from
Yourdon/De Marco SA, represent data repositories (files). The small circles
are on-page connectors to reduce line crossings. For exarple, all circles labeled
with 1 connect to each other. In reading the DFDs, data is input at the
left side of a rectangle, control is input at the top, outputs exit the
right side, and flow is in the direction of the arrows.
The label on each line connecting the rectangles and circles is des-
cribed in a data dictionary which provides further deccmposition of the in-
formation. For example, on the Node AO diagram (Figure 2), the "sorted
message" data flows from box A3 to A4. Because multiple inputs and outputs
are numbered in ascending order frao top to bottm, the "sorted messages
output" fran A3 is 02. In cniparing the "sorted messages" entry in the
sumkary data dictionary of Figure 3, it can be observed that a connection
from output 2 of node A3 exists, as well as connections from input 2 of
node A4, input 1 of A41, and input 1 of A4II. Further, it can be seen that
sorted messages are made up of a message plus a message control block CB).
These terms can be further decanposed as seen in the "message" entry.
For the message switch application there are thirty-two additional
graphic diagrams that represent successive refinement of the top level
functions illustrated here. Eventually, a point is reached where a function
becomes so trivial that it is no longer feasible to represent graphically.
At this stage, an Ada subset is used as a requirenents specification langu-
age (RSL) to express the specifications for each lowest level (primitive)
function of the DFD. The subset of the Ada constructs utilized by the Ada
Requirements Methodology (AY4) is provided below:
OSADT is a registered trademark of Sofrech, Ic.

274
 VMS

wan.
a.oa

MD

49 as
zZ33= Z E=I IS'1 w 1.r) 94 LI
3~- zz tI 3 - om ycg
w1...of

xesag
Sw2itch c

275 7o Qq L 1
 if statemt
case statemnt
loop statement
assignment statemt
code stataent
expression
relation
exit statemnt
procedure calls for pre-defined procedures
raise statement
exception handler
Displined English is used to suppleiment the Ada requirements language
constructs when knowledge is insufficient for representing a particular
requirement in detail. Additionally, comments are used where appropriate
to add clarity to the requirements. The symbol for a comment line is
"-", the same as the Ada canment notation. A "->" symbol is used to
i-4icate a line of requirements specifications that is stated in disci-
plined English.
In addition to the Ada RSL, a primitive contains a brief narrative which
explains its purpose, shows traceability back to the "A level" specification
provided by the custrrer, and contains the date and initials of the analyst
performing the work. Figure 4 is an example of an Ada requiremants specifi-
cation which uses Ada constructs, disciplined English, and ccmments. During
the requirements phase approximately 150 primitives were produced.
By late October, one analyst had been transferred to the methodology
group and another had been added, leaving a total of four, and the first
draft of the Ada Requirements Methodology was released from the methodology
group. Fortunately, the data flow diagrams were still based on SADT, but
additional enhancements were supplied by structured analysis techniques.
Sane redrawing of the diagrams was required as a result of the methodology
arrival and additional levels of decmposition occurred. Another require-
ments analyst was then assigned to the project. The chief engineer assigned
the analyst to the output message section. The chief programmer was con-
tinuing with message routing and the previously-assigned analyst continued
on the input message section. Initial assignments were made by the chief
engineer based on individual interest, which was samewhat related to the
team menmbers' backgrounds. Hardware designers worked in areas of I/O and
software designers in transform analysis. The chief engineer was coordinat-
ing the requirements development, assisting in message input, and spending
part of his time ompleting another project unrelated to the message switch
(real world problem).
The decanposition process continued into December. Initially, it was
expected that the design document would be ompleted by Christmas, but this
was not accamplished. The message input requirements were considerably
behind, and the requirements analyst assigned to the message input function
asked to be removed from the project. T-e chief engineer and chief pro-
grammar cxipleted the section by late January while the other analyst
finished the message output. Also, in January, non-functional requiremants

276
 --A413 PERFORM ROUTING LINE SEGREGATION
--PURPOSE : GENERATES MULTIPLE ROUTES, SEGREGATED BY OUTPUT
-- TRUNK TYPE
--REQUIRED BY PARAGRAPH: 3.2.1.2.7.6, FURTHER REFERENCES IN
-- DCAC-370-D175-1, SECTION 9-4.
-- REV BAAA
-- 11/5/81 HF/PD

procedure SEGREGATE Is
begin
for NEXT RI in ROUTE.LINE loop
--OBTATN NEXT RI IA HEADER
if NEXT RI z RI TERMINATOR (2EH) then
--> C6PY RI TTRMINATOR TO NEW ROUTE LINE;
exit loop;
end If;
if NEXT RI z RI In GROUP RI then
--> CUPY NEXT RI TO NEW ROUTE-LINE;
else
--> REPEAT UNTIL ALL RI IN GROUP RI HAVE BEEN COMPARED TO
--> NEXT RI;
end if;
If NO RIzNEXT RI then
If OUTPUT DEVICE 15 DTE then
If LMF PAIR z "SC","CC","BB","DD" or OII"then
--> COPY AN EQUIVALENT NUMBER OF SPAEES TO
-- > NEW ROUTE-LINE;
end if;
el31f LMF FIRST a "S","C","B","D" or "I"then
--> COPY A SINGLE SPACE TO NEW ROUTE LINE;
elsif LMF FIRST a "T","R","F","Q' or "I"then
--> COPY "SI"(OFH) TO NEW.ROUTE LINE;
else
raise LMF ERROR;
end If;
end If;
--> COPY ONE SPACE CHARACTER TO NEW ROUTE LINE;
end loop;
end SEGREGATE;

Figure 4. Exanple of an Ada Reuire!.ts Priidtive

277

:"
., ' ' . ,_ , ' , o ,,,' ' , " / ' } ) 3 'J .5 : ,',,¢., , ... ,h
relating to performance, reliability, and operating constraints not des-
cribable elsewhere, were omnpleted. Concurrency (high level) was studied,
and a concurrency chart was produced.
The efforts of the design team during the requirements phase resulted
in Ada requirements document. This document restated the "A
level"174-page
a specifications in a mre structured, organized format with many
graphic illustrations (DFDs and concurrency), Ada subset RSL, and narrative.
The application of ARM produced a very good understanding of the
problem during the requirements phase. The success in this area can be
mainly attributed to the functional decaposition, DFD approach used.
Although it was not known at that time, the design and coding phase went
considerably faster than expected. It is felt that this is due partly to
the thorough understanding gained during this phase.
DESIGN PHASE
A transition from the requirements phase to the design phase took place
in late January, 1982. The four requirements analysts continued on the
project and two new personnel were brought in from engineering. The engi-
neers were given the Ada requirements specification as their primary source
of information about the message switch, as well as a briefing on the
methodology. The design team met as a group for several weeks, sometimes
in full day sessions. Various issues arose during the sessions and the
need for individual thought dictated half day sessions on many occasions.
The first two weeks were spent on object-oriented design. Since none
of the designers had ever participated in an object-oriented design session,
the methodology group was frequently invited. It was suggested by the chief
methodology engineer that the search for objects should begin with top level
DFD (node AO). This turned out to be a good idea since four out of seven
objects appeared at that level. The process of identifying operations to
be performed on the objects gave the design team the opportunity to more
closely observe the relationships between data structure ccmonents. Thus,
information hiding techniques could be applied that allowed operations to
be hardware independent. This was especially evident when designing the
"reference storage" object, where the "construct" operation was defined to
make a sequential operation work acceptably for random access or sequential
hardware devices. In addition, the "message" data structure and its cam-
ponents provided the basic structure for the internal system software design.
During the design sessions, one designer was in charge of updating the
chalkboard as the design evolved. The chief engineer refereed the dis-
cussions, especially when it was felt that enough time had been spent on a
topic. The chalkboard was copied to paper by the participants at the end
of each design session or when a new topic was to be considered.
The object-oriented design sessions could have continued longer, but
opinions varied as to what additional usefulness would be gaire from this
relatively new approach. The next step in the methodology lasted about
four weeks and began by utilizing traditional structured design techriqe,
to geerate a structure chart of the message switch. Athoc'- co.'.-
tion was given to startup/restart, operator interface, maintan-,-ce zr-:uraw.-
278
I
and runtime support, the primary design emphasis was related to message
processing. This was because the message processing is the most important
real time aspect of the system and all other software in the switch is
present for its support. The support functions were somewhat limited
because of the time and scope of the project. The emphasis on support
functions was at the interface to the message processing function.
After several rounds of refinements, the chief engineer made assign-
ments to team personnel. For those who participated in the requirerents
phase, the assignments were in a different functional area. This was wot
only to provide each person with swe variety, but also to see if a
designer could interpret the requirements written by another requirements
analyst. Frum the time the assignments were made, the person responsible
for a particular area of the message switch would be the resident "expert"
during a design session imlving that area. This helped to ensure that
a specific designer was responsible for issues arising during the sessions
pertaining to his area of expertise, and part of his time outside the ses-
sions was to be utilized solving these problems.
Throughout February and March, the structure charts were refined,
additional concurrency requirements were identified and coupling and cohe-
sion ("goodness" of design) were evaluated. In mid-March, an in-house pre-
liminary design review was held. All design and methocblogy team members
were present as well as an Army representative and consultants. An overview
of the message switch was presented for the benefit of the consultants. Then
the object-oriented design, structure charts, and concurrency were discussed.
Same minor errors were detected during the process and it was generally
agreed that the review was mxthwhile.
In late March three areas of the message switch were identified as
potential condidates for coding as required by the contract. Message output
was suggested as the runmber one choice and the Army subsequently agreed.
In early April interconnectivity charts were made by each designer for
his area of responsibility. The two primary data structures, linetable and
routing indicators, were formally organized and recorded. One designer
with much hardware experience wrote a description of the executive initia-
lization and user interface modules in narrative form. This was done to
show the cmpleteness of the system design. The area of user interface,
startup/restart, fault detection, and maintenance diagnostics are just as
important to the system as the application. Due to the size of the message
switch and the scope of the project, the level of detail in these areas
was necessarily limited. The first seven steps of the design methodology
were ccnplete and a one hundred page document was campiled for the critical
design review held in mid-April.
All steps in the methodology were useful for design purposes except
the interconnectivity charts, which were intended for documentation of
interfaces. The infonation in these charts was derived directly from the
structure charts.

279
* After the CDR, the Ada Unit specifications for each Ada design unit
of the structure chart were created. This served the purpose of formal
specification of the calling sequences, tasks, declarations, parameter
lists, and other items required by an Ada specification. The example
sham in Figure 5 is one of over one hundred written for the message switch,
and forms the basis for a PDL. The designers accomplished this mostly as
an individual effort, with reviews by the chief programmer.
The hardware/software partitioning was done concurrently with the unit
specifications. The designer who wrote the "run switch" description worked
on partitioning full time. The chief engineer assisted with this process on
a part-time basis. In addition to task coordination, tine was spent assist-
ing with the data structure unit specs. It was discovered that the dis-
tributed processing approach decided upon by the hardware designer could
have significant impact on the structure that had been defined up to this
point. The level of impact depended on where the partition was drawn. A
group meeting was called to discuss the matter, which resulted in a parti-
tioning that had a minimal design impact, yet provided good interprocessor
load sharing and cost effectiveness. The conclusion drawn fram the expri-
ence was that the hardware/software partitioning should be considered
earlier, particularly in a distributed environment.
Because of the scope of the project, the detailed design was done only
on the selected module and its interfaces.
The detailed design phase was carried out differently than MI.Ikied
by the Ada design methodology, mostly because the expression of the system
design in Ada PDL wuld not be very different from the requirements RSL that
already existed, except in the area of message processing support routines.
A two day group meeting was held to establish the exact routines and func-
tions needed for this support, including the memry allocatioVdeallocation
schew for message buffering. After establishment of this structure, each
designer/programmer was to use these support (library) routines as necessary
and report to the chief programmer any new support needed but not yet
defined. All routines in the MESSAGE OPS, SE2 TVOPS, and MNAGE IIRANSIT
packages resulted from these sessions, as wall as Ehe message scheinn, a
diagram showing the basic internal message structure. Having these packages
at the start of the detail design provided a certain amunt of consistency
to the resulting design because each designer worked with the same building
blocks, not creating individual special purpose routines that partially
duplicate functions. This approach wrked extremely well. Tw designers
were paired to design the output message validation routines, another defined
the queueing to output port interface, another designed the output port task
call/accept structure and support routines, and another continued on hard-
ware/software partitioning.
The final design review called for in the methodology was held at the
technical interchange meeting of May 25 and 26 near Ft. Monmouth, N.J.
Essentially, there was a complete design walk through (informally held at
General Dynamics the week before), a design philosophy review and explanatior
of the hardware/software partitioning. The requirements-to-design trace-
ability had been orpleted at the prior design review meeting.

280

- V.
RD-Ai45 697 PROCEED INGS PAPERS OF THE RF5C (AIR FORCE SYSTEMS 4/6
AVIONICSAFB
WRGTPTESNAOO
WRIGHT-PATTERSON AERONAUTICAL
IETRTCOMMAND)
STAND..(U)
OH DIRECTORATE 0.. SYSTEMS DIV
UNCLASSIFIED C A PORUBCANSKY NOV 82 F/G 1/3 NL

EhEmoEEEmhEE-
EIIIIIEEEEEEfEE
llIlhllEEllllEE
lflflflllllflflfll..
llEEEEE~hEElhI
-lo lot L,= 6 ---

1.1 s'
 MANAGEINTRANSIT

package MANAGEJNTRANSIT 13
ATE:---May---------1--82
------- --
-NAME: MANAGE INTRANSIT
-PURPOSE: contains procedures and tasks to manage the Intransit
storage memory resource.
PROGRAMMER: Paul Dobbs
-----------------------
ce ao-------------------

type MEM-SIZE Is INTEGERI

type THRESHOLD Is range 0..1991
procedure SET THRESHOLD CLOWER:THRESHOLD :- 601
UPPER:.THESHOLD to 70);
-SETS LOWER AND UPPER THRESHOLD AS SPECIFIED IN CALL
-MIDDLE THRESHOLD IS SET TO THE AVERAGE OF LOWER AND UPPER
procedure READ THRESHOLD(LOWE~rM.IDDLEUPPERs out THRESHOLD);
-- READS CURRdiT THRESHOLD SETTINGS
task CALCULATE THRESHOLD Is
-- CALCULATET THRZSHOLD VALUES AND INITIATES OVERFLOW
-- ACTIONS
entry GET(31TS:MEM SIZE);
USED WHEN GETTING STORAGE
--
entry PUT (BITStMEM-SIZE)i
-- USED WHEN RETURNING STORAGE TO INTRANSIT
end CALCULATE-THRESHOLD;
end MANAGE-INTRANSIT;

Figure 5. DcKiple of an Adia Unit Specification

281
PROGRA P1HSE
Although there was no formal preprogramming Ada evaluation, a set of
standards was developed by the Methodology group as programming progressed,
and members of the design group consulted with each other on a regular
basis to ensure that the development stayed on the right track. The selected
module (output message) was programmed in Ada utilizing the primitives (fran
the requirements phase) and the Ada unit specifications (from the design
phase) for the application software, and the machine dependent structure dia-
grams and Ada unit specifications (both from the design phase), for the
support (library) software. The support software consists of packages of
functions and procedures (such as segment ops) required to perform operations
stated in disciplined English in the appl1cation primitives. Most of the
message switch support routines, queueing interface and validation routines
had been written by late-May. The "send message" routines, which required a
much closer orientation to the hardware were written in June. It was quickly
determined that Ada has some deficiencies when interfacing at the hardware
level. Most of these concerns have been rectified by revisions to the Ada
language subsequent to the July 1980 version used in the project. Also, in
June, time was spent formalizing various documentaticn.
Since no one had any Ada progamung experience, the New York University
Ada Ed Campiler/Interpreter was used frequently to find syntax and semantic
errors. Even though sane problems were uncovered in Ada Ed, it was deemed a
valuable tool. It was necessary to restructure and break up some of the
larger modules in order to allow compilation, but it was also agreed that
using "separate" procedures made higher level routines more understandable.
This increases the need for a good cross reference tool, however.
An error analysis was accomplished to determine the frequency and types
of errors made by the individual programmers aid to relate this information
to the experience level and training provided for each programmer. It was
no surprise that programmers experienced in Pascal and Jovial understood
the concepts of Ada the easiest and turned out more error free code. Typo-
graphical errors were the largest category (about 25%), but declaration
errors, failure to Import packages, and type mismatching accounted for half
of the errors made after correction of syntax. Better training and
experience should lower declaration errors, but good tools should help lower
the errors attributed to import errors, and maintenance of.a type dictionary
would probably have decreased type minatches. The tern uembers who did
Ada progrTUming became very proficient in its use, partly with help f rn
other prograners proficient in Pascal and Jovial, and partly through use
of AdaEd. Approximately 7500 lines of comnanted code were generated by
four programmers with an overall rate of approximately 7.5 lines per program-
mer hour. The 7500 lines of code generated represented nearly 15 percent of
the total systan.
CENCLUSIONS

The Ada Capability Study has been a success and has demonstrated that
Ada can be used effectively in the definition, design, and prgranmIng of
a large scale digital systen. In a span of twelve months, a methodology war
developed, personnel were trained, system requirements were 6cfined, a

282
 lww.rvr.
'W Wwy- : -- W.. 7't. F.UP; . ..V. .. . - f- - r -- ..

design was aooc lished, and a module of the system was coded. Since an
Ada cop2iler and run time support package are not yet available, it was not
possible to execute any of the inrplemented code. It is recognized that
certain embedded real tire applications may present Ada ipleentation pro-
blems heretofore not realized, particularly in the area of hardware inter-
facing and tasking.
A case study such as this is a good beginning, though it is only the
beginning. Continuing research in methodology development and in the use of
Ada is required with the developzunt of cmpilers and an Ada environment.
In a paper of this length it is difficult to discuss all aspects of a
project such as this one. Several docmrents were produced which describe
each seqment in great detail. The titles are listed in the appendix and
are no available from the National Technical Information Service.

U WS V Vqp.VE?1

283
 APPEDDC A

List of Documents Produced by the

Army' CW Capability Study

All wre pxoduced under contract no. DAAXO-81-C-OlDS

U. S. Army CE=
Joe Kena=, DRSEL-'I:S-ADA
Ft. Monmouth, N.J. 07703

by GOOAL DYHIWCDPOM'S
Data Systemw Diviscz
Central Cnter

(1) Ada Integrated Metkmdology, NTIS #ADAI 123305

(2) Ada Equivalent system Requirements Specification for AN/rYC-39 Store
and Fonird Message Switch, Revised, MTIS #ADA~ 123306

(3) Ada System Design for the AMtrY-39 Store 6 Forward Message SwitchNTIS #ADAJ.23307
(14) Ada Capability Study Source Code Document, Revised, Not assigned to NTIS

(5) Ada Capability Study Final ReportNTIS #ADA 123304

The NTIS order desk telepone= rnznber is (703) 487-4650

Michael D. Patrick, an employee of General Dynmics Data System

Division, has 20 years of experience in cm~xiter prograseing and softwre
design, specializing in real time emedded =Wputr systems. He served as
project manager for the recently cowleted Ada Capbility Study. I that
capacity he was instruental in selecting the team memsbers, sec'r~l expert
con'sultants, and coordinating contract activities. Mr. Patrick har a B.S.
in ra~ho'matics from the University of Texas at Arlingjton. He is m r-er
of the AtO. and the Ai3Tec special interest grulp

Hall C. Ferquson, an coiployee of General Dynaiwcs Data Fyqta-S Division.

has &,tensive expeiiance in both hardware and i~ftware design and the deve-
jcprcnt of real time process control system.. He served as chief systm
engincer on the Army Ada Capability Study onntract. in that contract he
led the design team effort whic produced a well-doinirentod rcdioin of an
mi vic-39 message switching system, using Ada throulou the de,.-eoopment
Froes5. in 1962 he received an A.S. in Electrical Migineeii 1(Lc-loc
frthe University of Texas at Arlington ankd in 1971 a B.S. in Itat-hCxnl-
tar Science from Texas Ciristian Universi.ty. He is a memnber of tlie A"N and
the Aja~ec special interest grouap.

28'4
STANDARDIZATION ISSUES - NEAR TERM

SE88N CHAMANA. Robrt Haruis

AFWALIAAAI

MOOERATOR: ColMs Hugo Welhel

AFWAL/AAR
 SUCC SSFUL DEVELOPMENT AD SUPPLY OF

STANDARDISED =1PUTER HARDWARE AND SOFTWARE

DURING A PERIOD OF RAPID TECHNOLOGICAL CHANGE

KB Dixon

Sales Manager

Ferranti Computer Systems Limited

Cwmbran Department
Ty Cooli Way
Cwmbran, Gwent
South Wales

Telephone: (06333) 71111

This paper overviews the experiences of parrenti Computer Systems as

mar developers, suppliers and users of Ug No standard computer and
interface hardware and software items over rtteen ypars.

Ferranti's leading role in this field currently centrea on the

development of the Military Argus computer range and associated

CORAL/MASCOT compilers and operating systems with emphasis on the high

performance bipolar VLSI radiation hard K700/4O processor due tor release

early 1983. These developments follow the earlier cosputer/mod'.I. rtnr,e

of the PH1600 series, widely applied in Naval Command and We.lror ".:nt-,

and Air Trafl'fic

Centrol,'Air Defence; and the FIO0-L mtltt.iry

microprocessor, used mainly in missile. armoured vehicle and a.1pc-

applications.

For the future. Ferrantt -ire heav.ty cem-itt1 to the

. ME . ,.,

Interface, and are engnged in developments relatinA to MtL r '1 1

'I
preparation ror VLSI implementation, probably In the Ada/APSE era.

The paper seeks, in the light of experience, to identitfy the vitil

Ingredients of success for standardisastion policies, where market size

can be limited, but performanee And quality requi.resnts nre extremeiy

high, durinK a period of technologieal charee.

287
FpagvgOU A

iIs-
BACKGROUD

With the notable exceptions of the Royal Navy and the United States Navy,

the application of standards to computer architecture, system interfaces

and high order languages for military real time applications is a

comparatively recent development.

For both the New World and the Old, it is not perhaps surprising that

'the Navy got there first'. It was the ships of the fleets that first

provided a basis for reasonable numbers of identical computer systems,

operating in an environment which, although to a degree rugged, with

careful design was compatible with the computer technology of the 1960s.

In the course of being leading developers and suppliers of real time

computers and associated systems to the UK MoD for nearly twenty years,

Ferranti have made a major contribution to the introduction of standards

within the Royal Navy.

288
In the early 19609 Ferranti were primarily engaged in the design and

supply of computer systems for fixed ground systems for Air Traffic

Control and Air Defence and for the first mobile Air Defence missiles

such as Bloodhound and Thunderbird. This was in the days when each

different system requirement tended to result in the development of its

own, special computer. The first naval systems were for 'capital' ships

such as the carrier HMS Eagle and later for the County Class Guided

Missile Destroyers. The scale and operational requirements of these

systems resulted in the development of the Poseidon computer and various

specialised associated equipment for interfacing to the radars and other

main sensors of the day; but the systems, whilst functionally complex,

were in no sense modular. As the real costs of these developments became

apparent one did not have to be a prophet to realise that if such systems

were going to spread across the different classes of ship in the fleet,

the development of a modular equipment and software base was essential.

289
 -l 7.7.-1 -7-72.-74 al..~ a-. K% -17117 177 -

It was soon realised that the achievement of modularity was conditinnal

upon the introduction of standards. However, it has to be recognised

that the application of 'standards' requires the acceptance of an element

of constraint, whether the standards apply to processor architecture in

the form of approved instruction codes, local computer to peripheraln

interfaces in terms of physical form and protocols, or - as we are now

seeing - to system architectures by interfaces such as 1553B. In other

words for a standard to be successful a balance must be struck between

compromise and overkill. It cannot be denied that in the 'iarly days of

standards, the element of compromise was sometimes found to be irksome,

and this prevented the spread of some standards beyond the range of

applications foreseen at their time of definition or choice. The

integrated circuit and its followers - 1431 and LSI - have, however,

progressively enabled the element of compromise to reduce, as the element

of overkill has become more economic. This has now reached the point

where, with VLSI, the advantages of intelligently chosen standards become

overwhelming.

It is important however, to recognise that technology is developing and

will continue to develop at an extraordinary rate. For this reason the

choice of standards must be matched to natural 'plateaus' in the general

development advance, so as to allow effective exploitation. This means

that some inherent flexibility of implementation is essential within the

framework of each standard so that, for example, evolutionary advances in

semiconductor technology can be embodied or taken advantage of without

loss of compatibility, until a new 'plateau' can be recognised which

implies major change.

290 .5

.5
A CASH HISTORY

A look at major milestones in the past fifteen years or so illustrates

how these lessons have been learned and applied In the UK.

By 1965 the advent of the integrated circuit enabled development of the

first truly modular equipment ranges to take place.

Forseeing the integrated circuit as a key element of a natural 'plateau'

- although this was before the emergence of an accepted 'world standard

IC range' - we in Ferranti developed and put into production our own

range of fast bipolar logic - DTL Micronor II - which had the inherent

environmental ability to meet military requirements. Around this we

created, by complementary technology development, a controlled electrical

and mechanical enviroment based upon multi layer printed circuits for

cirds and back planes. We engineered modular shelf based computers -

such as the FM1600 and F71600B processors - and a matching range of

peripheral control units. In all, a range of over 130 modules which

could be interconnected by the Ferranti 'B' Standard Interface.

291
4 From these we were able to construct systemi ranging from Aircraft

Carrier Command and Control systems - as on Invincible and Hermes-

through more complex systems involving direct digital control of' weapons
4 and sensors, as on the Type 42 guided missile destroyers, the Type 21 and

Broadsword Class 'Seawolf' frigates, down to the nuclear 'hunter killer'

submarines. In the recent Falklands conflict, these systems performed

reliably and well, an achievement of which we are justly proud.

In addition to operational systems, the adoption of this modular

equipment range has enabled the configuration of both tactical and

operations rooms trainers.

We were able, within the concepts of the F1600 series computers, to take

advantage of advances in technology.

* The FM1600 and FM1600B computers gave way to the FM1600D and

FM1600E computers....

* The Equipment Standard evolved, enabling a higher degree of

modularity, more flexible maintenance choices for first and second

line repair.

292
 And the printed circuit card sizes enabled, in some cases, the

* packaging of modules in ATR cases for airborne application. For

example, the FM1600D computer, heart of the Nimrod MR aircraft

'Searchwater' radar.

In all, systems based on this modular equipment range accounting for

several hundred millions of pounds sterling have been supplied by

Ferranti, of which over £100M have been for export - and sales continue

to grow.

This is a resounding success to be attributed to the adoption of

standards.

293
There is a wider lesson to be learned from this, and taken into account

in the choice of standards today. It is simply that, despite claims to

the contrary by manufacturers of equipment designed for 'soft' civil

applications, on balance military applications demand differences in

design. Principally these arise from differences in environmental

ability, affecting:

choice of semiconductor technology because of need for wide

temperature operating ranges consistent with high noise immunity

and in some areas need for radiation hardening;

choice of printed circuit board sizes and connectors, so as to meet

conditions of vibration, shock, humidity and cooling;

choice of interface standards, so as to give the required transfer

and response speeds within the number of connections that can be

allowed, consistent with pin-out limitations and emp

considerations.

choice of packaging technology to meet both environmental and

maintainability requirements.

It is for these sorts of reasons that 'hardening' a commercial design can

become not only a re-engineering exercise, but, more often, a re-design

exercise involving the loss of compatibility with its 'soft'

counterparts.

294

V *0~ * ~ ~U N -.
MOD POLICr - TE FRRAMTI ROLE

The introduction of the FM1600/FM1600B computer equipment range coincided

with the first serious attempt within MoD to define computer standards.

Driven by a concern to take advantage of development costs spread over a

wider market than that provided by the limited volume of UK military

requirements, the MoD 'Christchurch' committee came into being. Its aim

was to choose a restricted number of 'approved' computer ranges and

architectures for development and use in MoD applications, each

preferably having a sound 'commercial' base. It was assumed that

programming would be in CORAL. The arguments raged - and three computer

ranges were chosen. Of these, however, only the Ferranti F1600 Series

had an effective standard interface, and moreover, one that met the

requirements of fast, real time response oriented systems. This was

adopted by MoD and known as the 'Christchurch' interface. In retrospect

this can be seen as a key reason why - and contrary to many people's

inital expectations - the Ferranti FM1600 and FM1600B ranges have come to

dominate the UK Naval computing scene, despite the claims of alternatives

to have a wider 'civil' market.

295
The evolution and acceptance of computer standards during the 1960s and

early 1970s in the naval scene has not, however, been paralleled in the

UK Army and Airborne scenes.

By the late 1970a the MoD, alarmed by the implications of supporting an

ever increasing range of different computers, programming languages and

support software, took a fresh look at computer policy.

This time, whilst the underlying aim has been to achieve a common

software support structure, based on CORAL 66 and MASCOT with a

controlled change to Ada/APSE in time, practical considerations have

again resulted in the choice of a restricted number of computer

architectures. The principal choice is Ferranti Argus M700 series,

embodying the MoD defined local bus - the EUROBUS.

Having its origin in the Ferranti commercial Argus series, a largely MoD

funmded development prograe has produced the first military Argus

processor - the M700/20. This is based on bipolar bit/slice devices and

in engineered on two double Eurooards. It takes its place in an

increasing range of Argus M700 series modules, ranging through memories,

peripheral controllers, data link interfaces and control, monitor and

test devices. It also includes interfaces to the 1553 data bus and to

the UK Naval standard interface - the AMW Serial Highway - together with

System Development Aids such as our versatile 1553B Bus Controller.

296

M -
 M-W I TV - LN S. URT.t- . -
.. . J.. . .

Although the H700 range is sold and supported by Ferranti as an OEM

product range, licence arrangements have been signed with the MoD

enabling its manufacture by other MoD sub-contractors. In this context

licences have been taken up by Marconi, relating to its use in the

TORNADO programme; and by British Aerospace

The M700/20 is, only the first of the M700 series, having been largely

configured from 'off the shelf' semiconductor components, albeit meeting

military standards.

Again drawing on our in-house semiconductor capabilities, a VLSI M700 is

currently under development - the M700/40.

The Ferranti semiconductor technology which makes this development

possible is based on three aspects:

the attractions of the Ferranti advanced Collector Diffusion

Isolation simple bipolar process technology - FAB II;

the pioneering and leading position of Ferranti in gate arrays;

297
 -A W- -!

advances in process technology and CAD in military chip design

derived from the successful F100-L military microprocessor

programe.

Based on these attributes, the Argus M700/40 offers:

" High performance - operating speed over 1.6 MIPS

" Low Power Dissipation - typically 4 Watts

" High Resistance to Radiation Damwge.

It is designed for use in all naval, land mobile and avionic applications

- and hence to meet the full military temperature range of

0
-550 C to +125 C.

The processor package comprises four LSI circuits, mostly based on

special high performance gate arrays, mounted in 84 pin leadless ceramic

chip carriers in a single hybrid package of 56mm x 91mm.

1
Also under development is the Argus M700/ single card microcoputer.

Based on the Argus M700/40, this includes cache memory, control and

monitor logic, and FILL control; whilst for interfacing to devices off

the card, a EUROBUS peripheral interface is included, and a local

'private memory' interface.

298
i

Ferranti are heavily committed both to the sale of the Military Argus

family as OEM products, and to their use in Ferranti systems. These

include, in addition to the new areas of Naval Goummand and Control

systems wherein the M700 processors are used in a distributed form,

activities in army missile, EW and avionics appl$cations. In short, the

military Argus family will be with us for a long time to come.

THE FUTURE

The emergence of Standards in the United States is undoubtedly having an

increasing impact on the UK scene. Few would deny that there is every

reason for the UK to join in.

In this repsect Ada/APSE is a most promising start, whilst the success of

1553B speaks for itself.

With regard to computers, the question has to be asked:

'With the rapid development of commercial microprocessors embodying

architectural features hitherto associated with mainframe machines,

will the comparatively limited MIL STD 1750A architecture stand the

test of time?'

The answer, we think, is 'Probably yes'

299
 The answer to the same question in respect of the Nebula 1862 as

presently ooncevied is, in our view, debatable. Yet, a powerful putlio

domain 32-bit standard machine architecture is urgently needed.

fUTU CAN DMW

In our experience the application of standards has proved beneficial both

to ourselves as a supplier of military hardware, software and systems,

and to the customers we seek to serve.

In the choice and implementation of standards, cognisance of certain

facts of life is essential for success:

The standards must be imaginatively and yet practically chosen and

matched to natural 'plateaus' in the advance of technology.

0 Combinations of functional, environmental, reliability and

maintainability requirements militate against the simple hardening

of commercial equipment for military use. Design for military

requirements from the outset is neoessary.

300

all
 Bearing in mind the limited volume requirements of the military

market, if industry is to have the confidence to put its full

weight behind the development of equipment to meet such standards,

it has the right to expect Government Procurement agencies to exert

an element of compulsion on contractors to ensure that the

standards are applied. It also follows that MoD/DoD funded

development programmes are essential.

The time for 'public' domain standards has come. There is every
reason to expect the United Kingdom to join with the DoD in the

choice, development and insistence on use of such common standards.

Ferranti, as a major supplier to the UK MoD are committed to support such

standards as they emerge, with products engineered in leading,

competitive technology.

THE AUTHOR

Keith Dixon has been associated with Ferranti computer developments since

1965, initially for Naval applications but since 1970 with emphasis on

Avionic and other hard environment applications areas. He assumed

marketing responsibilities for military..computer LSI development and

investment in 1975, and is now responsible for marketing and sales of

FCSL standard military computer products, and of Army, Avionic and

ATC/Air Defence systems produced by Ferranti, South Wales.

301

Jl
inran~r .~. .- t,.-u~w-twt ~ ~.- ~ ~ ~ .9, ~ ~ ~.. ..- rr rurtm-~uc- rr -

Er . -
 THE AN/UYK-43(V) AND AN/UYK-44(V)

A PROGRAM OVERVIEW

Captain James P. O'Donovan, USN

Naval Sea Systems Command

Washington, D.C. 20262

(202) 692-8204

Biography

Captain James P. O'Donovan

Project Manager
Navy Shipboard Tactical Embedded Computer Resources Project
Naval Sea Systems Command
Washington, D.C.

Captain O'Donovan has served in a variety of R&D, Fleet Support and acquisi-
tion engineering billets during his career.

Tours at the Long Beach Naval Shipyard, Electronics Officer aboard USS Hornet
and Fleet Maintenance Electronics Officer on COMSERVPAC and CINCPACFLEET
staffs have been interleaved with Washington, D.C. assignments as NTDS Project
Officer for the CGN-36 and CGN-38 ship class Combat Direction System designs,
and as Director for Electronics Programs on the staff of the Assistant Secre-
tary of the Navy (Installations and Logistics).

Captain O'Donovan received his degree in Electrical Engineering from Manhattan

College and has obtained both his Masters in Electronic Engineering from the
Naval Postgraduate School and in Administration from George Washington Univer-
sity. He is also a graduate of the Industrial College of the Armed Forces.

IHe comes to his present job as PMS 408 from a tour as Commanding Officer of
the Naval Electronics Engineering Center, Charleston, South Carolina.

Abstract

The AN/UYK-43(V) and AN/UYK-44(V) program will provide replacements for

the current Navy standard computers, the AN/UYK-7(V) and AN/UYK-20(V) respec-
tively. The AN/UYK-43(V) and AN/UYK-44(V) are planned for use in all Navy
shipboard tactical systems requiring digital computers. The AN/UYK-43(V) is a
militarized general purpose large scale 32-bit computer. The AN/UYK-44(V) is
a militarized general purpose 16-bit embeddable processor or a standalone ful-
ly packaged minicomputer.

303
 Both the AN/UYK-43(V) and AN/UYK-44(V) are modular in construction to per-
mit optimal configuration according to the unique requirements of each user
system, enhance maintainability and logistics supportability, and permit
orderly infusion of advanced technology into the computer hardware.

Both the AN/UYK-43(V) and AN/UYK-44(V) are micro-programmed emulators of

their respective antecedent computers. This emulation permits use of the same
support software for systems application software development, and it allows
capture of existing software that runs on the respective antecedent computers.
Moreover, the Instruction Set Architecture (ISA) can be extended or enhanced
to meet new requirements.

INTRODUCTION

The AN/UYK-43(V) Navy Embedded Computer System (NECS) and the AN/UYK-44(V)
Militarized Reconfigurable Processor/Computer (MRP/MRC) programs will provide
a new generation of highly reliable computing resources for support of Navy
tactical systems developed and deployed in the 1985-to-1995 time frame. Both
programs are built on the current extensive base of Navy tactical embedded
computer resources (TECR). The term tactical embedded computer, as used in
this program overview, is defined as a computer or processor that is an in-
tegral component of any system or subsystem contributing to the combat cap-
ability of the operating forces. It follows that TECR then, are those
computers/processors integral to a tactical equipment/system combined with all
the software, data, support, training and personnel associated with the combat
ready status of these computers/processors.

Since 1971, U.S. Navy experience has confirmed that standardization of

TECR results in improved operational availability of deployed U.S. Navy sys-
tems because of commonality of spare parts, documentation, and availability of
trained maintenance personnel; for similar reasons, hardware standardization
reduces overall system life cycle cost. More importantly, however, Navy
standards for High Order Language (HOL) use and software documentation result
in significant savings in development and life cycle support of both appli-
cations and support software because of reusability, ease of configuration
control, and consistency in documentation for software support activities.

GENERAL DESCRIPTION

The AN/UYK-43(V) and AN/UYK-44(V) computers are planned replacements for

the current Navy standard computers, the AN/UYK-7(V) and AN/UYK-20(V) respec-
tively. The AN/UYK-43(V) and AN/UYK-44(V) will be used in all Navy tactical
systems requiring digital computers.

The AN/UYK-43(V) is a militarized general purpose large scale 32-bit com-

puter that will be available in two enclosures, the "A" enclosure (a direct
replacement for the AN/UYK-7(V) computer) and a taller "B" enclosure. (Figure
la and ib). The AN/UYK-43(V) is a software-compatible extension and enhance-
ment of the AN/UYK-7(V) computer system which represents the Navy's 32-bit
computer instruction set architecture base. There are currently over 2,OOU
AN/UYK-7(V) units in Navy applications with a similar number of AN/UYK-43(V;
applications planned. The AN/UYK-43(V) computer system will represent .:a

304
stride forward in computer capabilities compared to the current AN/UYK-7(V)
32-bit baseline. This includes 9 times the processor throughput speed, 25
times the memory space, 6 times the input/output (I/O) throughput and greater
than 3 times the reliability when configured in the "B" enclosure. The
AN/, YK-43(V) computer system features advances in maintainability, built-in
test (BIT) design and fault-tolerant architecture unmatche. by current Navy
systems. Single-button maintenance actions performed by Navy technician
A-school graduates with one additional week of specialized training will suf-
fice to diagnose and fault isolate failures in the AN/UYK-43(V) computer sys-
tem. A combination of hardware, firmware, and software modules called the
Fault-Tolerant Reconfiguration Module (FTRM) combine to provide a computer
system with no single-point failures (when properly configured). Extended
mission availability in the presence of degraded hardware is then achieveable
and tactical applications software can be executed to obtain system MTBFs
significantly beyond the 6,000-hour basic computer MTBF realizable without
FTRM (the degree of hardware resource availability in degraded mode is an
end-user system design prerogative).

Figure 1A. AN/UYK-43(V) Computers, "A" Enclosures [IBM (Left),

Sperry Univac (Right)]

305
 Figue
Coputrs
1.
ANUYK4
B"
nclour
[IB
(Lft
SpryUiac(ih)

The
N/UK-44V) samiiaie geea pups 6bt ro sor nd r

330
Figure 2A. Standard Electronic Modules (SEll) Used in AN(UYK-44(V)
Militarized Reconfigurable Processors (MRP) (IBM (Left),
Sperry Univac (Right)]

Figure 2B. AN/UYK-44(V) Militarized Reconfigurable Computers (MRCs)

['.BM (Left), Sperry Univoc (Right)1

307
 The AN/UYK-44(V) Militarized Reconfigurable Processor and Computer (MRP/-
MRC) is a software-compatible extension and enhancement of the AN/UYK-20(V)
and AN/AYK-14(V) shipboard and airborne minicomputer family which represents
the Navy's 16-bit computer instruction set architecture base. There are more
than 5,000 units of the Navy's 16-bit computer family currently planned or
installed in tactical systems. The MRP/MRC population planned over the next
decade will reach more than 10,000 units. The MRP/MRC is a noted departure
from current computer standard efforts in that the design of the component
circuit cards has been specified at the card level. With the aid of the
Standard Electronic Module (SEM) program, the Navy has directed the develop-
ment of standard printed circuit cards and card sets which may be separately
ordered and inserted into existing systems' physical equipment structures,
thereby supporting the first truly embeddable military processor. Through
this engineering approach, system designers will be able to acquire and in-
stall as many or as few computer parts and capabilities as their processing
needs demand. The MRP/MRC additionally represents advances in computer cap-
abilities as compared to the current AN/UYK-20(V) 16-bit base, including 2
times the processor throughput speed, 16 times the memory space, 3 times the
reliability and 4 times the I/0 throughput.

Both the AN/UYK-43(V) and AN/UYK-44(V) are micro-programmed emulators ot

their respective antecedent computers. This emulation permits use of the same
support software for systems application software development, and it allows
capture of existing software that runs on the respective antecedent computers.
Moreover, the Instruction Set Architecture (ISA) of both the AN/UYK-43(V) and
AN/UYK-44(V) computers can be extended and/or enhanced to meet new require-
ments. In addition, the functional partitioning of the AN/UYK-43(V) central
processing unit (CPU) and flexible bussing structure of the AN/UYK-43(V) make
it possible to emulate new or different ISAs and effectively create a family
of computers sharing common hardware with different ISAs. However, there are
no plans to do so at this time.

DEVELOPMENT OBJECTIVES

The Navy's strategy underlying the current TECR development effort can be
summarized as follows:

a. Ensure that the AN/UYK-43(V) and AN/UYK-44(V) computers meet the full
spectrum of systems requirements in terms of performance and operational sup-
port capabilities.

b. Capture and build on the existing tactical applications software

base .

c. Ensure that the AN/UYK-43(V) and AN/UYK-44(V) computers are supported

by existing programmer environments of machine transportable support software.

d. Emphasize reliability, maintainability, and enhanced operational

availability (RM and Ao ) in developing the AN/UYK-43(V) and AN/UYK-44(V).

e. Provide a family of computers with common instruction set architec-

tures and high order languages.

308
 ,
vi. -7 7 w-vVr W R". . 77777
.. '.-.'. ,.

f. Provide new computers in a variety of modular form factors and per-

formance ranges.

Do not sacrifice RM and A0 for performance in the development of

the AN/UYK-43(V) and AN/UYK-44(V).

The engineering objectives of the AN/UYK-43(V) full scale engineering de-

velopment effort that implements this strategy are summarized as follows:

1. Provide a family of 32-bit computers capable of emulating a variety

of instruction set architectures.

2. Develop a machine that emulates an ISA based upon that of the

AN/UYK-7(V) with extensions to increase the capability of the final product,
i.e., the ISA of the AN/UYK-43(V) computer is a superset of the ISA of the
AN/UYK-7 (V) computer.

3. Capture current AN/UYK-7(V) tactical applications software as a

primary design objective.

4. Develop a modular design to allow configurability to meet current

system demand, and at the same time, permit ease of field modification to meet
future growth needs.

5. Provide complete rehostable support software concurrent with computer

development to facilitate program generation facility operation.

Performance requirements for the AN/UYK-43(V) have been summarized in

Table 1.

PROCESSOR
SPEED 22111NIS CACHE).162t KIPS
MND. NS NIS (CORE)
I/OSEEO M WORDS
(22EIT$ SECOND
PERIOC
MULTI-CAIIlIET CONNECTION CISPERMITS SYSTEM MOE ABDUESSABILITY
(23n WORS) I uR CPUANDS IO'C
UPTOIS ENCLSORS MAYBEIUTIRCOONNETSO.
1/0 CHANNELS IOA$PERIOC
32 INDEPENOENT

MEMORY
ADDRESSING 326115
SIZE(IN.)IN.W.0) A-4@XIE.x2LUK FITTHROUGH
21"SUWARINEHATCH
1-lZISSXUZS
REGISTERS : SETOFTASKS
4SETSOF EXEC
BREAKPOINT
RESISTERS I SETSOFS REGISTERS

CPU1/0CONTROL CPUCONTROLS
UPTOI IOs
MTSF(MINIMUM) -m HNS
AVAILABILITY (MINIMUMI 11
.15

COOLING AIR/WATER
POWER
CONSUMPTION 2.55 WATTS
1"A"ENCLOSURE)
S.6l WATTS
("S"ENCLOSUREI

Table 1. AN/L'YK-43(V) Performance Requirements

309

4..4
 The engineering objectives of the AN/UYK-44(V) computer system development
are summarized as follows:

1. Provide a family of 16-bit computers capable of meeting a variety of

Navy applications and performance requirements.

2. Develop an embeddable version, to be identified as the Militarized

Reconfigurable Processor (MRP), as a set of modules packaged in Navy Standard
Electronic Module (SEM) Format B type hardware. Figure 2 a)

3. Develop a standalone version, to be identified as the Militarized Re-

configurable Computer (MRC), that utilizes the MRP and is a form, fit, and
function replacement for the AN/UYK-20(V). (Figure 2b)

4. Both the MRP and MRC versions emulate an ISA based upon that of the
AN/UYK-20(V) and AN/AYK-14(V), with extensions to increase the capability of
the computer, i.e., the ISA of the AN/UYK-44(V) is a superset of the ISA of
the AN/UYK-20(V) and AN/AYK-14(V)

5. Capture current AN/UYK-20(V) tactical applications software as a pri-

mary design objective.

6. Provide a commercial grade system for MRP testing and system develop-
ment, to be identified as the Microprocessor Development System (MDS)

7. Provide complete rehostable support software concurrent with computer

development to facilitate program generation facility operation.

The key performance requirements for the AN/UYK-44(V) are summarized in

Table 2 and Table 3 for the MRP and MRC respectively. The cycle times speci-
fied for core and semiconductor memory in the MRC are 900 nanoseconds and 350
nanoseconds respectively. However, performance data shown in Table 3 depicts
throughput characteristics for an MRC with 1000 nanosecond core memory and 250
nanosecond semiconductor memory respectively.
t""We tom- am-

NwoW..m (Pm Moo "mum

lamg-a

IftinWm tou

UMAU"t" *in.- Int Mim AU

aeNaAING -c iu..i.1

i nt
WAN9WA LIGU"N POLLWN M~IS

iL 0-1i11"n-

~-IIIA,
WL?4T-4IS
*A1*

Table 2. AN/U h-44(V) MPP Performance Requirements

-. ~ 9. ~ ~ ~ ~ ~ 'I 9T M 9. 310 U 9 -. .. . . . . . .~
OL~ff9-A
 LOW PERFOR- PERFOR-
HIGH
MANCE NRC MANCEIRC

THROUGHPUT SEMICONDUCTOR SEMICONDUCTOR

REQUIREMENTS COREMEMORY MEMORY COREMEMORY MEMORY

CPTHROUGHPUT 260 360 30 9i11

IKOPS)
IOCTHROUGHPUT 210 M 600 I"
IkWORDS)
RELIABILITY 8000HOURS N HOURS
SIZE 19 IN WX 2GInH X24 InD
INPUT I SINGLE PHASE.115VOLT. U OR40 HNz
POWER B THREE PHASE WYE, III VOLT, 1OR 401 N&
I THREE PHASE DELTA, EM VOLT. N OR 40 Hz
COOLING I AIR COOLED
I WATER COOLING (OPTIONAL)
MEMORY I =56KOFCORE MEMORY. 612K OF
CAPACITY SEMICONDUCTOR MEMORY ORMIX

UO CAPACITY 0 UPTO 16110 CHANNEUS OFANY TYPE, ANY MiX

WEIGHT I lIB LOS
OPERATING S -50C TO+BlC
TEMPERATURE
MAINTAINABILITY 0 UIT AND DIAGNOSTICS; liEN MirR

Table 3. AN/UYK-44(V) MRC Performance Requirements

PROGRAM SCHEDULES

In both the AN/UYK-43(V) and the AN/UYK-44(V) projects there is a com-

petitive development of two candidate systems. The AN/UYK-43(V) development
contracts were awarded to IBM, Owego, New York and to Sperry Univac, St. Paul,
Minnesota in September 1980. The AN/UYK-44(V) contracts were awarded to IBM,
Manassas, Virginia and Sperry Univac, St. Paul, Minnesota in September 1980.
Commander, Naval Sea Systems Command (PMS 408) is the Development Agent for
both systems with Navy laboratory support teams providing technical as-
sistance in the specification and testing process of the candidate systems.

The AN/UYK-43(V) Engineering Development Models (EDMs) are scheduled for

March 1983 delivery upon completion of contractor-performed, government-
witnessed testing. After delivery, additional government lab testing will be
conducted to validate Fault-Tolerant Reconfiguration Module (FTRM) perform-
ance, software transportability, automated maintenance features, and other
related performance characteristics. Source selection of the prime contractor
for the production phase of the AN/UYK-43(V) project is planned for third
quarter FY83 after delivery of candidate units. First production units are
scheduled for December 1984 delivery. (Figure 3)

311
 YEAR
FISCAL I,0 1 1, VL 9L3 . .
CALENDAR YEAR -2 1 1 13 14
AN/UYK-434V)

i ENGINEERING
DEVELOPMENT
ClONTRACTAWARD
I BEGIN
DESM
VERIFICATION
TIMT
A

EVALUATION

9 PRODUCTIONCON- 2
TRACT SELECTED
3
* NAVY LAI IO- A
DELIVERY
3S
R COMPLETE NAVY AA
LAI VERIFICATION

I 1STPRODUCTION
UNIT

I LANO-SASED iN 3
OPERATIONAL _AA
TEST S
" ASUREQUEST -
S FOT&E U.-

RFP - REQUEST
FORPROPOSAL
ASU - APPROVALFORSERVICEUSE
FOTSE - FOLLOW-ON TESTANDEVALUATION

Figure 3. AN/UYK-43(V) Program Milestones

The AN/UYK-44(V) MRP/MRC EDMa have been undergoing periodic delivery (card
sets and support systems) since 18 December 1981. Advanced Production Equip-
ment (APE) deliveries will be complete in November 1982, except for the MRC
packaged computer. Both contractor and independent lab testing is in process.
Testing will be completed by January 1983. Source selection is planned for
not later than the end of the third quarter FY83 contingent upon completion of
testing. First production HRP units will be available prior to December 1983.
Final MRC testing and MRC production unit deliveries are anticipated by
December 1984. (Figure 4)

COMPARABILITY WITH ANTECEDENT COMPUTERS

The AN/UYK-43(V) is designed to be used in one of two enclosures. The "A"

enclosure is a direct physical and plug-compatible replacement for a single
bay AN/UYK-7(V) computer. The "B" enclosure has the same footprint as a
AN/UYK-7(V) single bay, but is taller. The AN/UYK-43(V) captures any
AN/UYK-7(V) software that does not rely on:

a. Precise AN/UYK-7(V) instruction execution time dependencies.

b. AN/UYK-7(V) physical partitioning (implementation dependent configu-

ration or hardware dependent software).

312
.3~8 L..2 1.. 132L
LL~ ___

CALENDAR YEAR 79 s0 11 12 33 14 S

I
PROGRAM INITIATION
ANIUVK-(V) 11
TASKING
FULL-SCALE DEVELOPMENT,]

ISSUERFP A
CONTRACT AWARDS A
12
FIRST MRP APE DELIVERIES

FIRST MRC APE DELIVERIES A

COMPLETEMRP EVALUATION

COMPLETEMRC EVALUATION

PRODUCTION

PRODUCTION OPTION EXERCISED

FIRST MP PRODUCTION DELIVERIES
12
FIRST MRC PRODUCTION DELIVERIES

OT-11C TESTING

IMAC)
REOUEST FOR ASU

Figure 4. AN/UYK-44(V) Program Milestones

c. Use of AN/UYK-7(V) instructions which are incompatible with Navy ap-

proved AN/UYK-43(V) ISA extensions.

Software transportability is further facilitated by the provision of an

AN/UYK-7(V) compatibility mode in the AN/UYK-43(V) that is a faithful emu-
lation of the AN/UYK-7(V) CPU and IOC ISAs. The AN/UYK-43(V) can operate in
the following compatibility modes:

1. AN/UYK-43(V) executive and task program state

2. AN/UYK-7(V) executive and task program state

3. AN/UYK-43(V) executive, AN/UYK-7(V) task "mixed mode" program

state.

In comparison to the AN/UYK-7(V), the AN/UYK-43(V) provides IOC memory

protection and significant IOC Instruction Set Architecture (ISA) and computer
hardware technical features of major benefit to combat system designers and
tactical applications programmers.

The following features are noteworthy computer system state-of-the-art

implementations in the AN/UYK-43(V) design.

a. A Computer Interconnection System (CIS) that:

313

* -I~. '
 1. Provides the extension of the internal computer bus outside of
the computer enclosure.

2. Allows processors in one computer to address memory and proces-

sors in other computers.

3. Allows direct processor to memory data transfers without I/O

channels.

4. Functions within currently defined ISA specification of

AN/UYK-43(V), i.e., it is transparent to the programmer.

5. Results in a virtual computer with 4 billion words of memory, 8

CPUs, 8 IOCs, and 256 I/O Channels.

*b. A fault tolerant concept for the computer system that provides for:

1. Detection of a fault through hardware/firmware/software contain-

ment of the fault and prevention of error propagation.

2. Localization of a fault to a functional module and isolation of

that functional module from the computer.

3. Applications software notification of available computer re-

sources for applications software reconfiguration, if required.
4. On-line repair of failed functional modules and verification of
repair action.

5. Module activation and return to the computer resources inven-

tory. Applications software is notified for restoration of full capability,
if required.

c. Maximum allowable integrated circuit junction temperatures of 80 * C in

the water-cooled enclosure and 90*C in the air-cooled enclosure under worse
case environmental conditions (i.e., 50°C ambient inlet air temperature and
40*C ambient inlet water temperature).

d. Designed system redundancy that essentially eliminates single point

failures with proper resource configuration in the AN/UYK-43(V) "B" enclosure.

e. Maintainable by operator ratings with one week of maintenance

training.

A summary comparison of other AN/UYK-43(V) computer system characteristics

in comparison to the AN/UYK-7(V) are shown in Table 4.

The AN/UYK-44(V) provides a performance range to allow the user to trade

performance requirements against cost. The high performance AN/UYK-44(V) MRC
has:

a. 2 times the speed (in KIPS) of the AN/UYK-20(V),

b. 8 times the memory capacity,

314
 AISIUYK-1(V1 ANUK-43V1 IMCL Al -ANIUVK.-43(V) I&INCL
SI

THROUGHPUT (MINIMUM) 1 NOPS am1 gOps 4.91K OPS

MEMORY CAPACITY NMK 1XIM LONW

CENTRAL PROCESSORS I 1 2

INPUT/OUTPUT CHANNELS Is 24 64

MEMORY ADORESSAILITY 215K 48 43

MTSF (MINIMUM) ZK 9 S6" 6 .10

AVAILABILITY (MINIMUM) W/A 0.15 > .PS

COOLING AIR JURAWATER AIR/WATER

DIMENSIONS (WXNXDI ssxixE IN AN/IJYK-1(V) FOOT- AN/UYK-UIV) FOOT-

PRINT 41 In NEISNT PUINTISFT NEIGNT*

POWER
CONSUIMPTION
(WATTS) 2.5 2,611 Sim

1/OINTERFACES IIL-STD-13S?)
(*NEW DEII1

TYPE A - UTHS SLOW TYPE E - LOW-LEVIEL SERIAL (NATO)

TYPE I - UTOSFAST TYPE F - *L-Sfh-1U2
TYPE C - ANEW TYPE a - RsS415 (-lUCOUPAIKUE)
TYPE 0 - SERIAL INTO) 'TYPEH - TYPECCOMPATIBLE
NISH-TUROUSNPJT PARALLEL
119IIm1103-40 WOuhSISEC)

Table 4. A/TJY-43 CV) Comparability to AI4IUYK-7(V)

c. the same number of 1/0 channels (higher throughput capability), and

d. .1.25 times the reliability.

Table 5 compares an AN/UYK-20(V) maximum configuration to that of a high

performance AN/UYK-44(V) MRC. The ISA of the AN/UYK-44(V) is a superset of
the AN/UYK-20(V) ISA, which allows the direct capture of AN/UYK-20(V) software
and use of existing AN/UYK-20(V) program generation facilities. The advance-
ments that the AN/UYK-44(V) provides over the AN/UYK-20(V) that will be of
most interest to combat system designers and tactical applications programmers
are summarized as follows:

a. Low and high performance embeddable card sets designed on SEX Format
B form factor for use in distributed processing and qualified to Level II SEX
environmental requirements (including 70K feet altitude testing).

b. Memory addressing increased to 4096K words.

C. Two modes (executive and task) of program operation.

d. Memory protection and malfunction detection.

e. Memory-mapped I/0 provided for 64 devices independent of the IOC

315
V ANIUYK-20(V) AN/UYK-44(VMRC

THROUGHPUT: 450 KIPS 350 KIPS TO 900 KIPS

MEMORY CAPACITY: 65K 512K

CENTRAL PROCESSORS: *

I/O CONTROLLERS:

110 CH4ANNELS: 16 16

MEMORY ADDRESSAIILITY: 86K WO RDS 4M WORDS

MTIF: 4000HMRS 6000NRS

COOLING: AIR AIRIWATER

DIMENSIONS 101=11"X241, t,"X20ir

POWER 1000 WATTS INI WATTS

WEIGHT 220LU 16 LIS

*THE AN/UYK-20(V) CONTAINS A SINGLE MNICRO-CONTROLLER FOR CPU AND IOC

INSTRUCTIONS SUCH THAT THE CPU AND IOC ARE NOT INDEPENDENT.

Table 5. ANIUYK-44(V) MRC Comparison with the AN/tTYK-20(V) Computer

f. Memory management instructions allowing unpaged access.

S. IOC functionally independent from CPU.

h. Up to 4 I9OCs for a total of 64 I/0 channels.

i. Specified AN/AYK-14(V) CP Instructions in addition to AN/UYK-20(V)

J. AN/AYIC-14(V) Extended Arithmetic Unit (EAU) instructions added to

MATH PAC.

k. Page registers increased from 1 to 4 sets of 64 registers.

1. Improved RMA

M. Lover power and weight.

n. Increased throughput.

o. Packaged Militarized Reconfigurable Computer that uses either the low

or high performance MRP card sets.

COHPUTER MODULARITY

Both the AN/UYK-43(V) and AN/UYK-44(V) are modular in construction to per-

mit optimal configuration according to the unique requirements of each user

316
 system. In addition, their modular nature enhances maintainability and
logistics supportability. This modularity also permits orderly infusion of
advanced technology into the computer hardware to improve performance and/or
reliability, or to reduce size, weight, power consumption, or cost.

The AN/UYK-43(V) and AN/UYK-44(V) are required to meet or surpass all the
applicable Navy invoked specifications for shock, vibration, air and struc-
tureborne noise, electromagnetic compatibility, electromagnetic protection,
safety, electromagnetic interference and environmental stress testing in ac-
cording with MIL-E-16400(G). In addition, the AN/UYK-44(V) design discipline
is specified in accordance with MIL-M-28787 for standard Electronic Module
(SEM) design.

The details of the AN/UYK-43(V) computer system's modularity are presented

in Figure 5. The architecture of the AN/UYK-43(V) "A" and "B" enclosures pre-
viously described are depicted in Figures 6 and Figure 7 respectively. In
each figure, the salient features of the architecture are listed.

ENCLOSURE TYPES
MODULES A 3

CPU$ 0-1 0-2

IOCs 0-1 0-2

I/O CHANNELS -24 0-4

MEMORY MODULES 0-5 0-10

POWER SUPPLIES 1 2

CiS 0-1 0-1

O/CP 1-2 1-2

ROCU 0-1 0-1

SIZE (WXHXO INCHES) 20X41X22 23X72X22

WEIGHT (POUNDS) 5"0 710

POWER (WATTS) 266 5506

CONSUMPTION

Figure 5. AN/UYK-43(V) modular Enclosure Configurability

The "A" enclosure is intended primarily as a plug-compatible replacement

for the single-bay AN/UYK-7(V). The "A" enclosure provides improved perform-
ance (e.g., with cache memory, 4.5 times the AN/UYK-7(V) processing capabil-
ity, 3.5 times the I/O throughput capability, 50 percent more I/0 channel
capacity, and 14 times the memory capacity), a Fault-Tolerant System Reconfi-
Zuration Module (FTSRM), and an extended architecture in the same physical
envelope.

317

',, . oi-
r.. _ %,..,'.''.V',V
. , ; , '- , ' ,,-.'% * 'r ,.--~
*%*.,'.v *,.,V N
. . **' 5,. : .- S
 EXCSUREA 2 U
CIHANNELS

SALIENT
ATTIBU6TES
I FAULT-TOLERART
DESIGN I AUTOMATES
MAINTENANCE
FACILITIES
- AUTOMATIC
DETECTION I EXTESSIVE
PSRPOMOANCE
MONITORING
ANS

:3-
PROGRAMSVE FEATURES
- AUTOMATIC
RECOVERY
O iuPU COBIROLLIR- 00C)
M7UTU
CASUALTY
REACTIONI
HIERARCHY ARITHMETIC
PROCESSING
CAPABILITY
TO
- PAULT-TOLERANY
ANDSYSTEM
RECONFIGURATION
MODULEIFTAM) S CPU-40C
EFFECTIVELY
CREATESI
DVAL
- TEST)
BIT(SEULT-4B
0 335241SITSCOREMEMORYWODLE
ISMUM
- PARITY
OffCOREMEMORY
ANDMODULE IiE 015X34BIT MAX)
DATATRAIPERS
O BUX31 SM EMI-COOUCTOR MEMORY
MOULE
- ERROR
CORRECTION
ONBNENCONDUCTOR MW" SIZE(11039 SETS
MAX)
MEMORY

Figure 6. AN/UYfK-43 CV) "A" Configuration Architecture

CNMMI CBAMI

MOTE: UORMILLUTRTE EACHREOUESTR LEMEMORY

OWMACM 3115:
000O MAYNCLUKN WES U FIUESTER
SAUSUWT
ATTINFINIS
IS ENCLOSURE
A ATTUOUTUP331*85

- SUALPSUER
SUPPLIES
- PULL IYRCONUCTIVITY OP
REVUSMABS IMMOY
- SYSTEMSRVIVABILITY
HARDWARE
IBUILT-IN1 REDUNDANCY
07" SOPTURI AILITY To
RECONFIGURE)
U. S~CPII.-WACEPPECTYELY
CREATEDVOUR
PROCESE CAPABILITY

Figure 7. AI(/UYK-43(V) "B31Configuration Architecture

318

'' B ' ~ '~g~% B'B~%w B

 The "B" enclosure is the centerpiece of the AN/UYK-43(V) system. It is,
in effect, a fully redundant, duplexed system in a single enclosure. It pro-
vides more computing power than two four-bay AN/UYK-7(V)s (five times the
memory), while occupying one-eighth the deck space and consuming one-fourth
the electric power. The "B" enclosure can contain twice the functional
modules of the "A" enclosure. In addition, a complete fault tolerant reaction
and on-line automated maintenance facility can be employed to yield a very
high system level MTBF/availability. The "B" enclosure has independent memory
modules providing a total of 2.56 million 32-bit words of main memory or 10
million bytes of memory. The two CPUs are capable of performing 4.5 million
instructions per second (cache), and two IOCs can transfer and process I/O
data at a rate greater than 6 million words per second over 64 I/O channels.

For either enclosure type, each I/O channel may be independently selected
from a set of eight standard interfaces. The Computer Interconnection System
(CIS) allows the system designer to implement a virtual multicomputer proces-
sing complex in which a processor in one enclosure may have direct access to
memory modules and initiate I/O chains in as many as 15 other enclosures or
peripherals.

AN/UYK-43(V) makes extensive use of the latest Large-Scale Integration

(LSI) and Very Large-Scale Integration (VLSI) technology, providing for com-
puter reliability, maintainability, performance, and capacity far superior to
earlier military computers at lower costs. The basic architecture and physi-
cal and functional partitioning of the AN/UYK-43(V) are designed to facilitate
the infusion of future technologies. The design allows upgrading of a func-
tional module with no impact on other functional modules or the interconnec-
tion bus system. The AN/UYK-43(V) design allows for the emulation of a wide
'variety of ISAs through microcode changes and/or processor replacement. New
instructions may be easily added to the present ISA via microcode changes. A
complete ISA change may be accomplished by the replacement of the processor
with one that executes a different ISA. The new processor need only meet the
physical, bus electrical, and protocol specifications.

The AN/UYK-44(V), as previously noted, is deliverable as an MRP card set

implemented on SEM Format B modules with standardized I/0, common data bus,
low power consumption, user configurable memory, and power supplies. Addi-
tionally, it can be ordered as an MRC computer in a standard mechanical en-
closure that is compatible with the AN/UYK-20(V) footprint, possesses standard
I/0 interfaces, incorporates the MRP and many of its options, possesses up to
1 million words of memory, up to 2 IOCs, a 32-bit serial and/or parallel I/O
channel mix, and is rack or deck mountable in either an air or water cooled
uconfiguration. Further, the AN/UYK-44(V) MDS can be acquired to support the
embedded MRP with optional features, and utilized to support operation and
test of the MRP and AN/UYK-44(V) software debug and test functions through an
4interactive display/ keyboard interface.

The generic architecture of the AN/UYK-44(V) is shown in Figure 8. The

MRP as shown may consist of:
a. A low performance or high performance processor and some combination

of the following optional features.

1. 1/0 Controller (IOC)

319

""
 MEMORY !EXTERNAL
DEVICES
I I I (UPTO 4)

SOOTSTRAPMORY MEMORY
INTERFACE I/O
MEMORV-MA1PIO

CONTROLBu
EXTERNAL
p -- PROUIOR
TENTRAL
CONTROL PANEL .W OROL AgD HAUNTIl!
EXTERNAL
INPUT REAL-TIMEAiOMONFTO CLOC"

MATHPAC Io

USIAaROWH
I MEMORY
MANADEMIENT

MEMORY
ADORESEXPAN

Figure 8. AN/UYK-44(V) Generic Architecture

2. I/O Channel Adapters

3. Control and Maintenance Interface

4. MATH PAC

5. Bootstrap Memory

6. Real Time and Monitor Clocks

7. Memory Address Expansion

8. Memory Interface Modules
9. Memory Mapped I/O Modules

10. Direct Memory Access (DMA)

Key performance characteristics of several of these options are summarizEld

in the following paragraphs.

a. The AN/UYK-44(V) I/O function allows for:

320
 i. One to four I/0 controllers

2. Independent operation of each IOC

3. Up to 16 I/0 channel adapters (serial and/or parallel) per I/0

controller

4. Up to 32 program initiated I/O chains per I/0 controller

5. I/O instruction repertoire - same format as CPU

6. Optional memory address expansion to 4 million words

b. The I/0 Channel Adapters (IOAs) are implemented in two channel groups
for the following standard interfaces:

1. PARALLEL CHANNELS

(a) MIL-STD-1397, TYPE A

(b) MIL-STD-1397, TYPE B

(c) MIL-STD-1397, TYPE C

2. SERIAL CHANNELS

(a) MIL-STD-188C, SYNC, ASYNC

(b) EIA-STD-RS-232-C SYNC, ASYNC

(c) VACALES

(d) MIL-STD-1397, TYPE D

(e) NAT-STD-4153 (PROPOSED TYPE E)

(f) NAT-STD-4156

c. The MATH PAC module functions include:

1. Square root

2. Trigonometric and hyperbolic vector and rotate

3. Floating point arithmetic, square root, trigonometric,

exponential and natural logarithm

4. Double precision multiply and divide

5. Algebraic left and right quadruple shifts

d. The Real Time and Monitor Clock and Bootstrap modules provide:

1. 192-word Bootstrap capacity

321

' T'.'- 'a"." "

,....
: ' "e ;" ",)'"";"Z e%"** ." -' ""'"'' ' A " , ;"..."'"
-- ,-- -. ' " I
 2. Preprogrammed or customer defined microcoded instructions

3. 32-bit Real Time Clock

4. 16-bit Monitor Clock

5. 1 KHz, 32 KHz, or external clock rate up to 50 KHz

e. The Memory Address Expansion module allows for addressability up to 4

million words via four sets of 64 -page registers.

f. The Memory Interface module provides access to a maximum of 8 memory

modules of up to 256K core memory words or 512K semiconductor memory words (or
a mix of both) with a cycle time range of 250 nanoseconds to 1000 nanoseconds.

g. Memory mapped I/O (MHIO) modules allow the CP and/or the IOC to com-
municate with peripherals by treating the control and data registers of each
memory mapped I/0 module as memory locations. Features of the MMIO capability
include:

1. Reduction in memory conflicts

2. Maximum of 64 MMIO devices per processor with a 250 nanosecond

cycle time

3. Asynchronous timing

4. Parallel or serial data transfers are permitted.

h. The AN/UYK-44(V) MRP provides a DMA capability which allows interfac-

ing directly to the common data bus. The DMA capability is compatible with
the AN/UYK-20(V) design.

The AN/UYK-44(V) MRC includes the MRP and selected options plus a single
DMA channel per MRC cabinet. In addition to the features shown in Table 5,
the MRC design provides for an expansion cabinet option containing one IOC, 16
I/0 channels, and 512K semiconductor or 256K core memory.

COMPUTER MAINTAINABILITY

a. AN/UYK-43(V) Summary

The AN/UYK-43(V) achieves a 15 minute Mean Time To Repair by using

on-line and resident diagnostics to isolate computer faults to a single Line
Replaceable Unit (LRU) 90% of the time, and to within three LRU's 98% of the
time. Ease of access, modular construction, fault tolerant design concepts,
on-line repair capability and simplified personnel training all contribute to
ease of maintenance. The AN/UYK-43(V) requires no periodic preventive mainte-
nance other than monthly cleaning of filters, lubrication of doors and similar
actions not of a time critical nature and not requiring system shut-down to
accomplish. All LRUs are readily accessible and can be quickly removed and
replaced without special tools.

Maintenance can be performed by a class "A" electronics school graduate

322
 76 z N!

with 36 hours of special training.

Fault tolerance is achieved through built-in reliability, hardware redun-

dancy, and hardware/software features which isolate and identify faults with
the aid of automated maintenance facilities.

On-line repair is implemented in a user-friendly fashion and is concurrent

with other computer actions. The operator sees an alphanumeric display with
clear, concise repair instructions. Only a single button is pushed to execute
diagnostics. Modules that have not experienced failure continue to process
normally. The system is not taken down or off-line to isolate the failed LRU.

b. AN/UYK-44(V) Summary

Using advanced Built-in-Test (BIT) microcode firmware and macro self-

test programs, the AN/UYK-44(V) achieves a Mean Time To Repair (MTTR) of 15
minutes. The diagnostic and BIT system detects at least 98% of all MRP/MRC
malfunctions, including those preventing successful program loading, and will
isolate at least 80% of all detected malfunctions to a single module, at least
95% to two modules and at least 98% to three modules. The microcode firmware
coupled with the macrodiagnostic provides an easy to use, minimum experience
to operate and fast malfunction detection capability as a means of achieving
ease of maintenance on the AN/UYK-44(V). Corrective maintenance is primarily
accomplished with pluggable modules, with only one preventive task (cleaning
filters) required of the MRC. All maintenance tasks can be performed easily
and do not require high skill level personnel, extensive support equipment or
extensive documentation. With the exception of the rear-mounted I/O channel
cable connectors, all replaceable elements of the MRC are accessable through
the front cabinet doors.

An easy to use operator and maintenance panel mounted on the front of the
MRC simplifies and reduces MTTR. This panel consists of a function/mode
select keyboard and an operator interface display. The microcode firmware can
be executed as an in-line macroinstruction, as a press-to-test operation en-
abled through the operator and maintenance panel, or at initiation when the
stop/master clear switch is momentarily depressed. Once diagnostic testing is
initiated, fault isolation is accomplished by display of fault group numbers
providing direct reference to the failed module(s).

CONCLUSIONS

Current U.S. Navy standard shipboard computers no longer have sufficient

performance and capacity to satisfy current and projected operational require-
ments. The limited performance and capacity of current standards is causing
increased life cycle costs for tactical embedded computer resources due to re-
quirements for complex system architectures to overcome performance/capacity
limitations, and complex system software designs to support these complex
architectures.

The new generation AN/UYK-43(V) and AN/UYK-44(V) will provide required

Navy operational enhancements and will yield significant gains in reliability,
maintainability, availability and fault tolerance at a substantially lower
life cycle cost to the Navy. Software capture will retain the substantial
investments in existing Navy software. Commonality of spares, training,

323 a
 technical manuals, software, maintenance and operator interface will allow
interchangeability of equipment and personnel between platforms and between
systems on the same platform. During critical operations, computer system
availability will be significantly increased. Standardization will allow cost
effective evolutionary preplanned product improvement upgrades of memory
capacity, ADA capabilities, and VHSIC-like technology insertion. The physical
and functional partitioning of the AN/UYK-43(V) and AN/UYK-44(V) are designed
to facilitate the infusion of future technologies to maintain these computers
on the leading edge of the produceable computer state-of-the-art.

324

.*. - 9 * ...
*~ * ....... * * ' " . .*
 GLOSSARY OF ABBREVIATIONS

A0 Operational Availability

APE Advanced Production Equipment

BIT Built-in Test

CIS Computer Interconnection System

DMA Direct Memory Access

EAU Extended Arithmetic Unit

EDM Engineering Development Model

FTRM Fault-Tolerant Reconfiguration Model

FTRSM Fault-Tolerant System Reconfiguration Model

HOL High Order Language

ISA Instruction Set Architecture

LRU Line Replaceable Unit

LSI Large-Scale Integration

MDS Microprocessor Development System

MMIO Memory-Mapped I/O

MRC Militarized Reconfigurable Computer

MRP Militarized Reconfigurable Processor

MTBF Mean Time Between Failures

MTTR Mean Time to Repair

4

NECS Navy Embedded Computer System

RM Reliability and Maintainability

RMA Reliability, Maintainability and Operational Availability

SEM Standard Electronic Module

TECR Tactical Embedded Computer Resources

VHSIC Very High Speed Integrated Circuit

VLSI Very Large-Scale Integration

325

-. U . ft~~t
.ft *. *U ~ ftU ~ %'V V ~ ~
 AN/AYK-14 (V)
STANDARD
AIrbOrNE

Henry H. Mendhall
Cruiputer Resources and Avionics System Division
Naval Air Systems Commad
Washington D.C. 20360

327

i •
-g .9 t h~ ' '
 N4~40
*r MC -4 r4 -I4
L. C0~~ V:r04) Cm.F
cd0rG co0i 04 "
r C. to

4C a) to 0 0m
.0 V4V CC U))
v Lm .4 "q a(1 16~4 0 c >
0 00 L f> .i 4 )0
4) 04) 0 C )0 L4 o
0 4)ML C4 z V M
:3 CL 4)E-4 w 0 4U 4)
bc0 4) .C -4 C . LU)
0IDw c
-r4 43E0 a Cdvs
tI w 114 4) -4 V4 0
>%
) - 0 L.4)0 4 1
0a s) 0 l0 a L V U
0400O.41 A40
K LU))r-4 CJ)M IC 0 E

>0 U 940 ~i.0o ) . i4)

L. m 43 :3
L C -4r- X
> 0c 4) C 0CvM-dC:-r b
0O"4 44 -4 0 r- C . l 4C 9:.
>4 t )P4 -o 4 >~ 0cL
ir r IIM 0 L 0 w 0 9 :909)*f LxC

94 r L .) c V 03It S 4)04 -4 -I44 r

~L.i4 4)0U 0 co W v
OPI In0 0 0c IU. M 0~I
U) Oi4J C ) -iC: L.
0 0 4'r-~.. *. 0) L
-' 4 4"f44 0
-4C r4 t 40 4)L r

0 L0
. v .4 4 W ac0 4j a) r4 'M 4
0 U 0C Ve4 9..- 4 toUV-4CaJC
00 U 0) -4 tn -1 0 2C) 0-4 (
Le 0. r~-4 0.40U t 0m 0 V4 a f-I
z)C V))0.C r4 .iW4 cc LXO.0).v
cd I-40
4) AT 0 C "4 0 -I 0

0h. 0.'b c .C0-Gr.

I" "1 4)
L.E4) -4 - 4)5-0 030 00

ho a
0 - 4 E*4 1 %- 0 Lc 0
t' d0cU)V) 0.
m0 r.UL
-T 9 4 4) Go L O r44
M. L 4 )-4
I )L . 4)C = 4) m4J
" C)"4:
bd 0 v.S. 0 4) . 0 )
V,4 z 3:
:0.4 L. 0 6 43c 4 ) S..)tos 00
%11 CLCC4v00 94 4)4)
0 4) C L 04)- 40C L A .) 4JL0 II
*0E 0 4U)0 3 414&00 L a) L5e4
A E 0a4)0 n0 4)3U C0U 0
W4 A.j ro*--4 0Or-4.) c 004.
00.#4) .o -4 0.O. 043a

327 a.
 iu
0

328
 LLI:

U 2 =

dI.

0 0 0

3
I ..I ....
 -7-767-7

uE
(4W
O) I

00
0
02.., I-

0 UCa

no 0 4 g I

z _ o(4 :R
2 .L

ul 0

UNW N0 l (c5
.4~~ 0 (al~
00 0 0E

330
 It

0""m 0

II I-
z

331

p - *. * .. *'*'j*******~~~*-1
 I-I

CO)

>-
- 0

Z0
>0~~ LUL.0
0 QW 00f
=I ) IL

w. w
w 0..iE E CC
2
44M~- 00

(0W .oZ cc z
~A . 00w
* 6 0

332A

a I
cc.

ou zo Ai
FR~rww

ul0

cc 0
0% Ul

>- I- I

>00

cc
0 0 0

333
 CO)
2 r14 kl l9 a
I-L In ILa
UO)

a CA
an 0

>. w
z 0S.

2 0 0 0 0 0 0

334
.4

LUU

, !=J
_ _+ __ 1.n
> 0 it _ _ _ __

a 411
a .

SI IU335

335

4J
 z I-

20 z
> p

w 1-w 0
00c
IL* N

a
0Uacc 0
0 ~ 2
cc WW A

z A.
cc Z -E -
L tEo
>0
z cC > z

4Uc

336
 ~. ~ F~ ~F.27?9 rr.9~ ?'~ V ~ ~ . R .

zI

4 LU

> 2C
=a.
wamov
q. w
cc A

zuL

> wl

lU U

4 S S 0 0 0

337

w'~~ vow "FWWM -- -1

 Biography

Henry H. Mendenhall
Computer Resources and Avionics Systems Division
Naval Air Systems Command
Washington, D. C.

BSEE Drexel University, Philadelphia 1968

EXPERIENCE

14~ years with the Naval Air Systems Command in Avionics computer and software
Systems.
CURRENTLY

Section Head for Advanced Computer Systems

Responsible for planning, engineering and acquisition of Navy standard and

planned standard computer resources.

338
ADVANCED SYSTEMS ARCHITECTURE

SESSION CHAIRMAN: Major 1. Caro

AFWAIJAAAF

MODERATOR: Colonel David J. Teal

F- 16 Deputy System Program Director
 -. *. . . 71 . . .- - 7: '

B-IB AVIONICS APPLICATIONS OF MLITAR STANDARDS

L. M. Carrier
and
G. A. Kinstler

Rockwell International, North Anerican Aircraft Operations - Avionics

2770 E. Carson St.
Lakewood, CA 90712
(213) 420-0290

Military standards applied to the B-lB avionics program are discussed.

Eahasis is placed on aircraft electronics systems design and interface with
the aircraft. Subsysteu discussed include the Central Integrated Test
System (CITS), Electrical Multiplex (EMUX) system, control and displays,
weapons interfaces, and Cmunications And Traffic Ontrol (C&IC). Standards
applied to offensive and defensive avionics are also sumarized. Program
constraints and rationale pertinent to the partial or deferred application
of some standards are discussed. The extent currently applied and options
planned for future incorporation in these areas (e.g., MIL-STD-1589B, -1750A,
and -1760) are presented.

INDTROXTric

The application of military or government standards to the architecture

and subsystem design of the B-lB is advantageous to minimize the total cost
of ownership. Cost savings accrue from such factors as:

1. Reduced acquisition cost due to standards encouraging the use of

previously developed techniques, oArLPnents, subsystens, or software
applicable to other military programs. •

2. Reduced support costs resulting from training transferability and

catmmality of maintenance actions and logistics support from other
programs.

ckwell has supported the application of current standards to the B-lB,

consistent with the B-IB development schedule. In some cases, standards have
been partially incorporated or other special considerations have been made
to allow future application of developing standards. Bquipment elements
selected for the total B-IB avionics suite were, where possible, the USAF
standard or preferred iten, or a current inventory iten omTmn to other programs
such as the B-52 Offensive Avionics Systen (OAS).

This paper presents an overview of the B-lB avionics suite and identifies
the standards applied, partially incorporated, or provisions made for future

341
IS BLANK
 standards incorporation. The discussion is organized into the following six
avionics areas:

1. ommunications and Traffic Control (C&TC)

2. Central Integrated Test System (CITS)
3. Electrical Multiplex (EMLX) systen
4. Flight Instrents Subsystem (FIS)
5. Offensive Subsysten Group (OSG)
6. Defensive Subsystem Group (DSG)

Though rxt further discussed separately withi.n the following subsections,

the B-lB program is currently in the acquisition process for automatic test
equipment supporting all of the above equipment areas at the intermediate
depot and shop level. It is intended to employ the new Modular Automatic
Test Bquipment (MATE) standard in this area to the maxinun extent possible
within B-lB program constraints.

C4MMtICATIONS AND TRAFFIC CONTL SYSTEM

Figure 1 presents a block diagram of the Cuunications and Traffic

Control (C&TC) system. Dual AN/ARC-171 UHF radios provide redundant line-
of-sight cmmunications capability. The SEC/KY-58 (USAF standard) secure
voice equipment provides encrypted voice transnissions over UHF. The AN/ASC-19
Satellite CaruMUications (SAT'M4) terminal permits world wide comunications
capability for voice or teletype messages. The new USAF standard TACAN, the
AN/ARt-118, provides navigational range and bearing information. High fre-
quency (HF) comuunications provide two-way voice cnnand and control capability
for the B-lB. The AN/ARC-190 HF radio is a new production equipment. The
AN/ARC-190 HF coupler is a CFE iten, modified from existing hardware to match
*the B-lB shunt-type antenna system. The AN/ARF-108 Instrument Landing System
(ILS) is the same as used on the B-lA and provides localizer, glideslope,
and marker beacon functions. The AN/APX-101 Identification Friend or Foe
(IFF) transponder used on the B-IB is the current USAF standard and, in con-
junction with the KIT-JA/TSEC secure IFF, provides a comprehensive identi-
fication capability. The AN/APX-105 rendezvous beacon used for the B-IB is
an X-band transponder. It is the same as used on the B-IA, except for a
connector change made to comply with current B-lB connector requirements.
It is being provided as CFE on the B-B. The ICS-150 intercom system is also
being provided as CFE. This systen does not yet have a military nomencla-
ture assignment since it is a new development for the B-lB. It is a lower cost
form, fit, and function replacement for the intercom system used on the B-lA.
Low Frequency/Very Low Frequency (LF/VLF) receive-only teletype message
terminals are expected to beccme available for the B-lB during the later
years of production. This is expected to provide a very long range jam-
resistant counvnd and control line to the B-lB.

342
 CENTRAL INTEGRATED TEST SYSTEM

The Central Integrated Test System (CITS) is an on-board B-lB aircraft

subsystem interfacing with but completely independent of aircraft avionics and
non-avionic operational systems. It provides real time functional testing and
in conjunction with the B-lB offensive and defensive systans provides functional
testing of all subsystems aboard the B-lB aircraft. To accamplish this, the
CITS utilizes techniques and procedures proven on the B-lA aircraft which max-
imize passive monitoring of end-to-end subsystem testing during normal operation
of the subsystem and minimize active interference during ground testing of sub-
'a systems without the aid of ground support dquipment.

The CITS is essentially a digital data processing and control systen with
elements dispersed throughout the air vehicle for acquisition and conditioning
of parameters from electrical, mechanical, hydraulic, etc. systems. A block
diagram of the CITS is shown of Figure 2. The CITS systen consists of a dig-
ital coimputer and a resident stored software program to control processing,
four Data Acquisition Units (DAU) for interfacing with aircraft systens to
transnit/receive test signal data, a CITS Control and Display (CCD) panel for
operator interface, an Airborne Printer (AP) to provide a "hard copy" of test
result data, and CITE Maintenance Recorder (CMR) which provides a magwtic tape
output for ground data processing and analysis.

The CITS testing functions are essentially automatic, with a mininun of

operator participation. All test logic is predetermined and fixed within the
software program, thus eliminating the necessity for the operator to inter-
pret results or make decisions as a part of the normal testing process.
In flight, CITE continuously monitors parameters frm the systems under test
and utilizes the signal data in performing over 4000 tests each second. Mal-
functions of systems under test are displayed to the flight crew with isolation
of failures being made to the Line Replaceable Unit (LA) level. This permits
an immediate evaluation of the situation and allows the pilot to make mission-
oriented decisions. If recessary, further data may be manually accessed
by the flight crew using CITS to individually select and display the value/
state of over 10,000 signals on the B-i.

All malfunction data displayed by CITS (identification of the failed

system, identification of failed LU, time of failure, and associated messages)
are printed on a paper strip tape which provides maintenance personnel with an
imnidiate view not only of trouble areas requiring maintenance action, but
also of most probable corrective action required. This information, sub-
stantiated and supplemented by flight crew "squawks", allows maintenance oper-
ations to begin unhampered by the normal procedures of investigation of flight
crew reports, hook-up of ground support test equipment, conducting of tests,
and interpretation of test results. These tine consuming tasks delay corrective
action, after which the same tasks must be repeated to verify that the original
problem was corrected. The success of such procedures is

343
highly dependent upon the skill level and special knowledge of the tech-
nicians performing the maintenance, the availability of properly trained
personnel, and the availability of a wide variety of special test equipment.
Each of these negative elements is affected positively through the use of
CITS. Special knowledge of a particular system undergoing test of mainten-
ance by a technician is reduced without detracting from confidence in results,
which in turn means that lower skill-level personnel can be assigned to
maintenance tasks; elimination of the need for special test equipment does
away with not only the tire required to position and connect the equipment,
but also reduces the number of people needed to handle and maintain the
equipment. This is of paramount importance in an operational environ-
ment where austere bases demand that aircraft be self-sufficient. The CITS
colputational system employs the current military standard nultiplex data
bus, MIL-SID-1553B, to interconnect all elements of the system, except for
the CITS Maintenance Recorder (CMR) which employs a B-52 OAS version of MEL-
STD-1553A.

The CITS central processor is a high speed, general purpose, dual

architecture machine derived from the merger of the B-52 OAS Instruction Set
Architecture (ISA) and the ML-STD-1750A ISA. It is common with the processors
used for offensive and defensive systems. The implementation of MIL-STD-1750A
ISA in this processor is presently scheduled for SEAFAC verification during
1983. The processor in conjunction with special test equipment can execute
either an advanced version of the B-52 OAS instruction set or the MIL-STD-1750A
instruction set. The common processor is currently being configured to execute
coding using the improved B-52 OAS instruction set architecture. Common
processor conversion to the MIL-STD-1750A ISA can be accomplished by minor
firmware changes at such time that the software is ready. The CITS software
is currently 75% programmed in the J3B higher order language (the remainder coded
in assembly language). It is anticipated that conversion to the lvIL-STD-1589B
(J73) higher order language will occur concurrently with the conversion to the
MM-STD-1750A ISA discussed above.

ELfRICAL MUTIPLEX SYSTEM

The Electrical Multiplex (HKUX) system is a digital time division multi-

plex system which transmits control and data signals over redundant data buses.
All B-lB aircraft electrical control signals are nultiplexed where practical.
The ED4X system reduces the point-to-point "hard" wiring, conventional signal
wiring and the associated hardware required, permitting a savings in both
weight and installation costs. The use of EMX provides additional advantages
of (1) improved reliability, (2) more flexibility, (3) greater maintainability,
and (4) reduced battle damage vulnerability for the aircraft electrical systems.

The DIJX system provides the function of accepting, formatting, transfer-

ring, performing logic and control functions, and outputting signals required
for aircraft subsystem electrical control, data transfer, and function mon-
itoring. The D= system serially transmits the signals over redundant cir-
cuits (data buses) by using Time-Division Multiplex (TDM) techniques and base-
band transmission. The &MX system consists of the following equipment:

344
two Control (CONT) boxes (bus controllers), ten digital Data Distribution
(DD) boxes, and one CITS Interface (CI) box. Their placement in the aircraft
is illustrated in Figure 3.

A redundant data bus interconnects all EVX boxes which are distributed
throughout the major equipment areas of the aircraft. Data transfer is con-
trolled by the CONT boxes which have logic processing capabilities sufficient
to perform sequencing, interlock and other control and load management functions
involving the discrete signals associated with the aircraft subsystems
electrical power distribution and control. The EKJX data sequencing, logic
processing, and load management functions are capable of being changed, pro-
viding the required control flexibility.

The E(JX system utilizes high density microelectronics and solid-state

parts, components, and circuitry to achieve small size, low power utilization
and high reliability. The EXJX is hardened to withstand nuclear radiation and
Electromagnetic Pulse (EMP) environments. Component and circuitry redundancy
provide that no single failure within an EX section will affect the data
transfer and processing of that section. Each E rA box has self-test functions
to determine failures and to switch over to redundant circuits or, if appro-
priate, to the redundant OONT Box. The EMJX self-test data is transferred to
CITS via the CI Box. Each (XNT, DD, and CI box has provisions to prevent
box damage due to overtemqerature conditions during ground maintenance modes.

Rockwell recognized that significant development effort was required to

implement MIL-STD-1553B in the EMUX system. While Frckwell supports the Air
Force's initiatives for standardization, it was recognized that substantial
schedule risk and cost impact would result. Since the EMVX system is an
existing design and is a stand-alone-system, few of the benefits of standardi-
zation would be achieved.

The evaluation of incorporation of MJL-STD-1553B into the B-lB EMX design

required consideration of the following signficant factors:

1. Development cost
2. Production cost
3. On-aircraft maintenance cost
4. Off-aircraft maintenance cost
5. Training cost
6. System modification and upkeep cost

Development costs would increase significantly because EMX with -1553B is

more complex and development schedule requirements will not permit the incor-
poration of an E4U system with -1553B into the Lot I and Lot II aircraft. A
new EBJX system, incorporating MIl-STE-1553B could only be installed beginning
with Lot III. This would necessitate two separate parallel development efforts.
Production costs would increase because of the increased complexity of the EMUX
units with -1553B incorporated and also the production learning curve would be
set back due to the introduction of a new design at Lot III.

345
 W- -.

On-aircraft maintenance wuld not be significantly different with -1553B. In

either case, EMEX reports its status to CITS which displays a maintenance
message identifying any malfunction. Should an item of support equipment
be identified as a requirement, the use of -1553B wuld have no impact.

With consideration given to the above factors, the benefits derived fram
mxdifying EMMX to comply with the MIL-STD were minimal since:

1. The EMX is an existing design

2. nhe design is proven and extensively flight tested
3. The EMJ bus is a specialized closed bus

kitionally, compliance would:

1. Cost additional money

2. Increase hardware and software complexity
3. Potentially reduce reliability
4. Have little effect on life cycle cost

FLIGHT IST TS SUBSYSTEM

The B-lB Flight Instruments Subsystem (FIS) includes sensors and trans-
ducers, and associated display components and electronic assemblies related
to air-data,attitude direction measurement systems as well as specialized
subsystem electronic interfacing equipment. 7he interfaces and locations of
subsystem elements are shown in Figures 4 and 5, as further amplified in the
following discussion.

Redundancy is employed so that loss of any single element will not affect
mission completion capability and no two component failures will result in a
hazard Category III or IV as defined in MIL-STD-882. The entire system is
designed with emphasis on simplicity of mechanisms, with minJin dependence
on support equipments, and it will meet the requirements of AFCS DH 2-1 and
2-2. Self test provisions require that any undetectable failure, when followed
by a single in-flight failure, will not result in an unsafe condition.

Principle interfacing systems are the Central Integrated Test System

(CITS), Cmmmuication and Traffic Control (C&M) system and the Offensive Sub-
system Group (OSG). Comrunication between FIS components and the OSG is
accomplished via a serial digital data bus conforming to the requirements
specified in MIL-STD-1553B. Communication between aircraft subsystem compon-
ents is also accomplished by dedicated serial digital, analog, and DC dis-
crete signals.

The FIS includes a fully redundant air data system including four side
gounted probes, installed to comply with requirements of MIL-P-26292, to sense
air pressure and flow angle, and two Total Temp Probes to sense temperature.

346
I'wo Centrai. Air Data Computers (CADC's) utilize the sensors' data to provide
highly accurate information including velocity, altitude and angle of attack
for prix.ary flight instrument displays and twelve other aircraft systeus. In
addition, mechanical stand-by instruments with direct pressure connections from
the air data probes provide vital altitude and velocity information to the pilots.

The Gyro Stabilization Subsystem (GSS) is an all-attitude Auxiliary Heading

Reference System (AHRS) which provides pitch, roll, heading, and turn-rate to the
pilot's and copilot's Vertical Situation Displays (VSD's); in addition, heading
is provided to the 1553B data bus. For maximnu accuracy AHRS requires True Air-
speed (TAS) indications from the CADC's. AHRS consists of a Gyro Reference
Unit (GIU), a Gyro Reference Unit-Mounting Base, Electronic Control Amplifier
(ECA), a Magnetic Axinmth Dectector (MAD) and a Control Panel (CP). As a
back-up for the AHFS pitch, roll, and turn-rate, a Self-contained Attitude
Indicator (SAI) and a rate gyro is provided. As a back-up for AHR1S heading,
a 'whiskey' magnetic compass is provided.

The Flight and Control Instruents (ECI) is a dual (redundant) system with
each individual. system consisting of Flight Director Carputer/Monitor Unit
(FDC/M) and a VSD system. The FrC/M selects attitude reference from either
the GSS or the Inertial Navigation System (INS) and computes steering cmmands
in various navigation and traffic control modes selected on the FDC/M panel.
Otput signals dre displaysed on the VSD and the Horizontal Situation Indicator
(HSI), and used by the Automatic Flight Control System (AFCS) for control com-
putations. The VSD is a CRT display, providing pilot Attitude Director Infor-
mation (ADI) and flight parameter symbology. It also provides video overlays
of Terrain Follcyiinc (TF) or Terrain Avoidance (TA) modes when selected. The
Surface Position MDnitor System (SPMS) includes the Sixface Position Indicator
(SPI), surface position sensors, transducer excitation power supply and signal
conditioning unit.

The DEta Transfer System (CTS) includes dual (redundant) Flight Instruments
Signal Converters (FISC) and a single Data Conversion Urdt (DCU) which provide
data conversion and processing needed for a compatible interface between various
aircraft equipments. In addition, the DTS includes a Multiplax Interface Module
(MIM) that is capable of receiving/transmitting asynchronous serial. digital data
on either of two data buses as specified in MIL-STD-l553B; the MIM is installed
inside the using subsystem IRJ, and a total of 10 MM's will be used on the
aircraft. Finally, the Data Link Terminal (DLT) is used to provide transformer
coupling between the data bus and the subsystems as well as bus termination.
The
two auxiliary equipment
clocks, two prepare includes the Flight
to eject bells, Instmxnents
an aural TestAMde a (FITM)
tone generator, panel,
windshield
temperature controller, and five GFE instr-mnts.

OFFENSIVE SUBSYSTE4 GROUP

The B-.lB Offensive Subsystem Group (OSG) utilizes state-of-the-art off-the-

shelf and modified system components to achieve unprecedented performance

347

:4I
capablities at minimum cost. The major elements of the OSG are shown in
Fiqure 6.

Accurate navigation is provided by a Singer-Kearfott dual dry tuned-rotor

gyro inertial navigation systen derived and improved from the F-16. A West-
inghouse Offensive Radar System (ORS) derived from the APG-66 radar (F-16)
provides high-quality ground map imagery for navigation system updates as
well as numerous other nodes including terrain following. A second radar
channel identical to the first performs backup functions. The terrain
following function provides much improved accuracy, sensitivity, and counter-
measure immunity relative to the B-lA avionics equipment. Both radar channels
operate through a shared electronically scanned phased array antenna which
Permits simultaneous radar modes on a tune shared aperture basis. Ale phased
array antenna design plays a key role in the B-lB's acheiving a low observable
signature. 7he doppler radar supports the navigation system and is umodified
off-the-sheif equipment (the current Air Force standard).

The computational system employs the current military standard multi-

plex data bus, ML-STD-1553B, and AP-101F computers derived and slightly
modified fran the B-52 Offensive Avionics System (OAS) upgrade program. A
total of eight such identical processors are utilized on the B-lB including
four for the central processing of offensive and defensive systems (one
redundant), two being utilized for the ORS terrain following computations,
one as a defensive systen pre-processor, and one for central integrated test
systen functions. More than 25% capacity for growth is provided in the
central processing functions. Controls and displays are a combination fran
B-52 OAS and B-i ndified as necessary. The navigation systen, camputational
system, and missile interface units have the accuracy, capacity, and interface
campatibility required to accomandate ALC carriage at a later date.

Weapon interface-units include existing units fran B-52 OAS and B-I
programs as well as new designs. B-lB weapons interface compliance with
MIL-STD-1760 is summarized in Table 1. Buried provisions to accommodate MIL-
STD-1760 requirements will be provided on B-lB aircrafts No. 2 and subs.
Fiber optics and 270 VDC transmission line requirements, which are part
of MILj-STD-1760, have been excluded since they lack B-lB applicability in the
reasonably foreseeable future. Thus, the additional buried wiring required
on the B-IB to accomdate ML-STD-1760 will consist of audio, video, and
RF lines fran each of the three weapons bays to the central equipment bay.
7he wire run fran each of the three weapons bays will consist of a twisted
and shielded pair of wires to accommodate audio, a pair of 75 ohm coax line
to carry video, and a pair of 50 ohm coax lines for RF. Each of the three
wire runs will be capped and stored in the central equipment bay as well as
in the forward, intermediate, and aft weapons bay.

Additional discussion of the OSG and standards is presented by Boeinq

r cranion paper.

348
 ]DEFENSIVE SYBSYSIM GROUP

The B-lB Defensive Subsystem Group (ISG) consists of a modified version

of the AN/ALQ-161 defensive avionics system developed for B-IA aircraft
(A/C-4), Expendable Countermeasures (EXC) developed for A/C-4, a Defense
Management System (DBS) and a Tail Warning System (TWS). The major elements
of the ESG are shown in Figure 7.

The AN/AQ-161 defensive avionics equipment includes transnitters, re-

ceivers, antennas, a Preprocessor Avionics Control Unit (PACE) and inter-
connecting electronics. Utilizing this equipment, the AN/ALQ-161 acquires
radiating signals frcm the external environment, processes these threat
signals to determine their identity, and based upon the type of signal
acquired, applies an appropriate electronic countermeasure (jamming) to defend
against the detected threat. Improvements made to the A/C-4 system consist
of frequency expansion to provide bands 1-3 receive and band 8 receive and transmit
and the additic of techniques to counter sophisticated radars.

The Expendable Countermeasures (EXCM) consists of eight interchangeable

flare or chaff dispensers located on top of the aircraft aft of the crew comr-
partment, a controller and controls and displays. Dispensing of 0CCM (chaff
or flares) is controlled by the EMS. It can be manual (operator initiated)
or automatic, based on missile warning data supplied by the TWS.

The Tail warning System (TS) detects aircraft and missiles in the aft
sector and provides information to the DNS for operator warning and automatic
dispensing of E04 as applicable.

The Defensive Management System (DMS) consists of controls and displays

and a preprocessor that provides the man-machine interface required to operate
the AN/ALQ-161 defensive avionics, EXC4 and WS. Primary data transfer is
accamplished via MIL-STD-1553B and data bus interfaces. The preprocessor and
certain other components of the ac are shared with the offensive avionics con--
trols and displays.

SUMMARY

In summary, military standards have been utilized for B-lB subsystems to

the maximum extent possible where shown to be cost effective and consistent
with B-lB development schedules. Standardization in the C&7C subsystem is
accomplished by equiprent selection. For subsystems employing common processors
(CITS, OSG, and DSG), the standard data bus is fully incorporated and provisions
are being made for future incorporation of MIL-STD ' s -1589B and -1750A t realize
software support cost savings in the future. Some elements of MIL-STD-1760
are being incorporated now for weapons interfaces, whereas other elements are
deferred. The mature development status of the B-lB E MX subsystem as well
as B-lB schedule limitations indicated no program/field support cost savings
could be afforded in that area by redesign to more current standards.

349
h

d V . W W
 ACRONYMS

ADI Attitude Director Indicator

AFCS Automatic Flight Control System
AFCS DH Automatic Flight Control System Design Handbook
AGE Avionics Ground Equipment
AHRS Attitude Heading Reference System
AL024 Air Launched Cruise Missile
CADC
A Central Air
Airborne Data Conputer
Printer
CCD CITS Control and Display
CFE Contractor Furnished Equipment
- CI CITS Interface
CITS Central Integrated Test System
CMR Cits Maintenance Recorder
C&TC Communications & Traffic Control
DAU Data Acquisition Unit
DCU Data Conversion Unit
DD Data Distribution
DLT Data Link Terminal
ES Defense Management System
DSG Defensive Subsystem Group
UTS Data Transfer System
ECA Electronic Control Amplifier
MP Electracagnetic Pulse
EMJX Electrical Multiplex
EXCM Expendable Countermeasures
FCI Flight and Control Instruments
FDC/M Flight Director QCiputer !4cnitor
FIS Flight Instruments Subsystem
FISC Flight Instz'nents Signal Converter
FITM Flight Instruments Test/Mode
GFE Government Furnished Equipment
GRJ Gyro Reference Unit
GSS Gyro Stabilization Subsystem
HF High Frequency
HSI Horizontal Situation Indicator
IFF Identification Friend or Foe
ILS Instrument Landing Systen
INS Internal Navigation System
ISA Instruction Set Architecture
LF/VLF Iow Frequency/Very Low Frequency
LRU Line Replaceable Unit
MAD Magnetic Azimuth Detector
1,4.
:IT., bdular Automatic Test Equipment
MIM Miltiplex Interface Module

35C

. ...........
 ACROYYS (Continued)

OAS Offensive Avionics System

ORS Offensive Radar Systen
OSG Offensive Subsystem Group
PACU Preprocessor Avionics Control Unit
RF Radio Frequency
SAI Self-contained Attitude Indicator
SATCCM Satellite Ccmmunications
SPI Surface Positon Indicator
SPMS Surface Position Monitor Systen
TA Terrain Avoidance
TAS True Airspeed
TtM Time Division Multiplex
TF Terrain Following
M Tail Warning System
USAF United States Air Force
VAC Volts Alternating Current
VDC Volts Direct Current
VSD Vertical Situation Display

351

r%
Table 1. B-1B MIL-STD.1760 Compliance

BURIED
AVAILABLE PROVISIONS DEFERRED
28 VDC X
115 VAC X
270 VDC X
DIGITAL DATA X
AUDIO X
VIDEO X
RF X
FIBER OPTICS X

352
 COURIS SECURE
VOICE MOTOROLA

uIIF.2 SMuMu
MULTIPLE IFFRIIIF

CLISSATELLITE -

AFSATCON BLAT
.SMED

In ( I -IAXTACAUM
ON
$TO)UPPE LOWER

COUJISICPECOUINY

LOCLIZESy 91VS17
SOLM
*NAI
MI stans16VS97
* euedca

Figure
2. ~B-BCnrlItgaedTs)ytm(IS

COLINSKffIA/U353M
 Control Box =But Controller
003Box Remote Terminal (Inteuface with Subsystems)
C1Box Interface with CITS

o
/2 CONTROL
BXES
3Ds CT
INTERFACE @X

Figure 3.8B-1B Electrical Mutiplex (EM UX) System Component Location

354
 V co

Q Q

,C,

03 U

.49

A 0

Spa
-gig

c~I® ~355
 IN 01 twV M~ COWMPS WTENS
ME_ o__ _ AS Pill
% CANNO CLOCEg e% Ul ANW/,M .
MSFIAYS
0555 FlOVT DSPLUAYSP
111,1111AS IO

is, mm. aOPOI "DSTTE

OMLAWEE? imFR-

IT Io~u
=U""

LTS Io K LT OLOT
AM~ -T mwsscuusaa

AVIONICS-NIL-liD IStS 39A DOUTAL

*x~~~~~~rmUwam DIS-ML4STDISI SIA DITl DCOISUTI AISALOG. 10-AL DIOTAL
KIW
$SU KINALDOTAL. DCDWCUT Svwjm. uANAO
DEPLAY - WEAL DOGTAL. DICD'CAN 2-WISE
AC SNWCS. ANALOG
CATO - NASALDIGITALDCDISCUITI.ANALOG

Figure 5. Flight Instruments Subsystem Interfaces

_________ ~-I- IMINI DATAWIG

JIGAL) _______

VIA "Am 0.

. . 11 ,e 1, hIIOS

SU
wiN" F IO111
US -iUSP5,

Ak me 9 H n11o

am gFS

INS DATA

SUM SYTEM
UVTIOV UA CONMII"1,011
INTERFAC
SYSTEM PMCEUMGI NAS MNGMN
UNITS SSEM

Figure 6.B fesv usse ruSp (OSG

356iaAigi
RECEIVE "OE

TRANMIT vlocal"4 tTfA

a 131M al
-Now 'c"m 11"

lomm.

ffp

MI'm am. Nlool

F1g4rs DeesveSbyseorop(sG
mammlB
0811- u 110=11MOM

4"m.

.s 044

s*mrsn

wom ww1a

m
t collm

soak,
ANN",

us's 6

'R'a

357.1 .mm

U&S
$64 ac
TWAS o tu-mO
w*Iliffi
 STANDARDS APPLICATION TO B-lB AVIONICS PROGRAM

H. L. Ernst

Boeing Military Airplane Company (BMAC)

Mail Stop 41-114
P.O. Box 3707
Seattle, Washington 98124
(206) 655-1130

This paper covers the B-1B Avionics Progran as related to the recently
developed USAF Avionics Standards. These USAF Avionics Standards include
MIL-STD-1553B Data Bus System, MIL-STD-1589B High Order Language (HOL), and
MIL-STD-1750A Computer Instruction Set Architecture (ISA). The B-lB
Avionics System is described c aering the system architecture, major
subsystem, and equipment. The recently conducted B-IB Standards Program
(MIL-STD-1589B and MIL-STD-1750A) is explained. Also the tasks are defined
and the suazmy of results and conclusions are included. The B-IB program
action, taken subsequent to the Standards Program wrap-up, is discussed.
Finally, a B-l1 program plan for application of the military avionics
standards is discussed.

BASELINE B-1B AVIONICS Proaram

The B-1 Avionics system was originally contracted in April 1972, well
before the USAF Avionics Standards were defined. The B-1 Program was
subsequently redirected from a production program to a test and development
activity in the latter 1970's. The B-1B Avionics Progra RFP was released
in January 1981 and the final contract signin was completed in May and
June 1982. The B-1B Avionics Program as oontracted in 1981-82 was defined
to be a low risk program (i.e., few developments). At the time the J73
Compiler was not proven (matured on a production application), and the
MIL-STD-1750A ISA had been only recently released. These factors resulted
in definite risk for standards application to a low risk program with tight
budget and schedule and a fixed price contract. Therefore, the B-1B
baseline definition included the IBM AP-101C Avionics Control Unit (ACU)
and JOVIAL J3B HOL transfer from the B-52 Offensive Avionics System (OAS).
With further B-lB program activity the IBM AP-101C ACU evolved to the
AP-101D model.
The B-lB Avionics Configuration includes (1) navigation subsystem,
(2)computational subsystem, (3) control and display subsystem, (4) stores
management subsystem, and (5) various features of the aft crew station
control console along with som features on the Front Station (pilots')
arrangement (Figures 1, 2 and 3). The AP-101D ACU was designated as the
common B-1B processor and as such is used in eight places on each B-lB
airplane. These applications are listed and defined in table 1. The CRACU
provides backup (redundancy) for the critical functions assigned to the

359 I PACE
,BL ANK
713
GNACU, WDACU, and the CDACU. The dual TFACUa provide redundancy for the
terrain following mode. The electronic countermeasures (ECM) has backup
capability provided in event of failure of the PACU. The AP-101D ACU
included an IBM MMP (Multipurpose Midline Processor) ISA, 400 KOPS thruput,
128K Words of memory, four dual channel 1553 interfaces, and parallel
input/output (I/O) for the ECM system interface.

PARALLEL STANDARDS PROGRAM

To pursue the possibility of applying MIL-STD-1589B (JOVIAL J73 HOL)

and MIL-STD-1750A ISA Processors to the B-1B program without impacting
schedule or costs, a separately funded parallel standards program was
established in January 1982. This program was initiated with a 90-day
phase 0 study period, January 11 through April 12, and a planned follow-on
phase I. To ensure minimal B-1B program impact, this program was conducted
by ASD/EN at IPAFB and by BMAC Avionics Technology in Seattle, Washington.
Rockwell International (RI), the Weapon System Contractor (WSC), and AIL
Division of the Eaton Corporation, the Electronic Countermeasures
Contractor (ECMC), also participated in the study.

The Phase 0 Program objectives were to initiate studies, identify

alternative incorporation approaches, develop plans, and initiate long lead
activities to:
o Replace B-1B ACU, AP-101D, with a MIL-STD-1750A processor.
o Replace J3B HOL with J73 HOL.
o Develop and validate J73/1750A compiler.
o Rehoat EMkC support software for compatibUlity with J73/1750A
standards.
o Establish viable B-1B standards incorporation plans within
current program constraints.

The Phase 0 SOW tasks are listed in table 2, and the key results are
outlined in figure 4. Data available by aid-May 1982 indicated that (1) a
decision to incorporate the standards at any time during 1983 or 1984 would
result in a schedule slide and high incorporation costs and (2) an August -
September 1982 decision date would have less impact than a November -
December 1982 decision date because of the planned start date of B-1B
software coding by both BMAC and RI. In all cases, the ECMC (AIL) did not
plan to make a 1982 or 1983 standards incorporation decision or to comply
with inoorporating the standards into B-i airoraft 4 or B-IB aircraft 1
first flight (figures 5 and 6). The phase 0 program was completed and
activity continued under contract into the phase I period through
7 June 1982.

Summary of results and conclusions reaohed during the Parallel

Standards Program (phases 0 and 1) by task are listed below.
a. Task 1, B-1B ACU modification kit to MIL-STD-1750A ISA:
Results of this task indicated that the current IBM AP-lO1D could not
provide sufficient thruput margin beyond the original 400-KOPS to allow f-r
the expected thruput efficiency degradation of a new compiler (J-73), as
compared to a mature compiler (J3B). As a result, this task was terminato'V
Ln mid-March and not carried on into the phase I program.

360
b. Task 2, Preparation of competitive procurement (MIL-STD-1750A ISA
processor);
A B-1B MIL-STD-1750A (ACU) competition within industry was completed,
source selection made, and the results were briefed to the B-1B SPO, along
with various ASD personnel. The WSC (Rockwell International, ECMC (AIL),
and the USAF(ASD/EN) participated in the competitive procurement package
preparation to ensure concurrence on a common B-lB MIL-STD-1750A ACU
definition. The competitive procurement package was released to seven
suppliers that were selected from an earlier listing of 13. Six suppliers
submitted proposals in early May 1982. The proposal evaluation (technical,
operations, Program Management, schedule, cost, etc.) and source selection
were completed by the end of May 1982. The selected HIL-STD-1750A ACU,
IBM AP-101E, was off-the-shelf, developed by IBM, exceeded the specified
requirement of 525 KOPS thruput, and complied with the requirements of 256K
words of memory capability. The B-1B Program office then chose the IBM
AP-1O1F dual-architecture ACU rather than the AP-1O1E selected by the
standards program competition. This choice was made because of program
factors that indicated a lower B-18 program cost and schedule risk while
still providing for standards incorporation. These program factors are
further explained in the next section of this paper, "Current B-lB Avionics
Program.*
C. Task 3, Modification of the ANWAL (SEA) J73/1750A compiler, and
Task 4, Evaluation of alternate J73/1750A compiler approaches:
Subsequent to definition of B-1B J73/1750A compiler requirements,
industry review, and identification of viable alternate compilers phase 0
contracts were awarded as listed below.
BASELINE
TASK SUPPLIER COMPILER REMARKS
3 Software Engineering AFNAL (SEA) Developed AFWAL
Associates (SEA) compiler
3 Proprietary Software AFWAL (SEA) Under contract
Systems (PS3) to GD/F-16
4 Advanced Computer F-16 MSIP Under contract
Techniques (ACT) compiler to GD/F-16
development
4 SofTech JOCIT Previous RADC,
(Software Technology) current MX, and
other related
contracts
As a result of the evaluation of Phase 0 activity, supplier Phase I
design approach reports, and supplier Phase I proposals with associated
not-to-exceed costs, Phase I development contracts were awarded to PS. on
the AFWAL (SEA) Compiler and SofTech on the JOCIT Compiler. The Phase I
contracts required initial compiler deliveries from each supplier on
15 July 1982 and final compiler deliveries on 15 September 1982. These

361
dates were selected to be compatible with the planned alternative program
decision dates of 1 September and 1 December 1982 for B-1B Program
incorporation of the NIL-STDs.

d. Task 5, Retarget BMAC support software to MIL-STD-1750A:

All critical areas of the BMAC support software rehost to the
MIL-STD-1750A were completed on schedule to ensure compatibility with other
elements of the B-1B Parallel Standards Program. The activities under this
task were (1) definition of change requirements, (2) assembler updates,
(3) link Editor updates, and (4) simulator update.

e. Task 6, Development of benchurk (J73/1750A compiler evaluation

system):
The objectives of this task were to develop a benchmark plan to assess
capabilities of the J73/1750A compiler using operational software, conduct
a review of the AFWAL (SEA) compiler status, and develop a detailed
compiler evaluation plan to measure the J73/1750A compiler acceptability.
Results of the review of the AFWAL (SEA) Compiler based on limited
benchmark code from RI, AIL, Logicon, and SofTech were that the J73
compiler used 16% more memory and had a 54% decrease in compilation time
than the J3B compiler. It was concluded that the AFWAL (SEA) compiler did
provide a basis for development of a mature compiler for B-1B application.
This task was phased to support the planned alternative program decision
dates of 1 September and 1 December 1982 for B-1B Program incorporation of
the MIL-STDs.

f. Task 7, Development of common J73/1750A implementation:

The objective of this task was to develop the J73/1750A implementation
plan for Phase I. Activities undertaken included (1) definition of
facilities and training, (2) impact of the conversion upon the executive,
(3) impact of the conversion on applications software, and (4) definition
of a master implementation schedule. The Phase I plan developed, figure 5,
is keyed to Program Incorporation decisions in August 1982 and
November 1982 to support effective dates of 1 September and
1 December 1982.

g. Task 8, Definition of alternative program plans:

The objectives of this task were to define plans for implementing
Avionics standards, MIL-STD-1589B and MIL-STD-1750A, in the B-lB in
coordination with the WSC (RI) and ECMC (AIL). Risk items and impact on
Costs and schedules were identified and engineering trade studies were
performed to select a plan for standards implementation. Initial plans
included four decision dates to meet B-lB first flight, ranging from
April 1982 to December 1983. Also, an alternative plan was included for
delayed incorporation of the standards, figure 6.
CURRENT B-lB AVIONICS PROGRAM
The MIL-STD-1750A industry competition was completed, including source
selection of the IBM AP-1OIE computer by the parallel program (BMAC
Technology). Studies and developments relative to the other program tasksi
(compiler, support software and flight and laboratory operational soft ware)
had indicated that significant program penalty (cost and szhedule) u
experienced with a B-1B program changeover to the new standards. hlso, i-

362
was indicated that future activities of the B-1B avionics and standards
would require B-lB program office funding.

Concurrently (late May and early June 1982) IBM had submitted a
supplier change proposal to the B-1B program covering a dual-architecture
computer (AP-101F), providing for the MIL-STD-1750A ISA and the AP-101D M4P
architecture. This proposal included provisions for validating both
architectures during the development period ino'luing tests by the USF
SEAFAC Laboratory of the MIL-STD-1750A ISA and providing the "user option*
of either architecture initially with a minimal impact changeover to the
other architecture at a later time (figures 7 and 8 and table No. 3).

Therefore, two alternative approaches were available for the

incorporation of the standards into the B-lB program. One approach was to
use the IBM AP-1012 computer, selected by the industry competion during the
parallel study program, and the J73/1750A compiler, with an immediate
changeover from the J3B HOL to the J73 HOL and from the AP-1O1D MMP
assembly language (AL) to the MIL-STD-1750A ISA AL. The second approach was
to use the IBM AP-101F dual-architecture computer with the Ml4P architecture
as an interim step along with J3B HOL and a subsequent change-over to the
Avionics standards with the AP-I1F using the MIL-STD-1750A ISA. The B-1B
program office selected the second approach thereby minimizing B-1B program
cost and schedule risk. Further, the B-1B SPO concurred with the follow-on
J73/1750A AFWAL (SEA) compiler development by P33 and that a continual
monitoring of other J73/1750A compiler developments such an the ACT/GD P-16
compiler be conducted. The USAF directed that the follow-on development of
the SofTech JOCIT compiler be terminated.

This course of action allows for program incorporation of the

standards when (1) a production level J73/1750A compiler has been
demonstrated, (2) the B-1B flight software development is stabilized, and
(3) the B-1B program schedule and cost impacts are optimum for the change.

B-1B AVIONICS STANDARDS INCORPORATION

The Phase 0 and Phase I Parallel Standards Program and the current
B-1B Avionics Program use of the IN AP-101F dual-architecture ACU allow
later incorporation of the standards in an orderly manner. A plan has been
prepared and discussed with the B-lB SPO and the associate contractors (RI
and AIL), figure 9. Specific actions and approximate schedules for
incorporation of the USAF Avionics Standards into the B-1B Avionics are as
listed below.

o ECP authorization, January 1985.

o Compiler and support software enhancements, January through
December 1985.
o MIL-STD-1750A executive development and J3 to J73 translator
completion (version 2), January through October 1985.
o B-1B test tape conversion, January through December 1985.
o SDL, upgrade to accomeodate MIL-STD-1750A ACU, August to October
1985.
o Avionics Flight Software (AFS) translation from JB HOL to J73
HOL, translation from *P-101F M9P assembly language to AP-101F
MIL-STD-1750A assembly language, and validation of translated
software in the BAC B-1B SDL, August 1985 through June 1986.

363
 o AP-101 FIELD MOD to incorporate user proms for utilization of
existing MIL-STD-1750A architecture, January through August 1985.
o Aircraft changeover from J3B2 to J73 software, June 1986
effective with B-lB aircraft 9 first flight.
o Flight validation of B-lB Avionics, ACU, and J73/1750A software,
B-lB aircraft 9, June 1986 first flight.
o Also, companion ECPs would be required from the other associates
for changeover of HOL and Assembly Language software.
SUMMARY
In summary, the B-lB program has incorporated the IBM AP-101F dual-
architecture computer that includes MIL-STD-1750A ISA, while presently
continuing with the current software approach using J3B HOL. This
selection provides improved B-lB ACU reliability, memory capability and
thruput over the AP-1OID (table 3). Also, the B-lB program is continuing
development and evaluation of the J73/1750A compiler to ensure meeting the
objectives of the Parallel Program to incorporate the avionics standards
(MIL-STD-1589B and MIL-STD-1750A) at minimal program risk. Efforts are
underway to identify the incorporation approach that optimizes B-lB program
schedule and cost impacts.

Mr. Ernst is currently chief, B-lB Avionics Technical Staff. He was

program manager of the BMAC B-lB Avionics Parallel Standards Program
(MIL-STD-1589B, J73 HOL, and MIL-STD-1750A ISA) from January through June
1982. After receiving his BSEE degree from the University of Kentucky, and
graduate work at Notre Dame, Mr. Ernst joined The Boeing Company in 1953.
He joined the Boeing Military Airplane Company in 1972, after 19 years in
jet transport programs (KC-135, 707, 720B, 727, SST, and new airplane
program NAP).

Subsequent to Joining BMAC in 1972, Mr. Ernst was systems technology chief
on the AMST prototype (YC-14) program covering the technical areas of
flight deck, avionics systems, electrical systems and equipment,
hydraulics, and mechanical systems and equipment. Then on the AMST (C-I1)
and C-X studies and proposals he was avionics technology chief, covering
the areas of flight deck, avionics systems, avionics equipment and
associated installations, such as equipment installations, cabling and
antennas. Also, human factors including the cargo compartment as well as
the flight deck were covered.

364

- OF
 ACRONYMS/ABBREVIATIONS

ACT Advanced Computer Techniques

ACU Avionics Control Unit
AFWAL Air Force Wright Aeronautical Laboratories
AIL ALL Division of Eaton Corporation
ASIC Avionics System Interface Contractor
BMAC Boeing Military Airplane Company
CDACU Controls and Displays ACU
CITS Central Integrated Test System
CRACU Critical ACU
ECMC Electronic Countermeasures Contractor
GD General Dynamics
GNACU Guidance and Navigation ACU
HOL High Order Language
IBM International Business Machines
ISA Instruction Set Architecture
MMP Multipurpose Midline Processor
PACU Preprocessor ACU
PSS Proprietary Software Systems
RADC Rome Air Development Center
RI Rockwell International
SEA Software Engineering Associates
SofTech Software Technology
TFACU Terrain Following ACU
USAF United States Air Force
WDACU Weapons Delivery ACU
WSC Weapon System Contractor

365
 List of Tables

Number Til
1 B-1 AP-101 ACU Applications

2 Parallel Standards Program Staemenrt of Work Tasks

3 Avionis Procer: Performance Compariso

Listof Figus

1 B-18 Offenive and Defensie Avionics Systems

2 B-i B Avionics Configuration

3 B-18 C&D Avionics

4 Key Results of Phas 0-B-1B J73/1750A Parallel Stadar Progiv

5 J73/1750A Parallel Stadarxs Program Incorporation Plan

6 B-1B J73/1750A Standards Program Plato Summary

7 Avionics Processor: Block Diagram

8 AP-101 F Architecture Switch Concept

9 B-1 B Avionics Standasd Program

366
 Table 1. B-IBAPIO1ACUApplications

QuanityAsscite
per contractor
Nomenclature Description airpane responsibility
GNACU Guidance and navigation ACU 1 BMAC-ASIC
WDACU Weapons delivery ACU 1 BMAC-ASIC
CDACU Controls and displays ACU 1 SMAC-ASIC
CRACU Critical ACU 1 BMAC-ASIC
TFACU Terrain following ACU 2 BMAC-ASIC

PACU Preprocesmor ACU 1 AI L-ECMC

CITS ACU Centrol intgraewd test vytm 1 RI-WSC
(CITS) ACU

Table 2. Parallel Stwdarda Progrm-Phaue0 Satemenr of Work Takir

Task Demcriptionfritie
1. -1B avionia control unit modification
2. Preparation of competitive procurement (MI L-STD-I 75A ISA pmceano)
3. Modification of the AFWAL (SEA) J73/1750A compiler
4. Evaluation of alternate J7311750A compiler approaches
5. Retarget of BMAC supportsoftware to MIL-STD-1750A
6. Development of benchmark (J73/1750A compiler evaluation system)
7. Development of common J73/1750A implementation
8. Definition of alternate programs
9. Monthly statm briefings
10. Program management
11. Phase 1 proposal

367
 A* C
Mae

':' .g3

20
qr 01
CC

N c
ILI
S ___ ______ ____cc

____ -6-
 g3F4

W5 5

ifi
336
 - - - - - - - -.. - &- M . _.

a: ,I
I
oU,,

I
I

I I

I I a

Ijjz*
• III!

- C eL. -
---
I !rai i I .,.

e
I I

'i

I370
 Maa

swa

Ias.

371
@4 compiler sippiers under cenums-MA. OnS. ACT. and Softedi-l Match 1962
* Cmpie
bndiukdevelopment InlSWeW-20 January 1962
* MIL4TD-1750A ACU omnpute promurnent pacedhe misued 10 induy-25 March 1962
*&-11 Standurds kbcorporstion dewt ellurnes of 1 Sopumb 1im62.1 Desember, 1932. and June 196
OB-iSprogra standards inoorporadon impctseand sO"~
* MILST1750APprocssr mest udiedads. for flat OWgh of B-i asraft 4 July 1034
* ThreeJ73/1750AncoPliers under developmnent
* ECMC (AlUI will not meet firs flight Incorporation
* Duel proesso developmn and tarnmnmo libit of ISM AP-1 01 Dcontract
OAvloioaflight so1twer (block 0 and block 1) dldee
(a) Sofiwem UImin
Mb Sofiws. rwark
(c) Decreesed softwr conmmonlIty(-52 OAS/S-i 5)
(d) Duelsupport softwar confWpAtlmn

Ffp*, 4, K@V Results of Pa 0--8451 J73/?7WA PwafW Standads Pr'ogwn

372
% I

--
a

CId
0

a 3 C3

AAga

'A. a373
 I* usas

ImI

rad

0.*j

374
S..L

ac

---- - - --- --- I

375
 CI

I ad

376
 II I I ' ..15,o 'I
,
* I i" II

-I I
. I Ii
z-J

Sl*
.4
oI Ii
! I,I
I_ " I
II I 1 I.
SI liIo
Ie~ ! I I

.8 . *..
. a... _ ..... . .

377
*1I

THE DIGITAL INTERFACE CHALLENGE

SESSaI CHMAN MOW Um Chosel*

MODERATOR: Coul J. GOfo

pftEVIOUS PAGE
IS BLAN4K

~ **'~ ~ .,% ~ '' In,

HH-60D Advanced Avionics Architecture

November 1982

Ira Glickstein, Sr. Engineer

HH-60D Systems Engineering

304AH21
IBM Federal Systems Division
Owego, New York 13827
(607) 751-4202

Abstract

The -H-600 Night Hawk Combat Rescue Standard Processing Hardware and Software
Helicopter avionic system design makes extensive use
of USAF/DoD interface and processing standards: All mission processing is performed in
dual-redundant MIL-STD-1750A Mission
* Standard Interfaces Computers, using the standard USAF
higher-order language, JOVIAL 373, and
- All data interfaces use a dual-redundant structured software development disciplines.
MIL-STD-1553B data bus, where cost and This controls the software development process
safety considerations permit. This provides and provides inherent growth flexibility
operational reliability and growth flexibility, through transferable software.

- Signal conversion for equipments that are not Existing distributed processors, with proven
data bus compatible is performed by four software and firmware designs, are used for
separately located Remote Terminal Units that peripheral tasks, where cost effective.
serve the cockpit/nose and transition areas. Processors in the Display Electronics Units and
This permits use of unmodified inventory units, Multi-Mode Radar are programmed in
and reduces risk, schedule, and life-cycle costs. JOVIAL 173, making possible future transfer
of software to standard USAF processors.
- The control and display subsystiem is Much of the software in the embedded
compatible with either 525 or 875 line TV processors has already been paid for under
(EIA RS-343A/RS- 170) and can handle either other military programs.
1:1 or4:3 aspect ratios. This allows se of
current forward looking infrared, multi-mode The HH-60D architecture is fully compatible
radar, and remote map reader technology, and with distributed processor avionics now in
future infusion of technology improvements, development for use on multiple military air
vehicles.

381
AD-A45 697 PROCEEDINGS PAPERS OF THE AFSC (AIR FORCE SYSTEMS 5/6
STAND..(U)
COMMAND) AVIONICS RFB
WRIGHT-PATTERSON AERONAUTICAL
OH DIRECTORATE 0.. SYSTEMS DIV 1
lllllllllllnl
UNCLASSIFIED C A PORUBCANSKY NOV 82 F/G 1/3 NL

EEEEI/I/////I
EEEEEII:EIIIEEE
EIEEEEEIIIIIEE
lEEEEllEEEEllI
/////////I//ffllfll.
1-2i.4

lit% g11
 4 S- T. - s'JE Lh .V

HH-60D Advanced Avionics Architecture

Introdwtdon • Two MIL-STD-1750A Mission Computers.

IBM Federal Systems Division has recently been • JOVIAL J73 mission software, and
selected by the Air Force as Avionics Integration
Contractor for the HH-60D Night Hawk Combat • MIL-STD-1553B, Notice 1. dual-redundant data
Rescue Helicopter. The Night Hawk isdesigned for bus.
search and rescue and special operations missions. It
will operate under day, night, and adverse weather Mimn Caeuuas -
conditions, and will be capable of penetration of hostile
territory, using very low-level terrin-masked flight. One of the strong candidates is the F-16 computer.
An advanced, highly integrated, multi-sensor avionics with 64K words of core storage. This computer meets
system provides the performance, reliability, and the MIL-STD-17SOA requirement, is "off the shelf,"
survivability features the alrcrew requires to and is in the Air Force inventory, offering
successfully complete these demanding missions. standardization benefits.

The Air Force HH-60D Night Hawk air vehicle is We intend to use two Mission Computers, with
supplied by Sikorsky. It is a variation of the Army identical software, to perform mission processing and
UH-60A Black Hawk and the Navy LAMPS SH-60B provide pr~ay and backup data bus control. With
Seahawk. This isa good example of tri-service this architecture, failure of either Mission Computer
standardization. As prime contractor for the Navy will cause absolutely no degradation in mission
LAMPS program, we are familiar with the H-60 performance.
airframe, and with installation and integration of
sophisticated avionics on helicopters. The Air Force MItndvas to Mold-Cempter Architecture -
HH-60D has much in common with the Army and
Navy versions, but is distinguished from them by We could have used a small, non-MIL-STD-1750A
external fuel tanks, air refueling capability, and an processor for "degraded" backup bus control. This
advanced, multi-sensor avionics suite. approach could have saved the cost and weight of one
of the two Mission Computers, however, it would have
The Night Hawk makes use of many standard Air increased software design, development, integration,
Force/DoD avionics units, and existing or slightly and test costs. We would have had to define the
modified designs. However, it has been put together "minimum essential get-home" modes, and develop
around a core of integrating elements that provide a and test operational procedures for the pilots to use
modern highly integrated system, with inherent growth under these degraded conditions.
flexibility. Our design has allowed us to introduce
standard Air Force processors, software, and interfaces Advatae. of Mid-Computer Architectere -
without the need to modify existing hardware, for the
most part. With the multi-computer approach, only one
operational flight program need be designed,
The core integrating elements of the Night Hawk developed, integrated, tested, and maintained. Only
avionics system (see Figure 1) consist of: one set of procedures need be learned by the pilots.
This saves time and money, and reduces risk, during
" Central processing and data bus, the full scale development phase of the HH-60D
program.
• Signal conversion (Remote Terminal Units), and
For the production phase, use of standard Air
" General purpose controls and displays. Force processors for centralized processing and data
bus control will be more cost-effective than
C&%VW PmeCbI and m Ba - introduction of non-standard processors in this area.
We recognize that the processor area is rapidly
This part of the Night Hawk avionics system is fully changing due to infusion of new technology. We
compatible with USAF/DoD processing and interface expect the MIL-STD- 1750A chip sets. and fast. dense.
standards; low-cost monolithic storage devices, to make future

382

,, ,' ' ' ' ' '

''" W '' , ,. y ,. V
''',, %';,' '%, ' , ','
"- ' ' -. \,V, '. "' ,,.,y' '",' - ,I
 W"- . W* .A. .F
-. 1*

Ohpb. Oesu 1) O

-Two
-a*3 WANo J3 SowWarV
I IPOmdK h Obwra

- ,emm
in dm w _ Mk2P
- F~dW R*Am~v- F 1"m~m
RedAN&AMW

tisbeth c
Shul , urmuticopue MILT-STDAchpse poesor.5hs3ayb

0J
dW= iM

Figre
. H-60 Coe lwlMingEem Sadr 5¢-o Sfwr dltr e

st, nda~ prcessrs

ar mre o e"v hnmlimd aa sfwrl d o rvJ
currentpM
oe.B hti eteHH6f eterinMM2
douenionadcnrlotesfwr
proucton we ayrid ermspe n dvipe Cae
roess thipenstepsdUyo

JOVIAL
J73inSofwar -- Dai ---i s"

Eectrnic Units (DEU) andapronfth

Dispay ArFoeDoD tob bscoptil. hs nlue
sFiur
no.e ofw
HM-60, reCoin thegin Een tsh e d em iStae nd im nterf ace

standardpe ssr fnaddtin

ore oefftv th anlimoerd software. aau.T In addrdndn
i to i 12 roniding
cenete onessorythime thoe Hwit es to pro
better cmentat
sio ads coro futhre srofwah.re
prodThuic wemyfn
ldst ste ihrsedads
poesrprtion, op dhexpecl ueeupment
oes hs nsdte possiliety
capity inlteosm sie box, a attat - prico(es tA i ome o tb -ucotbeThis
softwaedest- -m

Shul
te a,
ti b urmlt-cmptr ELST-170Acipse poesor.383smab
.andidates for future HH-60D upgrade such as GPS. (nose/cockpit area), and two are in the rear (transition
Electronic Survivor Location Equipment (ESLE), and section).
defensive subsystems.
Each of the RTUs has a common design, except for
plug-in subsystem interface modules and associated
MissionComputer =1 (Primary Bus Controller) interface wiring. Figure 3 is a simplified overall view of
Minion Computer -2 (Backup Bus Controller) the Night Hawk's avionics architecture and

Remote Terminal Unit -I interconnection. and indicates the preliminary

Remote Terminal Unit =2 partitioning of signal conversion between the four
Remote Terminal Unit *3 RTUs. We have partitioned the signals in accordance
Remote Termiml Unit =4 with the following guidelines:

Display Eleetronics Unit *1

Display Eletronics Unit *2 Cddcal signals, such as warning/caution/advisory
and engine parameters, are converted by two
Inertial Nvigation Set (ASN-141) different RTUs. so that loss of one RTU does not
Multi-Mode Radar (LANTIRN Modified) caus degradation.
Remote Map Reader
Doppler Radar 0 Where completely redundant signal conversion was

GPS (Growth) not practicaL we used functional redundancy, such

Electronic Survivor Location Equipment (Growth) a interfacing each of the VHF radios via a
different RTU, so the VHF function remains
Figure 2.Units on HH-60D MILSTD-1553B DataBus despite loss of one RTU.

0 If practical, we intend to make the two forward

In addition to growth flexibility, use of the RTUs identical.
MEL-STD-1553B data bus provides reliable, redundant
interfaces between equipments. This has allowed us to • Signals are generally routed to the RTU that is
make use of shared display units for engine closest, to m e aircraft wiring.
instruments, warning/caution/advisory indications, and
other functions that traditionally have dedicated • To the extent possible, spare capability is evenly
indicators. Our dual-redundant data bus, redundant divided between RTUs.
processors, and multiple, interchangeable displays are
actually more reliable and survivable than simplex Our use of interchangeable, physically separated
dedicated indicators. Our approach also saves panel RTUs, and dual or functionally redundant signal
space and puts critical indications in primary viewing conversion, assures reliable, cost-effective
areas for better pilot response. MIL-STD-1553B compatibility. We have utilized
existing, standard avionics units, for minimum
Inthe highly unlikely case that both Mission acquisition and operational costs, making full use of Air
Computers fad, or the dual-redundant data bus fails, Force/DoD maintenance, training, and logistics assets.
the following functions continue to operate: 1) Standby
flight instruments, 2) Intercom. 3)UHF radio, and 4)
Automatic Flight Control System. So CWrv6l and DAplap -

SIta Cmu'a (Rause Tndavid Udb) - Most HH-60D control and display functions, for
both pilot and copilot, utilize shared control and display
In order to reduce full scale development and life units, located in prime viewing and reach areas. Figure
cycle costs, we selected hardware that was already in 4 shows the instrument panel and center console.
Air Force/DoD inventory. Some of these inventory These shared resources include:
units, such as the ASN- 141 Inertial Navigation System
(INS), are compatible with the data bus, but most are . Four interchangeable Multi-Purpose Displays
not. Units that are not data bus compatible require (MPD).
signal conversion. DC analog, synchro, discrete, and
digital signals are converted to MIL-STD-1553B by . Two Helmet Mounted Displays (HMD).
four Remote Terminal Units (RTUs). Two RTUs are
located in the forward part of the helicopter . Two alpha-numeric keyboards.

384

. ......... ~ *'
44

u-rn IMU

Oma

IAS
ANN~ Ifttea ~
'3 al"iuc BItk D PLIagram

Mb385

-P MA -~ ke -1 .2 '-
 -- 2-.~ -1 -P -P--7

,. +

OC,

-____,_
@onto Ii+st,8 I

~:~- ::5* . +zma:s

-- &-,-
* J*
LIs'
:-'+;,(.4.N . I +

;f~-I-
I lmi +. ' °
" .+ .... . I !
-

, I,...-.... -
, " C

, ;:. :c :... * _,_o.__--__-

6P: w.- --

_ _ _ _" _ ,,A.. I. . f= • - 1 . "' c

CL.
'.Ihi+m,i.,~: L :
r 1"':7 . o,:"L -- 2' ...
'1its:
0-Pflt'l
_ i_ _ _

,386

386
 SA tracking handle, We have standardized our video interfaces to utilize
875 line. 1:1 aspect ratio TV in accordance with
" Cyclic and collective stick grip switches, and Electronic Industry Association (EIA) RS-343A.
However, our MPDs and DEUs can also handle 525
* Two display electronics units (DEU). lines, and 4:3 aspect ratio (EIA RS-170) signal
standards.
Any display format may be selected on any MPD.
If both DEUs are operational, up to four different
display formats may be in use by pilot and copilot at We expect that new or modified sensors win] be
any time. It is thus completely up to the pilot and added to the HH-60D avionics suite in the future to
copilot which display formats will be displayed on their extend the operational life of the system. With our
MPDs and HIMs. shared control and display architecture, featuring
standardized, interchangeable control and display units.
The MPDs also provide control capability via 21 standard data and video interfaces, and software
"soft" keys located in the bezel of each MPD. The control, we have inherent growth flexibility. We
function performed by each key is software controlled. believe that the Night Hawk's mission controls and
and is displayed on the surface of the MPD near the displays are easier to use, have higher operational
key. When. for example, the [R mode (Forward reliability and survivability, and are lighter and less
Looking Infrared) is selected on a given MPD. that expensive than separate, dedicated control and display
MPD becomes a complete control and display surface panels.
for the IR sensor. If the RDR mode (Multi-Mode
Radar) is selected, the MPD becomes a complete Fum Appkd
control and display surface for the RDR sensor. We do
not have a separate control panel for either the IR or
RDR sensors, nor do we have separate panels for the HH-60D Night Hawk use of standard Air
remote map reader. INS, etc. Should any MPD faiL the Force/DoD eauipments. processors, software, and
function may be performed on any of the remainig interfaces is a good example of how these standards
MPDs. Should either of the two DEUs fail, all MPDI may be used without stifling creativity or limiting
and HMDs continue to operate, but the pilot and overall system performance or growth flexibility. In
copilot are limited to a total of two display formats. fact, the use of standard processors. interfaces, and
software has improved performance and growth
We do not have separate keysets for entry of flexibility. We expect very similr core architecture to
navigation data, communications data. etc. All be utilized on future projects in the helicopter/VSTOL
alpha-numeric data entry is via the two interchangeable area, such as the Joint Services Advanced Vertical Lift
keyboards. Should one fail, any type of data entry may Aircraft (JVX), and other avionics systems.
be performed on the other.

Biographical Sketch

Ira Glickstein is a Senior Engineer at IBM's Federal (ASIT), A-4M Angle Rate Bombing System. Light
Systems Division. Owego. New York. He served as Airborne Multipurpose System (LAMPS), AC-130E
lead systems engineer on the HH-60D proposal with Gunship. and A-7D/E Navigation and Weapon
responsibilities in the system architecture and Delivery System. He received Outstanding Contributon
controls/displays areas. He is currently in the HH-60D awards for hio work oan a computer memory correction
systems engineering department. method and for systems engineering efforts.

Ira has been involved in new busines and initial Prior to coming to IBM, he was employed by
development engineering for several piojects at IBM. Lockheed Electronics and Norden. He holds an
including: Coherent Emitter Location Testbed electrical engineenng degree from City College of New
(CELT), Army Command and Control Master Plan. York and a Professional Engineering License (New
Joint Tactical Information Distribution System York).
(JTIDS). Adaptable Surface Interface Terminal

387
 FAIRCHILD'S DATA TRANSFER SYSTEM - UTILIZING

THE LATEST MILITARY STANDARDS

AUTHORS

Stephen L. Belechak-Becraft/George D. Farmer

Fairchild Space & Electronics Company

ABSTRACT

Fairchild's F-16 Data Transfer Unit (DTU) is a cockpit mounted,

microprocessor-controlled unit which provides for automatic exchange of pre-

flight, in-flight, and post-flight information with the avionics system over

the MIL-STD-15538 (or A) serial digital multiplex data bus. This information
exchange is facilitated by a detachable nonvolatile Data Transfer Cartridge

(DTC). On the ground and away from the aircraft, the information in the DTC

is managed via the computer-based Ground Support Equipment.

The unit is implemented with the latest military standards

encompassing mux bus operation (MIL-STD-1553B), computer hardware imple-

mentation (MIL-STD-1750A), and software development and maintenance (MIL-

STD-1589B). Employment of these standards enhances commonality and compati-

bility with the latest avionic systems, improves maintenance, and reduces

life cycle costs.

389
BACKGROUND
Avionics systems of current military aircraft have substantial
and ever-increasing informational requirements. Specifically, this informa-

tion takes three forms:

a) PRE-FLIGHT:
Pre-program information into aircraft for initialization
of subsystems and for storage purposes so that the data
can be recalled during the flight. Such information may
include aircraft status, waypoints, stores management

initialization and sequencing, threat data, navigation

and communication data and coordination data.

b) IN-FLIGHT:
Record all flight parameters and pertinent mission data
to be used for analysis and debriefing. This data would
typically include threat location, tactical data, main-
tenance data, system "built-in-test", training informa-
tion, airframe and engine fatigue life. Also, during
flight, provide subsystem initialization parameters and
a flexible data base access.

c) POST-FLIGHT:
Retrieve all mission data for debriefing and maintenance

purposes.

The increase in digital communications and data processing

influenced by microprocessor development has given rise to system designs
that are programmable, flexible, and capable of handling a multitude of

options.

390

- - - j * . . ,, *, " ," ,
 At the present growth rate of computing power that can be
embodied in each subsystem, the demand for a method and mechanism to provide
efficient "data transfer" is necessary.

The magnitude of these informational avionic requirements have

reached a point where direct communication of this data to and from the flight
crew is not effective. The scenario is time consuming, prone to errors, and
quantity limited. In a fighter aircraft, the pilot must routinely enter a

thousand digital alphanumeric characters before take-off if he intends to

make use of present avionics processor capabilities. This is clearly unaccept-
able from an operation standpoint and unthinkable for next generation avionics.

An alternative is to use a memory storage device which can, on

command, automatically transfer data directly to/from aircraft avionic systems.
This device would complete this task faster and with fewer errors than the
flight crew. The memory storage element of this device would be portable and

nonvolatile; thereby, initialization, access, and analysis of this informa-

tion need not be conducted at the aircraft. Such a device has been developed
under the F-16 Data Transfer System contract award to Fairchild Space &
Electronics Company from General Dynamics.

391

-_:&A
 F-16 DATA TRANSFER SYSTEM
The Data Transfer System concept is depicted in Figure 1.
The Dati Transfer System consists of Data Transfer Equipment (DTE) and

computer controlled Ground Support Equipment (GSE). The DTE consists of

a Data Transfer Unit (DTU) and a Data Transfer Cartridge (DTC).

Utilization of this system begins at Pre-Flight. The ground-

based computer, GSE, accurately loads and verifies preprogrammed mission
data into the portable DTC for initialization of aircraft subsystems. The
DTC is then inserted into the cockpit resident DTU. In flight, the micro-
processor-controlled DTU provides real-time access to the DTU memory over

the MIL-STD-1553 data bus. After the flight, the DTC is removed from the
cockpit and inserted into the GSE. The GSE is then used to retrieve all
mission data for debriefing and maintenance purposes.

The OTE may be compared to secondary storage devices found

in computer systems. Relative to this analogy, the DTU is considered to
be the unit controller and the DTC is considered to be the unit storage
medium (e.g., floppy disk). As a secondary storage device, the DTE is
designed to interface as a remote terminal on a MIL-STD-1553 type data bus.

It is over this data bus that the DTE will receive commands and data and
a transmit status and data. This data exchange is depicted in Figure 2,

Avionic Architecture and Data Exchange.

*The DTU contains a complete file management system which

allows the bus controller (mission computer) to access data in the DTC
without knowing the address location of the data, only the "filename" is
needed. This also allows testing and data verification to be performed by
the DTU. The use of file management clearly reduces the new software
development overhead required by the bus controller in order to use the DTU.

392
 DATA TRANSFER SYSTEM

in DTC c6*01IW

~PREFLIGHT:

- PREPROGRAM INFORMATION INTO A DATA CARTRIDGE (USING GROUND SUPPORT

EQUIPMENT) FOR INITIALIZATION OF AIRCRAFT SUBSYSTEMS AND STORAGE OF
IN FLIGHT MISSION DATA.
~- INSERT PREPARED DATA CARTRIDGE INTO A COCKPIT-RESIDENT RECEPTACLE.
IN-FLIG HT:

-PROVIDE SUBSYSTEM INITIALIZATION PARAMETERS AND A FLEXIBLE DATA BASE.

- PROVIDE INFLIGHT MISSION DATA BASE
• " "", - "-' W "• - ' ,"-' .l , , - - :'_
- RECORD FLIGHT PARAMETERS, MISSION DATA AND MAINTENANCE
INFORMATION USED FOR ANALYSIS AND DEBRIEFING.

-PREMOVEATA CARTRIDGE FROM COCKPIT

- RETRIEVE ALL MISSION DATA FOR DEBRIEFING AND MAINTENANCE PURPOSES
A - UTILIZING THE GROUND SUPPORT EQUIPMENT (GSE), THE DATA TRANSFER
EQUIPMENT (DTE) SUPPORTS THE AUTOMATED CORRELATION OF
INFORMATION FROM MULTIPLE MISSIONS

Figure 1. Data Transfer System Concept

393

- -nil
 AVIONIC ARCHITECTURE
AND DATA EXCHANGE

D U UCNI PCR MPUD INS CAOC

$ 1563 AVIONICS MULTIPLEX BUS

FIRE
CONTROL SMS
COMPUTER
"* WA l
WEAPON
IUS I

1563 DISPLAY MULTIPLEX BUS

PDG

- AVIONICS BUS CONTROLLER TRANSFERS DATA TO AND FROM DTU

- SYSTEM SUPPORTS REAL TIME 1653 DATA TRANSFERS INCLUDING REMOTE TO
REMOTE MODES
- MULTI-FUNCTION DISPLAY HAS ACCESS TO THE DTC DATA BASE THROUGH FUNCTION
SELtCT SWITCHES. INTEGRATED BY THE FIRE CONTROL COMPUTER
- CHANGES IN DATA CONTENT ARE ACCOMPLISHED WITH THE MFDIKEYBOARD
- COMPUTER CAN ACCESS FILES/RECORDS WITH SYMBOLIC REFERENCES (FILE NAME
*RATHER THAN BY ABSOLUTE MEMORY LOCATION)
- MULTIPLE MODES OF FILE ACCESS PROVIDE FLEXIBILITY TO BUS CONTROLLER AND
SIMPLIFY CONTROL ALGORITHMS

Figure 2. Avionic Architecture and Data Exchange

394
Further, the mission computer does not have the burden of executing a file
management system, and associated error routines, otherwise needed if the
DTU did not contain same.

395
DTS APPLICATIONS
Figure 3 highlights the major types of information to be
stored and or retrieved from the DTC, such as: communication channels,

waypoints, threat data, etc. The DTU does address the proper handling of
threat data. A DTC erase switch in the cockpit is hardwired to the DTU
and can be activated by the pilot. The DTC contains CMOS RAM and, there-

fore, erasure is near instantaneous. If the OTC is removed from the DTU,

erasure can still take place by closure of the local erase switch on the
DTC itself.

Not only can the 0TU be used for the obvious purpose of data

transfer, but in addition may contain program overlays from the mission com-
puter, as well as being treated as an extension of the mission computer
memory.

Also listed in Figure 3 are the benefits of using the DTS,

ranging from reduced pilot workload to increased mission effectiveness.

396
 DTS APPLICATIONS
PREPROGRAMMED INFORMATION
- RADIO CHANNELS
- TACAN STATION LOCATIONS
- WAYPOINTS
- WEAPON DELIVERY PROGRAMS
- RELEASE POINTS
- NAVIGATIONAL UPDATES
- AIRCRAFT STATUS
- STORES MANAGEMENT DATA
RECORDED INFORMATION
- TACTICAL DATA
- THREAT LOCATION
- MAINTENANCE DATA
- SYSTEM BIT
- TRAINING INFORMATION
- AIRFRAME & ENGINE PARAMETERS

FUTURE APPLICATIONS
- PREFLIGHTIPOSTFLIGHT SYSTEM TEST ENHANCEMENT
- SUPPORT LARGE MEMORY STORAGE FOR
PREPROGRAMMING (TERCOM, ASPJ, ECM, ETC.)
- MISSION ORIENTED DATA BASE MANAGEMENT SYSTEM
- FLIGHT MANAGEMENT COMPUTATION

- REDUCES PILOT WORKLOAD

- DECREASES REACTION TIME
- REDUCES PROGRAMMING ERRORS
- INCREASES MISSION EFFECTIVENESS
- SUPPORTS MISSION COMPUTER
- SUPPORTS MULTI-FUNCTION DISPLAYS
- SUPPORTS ADVANCED SYSTEM AVIONICS
- IMPROVES MAINTAINAMILITY
- IMPROVES FLIGHT HISTORY RECALL
- IMPROVES OPERATIONAL EFFECTIVENESS
- PERMITS REAL TIME OPERATION WITH AIC MULTIPLEX DATA BUS
e.,

Figure 3. Data Transfer System Applications

397
AVIONIC SUBSYSTEMS
The present day avionic suite in modern military aircraft
is very "integrated". This term recognizes the need for subsystems to be
highly interactive on future aircraft. In the past, many of these sub-
systems were significantly independent in function. However, improved
performance can be obtained by correlating the information developed and
the control processes applied by these subsystems. Figure 4 (F-18 Avionics
Multiplex Bus) and Figure 5 (Advanced F-16 Avionics System Architecture)
represent present and near future avionic suites. Commnon to these air-
craft avionics is the following:

0 Multiple MIL-STD-1553 Multiplex Buses (trend to hier-

archical buses)

* Proliferation of Digital Equipment

* Software Intensive

* Intelligence distributed to each subsystem (Embedded

Processors, Microprocessors)

The DTU is consistent with the above trend. In support of

distributed processing, off-loading tasks from bus controller (mission
computer), the DTIJ contains a file management system to facilitate DTC
data accesses. Thereby, the mission computer needs only to know the data
organization within its file and not how the information is stored within
the DTC. This also allows testing and data verification to be the responsi-
bility of the BTU rather than the data user devices. DTC data access is
achieved by specifying a sixteen-bit logical file name. This opens a
512-word window (called a page) within the specified file. Data access
pointers are used as the pointers within the page where data transfers occur.

398

- - * ~ 'b ~ ~% q % % -
 NO.~ X I ONRO EGENERATOR

FLIGH I I GENERATOR
I .
IN___WCONTROL___J

U A

MANAGEMNT 399
 MMUN

UIS ~~~A
CaC W~lD lISI SN S AT Di

Figur F16
5. dvaned
Aioni Sysem Achitctur

400
 Commands are provided that allow bus devices to alter these pointers, change
the access window and examine system status including the
Spage number, file name, file size as well as other information. Data access

modes may also be specified to allow the using device the flexibility to
optimize data access for its particular application. Files may also be
write-protected either in flight or by the Ground Support Equipment prior

to the mission allowing read-only access to vital information. This file

management technique is analogous to accessing a floppy disk drive in a
commercial home microcomputer system.

Higher throughputs will be required from avionic subsystems

in near future years. The F-16 DTU contains full parallel address and data
line interface to the DTC, thereby providing an inherent high speed archi-

tecture. This architecture is depicted in Figure 6, DTU/DTC Block Diagram.

The D70 also addresses the importance of exhaustive self-test

and built-In-test (ST/BIT). The proper ground work for ST/BIT begins with
functional card partitioning within the unit. Each card in the DTU is an

isolated function: 1553 bus interface (BIU), microprocessor controller

(MICRO), memory and power supply (see Figure 6, DTU/DTC Block Diagram).
Testing in the DTE is divided into four categories: initialization testing,
real-time testing, background testing, and foreground testing. Initializa-
tion testing verifies that the DTE is operational before allowing any 1553
bus commands to be received. These tests include checking RAM, ROM, and

the CPU for proper operation. Should anyone of these fail, the DTE does
not respond to any bus commiands. Some hardware timing tests are also checked
at this time since bus traffic would prevent accurate timing measurements but
errors for these tests are only reported is the test status word and do not

401

I.

- -
 h ii A a I -

- DTCINSETION(POWROON

~ COMAD
ae CONRO

- SIT/SELF.TES

~~
- DTOEMVL(PWRCON
Lt
- DC RAS OCA EAS
-MATERS

- PROGRMMING
BEPRO
- ~ DUA
153POOOv(EETBE

-~ ~ ~ DT NETON(OE
N
 suspend OTE operation. Tests performed in real-time verify proper bus com-

munication. The Remote Terminal (RT) address in the received 1553 command

word is checked to ensure that the DTE is only responding to the assigned

terminal address. File management commands are checked to ensure they are

received in a meaningful sequence (such as reading data before a file is

opened for access). Data access commands are also checked for validity

(e.g., not reading more data than the file contains or writing to a write-

protected file). Other tests, such as illegal file names and data words

are also checked during this real-time phase of testing. Background test-

ing is conducted whenever the DTC is not busy processing bus commands. All

aspects of the DTU and DTC (with the exception of the BIU) are tested.

Checksums and parity are used to verify both local and DTC RAM. ROM and

the CPU as well as other hardware are checked for proper operation. Fore-

ground testing is initiated by a bus command. This allows the DTE to per-

form tests on the BIU. These tests verify proper operation of the Bus

Interface up to the bus transmitters (no data is actually sent out on the

bus). All of the other tests indicated above in the background test are

also performed.

There never seems to be adequate memory storage space in

avionic systems for future needs. The F-16 DTE design anticipated future mem-
-S.
ory requirements for such units as weapon systems, JTIDS, etc. The DTU can
address up to two megawords of DTC data. The present DTC can be configured

for up to 128K words (16 data bits plus one parity bit). This high density
is accomplished by the memory carriers used. Each memory carrier, measuring

less than 3.6" x 1.25" x 0.25", provides 8K words of buffered memory. On

every carrier are 32 4K x 1 CMOS memories with associated data, address,

and control buffers, each packaged in a leadless chip carrier. The DTC will

403

1'"20
allow up to sixteen memory carriers providing from 8K words to 128K words of
memory in 8K word increments. The electrical design of the interface cir-
cuits, both on and off the carriers, was implemented such that only one
memory carrier would be enabled during any given access. This yields
dynamic power requirements to be equal to that of just one memory carrier

regardless of the size of the DTC memory. The DTC was designed to contain
a large amount of memory but still maintain the access speed, power con-
sumption, and volume associated with much smaller memory systems. Todays
2Kx8 CMOS RAM provides DTC memory expansion to 256K words with the develop-

ment of new memory carriers.

40

4O4
 STANDARD ISSUES
Many avionic subsystems today are dedicated designs optimized
to an aircraft type or system. This magnifies DOD support costs (life cycle
costs) since support tools (hardware and software) are not common from air-
craft to aircraft nor even from program to program on the same aircraft.

Military standardization provides an effective means to lower

unit life cycle costs. MIL-STD-1553 bus interface is an example of a stand-
ardization that permits a common front end solution to avionic boxes.

The Data Transfer Units is developed with current Air Force

requirements and standards. The primary standards pertinent to the DTS are
MIL-STD-1553, NIL-STD-1589, and MIL-STD-1750. The 1553 Serial Multiplexed
Data Bus is implemented in the bus interface unit. Either 1553A or 1553B
may be selected by a jumper on the external signal connector. The two pro-
tocols as implemented in the DTU are different only by the valid mode code
definitions. Therefore, no changes will be required when retrofitting older
aircraft (1553A). The operational flight program (OFP) is currently written
in assembly language but will be replaced by a Jovial/J73 (MIL-STD-1589B)

version over the next three months. The assembly language OFP will be con-
verted to IEEE standard mnemonics to facilitate 1750A conversion as well as
making the assembly language routines needed for the J73 OFP compatible with

the J73 assembler and linker. The internal architecture of the DTU is de-
signed to be compatible with Z8002 or F9450 microprocessors. The DTU's 1750A
microprocessor card is designed to be form, fit, and functionally equivalent
to the present Z8002 microprocessor card in the DTU. No electrical or physi-
cal changes to the DTU will be required for the interchange of cards. Delivery
samples of the Fairchild Semiconductor 1750A microprocessor chip (F9450) is
expected in first quarter 1983. The 1750A micorporcessor board in the F-16

I 405 v.o5
DTU will meet the requirements of a MIL-STD-1750A processor. The 1750A
microprocessor board provides the following functions required for compati-

bility with MIL-STD-1750A: 1750A instruction set and functional architec-

ture, trigger-go timer, timer A, timer B, fault register, pending interrupt
register, interrupt mask register, status word, exhaustive decode of memory
and I/O address for the detection of illegal addresses, and detection of
incorrect parity during memory and 1/0 transactions. The 1750A micropro-
cessor board also provides address and data demultiplexing, I/O strobe gen-
eration, wait state insertion, DTC decoding, control signal translation, and
segment number latching necessary for compatibility with the Z8002 micro-
processor card. The prescaler for timer A and timer B, the trigger-go timer,

the illegal address detection, and the parity generation and checking are
implemented in circuitry external to the Fairchild Semiconductor F9450 CPU
which implements the remainder of the functions required by MIL-STD-1750A.

406
 GROUND SUPPO*

u und Support Equipment (GSE) provides three primary func-

tions: pre-flight DTE support, post-flight DTE support, and DTE testing
*and fault isolation. Prior to a mission, initial mission data must be

organized, formatted, and entered into the DTC. This information depends

on the aircraft mission but includes data for such systems as the inertial

navigation unit, communications, stores management and navigation waypoints.

Space is also allocated for files that will be generated during the mission.

All checksums as well as all other DTC format linkages are provided by the

GSE DTC formatting programs. When the DTC is returned to the GSE after a

flight, the files that have been created during the mission can be analyzed.

Data files such as new target positions can be used to generate pre-flight

data files for subsequent missions. Maintenance data files can be examined

by the appropriate personnel on the GSE without tying up the aircraft,

thereby conserving fuel and allowing the plane to be configured for its

next flight. DTC testing is normally performed both before each use to

ensure that the memories are properly functioning and that the battery has

sufficient energy to sustain the data between the time it is loaded and

when the information is retrieved after its mission.

Two versions of the Ground Support Equipment are available:

one implemented using a Digital Equipment Corporation PDP 11/24 (see

Figure 7, F-16 GSE), and the other using a portable desktop computer

(see Figure 8, Desktop GSE). Both systems provide full support capabili-

ties for the DTC and both have RS232C interfaces for host computer con-
nections where mission planning and analysis can be performed. Also,

both units use menu displays to simplify data entry. The PDP 11/24 system

also contains provisions for full test and fault isolation for the Data

407
 PDP CPU
L

*CONTROL
, POWER

/*

RL02 RL02
CARTRODE ]CARTRIDGE

- END TO END COMPATIBLE SYSTEM OPERATION

- INITIALIZATION OF THE DTC
- ENTER MISSION DATA INTO DATA TRANSFER CARTRIDGE (DTC)
- POSITIVE VERIFICATION OF STORED DTC MISSION DATA
VERIFICATION OF BArTERYIMEMORY DATA RETENTION
- INTERACTIVE ACCESS AND CONTROL OF DTC DIRECTORY, FILES AND DATA

- CONVERSION OF DATA FROM ENGINEERING UNITS TO APPROPRIATE BINARY

FORMATS AND LOCATION IN FILES
- CONVERSION OF DTC FORMATTED DATA TO ENGINEERING UNITS FOR ANALYSIS

- OPERATIONAL SUPPORT SYSTEM PROGRAM (OSSP) CAN BE MODIFIED TO MEET

VARIOUS DATA TRANSFER SYSTEMS REQUIREMENTS
- MONITOR DTC BATTERY FOR END OF LIFE
.Ai- PROGRAM TWO DTC'S SIMULTANEOUSLY

Figure 7. F-16 Ground Support Equipment (GSE)

406

. ..
. .. . .. . . .- "..............' "' , ","' ,' V", , ' "
 V6

Transfer Unit for shop-level support. The portable desktop computer GSE
has been delivered to Sperry Flight Systems on the Army Helicopter Improve-

ment Program (AHIP).

409
S.M rr-7 -uN3 -7 V772i -- - -- r - w- .-----

Iwo.
a

ICAI
-- l

40 LL0
: S S

LLU
4J

,Je 0L.

410

a,]

.. .
SUMMARY
Fairchild's Data Transfer Equipment (DTE) is a general pur-
pose solid state memory cartridge and memory management system providing

avionic computers and subsystems real time access to mission planning data.
A multimode file access system, under microprocessor control, performs all
file management functions, thereby reducing user overhead processing and

simplifying user interface.

This system, in conjunction with a ground-based computer,

provides an end-to-end capability to accurately load pre-flight mission
data, maintain in-flight memory access recordings, and perform post-flight
analysis. The system features high reliability, real time data exchanges
with the 1553 data bus, flexible file access system, and a high density/
capacity solid state nonvolatile memory cartridge.

Data Transfer Equipment features include:

* Compact high capacity real time memory access system.

* Portable nonvolatile memory cartridge expandable from

8K words to 128K Wids Atht- tj e1emory echnology

(CMOS).

* Memory growth to 2M words provided in hardware and soft-

ware for future high density 1pemories.

0 Integrity of data'storage and transfers enhanced with

high degree of error checking/detection throughout system.

* Rugged construction designed for expected handling environ-

ment.

411
~~ m q E y A L ~ . . ~ ~ ~ - r -r. . 1 - ,

Implementation with current MIL standards:

- MIL-STD-1553 A/B Multiplex Data Bus

- Z8002/MIL-STD-1750A Microprocessor

- MIL-STD-15898 Jovial (J73) Higher Order Language

Software

0 EEPROM in DTU memory permits reprogramming of DTOP soft-

ware through box connector.

* Multimode file management system.

Fairchild's employment of military standards enhances common-

ality and compatibility with the latest avionic systems, improves maintenance,

and reduces unit life cycle costs.

F-16 DTU Hardware Pictorials and Drawings are enclosed.

412
DATA TRANSFER FLIGHT HARDWARE

413
 DATA TRANSFER EQUIPMENT

DTU
Inc

DTU PHYSICAL CHARACTERISTICS

SIZE L75" WIDE x 4.5" HIGH x 7.0" LONG

WEIGHT 6.25 LBS.
CONSTRUCTION ALUMINUM ALLOW INVESTMENT
CASTING
POWER 26 WATTS WITH ZS000 PROCESSOR
30 WATTS WITH 1750A PROCESSOR

DTC PHYSICAL CHARACTERISTICS

SIZE 1.625" HIGH x 4.72" WIDE x 7.5" LONG
WEIGHT 1.5 LBS. MAX.
CONSTRUCTION ALUMINUM ALLOY INVESTMENT
CAST HOUSING & COVER
INTERFACE LOW FORCE CONNECTOR
LOCKING PINSIHANDLE
ALIGNMENT PINS

4.14
F-16 DTU MEMORY CARD

F-16 OTC CARRIER M4OTHER BOARD

415
F-16 MEMORY CARRIER

416
 - --- 1- .~ --

DTU ASSEMBLY

SDESIGNE FOR MANTAINA--ILITYOUSING

A AASSEMY

- DESIGNEROOEHNNER ETRTNF

- INVESTMENT CASTING FOR RUGG. CONTRUTIO

- ILLUMINATED PANEL (REMOVABLE WITH FOUR SCREWS) PROVIDES ACCESS TO
ELECTRONICS
- SPRING-LOADED COVER REMAINS OPEN FOR INSERTION OF DTC AND CLOSES UPON
EXTRACTION OF DTC
- POWER CONVERTER CARD AND ELECTRONIC PRINTED CIRCUIT CARDS ALL
* PLUGOABLE FROM PROCESSOR
- MP - MICRO FRONT OF THE UNIT
CARD (ZIU2FRlSOA)
- BIU - BUS INTERFACE CARD

- MEMORY - PROGRAM MEMORY FOR DTOP SOFTWARE AND BUFFER RAM

- POWER CONVERTER -- 110 VAC, 40CHz TO DC CONVERTER

417

-- - - - -
 DTC ASSEMBLY

ACCESS

BATTERY MOTHER BOARD

I
SOK WORD BASNVINE
-WPANDABLE TO I=3 WORDS WITH SUIRE NT CHIP MEMOR DENSITY -CMOS LCC
- MOTHERBOARD COMPATIBLE WITH 2W6 WORDS WITH DOUBLE DENSITY MEMORY CARRIERS
- MOTHERBOARD COMPATIBLE WITH 2M WORDS WITH &XDENSITY MEMORY CARRIERS
- LOCAL AND AUXILIARY ERASE CAPABILITY
- BATERY BACKED DATA RETENTION
- AILSAFE INSERTION PROCEDURE FOR DTE POWER ON
PROGRAMMABLE WAIT STATE OUTPUTS TO DTU TO ACCOMMODATE RANGE OF MEMORY
TECHNOLOGY
- POSITIVE LOCKING MECHANISM PROVIDES INDICATION TO PROCESSOR THAT CARTRIDGE IS
MOSERED AND LOCKED

418
 F-16
GROUND SUPPORT
EQUIPMENT

419
 + LOG

*I 30VU01S
P80al ANM
3AI~.I
3AM~3*
r
al' f6v accgss
co-ce "4
.684 DoNINkfm
-
LOCRB
a PLCs
.4

.$soALM

rae SIK

4.2.Vg
I -

LL-S

YCUOW vD4%Ll Lg.ca Coo

EN~VELOPE DRAWING

420
...
.~(a* ... .0 .A.4 .. "f .( ac1 4

ol.-ce .9-c I 5'

Amn
.4KPAA

* 4r

LJD.
ace ---.

_aL

l~aa -S~5o-. tN~a 1

000" *Nbvf CWt T* atow"DC ro M D^

we w ~C..VP,fn. GW= t

fa ..soc,1*

*tAD'Sa1 032.OSt1

StE tRt,.0*. 4VELOPE

aj &n*V DAT TRNI

421
 STEPHEN L. BELECHAK-BECRAn

Mr. Selechak-Becraft is presently Manager of Avionic Products Devel-

opment at Fairchild Space and Electronics Company. His present duties
include technical management of AvionLc 1 0 programs as veil as now Data
Transfer System applications. He Is also serving as Technical Advisor to
the F-16 DTS program for MIL-STD-1750A processor application.

Mr. Belechak-Secraft has ten years of experience In military avionics

development projects, from Initial system concept through production Integra-
tion and test. Prior to joining Fairchild. he was supervisor of an avionics
digital signal processor design end development team. Program assignmentb
have included: 7-16 Airborne Radar, F-16 Data Transfer System. Divisional
Air Defense Radar. Standoff Target Acquisition System and the Advanced F-16
Radar Programable Signal Processor.

DUCATION

Mr. Belechak-Secraft holds the Bachelor of Science in Electrical

Engineering from University of Maryland. and the Master of Science in
Computer Science from Johns Hopkins University.

ACADoIC AD PROFESSIONAL SOCIETIES

ETA KAPPA NU
MIL-STD-1750A User's Group

American Management Associations

9 GEORGE D. FARMR

Currently. Kr. Farmer Is responsible for software related issues

for Advanced Avionics Development. In thin role. he has been involved
In a number of proposals as vell as the development of IPAD systems.
Previously, Mr. Farmer served as lead software engineer for the Data
Transfer Unit (MTO) for the General Dynamics F-16 aircraft responsible
for both the Operational Flight Program as well as the test equipment
software deelopmnts. Previously, he developed the software for fault
detection/isolation and a network status display package for a fault
tolerant processor for use on the NASA Digital fly-by-wire F-8 test
aircraft. A study was al o conducted to utilize a similar instruction-
eynchronous fault tolerant processor as a Command Augmentation System
in the Fairchild A-IOA aircraft.
While working for MIT Lincoln Laboratory, he developed a Z-80 based
cockpit Information display system under the FAA DABS/Datalink program.
*This system used aircraft surveillance data supplied by the ground DABS
*computer to track nearby aircraft and provided collision avoidance via
a graphic representation of the encounter on a color CRT.

0:1 DUCATIQN
Mr. Fsrmer received his 4S degree in Aeronautics and Astronautics/
4Guidance
and Control from Massachusetts Institute of Technology in

January 1980.

422
 THE FAIRCHILD MIL-STD-1553 SERIAL MULTIPLEX BUS TESTER

Alan M. Dunn
Fairchild Space & Electronics Co.
Grmtwn, HD
ABSTRACT

The Fairchild Serial Multiplex Bus Tester (SMBT) is a general purpose

computer controlled MIL-STD-1553 stimulus/response/analyzer module designed
for use in maintenance and production test systems. Moreover, SMBT has been
selected to fulfill the data bus testing requirements of the Air Force Modular
Automatic Test Equipment (MATE) systems. The SMUT integrates Monitor,
Controller, and Remote Terminal functions into a single unit, which can be
rack mounted and remotely controlled via a IEEE-1188/ATLAS compatible protocol.
Modular design in hardware and software allow the SMUT to be modified to
customer requirements. The design enables the SMBT to be controlled and
synchronized by a master computer performing a coordinated total checkout of a
unit under test.

Conceptually, the SMBT may be thought of as three separate devices or

functions: a monitor, a bus controller, and a remote terminal simulator. These
functions may be operated in any combination. They are programmed via the IEEE-
4i88 interface with a protocol that is semantically compatible with ATLAS-type
test scenarios. The monitor allows the ATE system to collect 10241 word "windows"
of bus traffic and simultaneously accumulate error statistics on all bus traffic.
V Trigger modes may be programmed which aid in the positioning of the collected
"window" in relation to selected bus events.
The bus controller allows the ATE system to generate a major frame of up to
128 unique messages. The gaps between these messages may be programmed. Also,
various word and message errors may be injected into each message of the major frame.

The remote terminal simulator allows the ATE system to simulate UP to 31

remote terminals. As many as 128 different RT responses may be programmed. The
response time is programmable and, as with the bus controller, various word and
response errors may be injected into each response.

Architecturally, the SMUT is divided into a real-time "front end" and a

secondary "back end". The back end is a Z8000-based microcomputer which is
responsible for managing the IEEE-4188 interface and for setting up the front
end. The front end is a sequencer-driven design which handles monitor, bus
controller, and remote terminal functions in real-time. The interface between
the front end and the back end is several dual-port memory boards which are
easily expandable. Operationally the back end accepts test scenarios, translates
them into a special format which is loaded into the dual-port memory, and
commands the front end to start. The front end then begins operating per the
specially formatted scenarios. When monitor information is required, the back
end pulls it directly out of the dual-port memory and transmits it back to the
host computer over the IEEE-4188 Interface.

In summary, the SMUT is designed to provide necessary stimulus/response/

analysis capability for MIL-STD-1553 Line Replaceable Unit (LRU) testing.
Furthermore, the SMUT is designed to provide this capability in a manner that is
consistent with ATLAS-oriented ATE systems. The SMUT, with its substantial baseline
capability, compatibility with existing standards, and its modular, expandable
architecture, is targeted specifically for "off-the-shelf" ATE systems.

423
INTRODUCTION

The SMBT shown in Figure 1 is designed to perform extensive testing of

a MIL-STD-1553 type multiplex bus system. The three major operational modes of
the SMBT are simulating the bus controller, simulating up to 31 remote terminals,
and monitoring all transactions on the bus. The bus controller is
capable of emulating any bus controller with the added task of selected error
injection. The remote terminal simulator is able to emulate up to
31 remote terminals concurrently while also injecting selected errors. The
monitor verifies all transactions on the multiplex bus, recording all errors
detected and providing for triggering capabilities to trap certain selected bus
traffic information. In addition to each of the above, the SMBT is able
to operate with all or any combination of the above modes concurrently.

There are also two non-operational modes of the SMBT. These are the
setup mode and built-in-test (BIT). The setup mode is the period during which
the parameters for the operational modes are chosen. Bus controller commands,
remote terminal responses, monitoring functions, triggering modes, and error
injection are but a few of .the parameters which must be determined. BIT can
be initiated by the host computer via the system control port (IEEE 488 interface).
BIT will verify the operational status of the SMBT to a high degree of
confidence and, if a fault is detected, it will isolate the fault to its
associated printed circuit card.

Figure 1. Serial Multiplex Bus Teeter

424

M
-IJ ~ 1
 BUS CONTROLLER SIMULATOR

The bus controller for a MIL-STD-1553 type bus system initates all
messages on the bus. It transmits messages on a frame basis where the frame
is broken up into equally spaced subframes. Each subframe may contain a
unique set of messages. The SMBT is capable of transmitting error free
messages in this format, or it may be commanded to inject selected, timing,
protocol, or electrical errors into the transmission. The bus controller of
the SMBT will be discussed in two parts. First, the normal bus controller
functions will be explained, followed by the error injection capabilities of
the bus controller.

The bus controller of the SMBT is able to initiate normal bus traffic
as stated in MIL-STD-1553 (A or B). The basic format for a frame is shown in
Figure 2. Each frame is divided into equally spaced subframes. Within each
subframe is a uniquely specified set of messages. The content of each message
within the subframe may be uniquely specified from all others.

The normal operation of the SMBT bus controller is to output a frame of

commands and then to repeat this frame continuously until directed otherwise.
There are only two ways to alter this normal pattern, one is by adaptive polling
and the other is to program a one-shot frame.

SUB FRAME

CYCLE TIME

1 JM2 P3 IMP 1I

FRAME

INTER-MESSAGE GAP

,M 1 _M2 I I M3

SUB-FRAME

CMD * STATUSP AT

MESSAGE

Figure 2. From Sub-Frame and fteseqe Format

425
 ......z.-

The adaptive polling feature allows branching from normal sequencing

when a particular status word is received in response to a particular command.
Adaptive polling is enabled on a command by command basis. An adaptive
polling word is compared to the associated status word on a bit by bit basis.
If a match is not found, normal sequencing ensues. Upon a match, an adaptive
polling vector determines the new bus controller path to follow.

The one-shot frame is a subset of normal sequencing. The bus controller

may be commanded to stop transmissions after a user selected number of frames
has been issued.

Subframes within a frame are all equally spaced. The two programmable
aspects of the subframe are the number of subframes per frame and the length
of a subframe. The number of subframes within a frame can be from one to a
upper limit equal to the number of messages in a frame. The number of subframes
within a frame can also change during bus controller operations. Since an
adaptive polling acceptance vectors the bus controller to a different sequence
and an unlimited number of adaptive polling sequences can occur, the length of a
frame can vary widely during operation. The length of a subframe can be varied
by the user, but once chosen will remain constant for all subframes within
a transmission. The subframe interval may be varied from 40 microseconds to
650 seconds as follows:

" Ten microseos to 64i millisecs in one microsec increments.

" Ten microsecs to 650 millisecs in ten microsec increments.
a One hundred microseos to 6.5 sec in 100 microsec increments.
* One millisecs to 65 sees in one millisec increments.
* Ten millises to 650 secs in ten millisec increments.
The number of messages and their contents can vary from subframe to
subframe. The command in a message can be uniquely specified from all other
commands in the frame. The programmable aspects of a message are:

" Command Type

" Specific Command Word(s)
" Specific Data Word(s), if any
a Bus Used
" Inter-Message Gap
There are three comand types, bus controller to remote terminal (BC-RT),
remote terminal to bus controller (RT-BC) and remote terminal to remote terminal
(RT-RT). BC-RT and RT-BC commands both contain one command word, RT-RT contains
two command words. Under normal conditions only the BC-RT command has associated
data word(s) transmitted by the bus controller.

Each command word can be specified with different address, subaddress,

word count, and transmit-receive fields as specified by MIL-STD-1553.

426
NV.
After the command has been issued, the data must be specified, if
required. The set-up sequence of the SMBT specifies the desired data patterns
to be transmitted with the command. Each bit of every data word can be uniquely
determined for every command. But, since the SMBT hardware is table driven,
two commands with identical data patterns can share the same data table.

... This allows for less memory to specify a given frame providing for
either a memory savings or increased message quantity for a given memory size.
As another user option, a random data table can be chosen. The data from this
table is generated from a pseudo-random number generator.

-. ~ In addition to specifying the bit patterns of the command and data words,
A the bus on which the message is to be transmitted can be specified on a per message
basis. The spacing between each message within a subframe can vary. This
time, called the inter message gap, can be programmed from 4 microsecs to 32K
4microsecs in 0.5 microsec increments. The accuracy of this time will be -0.1
4 to +0.2 microsecs.

ERROR INJECTION

The bus controller of the SMET not only acts as a versatile bus con-
troller, but it is also able to inject errors within its transmission to verify
remote terminal(s) operation. The SMBT bus controller can inject a wide variety
of errors, on a bit, word, or message basis. The following errors can be
generated:

* Manchester error
* Inverted sync
* Parity
• Bit Count
* Discontiguous Data
* Word Count
e Amplitude Deviation
* Simultaneous transmission

A brief description of each of these errors follows:

AJi MANCHESTER ERROR - A manchester error is an error in which a bit is

transmitted without a zero crossing. The SMBT can inject Manchester errors in
bits 1 thru 15 of any command or data word. As many words as desired may
contain a manchester error.

INVERTED SYNC - An inverted sync error is one where a data sync is

transmitted in a command word or a command sync is transmitted in a data word.
The SMBT bus controller is able to specify the sync for every word in every
message allowing for as many sync errors as desired.
PARITY - Each word transmitted onto the multiplex bus should have odd
parity. The SMBT bus controller has the capability to transmit odd or even
parity for every word in any message of the frame.

427

< . ~
* ~ ~ - IN 2h* -

BIT COUNT - The normal bit count of a MIL-STD-1553 type word is 20 bits,
three for sync, 16 for data, and one for parity. The SMBT bus controller is
able to transmit from 12 bits (three sync, eight data, one parity), to 27 bits
(three sync, 23 data, one parity). The bit count is programmable in every word
of every message the bus controller transmits.

DISCONTIGUOUS DATA - All data words transmitted by a bus controller

should be preceded by either a command word or another data word with no inter-
word gap. The second command word of an RT-RT transmission should also follow
the first command word with no inter-word gap. The SMBT bus controller is
capable of inserting an inter-word gap in each of these cases. The gap is
programmable in any word of any message. The limits of the gap are from 0.5
microsecs to 7.5 microsecs in 0.5 microsec increments.

WORD COUNT - The number of data words transmitted in a BC-RT command

should be equal to the word count field in the command word. The SMBT is able
to select the number of words to be transmitted from none to 255 words. This
capability also applies to RT-BC and RT-RT commands. The data is sent contiguously
unless a gap is specified by the discontiguous data error.
AMPLITUDE DEVIATION - The amplitude of the output voltage of the SMBT
onto the 1553 data bus is programmable on a message basis. The range is
programmable from 250 millivolts to 6.5 volts peak to peak, line to line.
The output voltage of the SMBT is adjustable in 50 millivolt increments.
The worst case slew rate from one level to another is less than 20 microseconds.

SIMULTANEOUS TRANSMISSION - A normally operating bus controller in a

dual redundant system will not transmit on both buses simultaneously. The SMBT
bus controller is able to specify two independent commands, each to be transmitted
on a different bus. The two commands may be programmed to begin concurrently, or
the start of the second command may be delayed from 0.5 to 63 microseconds beyond
the start of the first.

REMOTE TERMINAL SIMULATOR

The remote terminal(s) simulator for the SMBT is capable of emulating

up to 32 remote terminals simultaneously. The SMBT is able to simulate the bus
traffic on a given dual redundant multiplex bus system or any part thereof.
In addition to the remote terminal(s) emulation, the SMBT remote terminal has
the capability to inject errors in the response. The requirements of the SMBT
remote terminal(s) simulator will be discussed in two parts, normal simulation
and error injection.

428
 REMOTE TERMINAL FUNCTIONS

The command word of a 1553 type message is broken up into four fields;
the address, the transmit/receive (TR)bit, the subaddress, and the word
count/mode field. The address specifies the remote terminal to which this com-
mand is directed. There can be up to 32 different remote terminal addresses.
The T/R bit specifies if the remote terminal is to accept or transmit information
over the bus. The sub-address field provides a means to specify up to 32 dif-
*ferent tasks for the remote terminal to perform. One of these tasks can be to
use the word count/mode code field as a mode code which specifies another
possible 32 tasks (usually front end related) that can be performed. The word
count/mode code field specifies the number of data words to be transferred for
this command when in the non-mode code function. For a a more detailed explana-
tion refer to the MIL-STD-1553 Specification.

The SMBT remote terminal is able to emulate the above terminal. It

monitors for the selected addresses then, when a match occurs, the remaining
fields are decoded to determine the action required to take place. The SMBT
creates a vector address by combining the address field, the T/R bit, and
either the subaddress field or mode code field, whichever is applicable. This
eleven bit quantity is used as an address pointer to a command-status response
table. This table contains information about the transmission of the status
words and the transfer of all data words.

The capabilities of the SMBT remote terminal(s) simulator is as follows.

The SMBT is capable of emulating up to 32 remote terminals at the same time.
The status response returned on the bus is uniquely determinable for every
address, T/R bit, and subaddress or mode code combination in the command
word. The data associated with each status is also uniquely determinable for
every command word. However, to conserve memory space, status and data responses
may be shared by multiple commands. The SMBT configuration for the MATE program
allows for 128 unique status responses and up to 8 unique data tables. The
response time of the status word is programmable in 0.5 microsecond steps from
4.0 microseconds to 127 microseconds, and is uniquely programmable for each
status response.
The data table requirements are identical to those of the SMBT bus
controller. Each status response points to its desired data table. The data
tables specify the data pattern desired for the particular status response.
Random data is also provided. Each data table can be shared by multiple status
responses to conserve memory. Incidentally, since these tables are specified
identically to the bus controller data tables, the bus controller and remote
terminal simulators can share data tables to provide for additional memory
savings. Under normal, error free operating scenarios, the SMBT will transmit
the status response on the bus from which it received the command.

REMOTE TERMINAL ERROR INJECTION

The SMBT remote terminal(s) simulator has the capability to inject errors
in its transmissions much as the bus controller does. The errors which can occur
in a status response area are as follows:

429
 " Manchester Error
" Inverted Sync
" Parity
" Bit Count
" Discontiguous Data
* Response on wrong bus
" Word Count
" Response Time
MANCHESTER ERROR - As in the controller mode, the SMET can transmit any
word in the status response with a Manchester error. A Manchester error is an
error in which a bit is transmitted without a zero crossing. The SMBT can
inject Manchester errors in bits 1-15 of any status or data word. As many words
as desired may contain Manchester errors.
WORD COUNT - The number of data words transferred in a non-mode code
response should equal the value in the word count field of the command word.
The SMBT remote terminal(s) simulator is able to select the number of data words
to be sent in relation to the word count field. Both a word count high, or a
word count low error may be introduced by the SMET remote terminal simulator.

RESPONSE TINE - The time that a remote terminal must respond to a valid
command is referred to as the response time. MIL-STD-1553 A and B define the
maximum and minimum limits of this time. The SMBT is programmable, on a response
basis, to provide a response time from 4.0 microseconds to 127 microseconds.
The response time is programmed in 0.5 microsecond increments.

INVERTER SYNC - An inverted sync is when a data sync is transmitted in

a status word or a command sync is transmitted in a data word. The SMET remote
terminal(s) simulator is able to specify the sync for every word in every
response allowing for as many sync errors as desired.

PARITY - Each word transmitted onto the multiplex bus should have odd
parity. The SMET remote terminal(s) simulator has the capability to transmit
odd or even parity for every word in all responses.

SIT COUNT - The normal bit count of a MIL-STD-1553 word is 20 bits,

three for sync, 16 for data, and one for parity. The SMET remote terminal
simulator is able to transmit from 12 bits (three sync, eight data, 1 parity),
to 27 bits (three sync, 23 data, 1 parity). The bit count is programmable in
* every word of every response transmitted.

430
. X u-r .- F .'-7~* - * - - . -

DISCONTIGUOUS DATA - All data words transmitted by a remote terminal

should be preceded by either a status word or another data word with no
inter-word gap. The SMBT remote terminal simulator is capable of inserting an
inter-word gap. The gap is programmable in any word of any response. The
limits of the gap are from 0.5 microseconds to 7.5 microseconds in 0.5
microsecond increments.

RESPONSE ON WRONG BUS - Under normal operating conditions the SMET

remote terminal simulator will respond with the status word or the bus which
transmitted the command. As an error condition, however, the SMBT can be
programmed to respond with the status always on bus A, always on bus B, or on
the bus opposite the one which transmitted the command.

MONITOR
The SMET monitor is responsible for transferring all information from
the multiplex bus to the system processor. In addition to the data bits of the
command, status, and data words, this information includes additional parameters
characterizing each word. Information such as word type, gap time, error(s)
present, sync polarity, and on which bus the word was received is recorded.
The SMBT monitor is also responsible for maintaining various error tables and
for detecting and the reporting of triggers. The monitor will be discussed in
three parts, the bus traffic table, the statistical tables, and the triggering
capabilities.

BUS TRAFFIC TABLE

The bus traffic table contains all received data from the multiplex
* bus including annotated information. The standard table is 1024 words long
* and is double buffered. Information gathering takes place in one buffer while
the system processor is examining the data in the other buffer. Buffer switching
occurs when triggers are detected. The trigger is placed at the middle of the
buffer. This provides the trigger and the 500 words before and the 500 words
after the trigger in the buffer for examination by the system processor.
* In addition to gathering the data information from the bus, the bus
traffic table also gathers status information for each word as listed below.

* Gap Time - the gap time from the beginning of this word to the end
of the preceding word is recorded. This information provides
a means to calculate inter-message gap (last word of previous
message to first command word), status response time (last word
of command to status word), and word contiguity (first command
to second command in RT-RT, status word to data word, and data
word to data word). Gap time is recorded with a 160 nanosecond
resolution.

* Type of Word - Specifies if this word is a first command word,

second command word, status word, or data word of the message.I
" Bus ID - This reports the bus associated with the word.

1431
 * Errors -Abit is assigned for every error the monitor provides
as trigger inputs. A complete list of the errors detected by the
SMET is contained in Table 1.

* Trigger - A bit which indicates if a trigger occurred during the

reception of this word.

* Transmit Status - This information is placed in the bus traffic

table by the SMBT bus controller or remote terminal(s) simulator.
The bit pattern is determined by the user. This feature is
provided so that the bus controller or remote terminal(s) simula-
tor has a means to indicate to the monitor what their current
status is, allowing some real time monitoring of the transmit logic.

STATISTICAL TABLES
c The bus traffic table is a very complete record for the windows of
information it gathers on the bus, but it can miss sections of bus traffic
while the system processor is busy analyzing data, and transmitting it back to
the host computer. The statistical tables provide all information concerning
bus activity in selected areas of interest.* These tables compile information
continuously from the start of the monitor's activity, until directed to stop.
The statistical tables generated by the SMET are the following:
" Terminal Error Count Table
" Status Response Analysis Table
" Bus Activity Table
" Error Time Analysis Table

Each of the above tables is generated simultaneously along with the

bus traffic table.
TERMINAL ERROR COUNT TABLE - The terminal error count table is a
tabulation of all detected error types vs. all remote terminal addresses. Each
entry represents the number of times the particular error type occurred for
the particular remote terminal. The range of this number is from 0 to 65,535.
When the maximum count is reached, the value will roll over to 0. Table 1
lists all error types detected by the SMBT monitor.

TABLE 1.* SMBT Detected Error Types

Invalid Word - parity, Manchester, bit count
Word Count High
Word Count Low
Simultaneous Bus Traffic
Late Response Time
Early Response Time
No Response
Discontiguous Data
Intermessage Gap Time High
I' Intermessage Gap Time Low
Response on Incorrect Bus
Inverted Sync

43 z
 a'tieSTATUS RESPONSE ANALYSIS TABLE table is a listing of the number
-This

tmeseach of the status bits was set for each remote terminal address.
of
The status bits infilude the eleven non-address bits. The range of each entry
is 0 to 65,535. When the maximum value is reached for any entry the value will
roll over to 0.
BUS ACTIVITY TABLE - The Bus Activity Table lists the number of commands
which have been issued to each remote terminal. Separate counts are kept for each
bus, as well as a total count on both buses for each remote terminal. The range
for each entry is 0 to 65,535 with roll over occurring if the maximum limit is
exceeded.
ERROR TIME ANALYSIS TABLE - The Error Time Analysis Table preserves a '
S record of' each time a "trigger" occurs in the SMBT monitor. This table
contains up to 10241 entries which record the trigger condition, the 1553 bus
word, all error bits, and the time of occurrence of the trigger.

TRIGGER
The monitor continually checks for triggers. When a preselected
trigger(s) occurs, the monitor will switch buffers in the bus traffic table
and inform the system processor that a trigger has occurred. There are five
sources of triggers, the monitor error detector, the monitor word detector,
the SMBT bus controller, the system processor and an external trigger. Each
of these triggers can be masked and combined to form the trigger condition.

ERROR DETECTOR - The monitor detects the errors listed in Table 1.* The
errors, when detected can be used as triggers. The monitor will apply a trigger
mask to the errors to enable only user desired errors. The enabled errors will
be ORed together to form the error detector trigger.

WORD DETECTOR - A second source for triggers in the monitor is the word(s)
detector. The monitor is able to compare from one to eight words of a particularI
type to a preprogrammed sequence of words. The types allowed are command words,
status words, data words, or all words. The pre-programmed sequence of words
will contain a desired bit pattern of ones, zeroes, or don't cares. Each word
of the desired type is ANDed with a mask word and then compared to the pre-
programmed words.* If type consecutive words from the bus compare to the

pre-programmed words in bit pattern and order, a trigger is generated.]

SMBT CONTROLLER - The SI4BT bus controller simulator is capable of
generating triggers. One of the bus controller instructions provides for a
N trigger generation. This allows triggers to be generated at any point within
S the bus controller routine. In this manner the system processor can be
informed in real-time of events requiring its attention.I
SYSTEM PROCESSOR - The system processor is able to generate a trigger
to the monitor logic. It will also be able to inhibit all triggers to allow
freezing of the double buffer bus traffic table.

EXTERNAL TRIGGER - A differential external trigger input is provided

to the SMBT to allow synchronization of the SMBT monitor with real-time events.
A pulse greater than 100 nanoseconds in length at the external trigger input
will trigger the SMBT monitor.

~433

.'4~~~~ ~ V. -V ~V~*~ ~ k.LL -

 BIOGRAPHY

ALAN M. DUNN

Mr. Dunn is presently Section Manager of Digital Circuit Design

at Fairchild Space and Electronics Company, Germantown, Maryland.
During his ten year association with Fairchild, he has participated
in a variety of avionic and space programs. His primary responsi-
bility is in the design and development of microprocessor based
equipment. Mr. Dunn provided the technical leadership for the design
4$ and development of the Fairchild Data Bus Monitor Controller, the
first commuercially available MIL-STD-1553 tester.
As with the DBMC, Mr. Dunn is now providing technical leadership
for the MATE/SMBT Program.

( - EDUCATION

Mr. Dunn holds a Bachelor of Science degree in Electrical Engine-

ering from the University of Maryland and a Master of Science in
Computer Science from George Washington University.

'43
- . -i17 .4. - --- 77 .2M ' -77- 77 77 ' 7- 7 - ---

SOFTWARE ENGINEERING SERIES IN THE

FEDERAL GOVERNMENT

PRESENTOR: GWENDOLYN E. HUNT

ASSOCIATE, SYSTEMS TECHNOLOGY
OFFICE, PACIFIC MISSILE TEST CENTER

ABSTRACT

SOFTWARE ENGINEERING PROJECT

PROFESSIONAL COUNCIL OF FEDERAL SCIENTIST
AND ENGINEERS

The West Coast Region, Professional Council of Federal Scientists

and Engineers has been exploring the difficulty encountered by the lack
of specific classification and qualification standards in the Federal
government for positions in the emerging field of software engineering.
This paper provides an account of the efforts to develop the software
engineering occupational series. It also describes interim approaches
by the Department of Navy, and some of its field activities, to
alleviate the problems of recruitment and retention, undefined career
paths and salary inconsistencies.
Finally a prognosis is provided of the success of the project,
together with the new initiatives which are being studied.

435
 7 - - F.7 V 7

SOFTWARE ENGINEERING SERIES IN THE FEDERAL GOVERNMENT

PROFESSIONAL COUNCIL OF FEDERAL SCIENTISTS AND ENGINEERS

ADVISORS TO THE DIRECTOR, SAN FRANCISCO REGIONAL OFFICE
FRANCIS V. YANAK, DIRECTORA

BACKGROUND

In the mid-sixties, the Department of Defense (DOD) began its trend

toward the acquisition of weapon systems embodying digital computers as
a primary component of a total system.
These computers performed the functions of data storage, process
control, and complex decision making. In order to perform these
functions, the computers required a set of instructions and data which
was narrowly called software. The continued miniaturization of computer
hardware through gigantic technological advances forced an acceleration
of this trend in the seventies. Simultaneously, decreased national
productivity, an unstable economy, energy shortfalls, and the increase
in Federally supported social services fostered the proliferation of
computers in the non-defense sectors of the Federal government.
In both environs, the complexity of the development, operation, support
and management of these computer-based systems spawned a community of
government employees whose required knowledges, skills and abilities
(KSA's) transcended traditional academic disciplines such as
mathematics, engineering, physics, and the like. These required KSA's
have been described in subject matter literature since the late sixties
as "Software Engineering", with the unique individual processing these
KSA's being known as a "Software Engineer." A recent software
engineering text provides the following:
"Among the many definitions of software engineering proposed since 1970,
the most accurate and descriptive was by F.L. Bauer of the Technical
University, Munich, Germany, in 1972. His definition can be stated:
~* ~ The establishment and use of sound Engineering
Principals (methods) in order to obtain economi-
cally software that is reliable and works on
real machines
This definition of software engineering encompasses the keywords that
are the heart of all engineering discipline definitions: sound
engineerinq rnils economical, reliable, and functional (works on
*real machines)." 29

436
 7777

To paraphrase, Software Engineering is the application of knowledge of

q mathematical and physical sciences acquired by specila. education,
training and experience to the various aspects of software system
design, development, and management essential to insure effective,
* efficient and economic utilization of computer system resources.
The Software Engineer is responsible for various aspects of software
system design, development, and management essential to insure effec-
tive utilization of computer system resources as elements of major .

physical or environmental systems which incorporate one or more specific

engineering disciplines. The computer systems are generally embedded
and/or integrated within a major system complex and provide direct real-
time control of and/or perform specific tasks within one or more of the
system functional elements.
While there is an equally important required skill of understanding the
computer and its languages, the software engineer must understand the
operation, functions, and interfaces of the total system in order to
effectively solve complex problems necessary to design algorithms and
instructions for the computer, resulting in an economical and reliable
system.
Private industry has already recognized this emerging technological area
and has established a career field for the software engineer. With the
demand far exceeding the supply, industry is also offering premium
salaries to applicants. Without a designated software discipline, the
Federal service lags behind industry and this compounds the recruiting
problems. The software engineering Job category must be recognized in
the public sector in order to overcome the recruitment and retention
obstacles which already include salary disparity within the industry and
lack of specific, well-defined career patterns in this field.
The West Coast Regional Council of Professional Scientists and Engineers
had for some time been exploring the difficulty caused by the lack of
appropriate classification and qualification standards in the Federal
government. The Council is composed of senior civilian representatives
of the DOD and other Federal civilian activities in the Western Region
which employ fifty or more professional employees engaged in research,
development, test and evaluation. It was established as an advisory
group to the San Francisco Regional Office of Personnel Management (OPM)
by the director, Francis V. Yanak. Through its involvement with the
many initiatives to upgrade the quality of the Federal technical work
force, it was successful in obtaining special pay rates for engineers;
first in the Western region, then nationwide. A more recent effort is
to obtain approval to extend this special pay status to all scientists.

The software engineering project was officially intiatiated in 1979.

The approach was that the Western Regional Office, utilizing field
activity resources accessible through its Professional Council of

~437
 Scientists and Engineers, undertake the development of a new engineering
series for Software Engineers. The first phase of the effort was to
conduct an occupational survey resulting in a definition of a new
series. Later efforts would be concerned with full classification and
qualification standards under the guidance of the Standards Development
Center OPM, Washington, D.C.
At the same time, the Department of the Navy System Commands, Material
Command and Field Activities were being plagued by the same problem.
The Master Plan for Tactical Embedded Computer Resources, a Naval
Material Command document states:
"Weapon systems software acquisition and maintenance
are becoming sufficiently important that consideration
should be given toward establishing a separate career
field for weapon system software engineers. Also,
software acquisition and maintenance is sufficiently
complex and challenging so that career incentives should
* be developed to attract and retain good personnel." (4:3-39)
4 The document suggests an action program which would:
0 Identify the software personnel requirements.
* Review the current classification procedures.
* Review training requirements and training
capabilities for preparing software engineers.
* Recognize this expertise as critical and develop
A necessary career programs and incentives.
Separate and independent initiatives began sprouting throughout the
government as more and more dependency upon the computer was evidenced.

The Air Force added software engineering courses to the curriculum at

the Air Force Institute of Technology (AFIT) and the Naval Postgraduate
School offered a degree in Computer Science.
The prime thrust of all this activity, however, was a reaction to the
computer technological explosion and many efforts proceeded redundantly
rather than synergistically.

MAJOR ISSUES
The problems of providing sufficient numbers of qualified software
3
A personnel did not lend themselves to short-term management resolutions.
The full impact on qualification requirements, and hence on recruitment

'I 438
 and placement, from the establishment of a highly specialized series
such as software engineering had to be thoroughly analyzed to assure
that the benefits to be gained outweighed the disadvantages to be
incurred. The vast number of Federal employees already performing
duties requiring specific KSA's of computer resources and classifed
to other occupational series, some non-professional such as the Computer
Specialist, caused the following issues to be considered:
1. Is Software Engineering a *professional" occupation; i.e.
requiring a engineering academic preparation. According to the position
classification standards for the Engineering series:
"Whether an occupation is placed in the
engineering group of physical sciences
group depends upon whether the nature of
the work and the qualifications required
for its performance are predominantly
identified with an engineering or physical
science discipline. It is the conmmon core
of professional knowledges and abilities
representing a discipline required for
perfornance of the work which distinguishes
series within occupational groups. Areas of
application or investigation are of secondary
significant....
In some cases, where large numbers of multi-
discipline positions constitute what may be
considered to be a new profession or occupation
with a cowmmon core of duties and qualifications
required, a new series is established, e.g., Soil
Conservation Series." (5:11,12)
By definition, the Software Engineer is responsible for the applicati on
of engineering principles, theory and concepts to the development of the
software which works, reliably and economically. These requirements
imply a specific academic progression to a certified level of competence,
even though many years of experience may sometimes narrowly suffice.
For example, an individual who "engineers" weapon system software must
have knowledge of the avionics subsystem within the weapon system if he
is to develop, design, or maintain the embedded weapon software and/or
firmw'are. One must understand the environment in which the weapon
0.£system is employed, i.e., threats, countermeasures, etc. In addition,
there is the equally important skill of understanding computer and
languages. Both these skills are required to be effective in designing
algorithms and the instructions for the weapon system embedded digital
computer. This example holds true for large, complex, non-embedded
systems which control many subsystems as an integrated entity.

439
 2. What is the impact of the lack of series definition,
specialization, classification and grade criteria?
Since there are no classification standards in Federal service for this
engineering field, Federal agencies have been forced to establish and
fill professional software positions from related disciplines such as
Electronic Engineers, Mathematicians., Computer Specialists, Aeronautical
Engineers and General Engineers. This clouds the career patterns of the
selectee, since the individual is not "set apart" in title and/or series
as to his specific expertise in software engineering. The lack of
series definition and specific classification criteria create an
opportunity for misunderstanding in grading positions since the
classifier must search for an appropriate standard or standards which
will properly grade the duties of the Software Engineer.
3. Are there recruitment and retention obstables?
Industry has recognized the need for a career field for the Software
Engineer. Given the fact that demand for Software Engineers far exceeds
the supply, and that premium salaries are being offered by industry, the
Federal government is lagging behind in recruitment and retention. At
the entry level, salaries offered by private industry exceed Federal
salaries by as much as $10,000 or more.
Once in the Federal service, the lack of a defined career path for Soft-
ware Engineers impacts upon retention.
Although the government provides the opportunity for challenging work,
and the opportunities for meaningful advancement, competitive salaries
are necessary in order to attract and retain highly qualified personnel
in this new and emerging discipline.
4. What is the impact on employees with other series
* designations who might be subject to reclassification?
Positions currently properly classified will not be impacted. Those
classified to a profiliiVo--a engineering or mathematics discipline and
whose primary duties are 'software engineering would require a change to
the new engineering series. Those properly classified in the non-
professional GS-334 series will remain as they are.
The qualification standards must be developed such that the basic
requirements and alternate requirements permit the placement of all
incumbents of "certified" software engineering positions.
These issues were given primary consideration; and, after many Ad Hoc
discussions, separate attempts at alleviating the problem within
specified time windows were initiated. In the following paragraphs, an
account of representative efforts 1is di scussed.

440
DEPARTMENT OF NAVY EFFORT

The Navy's investigation of the problem began with 20 Navy representatives

attending a meeting in August of 1979 to study the computer software
engineering field in order to better understand this emerging occupation
and the role it plays within the Automatic Data Processing (ADP) community.
The Navy's plan of action included:

1. Define the scope of the Study

* Develop an overall plan for the study including

- Study format
- Methodology
- Milestones

e Tie-in with the OPM - Professional

Council for Federal Scientists
and Engineers, San Francisco Region,
Project for a Software Engineer Classification
standard
* Identify major functional areas
* Identify major problem areas and issues

2. Identify Procedures and Assignments

* Define workload and assignments

* Conduct fact-finding
* Develop a draft of findings
* Coordinate with other offices and
activities in geographical
area/systems command
* Corroborative fact-finding by OP-141C1
3. Develop Final Draft of the Study

* Review and develop draft Interpretive

Memorandum
* Circulate draft for review and comments
* Complete final draft for publication

4. Publish Interpretive Memorandum on Computer Software

Engineering Positions.

441
* ~ ~M --. W . .i~~'.. '~-

Some resistance to the study effort was evident by those activities with
a large number of software personnel classified under the 334 standard;
however, the majority of the new activities agreed that a special*
classification series should be established for the long term.
Many problem areas and issues were exposed, the most pervasive issue was
an uncontested description of the software engineering discipline and
the associated minimum basic qualifications.
The final results of this effort was an Interpretive Memorandum to aid
in the classification process. (3)

INTERPRETIVE MEMORANDUM
The Interpretive Memorandum, which was formally issued in October 1981
from Navy Personnel Headquarters, offers extensive classification
guidance on Software Engineering positions which was completed at Navy
Personnel Headquarters. It provides criteria for determining the
classification of engineer and other professional positions involved
with computer software engineering for embedded or similar computer
systemu. "Software Engineering, as defined in this memorandum, covers
the engineering work pertaining to the research, development, design,
testing, production, installation, maintenance, operation and other
functions relating to computer programs and the data required to allow
the computer to perform its functions. This guide provides occupational
information and grade le-vel criteria for the classification of Navy
positions requiring the performance of professional technical work in
the field of computer software engineering.

NAVAL SURFACE WEAPONS CENTER (NSWC)

For the Naval Surface Weapons Center, the Interpretive Memorandum has not
solved the total problem. The Naval Surface Weapons Center has been
concerned with identifying the academic preparation and the actual
preparation of personnel. (Reference Appendix A). Because of the
different backgrounds of those involved in the study, an early decision
was made to ignore the titles of positions and the job descriptions.
NSWC began by identifying the knowledge areas important to the
development of the Nayy systems for which NSWC has, or could have,
reponsibility. These knowledge areas, considered to be necessary for
those individuals developing successful systems consist of:
1. Controls - controls, information feedback systems, basic
systems distinctions (open loop, closed loop, hierarchical, etc.).
2. Process exposure/dynami c interrelati -onships - time-
dependent behavior, system interactions, the "process" concept, cross
effects, binding time, process comunications, cooperation and compe-
tition.

44.2
4NI-MM oKI7IF%1 NV-7

3. Design Principals -the principals of engineering (or the

scientific method), elements of the design activity (specification,
analysis, decomposition, synthesis, testing), maintenance and reliability.
4. Interpersonal communication skills - written and verbal
communication, team participation and team leadership.
5. Functional capabilities of digital hardware - logical
structure and composition. (This area was recognized to be potentially
divisible into computer hardware and digital non-computer hardware.)
6. Software design technology - system life cycle, speci-
cation techniques (e.g., PSL/PSA, Workbook, Jackson, etc.), development
techniques (e.g., chief programmer, structured walk-through, design
* reviews, builds, code reading), documentation, modification and mainte-
nance.
7. Evaluation - systems analysis techniques, models and
modeling identification or creation of alternatives, characterization of
trade-offs.
8. Systems integration - component and subsystem testing,
system reliability, progressive testing, diagnostic capability, degraded
mode options, recovery.
9. Programming systems techniques - programming languages,
systems programs, structured programming, modularity, stubs, program
documentation, program testing.
a10. Human factors engineering - human/machine interface,
dialogue design, prompting, "trainabilitym and "learnability", adapt-
ability and design and change. (This area was recognized as potentially
divisible into software design for human use and hardware design for
human use.)
In addition, a plan has been devised by the Software Engineering
Committee for the acquisition and training of Software Engineers for the
Naval Surface Weapons Center. It was recommended that all newly hired
persons who are intended for organizations involved in software
development and do not already have an appropriate background be
included in the Software Engineering Development Program. Others who
wish to change from their present jobs to developing software will also
be included.
The plan assumes that the trainees have no detailed knowledge of
computers but that they do have at least a BA degree or equivalent in
one of the scientific fields. Training opportunities will also be
provided for experienced software development personnel through a series
of short courses conducted at the Center.

443
 The Plan includes a two-step training program including formal classes
as well as On The Job Training (OJT) with specific training experiences
* to be added-as needed. (Reference Appendix A).

Pacific Missile Test Center (PMTC)

At the Pacific Missile Test Center, the impact of the shortage of
employees having software engineering expertise is severe. It causes
understaffing of current operations and overworking of available
people. There is great fluidity in labor supply which leads to round-
robin attrition, lost continuity and an unbalanced work force. High
attrition leads inevitably to a high risk environment in terms of
performance, schedule, and cost.
It became increasingly evident that a plan to overcome this growing
problem was needed to increase the supply of skilled software engineers
from within the organization. The proposed pr'ogram addressed a modular
approach which:
(a) offered a career training program at the undergraduate
level.
(b) provided for career branching after the undergraduate
program is completed.
(c) offered several graduate certificate programs to
employees currently having a bachelor's degree in the
professional fields.
(d) provided for up-dating state-of-the-art to employees
currently working in the software field.
The objective of this program would be the potential creation of new
resources for the areas of Software, 7lectronic Warfare, and Test and
Evaluation.
The Career Development Division was tasked to design a Software Engineering
Career Development Program which would offer modular training opportunities
and attract potential resources to the software engineering function at
* the Center.
A survey of need for this function was conducted in late fiscal year 1977.
0 -, The scope was limited to software support for scientific and engineering
functions and excluded management, business, and supply functions. The
training program was to be designed around requirements for Tactical
Fighter Weap.ins Systems software requirements, since the biggest "gp
was occurring within this function. Further, it was felt that any

444
training program designed to meet needs for this highly specialized area
would automatically include the knowledge, skills, and abilities necessary
to meet the requirements in the excluded areas.
The survey indicated an immediate requirement for 46 new journey
employees to meet current demands; 10 additional requirements for fiscal
year 1978; and 11 additional requirements for fiscal year 1979. When
coupled with retirements and attrition rates over a five year period, it
became evident the need for qualified software engineers far exceeded
the supply. In addition, many of the current employees badly needed
training to keep abreast of the exploding technological changes
occurring in the software field.
An intensive recruitment program was then mounted to attact such
resources to the Center. In addition to attracting recent college
graduates at the entry level, attempts were made to capture intermediate
or journey professionals in the field. Although some gains were made,
the competition for resources in other government agencies and in
private industry created an environment where the attrition rate was
higher than the accession rate.
Concurrent with the above efforts to attract employees to the software
function at the Center, a major Personnel Evaluation and Audit was con-
ducted by the Office of Personnel Management. Findings of the evaluation
team included many high grade positions recommended for down-grading.
As a result, Reduction-In-Force placements occurred, and many of the
supervisory/managerial positions in the software function suddenly had
new employees who were limited in the knowledge/abilities of the soft-
ware function.
It was in this climate that the need to design a program aimed at
attracting new employees into the field; provide up-date training to
current software employees; provide supervisory/managerial overview
orientations; and provide for some type of upward mobility opportunity
which would attract and retain employees over a longer period of time in
an effort to "grow our own* software employees became paramount.
This effort was separated into two phases:
Phase I - provide for a Task/Competency Needs Assessment.
This phase was completed during fiscal year 1978.
Phase II - Design Modular Training which would include all of
the elements addressed above. The objective of this phase was to design
and implement modular training which would include requisite
knowledges/skills to satisfy each element of the overall program. The
highest priority in the modular development was the providing of state-
of-the-art training to current employees. This was due to the high
attrition rate of employees having the requisite skills; the rotation of

445

ILA. %%.* .. 9.v* *m'V. %V ~ ..

 new supervisors into software functional areas; and the recruitment of
personnel having less than adequate knowledge/skills/abilities. This
combination presented a serious performance/p oduct problem for the
Center.
The Phase I product was the identification of knowledges, skills, or
abilities required of employees in each of the occupations assigned to
the tactical fighter weapons systems function. These knowledges,
skills, or abilities were then translated into the development and
presentation of 25 courses which offered up-date and state-of-the-art
training believed to have the most urgent need. Three-fourths of the
courses in this module have been presented to current employees at least
once, and feedback from supervisors indicate they see immediate results
in improved performance or motivation of their employees.
Appendix B addresses the complete modular training program; the Phase II
product.

PROFESSIONAL COUNCIL EFFORTS

The intiatives described in the preceding paragraphs represent short-term,

stop-gap measures and may in themselves solve some of the problems Of
the organizations involved.
However, a long-term commitment by the public sector mangagement to
develop personnel programs which ensure adequate numbers of software
personnel for complex system software acquisition and maintenance is
needed.

The effort by the Professional Council is considered the first step to

that end. In 1979, the Professional Council established a committee to
work with OPM in the development of appropriate classification and
qualification standards for engineering positions. The Pacific Missile
Test Center, Pt. Mugu (PMTC) member, K.I. Lichti, was designated action
officer for the project. His sub-committee consisted of the following
persons:

Technical Experts

G. HUNT Navy, Pacific Missile Test Center Sub-Committee Chairperson

S BERMAN Navy, Pacific Missile Test Center Sub-Committee Member
G. WROUT Navy, Pacific Missile Test Center Sub-Committee Member
D. NAURATH Navy, Pacific Missile Test Center Sub-Committee Member
J. BOK Wavy, Pacific Missile Test Center Sub-Committee Member
H. JOHNS Navy, Pacific Missile Test Center Sub-Committee Member
J. SALAZAR Air Force Vanderberg Sub-Committee Member
D. FARREL Navy, China Lake Sub-Committee Member
* J. HOWELL Air Force, Edwards Air Force Base Sub-Committee Member

446
 7 Y a'-'

Personnel Analysts
J. BENNISON Office of Personnel Management WR Analyst Team Chairperson
D. PIUSER Navy, Pacific Missile Test Center Analyst Team Member
V. VERNEUILLE Air Force, McClellan Air Force Base Analyst Team Member

The tentative schedule for 1980 was established as follows:

ACTION DATE LEAD ACTIVITY

Draft Questionnaire & Series 20 June OPM-Western Region

Description
Establish Action Plan 20 June PMTC/OPM-WR

Draft Cover Letter 3 July OPM-WR

Solicit Distribution Lists 3 July PMTC
from Council Sub-Committee
Distribution Lists due to PMTC 10 July Council Sub-Committee
Generate Composite Distribution 11 July PMTC
List
Finalize Questionnaire and 14 July PMTC
Series Description
Distribute Questionnaire 15 July PMTC

Establish Analysts Committee 18 July PMTC/OPM-WR

Questionnaire Response due to 1 August Distribution
PMTC
Complete Data Search 5 August PMTC
Complete Initial Data Analysis 8 August Analyst Committee

Review Analysis 19 August Council Sub-Committee

Develop Series Definition 8 September All
Package
Deliver Package to Council 15 September PMTC

Review 26 September Council

Deliver Package to Standards 30 September Council
Development Center, OPM,
Wash., D.C.

447
The sub-committee distributed a questionnaire to a cross-section of
Federal activites. The analyst team convened on ALgust 19-20, 1980,
and completed the initial review of responses. Of 285 questionnaires
mailed to 69 activities in 8 departments/agencies, 26% were returned by
the activities. The quality of the input ranged from cursory to very
thorough. The enclosures and additional materials furnished by
activities such as the Naval Surface Weapons Center, Dahlgren, Virginia,
and the Naval Weapons Center, China Lake, California were indicative of
the interest in this topic, and other studies which had already been
undertaken. The respondees indicated that approximately 1200 positions
would potentially fall within coverage of the Software Engineer Series
GS-8xxx as defined in the questionnaire. The number of positions
identified exclusively with a requirement for an engineering degree was
a significantly lesser number than 1200. The most significant
population, however, was in the Electronics Engineering Series GS-855.
Though some Jobs were included in the Computer Specialist Series GS-334,
the vast majority, estimated at over 95%, were classified to
professional series in the GS-800, GS-1300 or GS-1500 groups.
The overwhelming response reflected the viewpoint that the nature of the
work to be performed required entry level professional training
comparable to that attained in a four year degree program leading to a
BS in engineering or computer science or mathematics or closely related
disciplines. In addition to the discussion of Minimum Qualifications,
a discussion of the required knowledges, skills, and abilities for full
performance was provided. The majority viewpoint characterized the
occupation as grounded principally in engineering fundamentals and
computer knowledges, with related knowledges of mathematics and physical
sciences, and abilities in general management and communications.
The questionnaire which asked for distinguishing characteristics of
Software Engineering from other occupations was not addressed by a
significant number of respondees even though principal differences were
detailed. The team did not summarize inputs regarding the Computer
Specialist series since the trend on minimum qualifications clearly
characterized the work as "professional".

From the data presented it was the Council's opinion that the software
engineering occupation should be established as a fully professional
engineering series. A very significant number of 1239 positions
identified with the proposed series in the questionnaire responses are
currently classified in the Electronic Engineering Series GS-855.
This fact substantiates the conclusion that professional engineering
training is the over-riding qualification requirement.

The Council further concluded that with approval of the new series, the
Federal service will be competitive with industry and will significantly
benefit in its efforts to attract and retain a fully qualified staff to
meet the software requirements of the Federal government.

448
Appendix C contains excerpts from the report as sent to OPM, Washington,
D.C. on 30 September 1980.

STATUS AND PROGNOSIS

The current state of the individual short term efforts appear somewhat
encouraging while attainment of the long term objective looks dismal.
The reports on these individual efforts are:

Naval Surface Weapons Center (NSWC)

0 The plan for the acquisition and academic
training of Software Engineers for NSWC
has been approved and endorsed by their
Technical Director.

NSWC is currently implementing Steps 1 and 2

(Reference Appendix A).

Pacific Missile Test Center (PMTC)

* The PMTC Software Engineering Career Development

Program effort is currently progressing.
Software Management Awareness Core has been
proposed and consists of the following:
9 Executive overview of Software Life
Cycle Management.
e Software Project Management Requirements
and Planning.
- Software Task Management Responsibilities
for NAVAIR Projects.
9 The Software Technology Update Core is in process.

e The objective is to provide opportunity for

current software employees to Increase their
knowledge/skills/abilities in software
technology and bring productivity to opti-
mum level.
* The Software Retraining Core Graduate Certificate
Program was initiated 1 Sept. 1980.

449

w
 .Irk

* The use at this time of the term

"engineering" in association with
computer programing and systems
analysis would require engineering
societies and engineering granting
institutions support. Such support has
not been obtained. Will PMTC buttress
their report to overcome these concerns?

* Are private sector employers using

software engineering titles? More
detailed information is needed to
confirm this concern. What is PMTC's
plan for contacting private sector
employers to obtain this information?
* Will the establishment of a software
engineering series/occupation would
substantially reduce turnover among
such personnel? Will PMTC conduct
some kind of a pay survey and if so
what is PMTC's plan for conducting
such a pay survey?

Most recently, Mr. Jerry Reed, Executive Director of Acquisition for

Chief NAVMAT has expressed great interest in the software problem in
DOD. He is exploring what can be done at NAVMAT Headquarters to assist.
His past successes allow for a great degree of optimism.

Nevertheless, the Federal government is at the threshold of an ever

escalating software requirement. To continue to ignore the need for a
positive, pro-active pursuit of a viable solution'is irresponsible and
can result only in disaster in the long term.

1450

kSO
J .,,,.
. . .. -" .. . . ,,, ,. r ,,
, - ',,
?, . ... . . . '. ,-._,., ,. . ,.. .. ' eO C> . h -,

0 The objective is to provide a core series of

courses in software at the graduate level
which provides expertise in software and
qualify employees with a Bachelor's degree
to successfully complete/qualify for positions
in the software..function.
* The Undergraduate Software Training leading to an
Undergraduate Certificate Program has not yet been
approved.
* The Master of Science Program in Electrical
Engineering and Computer Science has been in
existence since 1975 and is designed for students
who need to update their background, experience
and operational ability in the computer area.

Department of the Navy

a Interpretive Memorandum was issued October 1981.

* There is no indication at this time that it
is in use for classification purposes.

Professional Council

The long term solution attempted by the Council has been stymied and no
new strategy has been developed. To date:

There has been several meetings with

Paul Katz, Director of the Standards
Development Center.
# These meetings have resulted in no new
actions to date.
* PMTC is investigating answers to the
following questions and concerns raised
by Mr. Katz:
* What can PMTC do to overcome the
evidence that indicates the continued
requirements for "professional"
qual ifications?

Gwendolyn Hunt
Director, Data Processing Service Center, Wpst
Pacific Missile Test Center
Point Mugu, California 93042

BA Tennessee A&I 1956

MS Univarsity of S~uthern California 1976
Graduate, Industrial College of the Armed Forces 1979

Exoerience:

26 years of software elgineering involvement including:

Pacific Missile Range - Range Software Development
Pacific Missile Test Center - Head, Tactical Software Design
Pacific Missile Test Center - Assc" Director, Systems Technology Dept.

Current Assignment:

Director, Data Processing Service Center West

Responsible for all Automatic Data Processing support for MAVMAT Activities
locatPd within the pro%imity of the Pacific Test Contir.
Tisll

451
STANDARDIZATION ISSUES OF THE FUTURE

SESSON CHAIRMAN: Darlow G. Botha

AFWAL/AAAl

MODERATOR Frank A. Scarpino

AFWAL/AAA
 THE APPLICATION OF STANDARD SYSTEM SPECIFICATION TECHNIQUES

TO THE DESIGN OF VERY LARGE SCALE INTEGRATED CIRCUITS

D. Jordan

Airborne Software Division

Marconi Avionics Limited
Elstree Way
Borehamwood
Hertfordshire
01-953 2030

Dave Jordan obtained his honours degree in Mathematics from the

University of London in 1974. After some years in the telecommunications
industry he joined the Airborne Software Division of Marconi Avionics
Limited where he is now the senior member of a team which has developed
the MENTOR system specification system.

The design of large-scale integrated circuits has traditionally

been the province of silicon real-estate artists. Standardisation
has meant keeping the same artist for each design iteration. The
infeasibility of this approach for circuits with gate counts between
10,000 and 100,000 is apparent.

The use of modelling programs, using hardware description languages

such as ELLA (I1,leads to the use of standard circuit modules with
their descriptions held in a model library. At Marconi Avionics this
approach has been extended through integration with MENTORf2) a-system
specification system.

The MENTOR approach is based on a standard specification language

which can be applied at all levels of design and which allows the chip
designer to both differentiate and correlate the behavioural and
functional descriptions of circuits and modules. Advanced language
analysis techniques enable detailed design verification and the
construction of a perfectly consistent design database.

-pREFVIOUS pAGE
/ IS BLANK

455
INTRODUCTION

The design of large-scale integrated circuits has traditionally

been the province of silicon real-estate artists. Standardisation has
meant keeping the same artist for each design iteration. The infeasibility
of this approach for circuits with gate counts between 10,000 and 100,000
is apparent.

The effective design of such large scale circuits can only be achieved
through an increased emphasis on standardised methods of modularisation and
specification. To some extent this trend is already visible. Hardware
description languages such as ELLA have bden-. developed enabling the
detailed specification of standard circuit modules. modelling programs
can then be generated which represent the specifications of designs using
those standard modules, and which enable some verification and testing of
designs.

At Marconi Avionics we have been separately examining the use of

system specification languages for the verification and validation of
designs in a more abstract way. This work has led to the development
of MENTOR, a sophisticated new specification system incorporating Powerkul
automatic techniques of specification analysis. With some extensions we
believe that MENTOR will prove a valuable addition to the arsenal of
sPecification methods for very large scale integrated circuits, which is
fully complementary to the hardware description language approach.

The MENTOR approach is based on a standard specification language

which can be applied at all levels of design and which will allow the
chip designer to both differentiate and correlate the behavioural and
functional descriptions of circuits and modules. Ad vanced language analysis
techniques enia-'le de,;ailed design verification and the construction of a
perfectly consistent database.

SPECIFICATION:A DOUBLE EDGED SWORD

It is usual to regard specif icatibn as.a simple interfacing activity. On the one
hand the specification informs potential users of a device of the designers
intentions in respect of the behaviour which the device will display. on
the other hand the specification informs the implementor of the functions
which the device must implement.

The specification is indeed subject to two forms of checking. The

potential user must satisfy himself that he can operate the proposed device
in such a way as to satisfy his goals and needs. The implementor must be
able to demonstrate that his implementation in fact achieves the specified
functionality of the device. These two activities comprise respectively
the validation and verification of designs.

The central problem which must be addressed by any specification

method is that of achieving a balance between the requirements of verification
and validation. It is important to recognise in this context that a
specification is not a pure and simple document which is either the
only correct specification or not the correct specification at all.
Specifications incorpoiate decisions: decisions which determine the
"operability" of the proposed device, and decisions which determine the
functional structure of the device.

456
 '
, ', -' ' - . ., - . - -. - .. -o- -- . '

An important role of the specification is to make explicit all of the

decisions which have been made. The validation activity must be able to
distinguish the impact of functional structure on the operability of the
device, and the implementation /verification activity must be able to
distinguish the impact of operability constraints on the interpretaion
of functional structure.

We believe that this can be achieved by means of a strongly structured

specification approach, and that functional abstraction at high levels is
of paramount importance.

THE ROLE OF HARDWARE DESCRIPTION LANGUAGES IN SPECIFICATION

Hardware description languages are designed to enable the behaviour

of a device to be specified in terms of its functional structure. The
device is represented in terms of the procedural, or algorithmic
interactions between its functional components without any regard to the
way that those procedures are to be realised in terms of the interconnection
of physical circuit modules.

Individual functional components may in turn be specified in terms

of yet more elementary components and their procedural interactions, or
they may be elementary building blocks whose behaviour is specified in
terms of their register transfer functions.

This structure serves the purposes of the implementation/verification

activity rather well. A device may be specified to any level of detail
without predjudicing the physical design of functional componentsor of their
interconnection net. Subsequenit designs can be modelled similarly in terms of
circuit components whose specifications are maintained on a central
library, and the descriptions can be exercised by simulation software
and tested to verify that the required functional behaviour can be achieved.

It is my view, however, that despite their hierarchical nature,

hardware description language specifications fall short of satisfying
the requirements for validation of device operability. To be sure,
simulations can be constructed to any required degree of complexity, so
that the operability of a complete device can be tested in simulation.
However, for a device of any appreciable size it will never be possible
to exercise more than a small proportion of 'fts.potential states in this
way.

Furthermore, the exercising of a hardware description language

specification is dependent upon the behaviour of functional components,
at some level, being specified in detail in terms of register transfer
functions. Consequently,by its very nature, the simulation of a device
from a hardware description language specification produces a great deal
of detailed information which, although valuable, is to some extent
peripheral to the issue of operability.

The essence of the specification approach being proposed here is that

functional abstraction should be employed at high levels of specification
in order to clearly exhibit the relationship between device behaviour and
operability. The introduction of functional detail should be carried out
in a structured manner, parallel with, and in support of the hierarchical
elaboration of behaviour. This in turn should be a guide to the synthesis
of designs in terms of interacting functional components.

457
 a At A -7 , *7777Z
_. '- -.. .. 771W.W.

Nevertheless it is to be anticipated that ultimately the specification

will contain sufficient functional detail to be capable of expression by
means of a hardware description language. In view of the advantageL noted
above in the use of this style of specification for implementation and
verification activities it would seem to be essential to provide some
means whereby the hardware description language can be generated. It
would however appear that by orienting the specification process towards
the creation of a design at the level of a predefined library of functional
components the procedures of the harCware description language could be
automatically and painlessly generated.

THE ROLE OF ABSTRACTION IN SPECIFICATIONS

The MENTOR approach is based upon the fundamental idea that any device
has significance only when it is embedded as a component in some wider
system, and conversely that any component in any system can be regarded
as a device in its own right.

In viev' of this we can say two things; firstly, that the significance
of any device can only be expressed in terms of the way in which it interacts
with other components of the system in which it is embedded. And
secondly, that the process of design concerns itself with the replacement
of one device by a number of other more elementary devices interacting in
such a way that each has a significance in the achievement of the objectives
of the parent.

The important point here, I believe, is that we do not need to know,

in detail, what any component does in order to assess the operability of
a given design. Tt is sufficient to know, in the abstract, the
significance of what the component does so that we can determine whether
it is being operated in an appropriate way to achieve the objectives of
the design in which it participates.

Abstraction, therefore, is a crucial factor in the understanding of

any design. If this were not so, surely, we could never design by the
divide and conquer method. The point which I am trying to address, however,
is this:-
When wp set out to create a design for some device, all that we can
ever know is:-

i) the way the device is going to be operated.

ii) the environment in which it will operate.

And
iii) the significance,in the abstract, of the operations which it will
perform.

Certainly, once a certain level of detail has been achieved this is

equivalent to knowing, if you like, the register transfer functions which
must be implemented. However, above this threshold, specification and
validation of designs can and should be carried out in the abstract.

V What does this mean in practical terms? The main point, I suggest,
is that a design comprises three distinct kinds of information (see
Figure I). Firstly there is information about the (abstract) significance.
of each component in the design. This can be expressed in terms of the
abstract behaviour displayed by each component, and amounts to a specification

458
 of the component which can be used either as input to a further stage of
design, or to select a standard component to fill the specified role.

Secondly there is information concerning the way that components

operate together. And,thirdly, there is information about the relationship
of the limited environments of individual components to one another and
to the environment in which the parent device operates.

In the MENTOR system these distinctions are explicitly supported by

means of distinct specification primitives so that:-

i) The abstract behaviour of a device can be expressed in terms of

the type of functional relationships which are established zetween
registers in given operational circumstances. Details of these
functional relationships cannot be explicitly given except in terms
of the functional structure of the device. ifowever their significance
can be made explicit by the use of appropriate names to identify
register contents.

ii) The operational interactions between devices can be expressed

in terms of the circumstances and manner in which they are activated,
and

iii) The structural relationships between device environments can

be expressed in terms of the significance of each register assembly
of the parent device, which is, of course, expressed by -,n appropriate
name identifying the register assembly in the parent device behaviour
specification.

MENTOR therefore enables the designer to specify his device in a way

which both differentiates and correlates its behaviour and functional
realisation. This is particularly valuable for validation purposes since
it enables the potential user to confirm that all significant aspects
of device operation have been identified. Provided that each component
is designed in a manner which fully reflects it operational significance
then the interactions of the components will achieve precisely the
desired effect in the environment of the parent device.

AUTOMATIC VERIFICATION IN THE ABSTRACT

A major issue in the use of an abstract specification style, and one

of the reasons why a more concrete form of specification is desirable
for detailed design work is the possibility that:-

i) different users may interpret the same abstraction in different

ways, or conversely:

ii) two distinct users may use different abstractions for the
same fundamental concept.

An important way of avoiding these problem§ is to make the

specification process as visible as possible and encourage communication
*0 between users of the specification. In order to achieve this
MENTOR maintains the database of specification informatiol and provides
a report generator which will provide, on demand, up-to-date diagrams,
summaries, and analysis of the specification. This facility is, however,
no guarantee that conflicts of interpretation will not from time to time
arise.

459
 There is however a certain amount of verification which can be
performed in the abstract, since it is possible to see whether the
operational interactions of a set of components achieve any effects
which can be interpreted as the behaviour specified for the parent
device. MENTOR incorporates a consistency checking mechanism, based
on a detailed logical representation of its specification primitives.
This interprets as inconsistent any situation in which the abstract
function of a device is not realised by the interactions of the abstract
functions of its components.

Thus MENTOR will generate diagnostic reports whenever it becomes

apparent that the abstractions used by different users do not correspond.
This mechanism will, of course, trap both:

i) situations where a design is simply wrong and will not work, and.

ii) situations where detailed design onsiderations have identified

significant features of the behaviour of a device which were not
anticipated and reflected in the specification of the functional
structure of the device.

MENTOR therefore has an important role in ensuring that the abstract

design specifications produced in the concept elaboration phase of a
hardware design project are complete and consistent in advance of any
detailed design work based on hardware description language style
specifications. This contrasts with a situation in which the same
information would be kept on paper in natural language and would be
subject to misinterpretation at the detailed design stage when its
significance must be clearly understood.

INTEGRATING MENTOR WITH A HARDWARE DESCRIPTION LANGUAGE

The application of a MENTOR-like specification tool in order to

support the achievement and validation of device operability offers
significant advantages in the design of complex, special purpose,device
architectures. However, the detailed logic design activity will, we
anticipate, continue to be based on hardware description languages such
as ELLA..,-X . Therefore, reliable mechanisms will be required for the
transfer of specification and design information from MENTOR to the
hardware description language format.

Ideally a fully automatic transcription process is required, and

the general purpose report generator facility of MENTOR provides an
appropriate vehicle for the automatic construction of the hardware
description language specification as a special purpose MENTOR report.
This strategy, however, imposes some constraints on the specification
process, which in turn have implications for the MENTOR system itself.

We have assumed that the devices to be specified will consist

largely of standard generic functional elements. This will, we believe,
be necessary in order that designers will be able to cope with the
complexity of these devices and, more basically,because the circuit
provin4 task will, otherwise, be infeasible. Detailed hardware
description language style specifications will, therefore, be obtained
by instantiating corresponding generic specifications maintained on a
central library.

460
 T4.

A consequence of this assumption is that the abstract specification

activity supported by MENTOR must be specifically oriented towards the
generation of a design in terms of the library generic elements.
Therefore, MENTOR must provide- structuring primitives which facilitate
the specification of library elements by specialist hardware designers.

One mechanism which can be employed for this purpose is the general
purpose property attribution mechanism. This mechanism enables each
functional element to be described by a set of arbitrary attribute values
identifying specific properties of the functional element. For example
a given functional element could have the "generic type" property assigned
the value "integer adder" and the "data precision" property assigned the
value "8" to identify it as an 8 - bit integer adder. An alternative
approach which shows some promise for the longer term, but which is
currently still under investigation would be to extend the range of
structuring primitives in MENTOR to correspond precisely to the library
generic elements.

In addition to this, provision must be made to handle those parts

of a required device which cannot conveniently be specified in terms of
standard predefined elements, Clearly, for these elements the hardware
description language specification must be proouc~d manually. For the
sake of completeness, however, these manually produced specifications
should be represented on the MENTOR system. MEN'I'OR will provide special
.4 primitives for this purpose.

CONCLUSION
As the potential complexity of integrated circuit devices increases,
and as the demand for purpose built integrated circuits is stimulated the
issue of operability of devices will be seen to be at least as significant
as the current concern with ensuring functional correctness.

Future special purpose VLSI devices implementing complex functions

will require many more control options than previous generations of easy
to operate general purpose devices implementing relatively simple
functions. For this reason it will be necessary to adopt specification
standards equivalent in power to those already in use in the fields of
systems and software design, and emphasising the issue of device operability

While very valuable for the achievement and verification of

functional correctness, current standardised hardware description
languages, such as WHDL (3) in the USA and ELLA in the U.K., appear to
have severe limitations as regards the achievement and validation of
operability. This is because hardware description language style
specifications.are intrinsically functionally detailed, whereas the
issue of operability is best addressed in terms of functional
abstractions.

Current work on more general abstract forms of specifications,

including Marconi Avionics MENTOR system offer the prospect of standardised
design specifications which are both verifiable and amenable to behavioural
validation. The special requirements of the integrated circuit design
process, however, demand that the specification be readily transformable
to the hardware description language form.

4,61
 For design tasks which require a preponderance of standard
generic circuit elements which can be predefined in a library this
apparently presents no major problems and MENTOR-like systems can
readily be accommodated to the automatic generation of equivalent
hardware description language. It therefore seems likely that
MENTOR-like systems will prove a valuable addition to the arsenal
of standard hardware specification techniques.

REFERENCES

1) "ELLA: A hardware description language" J. D. Morison, N.E.Peeling

and T.L. Thorpe.
Proc. IEEE. Int. Conf. on Circuits and Computers. Sept 23-Oct 1 1982 NY
PP604-607

2) "The MENTOR approach to requirements specification" D. Jordan and

B. Hauxwell. AGARD Symposium on Software for Avionics. Sep 8-10 1982
The Hague

3) "Report of IDA Summer Study on Hardware Description Language"

G. W. Preston.
IDA Science and Technology Division, Paper P-1595, DTIC ref AD-A-
110866.

462

* ~ . ,~Q. -
 DEVICE
OBJECTIVES

1ENVIRONMENT BEHAVIOUR

Interpretation Operation

FUNCTIONA FMMWCTIONAL FUNCTIONAL

COMPONENT COMPONENT COMPONENT
12 3

EN. EN EV. BEH. ENV BEN.

FIGURE 1. THE STRUCTURE OF ABSTRACT DESIGNS

4.63
ADVANCED STANDARDIZED SYSTEMS/SUBSYSTEM

SESSION CHARMAAI* Major L Caro,

AFWALIAAAF

MODERATOR: Colone Darrold D. Garriso

AVRADA/DAVAA-D
 COMPUTER STANDARDIZATION IN THE SUBMARINE ADVANCED COMBAT SYSTEM (SUBACS)

by Ronald L. Ticker

Naval Sea Systems Command

Biography

Mr. Ronald L. Ticker

Systems Engineer
Submarine Combat Systems Project (PMS 409)
Naval Sea Systems Command
Washington, D.C. 20362

BS University of Maryland - 1979

Graduate Studies - George Washington University
Member - IEEE and IEEE Computer Society

Abstract

The Submarine Advanced Combat System is a modular, distributed combat system

for SSN 688 class attack submarines, currently in concept development.
SUBACS will be among the first weapon systems to employ the AN/UYK-44(V)
computer and the AN/UYS-2 Enhanced Modular Signal Processor (EMSP). The
SUBACS architecture utilizes commonality and distributed processing to provide
flexibility in reconfiguration and growth. To achieve this, standardization
is exhibited at many levels within the system. This talk will focus on the
development and evolutionary plans of the SUBACS and the utilization of
standard computing devices in those plans.

467

pAltvoUS PAGE
IS SLAN4K

16~
 I. INTRODUCTION

The Submarine Advanced Combat System (SUBACS) will be installed on new

construction SSN 688 class nuclear attack submarines with delivery in 1988.
The SUBACS consists of several subsystems and associated programs which will
be integrated into a total ship combat system. It will replace existing
NN sensor and fire control equipments providing significant performance
improvement in acoustic detection, data base management, system reliability
and flexibility plus reductions in manning, space and weight requirements
crucial in the submarine environment.

The SUBACS Basic, illustrated in Figure 1, will be comprised of some new

equipments integrated with retained portions of existing systems. This
W approach will permit advanced but mature capabilities to be introduced in a
manner responsive to fleet needs while minimizing development costs. The
SUBACS A, is shown in Figure 2. It will build on the Basic SUBACS and provide
new capabilities, particularly in the area of fire control. Much of the
equipment retained from older systems will be replaced by newly developed,
more capable equipments. The SUBACS B, depicted in Figure 3, will provide
additional improvements.

* A summary of the SUBACS evolutionary, or pre-planned product improvement

* program is provided in Figure 4. Each stage of SUBACS development planned at
three year intervals, is under-taken with the evolution to the next, and later
stages being considered. The progression from stage to stage is faciliated by
two important features of the SUBACS. The first feature is the commonality
which the SUBACS provides both within and across systems. The second is the
distributed, bussed architecture.

The SUBACS will be one of the largest combat system development

activities the Navy has ever undertaken. By the time SUBACS B first goes to
sea, over 2 billion source lines of new code will have been written. It will
integrate more than 24 AN/UYK-44(V) computers and over 150 Motorola 68000
microprocessors.

II. COMMONALITY IN SUBACS

The SUBACS will be a modular system with a high degree of fault toler-
ance, flexibility, and capacity for technology inserti3n. Full system
availability will be improved through the use of "Hot Spares." Failures
occurring in existing systems result in loss of capability, the severity of
which depends upon the nature of the malfunction. Each hardware element of
the SUBACS will have at least one identical element capable of maintaining
full system performance.

The modularity is largely due to the packaging of SUBACS elements at the

drawer rather than the cabinet level. The SUBACS common enclosure, shown in
Figure 5, consists of nine common drawers arranged in a three-by-three matrix.
Each has its own power supplies and identical form and fit. Processors, such
as the AN/UYK-44(V), are embedded four to a drawer in SUBACS Basic and eight
to a drawer in SUBACS A. This allows replacement by drawer rather than
cabinet permitting simpler, cheaper system upgrades.

468
 I-C

idi

mg
CPit

Is469
'II

y)c

IHI

EXi
lel

470

kx iq 0 NO
 HIM
9-n

AA

ccd

C.)-

11-

471
 z U Q

am
I- 2
oL s 0

ccU& 00 0 0 0ee000

CL CL
OOOWA%

iCi 00 00 00to00

0.. o -

(IIS

Isa

472
 C-
03

owl LIM

C.34

ccz
D-

CL

'U

473
 The moduldr cabinet concept provides a building block for oLher SUBACS
units. The SUBACS Combat System Display Consoles consist of three common
drawers in the lower third of the cabinet with the display surfaces and
controls located in the upper two-thirds. The data processing and storage
cabinets will house two Random Access Storage Systems (RASS) disks each in
one-third of the cabinet with three drawers again occupying the lower third.

Since each AN/UYK-44(V) is identically configured, the use of a

particular processor to support a given function is transparent to the
operator. The loss of an AN/UYK-44(V) will not degrade the system since its
function may be performed by another AN/UYK-44(V). The spare AN/UYK-44(V)
need not be located in the same drawer or cabinet as the failed processor, but
may be found elsewhere in the system.

The SUBACS system commonality is further enhanced through the widespread

use of the Navy's Standard Electronic Modules (SEM). The new, large SEM
format to be used in SUBACS will be compatible with VHSIC/VLSI technology
insertion. The new format will provide for functional partitioning by card
and the additional input/output capability required by new technology.

III. DISTRIBUTED ARCHITECTURE AND THE BUS

Existing, non-distributed combat systems are generally controlled by a

single, central computer. For example, the AN/BQQ-5(V) sonar and fire control
system Nk 117 both use AN/UYK-7 computers as central controllers. The
occurrence of a computer failure forces a system reconfiguration or
degradation. Maintaining system critical functions are subject to available
computer resource limitations and a predetermined set of priorities.
Probability of mission success is therefore very much dependent upon the
reliability of single pieces of equipment.

A distributed architecture, like that of the SUBACS, replaces the cen-

tral computer complex with a network of independent processors. Reliability
and operability are improved by the presence of unused "hot spare" processors.
Processing capacity is increased by the parallel processing capability of
several computers operating simultaneously.

Communication between SUBACS processors and other elements is

accomplished via a hierarchy of busses. The array bus connects beamformers,
signal processors, mass data storage and system control units. A high bus
bandwith of 32 megabytes per second is required including 100% reserve
capacity, due to the high data rate associated with sensor data, Fiber optic
technology is used to provide the increased throughput and also eliminate
electromagnetic interference and reduce requirements for large, bulky cables.
A fiberoptic system bus, having a 8 megabyte per second bandwidth, will
transfer control and display information beginning with SUBACS A.

474
 Most SUBACS units have internal cabinet busses. The cabinet busses
extend the array and system buses to the drawer level. This effectively
allowed subcabinet elements to communicate in the way cabinets do in more
traditional system architectures. The independent communications permitted
the subunits provide reliability and reconfigurability improvements. Product
improvement is facilitated by placing the interface at a lower level than in
traditional architecture thus reducing the extent of the required
modifications.
redesign of the Aunit.
subelement could be added in a spare slot without a major

Each AN/UYK-44(V) processor, EMSP, disk, as well as many other SUBACS

sub-elements, are connected via a bus interface unit to the bus network. The
bus interface is controlled by a Motorola 68000 microprocessor which performs
message scheduling and status accounting. It has its own associated memory
which is used for message queuing and routing.

The busses are interfaced through bridges. These are similar to the bus
interface devices. The bridges are also controlled by a Motorola 68000
microprocessor. The bridge provides a mechanism for interfacing busses of
different speeds and technologies. It also makes the location of distant
processes appear as if they were local by acting as a relay point.

Each bus is paired with a redundant bus for reliability. Either bus can
provide sufficient bandwidth on its own to completely service its users. All
bus interface units and bridges are connected to both (redundant) busses.

The bus hierarchy provides a structure upon which the system may expand
to meet future needs. Additional cabinet buses or subsystem busses may be
added by bridging onto an existing bus. The number of bus ports usually
limited by addressability, bandwidth considerations and driving distances,
could therefore be increased according to system requirements.

IV. SUMMARY

The SUBACS, using standardization and state-of-the-art technology, will

be the Navy's submarine combat system far into the twenty-first century. Not
only will it be adaptable to meet changing threats and reliable in countering
those already present, the SUBACS equipped attack submarine will pose a
significant threat of its own. Vertical Launch Tomahawk cruise missiles with
over-the-horizon targeting could provide both conventional and strategic
capabilities. Advanced Capability Hk 48 torpedoes and the Anti-Submarine
Warfare Standoff Weapon will enhance the submarine anti-surface and
anti-submarine warfare roles. Improved target detection and localization
techniques and equipment will reduce the time required for weapon targeting.
Improved data management would simplify operations in heavy contact areas. In
general, the submarine equipped with the SUBACS will be a force to be reckoned
. 4with.

475
 b,*.. r.N . V,. ;. ... . -. ..
- -. :* ,
... .,, * *I .

Defence Materiel Administration

Airborne Electronic Division
115 88 STOCKHOLM, Sweden

Computer standardization in Swedish Air Force

(Mr G Elg, chief engineer, Airborne Electronic Division)

The Swedish Defence Materiel Administration, has been engaged

in a standardization effort for airborne computors since 1975.
The effort has resulted in the SDS80 Standard Computer System,
which is now under full scale development for the JAS Aircraft
program.

The SE380 includes a high order language, based on Pascal, a

programming environment PUS80 and a modular computer D80. All
three components are well matched to each other to be an effi-
cient solution to the computing requirements in the Swedish
aircrafts and related systems. Details on the system will be
presented seperately.

This presentation convers the specific background for the Swe-

dish program and the approach we have taken to develop the
standard. It also explains how we have got it accepted by the
Swedish industry as a basis for a fix price aircraft develop-
ment and production contract.

477
[pREVIOUS PAGE
t NAK
S

~~~~...... , ' * 'N "', .......

i : ...
SDS8O STANDARD COMPUTER SYSTS'

BACXGROUND

APPROAC To STANDARD IZATION

SYSTEM4 DESCRIPTIiON

STA~TUS 'NDFUUR

DIscuss-foN

478J
 40

_ 2l
Cc 0
- cc -
Cg In

0s as

00

cc E cm 002
_ - ~Cf *
fA
_
moo Op

-O r

A 0w I, < '

479
Sfl58'O. A COtICEPT FOR STANDARDIZED HIGH-ORDER
LAN~GUAGE COM1PUTER SYSTEMS

1. BACKGROUND

2. SDS80
1!10RD'E' LVIJAGE
7ROGRA1 'DEVELOM~EIIT SYSTEM
Coai'UTER 41ODULES

3. APPLICATIONS OF SDS80

4. -EXTENSION TO ADA

5. SDS80 PRESENTATIONS TO US GOW'T

480

I. %
 rr-n -q-. ..-. -..-

EDRT TV~ii.
~ EECIOMC

PROC co~uli
RPOC\Wj

coa E IIn......

RFC POC
-Y
HC I____ EC-
-,0 C

481~RU 5 TOC01LERS~EdTc

4
 INVOLVE AN COMIT

RESISTANCE TO STANDARDIZATION:
----------------

LIMITS FREEDOM OF CPANIES AND INDIVI-

DUALS

STYMI!ES TECHNOLOGICAL ADVANCES

REQUIRES !;IORDINATE AMOUNT OF o30RDI""A'7:N

ALL EGGS IN ONE BAS4(ET

ETC

OUR SOLUTION:

INVOLVE .'OTEATIAL JSERS HEAVIL': il ZPEC.FIC.1-

T 1CI F "E0UIE'1EITC

LET THE BEST EXPERTISE, REGARDLESS OF AFFILIATION,

COOPERATE IN CONCEPT FORMULATION
..VC-.: .A,.. JSE2 :CUIiE:JT :-TRACTCRS IN

DESIGN AND DEVELOPMENT OF THE STANDARD EQUIPMENT

GIVE FREE ACCESS TO TECHNICAL INFORMATION

DESIGN TO ACCOMODATE TECHNOLOGICAL PROGRESS

482
 SIDE EFFECTS ThROUGH STANDARDIZATION

STANDARDIZING ON A MODULAR LEVEL AUTOMATICALLY

GIVES STANDARDS ON COMPONEIT LEVEL.

,,ADRD,-IIG .'A 'OI,11T "ELOPI" ETlT PRO!ECT

3i''E THE ?OSSIBILZT' TO USE ._.Dr-" -CR
DEVELOPMENT, BOTH QUALITATIVE AND *UA;TlTA-
TilVE, INA MORE EFFICIENT WAY.

- STANDARDIZING GIVES THE POSSIBILITY TO USE

MOST COMPETENT PEOPLE FOR DESIGN AND DEVELOPMENT
INDEPENDENT OF WHICH FIRM THEY BELONG TO.

3- NIIG JIVES IiDUSTY THE POSSIBILITY

- ^S
COPERATE, LE.RN FROM AND SPUR EACH OTHER.

STANDARDIZING GIVES A LARGER BASE FOR SUPPORTING

-RELIABILITY AND QUALITY ACTIVITIES.

'::DRD IZ:G ::"PL:Fl- ~ fOJC G~:

TASK OF THE CUSTOaIER. AID REDUCES THE 'GRKLOAD
FOR MAINTENANCE- AND TEST-DEVELOPMENT.

483

M .-
RD-R145 697 PROCEEDINGS PAPERS OF THE AFSC (AIR FORCUSY5TEN1
COMMAND) AVIONICS STAND..(U) AERONAUTICAL SYSTEMS DIV
WRIGHT-PATTERSON AFS OH DIRECTORATE 0..
UNCLASSIFIED C A PORUBCANSKV NOV 82 F/G 1/3 NL

EE!EEEEEEEEEEE
E
EI
 I1111 9= _u~IL
u..i~
U...-
*flu~
is. .215
-
Has
II',' 1*1 3.
II~~ - -

.INI-
11111126 lii 14 * 1*6
~ ~

1mfl1= UIE= NU~

.~p ~ is~ ~ N.

A j 5. -' . 'P~%j.* ~S *;..~;, Al.;A

 COPIJTR ARCH ITIETS

CONCEPT LAYOUir
6UNNAR CARLsTEDT, HyLAB

DEsIGN REAIZATIO
3T1~LN VENERFEL7I SRA

* B Lz11 ORGANIZATION

DAoRKNSORtum 8D

* UI Enimsom (PROJECT iA1AGE11EUT)

DATASAA31

,M, COWINICATIOUS

'SY~EI~S nfo:;RAI'V~!G Lm,: HLL &COMPILER)

484
 1
1
I

U
B -
*
- - e - -
4
I

iii
r-
S a
S I I
I-

I
I

r '.0 -'~

~ I ~j

I'

I
I

4 - - -- - - - - -

II
'if
I
485 r ~ U ~ ~*%**~q%~. *q~~%* U* ~% %~% - -

.p ,*.
 . io.0 -

A~rM=I STMI 191tIMI

.4tum 600 oME.' 39=3i

STANDARIZED CARD DESI=

POME SWPIES

2 stus: 200 30V

'.86
 5?ADA~COMUTE8 STVS~m sm s0

£96 161 1962 1903

Notbodes upport

uupport tools fogt-

,Q~p I

I ~,%:-,r2nea mat

Pr. Pwtotypo

tPrototypos"j

71y~inq 2d*
(?-Delivery
-... . . . . .

1%6

ii

IWO

III

!,- . . , , I_. I1±-'

-I a '.1

'
" - • " ' '' ' ' "' '- :€.-"Cr . 4 - ._ 4r-'. ,-- ..
*EFFICIENT PUO06M DEECiilSYSTOI
cmnM
-OPJE NPUTusi

UG4

- t ' .,
 II

A
II
393 -m
IJ
16i

mu i"I
 %00

3r~TornI Terminal T 'winal

un Twminal

DEC. E

Conro

?We

-A
SOS Sto mntmrol ConyuW -OP
O.Ormug to 8 O optr simultafiwousMly
4
R*~r .4.1i

- ~n be operatee. !ram hwks compute r teminals

Mior PUS8O Software Tools*

-PASCALIDOO compiber end Ilidies forho

Sblc
-~~ dsbupm ars for hOWad r

-Prett print M.
-oI,-am

- 7~x mnga~tad~er(Scce odeControl System)

wv -
IM-dhu
mp tuowt

-IL -
-lo
cit *i-

#9n

-aa OL

lotRu

*Ma

JV1-
 0. . . . . .. .. . . . . . . . . - - - -- .-

SOS 8O0tan-nzs Cownyiutig S "ago

- Commnon v I@g memry (CM)

- !ntermcdule bus

Seven pmIde rcse per Proceliwn.

Fims
MEMO** *
 S.8 - . b --

:1S S OO tdudiz Computing Systen

CHARACTERISTICS OF THE 080 PROCESSOR

HOLM with support for parallel processes/multi processors

qOLM (High Order Language Machine)
• tacA :nachine
S'Aachine instructions reflecting HOL (High Level Lang-
uage) structure (block structure, addressing)

Parllel proem support

0 Ilwdwe suppbrt for parallel processes
- Machine inwuugions for synchronization and communi-
=tion ethveen processes n the some or .nother proc.-

FM axwnion
- Architecture supports HO L primitives
* Separte address calculation
Separatedm .xogram and data buses
jc .izt: r.fmnr,, ror Zr's It Jcc3Is
",;. r,:.mc ;na
ogic init.vith hardware supported

Ra-4ta wea ien of 1t in a rl time ivronment

'4ith a tow opeainy zw overhdK

# Iq
....... * * * ,~ ~ la1
-. 4-. * -
 cc *-

&o
oo
= a.
C

0 CL E
- r

Al i
-
QIUE.E.

3 U0
as

Co.ho

a.MW

iiL

us)c

cc

-cr
~* % *
 'Wm

CCDP
=1 cc
-

.5 at
.AM_ _ _ _ _ _

tam1

-c

E __

C -i

T. .
* _Opp

P49
afor
 C,,'

.Eas

COO

498t
-'cm,- ~
 44 x (4o

C~Cj

44

b499
 JAS Arrf
Standardized Computing System
TEST (Aircraft and Workshop Level)
3 (15538B)

Bus I

C.1.

Dislay Computer1

Display Computer 2
"Nut-..

General Signal
Computer

500
 I ! . t t .. . . . . . . .

Navy Real Time Signal Processor Development: Second

Generation Planned Service Standard

C. S. Robbins
Deputy Project Manager, Navy Shipboard Tactical Embedded
Computer Resources Project (PNS-408), Naval Sea
Systems Comand, Washington, D. C. 20362
Abstract

Planned growth in the coming decade of Navy combat systems will

generate signal processing performance requirements that far exceed
the capability of the current Navy standard signal processor. There
is a further need to improve the programming environment of Navy
standard signal processors to increase programer productivity. The
Navy has initiated development of a second generation standard
signal processor, the Enhanced Nodular Signal Processor (IMSP),
nomemclatured as the AM/UYS-2. This paper describes the Navy
program to develop the ISP as a multi-processor signal processing
system. The approach to specifying system performance and
programing environment along with the acquisition approach that
resulted in vigorous competition for the engineering development
contaract recently awarded is discussed. The commodity management
concept for OISP's in-service lifetime involves interface management
within the system and controlled technology infusion. This
important plan to stay abreast of technology while meeting user
community requirements for product stability is described.

Introduction
The Navy is committed to the use of standard computers and
programmable signal processors in sea going and airborne weapons
systems and sensor information processing systems. Extensive use of
these Tactical Embedded Computer Resources (TNCR), standard
computers and processors embedded in larger systems, is the basis
for one of the major strenghts our Navy enjoys. Aggressive
acquisition policies are being pursued to add new members to this
standard family. The AN/UYK-43 and AN/UYK-44 are being developed as
planned standard mainframe, mini-computer, and micro-processor. The
AN/hYK-14 is being developed as standard airborne mini-computer.
The AN/UYS-l, the first standard programmable signal processor for
shipboard and airborne applications is in production.

Even as the first standard programable signal processor begins

service life, a clear need to begin development of the second
4 generation standard programmable signal processor is seen. Current
processing capacity is limiting the effective aperatures of our
sensors to less than that which the spectral, temporal and spatial
coherence of progation media supports. Implementation of
newalgorithms expected to mature this decade that process
information from larger aperatures to cope with reduced target
information must not be limited by programmable signal processor
throughput or the economic limitations of non-programmable or
difficult to program processors. Fleet introduction of these new

501

* *" .""* * U- *. . . . .s t-"*1 " : ': -

information processes is essential to maintaining the qaJa:. ,t 3
advantage of out forces. Development of a next qeneration
Trogramable signal processor to support sensor and slqot ithn
pfrovements is being undertaken now as the AN/UYS-7, ttw rnhance4
Modular Signal Processor (UwSP).
Requirements to meet the coming decade's processing needs and
improve in-service support of standard signal processors have been
establsihed for the NIP. First, the ICSP must be a complete
product line, five different sited versions will be available with
five corresponding performance levels, sites, power requirements,
and weight. At the high end, at least an order of magnitude
throughput improvement is necessary, 0 illion real multiples and
adds per second steady state performed in the context of the complex
arithmetic in typical signal processing applications. Secondly,
there is an urgent need to Improve the programable signal processor
programing environment. Machine level programing of programmable
signal processors, the current practice, poses severe limitations on
practical use of signal processing power of new technologies and
architecture. The direct relationship between lines of machine code
and number of gates to be programmed requires major improvements in
programer productivity If signal processor hardware advances are to
be fully utilized.

Through the course of development of the AN/UY-1, the Navy has

slowly advanced from machine level programing to partial use of a
Nigh Order Language (SPL/1). Most programs remain assembly code
programs. Although a true High Order Language exists architectural
constraints of the current standard result in applications code that
is not machine independent. Systems programers are required to
effectively program the current standard. The small number of
applications engineers with this programing expertise limits
productivity. There Is a requirement for an applications code that
is not machine independent. There ti a requirement for an
applications oriented interface to the users at a level of
abstraction above the NOL, a problem oriented notation system. This
notation system is to be part of the machine/languaqe independent
application programers interface. Production enhancing
environmental tools based on the Navy's Machine Transportable
Support Software (NTASS) tools must also be made available for
programable signal processor program developments.
Thirdly, there is a requirement to develop an in-service
commodity management concept that accommodates the conflicting goals
of providing long term product stability for economic and
logisticsupport reasons and following a program of agressive
technical infusion during service life. This requirement dictatep
the recognition of WISP as a system rather than a device.
Interfaces between architecturally significant elements must be
formally managed to allow technical infusion in independent
elements. The software Interface to the applications programmer
must isolate applications program from hardware or system software
upgrades. And, system upgrade must be accomplished on a module
replacement basis to decouple EISP upgrades form ship overhaul
periods.

502
 Finally, there was an absolute requiremint fot competitive
selection of the engineeringl development eotractor. **cause the
Navy standard computers and processors, once in production, ore used
in all systems with processing requirements as a matter of policy,
development contracts must be competitively awarded.
?he acquisition approach taken to selecting an enqineerinq
development contractor has worked well, beyond Navy expectations.
Seven team composed of twenty-one prominent firms submitted
proposals. Five of these firm were selected to participate in a
sMachine Definition/Proof of Principle testing phase. Competitors
developed a Principal of Operations (POPs) document describing CSP
to the level necessary to program it at the assembly level and
performed proof at principal demonstration necessary to satisfy
preliminary Navy technical testing requirements. Western Electric
Company was selected from this highly competitive field.
?qK: nical Ao

n1 mosm"3
ow I WOau

CQQMK~ N I APKa
I AC? 'CAL

This section presents the technical approach to MSP. The

technical approach was developed to encourage Industry participation
and innovation.
Figure 1 is a block diagram of ESP. It was used by the program
office to present the MSP architectural requirements, not support a
particular architecture. The parallel set of processing modules
consist of proqramable array processors, special purpose single
function devices, and high speed Input/output modules. The number
and types of modules in parallel and system performance will vary
f ro one proposed systlm to anothor. The effective agreqate of
4 computational power of th set is the system's performance. Sensor

4 503

-. ,* ~? % '' - ~ .P~J.**. 1 I Mai'

 ata tS input to these modules. ?he high speed I'0 modale
intefa•eS the syst" to Combat ystem data lbusses of linef devar -:
requiring data rates that esceed those provided bY M LztO*jIj,
interfaces. A global goo"ary is 8hwn as one at the said(
architect4ral elements. This memory is to be accsseble by all
processing modules. The Data Transfer Network (DIi shown as the
center block is the physical interconnection of proceasinq
modulesand mmory and the control processes ad procossofs tst
control module operation and intermodul. data transfers. It to in
this are of networking in which the Navy is properly taking vW%4t is
considered measured tochnical risk and expects signiticmnt payoff.
There were a number at excellent array processor, available to the
Navgy in mplentations that Teruit their stacting in large numbers in
fte € umuloative throughput of that stock w~ould
4 single cabinet.
more thas meet the performance required. Realizing an effective
system level of performance requires agreqating individual module
performance by the DII without -unacctancedegradation cause4 by
network contention or control problems.

The performance of the system has been specified in considerable

detail in terms of a set of benchmark algorithms. Input bandwidthv
have been specified to establish computational performance.
Algorithm ares

a. Inter Array Procesina

This algorithm produces large, two dimensional ambiguity
surfaces from Independent Input data streams. Poes it
sequential ambiguity surfaces are tracked to establish
convergence to mean vplues of surface parameters and
uncertainty area about mean values.

b. Adaptive Bem Foralng

Individual sensor data from an array of sensors is
constructively added to form a directional array rpsponso.
Sensor phase and amplitude weights are adaptively moadlfl
to steer side lobe nulls at directional interference.
Modifications ate constrained to prevent unacceptable m*in
lob*e degradation.
c. Sonobuoy Processina

Sensor Data from a large number of sonobuouys is filtared

through S octavts. Bach octavo of each sonobuoy is
spectrum analysed In parallel paths.

Sonar data from a multi element sonar array is *)Peam forsed

by a linear beam forming process. sea* data it spectrux
analysed in wide baud and narrow band spectruo analvnitt
paths.

]5a%

A. . . . . . . . .I
 0. wide band Lnetc*Vt PfqC@sStini
Vety wide band data tram a s0q1e seso is spect+,
anlIyved In wd4band and aarow band paths. EnOry
detection in eithbr path Initiates tifer rIsla sigals
analysis.
each alqoritbn is specitiod I signal flowiaoph toro. VW
Co0pwatw4tOal operations at 04a made are epeeli04.
The set Ot bencharli algorithms establishb s r qsatmots tor
data tlaw, eaedling provellq tas4s1 oOutations, inteorodil.
data traosfers, and seor ylow ad rortoresnc. tot the systei. This
set was means to stress t doein we" repreesoaltolve ot
anticipated applications of MUP. ThW dowaeiIod omboets of Cho sip
faally are speilled in ters of proportiomally scaled Gets of the
S

tenalorm
seet ima. f
Senchar~ alo#men

-0- -0

O O MM _M- PIGOII
fl I .

riqure 2 sowmS th specific NP a1rchitectural 41pproach. '

I ndtepend~nt memory modules are connected to processi1ng sodulee
YrProwqb a1pelt of non-blontlnq s1witchin ntwtort. the p1thsl are 12
* item wide. Attown*
the DIu Lco10 rate, l1 bit words 41re comlunica ted at
4 tAO abs rate. Th set of procseing modues Isave aim aggregaste of]'
JOG a inglt/ntec burst ra1te processing poser of i whicl~O S0 me ts/asec
41P

plus can be realied" in steady sta1te procesing b~enemarts.

="~ ~ ~
$cheduling IIY
~ is Te""
~ ~ liva1
proided :"f-s'+'m'
~~ 4a"separa1te
~~W ' ""OW "+' buas.
control "+ "+
Th : + "'+
system can+ "" ", '
-ctable and dislpatch 40 Inodsfs signal procesinq tests WI?, -
Av a'raq., Correlate, etc.) wahichl f4r ewcLeds benebs1art reruire~mt+.I
*. -
 c -

li"twr Awjw

Avg

L
Men

Theevelpin
asyto anaffrde o te stlwaJ 2908

prcesigefirm~"th WiO - iofet hsevt-1 1t

COMMOA tndr W
-_____eCrrn VWl 40Pttt"

leeboeaiFe
04qletm

"0prgrmig
rga

otwwr~og
IfIure I-eit'hs nioMt
retect~

t bod n
tl~dt

drete
PPs

tSAgrphftetw

019MI pre'Iv NOL thelopha9 C to"thtie@vy stnae

irade .Iq allo
 &.wtt that wftO4u1. mind dISMI.... tkdo tb glop 64"ehaad 0a
wu6140tit1y of 44"tI dagoi to a6
o** 4ato ttaw 60evl610'h
.MW AV SIC9O 00f tw each AV pfisiiu0.
aWpitlaw.e Pgoggare Spocitted to qrIF60c* tore ad %*ad
Cooed ts grapli fteat ion. te go"p &baglo coo~ be owch see
pf"*esed to utewta'te amdei1thof AWiS-t of 401VS-) cadif"
at f fWe"10 a todotsv of on order to SM55tid 00
Shia toe
a"*41 the Mom@
~of @t io of 0&~ to 60 6&e oded. Rafct 41
40411&0 to Gdo .PP11sea prof" oa l vol otf 'r"0
46MOe NOt peov#400~ eeo of 9ft .ubr at Its** ot 0.01 O040
to00b W11SO 6 8506 OPY SWe %%S 09er Of 01404t~dO.
?too#* 4 sham a typeol Was so Its", pae of 00. 6006"O
* 1
Trom~e. s algorithm. This eoqrph o. part of tbe wo" hmo to
tor %tb.els as elt* re . ts lbse O&VIe. te det~a
40000 o OORtedtotheAOC"f bo %b C 00a to coft"Wie to
a eqvese of incw filter -1Oa. sea%GetaVo filler side to
Comprted to Ite owt otave tiler noei-o S-In lss, O 05vputo
to aSolber &AD raph wells Ie fleet1 qgoe (Wi bhhit
boset "a AC nodes*eotes h be tc.OMC qvoe once@
tor.eebeld Valo. dad coapta to the goV qe. Owte *"*fat
qe. ios of the AM sct tow tom "g data auotai will
0*9eed ttlobld dad the Oc"VAW 5581~v e teeoo ame da to
%*at qVeue. Two data to filtet 1020 bolt badol tbs a e . fat
bond it coae to the @CTAM3 qseue ad the lower lot*1=WIQ?
queue %#shot*v9"00e 6 nde.et thrtestledpt

queueIbtebeld
alis ore mdsd

OWNc~

vimi
 ?Tbo SOLUOSPL Iq~g
Iwpm~e
to tf* *W ,cot s i , ,c
M
"4 as iwell OPW tho MeO~
d' if%*i~e3t46

?be " I~oIt satwerv O*PtG4ft *I 0411t *#*~dad t%4&- tc~

lap Como Opcatinq Softveq cookpi. fthe 4149h
#Otw.* ob*4f total 4" WL tsPL/It *go C04M #04s t*%.q 1b@4Aq
developed tog tho cottons SC&A"drd. Vhs ou 4" trot i~fto
rptogamwtoL peovld. an Islotoo to the ~C*Ofo 0 :t,efi Pf
rep@WPUl qt*IiS* to ehmo foadeble tweet~. WW a *l&
Peoousooof"Ioomea to pfcors Ofaph veec'eti1o coneael Pfewe..

Tseo %l*q Ism* Mfeades"ils*iqiit.*t, OP~t svI

bit
-- I - o#* wl. toUds deI*e AACe tOtatsq I9. od
d"ov*
de Sm M 01b Oatot se.p tot lb.qof.. s&cI~ '.
%**I~
#alto#. tImtws
$"eiitve to"*##,4 tee3
col time130 a i ts do ot. ctig Oatio thelt' SI40wo I%&
OW4@ f too Ptsowe
110 SotOW*I*i403
"t~10 Ofb.~t to.
as
doteticp16161o6 ctqeicmtte
*to. to eftii.ottevat. *Of~f*

OIfIcople in Bato
gwo tcoeir
be.@c.
%a* 00'4~
Oatot Voe peeeq
toe~Iftleft both t M
00"q*so c
sata .*of s

pctee0*1 00010 compee~le Pte.VIGO* too*# .

4,

NO W

sit'

AW9M
 Table k lists the SPGV that specifies this subqraph to the
prepfoceor. Although notation conventions have not been covered in
tris paper, The notational representation of the qraph is
*Ott-exptanatory when compared with the subgraph. Bach of these
node statements expands into 12 lines of SPL/, the ROL. These 12
lines of SPLI| expand Into approlmately 140 lines of machine level
control code for the current standard.

aW
0 $* * - 0i" 6
0
W*0 4 m07#*0v *
.UI q . ,Ill

* 40
, lU *4 4"+411 *%*40**•+ W ,
O.
l , -• 1*l
,A

04w*0t#1404 ffW*A#4 -*O

•
*ll~ mI,&4 S.ll 'S.

*tf ato *,*I

a. t.
"oft* 4q w •soft
O*0.**.Wn 444*44.0 * ft

1* 4*6., l II,
ew l

of* *"V'. *

;Aft 4I*"#~ 40S4 **,f"I NIO

-,I m *- Im

OWAN010m. *AOOsO4

.01WW
" two t * 3V-04
oft Oft 0

4a~~"n 00*q*t44
ft"US4

The operatinq system of the current standard is being modified

* by tr, aMdtim of a data flow based scheduling and dispatching
prarae. Thls algorihw m called a 119U., monitors data accumulation
iis data weees fincludinq tti99er queues) and schedules execution of
ncites vhev data quome threshold values have been reached. The
resultant Is a data driven operating system asynchronously executing
t-10 no, Speclilfied by signal tlow graphs with the Signal Processor
(Iraph Notation (SPG). The amer interface SPGN is machine
indewponedot and oriented towards the expertise of the applications

dli'l
iliJr,
 VT emt* ties "s'lret, peil of the pfoqraiftq
0wmicamow.t. to Obo to q@Mt daetl to titugo 6. Machinet
r oaogo twat& CO000
of swll..ltom ptrvinamqIinpu it% tIt.
apof gcoo eattlism to the puepoveeao. A macro file to# iso
on$. to? this aie. was% be -Atitived. Sotitco. ce
ewla,. ltqtOW impat
rt 0OWseFtgd 10 SbO COW410. TIe CM~ito oetpis Lo]&-
file* toto It***#R. Tte III**# accopt* CO)O~ ft**e for %s
Opeatiag *yotai peoqv.s the 09LL SIJI owtom~w.. *ad th* SPLO1
comd peogai %6106boe Mbe epewtessly to* 0104. Uittd
~W~tibit" s"
goe* state cofed peloittwo .ro 11not as
well. Aad ape to Ite. 9emtod tot US?.
The OS? speta eyeless too OW 98=, to caftt4ored ve
bestqot the US? d~vio. aid sepet ble tfa t" ptwlkiq~s
*ukfteatote. ?TW a eftleivm.V to supe log data diriv"4 teso
quastlem 041l delegte* uw 604 of 1Ake OtSCOS 040t*48 Q4Cii.
I rel
Ib,.q~ lad o. ttectiv
Io kriqwt.

cudity amtqastleft o01US dat Seq its. q.rvie

Oset
lite will be based amsotaIblihmet o1 stawndud iptattoc Oa'd
prot"Ocl. *414ia the SO&* aid strict 00"tiq~rtai *Aweeww.ev ofW
thaws steadardo 60t 90#9109 lie. IMuu4a of tecutao
q'm
Isf..iet will be be= cm a~fdipq statlectatal 1@eseeto tbeI.efq
ietefteo *Rd feqwIrla9qf~rded 40"Je be d4I1qr4 to WAet

WOO a.

loll
 Figujre 7 shows the VISP architectural block diagram with interfaces
to be configuration managed identified. The interfaces to the
sensor data are expected to be a reasonably small set of
interfaces. As new applications require interfacing E4SP to new
sensor types or other devices via a high speed 1/0 additional
interfaces will be developed. The interface between the Data
Transfer Network and the set of Processing Modules is of utmost
importance. As new applications require new types of special
purpose processing modules, new modules will be designed to meet the
existing interface and Incorporated into the EMSP system.
Technology upgrades of processing modules shall be accomplished such
that the upgraded module meats the existing DTN, interface and
protocol. Back fit of upgraded, modules may be accomplished
conveniently without expensive, equipment rip out of reprogramming of
applications programs. Recent congressional language directed the
049P program to insert V11SIC technology and conduct proof of
principle demonstration to validate the concept of VHSIC technology
44 insertion. The Navy will address VHSIC Insertion at the chip level
and the module level. VUSIC chips will be incorporated into
,'7
appropriate modules as VUSTC chips became available. Navy VHSIC
trassboards will be reimplemented In the RKSP brasaboard from factor
and interfaced to the MOSP DYN. These VUSIC brasaboards will be
integrated into MUP as front end modules. Operation of benchmarks
at ouch increased performance levels will be demonstrated. The
interface to the support computer will be one of the standard tDS
interfaces. Upgrade of the DTN when technology supports such an
upgrade oust be accomplished to meet both the processing module
interfaces and WTDS interfaces. The interface to the user, the
applications prograer is the software interface previously
discussed. It is intended to pursue an agressive, technology
intaslon program during the service life of the WISP system. As
otpontive as technology upqrades and system software changes are,
rPn#y are bearable a" non-recurring costs of keeping abreast of
technology and ahead requirements. Recurring costs of application
software changes for each upigrade must be avoided. Upgrade of
ptaqrasmablo processing modules will require new primitive microcode
to be generated and operating
Ineto.TeNv i!ades4EI system changes,
neto but not
ttec~changes in
ee
applications
an4h ouelvl programs. From the
BI hp users
iib pointnoprtdit
of view, the EISP
system should remain stable.
) asbors wi***re*f*mtaReliability andn Availability
h BlS brsbor %ro* factor*%

The hi ~h degree of parallelism in the architectures of candidate

WIs viii support deyelopet of operational availabilities that
an
(at 0ue prs ent levels. Spport ctots, the cost of parte parts
and repeite will remain a function of fundamental hardware
Sreliability. ABoth attributes are important to Wpi.

sunsosental hardware reliability is being specified as a

Tranferie to Fault I with faults defined as any hardware
cetritipan requiring a logistic action, i.e., repair, spare part
consumption, te. All faults, wetheor their repair is deferred or
i-wediat, are conted. nr ing equipments for extended missions
by replacing cards with built in redundancy bcause of fault of one
or more of the parallel paths is a deferred repair.

#4 511
 Operational availability is specified in terms of a Mean Time
Between Failures of the system (MTBF). Failures are those single
faults or aggregation of uncorrected faults that cause the system to
operate at less than full capacity. MTBF must equal or exceed
MTTF. Those architectures which have signicant redundancy in
architectural elements in reserve will have MTBF's far exceeded
MTTF. Two levels of degraded mode operation are specified, an 80%
or 50% performance level. These levels mean that all application
programs can be executed at the specified percent of the input
bandwidth. The Mean Time Between Failure below the 80% and 50%
performance level of the system is greater than the MTTF and MTBF
for full performance system failure. A final availability to be
specified is availability of a particular application program. This
quantity is dependent on the amount of extra capacity available for
reconfiguration in the event of a fault for a particular EMSP
configuration and application program. This is specified in terms
of Mean Time Between Critical Failure (MTBCF). A critical failure
is defined as a fault or aggregate of faults that causes a
particular application program to be unable to execute at its full
performance level. An application program that loaded the EMSP 50%
would sustain a critical failure if the system degraded below the
50% performance level. The MTBF for 50% degraded performance level
would equal the MTBCF in this case. Since a variety of
configurations will be available to users, including multi EMSP
systems, application engineers may control the availability of their
program through designing in over capacity for their particular
application programs
Acquisition Approach
The constraints of supporting the first users concurrent weapons
system development, the technical risks involved, and meeting the
normal requirement for competitive selection of the engineering
development contractor, dictated a non-traditional acquisition
strategy. The Navy is has completed a two phase extended service
selection process which resulted in the selection of a single
engineering development contractor. The first phase was a normal
proposal phasel the participation of all potential contractors was
been solicited. As mentioned previously, a variety of system
architectures were proposed. Offerors were required to identify the
technical risks involved in their particular approach and propose
Critical Item Demonstrations (CID's) to demonstrate manageability of
technical risks in engineering development. These CID's were
proofof principle type demonstrations on partial brass boards with
supporting analyses. An outline of the Principles of Operations
(POPs) was proposed as well.

For the second phase of the extended source selection process,

the Navy awarded five contracts for performance of the proposed
CID's, completion of the POPs, and delivery of plans and studies
such as hardware and software development plans and reliability
analyses for evaluation. Based on the POPs, the plans and studies,
and the Critical Item Demonstrations, the Navy selected the sinqle
engineering development contractor, Western Electric Company.

512

* - ~ Vf.* *~J~%*
 ..... ,in,. . *J * . .. . . . . . .T .. -. . . > . i

Major Engineering and production milestones are listed below:

Engineering Development Contract Award -- August 1982

Delivery of System Engineering Facility (SFF) -- August 1983
Delivery of Functional Development Model (FDM) -- March 1984
Delivery of Engineering Development Models (FDM) -- Sep 1985
Availability of Advanced Production Equipments (APE) -- 1986
Availability of Production Equipments -- May 1987
The System Engineering Facility (SEF) is a software simulation
of the POPs which is hosted in a commerical machine. The Functional
Development Model (FDM) is non-militarized version of the EMSP, a
POPs emulator. The Engineering Development Models (EDM's) are fully
militarized units delivered for Navy acceptance testing. Advanced
Production Equipments (APE's) built to EDM specifications will be
made available to users for system development. Upon completion of
Navy acceptance testing of EDM's any discrepancies found will be
corrected in APE's upgrading them to production quality machines.

Software deliveries are scheduled to commence 6 months after

award of the engineering development contract and continue through
delivery of the FDM's.

Testing
A vigorous program of testing is planned during engineering
development with the goal of supporting an early decision to
authorize a limited amount of pilot production in advance of
authorization of unlimited production by the Navy. This limited
production authorization is important to accomplishing fleet
introduction of a new processor on an economical basis.

Using the SEF as a vehicle, software Validation and Verfication

(V&V) will be initiated early in the development. An independent
first users group will be formed within the Navy Project management
team. This team will program the benchmark algorithms for execution
on the FDM's. Algorithms from selected in service systems as well
will be programmed using the FDM. This group will do much of
thesoftware and functional debugging that in the past has fallen to
the first combat system user. Functional testing of the EMSP and
further software (V&V) will be conducted on the FDM.

Technical testing of the EDM's will consist of environmental

qualification testing including maintainability and reliability
demonstrations and Design Verfication testing. Operational testing
will consist of execution of selected algorithms in shore based test
facilities on actual sensor data. Based on successful technical and
shore based operational testing of the EDM's authorization for
limited production will be granted, and a production line opened.

513
 Conclusion
The Navy is undertaking an agressive program to introduce a
second generation standard signal processor EMSP into the fleet by
1987. This processor will meet emerging processing requirements for
this decade and accommodate technology infusion to upgrade it for an
additional decade's services life. EMSP is a multi-processing
system, network of programmable array processors and special purpose
devices. System performance is the effective aggregate of
individual processor performance. EMSP software, ECOS, is based on
support software under independent development for all Navy standard
signal processors. It provides a user interface a level of
abstraction above the HOL SPL/I. The system will have a data driven
operating system and support tools to increase application
programmer productivity. The software, particularly the operating
system, will influence the system architecture and implementation.
The Navy is in effect building an ECOS machine. There is technical
risk involved in this development. The acquisition plan and test
program are designed to manage risks, keeping them at acceptable
levels. While this development is to meet future Navy signal
processing needs, it is hoped that many multi-processing concepts
may be validated in the course of development that are extensible
beyond signal processing applications.
References
1. Purchase Description No. 101 for the Enhanced Modular Signal
Processor (EMSP), Naval Sea Systems Command Purchase Request Number
N00024-81-PR-28807, April 24, 1981
2. ACOS Methodology Program Performance Specification, Naval
Sea Systems Contract N00024-80-C-7198, January 7, 1981

514

-" .-, ... "S

STANDARDIZED SOFTWARE DEVELOPMENT

SESSION CHAIRMAN. David J. Krle

ASD/ENAMR

MOOERATOR: Colonel Harold C. Falk

AFWAL/AA
Speci Assistant for 81Outtors

I'v * . ..t
.
 *ft

IL a
0 4
a fl~a
I z

@!SZ

517

.
z .4 ~ ca m-

Zm4~

m mm

Zo a
C)
mm .

m0
z Z

%V ~.%gap
 I.-

OUs ZJ
wui .

0 4
0,0
-IC C
- 4

91
 ICI
I...

520

-. ~U %-- **~I% *** ~r

VdI*~* W .
 idol
0~o
fil
U2
 3
i

SI
iicu

Mla

oe
Mas

52)
 00c
wLI

~0 c
UU
* 0 w
5 z E
30~ a c

524
 z. . . . . . . . . . .

16

Si

U
0 z
us Us
w a
~~zu

Uggg
44l
0

i 0 0 am
0 PO z

8~~E

II

S27
 z

0 0
~EI0 an

OU 0 z

000

528
 0 -vm w

G om8

*l

0- ,'