BEACHCA

AAI?95 TRWDEFENSEANDSPACESYSTEMSGROUPREDONDO F/9 9/2

DIGITAL AVIONICS INFORMATION SYSTEM (DAIS): DEVELOP1ENT AND DEM--ETC(Ul
SEP at N J COOK, R C MASON, J L STAUTBERG F336h158C-1502
UNCLASSIFIED AFWAL-TR-81-1165 NL

m IIIIIIIIIIEE
ElEElllllElllE
IIIIEEEEEIIIEE
EIIEEEEEEEIIIE
 AFWAL-TR-81-1165

S DIGITAL AVIONICS INFORMATION SYSTEM (DAIS):

DEVELOPMENT AND DEMONSTRATION

TRW DEFENSE AND SPACE SYSTEMS GROUP

ONE SPACE PARK
REDONDO BEACH, CALIFORNIA 90278

September 1981

I Final Report for Period 1 October 1978 to 31 July 1981

Approved for public release; distribution unlimited

U- AVIONICS LABORATORY
AIR FORCE WRIGHT AERONAUTICAL LABORATORIES
AIR FORCE SYSTEMS COMMAND
WRIGHT-PATTERSON AIR FORCE BASE, OHIO 45433

S 1i 01011

--
-----
 NOTICE

When Government drawings, specifications, or other data are used for any purpose
other than in connection with a definitely related Government procurement operation,
the United States Government thereby incurs no responsibility nor any obligation
whatsoever; 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
other person or corporation, or conveying any rights or permission to manufacture
use, 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.

r-
_)V1tid
BOYDOE. HOLSAPPLE
I 0&1A4 9 4
L. DANIEL SNYDER, Chief
PROJECT ENGINEER Mission Software & Sys Integration Gp
System Avionics Division

FOR THE COMMANDER

RICHARD H. BOIVIN, Col, USAF

Chief, System Avionics Division
Avionics Laboratory

"If your address has changed, if you wish to be removed from our mailing list, or
if the addressee is no longer employed by your organization please notify AW.'/A &I,$°
fV-PAFB, OH 45433 to help us maintain a current mailing list".

Copies of this report should not be returned unless return is required by security
considerations, contractual obligations, or notice on a specific document.
SECURITY CLASSIFICATION OF THIS PAGE (ahn Dae Entered)

REPORT DOCUMENTATION PAGE

PAGE READ INSTRUCTIONS
BEFORE COMPLETING FORM
1. RPOR NUBER2. GOVT ACCESSION No. 3, RECIPIENT'S CATALOG NUMBER
1REPORT NUMBER
7-.
AFWAL-TR-81-1165 R N
4. TITLE (od Subtitle) S. TYPE OF REPORT & PERIOD COVERED
DIGITAL AVIONICS INFORMATION SYSTEM (DAIS): FINAL REPORT
DEVELOPMENT AND DEMONSTRATION 1 Oct 78 - 31 Jul 81
6. PERFORMING ORG, REPORT NUMBER

7. AUTHOR(e) II. CONTRACT OR GRANT NUMBER(s)

M. J. Cook L. E. Self
R. C. Mason R. L. Ellison F33615-78-C-1502
J. L. Stautberg M. J. Strathman
9. PERFORMING ORGANIZATION NAME AND ADDRESS 10. PROGRAM ELEMENT. PROJECT. TASK
AREA & WORK UNIT NUMBERS
TRW Defense and Space Systems Group 63243F
One Spack Park
Redondo Beach, California 90278 2052 05 18
II. CONTROLLING OFFICE NAME AND ADDRESS 12. REPORT DATE
Avionics Laboratory (AFWAL/AAAS) September 1981
Air Force Wright Aeronautical Laboratory 13. NUMBER OF PAGES
Wright-Patterson AFB, Ohio 45433 201
14. MONITORING AGENCY NAME & ADDRESS(If different from Controlting Office) IS. SECURITY CLASS. (of this report)

UNCLASS IFI4ED
ISa. DECLASSIFICATION/DOWNGRAOING
SCHEDULE

IS. DISTRIBUTION STATEMENT (of this Report)

Approved for Public Release; Distribution Unlimited.

17. DISTRIBUTION STATEMENT (of the abstract entered In Block 20, it different rom Report)

IS. SUPPLEMENTARY NOTES

19. KEY WORDS (Continue on reverse side If necessary and Identify by block number)
Avionics Software Displays Multiplex
Avionics Systems JOVIAL Processor
Computers MIL-STD-1553 Simulation
Controls MIL-STD- 1589
DAIS MIL-STD-1750
20. ABSTRACT (Continue on reveres side If necessary end identify by block number)
The Digital Avionics Information System (DAIS) represents a significant
advance in the technology of avionics system architecture. DAIS is a total
systems concept, exploiting standardization, modularity, and application
independent executive software to provide a system architecture adaptable to
many aircraft, missions, and avioniLs configurations and fully capable of
accommodating new advances in technology. These fundamental system charac-
teristics are described in this report; the specific system features which

DD IjAN 73 1473 EDITION OF I NOV SS IS OBSOLETE UNCLASSIFIED

SECURITY CLASSIFICATION OF THIS PAGE (*%en Date Entered)
SECURITY CLASSIFICATION OF THIS PAG("n9 Dae Entoerd)

20. provide these characteristics and attributes are presented.

The DAIS core elements along with support software were integrated
into a hot bench support facility. Significant efforts were placed on
developing and validating new military standards in the areas of multi-
plex systems (MIL-STD-1553B), processor instruction set architecture
(MIL-STD-1750A), and software (MIL-STD-1589B, JOVIAL). This report
describes the integration of the core elements, the validation of the
military standards, and the phased demonstration of these military
standards in a representative close-air = support scenario.

UNCLASSIFIED
SECURITY CLASSIFICATION OF THIS PAGE(Whien Dos Entered)
 TABLE OF CONTENTS

Page

1.0 INTRODUCTION AND SUMMARY 1

2.0 BACKGROUND 3

3.0 DAIS SYSTEM ARCHITECTURE 6

3.1 System Configuration 6
3.2 DAIS Core Elements 10
3.2.1 DAIS Multiplex 12
3.2.2 DAIS Processors 21
3.2.3 DAIS Controls and Displays 22
3.2.4 DAIS Mission Software 27
3.2.4.1 Executive 27
3.2.4.1.1 Local Executive 28
3.2.4.1.2 Master Executive 28
3.2.4.2 Application Software 29
3.2.4.2.1 Navigation 29
3.2.4.2.2 Guidance 29
3.2.4.2.3 Weapon Delivery 29
3.2.4.2.4 Position Update 29
3.2.4.2.5 Display 29
3.2.4.2.6 Miscellaneous Functions 34
3.2.4.2.7 Stores Management 34
3.2.4.2.8 Pilot Control 34
3.2.4.2.9 System Control 34
3.2.4.2.10 Common Subroutines 34
3.2.4.2.11 System Functions 34
3.2.4.3 Mission Software Architecture 34
3.3 Other Elements 35
3.3.1 System Mass Memory 35
3.3.2 Processor Control Panel (PCP) 39
3.4 Non-Real-Time Support Software 39
3.4.1 JOVIAL Compiler 39
3.4.2 Partitioning Analyzing and Linkage Editing
Facility (PALEFAC) 42
3.4.3 Assemblers/Linker 44

4.0 DAIS SYSTEM CHARACTERISTICS AND FEATURES 45

4.1 System Control Procedures 45
4.1.1 System Startup/Restart Operations 45
4.1.1.1 Normal System Startup 46
4.1.1.2 System Warm Start 46
4.1.2 Normal System Operation 48
4.1.2.1 Bus Control Operation 48
4.1.2.2 Mode Command Operations 56
4.1.3 Application Software Executive Services 56
4.1.4 Error and Failure Management T -65-i
4.1.5 Configuration Management 67:

iii
 TABLE OF CONTENTS (Con't)

4.2 DAIS Architecture Features 72

4.2.1 Bus Devices 75
4.2.2 Processor,'Bu Controllers 75
4.2.3 Pemote Terminal (PT)/Interface Modules (IMs) 75
4.2.4 Application Software 76
4.2.5 Interface Standards 79
4.2.5.1 DAIS/15b3B Message Protocol 79
4.2.6 Portability 79
4.2.7 Redundancy 79

5.0 SUPPORT FACILITY 81

5.1 System Configuration 82
5.1.1 Integrated Test. Bed (ITB) 82
5.1.2 Software Test Stand (STS) 82
5.1.3 Physical Configuration 88
5.2 ITB Support Hardware 88
5.2.1 Universal Remote Terminal 88
5.2.2 Bus Monitor Unit 99
5.2.3 Console Intelligence Unit 100
5.2.4 Hazeltine Terminels 100
5.2.5 Processor User Console (AN/AYK-15A) 101
5.2.6 Performance Monitor Interface Unit (PMIU) 101
5.2.7 Simulated Subsystem Interface Unit (SSIU) 103
5.2.8 Super Control and Display Unit (SCADU) 105
5,2.9 ITB Power Distribution and Control 107
5.2.10 ITB Test Control Center 107
5.2.11 Controls and Backup Instruments System (CBIS) 107
5.2.12 ITB Equipment Racks 107
5.3 IT6 Si.,port Software and PDP-11 Processors 108
5.3.1 Performance Ionitor and Control 108
5.3.2 Performance Monitor Interface Unit 109
5.3.3 Simulated Subsystem Data Formatter (SSDF/URT)
Software 109
5.3.4 Evans and Sutherland Graphics System 111
5.3.5 ITB PDP-11 Processors 111
5.4 STS Support Hardware 111
5.5 STS Support Software and PDP-11 Processor 112
5.6 DECsystem-10 Host Simulation Processor 112
5.7 Simulation Software 114
5.8 Picture System 115
5.9 Data Reduction and Analysis Software 115

6.0 SOFTWARE CONVERSION 117

6.1 Mission Software Conversion 117
6.1.1 Executive Conversions 117
6.1.2 Application Software Conversion 117
6.2 Core Element Test Snftware Conversion 117
6.3 Multiplex Diagnostics Software Conversion 118
6.4 1750A ATP 126

iv
 TABLE OF CONTENTS (Con't)

Page
7.0 HARDWARE CONVERSION 127
7.1 Multiplex System Conversion 127

8.0 INTEGRATION AND TEST 129

8.1 Stand-alone Tests 129
8.1.1 Core Element Hardware 129
8.1.2 Executive Software Testing 129
8.1.3 Application Software Unit Test 132
8.1.4 Environmental Model Tests 132
8.2 Hardware Integration and Test 132
8.3 System Readiness Test 145
8.4 Results of Testing AN/AYK-15As from Two Contractors 145
8.4.1 Inventory of Tests 145
8.4.1.1 Bootstrap Loader 146
8.4.1.2 3-Processor Executive Acceptance Test
Program (ATP) 146
8.4.1.3 Processor Acceptance Test Program (ATP) 146
8.4.1.4 Multiplex System Diagnostics 146
8.4.1.5 BCM Error Response Tests 146
8.4.1.6 Input/Output (I/O) and Internal Tests 146
8.4.1./ Miscellaneous Tests 146
8.4.2 Results of Testing 152
8.4.2.1 Test Results for Westinghouse AN/AYK-15A 152
8.4.2.2 Test Results for Sperry Univac AN/AYK-15A 152
8.4.2.3 Results of Miscellaneous Tests 152
8.4.3 AN/AYK-15A Compatibility 152
8.5 Fiber Optics Multiplex System Integration and Test 165

9.0 SOFTWARE ASSESSMENT 168

9.1 Application Software Assessment 168
9.2 DMSS Assessment 168
9.3 PMC Assessment 169

10.0 MISSION DEMONSTRATION 171

10.1 Baseline Demonstration (Mission a) 171
10.2 Upgraded Mission Demonstration (Mission 6) 174
11.0 TECHNICAL SUPPORT 179
11.1 Hot Bench Development for PAE 179
11.2 Fault Tolerant Assessment of DAIS 179
11.3 Advanced Avionics Systems for Multi-Mission
Applications (AASMMA) 179
11.4 Fiber Optics Bus Receiver Requirement 179
11.5 Remote Link Unit Design 179
11.6 Fault Tolerant Computer Network Study 179
11.7 Mission Management Software for the KC-135 Avionics
Modernization Hot Bench 180

v
 TABLE OF CONTENTS (Con't)

12.0 CONCLUSIONS/RECOMMENDATIONS 181

12.1 Core Element Hardware 181
182
DAIS Software
12.3 DAIS
12.2 Support Hardware 184
184
12.4 DAIS Support Software

12.5 DAIS System Control Procedures 185

vi

r'
 LIST OF ILLUSTRATIONS

Number Title Page

1 DAIS Functional Architecture 7

2 DAIS System Architecture 9
3 Generalized DAIS Configuration 11
4 MIL-STD-1553B Message Formats 13
5 MIL-STD-1553B Word Formats 14
6 MIL-STD-1553B Message Sequencing 15
7 Bus Control Interface Unit 17
8 DAIS Processor/Bus Controller (AN/AYK-15A) 18
9 Remote Terminal Unit 19
10 Control and Display 24
11 System Mass Memory Message Formats 37
12 PCP/ACP 40
13 J73 Compiler Structure 41
14 PALEFAC Overview 43
15 Bus Operations 54
16 Message Transmission During a Minor Cycle 55
17 Asynchronous Message Protocol - Remote Terminal Request 57
18 Asynchronous Message Protocol - Interprocessor Message,
Example #1 58
19 Asynchronous Message Protocol - Interprocessor Message,
Example #2 59
20 Task State Diagram 63
21 Configuration Management Interactions 68
22 Reinitialize RT 70
23 Built-in-Test (BIT) Word - RT 71
24 Built-in-Test (BIT) Word - BCM 73
25 Status Exception/Bit Word Analysis 74
26 Mission Software Partitioning - Three Processors 77
27 Mission Software Partitioning - Two Processors 78
28 Initial Support Facility Functional Diagram 83
29 Current Support Facility Functional Diagram 84
30 Integrated Test Bed (ITB) Functional Block Diagram 85

vii
 LIST OF ILLUSTRATIONS (§on

Number Title Pale

31 Integrated Test Bed Pictorial Diagram 86

32 Initial Software Test Stand (STS) Functional
Block Diagram 87
33 Current Software Test Stand (STS) Functional
Block Diagram 89
34 Initial STS/ITB Floor Layout 90
35 Current STS/ITB Floor Layout 91
36 Initial Software Test Stand Test Control Center 92
37 Current Software Test Stand (STS) Test Control Center 93
38 Initial Software Test Stand (STS) Equipment Racks 94
39 Current Software Test Stand (STS) Equipment Racks 95
40 Integrated Test Bed (ITB) Test Control Center 96
41 Initial IntegratedTest Bed Equipment Racks 97
42 Current Integrated Test Bed Equipment Racks 98
43 User Console Configuration 102
44 SSIU Interface Block Diagram 104
45 DECsystem-1O Host Simulation Processor Configuration 113
46 Functional Configuration - Picture System 116
47 Sample Hardware Configurations 134
48 Block Diagram of Hardware Used by the RT/IM
Diagnostics 136
49 Hardware Configurations for Testing the C&D 143
50 PMIU Interface Diagram 144
51 Test Configuration for the 3-Processor Executive ATP 147
52 Test Configuration for the Processor ATP 148
53 Test Configuration for Multiplex Diagnostic Tests 149
54 Test Configuration for BCM Error Response Tests 150
55 Test Configurationsfor the I/O Tests 151
56 Mission a Configuration 172
57 Mission a Configuration 175

viii
 LIST OF TABLES

Number Title Page

I Design Considerations Utilized in Meeting
DAIS Objectives 8
2 RT Interface Modules 20
3 Application Software Programs 30
4 Start/Restart Cases/Options 47
5 Bus Message Operations 49
6 MIL-STD-1553B Mode Code Commands 60
7 MIL-STD-1553B Mode Code Relationship to System
Functions 61
8 Data Available to SCADU from AN/AYK-15 Processor 106
9 List of all the MUX Diagnostics Tests 119
10 Devices Used by Each Test in Mux Diagnostics
AN/AYK-15, 1553A 122
11 Devices Used by Each Test in Mux Diagnostics
AN/AYK-15, 1553B 123
12 Devices Used by Each Test in Mux Diagnostics
AN/AYK-15A, 1553B 124
13 Special ATP Test Names and Descriptions 130
14 ATP Load Module Names and Descriptions 131
15 RT/IM Diagnostics Tests 137
16 Controls and Displays ATP 139
17 Westinghouse AN/AYK-15A Summary of Failing
Processor Tests 153
18 Westinghouse AN/AYK-15A Summary of Multiplex
Diagnostic Tests 154
19 Westinghouse AN/AYK-15A BCM Error Response Problems 155
20 Westinghouse AN/AYK-15A Summary of I/O and
Special Tests 157
21 Univac AN/AYK-15A Summary of Failing Processor Tests 158
22 Univac AN/AYK-15A Summary of Multiplex Diagnostic Tests 159
23 Univac AN/AYK-15A BCM Error Response Problems 160
24 Univac AN/AYK-15A Summary of I/O and Special Tests 161
25 Univac AN/AYK-15A Memory Access Test 162
26 Master 15A BCM Start and Stop Times 163
27 Mission a Configuration 173
28 Mission a Configuration 176
29 Mission Differences 178
ix
 GLOSSARY

ACRONYM DEFINITION
ADI Attitude Direction Indicator
Alt. Altitude
AP Armament Panel
AR Aiming Reticle
AVSAIL Avionic System Analysis and Integration Laboratory

BCI Bus Control Interface (module embedded in the

AN/AYK-15A processor)
BCIU Bus Control Interface Unit
BCM Bus Control Module
BFL Bomb Fall Line
BIT Built-in-Test
BMU Bus Monitor Unit

,AS Close Air Support

C&D Controls and Displays
CBIS Controls and Backup Instruments System
CCIP Continuously Computed Impact Point
(IU Console Intelligence Unit
CPCI Computer Program Configuration Item
CRT Cathode Ray Tube

DAIS Digital Avionics Information System

DEK Data Entry Kevheard
DISP Display Process
DMA Direct Memory Access
DS/MU Display Switch/Memory Unit

EQUIP Equipment Process

FIM Facility Interface Module
FLIR Forward Looking Infrared Radar
FPM Flight Path Marker

HARS Heading Attitude Reference System

HAS Hardware Architecture Simulation System
HBC Hot Bench Computer
HSD Horizontal Situation Display
HSI Horizontal Situation Indicator
HUD Head Up Display

ICD Interface Control Document

[CS Interpretive Computer Simulation
ILS Instrument Landing System
IM Interface Module
IMFK Integrated Multifunction Keyboard
INS Inertial Navigation System
IP Initialization Point
ITB Integrated Test Bed

x *1
 GLOSSARY (Con't)

ACRONYM DEFINITION

LDGP Low Drag General Purpose

LRU Line Replaceable Unit
LOS Line of Sight

ME Messaqe Error; also Master Executive

MFK Multifunction Keyboard
MMP Master Mode Panel
MMU Mass Memory Unit
MPD Multi-Purpose Display
MPDG Modular Programmable Display Generator
MTU Multiplex Terminal Unit
MUX Multiplex

NAV Navigation
N.M. Nautical Miles

OAP Qffset Aiming Point

OEM Original Equipment Manufacturer
OFP Operational Flight Program
OPS Operational Sequencer
OTP Operational Test Program
PAL PALEFAC Auxiliary File
PALEFAC Partitioning Analyzing and Linkage Editing Facility
PCP Processor Control Panel
PDS Power Distribution and Control System
PGI PALEFAC Global Input
PIM Processor Interface Module
PIO Programmed Input/Output
PMC Performance Monitor and Control
PMD PALEFAC Mission Data
PMI PALEFAC Module Input
PPI PALEFAC Partitioning Information Files
PRE Post Run Editor
RAM Random Access Memory
RAT Ram-Air Turbine
ROM Read Only Memory
ROT Rough Output Tape
RT Remote Terminal
SCADU Super Control and Display Unit
SCU Sensor ControIklr Unit
SDVS Software Design - Verification System
SITC System Integration and Test Coordination
SLS Statement Level Simulation
SSDF Simulated Subsystem Data Formatter
SSIU Simulated Subsystem Interface Unit
STS Software Test St I

xi
 GLOSSARY (Con't)

ACRONYM DEFINITION

TCC Test Control Center

TCU Timing and Control Unit--in Remote Terminal
TDM Time Division Multiplex
T/F Terminal Failure
T/R Transmit Receive

URT Universal Remote Terminal

VSD Vertical Situation Display

xii
1.0 INTRODUCTION AND SUMMARY

The Digital Avionics Information System (DAIS) represents a signifi-

cant advance in the technology of avionics systems architecture. DAIS is a
total systems concept, exploiting standardization, modularity, and application-
independent executive software to provide a system architecture adaptable to
many aircraft, missions, and avionics configurations and fully capable of
accommodating new advances in technology. The DAIS architecture results in
improved reliability and availability of avionics systems while at the same
time reducing life cycle costs.

Under the total systems concept, DAIS elements are not dedicated to
any one avionics function. Rather, the elements are used to perform the pro-
cessing and integrate the functions associated with the avionic sensors and
subsystems employed for a particular aircraft/configuration/mission. This is
achieved in part by the use of AN/AYK-15A general purpose digital processors
conforming to MIL-STD-1750A. The processors communicate with each other and
other system elements (e.g. C&D subsystem) via a MIL-STD-1553B dual redundant
multiplex data bus. Centralized system single point control is performed by a
processor-resident software executive. Application Software is structured to
provide modularity, reliability, and transferability. Both executive and
application software are implemented primarily in a MIL-STD-1589B JOVIAL J73
higher order language. The software modularity is enforced and enhanced by a
standard executive-to-applications software interface.

The basic elements of the DAIS architecture which can be reconfigured

for various avionics applications are called DAIS core elements (or building
blocks). The core elements consist of the DAIS processors, DAIS multiplex, DAIS
Mission Software, and DAIS Controls and Displays. Additional elements are the
support software elements, namely the JOVIAL compiler-, the assembler/linker,
and the Partitioning, Analyzing, and Linkage Editing Facility (PALEFAC). The
core elements, along with support hardware and software were integrated into a
hot bench support facility also known as the Integrated Test Bed (ITB). A
postulated 1980's avionics mission was flown using real-time, pilot-in-the-loop
simulations to demonstrate the DAIS architecture and concepts. The subject of
this report is the description of the functional elements and operational
characteristics of the final configuration of the DAIS ITB.

The final ITB configuration is the result of developments performed

in the period covered by this report. The baseline for that development was
the DAIS ITB as successfully demonstrated in September 1978 and documented in
AFAL-TR-79-1027. The substance of the development was the incorporation of a
number of system improvements, the integration of second generation core element
hardware and the conversion to the newly adopted military standards: MIL-STD-
1553B (Multiplex), MIL-STD-1750A (Instruction Set Architecture), and MIL-STD-
1589B (Higher Order Language). The effort included the upgrade of all system
level specifications to completely and accurately reflect the current system
implementation.

This report presents a review of the DAIS architecture with a section

on each of the core elements. A section on other key elements and each of the
non-real-time support software elements is also included. System operation is
described in detail, both normal operation and exception management. Principle

-1-
features of the architecture are discussed and the support facility is des-
cribed. A separate discussion of the software and hardware conversion efforts
and integration and testing sequences is presented. The demonstration mission
scenarios are reviewed and project management and control procedures are
discussed. Support provided to other Air Force programs is identified and a
final set of conclusions and recommendations is presented.

Overall, this report presents and describes in detail an avionic

system architecture compliant with the most recent military standards, already
implemented and demonstrated, which is easily adaptable to many aircraft and
missions.

-2-
2.0 BACKGROUND

The Digital Avionics Information System (DAIS) has been under

development by the Air Force since 1973. Air Force avionics systems in
existence in the early 1970's were largely analog systems interconnected by
dedicated wiring harnesses. In addition to the weight penalty, these were
difficult to maintain, difficult to modify in response to new threat environ-
ments, and difficult to upgrade to accommodate new technology. The initial
thrust of DAIS was to investigate the use of general purpose digital computers
for avionics processing and of multiplexing techniques for data interchange.
In addition to these two specific areas of technology, DAIS also addressed the
larger problem of providing a system architecture which could adapt available
avionics subsystems and sensors to a common, modularly expandable avionics core.

The lack of commonality and compatibility was an area of major con-

cern. The classical approach to avionics provided a system unique to each
particular aircraft. Avionics systems tended to be snapshots of technology
available at the time of development with little or nor relationship to previous
work. The result is that aircraft which are part of the operational fleet at
a given time have neither commonality of hardware or software, nor any sort of
compatibility. The effects are felt in costs and reliability. Additional
front-end design costs are incurred and a less mature product (hardware and soft-
ware) is obtained on each new development or upgrade/retrofit effort.

Even more serious, from an operational viewpoint, is the limited

adaptability of point-designed avionic systems to changing threat environments
or expanded mission roles for the weapon system. Past experience has shown
that the airframe lifetime is significantly longer than the useful (in the
sense of operational capability) lifetime of the avionics. Hence, a typical
weapon system is modified many times during the life of the airframe. The
Digital Avionics Information System (DAIS) was conceived as a means of avoiding
the problems inherent in the classical avionics approach. DAIS considered the
avionics job as a hybrid of process control and information management functions
and provided a system architecture independent of a particular airframe and, to
a large extent, of the technology used to implement the system. An important
aspect of the DAIS concept is that it views the avionics as a whole and not as
a collection of previously defined systems.

By using this approach, common functions of the avionics system were

identified which are required by each of the mission functions. This resulted
in an integrated avionics system which accomplishes all of the required mission
functions but is partitioned along the lines of processing hardware, software,
information transfer, and display and control. A new partitioning of the
avionics system was defined so that the mission functions could be mapped onto
that partitioning. The next step was to apply some constraints to the evolving
system architecture. For reasons of cost, maximum utilization of common hard-
ware was desired. In order to enhance redundancy and error management and
recovery, maximum sharing of information and maximum use of shared resources
were desired. This was based on the premise that if the necessary information
is available system-wide, the system can re-orientthe task of selected resources
to accomplish critical mission functions when primary resources have failed.
One of the few performance improvement constraints was to provide a better method

-3-
of interfacing to the pilot. The classical system forces the pilot to process
large amounts of raw data as well as make deciions. The DAIS approach was
to produce data for the pilot and aid his decision process, thereby reducing
pilot workload. The final constraint was to provide an open-ended system
capability. The architecture chosen should be capable of handling tasks
larger than any anticipated today and should not depend upon today's technology.
The system should be able to expand or change by adding or modifying resources
without affecting the architecture.

The topology chosen for DAIS was that of a distributed system. This
allowed physically distributing the resources to enhance survivability and
provided a means for expanding system capability without regard to physical
placement of the resources. The architecture chosen for DAIS s a hierarchical
system structure operating under centralized control. To the "user", therefrre,
DAIS appears as a centralized system. The implementation of DAIS required the
development of certain building blocks to achieve the design goals. These
building blocks are called the DAIS core elements and consist generically of
processors, multiplex equipment, control and display subsystem and the software
associated with the flight processors.

AFWAL initiated the DAIS program in 1973 with two separate contracts
to Texas Instruments (F33615-73-C-1156) and General Dynamics (F33615-73-C-1244)
to define and provide the guidelines for the design of the DAIS system. Fallow-
ing these studies, contracts to The Boeing Company (F33615-74-C-1108) and Texas
Instruments (F33615-74-C-1023) were let to provide the initial hardware and
software specifications for the DAIS core elements, and initial system designs
for DAIS.
Subsequent to these studies, AFWAL let contracts to design and develop
the core elements as shown below:

Multiplex Equipment IBM

Processor Westinghouse
Mission Software Intermetrics
Controls & Displays Hughes

Also, AFWAL let a System Integration and Test Coordination (SITC) contract with
TRW Defense and Space Systems to support AFWAL in combining these core elements,
along with support hardware and software, into an integrated test bed (ITB) or
"hot bench".

The initial part of the SITC effort was the development and demonstra-
tion of the Hardware Architecture Simulation, a DAIS prototype, to investigate
and verify the DAIS architecture. This effort provided confirmation of the
feasibility of the DAIS architecture and supplied useful inputs to the concurrent
development of t he core elements. As the core elements were delivered, they
were tested and integrated into the hot bench facility. This effort culminated
in the successful demonstration of a Close Air Support mission in September 1978.

AFWAL awarded follow-on contracts to TRW (F33625-78-R-1502) for

continued System Integration and Test Coordination (SITC) and to Intermetrics

-4-
(F33615-78-R-1542) for Mission Software Enhancements (MSE). Second generation
core element hardware was procured as shown below:

Processors Westinghouse
(dual procurement) Sperry-Univac
Multiplex Equipment IBM

In parallel and interactive with these efforts, the Air Force was
pursuing the finalization of revisions to the key avionics military standards.
These were approved as follows:

MIL-STD-1553B September 1978

(Multiplex)

MIL-STD-1750A July 1980

(processor instruction
set architecture)

MIL-STD-1589B June 1980

(high order language)

AFWAL anticipated the importance of DAIS demonstrating an implementa-

tion of these standards and extended the SITC contract to accomplish the
necessary conversions. The integration of the second generation core elements
and the conversion to the new MIL-STD's was accomplished and a formal demonstra-
tion of the DAIS ITB was performed in March 1981. The final configuration of
the ITB and efforts leading to it are the subjects of this report.

-5-

"1(
3.0 DAIS SYSTEM ARCHITECTURE

Historically, avionic systems have been established along semi-

autonomous functional areas such as navigation, weapon delivery, stores
management, flight control, communications, etc. Each of these functional
areas would have an analog or digital system with its own processing,
information transfer, control inputs, and display set. There would be an
interface between functional areas only as necessary for interaction pur-
poses, usually a one-of-a-kind, non-standard interface. The DAIS concept is
that the processing, information transfer, control and display functions be
common and service all the previously described functional areas on an
integrated basis.

These basic functions are implemented via the core elements which
are aircraft and mission independent. The specific avionics capabilities
are then achieved by selecting the sensors, weapons, and other subsystems
desired and installing the appropriate application software to control and
process the avionics data. This functional architecture is represented in
Figure 1.

The purpose of the DAIS concept is to reduce the proliferation and

non-standardization of aircraft avionics and permit the Air Force to assume
the initiative in the specification of standard avionic systems and interfaces
for future Air Force System acquisitions. This approach of isolating the core
elements, and separately developing and verifying them should also aid Air
Force suppliers by permitting them to concentrate on the specific avionics
problem by viewing the core elements as a service facility interconnecting the
application software with the sensor/subsystem hardware. The general objectives
of the DAIS architectural design are listed in Table 1 along with the design
considerations or attributes to help satisfy the objectives. These attributes,
such as standardization, redundancy, modularity, on-board test, etc., have been
designed into the system at the start as opposed to incorporation at a later
stage.

3.1 System Configuration

The DAIS configuration is shown in Figure 2. The MIL-STD-1553B

data bus is the central element of the configuration; it provides the commun-
ication link between the DAIS processors, Controls and Displays, and aircraft
subsystems. The basic core elements or building blocks of DAIS are the DAIS
multiplex system (dual bus and remote terminals) DAIS processor/BCfls, DAIS
Mission Software, and DAIS Controls and Displays.

The AN/AYK-15A processors include the bus interface/controller

function and normally reference is made to a "Processor/BCM" as a functional
unit. The Remote Terminals (RT's) receive various analog, digital, and dis-
crete signals from the sensors/subsystems and format these for bus transmission.
The RT is designed to accommodate various types of interface modules to provide
the proper electrical interface with different sensors. It is programmable to
permit mapping of the data between the data bus and the sensors as required for

-6-
 -m--- w
r - -1

Ii C La1
x I
c S

I ',I Ic, 'J

NE
Iu : I

L.-I
cz C3'

I I CD
-7--

co

a--V co Ia ca -
ci ciM

--- -- ---
 4L) 41 4-)
+- C 4J 4-) 4A
tn c 0 C U U 0 0
(L. *- 4.) L. Ii Li

In1 C
4A u 0 04-b #A 0) 0) 0 4-
o0 #V 0) : L) in u U
L>E E -o ea nL) do a fa I E
C). S- .- C In in c C 0 0
0 0. - .- 4.b 4) 4-30) 0) .- 0
I-J fo C C- U 5- 4)A 4) -
LA0) 4-2 4) - 0 r- rC0)
> .- 0n to - 'a m .- .- >
cu Ccr_ S - 0)ut ao)
I-~ nI LA- Q E
LAJ

C)

Lai 4-)
LU C

0)0
4)
U) LU 4-)
Ol C> to $-
La.J 0 0~Nto >

M. t)o L3 0 U)0-
&- - - r_ 41 4-A0
~ 'A-
~ cu) C
4)3
to
- .C
Uu
= n
0-3
.

P4 4v >11 L)-
In - u o
r-V 0 0
o
Li>
0 to ~ 4)-
o
c0 V-
to*.E C
I- - Vo R 4) c 0 4)0 ) 0D
- r_ 0 - : .0 u. 4)j
0.
CL 4)j 0c V
-0 C
r_ 0
UAJ 041): - &) c :3 :*..
o3 V) ol~c~ LL- L/) CL.
C)

ca C C1C
00

LU
o 4)
C C
u R 1.- 02.
W ~ I Lc.
1
- - 4.
E. do >1 4$
wto a 41 m4)
CD c)0 M >, m 0
En C) L.
W.0 w 00
.0 414 t c)C
41
2-- 0P
CC1r-
E 4-. > E0

-8-
 I LIJ

" II

LO

Io LL)
.60.

I 3m C-

t I WO

Us I1
the specific avionic system configuration. Sensots, control and display
equipment, or other subsystems, may interface directly to the bus, or may
interface via the Interface Modules of a Remote Terminal (Pl);. This 'lexi-
bility is provided within the communications protocol of the MIL-STD-1%'36
multiplex bus.

In normal system operation, one processor/BCM is designated as

master and is in control of the system. All bus commands are issued by this
unit under the direction of the Master Executive software resident in the
processor memory. The remaining processor/BC1s are designated as remotes and
contain mission application software appropriate for the configuration. All
processors also contain software known as the Local Executive providing basic
real-time task management and utility functions.

The Processor Control Panel (PCP) is interfaced to the multiplex bus

via an RT and provides the pilot control over what processors are active in a
configuration. The system mass memory is actually a simulation of a bubble
memory device with an embedded bus interface. Twc independent, fully redundant
RTs are used to interface the C&D system to assure availability of this critical
pilot interface. Other RTs/Subsystems are added to the confiouration as requireo
for a particular mission demonstration. The RTs may also be simulated in the
Universal Remote Terminal (URT).

It should be clear that while this specific configuration was

implemented in the ITB, the DAIS architecture is applicable to a wide range
of configurations. For illustration, a generalized DAIS configuration is
shown in Figure 3. The main point is that DAIS provides a set of application-
independent core elements. For a specific aircraft application, the system
designer is at liberty to configure these building blocks to the specific
hardware configuration required. The software can also be partitioned based
upon avionic subsystems and mission requirements such as reliability and
availability. The support software, J73 Compiler and PALEFAC, provide the
system designer and application programmer the tools to develop, test, and
partition the application software and automatically generate the executive
tables for the specific aircraft contiguration.

The number of processors can be reduced or enlarged depending upon

the avionics and mission requirements. Application-independent executive
software makes the DAIS architecture flexible and adaptable. It can be
applied to a broad class of applications, and mission-to-mission changes in a
particular aircraft are also easily accommodated. Sensors, weapons, and other
subsystems are selected as required for the particular mission. Application
modules of the software are selected or developed as required by the sub-
systems. This basic DAIS architecture reduces unnecessary development duplica-
tion of similar tasks every time new systems are developed.

3.2 DAIS Core Elements

The basic elements of the DAIS architecture, which are independent

of the aircraft and mission,are known as the core elements and consist of:
DAIS Multiplex (dual bus and RTs)
DAIS Processor/BCI
DAIS Controls and Displays
DAIS Executive Software
-10-
A
 wU

(A

LIo
C C)

LW~ LUJ LA

L'U Li

LW~ (..X C --
-'J LU
.z LL.

LnU

C -j

LUJ

Ix ex
uVw.L -12

( A
 The systeus desiqrier ruust detrioire he niuber of pr( sr/BM .
required, but otherwie ful y defines syfws fTu(t lorIal ity 'oiol I with I-
cations software irnd the suite o)f avi( 'ics sensor-s, 1 ubsytr (cci
, 0) red.
The core element, are deseribed in tte fol owirr c cr.

3.2. 1 DAIS Mult i)_lex

The DAIS multiplex provides a channel for information transfer between

the elements within the system. It consists of tne Bus Controller Interface in'.i
(BCIU) or integrated processor/bus conLroller (AN,'At'r-15A). Remote Terwinal units
(RT), and the multiplex cable assembly (data bus). The message structure, data
format, and cominand-respond protocol is as defined in MIL-STb-15u3B. The messace
format consists of three types of operations as shown in Figure 4 with word for-
mats as shown in Figure 5. The conuiunications protocol is a time division
multiplex (TDM), command-response approach with one processor/BCIU controlling
the bus traffic at any given time. Each multiplex cable assembly consists of
a twisted, shielded wire pair and bus couplers.

Message protocol is the sequence of the bus messages required to

perform system and bus control functions (synchronous and asynchronous oper-
tions) and error and failure manarement operations. A set of system control
procedures was defined to describe the urocedures to perform these operations
as summarized in paragraph 4.1. The overall message sequencing is shown in
Figure 6.

a. Bus Controller Interface Unit (BCIl}. The BCIU provides the

interface, control, and data transfer functions between a processor and two
data buses. The BCIU operates under control of the Executive software in
either a remote mode or master mode.

In the remote node, the BCIU provides the transfer of data to and
from the processor based upon commands received from either of the data buses.
it provides the status reply on the appropriate data bus, performs special
irernal operations, and Dresents interrupts to the processor for a few speci-
'ied conditions.

In the master mode, the BCIU constructs and issues the bus commands
based on a two-word instruction fetched from the pocessor memory. These
instruction words contain not only transmitting-rec-,iving terminal addresses,
subaddresses, and word count fields, but also thc fields to dictate bus selec-
tion, automatic retrv options, and BCIU internal operation codes. The BCIU
sequentially interprets each instruction oair to determine the action required.
Depending on the op-code contained in the instruction pair, the BCIU initiates
a bus operation, performs a no-op, or performs a link operation. If a bus
operation is indicated, the BCIU controls the message transmission on the data
bus. It accesses the next sequential instruction pair when the present operation
is completed successfully. If a no-oo is indicated, the BCIU accesses the next
requested instruction pair. If a link operation is indicated, the BCIU performs
no bus operation, but uses the second word of the instruction as the address of
the next instruction pair.

-12-

'S
 LJ
_* m:
l
=3 i E t
lC 9= C
ax l aM
I~ ~ ~ I.Co
-

0
ml

C)

ILJ
Ic
im,
Pn ce
ca C~o

cc V)

LaJ ca
I~I
~ LmJS
C3w
E
~Lf L.-

LjJS LU

C) a- U C

IC-13-
 CL -l cx

00 00
(~C0

C) m

LLrJ

IL.J

-n LO =

- 0r- 4 Of
cm C)
C0 0 0)79
-/ C) vi >.-~
-x co

a: L..J m
-c- I
C)-

< = U-
ce~
LAJ L0-

( w ~= U-L

Z: C)
cc cc i-o
)Low= -,
- fn cc f- Ic

C) a: C3.LJ >- L
V) CD C;) V) -i-
-L ccJJ.I--.

<~ C)

-~ - ----------
 CD)

L&J

5 L.

Lr)

Q, If
C3,

.4 -.
 Figure 7 identifies the major components that comprise a BC1.
Each Multiplex Terminal Unit (MTU) provides the interface function to one
data bus. The Processor Interface Module (PIM) provides th, interf(ace
function to the processor. The chanqing of processor types is accormodated
by a re-design of only the PIM. The Bus Control Module (BCIA) provides the
timing, control, instruction decoding, and data transfer routing requi-ed
to implement the various operations. The BCIU also performs ,;ode code opera-
tions to obtain status or built-in-test information for error and failure
analysis or to perform special mode operations as defined in paragraph 4.1.2.2.

b. Bus Control Interface Module (BCI). The BCI is embedded in the

AN/AYK-15A processor and operates in either of two modes: master or remote.
The BCI performs the same duties as the BCIU but provides enhanced status word
interpretation and interrupt code generation. Figure 8 shows the major com-
ponents of the AN/AYK-15A processor/bus controller.

c. Remote Terminal (RT . The Remote Terminal provides the interface

between the subsystems and the two data buses. The RT transfers data in both
directions between the multiplex bus and subsystem via the Interface Modules.
It receives these commands from either of Lhe data buses and provides the
status reply on the appropriate bus. The RT performs special mode conand
operations upon receipt of a mode command.

The RT is modular and programmable. This allows flexible partition-

ing of the data messages to the appropriate subsystems/sensors and signal
conditioning required by different numbers and mixes of subsystem and signals.
The RT is composed of Multiplex Terminal Unit (MTU), Timing and Control Unit
(TCU), and Interface Modules (IM) as shown in Figure 9. The Multiplex Terminal
Unit (MTU) interfaces to the data bus. It transmits and receives information
between the data bus and the Timing and Control Unit (TCU) under control of the
TCU. The RT is dual redundant with respect to the MTU, TCU, and power supplies.

The Timing and Control Unit (TCU) performs all of the timing, control,
buffering, decoding, and checking required to receive or transmit information
on the data bus. It transfers that information as outputs or inputs from the
RT via the Interface Modules (IM). The TCU contains a programmable device whiLh
controls the mapping of each data word in each message to the proper subsystem
interface, i.e., the specific IM slot in the RT and channel on that IM. The
interface between the TCU and IM is standardized and contains the signals re-
quired to allow the TCU to select the individual nodules. Therefore, all IM
slots accept all IM types.

Each RT will interface with different numbers and mixes of subsystems/

sensors signals for each specific system configuration. This is accomplished
by inserting the proper number and type of interface modules into the IM slots
in the RT housing and by programming the ROM in the TCU. Table 2 lists the
typical type of RT Interface Modules provided to interface with the subsystems.
If required, a special interface module can be designed to interface with any
existing subsystem.
The MTU and TCU functions of the RT can be embedded in a sensor or
subsystem so that the interface of the sensor or subsystem is directly with

-16-
Im

DATA BUS A T

DAT
BU B P

POWER POWER SUPPLY

FIGURE 7. BUS CONTROL INTERFACE UNIT

-17-
 L 4-

s- 4-

4-'O

CLLf

u V)

L. S- "

C>j

-U
I m
-o -jC:

Q ~ ~ C C)0.C

000 C0

4J

-Z F - < 0..
(A . nL Z
*j E~-LO r
L x- x)-

- w cu

r- S- 4-) - -

I I I I A

C-18
 LU

Lo

ceCO

=0*.

< Ln

an Ln
>-
< LI)

CD C> o

-19-

----------
 CL

.6, !:

:33

Uo
) 0.)0 C 0z
1-4-) 4-L4

CL

CL a
V)

CD,

W COM., OW-. 0

-E a

- 00)
C) CD$j-

*0 4

CC) 0)

CM IM -SA- 41 41

0.4. V)4- V) U- V) Ln V)t V

CC ~~ Ci -0)
the multiplex data bus. Functionally, the embedded RT responds to commands
received on either data buses in the same way as an RT.

3.2.2 DAIS Processors

The AN/AYK-15 DAIS processors provide computational, control,

memory, and input/output capabilities. The DAIS processors are distributed
in the architecture and are interconnected through the DAIS multiplex system.
In this architecture, the processors address only their own memory units.

The DAIS processors include the following features;

* Central Processor Unit (CPU)

* 16 general registers

* Extensive instruction repertoire

* 379K operations per second throughput based upon

a specified benchmark program

e Floating point capability

* Direct, indirect, immediate and index addressing

modes

@ Programmable interval timers

* Vectored interrupts

# Memory

* Expandable random access memory to 65K words

(16-bit words), in 16K word memory modules

* Memory parity and write protect features

o Input and Output

e Discretes

e Program controlled

* Direct Memory Access (DMA)

e External interrupts

The AN/AYK-15A integrated DAIS processor/bus controller combines the

processor and BCIU functions into an integrated unit and incorporates the MIL-
STD-1750 instruction set. Figure 8 describes the AN/AYK-15A. This integrated
DAIS processor/bus controller includes the following features:

-21-
 e Processor

# 16 general registers

e Extensive instruction repertoire as specified in

MIL-STD-1750

* 400K operations per second throughput based uoon

specified benchmark program

e Floating point capability

* Direct, indirect, immediate, base relative, IC

relative, and index addressing modes

* Programmable interval timers

@ Vectored interrupts

* Memory

9 Expandable random access memory to 65K words

(16 bits per word), in 16K word memory modules

@ Memory parity and write protect features

* Input and Output

* Discretes

e Program controlled

* Direct memory access

* External, encoded interrupts

* Multiplex data bus

* Bus controller

3.2.3 DAIS Controls and Displays

The DAIS Controls and Displays (C&D) provide the interface between
the pilot and the various avionics. The C&D consists of a set of shared
multipurpose data entry devices, control devices, and display devices. The
C&D concept is based upon an integrated set of common and shared devices which
can be used for most of the avionic functions. Thus, the DAIS Controls and
Displays concept embodies the following features:

e Flexibility to accommodate changes in avionic functions

and moding as a result of new sensors/subsystems or
mission changes without requiring a physical change in
the control and display devices.

* Efficient design for centralized system management by

the pilot as required for the system application.

-22-
 e Redundancy if required for specific system application
(e.g. CRT's serve as backup to each other, redundant
display generators) for backup of mission-critical
functions.

# Provisions for mode control and command data from data

entry devices and to display devices to be transmitted
and received over the multiplex bus to or from mission
software.

The set of Control and Display equipment developed for the DAIS demonstration
is representative of what one would utilize in the DAIS architecture. An
example of the Controls and Displays subsystem configuration is shown in
Figure 10. The units or building blocks of the DAIS controls and displays
include the following.

a. Modular Programmable Display Generator (MPDG). The MPDG is a

programmable graphic display generator. It is capable of being programmed
to generate graphics composed of predefined symbols, line segments, and alpha-
numeric symbols. The MPDG generates symbols for presentation on both raster
and stroke written display devices. The MPDG generates the display data for
up to four raster display devices via the Display Switch/Memory Unit (DS/MU)
which contains the refresh memory for the raster displays. The MPDG also
generates stroke (x and y deflection signals, and blank/unblank signals) for
one stroke display.

The MPDG generates various forms of symbology including geographic

map symbols, overlay symbols, tactical horizontal and vertical situation
data, and flight situation and director symbols as programmed in the C&D sub-
system application software. This application software executes on the
programmable processor in the MPDG.

b. C&D Subsystem Application Software. The C&D subsystem applica-

tion software consists of the routines and display lists for the display
generator in the MPDG. This software generates the display symbology, text
formats and pages, map data, etc., required for a specific avionics system
application. Mode control and data messages received from mission software
via the multiplex system controls the display modes, display assignments,
text displays, and variable symbology. The application software is commanded
by mission software. It performs the loading of the MPDG programs, text pages,
and map data from the C&D Mass Memory Unit (MMU).

The specific application software was developed using an MPDG

assembler hosted on a DECsystem-10. The source language consists of the MPDG
microprocessor instructions, display generator command formats, and assembler
directives.

c. Display Switch/Memory Unit (DS/MU). The DS/MU is used in con-

junction with one or two MPDGs to drive the raster display devices. The
DS/MU accepts digital data from one or two MPDGs, stores the data in up to
six refresh memories, and sends the data to up to four raster displays (525-
line or 875-line format).

-23-
Prn

vi~

I--

ca L" mm n L

00 Z

-24
 The raster displays are displayed ilone or overlayed with sensor
video. The DS/MU provides the capability to route signals from up to 14
sensor or weapon video sources (e.g. TV sensor - 525 line, FLIR sensor -
875 line, weapon station sensors - 525 line) to any of the four raster dis-
plays. One external video signal is routed to a single display at one time.

The DS/MU also accepts stroke-generated signals from one or two

MPDGs and routes these signals to one of the two stroke displays. Although
the DS/MU is a serial element in the system, it is designed to minimize the
probability that a single failure will cause complete loss of display
capability.

d. Display Devices. The display devices are cathode-ray-tube (CRT)

displays which are driven by the MPDG and DSMU as described above. This allows
changes or additions to the information displayed to the pilot without physical
changes to or movement of the display devices in the cockpit. The CRT display
devices consist of raster-written and stroke-written devices as follows:

* Head-Up Display (HUD) - stroke-written

* Multiple Purpose Displays (MPDs) - raster-written

The MPDs can be used for Vertical Situation Display (VSD), Horizontal
Situation Display (HSD) and Multi-Purpose Displays (MPDs) as required by the
specific avionics systems configuration. All the MPDs are identical except for
the legends on the display selection buttons. The Head-Up Display (HUD) pre-
sents the symbology (e.g. cues, flight information) in the pilot's forward
field-of-view, so out-the-window scenes (e.g. targets, IPs, etc.) can be viewed.

e. Data Entry Devices. The data entry devices provide flexibility

in the information which can be entered by the pilot to control and manage the
specific avionics system (mission functions, sensors, and subsystems). The
design of the data entry devices allows changes or modifications to the
avionics functions without physical changes to the cockpit. The output of the
data entry device is received and interpreted by Mission Software via the
multiplex system. Display responses to the device are generated by mission
software via the multiplex system. The type of data entry devices include the
following:

1. Integrated Multifunction Keyboard (IMFK). The IMFK consists of

a programmable alphanumeric 280 character display, seven master function push-
buttons, and ten submode select pushbutton switches, five on either side of
the display. The IMFK display is capable of displaying ten rows of characters
divided into three columns (nine characters in left and right columns, and
ten characters in center column). The display information is generated by
mission software. The pushbuttons generate a request via the remote terminal
for thea master executive to asynchronously service and transmit the data to
the appropriate processor. Application software interprets the pushbutton
or switch action and provides the appropriate response.

2. Multifunction Keyboard (MFK). The MFK consists of seven master

tunction pushbuttons, ten submode pushbutton switches, and ten indicator
lights. The MFK interfaces with mission software via the RT in the same way
as the IMFK. It can be utilized for specific control and display functions
or as a backup for the IMFK.

-25-

- •
 3. Data __Entry _Kyboard (!EK) The DEK ::rovides *h: 1,ilo t ,h
means of entering numeric and limited alpha data i to mission software vit
the multiplex data bus. The n' K ste.res did di ,nlav up tq ter ,ha ra
When the enter key is depressed, ci' juest for- tArv ice, via the RT is r ace
to the master executive. Upon veceivi gi te data, Mis'.ion Software inte'r--
prets the data dependinq upon the se I,"c ted suhmode ,via the 71Fv ' (,r MFK.

f. Control Devices. The Controls ,nd Displavs subsi/ste, also

provides several -coi-tro1 devices as follows:

1. Sensor Cont-ol U it ISCU). Th( SCU provides fo, selection and

position controT of a jibo or sensor (X and Y directions). The hand con-
troller is a force control with D,_voltage outt.ui whi, h i , ropu,_,-t Icm& to
the force in the X and Y directions. The SCU also provides tr-.ger and swvitch
discrete outputs. These outputs are traismitted to missior, software via the
multiplex data bus; mission software drives the }p. -o:.r'atc sylol or sensor
bised upon the selected mode. The SCI; .o d cntrol -Ch t(, c-T'
cursor brightness.

2. Armament Panel (APj. The armiament ,ariel pr(uvides switch, fov

weapon armament control Tbombing, fusi.ib , .-
Jun firing, and Jettison).

3. Master Mode Panel (MMP. The MMP :unsists of fifteen f'astet

mode switches. Each has an indicator li(iht atd HUP-ielatcd switches and con-
trols. Phen a master mode switch is depr'essed, v tequest fcr :ervice will be
made to the master executive. 11non receiving the data, - ision software ... e -
prets and responds to the selec-ed maaster mode.

The interface between the pilot and the integrated set of Controls
and Displays is dependent upon the specific avionic mission and system con-
figuration. The system designer selects the set of integrated Controls and
Displays required for the specific avionic system and cefines the pilot
sequences and display responses requited to control and mode the avionics
system.

The interface between the Mission Software and the C&D applicatior
software in the MPDG is also mission-and application-dependent. This inter-
face is defined by the data bus me-sages from Mission Software to the MPDG
to perform the following functions:

* Load the MPDG

* Control display (VSD, MPh, HAD, & HUD) assignment

* Control display modes

e Provide data to drive th' display symbology, e.g.

elevation, altitude, heading, etc.

* Provide text data

-26-
 With increased avionic and mission complexity, the role of the
pilot is changing to that of a total system manager. Mission Software can
perform the systems management function, collecting information and con-
trolling a functionally integrated set of subsystems and sensors, to reduce
the pilot workload. Functions such as subsystem checkout and monitoring,
data computation and reduction, routine sequencing within mission modes, and
mission and aircraft data storage can be performed by the mission software
with minimum pilot intervention. Operation by exception can be designed
into the system control and operation.

For example, the pilot can use the integrated Controls and Displays
to mode the avionics system throuqh the Mission Software applications func-
tions. He receives display information about the mission and avionics
system operations from the software. The control devices permit the pilot to
establish the operations to be performed by the software functions. The
master modes set the display devices to prescribed formats via Mission Soft-
ware and the MPDG. The pilot, however, can override these normal operations
to either cause alternate modes or activate operations not required by the
selected master mode.

Master modes are defined for specific phases of the mission where
certain normal operations are active. Upon entering a new master mode, some
previous operations are terminated as new ones are activated. Manual modes
previously selected by the pilot can be retained if compatible with the new
master mode. If the new master mode requires a system that has been"deselected"
using the manual mode, the pilot is alerted through display exception messages.
The Master Mode Panel, as labeled for the specific mission applications, permits
the pilot to select these prescribed master modes. Mission software, in res-
ponse to the selected master mode, will command the C&D application software to
generate formats for the various displays (HUD, VSD, MPD, et,.). The pilot can
9verride the preprogrammed mission functions through the IMFK-displayed pages
and side keys which are also handled by mission software. The pilot will also
be able to enter information into Mission Software via the DEK. For the DAIS
demonstration, a representative set of master modes and mission operational
sequences were defined and implemented under control of mission C&D application
software. The requirements for these modes are defined in a Pilot/Operational
Sequence Interface Control Document (ICD).

3.2.4 DAIS Mission Software

The DAIS Mission Software (MSW) is the set of programs which support
and perform the avionics functions required for the DAIS Close Air Support (CAS)
mission. To control and perform these functions, the MSW contains both Execu-
tive and Application Software.

3.2.4.1 Executive
The executive is the operating system for MSW. It is organized into
the local executive and the master executive.

-27-
3.2.4.1.1 Local Executive

Each DAIS processor contains a local executive. The local execu-

tive software is table-driven. It performs the following functions:

1. Process Control - provides services for the application

software to activate and deactivate periodic and non-
periodic tasks when appropridte conditions have been met.
These conditions are based upon logical ettings (on or
off) of real-time events.

2. Event Control - provides the mechanism for setting,

resetting, and evaluating real-time events which commun-
icate conditions (on or off) signalled between tasks in
the same or different processors.

3. Data Control - guarantees integrity of shared data and

provides mechanism for transmission and reception of
data over the multiplex bus.

4. Processor Initialization - provides initialization for

processor power transient recovery, initializes program
loads, and performs minor -:ycle synchr, nizatic,q with the
pther processors.

3.2.4.1.2 Master Executive

One of the DAIS processors contains the master executive. The

master executive is table-driven. It manages the system configuration by
performing the following functions:

1. System Synchronization Control - allocates time segments

(minor cycle and major cycle) for synchronous messages
and performs minor cycle synchronization by transmitting
minor cycle master function mode commands to the other
processors.

2. Bus Control - controls transmission of synchronous and

asynchronous messages over the multiplex data bus.

3. System Error/Failure Management - !initors and analyzes

errors and failures on both bus and termiinal devices.
Initiates message retry procedures to recover from
message errors.

4. Configuration Management - detects and isolates permanent

device failures, maintains system configuration status,
reports failure to the application software, and initiates
backup or recovery operation if required.

5. Mass Memory Management - provides for retrieving and

storing information from the mass memory on request.

-28-
3.2.4.2 Applicatio, Software

The application software performs the tasks associated with the

avionics requirements of the mission. The application software is divided
into eleven functional areas.
e Navigation
* Guidance
* Weapon Delivery
* Position Update
* Display
9 Miscellaneous Functions
* Stores Management
9 Pilot Control
e System Control
* Common Subroutines
e System Functions
Table 3 lists and briefly describes all the programs in each of
the functional areas.

3.2.4.2.1 Navigation
The navigation software computes aircraft position and velocity
and related information used by the pilot and by avionics algorithms. The
Navigation programs include three navigation modes (INS, Dead Reckoning,
and TACAN), associated programs, and programs to interface with the appro-
priate avionic sensors.

3.2.4.2.2 Guidance

The guidance software computes flight path deviations and handles

pilot requests. It calculates and displays to the pilot information needed
for steering. The guidance software provides the six steering modes: Command
Track, Command Nav, Command Heading, Command Altitude, ILS, and TACAN.
3.2.4.2.3 Weapon Delivery

The weapon delivery programs perform the calculations to aid the

pilot in releasing weapons. Variables such as ejection angles, range-to-
target, miss distance, stick length, and bomb-fall-line are computed and dis-
played. Two delivery modes, CCIP/Auto and CCIP/Manual, are available.

3.2.4.2.4 Position Update

The position update programs in conjunction with the weapon delivery

range algorithms allow the pilot to update the aircraft position based on known
waypoint or target positions. Three position update modes are available:
INU HUD update, Flyover update, and FLIR/Laser update.

3.2.4.2.5 Display

The display software presents information to the pilot in the cockpit.

It controls data sent to the MPDG's and the IMFK and MFK. It provides specific
display messages to drive the symbols and graphics on the DAIS displays.

-29-
 ,,_ TABLE 3. APPLICATION '01 IWARF. PROGRAMS

FUNCTIONAL AREA APPLICATION SOF]vAi-J DESCR!PTION

Navigation SP01NAVCONFROL Navigation coritrcller

SP02NAVPARMS Calculates flight parameters
from INS data
SP03NAVINS Interfaces with INS and computes
wander angle, latitude, iner-
tial velocity
SP04TACANNAV Calculates latitude, lonq tude,
velocities using TACAN

SP05DRNAV Implements Dead Reckoning navi-

gation
SP06ALIGN Controls timing of INS alignment
SP07NAVDATA Computes transformation inatrix
SP08TACSEI. Selects TACAN station to be used
in TALAN Area Navigation
QP0IINSOUTMODE Outputs mode and power to INS
QP021NSOUTDATA Outputs barometric altitude to
INS
QP031NSOUTUPDATE Outputs direction cosines and
lonqitude to INS
QP041NSINDATA Inputs INS data

GUIDANCE SP10STEERCONTROL Guidarce :-ontroller

SPIISTEER Main task of steering function
SP12DESTINATION Changes command nay steering
destination
QP15TCNOUT Outputs mode and channel select
to TACAN
QP16TCNIN Inputs TACAN range, bearing,rang=
rate, status
QP20ILSOUT Outputs Power and frequency to
ILS
QP21ILSIN Inputs glideslope and localizer
deviation

WEAPON DELIVERY SP40ATTVEL Calculates air mass velocity and

ejection angles
SP41WDCONT Weapon Delivery controller
SP42AIMING Controls aiming reticle
SP43FLR FLR (Laser Ranger) pointing
angles
SP44BALLISTICS Ballistics algorithm
SP45WPNRANGE Sets steering modes and in-range
flags
SP46SC Solution cue position
SP47BFL Bomb fall line parameters
SP48PD Positions the pull-up cue
SP50CCIP Solution cue for CCIP manual
SP51WDINIT Initializes weapon delivery
software

-30-
 TABLE 3. APPLICATION SOFTWARE PROGRAMS (CON'T)

FUNCTIONAL AREA APPLICATION SOFTWARE DESCRIPTION

WEAPON DELIVERY SP52RANGING Computes target range

(CON'T) SP53RELEASE Time-to-release
QP50LSRINRNG Inputs range and status from
Laser Ranger
QP51LSROUTDATA Outputs data to Laser Ranger
QP55SCUIN Converts SCU data into internal
format

POSITION UPDATE SP90POSUPDATE Coordinates pilot slewing the

aiming reticle and designat-
ing to perform a position
update
SP91POSUPDATECONTROL Position update controller

DISPLAY OP01MMPLIGHTS Changes MMP light state

DP021MFKLIGHTS Lights the IMFK Brute Force keys
DP03MFKLIGHTS Lights the MFK Brute Force keys
DP04PAGE Displays entire IMFK/MFK page
DP21MPDG Synchronous DISP for messages to
MPDG
DP23MPDGDISPLAYASSIGN Formats and sends data to MPDGs
DP24MPDGWPTINIT Initializes waypoints for MPDG
DP25MPDGTABLDISP Sends message to MPDG1
DP30FLASHSYMBOLS Controls flashing
DP52STORESTAT Changes MPDG stores option format
DP60BLINKFD Blinks the flight director
DP51MAPUPDATE Determines which map data blocks
are needed
QP71SCUDEKOUT Output lamps, DEK activity,
display power

MISCELLANEOUS SP20ADCOMP Air Data computations

FUNCTIONS SP21WIND Computes wind velocity
QP25RDRALTOUT Outputs power and test bits to
Radar Altimeter
QP26RDRALTIN Inputs Altitude and Status from
Radar Altimeter
QP40ADIN Inputs Air Data
QP43UHFOUT Outputs frequency and mode to
UHF
QP49GEARIN Inputs aircraft status

STORES SP70STORESCON Stores management controller

MANAGEMENT SP71STORESCON1 Deactivates weapons
SP72MK82CON Controls MK-82
SP76PJETT Performs programed jettison
SP77EJETT Performs emergency jettison
SP78STORESINIT Brings loaded stores to quies-
cent state
QP60ARMIN Inputs armament switches
QP80MK82 MK-82 control
QP81STAlREL Station 1 Release
-31-

'.

Ll '
 TABLE 3. APPLICATION SOFTWARE PROGRAMS (CON'T)

FUNCTIONAL AREA APPLICATION SOFTWARE DESCRIPTION

PILOT CONTROL CP03MMPREQPROC Handles MMP Pilot requests

CP041MFKREQPROC Interprets IMFK key inputs
CP05MFKREQPROC Interprets MFK key inputs
CP07HANDLER Carries out actions when IMFK
side key is pressed
QP70DEKlIN Inputs data from DEKI and DEK2

SYSTEM CONTROL CP0IMASTSEQ Initializes application software

CP02CONFIG Sets up application software
configuration
CP11WOGSIMKEY Weight-off-gear simulated key
producer
CP12FLYTOSIMKEY Fly-to-point simulated key
producer
CP13WHLSIMKEY Wheels down simulated key
producer
CP14FLAPSIMKEY Flaps set simulated key producer
CP15MMPILLSIMKEY MMP illegal simulated key pro-
ducer
CP16MMPNIMPLSIMKCY Non-implemented timulateo key
CP17WONGSIMKEY Weight-on-gear simulated key
producer
CP18OFFFPSIMKEY Off-flight-plan simulited key
producer
CP19TO2DIMWPTSIMKEY To 2 dimensional waypoint simu-
lated key producer
CP20OUTBNDSIMKEY Outbound intercept simulated key
producer
CP30VTOFFGEAR Take-off/Climb simulated key
Droducer
CP40MMCOPY Copies Master Mode
CP50DISPCONTROL Activates CP07

COMMON ALTSET Formats reference pressure for

SUBROUTINES :MFK
BINARY Performs binary searcn
CNTRST Formats weapon station informa-
tion
CONVER Converts radians to degrees and
seconds
DEGREE Converts radians to degrees
DENORM Converts floating point to
fixed point
ELEVDH Formats IMFK legend
FLOATF Converts floating point to ASCII
FLYTOF Formats the fly-to display
FUZLNG Formats the fuzing for display
ILSCHN Formats the ILS CHNG IMFK ,egend
INTERV Formats the interval for the IMFK

-32-
 TABLE 3. APPLICATION SOFTWARE PROGRAMS (CON'T)
FUNCTIONAL AREA APPLICATION SOFTWARE DESCRTPTION

COMMON SUB- JETPAG Formats the jettison programs

ROUTINES (CON'I LATLON Converts radians to character
display
LIMIT Limits an integer to a specified
range
LIMITF Limits a floating-point to a
specified range
MAGVAR Formats the magnetic variation
MODEFO Formats the weapon delivery mode
MTXV Multiplies matrix transpose
times a vector
MXV Multiplies matrix times vector
MXM Multiplies matrix by matrix
NORMAL Normalizes a fixed-point number
OFFSET Formats the offset for display
QUANID FormaLs the quantity/weapon ID
REVERS Reverse the bit pattern
SMOOTH Performs first-order lag
smoothing
STATIO Formats the stations
TCNCHN Formats the TCNCHNG legend
TRANSP Performs matrix transpose
S15ENC Converts integer to ASCII
UHFCHN Formats the UHFCHNG data
VADD Adds two vectors
VDOT Performs dot product
VUPDATE Performs vector operation
VXV Multiplies two vectors
WINDSE Formats the windset display

SYSTEM FUNCTIONS SIN Sine

COS Cosine
SIND Sine (de, s)
COSD Cosine (dL _.es)
ASIN Arc sine
ACOS Arc cosine
ATAN Arc tangent
SINH Hyperbolic sine
COSH Hyperbolic cosine
TANH Hyperbolic tangent
MAX Maximum
TAN Tangent
LN Natural logarithm
LOG Logarithm
SQRT Square root
EXP Exponential
ATAN2 Two-argument arc tangent

-33-
3.2.4.2.6 Miscellaneous Functions

The miscellaneous functions include wind and air daLa calculatiuns.

They also provide interfaces with the 3)r datd sensors, tnt(radar altimeter,
the UHF radio, and the gear.

3.2.4.2.7 Stores Management

The stores management software maintains invento - of the weapons
on board the aircraft. It keeps track of the number and type of weapons as
well as their state.

3.2.4.2.8 Pilot Control

The pilot control software responds to the pilot's rvquests and invokes
the appropriate application functions that generate information for displays
or for controlling avionic support subsystems.

3.2.4.2.9 System Control

The system control software scnedules and controls the application

software.
3.2.4.2.10 Common Subroutines

The common subroutines (COMSUB's) are a set of reentrant programs.

They perform mathematical operations such as matrix multiplication as well as
data manipulations such as reformatting.

3.2.4.2.11 System Functions

The system functions include the mathematical and trigonometric

functions such as sine and square root.

3.2.4.3 Mission Software Architecture

The mission software is modular and flexible. .It can accommodate

mission-to-mission changes as well as changes in the complement of avionic
sensors. It allows for modification of both the executive and the application
software which greatly facilitates implementing the DAIS architecture on other
aircraft.

The application software is organized in a hierarchical control

tree structure. Each program is either a controller or a calculator. A
controller schedules a particular set of calculators. Each controller is,
in turn, scheduled by a controller at a higher level.
The master sequencer is at the top of the application software
hierarchy. It controls the request processors,configurator, and subsystem
status monitor. This master sequencer is only required in the master
processor.

-34-
 The configurator schedules the remaining tasks. It defines the set
of application functions to be invoked by request from the request processors
or the subsystem status monitor. It also generates a new set of available
functions upon significant chanqes in mission phasing or equipment moding.
This set of functions is based on a global knowledge of overall system status.

The structures described above are further divided into modular

components. Each component is a closed program, that is a program with only
one entry and one exit point. In addition, each program is under control of
a program at the next higher level of the hierarchy. Also, the components
isolate separate hardware functions; this localizes the impact of equipment
changes and allows for mission-to-mission system changes.

Structured programming techniques are used to increase reliability

and understanding and to eliminate intricate logic that is difficult to
validate and verify. Only closed logic structures--logic structures which
have a single entry point and a single exit point--are employed in the con-
struction of program components. To further emphasize standardization and
understanding, the higher order language JOVIAL J73 is used for development
of the Mission Software. JOVIAL is not used for those portions of the program
where computer time must be minimized or a high degree of numerical accuracy
is required or interface with processor or bus controller hardware is performed.

3.3 Other Elements

3.3.1 System Mass Memory

This optional subsystem supports the DAIS capabilities to load/

reload program modules. In the ITB, it is actually a simulation of a bubble
memory device. The simulation is implemented in the universal remote terminal
(URT).

A fixed RT address is required for the system mass memory in order

for it to be accessed by the bootstrap routine during startup. The system
mass memory has four basic operations, as follows:

Address Select - to set a starting address for the

mass memory and specify if synchronous or asynchronous
operations are to be performed. Also to set read mode
or set write mode.

Address Retrieve - to obtain the current (i.e. next to

be accessed) mass memory address and settings of the
Read/Write and Sync/Async flags.

Read - to transfer data from the mass memory and advance

the current address by the number of words transferred.

Write - to tr, nsfer data to the mass memory and advance

the current address by the number of words transferred.

-35-
 The format of the messages associated with eacni of the basic
functions is shown in Figure 11. In this example, Receive (T/R=O) sub-
address 17 is used for Address Select; Transmit subaddress 17 is used for
Address Retrieve; Transmit subaddresS 18 is used for Read; Lrid Receive
subaddress 18 is used for Write. lhese are, of course, arbitrary choices
that may be changed by the system designer. The significant point is that
the startup program must know the bus address of the mass memory and the
subaddress of each function.

These messages have some bit definitions unique to the system

mass memory. The sync/async bit in the address select command tells tne
unit whether or not the Last Connand Word is to Le included as the first
data word of a Read operation.

The read/write bit, also in the Address Select message, specifies

whether subsequent operations will be writing data to or reading data from
the system mass memory. This information is required to properly manage
data buffers internal to the interface. It also provides a first level of
security, reducing the chances of inadvertent data destruction.

To meet the multiplex bus response times, a buffer interface is

necessary. Further, the buffer size is selected so that the time to load
the buffer from the memory device is less than the time to transmit the
buffer contents over the multiplex bus. A standard double buffering tech-
nique can then support a continuous data flow and no delays need be encountered
after the initial access.

The bits defined in the status word provide the Master Executive
or Startup Loader with information on why the most recent operation %,as not
successful. These are interpreted as follows:

ME - Message Error - indicates data was not received

correctly off the bus. The data has not been
accepted, and the address has not been advanced.

BSY- Busy - indicates the data transfer could not take

place; e.g., buffer full, access in progress.

TF - Terminal Fail - indicates an unrecoverable device

error occurred on the most recent operation.

The system mass memory is not to be confused with the C&D mass
memory unit (MMU). The MMU is a component of the C&D subsystem though a
system designer may opt to implement these logically distinct units on a
single physical device. (In this case, the interface unit would be required
to resolve any access conflicts internally in a manner transparent to the bus
operations.)

Alternatively, a specific implementation may choose to economize by

omitting the system mass memory, thereby foregoing the inflight reload capa-
bility.

-36-

• .
 IL
IV
CL C:)

00
a 00

(/)

LU

L=

4
-37-i
 c2 we C

CD C) 'X
a~ 4

UJ ix

lal la
> 0 0

~ 35>

w)w~

0
Me a

om t

033

LOU

a- I o
w
ww

020

-38-
Il

3.3.2 Processor- Control Panel (PCP

The Processor Control Panel provides switches to scparately enable

power to each side (A arid B) of the multiplex system and to each of the pro-
cessors. Two toggle switches and two push buttons provide the pilot control
over system load and system restart operations.

The advisory caution panel (ACP) provides a display of hardware and

software status during the startup process. This is shown in Figure 12. The
two panels are normally referenced together as the PCP/ACP. The lamp test
button on the PCP provides a local test of all lights and backlighted push
buttons on both panels.

3.4 Non-Real-Time Support Software

The DAIS non-real-time support software provides the tools to

develop, generate, test, and partition the mission software for the specific
avionics configuration. The non-real-time support software includes the
JOVIAL Compiler and the Partitioning Analyzing and Linkage Editing Facility
(PALEFAC).

3.4.1 JOVIAL Compiler

The JOVIAL Compiler is a program which translates high-order-

language source code into object code. Two versions of the JOVIAL language
and, therefore, two versions of the JOVIAL compiler were used in developing
the DAIS mission software. Mission Software was first written in JOVIAL
J73/I. In 1980, all Mission Software was converted to JOVIAL J73. Both
versions of the compiler serve the same function and fill the same role in
the DAIS system architecture.

The JOVIAL compiler generates object modules which can be loaded

and executed on specified target computers (such as the DAIS processors or
the DECsystem-lO computer). The JOVIAL language is machine-independent.
It uses self-explanatory English words and familiar notation for algebraic
and numerical computations and logical operations. The JOVIAL compiler pro-
vides a common, powerful, and easily understandable programming language for
a wide range of applications. The compiler provides a capability for sharing
data among interdependent programs or tasks through a communication pool
(compool).

The JOVIAL compiler is designed to be easily retargeted to produce

object code for a new and unspecified computer. It is also designed to be
easily rehostable to another host computer. Initially, the compiler was hosted
on the DECsystem-1O computer system and targeted for the DAIS processor and
DECsystem-1O.

The structure of the compiler is shown in Figure 13. The system

programmer generates the source input and compool input files. The programmer
then compiles the source program using the compiler which produces source
listings, cross references, object listings, and the relocatable object files
for the selected target computer.

-39-

4,
 0 z

__~ 7FJf
~~ -- li,7
--- L2
-------- '~..

0 _r

-40-
 -n 0. a- A

CI

LULU

4t-

ix LAU
LAJ -f

ICL C) 0A
Cl L. QI V

r LLr w

LLJ 13 tALL)

V) < 51 (L

I-) cLnL-) c C

LillI

L.LW

LAA
 The output of the compilation is a relocatable object file. ,
order to execute the program on the DECsystem-iO, the object file :;ust be
converted to core image form using the DECsystem-10 (LINK-IO) li;ver/loader.
In order to execute the program on the DAIS processor, it must be converted
to core image form using the HBC linker/loader.

The JOVIAL Programmer User's Manual provides definition of the J73

language, properties, and statements including examples of how to write a J73
program. The guide also presents a syntactic description of the languaoe
elements with examples and necessary information for the user to write, co,.-
pile, load and execute programs on the target computers.

3.4.2 Partitioning Analyzing and Linkacle Editing FacilityFPALEFACL_

PALEFAC is a non-real-time support software tool for use by the

system designer and application programmer to:

1. Build the data tables for the DAIS local and

master executives.
2. Provide bus analysis and module partitioning
information.

3. Produce the exe,.utive tables in J3/ source code.

4. Generate linker cor.-,and files for each DAIS prc-

cessor for the DECsystem-10 Linker or DAIS
Processor Linker.

PALEFAC is used as a stand-alone tool. PALEFAC consists of three

basic programs, as shown in Figure 14: PALEFAC pre-processor, PALEFAC main
,,'ograrT, and PALEFAC module input (PMI decoder.

PALEFAC is used to build the 'mission software load modules for each
of the DAIS processors. Inputs to PALEFAC are the Application Software mod-
Pies including the executive service requests generated by the application
programmer in J73 source code. The pre-processor reads each application module
and creates a record for each application module in the PMI file.

The system designer prepares a PALEFAC Global Input (PGI) file based
upon the specific system confiuration, partitioning of application tasks to
each processor, and bus messanes to each terminal. This would include:

a. Bus Messages

* To/from data block name or Terminal Address/

Subaddress

9 Cycle (period and phase) for synchronous

transmissions

9 Activity request identification for asynchronous

transmission

-42-
 La
4A
LLI C)
-X. ci -~ )4

4A <~ L) .La>a=
LA-~ L)

0. u U w oC
< La3 LL- CDj -j a..J
-. La- 0
.. La W.. = =

C) S L
LLJhJ
s

(a LL U

-oJ-
cn < co
a.J I

0 0 0 0
P.C 2

cc a

-a-

-cc L ui i -C
0- :E w
-c I U m--LV) C-)lC

-43
 e Word count

e Class for ':saoe error retry

b. List of all tasks or modules for eachi processor

c. Override directives

d. Number of processors in the sy,te&! confi(iuration and

address of each terwinul

The system designer also generates the PALEFAC Auxiliary File (PAL) for common
subroutines (comsubs) and comn;on coT1urication data blocks (compools).

The PALEFAC main progran: builds the executive tables and linker
command files based upon the system designer specified configuration. The
output of PALEFAC is the PALEFAC mission files (PMD), PALEFAC Partitioning
Information Files (PPI), and test output files shown in Figure 11. The PMD
files contain all the executive tables including the bus control tables in
J73 source code. The PPI files contain toe linker commands for each pro-
cessor and specify all the mission software moduies (e.g. executive modules,
application tasks, comsubs, and executive table,! in urder for the linker to
produce the load modules for each processor. PAL[FAC also produces text
output files listing all the PALLFAC input filec, t e cotpuf files, and error
messages.

3.4.3 Assemblers/Linker

ALAP is a retargetable assembler written in Fortran IV and hosted

on the DECsystem-1O computer at the AF Wright Aeronautical Laboratory. The
assembler can be retargeted to a variety of machine languages. Its function
is to translate assembly language scurce into object !)odules which can be
loaded and executed on a specified target computer (e.g. AN/AYK-15 processors.
AN/AYK-15A processors, DECsystem-10 computer) or into relocatable files for
further processing by LINKS.

LINKS is a target-independent linker written in Fortran IV and

hosted on the DECsystem-1O computer at the AF Wright Aeronautical Laboratory.
Its function is to combine relocatable files proouced by the ALAP assembler
and/or the JOVIAL compiler into a single object file ready for execution on
a specified target computer.

-44-

"l , AL'
, '
4.0 DAIS SYSTEM CHARACTERISTICS AND FEATURES

The performance characteristics of DAIS include system functional

control characteristics as well as system architecture features and attributes
included in the design of DAIS core elements. These sections address the system
control features and the primary characteristics which are unique and important
to the DAIS concept.

4.1 System Control Procedures

The DAIS architecture and integrated system design result in a

special set of functional requirements, designated system control procedures,
which include system startup/restart, control of the bus communication, and
utilization of redundancy in the event of core element failures. The system
and bus control functions are distinguished from mission avionic functions
which support the specific mission tasks. The mission avionic functions are
composed of navigation, guidance, weapon delivery, communications, target
acquisition and track, stores management, and subsystem management.

Another important group of functions, on-board tests, utilize both

hardware and software to isolate in-flight failures. This allows utilization
of redundancy, maintains a complete updated status of every equipment on the
system, and provides isolation of failure to LRU levels with a minimum of
duxiliary group equipment.

4.1.1 System Startup/Restart Operations

The overall objective of the system startup/restart procedures is to

give the pilot control of the system configuration and to provide a verification
of the hardware and software prior to entering normal system operations.

The pilot controls the system via the Processor Control Panel (PCP).
The power enable switches allow him to remove a processor from the system by
powering it down. The GROUND position of the startup switch permits him to
specify an initial startup as opposed to a restart, indicated by the INFLIGHT
position. The START button permits him to request the use of software already
loaded, while the LOAD button allows him to force the reload of all software.
Of course, the LOAD function is supported only when a system mass memory is
configured in the system.

In addition to the pilot-initiated restarts, the system will, under

certain limited circumstances, perform an automatic restart. It is essential
that an automatic restart have minimal impact on continued system operation.
This consideration defines the need for a "warm start" initialization of soft-
ware as opposed to the "cold start" associated with normal system startup.

"Cold start" assumes a fully operational configuration. It involves

the complete initialization of executive and application software and the
assignment of initial values to events and data.
"Warm start" continues the current operational status. A partial
initialization of the executive is performed, current data is maintained, and
application tasks and events are assigned to a known, predetermined state.

-45-

t o u t u
" Warm s
 The various startup/,estart cases are summarized in Table 4.
As is evident from this table, it is important the pilot sot the startup
switch before powering up the prucessors. Otherwise, the power-vs would
look like a transient recovery. Conversely, the pilot must return the switch
to the INFLIGHT position at the completion of a normal startur). Failure to
do so would allow a transient to brino the system to a stop.

4.1.1.1 Normal System Std rtup

Each processor is equipped with a read only memory (ROM)*, which i

enabled when the power up condition is detected. The ROM contains sufficient
instructions for the processors to perform self tests, determine the integriti
of loaded software and arbitrate control of the multiplex bus. The ROM may
contain additional functions as desired for any specific implementation, but
normally considerations of stability and size would indicate only essentials
should be in the ROM. The minimum ROM contents are dictated by the requireenrt
that the ROM be capable of starting or 'estartinc i system without a systen
mass memory.

As each processor senses power-up, it enables the ROM and begins

executing at location zero. Memory protection is established, interrupts
are cleared, and self tests are perforrmed on the nrocessor/BCM.

At the completion of self tests, sof~ware is verified and one orocess,-

is established as controller of the multiplex bus. The ether processors rerai,
in remote mode, prepared to transmit the results of self tests and software
verification. The controller polls all possible processors for this informati
to determine the configuration to be run. A processor is included in the
configuration if it passed self test ond it successfullv communicates on the
multiplex bus.

Software verification/loading is the final phase of the startup pr,-

cess. Based on the configuration which is operatioral, the system loader
accesses a startup configuration table to determine the load module required
in each processor. If the required software is not nresent, it is loaded from
system mass memory, and the verification process repeated. When it is confirmee
that all processors are properly loaded, the controller directs each processor
to perform initialization. The controller then enters its own initialization
and normal system operation is begun.

4.1.1.2 System Warm Start

System Warm Start is designed primarily as a response to a system-

wide power transient. The objective of a warm sta~t is to resume operations
as quickly as possible. The procedure starts what it finds and verifies
in the processors' memory and does not perfor, reloading. The pilot will be
alerted if a runnable set of software is not found.

The ROM, in effect, overlays the first four thousand words of memory while
invoked. This is a feature of the AN/AYK-15A processor and, since it is
the preferred implementation, the startun procedures are described in this
context. With the AN/AYK-15, or other processor not equipped with a ROM,
the startup software must be permanently preserved in low memory and memory
protected except as required when modifying interrupt vectors.
-46-
 LU LU
w I- 'r-
-- .IX <

~ :tJ I 2z :

CD)V

:i LU 0 ~ ~ L ~ L

u A CD I- -J V:I) 0) F-
LU L - -J (n LU C3 Lw- >- -.J V)

(A1 -1 cc()
CO LU U C -c LU 0 0) Uj LU )
-~> =* :2 -
V:~ I 3LC.)
c2
Ln V) Vd)
0.. >. >- .
0) ( 0 0S L) 0 0 U) S S S

LU

F-

I- = =
(A CD-
I--- 0-

F- C 0

0L L -i 4x Of U)
(A
<) LUC>C
03 -1 L) R F0l

C3 w
2:J a))2u
0- ) V) j ot LUC

-47-
 As power is restored to each processor, it will enter !he ROIA,
perform self tests, verify software and build startup status irtornation as
in normal startup. The absence of any bus activity permitc one of the
processors to assume control to manage the warm start. The fact that it is
a warm start is determined by the INFLIGHT position of the start switch and
the absence of the discretes for both the start button and the load button.

The startup configuration table defines the acceptable ronfigurations

for a warm start in their order of preference. This information, along with the
module ID's required for an initial load, is kept in the fixed information table
in each processor to facilitate quick transient recovery. If the procedure
cannot find the configuration matching the initial load (which by definition is
the most preferred configuration for a warm start) it then goes through the
restartable list trying to find a configuration in which each of the load module
ID's can be found in some processor.

Should no restartable load set be found, the pilot is alerted by

the master caution lamp. The startup process is then recycled to the point
of reading the PCP prior to identifying the configuration. The procedure
will, therefore, automatically detect a processor that recovers from a power
transient much slower than the others. It will also respond to new direction
from the pilot via the PCP.

4.1.2 Normal System Operation

In normal system operation one of the processors, designated the

master processor, contains the master executive and controls the bus. Each
of the remaining processors is designated a remote processor and each contains
a local executive. Application software is distributed among all the processors.

4.1.2.1 Bus Control Operation

Bus control operation is concerned with the control of the bus messaqe.
l
and sequences as defined in MIL-STD-1553B and as shown in Figuye 6. The contro
of bus traffic operations provides for major/minor cycle synchronization, which
is maintained via transmission of minor frame (synchronize mode command) messages
to each remote processor, and provides for both synchronous and asynchronous
bus communication.

The synchronous bus traffic is controlled by a predefined bus command

list. Asynchronous messages, which are predefined, are scheduled by the master
executive based upon requests from terminals or application tasks. In addition,
the bus control operations themselves may generate asynchronous messages in
managing exception conditions.

In general, asynchronous operations are given priority over synch-

ronous operations. A more complete breakdown of the priorities (I is the
highest priority, 6 is the lowest) is included in the summary of bus message
operations, Table 5.

Message protocol is defined as that sequence of bus messages re-

quired to perform the normal multiplex synchronous and asynchronous operations
and to support the error detection and recovery process. In order to insure

-48-
 an 0 a1
CO .. cC 4-J
6-
u0.- - %- S
>% . Lo0 0 OEuCX4
U ' U.- 0. >% u I
'E
Lo Q~ C 4- M4 AC
0 w 0U

C- to . 4S
0~~ 04-'00U
(L) 0 _r = u# x

'0>UD-,4- - M -4- do =
4A1 4A 00
* t-4
(L)O0 -G
In
%A
Q
~ Li
CC4J
fin
n 4
W QA
01.0 >1
L E C
01 M C S.. L. - OA
1d7 0) to0w +J4J 0-0)4-0#
- 4'OE
1 r In.z - , &4 4 0)
c)

rO ~ Q)> >b-am a >, M=

LL- L&J

o Wn S 0 $- .0 0
4 4.'32 04) 44t t La)m %-
LL C m >4-' Ln4j
.- V 4- -- -0
L-
AW oLC 4'3 =.or E (D4144 n E
(/ 0 L 'U O .- 0 01 V) u4-) w m
01- C
ch C>1. L- 'Ua0 LLA l.

v >%
00
u u
0 ~0Q. L 001.-
4- S- 0 fU d4-) ICAc 0
0) 4) 4A
0-
01

0_1_ VaEVA o 4 d .' 4W04A

CL0
-. J a C 0A
a) w" U- to0 QC4
-4- 04-
0m a O-j ~
CL *-U -C-u C- -C W

0l V) 0 A
U, _a m ,U > v , 4
m n.-MA-L 0 A 1

u- Q) CA04 -M -0
00j L . - 0 010=4)
U - J- -
C01 00c4' U , 1d
41U w S4 'U. -d)0 r Lw'
V)U1 U, IA Q DCA4 ot

co
In

C-CC

(/1 0i 0 1-
) (A 4L
0 tA
Lfl d)0 0C

crun *1 01 C-(

0 L) E 0 S- M

I--49-

Lo 2 0
 -~0 4) 14-0 4C 0) d)
4J 4. 41> 4 A V)
e4'- 41 E
#A w ,mn 4-) oen
:; .az 41
001 4 CZCr= 0 0 > Z: *nCI.1-0 u- to
4J1 - =,; to CC f..€
U'- Go CL oE wj-ct
C0go. CU ) > C - I-- *A 14A .C0I- CA O- 4'e
0

0+A! IV 0 .-
f -
0 f ) U-4-)4J 4,E.C~
Ans-
W.- E -n.) 4
4J
0- u
-C IU- J4-' o- - -0
I-W
• )C C 0 uo - ' f- -0. X.-C4-A)cur=
C- L -6,0) >i
C CM>, > 4-'$A > 4A a) 0 iC > a).- *L e
'; - 5- 0) N -%A ",-0 tnW LOW -O)C
- , ) 0 M O,4-- .- E ,E
4J)~
L4E U0 :;W -0n Ln 'D.-
S_ aCO 00Q
DW ) L- 'D w4n a,0 1- C -- e n. a4 -
) 0- I- 4)4- S- X C. U a , -- 4 4-) w L c a)C
> 0 U
-,- &AI CC 0 S- 0 O
3C-'fO'0 4J- w W $,- m E 4-J
L. S- 06.U thl 'a .9" -) 4m0 -. E 41 0
,.--E w 0/
4 -i-' W ~C U - W- - 0 14-0,4) f03I L-U) 4J
u 0 U, = .0u SA - iZ30 -- 0 0 *>"
4) .
V S- 4J *
:.:..--- 0 '0 0 4-" 4) 4J LM-- gO a L. -
x 01 M) 4 - :3 -J-E C - #Afl &- C) .r-CU a -&-' 0 '-"0
) 4- Q) -4 .4- '- -
, *0#A 0 - a) S- -0 C fO S - 0 4' -
s- L- t S - m EW )0 CA cm 3 m
0) ucw .= -

Co 0 4A 4 J Ci
X to ) .-.- 0U ) CU) 4Ca.
& c.U4CL4
-Ai E~c ix~ L) - ' "Vt 2:
E : 0 fa Mu t- 0-

L• -Ir) Lu - 0
LU
-V

0_ - ..o -
.4- 0 00u
C) to Il >1 C - 4)
- )C M)4- CL

0.t 0.0U)- (a.-

C) 0 ) U)
c )t 0
Q-C M00L ~
LU 4CW) enin
(D 1110)t 4-1 00t
< 4.) CA 4.) C
I"-

V4) a) 4)44w
(4 CA >W r_-0=n4-o
0L to .U) ~ rc CO
S- = o~ 4-. -) 4J4-
I-LW
4-- .) LWcu
I-) rO a)$ 0 I-34

UU4JS-

>-

C)
ex
Cii

u
4-)

0)0

od
tn CLcm-0P
s-OL tot

00 00)

-50-
 S.- 4-S
a-
4J ) 00 0 #A A 04
0.) u 4 1- ooj 4j.~ - V
41- 4" 4AJ-0 0 w2
0L0 - 0

4 hV43 )C). ~ JV 0 SW 4) CA
4) (LI 4J M4.0 0)1M S0~ab
U0)o 'a- 4- ~~~~~I
L - -
C7 -0 >,E0)UQ50.= m0EUc0 4m 4-0)1anO0
GJ)41tfl>01u V .J0w m L. 4j5. 41
LU 0 -CW X 4C *OU 0. 0U w =
>,O-0
to -'I-4-.&Al E tn0 .1
(7)~ L 4J - J oU1" - wI 04-e )
oo1 0 .5I4'1. to).- (DU 41I .- 4j 4C (AJCA
-~0 X 0 $- W - 0 MJf*4-'0)UZ W
q.-U2 aSCU4J
-C'4U U: C Cr C0)
4A0 of wS> u 30 wC 4
E= )C0'
0 40 )T; _ x ) w (A0-0)

N 0 41 ~C)4-S-C: 3 MI1 =U S- ' -0 0 CAsl-

- l- )e 0
L)0.5-.- AU wI- =w

.0-L)X
fA - cc US0 4j Ju5

1-)

LAJA

4-i tn S (A7 4-)

C/7 0.---- u 0 E
4-l C O t-4-
c1-. oA
C) 0 &-i

4) 4-1U5)
o ~ : Lf)~v0
L.J oL4-'0 0lt )0
a. ~ c 4-P 4 i
C) US 4)

- -E 5 to
I- S-)>4 0.).0

<a 0 S-4

V)L_ Ln -1 t
Ln = v 0+-

C0C)
LA--0
00 4-

0 00

CL.C"

0-

w - 0) m - 0.-

-)r 0 L7 E

C) . 0n
 4-)
4)~ ~~- 4-4 ) oL
-04J300
0- CL
.* 'C 0 4A E
i ,-
3 4) I r_ C fa "
1 -4J4 gto CA a--F'Ea
W34- 0.- 5- = (u 0,0 0 L.
4S- 0C= 4-&A .w..
E 41 "t' LJ
L: .00 fowOO =~ An
.
o C
u >.0) 0--4-J
U) @3t m.@aoJ
OCL- 4 CU 0 .- . (V
0 4-. 4.- :3" 4- -:3

4J)-43 4.1Wr 0 in
@30 0 XWV 4- -
d. .o to w 4n - .- C --
o c
a") S- n 4m -, 0-

-zr- 06 FO 0) to c 'o 2" L-

"a @L. u OE03) -'OS- >

I'-

0A

tu 0O . a)Q '- 4-A 4- 0 C WL

X:
EL3 . 3 -4J 0 O (D

LLJ €:::
0 CE --0@3
LLJ U)4J ( 0)
C) C 4-b
a)-to0 to (~0 )4
C3 0 : % C :-3 w
n t -U)
Li*,z3.
lt,. I- 3 ) ", U)
'G-J0
V)U O 0 4- t

V) 0-
ea -o0
-D~ EC 43 '04- In
co# U)s- C 0 :3
mOLu L Mc
S- S0-) @3CCr_
LOA C) -L)ao) Q a.--
LiJ

I.-

CDC

"o 0
CC
10 - 43
L~ 0)
L- I CI

LA) to4
n g nI

4 nC i dimnAO

L IA

--- C
minimum processor executive and multiplex bus overhead required to implement
the message protocol, two concepts are introduced: mode commands and system
control procedures (Figure 15).

System control procedures define the message protocol for the multi-
plexed data bus system. They serve to provide the executive software designer
with the logical decisions required to manage normal system operation. They
also define the required system flow to detect and recover from random bus
message errors and selective terminal failure modes. The system control pro-
cedures serve to link the executive mission software, bus message protocol,
and the terminal-to-subsystem interface management.

A time slice approach where messages occur on a minor cycle/major

cycle basis is used to control bus message operations. Messages that are
transmitted at specific iteration rates within a major cycle are defined as
synchronous messages. Each synchronous message is assigned a period and phase
for transmission. The number of minor cycles per major cycle is specified by
the system designer. An example is 128 minor cycles every second or major
cycle. Messages that are to be transmitted on a demand or request basis and
not at a specific phase and period are designated as asynchronous messages.
Table 5 summarizes the bus message operations.

Bus control operations provide for major/minor cycle synchronization

and for synchronous and asynchronous bus message transmissions as shown in
Figure 16. The synchronous bus messages are controlled by a predefined bus
instruction list. The bus instruction list is part of the Master Executive
preloaded tables. It contains an instruction pair for each synchronous message
that is transmitted on the data bus. Since not every message is transmitted
every minor cycle, the instruction lists are organized so that the instructions
for all messages with the same period and phase are grouped into a block. Each
block ends with a link to the block for the next higher message rate with the
appropriate phase. In this way a static list can be employed. No dynamic
linking is required each minor cycle; the Executive just starts the bus at the
correct place ir,the list.

Each data word on the bus is transferred to/from the processor's

memory in real time via a direct memory access channel. The address at which
each message block begins is constructed by combining the current base address,
the transmit/receive bit, and the subaddress into the pointer address, and
then fetching the contents of the address via DMA. Consecutive data words are
stored in contiguous memory locations until the word count for that particular
message is exhausted. For all receive operations, each message block is pre-
ceded by a generated tag word which contains the current minor cycle number,
word count of the received message, and a message error flag.

Asynchronous messages are scheduled by the master executive based

upon requests from remote terminals, application tasks, or the master executive
to perform message error or terminal failure operations. Subaddress 30 is
dedicated to asynchronous receive messages. After receiving an asynchronous
message, the BCM interrupts the processor and the local executive updates the
pointer word for storing data before restarting the BCM. A transmit asynch-
ronous message is sent via subaddress 29 and does not cause an interrupt.

-53-
 CDL

Lu ,

7> CD,

CD:

LLLU

V) (L)

LCL

LnU

coz
-LUJ
CDa:
C-D)

C-))

LI)

-54-
 LnjIU L-)

cVD -JC
=:)J ZD
(,C)J Or
43LJ
=

-2:<4 F-C

C):( L L L)

0) -33 V)
3L
V)j c
LLJMLLU

V3:
-1 L-) Cy 3 : -L
=J:i DC)C LX

c- 3l: (/A C) (
LU
...(AXLLJ-- LA 3:ca
<c :i CD l 0X: 0

L( V) i -U
o:: =D 03
F 3:>-( c
(A Li00 M')3 U
>- (i C) 4 c1I
-1 (Y- >< X- >- (r5
CO 3LLJ-j <~3
L><:-
M 3: (
LA >- Lii (A C) LLI
Ln Dc >- .. 3

-0 -1 cc L

- LAX

LLA.
The first word of all asynchronous messages is used to designote the ,olir'-C
of the message. This asynchronous message identif'ier is used Ly the V:oI
executive to process the data or identify the executive services actie
required.

There are several types of asynchronous bus message operations

based upon the resource making the request and protocol to process the
request as defined in Table 5. Upon receiving the request, the master execu-
tive causes the BCM to halt at the end of the current message operation. It
then executes a predefined or generated bus instruction pair to initiate the
asynchronous message operation. Figure 17 shows the message protocol sequence
for a subsystem connected to an RT requestinq service. Asynchronous operations
are used for pilot panel inputs and weapon release messages, as examples.
Figures 18 and 19 show asynchronous rt;essage protocol sequences for interprocessor
operations. Interprocessor messages are used to signal master mode changes
between application tasks in different processors and steering/guidance waypoint
passage, as examples.

4.1.2.2 Mode Command Operations

The mode command operations are indicated by usinq a subaddress of

or 31 with the specific mode code in the word count field. Table 6 specifies
the mode commands required to support normal operation and error/failure manage-
ment. The MIL-STD-1553B Mode Codes have the following uses in DAIS.

a. Mode codes 2, 18, and 19 are used to support detection

and recovery from bus message errors.

b. Mode codes 2, 3, 8, 18 and 19 are used to support

terminal failure analysis.

c. Mode codes 3, 4 and 5 are used to control the redundant

buses.
d. Mode codes 1, 16 and 17 are used in asynchronous bus

operation.

e. Mode codes 0, 6, 7, 20, and 21 are not used.

Table 6 indicates which mode command operations are required in a

remote device to make it compatible with the DAIS system control procedures
and master executive.
Table 7 shows the use of the mode commands in relationship to the

system control functions.

4.1.3 Application Software Executive Services

The DAIS Local Executive provides certain services to the Applica-

tion Software. It defines both software elements and real-time statements.
The software elements allow program and data modules to be classified according
to their function. The real-time statements operate on the software elements.

-56-
 Ld
-D

- LJ~ LUi

I-- ' LUJ I-- ~I

LLJ Ji :D LULJQ I-

C)
C) C.)
C)

1- LU
- U-
ull
(A
(A C:0 LUA

LUJ

M F-) LL LUCDC
V) M) V -sLU

- 2:
zF L, 9 =

V)LU-

0j
U,

-57-
 Lu C

C) cr
X: C)
Ln
(-3

C)

cr)

Ln

Qrn-k-- Lo

o) F LU
LOU

C) :r F-

-- = ~
=-
LI ) m zt ::t 3 CD
~ -CD L- <! CD C
~.> CD LI-I
)J
LU-
V) U
- ~-~m
t~
f

LU( 2:VC
-

LLU

LiI

C-))

-58
 V)

VA
V)CUC~

or LUJ

C-)) C LU
L, > - '- (A LI:
C) V) ciJ
X: CE
LUJ
cy

LLJ
C I 0c

C)

LALU

CD m,
(D ca
cc (A LU=:
C

-- < 2-CiC LU

vi < C -) F-

H- - C)
LU E u C)
LU Z t-) (A -
(A
V) LLU LJ 4c LL
mc =- r-.Jcn LU
if
LJ C: -CM - ni
C-M Ec = F- 0 (
-/ cz 0=)
CA) C-) (A)
= ci = CD LA
< == = LlU

CD

V)-

C)l

(A
iU
H- (

-59-
I4

ea Z -

C) 0 Ln -P
(A 4- C-4o 4-J
S- go 4'C 4-;

-U (A 4- V 4- -
CE cu CC ~i &-' -- u

U. 4 4 -4 Cn '
S- - v C- 0
E-
V
S.-
a)
a) L.
4) .. a)) S--
E0 ~ -

V)) ( ) tS ~ )- +-
d Q-) (a0 .0 -
~
0 4- ~)) ~ 4-'di 4U W 4'.. 0 -
C.. Cn 0. 0)
uj.. L-) O

mA (' C: j( U-1 C0D- C)

Cp C ) 0D
CD C)

CA Li - Li C) -LJ Li

Ln C
r- - S-

o. 0 c' CO
F- r- r- to (a--a
oo t v ( o ( 41 4- 4 1

oa -O *O V -
0 0 0 0 0 0

5-0 0 0J 0 0 0
cc
<
4-)
0
-
)
'a-
4.)
~ 4) 4)
4) 4) ~ -
F- C) au -A -1 o
-3E
0g_0 0 01 :
F- 4J 0 4C
I. S..
) 3i 0) C-Q U C

0_ 4-' 4.)0i w 0 al 4)
3A 4-(A E
s'
(A
tO -- V)

a. m 0) 0) (
- ) 4-' 0) > 4-
a)- 0 )
N ( (A 0 C QK >- N) - F- 4.

wA C ~
4-)
Li
)
4-)La
-' )0 OD to' C c- 4-'
2m) 0 - 4'O L - - -

CO C... E 0 E 60-+'E S- E E0
 C~

LUI

V/)

t-J LU ~ D

L. -40

L" LU
C) CD CD D
Ul a- M: C)L
-n CD~LA C
f (C) L

LU (n

cn ui

-61

____ C Vu
 The Application Sottware elements which , e recognized by tshe lo al
executive software are Tasks, Comsubh-, Compoo] Block., nd Fvent,, def-,,-( I
fol lows:

a. Tasks are programs or processing modules which can either be

controllers or cal-culators. Application software is organized in tasks (oro-
gram modules) with each performing a function as required for the specific
system application. Each task contains executable code and local data.

b. Comsubs are common subroutines which differ from tasks in that

they are required to be re-entrant. Consubs can be used by many tasks, so
that one task using a particular comsuh can bp suspended in the middle of thre
comsub routine by another task using the same corsub.

c. Compool Blocks provide data communication between tasks and the

external world or equipment. A buffer system is provided by the use of global
copies and local copies to prevent a compool block from being read when it has
been partially updated. Every task, except privileged tasks, interfaces with
a local copy while performing its calculations. The local copy is updated
from the global copy with the READ statement; the local copy updates the global
copy by the write statement. A special statement (TRIGGER) is used for a
critically timed compool block.

In a privileged task, communication is allowed directly with the

global copy in the processor in which the task resides. The privileged task
cannot be interrupted by another task or by the Executive.

Since the READ, WRITE, and TRIGGER statements invoke Executive

services that operate in the Privileged Mode, this guarantees a task will not
reference partially updated data.

d. Events are data items used to communicate real-time conditions

signalled by a process. An event is either "ON" or "OFF".

Real-time 3tatements are used by tasks to control the state of other

tasks, control values of events, and control reference to cempouo blocks. The
are J73-defined statements which the application programmer uses durine the
jevelopment of mission software as follows:

Schedule Statement
Cancel Statement
Terminate Statement
Wait Statement
Signal Statement
Read Statement
Write Statement
Trigger Statement
Broadcast Statement

The first four statements are used to control task states. These states and
the method of transitioning from one state to another state are shown in Figure 20.

a. Schedule Statement. Schedule statements are used to place an

uninvoked task into an invoked state. An invoked task bpcomes active and
dispatchable when the required event conditions are satisfied. An invoked

-62-
 UNI NVOKE D CANCEL
(FROM ANY STATE)
SCHEDULE _CANCEL

INVOKED

(INACTIVE) TERMINATE
(FROM ANY STATE)

EVENTS/CONDITION
SETS SATISFIED

DISPATCHABLE
I I
END {_.
SPRIORITY I

I PRIORITY

EXECUTING SUSPENDED

20.TSK TAD DISAGRAL

FIGUR

WAITENT OR TIME

ACTIVE)DND

FIGURE 20. TASK STATE DIAGRAM

-63-

.-. o
task is placed in execution by the Executive if it has the hichest prirrity
among the tasks which are dispatchable.

A schedule statement includes the name of the task to be scheduled,

the mode of task (privileged or normal), priority of the task, and event
conditions to be satisfied.

b. Cancel Statement. The Cancel Statement is used by one task to

place another task in the Uninvoked State. If a task is cancelled, all the
lower branches or sons of the tasks in the control tree structure are cancelled.

c. Terminate Statement. The Terminate Statement is used by one

task to place another task in the inactive, but invoked,state. If a task is
terminated, all the lower branches or sons of the tasks in the control tree
structure are also terminated.

d. Wait Statement. Wait Statements are used by tasks to place

themselves into the Wait State pending occurrence of cne of the following
conditions:
1. Absolte Time
2. Rel ive Time
35. tatched Event
4. Unlatched Event
For the latcheo or unlatched events, the task remains in the Wait State until
the specei* event, either on or off, occurs.

e. Signal Statement. Signal Statements are used by tasks to set a

Specified event to a specified value, either on or off.

f. Read Statement. Read Statements are used by tasks to copy the

values of specified compool blocks (global copies) into a local copy to Le used
by the task.

g. Write Statement. Write Statements are used by the tasks to copy

the values of specified locaT copy into the specified compool block (global
copy). The Write Statement causes global copies in other processors or virtual
copies in remote terminals to be updated and causes signalling of an event
associated with the compool block.
h. Trigger Statement. The Trigger " "ts are used by a task
to send a specified critically-timed compool --k ' a) to a specified remote
terminal at a specified time. This causes . "cicaliy-timed asynchronous bus
message operation to be performed where the local copy of a specified compool
block is sent to a global copy in the Master Processor and where, at the speci-
fied time, the data is transmitted to the specified remote terminal.

i. Broadcast Statement. The Broadcast Statement is used only by

a privileged mode task. After updating a global copy of a compool block, the
broadcast statement is used to cause the asynchronous update of remote and/or
virtual copies of the compool block.

-64-
4.1.4 Error and Failure Management

Bus message error management and terminal failure management are

performed by the master BCM and the master executive. In addition, each
terminal on the multiplex data bus provides mechanisms for detecting and
recording message error conditions and terminal failures. Message error
conditions and terminal failure conditions are recorded in the Built-In-Test
(BIT) word which can be obtained by the master with a mode command. Also,
each terminal records in a register (Last Command) the last valid command
received by that terminal which also can be obtained by the master with a
mode command.

The master executive and BCM centrally manage the message protocol
to recover from message errors and reconfigure for terminal failures via the
following activities.

a. Monitor the message sequence to determine successful or

unsuccessful completion.

b. Analyze error response and determine type of retry

procedure for unsuccessful messages.

c. Perform retry of unsuccessful message, first on the

same data bus.

d. Analyze error response if not successful and retry

the unsuccessful message on redundant data bus.

e. Perform failure analysis if retry of message on alter-

nate bus is unsuccessful.

f. Update the system configuration tables based upon the

error conditions and failures.

The remote devices on the multiplex bus collaborate in message error

detection by validating each receiveo word. A word is invalid if it contains:

9 Parity error
• Incorrect or missing sync
a Incorrect bit count
* Invalid Manchester format
A remote receiver will not respond with a status word after detecting
a message error. As message data is received by a BCM, it is stored in the
processor memory via DMA. If received unsuccessfully, the message error bit
in the tag word is set. As message data is received by an RT, the data is
temporarily stored. If received unsuccessfully, the data is not transferred
to the subsystems.
Message Error analysis and retry procedures are performed by the
Master Processor/BCM. Error analysis is based on:

* The bus instruction which caused the message to

be sent.

-65-

( .:
 e The status word(s) received from the trarismittirnq
and/or receiving terwial involvea in the opera-
tion, and

9 The interrupt code register (ICR) and internal status

register (ISR) in the Master BCI.

The method of retry is based on specifications o; the system designer,

the type of message operation, and the manner in which the error is detected.
The majority of messages are simply retried thn number of times specified in
the individual bus instruction, and then if necessary retried again on the
redundant multiplex bus. The system designer may specify that a message re-
quires a careful retry. This is done if a subsystem would be degraded or
function improperly if sent repeated data. In this case, the message error
management must first confirm that the data was not properly received befoe
repeating the message.

The type of message operation influences the message error management

in several ways. Synchronous messages may normally be repeated inmediately. A
second message simply overwrites the first and the message data is not scheduled
for processing until a later minor cycle anyway. If one assumes that ti..e source
of a message error is of short duration and occurs randomly, it is easy to see
this is the most effective approach. The BCI can recover the error automatical 'T
and an interrupt of the processor is not even required. Asynchronous messages
to a remote processor require careful retry. Such messages are separately
buffered and queued as received and thus risk duplication if repeated. An
asynchronous message from a remote processor can be retried immediately since
the remote does not perform buffer management/queue update processing until after
the synchronize mode command is received.

The method of error detection is principally a question of whether

the master is explicitly aware of the message error. This is the case when a
data error is detected while the master is receiving data (i.e. RDE indication
in a terminal to controller operation). In this instance, no further analysis
is needed. When the primary error detection is by a remote device, the situatic ,
;s less clear. In accord with MIL-STD-1553B, remote devices, upon detecting .n
error, do not return any status. Subsequent mode code operations are necessary
for the master to acquire and examine the status word associated with the T'Iost
recent operation.

However, the status word error bits in the ISR do not necessarily
imply a message error. They indicate the absence of a good status, which
could simply mean a bus error occurred during the transmission of the status
word itself. A similar result occurs if a bus error happens during the trans-
mission of a command word. The intended terminal will not respond to a garbled
command, and the Master BCI will set the status error bit after an appropriate
time out. But, in this later case, note that the status word contained in the
remote device will be a good status left over from some previous message opera-
tion. This defines the need for the last command sequence.

It is to be recognized that the last command register is maintained

in each TCU in an R, and is, therefore, bus-dependent. The mode code to transmit

-66-

_ _ _ _ _
the last com and must be sent on the same bus as referenced in the bus instruc-
tion pair for that RT. Also, the Last Command register is updated by all
commands other than Transmit Last Command. Therefore, if the last command may
be required for error analysis it must be retrieved first.

It should also be noted that the technique of retrieving the last

command register assumes the most recent successful operation was not an iden-
tical (subaddress, word count, transmit/receive) command. Should back-to-back
identical commands be possible, (such as for a very limited use RT), the system
designer is responsible for seeing that intervening commands are sent to permit
the correct operation of the retry procedures. Generally, a transmit status mode
command before each such message will be most reliable.

One of the expected sources of message errors is that a remote device

will occasionally be busy when conanded to transmit or receive data. A busy
transmitter sends no data and a busy receiver accepts no data, so duplicated
messages are not a problem and no confirmation of an error is required. A
imple retry of the message is performed, and a count of repeated busy responses
on a single message is maintained to prevent an infinite loop.

When a message error persists after the specified number of retries,

the error is logged via the configuration management function and the message
s switched to the redundant multiplex bus. Note if the message succeeds on
the alternate bus, the bus operations simply continue and the switched message
remains on the alternate bus. Thus, if one bus side of a terminal is operating
-n a marginal fashion, messages will migrate to the good bus side as errors are
Encountered.

An auxiliary function imposed on the message retry procedure is that

of NO-OPing messages after a terminal has been declared failed. When a terminal
is failed (a decision made by the configuration management function) no attempt
is made to remove the instructions addressing the terminal from all bus lists.
That would require an extensive search operation or some pointer lists to locate
all the affected bus instructions. Performing the NO-OP in the retry procedure
distributes the impact of removing a terminal's messages at the cost of an
interrupt per message. It is also worth noting that the NO-OPing procedure 's
operationally almost identical to switching a message to the redundant bus.

4.1.5 Configuration Management

The repeated failure of a bus message is reported to the Configuration

Management function for tabulation and analysis. A message which succeeds on
immediate retry is not reported. (In fact, the processor is not even aware of
the error if an automatic retry succeeds.) Reported errors are tabulated against
a terminal address with separate counters accumulating errors on the two redundant
communications paths.

The overall interaction of the assorted system functions involved in

declarinq or responding to a device failure is shown in simplified form in
Figure 21. Configuration Management is notified only after repeated errors
and then a failure is declared only after a critical threshold is reached or
self tests reveal a hard failure.

-67-

--~i -I-
 Lf)

(D r
M

I u-

LU ~)(.
::D C L
V- -J

vii

cci

w V)

L4 ZD
C-:) (D ,

-68-
 The first task of Configuration Management is to decide what
terminal to charge with the error. While determination that an error occurred
is primarily based on the receiver's status word (or lack of it), the error
is normally attributed to the transmitting terminal. The receiver is charged
with the error only in the case that he reporcs an error when neither the
Master processor/BCM nor the transmitting terminal detect any anomaly.

Error counters are maintained by Configuration Management for each

bus side of each terminal address. Each time an error is logged against the
terminal and bus side the counter is incremented and compared to a user-defined
threshold.

When the error count reaches this threshold, the bus side is flagged
as "suspect" for this terminal address. Once a bus side is flagged as suspect,
the message retry procedures will no longer switch messages to this bus for
this terminal. If the threshold is reached for both sides of a terminal, the
terminal is reinitialized in an attempt to restore normal operating character-
istics.

The reinitialization procedure is represented in Figure 22 and con-

,ists of a series of mode commands to reinitialize, perform self test and
transmit the BIT word. The BIT word format for an RT is shown in Figure 23.
As may be seen, the terminal is capable of detecting a variety of internal
:)roblems. The sequence of initialize and perform self tests primarily exercises
the TCU and MTU functions. (The individual IM's and channels are tested in
background of normal operations after being accessed for data.)

The reinitialize function will analyze the BIT word retrieved and
flag each bus as good or failed and report back to configuration management.
Should any errors occur in these mode code operations, this will be considered
an indication of failur6 of the bus side of that terminal.

When a good bus indication is returned to configuration management,

the terminal will be considered operable on that bus. The appropriate rrror
counter and "suspect" flag will be cleared and normal communication witn the
terminal will be resumed. Should the error counters again reach the thresholds,
the whole sequence will be repeated. To protect itself from excessive overhead,
the system will keep count of the number of times a terminal has been reinitial-
ized. If this count reaches a user-defined limit, the terminal will be flagged
as failed.
DAIS has not implemented any recovery procedures for failed RTs. Once
a termir is flagged as failed, messages to that terminal are NO-OPed as errors
are enco red and all communication with the RT ceases. Message traffic is
restored r Iy by a system reload and cold initialization.

Messaqe errors which are attributed to a remote processor will be

ccunted aqdinst each bus side and the count compared to a threshold as des-
cribed above. One bus side may be flagged as "suspect" and message traffic
will migrate to the other bus. However, if a remote processor becomes suspect
on both buses, it is failed immediately and the startup/restart function is
invoked.

-69-

e.!
 ON BUS A, SEND IE
I

MODE CODES TO: 1

ICONFIGUTION
MANAGEMENT INITIALIZE TERMINAL I7MOE
FAILURE IO
I(FIGURE 4.2-27) PERFORM SELF TEST

I OES BIT WORD SHOW ETOSATS

FMTU/TCU FAILURE? FTO
NO

ON BUS 6, SEND MODE

CODES TO:
* INITIALIZE TERMINAL MODE CODE
* PERFORM SELF TEST FAILU
STRANSMIT BIT WORD URE I

U BD BSET
DOES BIT WORD
MTU/TCU SHOW
FAILURE S STECO
FAIL TO TO STATUS
TO FAIL
NOL A&B

TO FAIL A FI
SET STATUS' NO_ J YES
TOA&
GO~ { USE BUS B TO SEND USE BUS A TO SEND
MODE CODE TO SHUTDOWN MIODE CODE TO SHUTDOWN
THIS TERMINAL ON BUS B THIS TERMINAL ON BUS B

FIGURE 22. REINITIALIZE RT

-70-
 - 0-

go:

- 03

L&A

4 ,al' ) C C- - CD )- O.J w-

4L1

20 - C3
. CD )C oz- -D0C

WC -- 10 zZ±ZCD-CD
> )C C C) .. 0 a 0
x: -1 C DC 0 W3:
 The DAIS executive software urchite~ture (d virtual memory ar;,1o1_2,1)
does not permit continued operation in the event of a processor failure. A
reinitialization sequence is not done for processors since the startup/restart
function provides a more comprehensive verification of both hardware and soft-
ware and, in the event of a solid failure, gives the pilot better visibility
into what equipment is operable, thereby facilitating reconfiguration.

In addition to error reports from message retry, the configuration

management function may receive failure reports from the status exception/BIT
word analysis function. This function is invoked when a status word returned
during a message operation contains an exception condition other than M/E,
SR, or busy. The exception is normally indicated by the T/F bit (devices with
other exception indicators are known as "strangers") and more detailed informa-
tion is contained in the BIT word.

The BIT word format for a BCM is shown in Figure 24. Since self
tests are not performed for BCMs duriny normal operation, the power-on-reset
is the only condition that will cause a T/F bit to be set for a remote pro-
cessor. This is treated as a fatal condition and the processor failed immedi-
ately. In practice, this will not occur, since the loss of power by a remote
will result in accumulated message errors and the recovery of power will cause
the processor to cycle through the startup/loader which clear,, the 7IT
register
prior to enabling for remote communications.

The flow of the status exception/BIT word ornalysis is shown i Fitur.

25. When the exception is from an RT, the BIT word is retrieved for analysis.
Either a bus side (MTU or TCU) failure is reported or an IM/-hantel failure
is reported to configuration management. The TM/channel failures are separately
counted for information purposes, hut rfherwise either exceLtion, is cleared by
reinitializing the terminal. Again, a excessive number of initializations will
result in terminal failure.

When an entire device is flagged js failed, Configuration Mma, e,,nt

will perform one of several actions deiendin'; on 0e type of device. if a
remote terminal is failed, Mission Ap Ii ati n, Softwa r- will be ,totifi,-, by
way of the Subsystem Status Monitor, so tnat :i:,)rop, iate action --iav bo iritiat .

When any processor fails, configquatiin tarajement invokes the syste.

startup procedures and all processors perform hardware and software tests to
determine operability. Outputs to the PCP/ACi li:hts advise the pilot of the
hardware/software status.

Note that DAIS has not implemented a Monitor function. Should the
Master fail in such a way that the above functions cannot be performed, the
system will freeze and manual intervention by the pilot is required.

4.2 DAIS Architecture Features

The DAIS architecture possesses specific characteristics which faci-

litate the adapability of the system to various applications and support effec-
tive incremental integration and test of the DAIS core elements. These key
characteristics are discussed in the following sections.

-72-
zz

of -,

00(1

-73-
 I INTERRUPT IS THIS TERMINAL
I HANDLER ADDRESS A
EHEN ICR:5,6, REMOTE PROCESSOR ?

,READ YIS REPRT EV

FROM DATAIFI RFFFAILE

Up

FIGURE ~
25 ~SAUSEXETION/BTWR
M AN ALYSIS

ISTI4
EMN

WORI,

READ BT. WOR

 Specific features in the DAIS system which allow adaptation of the

core elements to a specific avionics system configuration are presented below.

4.2.1 Bus Devices

The basic messdge structure, data format, and command-response pro-

tocol required for the multiplex system is described in Section 4.1.2. The
message protocol is defined as that sequence of bus messages required to per-
form normal multiplex synchronous and asynchronous operations and to support the
message error detection and recovery process. The MIL-STD-1553B definition of
the command format allows up to 32 different addressed devices to be,implemented
on the multiplex system. DAIS has restricted this definition to allow up to
four processors/BCMs and 28 remote terminal devices.

The system designer defines the specific configuration (number of

[,rocessors/BCMs, number of RTs to interface with the avionic sensors, and sub-
,ystems using the standard Interface Modules (IMs) or unique IMs if required).
*he system designer then defines the sensor inputs/outputs as data bus messages
,id inputs this information to PALEFAC. PALEFAC generates the Executive bus
nstruction list tables accordingly. This directs the messages to the proper
irocessor containing the application software (e.g. EQUIPS module) which pro-
esses the sensor/subsystem data.

The DAIS architecture is readily adaptable to various numbers of

devices on the bus. It provides the tools to automatically genera t and
direct the messages to the proper application software in one of the
processors.

4.2.2 Processor/Bus Controllers

The drchitecture provides the capability to expand or reduce the

number of processors/BCls fora specific application. The system designer
considers trade-offs in determining the number of processors/BCIs required.
Mission requirements, reliability and availability must be considered.

The system designer defines the Mission Software application

iodules bdsed upon tne mission requirements and avionic suite. The applicd-
tion programmer develops the application modules using the J/3 language and
mission softwdre standards. Based upon the application execution times,
memory size, datd access, comsubs, and the bus message traffic, the system
designer then partitions the application tasks among the processors using
FALEFAC. PALEFA r produces the tables required for run time execution of the
application soft~are in the specific configuration of processors/bus con-
trollers. These tables are used by the master executive and the local
executive.

4.2.3 Remote Terminal _(RT)/Interface Modules (IMs)

The RT has a modular and programmable design. This allows flexible

partitioning of the data messages to the appropriate sensors/subsystems and
signal conditioning required by different numbers and mixes of subsystem
signals. This is accomplished as follows:

-75-
 The Timing and Control Unit (TLU) in the ,T perforrs all rof tnt
timing, control, buffering, decoding, and checkin:. required to receive nr
transmit information from the data bus and transfer that information as
outputs or inputs from the RT via the Interface Modules (IM). The TCU con-
tains a programmable device which controls the mapping of each data word in
the RT. The interface between the TCU and IMs is standardized and contains
the signals required to allow TCU to select the individual modules. There-
fore, all IM slots can accept all IM types.

Each RT will interface with different numbers and mixes of sensor/

subsystem signals for each specific systeii configuration. This is accom-
plished by inserting the proper number and type of interface modules into
the IM slots in the RT housing and by programming the ROM in the TCU. If
required, a special interface module can be desi~iied to interface with an
existing subsystem having a unique interface.

The furctions of the RT can also be embedded in a sensor or sub-

system so that the interface of the sensor or subsystem is airectly with
the multiplex data bus. Functionally, the ef-bedded PT responds tn colmiands
received on either data bus in the sa',e w.y is an RT.

4.2.4 Apppjca tion Sof twar

The DAIS System Architecture is desioned to allow iodular imple-
ientation of specific systems L,, usFr tie required e'c. ents ,,f the DAIS
system, both haroware and softwdre. I'st, tnt set u ul tiplex equipvient
for interfacinj to the external wui Id sensors arid Contrels arid Lisolays
tra lpmert) ,'ust be chosen. TIi,, the ;esi ;r of the processin,, syste* can
,egin. The Applicdtion Software is initiaily designed as if it wll exist
in one large virtual processor. This virtual processor has as much ,'ermory
space and execution time available as the sum of the flight processors to
actually be used in the system. After the data interfaces have been defined
t, the outside world ("ultiplex but, .esi~es, dud the Iinctioral pe,,or
,rquired of the application software harvheer identified, the :ayo.,t of
,_,ipool Blocks and Tasks can begin.

Compool Blocks are the data coinivunication paths between the appli-
cation software and the external world and among the ipplication software
tasks. Tasks are the processina eleri ents in the application software which
collectively perforw the avionics processinq fun~tion. Tasks access the Cor-
pool Blocks through calls upon Executive services ('such as READ and WRITE)
and operate upon the contents of the Lonpool H)ocks for processinq purposes.

After the functions of the application system have been designed

in terms of Tasks and Compool Blocks, and the Application Software has been
tested on the host processor, partitioning of the application system onto the
flight processors begins. This partitioning is illustrated in Figures 20 and
27 for a two and three processor system configuration, respectively.

The application software can be easily partitioned across a set of

flight processors by using the DAIS Executive and PALEFAC. The DAIS Executive
provides general I/O control for all communications on the multiplex bus
(between processors and to the external world). PALEFAC builds the data base
which is then used by the Executive to control system com-unications.

-76-
 -

4.4 CDcck I-
IAJ C.

I.- VE

C40 LID
uLJ C2,

03.

LUi

Cf)

CD
LU

La 0 -

UL-

CL.)
C-,4w. . CL LU4
::3 0 L~
0j9. wJ

-77-
 c~I m

LAJ 0 0
WI
-
C
cn C:
0 bi
r-10.-

c I. I =J

I,--

V(1

CDC) cn-
0le La

C-78
 The use of the Executive and PALEFAC results in an automatic parti-
tioning of the Compool Blocks onto processors based upon the partitioning of
Tasks and upon which Tasks use which Compool Blocks. If a Compool Block is
used for convlmunications between tasks and if the tasks are split into two or
more processcrs, the system will automatically generate a copy of the Compool
Block at each processor; it will also generate the multiplex bus message to
update all other copies when one copy is updated.

The system will also automatically generate the multiplex bus

messages required to connect the Compool Blocks to the devices on the multi-
plex bus. All multiplex bus messages may be declared as synchronous with a
period and phase. If not so specified, the system will automatically generate
asynchronous updates of the bus messages when a copy is updated.

4.2.5 Interface Standards

The DAIS was converted from MIL-STD-1553A to MIL-STD-1553B.

4.2.5.1 DAIS/1553B Message Protocol

As discussed previously, MIL.-STD-1553B defines the basic message

structure and command-response protocol. In order to properly handle detected
message errors and other DAIS system features, DAIS developed a set of proce-
dures that define bus operations and message error and terminal failure
letection and recovery processes. If a sensor/subsystem device's bus interface
conforms to this composite DAIS/1553B protocol, it would be fully compatible
with the DAIS System Architecture.

4.2.6 Portability

The DAIS Mission Software has, from the very beginning, been con-
ceived as an easily retargetable system. The single most important feature
that allows this capability is the development of more than 97 of the DAIS
Executive Software in JOVIAL J73 (The only routines written in assembly
language are processor-dependent I/O operations, register manipulation opera-
tions and lowest level interrupt handlers). All of the DAIS Application
Software is implemented in JOVIAL J73. A striking demonstration of the porta-
bility of the DAIS Mission Software is the fact that it executes both on the
DAIS processor ano on the DECsystem-1O, the host processor facility. In fact,
stand-alone module testing and initial subsystem integration testing of Appli-
cation Software is performed on the host processor. This is possible since
the JOVIAL J73 Compiler has a code generator for both the DECsystem-10 and
the DAIS processor, which points out the ease of retargetability of the DAIS
Software System.

4.2.7 Redundancy

DAIS provides redundancy in the system architecture. This can be

employed to provide backup and recovery to complete mission functions in
spite of hardware failure. The areas which can be used for redundancy are:

a. Dual redundant data bus includes redundant bus

interface modules in the BCIU and RT.
-79-

. ... _ _ _ _ _ _ _ _ _ _

<A
b. System can employ dual rPdurldant T r - ,ei
subsystem.
c. Multifunction keyboard and associated Data Entry
Keyboard can be used as a backup to the !nteorated
Multifunction Keyboard and assuciated Data Erttry
Keyboard.

d. Raster displays can serve as backup to each othe-.

-80-
5.0 SUPPORT FACILITY

The purpose of the AVSAIL support facility is to test and evaluate

the DAIS core element architecture and a representative set of sensorssubsystems.
The support facility provides a real-time simulation of a military aircraft
performing an operational mission. The simulation generates the interface
signals between the simulated aircraft sensor suite and the DAIS system. The
avionic equipment is thus subjected to a data signal environment which is
nearly identical to actual flight. A simulated cockpit is included as part
of the simulation for realistic evaluation of the avionic system.

The support facility for DAIS consists of a Software Test Stand

(STS) and an Integrated Test Bed (ITB). Initially, the Software Test Stand
provided a capability to test the mission software resident in the DAIS
flight processors (AN/AYK-15). The Integrated Test Bed provided the capability
to test the DAIS core elements which included the mission software, the DAIS
processors (AN/AYK-15), the multiplex bus system (MIL-STD-1553A) and the
cockpit controls and displays. Currently, both the STS and ITB use a MIL-STD-
1553B multiplex bus system. The flight processors have been changed to the
AN/AYK-15As on the STS only. Therefore, the STS provides the capability to
test the DAIS core elements which include new mission software, the DAIS
AN/AYK-15A processors, the MIL-STD-1553B multiplex bus system and the cockpit
controls and displays. The ITB's flight processors are still the AN/AYK-15s,
so the ITB is used for testing hardware an6 running simulations. Both the
STS and ITB utilize a complex of digital computers consisting of a Digital
Equipment Corporation (DEC) DECsystem-10 and a number of DEC PDP 11 series
computers.

Simulation software resident in the DECsystem-10 was developed to

provide real-time simulation of a military aircraft in an operational environ-
ment. The aircraft dynamics, the aircraft sensors and weapon targets are
simulated. The simulation is driven from the cockpit by an operator acting
as a pilot. The simulated cockpit is equipped with Controls and Displays so
that the various modes of a mission may be flown by the pilot with an out-the-
window background scene.

The support hardware and software provides interfaces between the

DAIS elements under test and the host simulation software. The support
facility provides the capability to set up a test, conduct a simulation, and
record data from both the DAIS elements and the simulation. During a simula-
tion, sufficient test data is displayed in real-time to indicate that the
system is operating satisfactorily. It provides presentation of test results
for observing systems performance.
The support facility is composed of:

1. STS Support Hardware

2. STS Support Software and PDP-1i Processors
3. ITB Support Hardware
4. ITB Support Software and PDP-11 Processors
5. Host Simulation Processor, DECsystem-1O
6. Simulation Software
7. System Test Software
8. Picture System
9. Picture System Software

-81-

Ill i ii,
. ..... .....
.... . ii... .. ............... ... ....... ..
...
.... iigm .. ..
..... .... ba :...
5. 1 Systel LoifiJuration

The initial support Iaility furlctio io i 'i Jtd , I u~ i ,

2bi. It consi sts of SFS & 13 hardwere rid sof tware tto '01a riI: llhr
Simul a tion Processor" und the DAIS cockpit.. 2he ctareot supior'. .ci tv
functional di agram is shown in Iigure 29. 5u -u twrr
r t u I., rwr icent "
the DECsystew-10 and irithe PDF-1i .ruces.sors.

5.1. Interated Test Bed LITBJ

The Integrated Test Bed (ITB) bi( 'd:arcjc
is Showr in r
It is coi-posed of the support facili ty arid D.: . core elerients. ,he
facility siiulates al 1 the equip!eoent and environme,,t exterral tc tne r;,.1
processor using the resident -ission software, DT' 'S rultipex syster . and
DAIS controls and displays. The ITb suprort facility is co:',posed of supp. rS
hardware, support software resident in the DP-i1 processor, the simiuiat-r'
software resident in the host si ulation prccessor, the DAI.1S simulatea cc ec.
and an out-the-window picture systelm.

The support hardware provides the interfaces between the simulati(

and the DAIS core elements. The interface inc c.rs: 1) the :ultiple' [ts
vessages which drive the mission software, ?) .1he [)erformiiance i:onitorinc -
the multiplex bus traffic arid the internal operation Cf tne ,i;sion softwcre
in the DAIS processors, 3) the curkit co'irc s a.d Dackup instrumIents. a-c.
4) tne out-the-window picture.

The support software controls and manages the support hardware arc
provides the ileans to link the DECsystei- I. silrulation so7 twdre wi th the
DAIS elements. The support software also provides the perfor, ane -oni tor
and control functions which are relited to test set-up, iontt,l ,nj at
collection for post-test analysis.

The host simulation processor is a comi-,ercial DF(syste-iJ ,',le,

The sinulation software generates the rea' world environment extcrr - -
CAIS processors in real ti,:e. The ii-jl ati.n is driven by the '1 -0o ,
flight controls so that an ,aperator _an tliv tre siwulaticn.

An out-the-window picture systenm Lroviues , symbolic backjroun,

scene outside of the cockpit so that the pil ot operator wil, expe,'iencc t!e
visual orientation of flight with respect to If-s, targets and runways. The
picture system al1So provides the ,'tion fcr dis la ing the 'HUD symbolocy
iverlayed on the bacfground scene.
iictorial rep-esenta+ion sf 17B is shown in Figute .

A set of system .-st software is resident in the host simlulation

processors, the ITB PDP-11 processors, and the DAIS processors. It perfori::s
the system readiness test prior to performing operational runs and diagnosinc
faul ts.

5.1.2 Software Test Stand _(.TS

A block diagra of the initial STS is shown in Figurt 37. The

system was similar in struc,ture to the ITP. it shirei utilimItio .
DAIS cockpit arid contru')s nc 4isl ty . 'ird rei -.
i c"atmcr sc:. ,'-'
the DECsyste:-10 tomplev . Come. ,o;-t cr.' ' -.

-82-
AD-AL07 906 TRWDEFENSE ANDSPACESYSTEMSGROUPREDONDO BEACHCA F/G 9/2
DITAL AVIONICSINFORMATION4SYSTEM(DAIS):DEVELOPMENT ANDDEN--ETC(UI
SEP S1 M J COOK,RtC MASON..J L STAUTBERG F3361578-C-1502
UNCLASSIFIED AFIIALTR-81-1165 N

.3ME

l.lfl molfllsfflf E

smmhshEEEEEEEE
smmhEsl-Ehmh..
hhEohEEEmoEEEI
EEEEEmhEEEmmoE
hosoEEEEEEmom EEi
 INTEGRATED TEST BED (ITB)
ITB POP-1lT DAIS
PROCESSORS SUPPORT IPROCESSORS,
HARDWARE BCIU's a RT's
I SUPPORT

LSOFTWARE I LOFTWARE
S
[LZ - - -- L -- -

I HOST SIMULATION PICTURE DAIS CONTROLS

DEPRCESSO SYSTEM EkDISPLAYS
SIMULATED
I COMPLEX8
I COCKPIT

I ISIMULATIONI

BSUPPORT
a
LOFTWAREII

STID-1 T DAIS
IPROCESSORS SUPR ROCESSORS,
SUPORTHARDWARE a BCIU's

L -SUPPORT-J

SOFTWARE TEST STAND SSU

SUPPORT FACI LITY DAIS

FIGURE 28. INITIAL SUPPORT FACILITY FUNCTIONAL DIAGRAM

-83-
 IINTEMATED
IITB PDP-11
TEST
TDAA
BED '(ITB)
I PROCESSORS YiPP( I)
-------- ARDWARE I
P,(
SUPPORT &
-- SYSTEM

L
im4

S HOST SIMULATION PICfURE DAIS CONTROL

PROCESSOR SYSTEM DV PLAYS
DEC-10 SUMULATED
COMDEX1 COCKPIT

; I ----
SIMULATION
SFWR
-I -*-1--
1

g t t & SUPPORT
SOFTWARE I I

STS PDP-11 ST As
PROCESSORS SUPPORT PPO'C[S'OFR,'E'

SYSTEM I
TEST Ir
I SOTAE IMISO
SOOFTWARE

-- -SOFTWARE TEST STAND (STS)

SUPPORT FACILITY IDAIS

FIGURE 29. CURRENT SUPPORI FACILITY FUNCTIONAL DIAGRAM

-84-
 14
12
iIE t-..
I ~ jjLI

-- I-t~,flh~t
II
It k4'±1 jfOf
1±
KJ171 LJ
-
D

I -~ n IL

-85
 ejj

fC

-86-
 It 0
~~C)

I-,-

a ~ LI
LA
ICI
0 0n

-8-Ia
both ITB and STS. The initial STS was generally utilized to test M.%sc,
Software and the support software when operation with the real-tir;e c .u -
tion models and DAIS (okpit was not required.

A blcck diagram of the current STS is shuw ii figure 3.. li,

current STS and the initial STS have the following differences:

a. The multiplex bus system was changed from MIL-WTD-

1553A to MIL-STD-1553B.
b. The flight processors were changed from AN/AYK-!Ss
to AN/AYK-15As.

c. The SCADUs were replaced by the PMIUs.

d. The CIUs were eliminated.

5.1.3 Physical Configuration

The support facility is configured as laboratory equipment. The

floor layout and rack/console configuration for STS and TTB are shown a_
follows:

a. Initial STS/ITB Floor Layout - Figure 34

b. Current STS/ITB Floor Layout - Figure 35

c. Initial STS Test Control Center - Figure 36

d. Current STS Test Control Center - Figure 37

e. Initial STS Equipment Racks - Figure 38

f. Current STS Equipment Racks - Figure 39

g. ITB Test Control Center - Figure 40

h. initial ITB Equipment Racks - Figure 41

i. Current ITB Equipment Racks - Fijure 42

5.2 ITB Support Hardware

The ITB hardware consists of the following subsystems:

5.2.1 Universal Remote Terminal

The Universal Remote Terminal (URT) simulates the operation of a

set of up to 32 remote terminals. The URT receives or transm.ts data between
the DAIS multiplex data bus and the PDP 11/40 processor. The URT provides the
same interface to the DAIS multiplex as a Remote Term;nal, except the URT
simulates up to 32 RTs.

The URT is set up and controlled by the SSDF software in the PDP
11/40 by loading the URT registers and RAMs. In real-time operation, the URT
performs the following:
-88-
 CD
0C-

LD

-89-
 L7
0
0I
N'

_ __
ox 0 I-

-J

-J

-4

II
II
lao'
IDOl
a."
LJ

I-

V 0

U a 0

LiiV0?
[7]
IqI
101
0

0
~

a.
K
\NW~XS

I-I
I~I ~
U
a '2 ~a:
LJ
0 ~ -,

U, U,
I-u
04
C

K __

-90-
 Pn-I , /40]

RACKS

EC-11O -

ITS rcc CD

-J
L-J
CD,

F-

K2~ I---

1-
LJ

PDP- 11/40 POP-11/40

wSA
1
FHW/SAT

/ LU
UJ
DAIS COCKPIT , DAIS COCKPIT D
SUPPORT .
HARDWARE

PDP- 11/40
SSDF/URT

STS
TCC

STS
RACKS

PFP-I/410
IPM CI 1
S STI
RACKS
-91-
 LU

II-

uLU

as]
 DEC WRITER DEC WRITER

4K

FIGURE 37. CURRENT SOFTWARE TEST STAND

(STS) TEST CONTROL CENTER

-93-

- ------------ -
 IIn

0 K Io

- 94--f
 S K-

r'~ ELN
pCe
-~o ; -

it Ln

-K I.-.
I - ~ LU

H-
LI

H-

LLJ

-95--
 Li

F-

LLJ

lul u
X., U0

-96-
____
_
_ ____
_
_
_
_
_
 0, 1; 1

N )A nj CO..
- 13 :1
rI *- o) KAr LI 0V
A ncr .L

COL ZiC -04 1,a

2.0.~0. 2 ( a.I~r

0
nW44
3 TL u
>-

0. 1J-CC -
a.L
"Jw o
oj
i
- ~ ii rw
0a.(

lo 3 ~ o
0- mO 0

0
kn.L 0 ) '~
C4 ./
Li X P.-:D - cc

L - -- n
Aci- dC: L/)

La0 I- S-

W fl Lo
La co V') 0a
Z en d 0 0(0L

-
0L cr
0 _j--4 _4
0 LA)4
-
tAJ LIi-F= m
2 La LAi ZI 0
L0 V) (1)~La4
6i O - La u - r- 'a-
4OLai La'4
XN)- I- Ve C

0 U) l
La JLn L~- L.)

LJ <.~l >F L
E011C Lai
LA U ><D
;,- -I-j 0F- z CJL ta'O

z N d

4 c1 Ir w '
LL)~U 0 C -
'q tA. J0) c

-970
 S a_,-~ C~
~~r
3-
tr-
a_
)
o

0 0
: tflrc
34 0~ V o n a 4r

CZcr CL0

ro 0 - -'4II v
-Wa ui- C) 0
3z w z ~ -
Lj
4r
'-'
t4 2
DWC-
0Q < r

0- (1) cr r~in

A C)

z 0 0
crorrc

( yI-- Wlj C C-
2 CL D ::)12 0 C-4.,-

_ _50_ La.IJ- - - -II - - 0-

-. U) M f 4 L
*5i 'n(/ C- LO-

u- u V ) - LoU
C

40t..Jcr taa4 (

(-r3
( r n- 2

oo (2
Li 0 022

z Wa Iz Z
4z fra 4 O
a,
04 a
LL, 2
r4.- -
C)c E:

u m
4- UJ -l(auJ~C
<(a1. 4 1 C-
wzU. C- Z j co 0

I r-c cr
-dJI( u

-98-

__ _ _ _ _on
 I. Transfers the DAIS multiplex data to/from the PDP 11
for each message operation (controller-to-terminal,
terminal-to-terminal, and terminal-to-controller)
based upon:

@ RT address/subaddress
* Transmit/receive bit
e Word count
* PDP 11 memory address

2. Responds to mode commands received on the DAIS multiplex

data bus. The URT has the capability to generate an
interrupt to the PDP-1I upon receiving the following
mode commands:

* MIL-STD-1553A
a MTUI or 2 shutdown
* MTUI or 2 shutdown override
e Reset BIT word
e Initialize terminal
a Initiate serial channel I/0
* Minor cycle sync

* MIL-STD-1553B
@ Synchronize (with and without data word)
@ Transmit status
* Transmitter shutdown
e Override transmitter shutdown
a Reset remote terminal
* Transmit vector word
% Transmit last command
a Transmit BIT word

3. Provides the capability to set/reset bits in the

serial channel activity register, module error
register, and the BIT register for each simulated RT.

4. Prevides the capability to inhibit the status response

to any receive command.

5.2.2 Bus Monitor Unit

The Bus Monitor Unit (BMU) receives, records, and breakpoints on

selected messages received on the DAIS multiplex data bus. The BMU stores the
received messages into the PDP-1l/40. The BMU interfaces with the DAIS multi-
plex data bus and monitors for data messages (controller-to-terminal, terminal-
to-controller, and terminal-to-terminal messages) and mode commands. The BMU
operates in either the automatic mode or manual mode.

The BMU is set up and controlled by the PMC or the PMIU software
in the PDP-11/40. The BMU has the capability to provide selective monitoring
as follows:

-99-
 1. Record the bus traffic heginnino at a specifif-o
breakpoint and record for a specit i c nur,,;er (f v,

2. Record the bus traffic beginning at a specified

breakpoint and record for a specified length of til-e.

3. Record the bus traffic beginning at a specified

breakpoint and record until a second ,pecified
breakpoint is reached.

4. Record the bus traffic beqinring at a ,,pecified

breakpoint and record only a specified 'esage.

5. Record all bus traffic, only the control wor'zs

(coiiriand and status), or only the data wore,

6. Transmit a message.

The BMU also has a manual control function which can record all
bus traffic, only the control words (commano and status), only the data
words, or only the message gap time. The manual iiodes arc contr'Iled c
from the BMU front panel.

5.2.3 Console Intelligence Unit

The Console Intelligence Unit (CIU) operates in conjunction with

a RS-232 interface with the PMC PUP-11/40, DECsystem-10, and the Hazeltine
terminals. It provides the means to control and load/change DAIS proce sr
registers and memory. The CIU is supplied by the DAIS processor vendor to sup-
port the debug and test of the mission software under non-real-tir-e iandVions
The functions the user is able to perform are:

1. Clear Processor 10. Clear Breakpoints

2. Halt Processor 11. Set a Breakpoint
3. Toggle Memory Protect 12. Step Processor
4. Read Instruction Counter 13. Execute Pro.essor
5. Load Instruction Counter 14. Load [ oe imaqt
6. Read Register 15. Write Tape imao,e
7. Load Register 16. Stutter Mode
8. Read Memory 17. DEC to Cassette
9. Load Memory 18. Cass,-tte to DEC

In the local mode, console commands are issued from the Hazeltine keyboard.
When under control of the DECsystem-10 or PMC PDP-11/40, the CIU is in the
remote mode. The DECsystem-10 or PMC PDP-11/40 functionally interfaces
with the CIU similarly to the Hazeltine terminals. This allows the Hazeltine
terminal functions to be performed at the DECsystemn-10 for loading, or
PDP 11/40 under PMC software control.

5.2.4 Hazeltine Terminals

The Hazeltine terminals, in conjunction with the Console Intelli-

gence Unit (CIU) provide interactive control of the DAIS processor registers
and -mmory as specified above. The Hazeltine terminals include the followinq:

-100-
 1. Hazeltine CRT Display
2. Hazeltine Keyboard
3. Hazeltine Thermal Printer
4. Hazeltine Cassette Tape Unit

b.2.5 Processor User Console (AN/AYK-15AJ

The processor User Console enables the user to connunicate with

the AN/AYK-15A precessors. The User Console configuration is shown in
Figure 43. The User Console was supplied by the DAIS processor (AN/AYK-15A)
vendors to support the debug and test the mission software under non-real-
time conditions. The functions the user is able to perform are:

1. Clear Processor
2. Display/Modify Memory
3. Display/Modify CPU General Registers
4. Display/Modify Instruction Counter (IC)
5. Display/Modify Fault (FT) Register
6. Display/Modify Status Word (SW) Register
7. Display/Modify Interrupt Mask (IM) Register
8. Display/Modify BCI Control Registers
9. Display/Modify Timer A
10. Display/Modify Timer B
11. Dump Memory Block
12. Step Processor
13. Step BCI
14. Set/Remove Breakpoints
15. Execute Processor
16. Load from Disk
17. Write to Disk
18. Control Printer
19. Clear User Console
20. Read User Console Status
21. Allow Processor Functions
22. Inhibit Processor Functions

In the local mode, console commands are issued from the Hazeltine keyboard.
When under control of the DECsystem-10 or PDP-11/40 via the PMIU, the User
Console is in the remote mode.

5.2.6 Performance Monitor Interface Unit (PMIU)

The Performance Monitor Interface Unit operates in conjunction

with the PMIU software. It provides the STS users with the capability to
monitor and control the software running in the DAIS processors (AN/AYK-15A).
The PMIU software sets up the PMIU for real-time operation by loading the
PMIU control registers via the DEC Unibus. The PMIU then performs one or
more of the following CPU monitor functions:

1. Monitor all instruction addresses

2. Monitor a specific instruction (OP-code)
3. Monitor CPU or BCI instructions within areas of memory
4. Monitor memory stores within specific memory locations
5. Monitor operand stores where operand value meets
conditions and address is specified

-101-
 A/AYK- 15A

RS-232-C
CHANNEL

LAB SPARE USER

COMPUTER RS-232-C CONSOILE
C ANNEL I

KLYI3OAkD CL [UAL FLOPPYPITE

DISK

FIGURE 43. USER CONSOLE CONFIGURATION

~-102-
 6. Monitor memory reads within specific memory locations
7. Monitor all out of sequence branches
8. Monitor all interrupt occurrences
9. Monitor any DMA occurrence
The PMIU also performs one or more of the following control actions:

1. Halt AW/AYK-15A processors

2. Start execution AN/AYK-15A processors
3. Single Step AN/AYK-15A CPU or BCM instructions
4. Clear processor
5. Read AN/AYK-15A memory or registers
6. Write AN/AYK-15A memory or registers
7. Inhibit and enable PDP-11 interrupts

5.2.7 Simulated Subsystem Interface Unit (SSIU)

The Simulated Subsystem Interface Unit (SSIU) provides the interface,

control, and data transfer functions required to interface a set of remote
Lerminals (RTs) to a PDP-11 unibus. Each RT interfaces to the SSIU via a
[acilit) Interface Module (FII) which is specially designed for this purpose.
igure 44 is an interface block diagram illustrating the SSIU interconnection.
The SSIU provides the interface for the simulated sensor suite that
in actual operation is interfaced by up to sixteen fully populated RTs with
:ny complement of Interface Modules (IMs). A FIM occupies a single RT slot.
It responds to any address which defines an IM slot and IM channel for which
'he data were actually intended. The SSIU uses this address as a pointer to
:tore and retrieve data from unibus memory in preselected locations which
Are mapped to correspond to the RT configurations begin simulated.

The SSIU uses a PDP 11 unibus memory that can support a Direct
Memory Access (DMA) data rate of at least 1 MHz for each 16-bit word and can
operate in a burst mode (dedicated unibus) for up to 34 microseconds. Other
fEatures of the SSIU include:
1. At the end of each data block written into unibus
memory, transferring a pointer by DMA to a pre-
selected location defining the starting address of
the data block

2. Providing an interrupt at the end of preselected

messages

3. Providing an interrupt for several types of error

conditions

Set up of the SSIU memory and control registers and monitor and control of the
SSIU during operation are provided via unibus Programmed Input/Output (PIO).

-103-
 C) -

L/) L)

L,) t- ccLILI
C-)cy

(z04C
5.2.8 Super Controland Dijsply Unjt

The Super Control and Display Unit (SCADU) operates in conjunction

with the PMC software. It provides the "TB or STS users with the capability
to monitor and control the software running in the DAIS processor (AN/AYK-15).
It collects, stores and/or breakpoints on the data received from the DAIS
processor (Table 8) and then halts the DAIS processors and/or BCIUs and
interrupts the PMC PDP-11/40.

The DAIS processors make available to the SCADU information accessed

or stored in the processor's memory. Based upon the processor's memory con-
troller micro-code addresses, the SCADU determines which data (Table 8 ) is
being received from the processor over the parallel multiplex data bus. The
SCADU then selectively monitors and stores this data.

The PMC software sets up the SCADU for real-time operation by

loading the SCADU control RAMs with specific micro-programmed monitor and
control actions. The SCADU then performs one or more of the following monitor
functions:

1. Monitor all instruction addresses

2 Moritor a specific instruction (Op-code).
3. Monitor all jump instructions which cause a branch.
4. Monitor all memory stores.
5. Monitor all memory accesses.
6. Monitor all interrupt occurrences.
7. Monitor all DMA occurrences.

Tne SCAU also perfons one or more of the following control

actions:

1. Breakpoint (halt) upon occurrence of one of the

specific functions above.

2. Log the data in SCADU buffer (trace) with a time

tag.

3. Compare the function with user's specific value

(fixp. point or floating point numbers) and
brec point.

4. Halt processors and RCIUs.

5. Interrupt PDP-11/40.

6. Start, stop, or reset the time tag timer.

After the appropriate control actions have occurred, the PMC soft-
ware reads the data collected in the SCADU buffer, and reinitiates the same
or a new operation.

-105-
 ( 0I(.

C' u

Ln
U)(

C)

-. C)

S LU- C

C CC

C) v)

V-) c~

U))

---- S- Li

~~, -

4---
ci

L. CL

L -
4)

4-)E-
.4

CI U a)1 c.

0) C) 0U

I..
S- -
SU vi Ur)
:2
- 4-' C34-3 V) LUj 1) clefA

:r Ll( C)
0 Li U
L.
--- a- cuII-o

-106-
 FI

..9 lIB Power Distribution and Control

The ITB Power Distribution and Control System (PDS) simulates

aircraft electrical system power for the DAIS core hardware. The PDS simu-
lates three power sources: tattery, master AC generator, and Ram-Air Turbine
(RAT). The output of the simulated power sources provides power to two sets
(AC and DC) of three electrical bus systems: emergency, primary, and second-
ar1 . Each DAIS core hardware element is capable of simulated operation on any
one of the electrical buses. Also, each individual hardware element has an
on.off control. This permits simulated power control or power failure of any
one of the power sources, simulated electrical buses, or individual equip-
ments. The PDS includes provisions for software control of the power sources,
electrical buse , or individual equipments. This software control is
accomplished via a PDP-11/40.

The PUS systew controls, distributes, and filters the power to each
f the DAIS core hardware elements. The PDS system also controls and dis-
tribures power to the support hardware.

;.2.10 ITB Tesc Control Center

The ITb [est Control Center (TCC), shown in Figure 40, provides a
entralized point for control of the entire ITB. The TCC contains the terminals
;nich can control the PMC and SSDF PDP 11 processors and the DECsystem-10
;imulation models via the PMC. Both system checkout and operation can be con-
-rolled from the TCC. The DAIS displays and the out-the-window scene are also
.isplayed on CRT monitors at the TCC.

,.2.11 Controls and Backup Instruments System' (CBIS)

The CBIS consists of the DAIS cockpit flight controls and displays
that are not part of DAIS. The controls include the throttle, stick, rudder
control and discretes. The displays are the basic flight instruments including
the standby ADI, altimeter and warning lights. The CBIS interfaces to the ITB
by means of the backup C/S interface unit which provides digital to analog
conversions and a digital link to the SSDF (URT) PDP-11/40.

5.2.12 ITB Equipment Racks

The ITB equipment racks, as shown in Figure 42, include the ITB
hardware as specified above as well as power supplies; special interface
panels (multiplex data bus patch panel, Processor/BCM breakout test patch
panel, and CIU,/RS-232 patch panel); power control panels and processor control
panel.

-107-
D. 3 liD_ Support Software and PUP- I Lk,-
U,

Support software is resident iv,tr, , :1 .

b. 3.1 Performance Monitor and Control

The Performance Monitor and Controi (II4C coftvrreslides in 0

G144 System (PDP-11/40) under RT 11. It is useu to set up, control, criu
monitor the Mission Software resident in the ')AIS p,---essor. (Ar/AY-15A).
The PMC is capable of servicing from one to four DAI. orocessors at one ti'.e.
It simultaneously monitors the mul tiol ' tr f.-f i ' vit thr S a:nd rt,,
selected DAIS system data for post-O',A anI.
fl ,

Tne PMC controls the SCADU's, CIU's, ind BMD. The DAIS Processor,
are monitored and controlled through the SCADU's and Lne CIL's. -he PMC
starts and stops the set of DAIS Processors. he DAIS processor Mission
Software is loaded from or dumped to the ULCsy' tew- (jnost simulation pro-
cessor or the PDP 11 processors under .'C control.

The PMC sets up test cases whlich define the procedures and data
collection for a simulation run. An operator is able tu set up the test b,
means of an interactive interface and the creation of t test control file.
The test control file is correlated with the DECsyste ,-lO scclation
tot
the collection of test data will proceed as defined by te file as the siu-
lation progresses.

The PMC supports the system users in the dehugging and evaluatior
of mission software. It allows selective real- time 3nd non-real- time 1d ?t! -
ing of data from the DAIS processor and the multiplex data bus. The 2MC
provides a repertoire of commands to perform the non-rec -time and reai- i1i
functions as follows:

1. Manipulate files on the DECssten-It1 and PDP-I I

such as rename, delet(', opv, t.
t

2. Lood or dump DAIS rocessor r ii-.si

S software fro,
or to the POP-Il.

3. Perform the CIU fun,.tios as defined in paragldph

5.2.3 when the DAIS processors are halted.

4. Start and stop (lhalt' the DAIS processors and B-IIC.

6. Set up the SCADU to peiform specified functions as

defined in paragraph 5.2. during ,eal-time operation.

6. Set up the bus monitor to record or breakpoint, as

defined in paragraph 5.2.2, on specific multiplex data
bus messages.

7. Display, print, or log the data collected from the bus

monitor or DAIS processors via the CIU and SCADU. Data
logged on a disk can he analyzed later by a Post Run
Editor.

- 108-
 8. Provide the cdpability to exdmine or modify DAIS
processor registers and memory locations either
with absolute or symbolic addresses.
9. Provide interactive capability with the DECsystem-10
to set up and run the simulation models.

lhe PMC provides the capability to restart Mission Software, along

with the simulation models, from a system snapshot point. This is accom-
plished by dumping Mission Software parameters at a specified PMC breakpoint,
and reloading these parameters to restart the system. This snapshot and
restart capability is used for repeated testing or demonstrations from a
specific point in the mission profile.

b.3.2 Performance Monitor Interface Unit

The PMIU software provides the STS users with the capability to
nonitor and control the software running in the DAIS processors (AN/AYK-15A).
no Performance Monitor Interface Unit (PMIU) is capable of controlling up
to four PMIUs on one UNIBUS. The PMIU software is designed to run under the
-I operating system on the PDP-li. The PMIU software monitors and controls
ihe DAIS processors (AN/AYK-15A) and monitors the multiplex bus traffic
rhrough the PMIU.

The PMIU software sets up test cases which define the procedures
.iddata collection for a simulation run. An operator is able to set up the
est by means of an interactive interface and the creation of a test control
:-ile. The test control file is correlated with the DECsystem-lO simulation
o that the collection of test data will proceed as defined by the file as
,-ne simulation progresses.
The PMIU software supports the system users in the debugging and
evaluation of mission software by allowing selective real-time and non-real-
time gathering of data from the DAIS processor and the multiplex data bus.
The PMIU provides a repertoire of commands to perform the non-real-time and
real-time functions as follows:

1. Load or dump DAIS processor mission software from or

to ttz PDP-il.
2. Set up the PMIU to perform specified functions as
defined in paragraph 5.2.6 during real-time operation.

3. Display, print or log the data collected from the

multiplex bus system or DAIS processors using the
PNiU Post Run Editor.

D.3.3 Simulated Subsystem Data Formatter (SSDF/URT) Software

The wain purpose of the SSDF/URT is to buffer data to and from the
DAIS Models Simulation System (OMSS) and to provide timing signals to the
DMSS. The SSDF/LfRT software sets up and controls the URT, double buffers the
data in the four-port buffer memory, and provides a user-selectable display
of the multiplex d;jta bus messages. The software is designed to run on both
the ITB and STS.

-109-

i ,
 All URT data areas for tranirnsi iun and rucept ion ot data irf
double buffered in the four port ouffor meory I buffer A an. .
model s' output data is read, the %SD[ /UPT waits until thIe 11( ;:nor
and switches the URI buffers. The DMSS out'ut for C: " , ,,ad oi11
processed if CBIS is on-line. The data received 6y the U. for the D Y-
passed to the DMSS as it is received. The LCIS/TCC input, are iassed tu ft,
DMSS 32 times per second.

The SSDF/URT and the DMSS use a handshaking flag to prevent the
reading and writing of partially updated messages in the DMA window.
Initially, the SSDF/URT sets the flag to a one. When the c ock iriterrupt i
generated to start a new DMSS cycle, the 'LR comi Ete wr'it.r; ary
partial messages to the DMA window ana then interrupts the DrCsystem-l Tr!
DMSS sets the flag to a two, reads all inputs and tnen sets tee flag to a
three. While the DMSS is reading its inruts, the SSDF/URT reads the DMSS
output and waits for the flag to be set to three. At this time, the SSUF/LP'
sets the flag back to one.

The minor cycle number (received with tne synchronize mode conmand
is maintained by the SSDF/URT along with the major cycle number (number of
times the minor cycle count transitions from 127 tL zero). Toese two vat, es
are written into the DMA window as they change to allow tagging of any
recorded data.

In non-real-time mode, the SSDF/URT performs the following:

1. Manages memory initialization.

2. Utilizes user-defined tables to initialize the URT

RAMS and registers for the specific mission.

3. Initializes the four-port buffer memory, display

processor, CBIS and keyboard.

4. Accepts user' configuration conriands to specify the

following:

a. Whether or not the SSDF/URT software should keep

cycling the real-time models when m:ission -:oftware
"tops.

b. Whether nr not the URT shoull be set up to respond

to minor cycle messages to buc address one requirea
for one-processor configuration to respond to a
dummy minor cycle message).

5. Simulates a mass memory device using the PDP-1I disk

unit to allow loading of STS and ITB nrocessors over
the DAIS multiplex data bus.

6. Initializes a real-time clock to provide interrupts

32 times per second to drive the real-time i.iodels.

-110-
 THe tirst lflinot LyLIC message received or a user command causes
tie SSDF/UkT to enter real-time mode. In real-time mode, the SSDF/URT
performs the following functions:

1. Maintains and displays minor and major cycle counts

and passes them to the PMC software if required.

2. Generates interrupts to the DECsystem-1O to cycle the

real-time models based on timer interrupts.
3. Moves data received from the URT and SSIU to the DMA
window.

4. Controls the swapping of the URT double buffers.

5. Reads the models output data from the DMA to the

four-port.

b. Uses the timer and DECsystem-1O interrupts to control

access to the DMA window.

7. Inputs and outputs CBIS data (performing all necessary

formatting,.

8. Hanales mode conand interrupts from the URT as

required to make the URT respond like a real RT.

9. Maintains displays of all pertinent information.

,3.4 Evans and Sutherland Graphics System

The Evans and Sutherland graphics system is used to generate a

cockpit out-the-window scene. The out-the-window scene is controlled by the
simulation software so that the scene viewed from the cockpit has the correct
dynamic orientation to synchronize with the simulated aircraft motion. The
graphics interface software transforms aircraft attitude and position data
obtained via the DECsystem-1O DMA window from the simulation software program
into a form that can drive the Evans and Sutherland graphics system.

5.3.5 ITB PCP-l Processors

The PDP-Il processors include:

1. Each PMC (PMIU) and SSDF (URT) processor has a complex

consisting of one DEC GT-44 PDP-11/40 processor, and
other peripherals.

2. The Evans and Sutherland Graphics interface processor

consists of a PDP-I processor.

b.4 STS Support Hardware

The initial STS hardware subsystems were identical to that

described for the ITB:

-111-
 Ir I'

1. One Universal Remote lerminal

2. One Bus Monitor Unit
3. Two Super Control and Display 'Jnit,
4. Two Console Intelligence tinits
5. Two Hazeltine Terminals
6. One Four-Port Buffer Memory
7. One HAS SCADU

The current STS hardware subsystems are identical to that described

for the ITB or are described previously:

1. One Universal Remote Terminal

2. One Bus Monitor Unit
3. Two Performance Monitor Interface Units
4. Two User Consoles
5. One Four-Port Buffer Memory

The STS Power Distribution and Control (PDS) system controls,

distributes and filters the power to each of these DAIS core elements and
the STS support hardware.

The STS Test Control Center (the initial STS TCC is shown in
Figure 36 and the current STS TCC is shown in Figure 37) provides a cen-
tralized point for control of the entire STS. The TCC contains the teri'iinals
which can control the PMC and SSDF PDP-11 processors and the DECsystem-1O.

5.5 STS Suport Software and PDP 11 Processor

The PMC software for STS is identical to the ITB PMC support soft-
ware as described in paragraph 5.3.1.

The PMIU software for the STS is identical to the ITB PMIU support
software as described in paragraph 5.3.2.

The SSDF (URT) software for STS is identical to the ITB SSDF fURT)
software except interfaces for the SSIU and CBIS are not op erated.

The PMC PDP GT-44 System and SSDF (URT) PDP GT-44 System are similar
to the ITB PDP-11 processor.

5.6 DECsystem-1O Host Simulation Processor

The DECsystem-10 facility block diagram is shown in Figure 45.

The KI DECsystem-1O CPU is used with the interfaces and peripherals shown
in the block diagram. The DECsystei-1O facility is a conventional DEC
configuration except for the Direct Memory Interface Controller which
provides a DMA window access to the DECsystem-1O memory for data transfer
between the DEC-system-lO and the PDP-II processors.

-112-
 --- -- - - -
-- -- - - - - ~

a w

'o 0
CL IL~
Li~
00
~~~ ~a a w (3
-j 4cLiI

L I. V LA-

-F -- C3 o C

0 dr to &2
a- 1,- 4
. La . ic
a W

- -- -- Ci
* c

X* -- -- - -- - -- - - cc I

* I I a a1D

04.

x. - wxi L-

a ao
Ct
it ~ a
a 0o

*~ c.

lot CL. a.4x Z

uC II C.)

Im x0 I

LI~~4 I 31

---------------------------- 4-
UL (1. -----------------------------------------------
5.7 Simulation Software

The Simulation Software, also known as the DAIS M elh, i ,1.t!

System (DMSS) is resident in the DECsystei,-10 tiost simultit *,rO S .
The DMSS consists of seven functional types of software:

a. Executive software responsibhl for overall simulatior

control;

b. Sensor models, which simulate the on-board air-raft

sensors;

c. SLU/STORES models, which simulate functional responses

of weapon systems to the operational Stores Management
software;

d. Aircraft/Environment models, which Provide airframe

dynamics, flight control dynamics, and propulsion
data in response to pilot and external system actions;

e. Interface utilities, which provide access to the Crew

Station cockpit controls and displays and to the Evans
and Sutherland Picture Systenm;

f. Checkpoint/Reset utilities, which allow for the capa-

bility to reset the scenario in both run mode and
non-run mode system operation; and

g. Scenario Generator software, which can be used in

place of the Aircraft/Environment software, and will
simulate all inputs and outputs required to "fly"
a predefined flight scenario.

The simulation software system as a whole operates with a major cy(le

(computational cycle) rate of 32 times per second. It should be noted, h,wcver,
that not all models operate at this maximum rate. The modcls are broken into
so)ecific rate group subsets, based unun computational reouirements (speed ar
accuracy) and operate at various speeds. Data is transferred 32 times per
second, based on the highest rate groun requirements. The data transfer infor-
mation required by the simulation system from Mission Software is initiated
when the SSDF/URT PDP-11 processor generates an interrupt to the DECsystem-1O
at the start of each computational cycle. The simulation system then reads ll
inputs from the PDP-11 and then generates an interrupt back to the PDP-11. The
simulation then performs its calculation and outputs its data to be provioed to
Mission Software to the DMA window. The SSDF/URT PDP-11 then accepts the data
and transfers it to Mission Software.

-114-
5.8 Picture System

The picture system shown in Figure 46 consists of a simulation

software-controlled ground display graphics generator and projector sys-em.
The graphics-generated display of the ground as seen by the pilot in the
simulated cockpit, is projected on a motion picture screen in front of the
cockpit.

An Evans and Sutherland graphics system generates an idealized

pattern which represents ground terrain, targets, runway, etc. The Evans
and Sutherland is controlled by the DECsystem-1O simulation software via
the PDP 11 processor. The graphics are generated on a stroke CRT display
and monitored by a closed circuit television camera. The TV image is trans-
icitted to the Advent projection subsystem.

-.9 Data Reduction and Analysis Software

The Data Reduction and Analysis Software (DRAS) processes, formats,

rid outputs data froml the Integrated Test Bed (ITB) or the Software Test
tand (STS). The DRAS is composed of two computer programs which perform the
allowing functions:

* Read ITB/STS data from tape or disk

e Convert data from binary to decimal
e Rewrite selected data onto a disk
e Read the data from the disk file
* Generate report files
@ Generate a disk file suitable for plotting

The report files generated by the DRAS include a data report, an

-vent and time report, and an error message report. The data report contains
a time history of selected parameters recorded during ITB/STS system operation.
The event and time report contains a block of STS/ITB data recorded at the
time a discrete event changes. These events include changes in navigation,
steering, or master modes, weapon release, thrust, INS alignment status, and
weight-off-gear. The error message report contains a list of all errors
which may have occurred during processing.

DRAS is used to support system testing and DMSS testing. It is

also used to provide a permanent record documenting the successful completion
of formal demonstrations.

-115-
 C3,

LLIU

cr-z
-C CD)

LLLU

c
(D -16-
CIL'
o.0 SOFTWARE CONVERSION

n.i Mission Software Conversion

The Mission Software was converted from JOVIAL J73/I to JOVIAL J73.
The conversion and retest effort took almost 15 months because corrections and
*ranges were being made to the new JOVIAL J73 compiler simultaneously. The
.,SW conversion was accomplished in an orderly and organized manner.

:,1.1 Executive Conversions

The executive software underwent three stages of conversions.

irst, the executive was converted from MIL-STD-1553A to MIL-STD-1553B bus
rotocol. The second stage of conversion was the retargeting of the executive
trom the AN/AYK-15 processor to the MIL-STD-1750 (AN/AYK-15A). The last stage
r conversion was the translation of the source code from J73/I to MIL-STD-
.o89b (JOVIAL J73). At the completion of each of the three conversions, the
,ecutive was fully tested.

The conversion to MIL-STD-1553B bus protocol resulted in simpli-

cation of the bus control functions of the executive. A small amount of
.design of the executive was required to incorporate the new bus protocol
ficiently.

The conversion to AN/AYK-15A required modifications primarily to

-ie assembly language routines of the executive. These rcutines contain the
ichine-dependent interface such as interrupt handlers and Bus Control Inter-
ices. The new processor also had a different repertoire of machine instruc-
ions which also affected these routines. Also, the use of the JOVIAL
Ki1 AYK-15A code generator necessitated the inclusion of a stack management
ystem into the executive.

The language conversion to JOVIAL involved primarily syntax changes.

,iowever, several semantic changes were required because of strong type check-
ing and addition/deletions of data types.

o.1.2 Aplication Software Conversion

The application software was converted to JOVIAL J73 and retested.

irst, the Compool Blocks and the Comsubs were converted because these are
used by the other tasks. Then, the application tasks were converted. The
:cceptance test programs (ATP's) were converted along with each task so that
testing coul, be kept up-to-date.

Some of the changes required to convert the tasks were trivial;

square bracketc were changed to parentheses and the syntax of certain JOVIAL
Atatements was modified. Many of the data items had to be converted so that
the data types matched. The structure of the data tables in the common data
area had to be redefined.

6.2 Core Element Test Software Conversion

The Controls and Displays (C&D) Acceptance Test Program (ATP) was
converted from JOVIAL J73/I to JOVIAL J73. The ATP handles the interface
between the C&D devices and the test software; it also controls testing by

-117-
prompt ing the user, and it )erforns the actuaI acceptaice test. The o ,/
probl ems encountered .jring the :nnversion invol - redrlininr ine' if
data tables; other required changes ere s impe 'o make.

The Remote Terminal (RT)/Interface Module (IM) LUiagrsstics exer-

cises RT and IM hardware through a series of tests and allows the isolation
of errors. The RT/IP, Diagnostics ha, two versi ,n :

1. The original is loaded in an AN/AYK-15 processor

and uses the MIL-SI)-1553A multiplex bus system
for testing.

2. The second is loaded in an AN/AYK-15 processor, as

the original, and uses the MIL-STD-1553B mul tiplex
bus system for testing. This version was created
by converting the oriqinal diannoltics to seet MIL-
STD- 1 53B

The RT/IM Diaqnostics tests are described in tite hardware intc-gration ano
test section.

6.3 Multiplex Diaqnostics Softw'areConvers ien

The Master Multiplex System Diagnestics are a set of up to 3 tests

that test the multiplex bus system and its devices. These devices incljde:

1. Master processor and BCIU or Master proctssor/BEM

2. Remote processor and BCIU or Remote processor/BCM
3. Remote Terminal
4. Universil Remote Terminal
5. System Mass Memory

There are three versions of the Multiplex Diagnostics:

1. The original is loaded in an AN/AYK-i5 prccesso,

and uses the MIL-STD-15S.,A multiplex bus syster,
for testing.

2. The second version is loaded in an AN/'AYK-15 pro-

cessor, as the original, and uses the MIL-STD-i553B
multiplex bus system. This version was created by
converting the original diagnostics to meet MIL-STD-
1553B and adding new tests.

3. The last version is loaded in an AN/AYK-15A processor

and uses the MIL-SID-1553B multiplex bus system. The
version was created by converting the second diagnostics
to AN/AYK-15A instruction s2t.

Table 9 contains a list of the tests for all the versions. A list of
devices used in the test by each version is found in Tables 10 through 12.

The Command Generation software (CMDGEN) is a general purpose

program designed to give a user the following capabilities:

-118-
 (n Q44- 4-

-70 C 0 (U0
(A 0 S.- "0VC- -.
cc a) k-) a) 0 F- F- C.
-0 4-. (U) - .)c 0
0 (U c _0 to(a ( 0 -j
L, V - 0 c ( 4 +j c .
() E (a C) 0 4-
0~~ Co ( A ( ~ U (
0-V
o c . 0 a) Ln (A 0-. VA
C0 : S A 0 0 c C)
V0 V (U (U 0 a) c c MU
a)( 41 Va V0 N V o 0 0 S.- (
C: = 0 (U) *4 0 L - - (
0L 4- L/' C
(0 u u a) S-
-
ai I+- .- V) a) C
c~ 4-) a) H-
V 0 (U) 4) -V) >1 (a 4)
C
cU - 0 Va '(1 ) 0 0A*4 (A4-. 4-) C (C
(U~ C V H 3 LI) <: kn C )ACCA 4-) eo

V)C CC clO ca cy a: m2 C
cc co)co

4)
I--V( 0. A
a)( ~ ( C3 C)
4-
V 4
(A 0 L- 0 a) C- .- H 0
a) C-) 4U3: VH- H
V (A) 4 0 4-U_ (A
_ 0r (U C aU a-) 'u (0
< Lr C ) Co tj .- V m.. C) 4 C
0 V *4 E co' 0
>-0 33 V UU
a) a) (
j C- Cp r o 0 H 0 0 0.L (A
c N V0 V j :
MU X (A) c CD .
a) -a(U4~ (U 0 cU 0<c 0 co) E
a 0 V0 N V V0 S- S-(
0 0 C
(D 4-J C.. SCA -C AC (0

V C) 4- -- I U >1H >, H- ( H
C - 0 (U 4-l V (A (A 4
- U . ) :32 V (U C 0 < C: Q)0)
C: cV H0
- S- S- (U -
4 C) C CD C)D
::D => * a) =a ) S- 0
LA- -C - '4- - 4- MU 2: E U-
- C C. C) .-) .-) - - - 02 C) .) 0- C-. (U

-) C ) C
Ln) 2 0 0 ) C O C O 0

4 c
(A 0.
Vj S- V0 (A (A (A
cc (A 0 -. 0 a) a) a)
H- V0 LA~
0 Cr (Uf
a) ( u
C
0
~'
V Fo
V
Q
a)
C
4-U 4JCC.)'-

32 3 3 V3
0 (U3
M 0 - 0 0
(U V:
c4 (U a:U
-- C C 0 V N S- -
0- 4- CACC ) C. .
CL 4 a) (u (a C
cC c

MU
4 C)
=
)
V CD
7-
H- 0
M2
C)
V-
0
:
::D
(U
Vo
4( A
-U
oD
V)
C
1/)
V
>1
LA
:Q
::D ~.
(A
<:
>1

S.C L. L.
-
C C.C.) C .. H- H- H-L- ) C) D
C. 0
C
m co
CO on 0if 2
CC: 0 ) ca ca V) V) VA

F-
(10 ca Cj CI) - r O
co) 0mf CD - C\J ('1
L.J 'I .
 CCL

U-V ) V) V) )

4- ) ) 0a ) QC)
ca C) 4- '- 4- '4- 4- 4-
rn 0 Uj) L/ t4 LIA
) V)

C) C) - S.- S.- S.- L -- U)

(A. VS
I J ~ 9- - 9- -99F9 F-- F-
SC7 0)
W
F- H
CU -

r - ro 10 M C)
a (C C
0C)z ) - 4-) 4- 4-) 4 ) 4+ 4-. 4-)4J '- 4- m)

4-> CO ci C:) CD C7: CD CD ~ a) C)

USm -o In Ci V) C) C .. S.- S- L - -

C) o 0 0 0 0 c . -
0 0 00 C

4-)
- : '-
~r Un
~ C
Ul
.
U
~ L/S U S U) 0.n
C) 0)

L) c c z mU ) V) V) V) A L)
a) 0 >) >) 5 > >1 C C C ) C
m) 0

H--

m C A V) AL
(.9 L) O - c: C : >

CD. S.- & S£ - S. .- S.

9- C C) - - 4 4 - 41 4- 4-4
2,5)~ U) C) I A 'A ( ~ Jm)

H- 4)l U/) C) V) A) V) ) C 4- 4'

c). o-C 0 0)

9-- 4- 4-)
So-/) 4.) 4-
S. S.. 4-) - :7 4-)
4j1 a) L" Ln -C -C LOC) C
-- C).U
0 a) a) u a) 0~C
CO o FC C r- C--
c)n( 0-

40 £. .-
V)- V4)4) 4- .
4-) .CU 51) CU CU a) a) C)'

0n 5- 9) .51 0 0 4- ) 4-A +) U S- S.
- C OH LC- CH- cm-C-
) U I ) C )~
-~ ) 0 >5 >5 5 > >5 C) ) C (C CC. (C

S-~C (A (A V))

0* >) >) >1CL c

Un
) V') V) ) C.0
(.n 4/) 4/-a

C) C) 00 C C) 5.zT.r
C\41

-- 4 C) C) C) C) C)
CH- C) C) C) C)
L'C
A51 4) 4) 4)4J . ~ 4) 4 ~ +-

H- ~ ) C) ) C) ) C)120C
 >

ncc

-I o

CD :3 : C uO
0 0 L"

V) 0 0 :3 :3

4-

Ln

(-)

-D

C) )I-

< >C
C4-

-I 0

Lc) 0.0Ln4

S- LA
-A

0~41

a)Lr
aC Cl

F- CY-

V) C~ Clj fl) ( n
 +C4K4 4 4 4 4'4 4'
4 414
41 41

- II4 4( 4'41c,
I ~ >< 4'>4 ' 4-<- '~ '4

-K f'-9 4 4'c 4 ' '4

X I' ''4i4'214 -1Z2 4'4

4'''44
C)) C)4 C 4

L 4444494 4'k

k~LiJ~L. -. Jk

I~ ~ (Id *d I*

U.".
N' (-) 4' ' 14 4 4 4K
41411114 '4
(I L < >>> <' '44 '<> ' >Z < 4 '4

:,j \Irn :I L) .0r-4o'5 c 4' 4T 4O D -Cj( n4' 4', -C T : 4'o

4'4 4' '4 (Id 0CZ3 4'j 4'i Y ( 4'

-122-' ' '4

 >< >< >< >< ><>

tit

X 4< 44><>
4 4 4
I- 4 4 4

C)- U4 U- LA 4

F- C4 4- 44
Vf) M4 44
M

w uD
LU LUN
icU

LI)

LO4 *
-J - 4 4
L/ /) * it4

L/') a4 4

74 44 j ~ 44
Cj (\ \ \ )C

C?) 41234
 LO'

cc >< >
C) ZD
.Z:'
CD'
M4

4'
LL- 4'i
>- 4

L'4'
L'4'

V/) I 4DC'

U') Of 4<' >< < <

- l 4'

LALU

u-o LnCl i M : Li %

<U C) J C> C l c ) % O a

4124
 C

(n
LO)

c- c

(-)

C..)

w) V) :D
>- F-

ui L >

Lu

F-

Ln r-- M Cn
- C, C%) M% -TJ (%O eki r- ) ~ (c
C>) C%

I-

-12a

-- -------
4
 I. build and execute up to .,) ur; , ,'.tuct ,i ,.
These ins t t it, :cw o hr.iuou
toJafM. G, r +
oe seri on th, un ltipe,, b'aL ly t+t '

. -)pecify the data to be sent on the mult"plex tu',

by the BCM.

3. Load BCM registers.

Specify the bus address used by th [3CM control d

Dy CMDGENI.

5. Caube toe B3 to run i - i tOer inatr remot e mode.

There are three versions of CMDGEIN:

1. AN/AYK-15, MIL-STD-1553A
2. AN/AYK-15, MIL-STD-1553L
3. AN/AYK-15A, MIL-STD-1553B
Tne development of these versions. was similacr to the duvelopnqet of the Mat-
Multiplex Diagnostics.

6.4 1750A ATP

The AN/AYK-15A Acceptance Test Program (ATP'I was converted to test

the MIL-STD-1750A. The ATP consists of extensive tests for each instruction
;n the instruction set. The first step in converting .the ITP was to defirl t,,
differences in the two instruction sets (MIL-STD-1750 and MIL-STo-1750A). An.,
differences in the instruction sets resulted in differences in the two AtP's.

Differences include:

e Several instruction set changes ,!,re made (PFRrand FR

were combined to make RCFR. for eYaipI_.

a New interrupts were defined.

e New options were defined (such as expanded nenicry).

* Stack was made to incremenit in opposite direction.

Fhe general instruction modules required minor changes because of

instruction set differences. The executive module needed to be modified to
include new interrupt handlers, stOck difference:, and sore xpan'Jed memory
processing.

Several new tests were written to test the expanded memory option
and the various options associated with expanded memory, such as access lock/
key, E/W, bit, and payc register operations. 1hese modules were written as
stand-alone tests. New tests were a!so written to test new instructions such
as BEX (branch to executive) and VIO (vectored I/O). These were designed to
be run with the executive nodce.

-126-

"1
7.0 HARDWARE CONVERSION

The hardware conversion of the DAIS ITB consisted of upgrading the

CIU's and RT's to be 1553B-compatible and subsequently replacing the BCIU's
and associated AN/AYK-15 processors with the integrated AN/AYK-15A processor/
'1M. The integration and test of the AN/AYK-15A is described elsewhere in this
•aport. This section will concentrate on the multiplex conversion.

.1 Multiplex System Conversion

Shortly after MIL-STD-1553B was formally approvLd and published, the

'AIS Problem Report Board (PRB) appointed a working group composed of AFWAL and
,,ritractor personnel to perform an impact assessment of converting DAIS to the
fw standard. The working group identified issues, developed technical approaches
-., resolving them, and drafted costs and schedule plans for accomplishing the
-rnversion. Based on this plan DAIS management elected to perform an in-house
-version of the BCIU's and let a sole source contract for the upgrade of the RTs.

The impact assessment report identified twelve technical tasks as

'lows:

# Delete Message Error, Busy, and Terminal Fail Bit

suppression for Transmit BIT and Transmit Last
Command.

* Update Last Command Register for Transmit Status

and Trdnsmit BIT (previously not updated).

e Design/implement new system control procedure for

RT Asyrchronous protocol which does not require
the reset mode command.

e Design/implement new system control procedure for

interprocessor asynchronous protocol which does not
use status embedded ARV or require reset status code.

e Define/implement a Reset Built-In-Test (BIT) without

a Reset BIT Mode Command.

@ Define/implement a new bus shutdown procedure using

1553B Mode Commands.

* Implement RT/Subsystem Retry at the RT/IM Level.

* Change/delete mode command assignments for DAIS/

1553B equivalent command.

e Do not suppress the husy state in the status response

for transmit status.

a Assign a new asynchronous .ubaddress.

-127-
 * Include subaddress 31 as an additional moie Leiia,''
indicator in both Master and Remote BC'r.;.

* Re-assign all status bit discretes.

These tasks reflect the fact that whereas 1553A had left rode code
definitions optional, 1553B spelled them out in detail and did not include
all the mode codes DAIS had defined. The more significant differences were
in the areas of asynchronous operations, RT/IM error handlingj and the use ul
subaddress 31 for mode codes.

The asynchronous differences resulted from the fact that DAIS ha

embedded an Asynchronous Request Vector (ARV) in the status word and used a
mode code to clear the ARV after it had been read. MIL-STD-1553B allowed only
the service request bit in the status word, moved the ARV to the vector word
and provided a mode code to read the vector but none to clear it.

For the RT/IM error handling DAIS had defined a status word bit an'
a mode code, Interrogate Module Error Register, to ide, tify the IM and channel
in error. MIL-STD-1553B included neither the status word bit nor the mode c,,di

Subaddress 31 had been used in DAIS to interrupt a remote Frocesscr

(the only subaddress on which a message would cause an interruot) rs part of
the asynchronous protocol. The use of this for a mode code required DAIS to use
another subaddress for asynchronous messages in addition to the morlificaiion
necessary to recognize 31 as signaling a mode code.

It is interesting that recognizing subaddress 31 for mode cod_,s is

the only modification of the BCIU actually requiring a hardware chance. All
other modifications were accomplished in BCIU microcode. The RT mdificatior
included an automatic retry of the IM/ch6nnel in error and this was part of
the motivation for not attemptinq the RT upgrade in house.

The conversion of DAIS to 1553B was accompli i,ed ir a thvre-ori, o

effort of system engineering, documentation, ano dvelruPent. More th- n ,a,
,the total effort was devoted to documentation, resulting 'I co,:lete : e
oure element specifications fully 1553B-compatible. The finil tesLjn ,,.
accomplished in two steps, the first using a PROM simulator (RAM) to debuc: t e
microcode changes. The second step involved burning the real PROMS. This
testing was completely successful and accomplished ahead of schedule. An
additional two units were converted and provided to the developers of the AN/
AYK-15A to aid in their testing.

-128-
8.0 INTEGRATION AND TEST

The modular structure and well-defined interfact: of botn the hard-

ware and software elements in the DAIS System Architecture greatly facilitate
the integration and test. A step-by-step approach was taken to test and inte-
grate both the DAIS core elements and the support hardware and software.
Initially, stand-alcng tests were performed on individual elements. Then,
these elements were incrementally integrated and tested until the system was
completed. The following sections highlight several of the key techniques
which contributed to the successful and rapid integration and test activities.

3.1 stand-alone Tests

8.1.1 Core Element Hardware

As each core element subsystem was received from the contractor,

stand-along acceptance tests were performed. First, the contractor supplied
*est
F,AL support equipment and software. These tests were then augmented with
and SITC tests. The tests were developed to verify all the electrical
.nd functional interfaces of each subsystem. In several cases, the contractor-
,Applied tests were not very comprehensive, and the test support equipment did
ot allow complete dynamic testing of all the functional interfaces. As a
esult, specifically for the multiplex equipment, complete acceptance testing
f these core elements was not completed until the subsystem was integrated
ind tested with other system elements as discussed in the hardware integration
;nd test section below.

The AN/AYK-15A processor has an Acceptance Test Program that runs

-he AN/AYK-15A in a stand-alone state. The ATP is an integral part of the
,AIS processor qualification testing package. The ATP consists of four func-
cional types: (1) Executive software, responsible for control and execution
of specific processor tests; (2) Processor test modules, responsible for the
testing of AN/AYK-15A processor functions, e.g. instruction tests; (3) Error
processing, responsible for the processing of errors detected by processor
test modules; and (4) Interrupt handler, responsible for the processing of
interrupts.

The ATP was designed so that the minimum number of 64K loads are
required. An attempt was made to group similar -st modules within a par-
ticular load, for example memory tests and men, irite protect test. Those
tests that do not lend themselves to executive control were placed in separate
loads. Table 13 contans a list of special test names and descriptions. The
special tests and CPU instruction tests are located in the LOAD modules. A
list and description of the ATP load modules is contained in Table 14.

8.1.2 Executive Software Testing

The DAIS Startup Loader was also tested. A set of application

tasks were developed which send messages to the C&D for display. The displays
(on the IMFK) were sufficient to inform the test operator of the state of the
software in each of the processors after inputs to the Processor Control Panel.
Several problems were uncovered in the Startup Loader, Executive's interface
to the Startup Loader, processor, and the BCM. After these problems were
corrected, the Startup Loader performed as required.

-129-
 TABLE 13. SPECIAL ATP TELT NAMES 'NU fi-cAk:'T10t,,

NAME DESCRIFT IUN

HANGT Randomly generates and executes a (PU instruction list.

GENREG Verifies capability to read/write the sixteen qeneral

registers.

STATREG Verifies capability to read/write the status word.

ILLIO Verifies proper interrupt and fault register setting upn

execution of illegal I/O instruc + ;o ns.

ILLINT Verifies proper interrupt and fault reoizter setting upon

execution of illegal CPU instructiors.

WRPRAM Verifies capability to read/write che menoty I.rotect RAV.

BNCH Computes processor throughput.

TRGTST Outputs trigger GO discrete.

DISCRT Verifies proper operation of external discrete lines.

DISABL Verifies that no interrupts are handled immediately fol Ov.-

ing a disable instruction.

ROMTST Verifies integrity of the bootstrap ROM.

PIOTST Verifies proper operation of PI lines.

TIMER Verifies interval timer values with and without inter-.t .]

INTERT Verifies capabilities of handling, masking, and clearing

externally generated interruots.

INMASK Verifies capability to readiwrite the interrupt mask.

BCMGEN Verifies capability to read/write the sixteen BCM qeneral

registers.

BCMCN1 Verifies capability to read/write the sixteen 6CM control

registers.

BCMCN2 Verifies capability to multiple store, compare and perform

bit manipulation on the sixteen BCM control registers.

-130-
 TABLE 14. ATP LOAD MODULE NAMES AND DESCRIPTIONS

NAME DESCRIPTION

BOUND.OBJ Boundary test

HANG.OBJ Hang test

ICTEST.OBJ Instruction counter test

INDEX.OBJ Index test

MEMADR.OBJ Illegal memory address accessing test

MEMTIM.OBJ Memory access timing test

MEMTST.OBj Memory access and protection test

PWRDWN.OBJ Power up/down test

LOAD1.ABS Executive-controlled tests 000-063

LOAD2.ABS Executive-controlled tests 064-097

LOAD3.ABS Executive-controlled tests 098-000

LOAD4.ABS Executive-controlled tests 098-111

-131-
8.1.3 Appi cation Software Unit Test

Unit testing of the Application Software was perforted ,n t'.

computer, a DECsystem-1O. At this level of testing, the !oic oDra'_ ,r
of each single task was tested. Acceptince Test Program5 j7 (rid
c'
support programs were written to implement the testing.

The support programs required for the testing include the followic.
1) a version of the DAIS Executive that runs on the DECsystem-IO computer, Ind
2) a data area similar in function to the data base created by PALEFAC.

Each ATP generates data to be used as in[,ut to the prograi;; belr,q

tested. Using the executive services it places the input data in the data
area. The ATP then invokes the MSW program being tested. The MSW procrj:
accesses its input, executes, and places its output in the common data area.
Finally, the ATP accesses and then prints the results of the test. The
testing process was automated so that retesting can be easily accompli',hed.

8.1.4 Environmental Model Tests

Acceptance testing was performed on the DAIS Models Simulation

System (DMSS). The acceptance test was performed at three levels:

1. Stand-alone test - a verification of responses by

the DMSS to simulated inputs.

2. Interface and Functional test - a verification of

internal DMSS communications and outputs to the
DMA-10 window.

3. System test - a validation of the entire DAIS system.

Stand-alone testing was performed for each individual model. The

test load module consisted of a tailored test driver and the model being;
tested. These tests were run on the DECsystem-10 computer.

The interface and functional test was performed by insert'nd TC'

sensor model being tested into the baseline model set for all other model.
Then, using the mission scenario generator (MSG), the response of the new
model was recorded and then compared with the response of the baseline model
set. This process was repeated for each model until all sensor models were
individually integrated and tested.

The acceptance testsrevealed several problems that required

resolution.

8.2 Hardware Integration and Test

Incremental integration and testing was performed, as each sub-

system became available, until the system was fully integrated and tested.
The key to the successful integration and test was the development of exten-
sive test software. Four major test software programs were developed:
Multiplex System Diagnostics Software, Remote Terminal (RT)/Interface Module
(IM) Diagnostics Software, Controls and Displays Acceptance Test Program
(ATP), and Performance Monitor Interface Unit (PMIU) ATP.

-132-
 The Multiplex System Diagnostics were previously described in the
Multiplex Test Software Conversion section. Sample Hardware Configurations
for the AN/AYK-1SA Multiplex Diagnostics are shown in Figure 47.

The Remote Terminal (RT)/Interface Module (IM) diagnostics exercise

RT and IM hardware through a series of tests and allow the isolation of
errors. Each test is designed for an RT or a specific type of IM. The diag-
,iostics run in an AN/AYK-15 processor as shown in Figure 48. The device(s)
to be tested is attached to the MIL-STD-1553B bus. The user specifies the
system configuration and the tests to be run. The diagnostic's executive
then sequentially calls each test selected. Each test that is integrated
with this software is required to do the following:

1. Perform its own error checking and reporting and

maintain error counters.

2. Perform all BCIU control including interrupt

handling.

3. Return t!,e following items in the same state as when

the tet was called:

a. BC:j registers
b. All interrupt vectors
c. The BCIU subaddress pointers

The Ihandling of all errors by a test are controlled by user-specifieo

,urametes. Ine trror reporting for each test must interface vith these para-
,eters to allow the following options:

1. Stop on errors and allow the user to retry the

failing sequence or go on to the next sequence.
2. Do not display errors but maintain counts of the
different types of errors.

A list of RT/IM diagnostic tests in found in Table 15.

The Multiplex System Diagnostics and the RT/IM Diagnostics were

developed in a structured and modular fashion so additional tests could be
readily added. Several of the key features of the above software test pro-
grams were:

a Testing of all functional areas of the core elements

under test.

a Testing of functional areas with extensive data

patterns with error checking under test software
control. Many failure modes were bit pattern
sensitive and/or intermittent requiring a large
number of data patterns at the system operating
speed in order to detect and isolate.

-133-
 HARDWARE CONFIGURATIO N
FR E

AN/AYK-15A

: I SYtSTEM 'BCM
{DIAGNOSTICS1

(This runs the RT undefined Mode Condes Test, RT

Initialize Terminal Mode Codes Test, and ,T M4TU
Shutdown Mode Codes Test.)

FIGURE 47. SAMPLE HARDWARE CONFIGURATIONS

-134- 1
 Rl HARDWARE CONFIGURATION

AN/AYK- 15A
UCSYSTEM ' CM
I C DIAGNOSTICSIBM

PDP-11

~URT DYNAMIC

TEST R
CRT SOFTWARE

DAN/AY K- 15
C REMOTE

CO SOEMULTIPLEX , BCI U

UCELI DIAGNOSTICS

BUS ADDRESS )

/ Y
A -1 5 -

tREMOTE '
... i I 1"...I<"
'
:,l
-
I -
IE
II~~~~~R
ML
 AN/AYKK15

~EB,~[ IJr 1/

DAG N . I

-'T

FICT2'E 48P BLOCK UIGR9 0i fARE WA10 L

bN THE ~ ?1DIAGNOSTICS

-136-
 ;AbLE 15. RliM )IAhNOSTICS T[TS

rEST TEST NAME

NUMBER

0 Initial polling
I Spare
2 Spare
3 Spare
4 Spare
b RT undefined mode codes
7 RT initialize terminal mode codes
7 RT MTU shutdown mode codes
8 Spare
9 Spare
10 Spare
11 Sinqle-ended discretes in out
12 Differential discretes in/out
13 Switch closure in/out
14 DC Analog in out
15 AC Analog in/out
16 Spare
17 Spare
18 Spare
19 Momentary in
20 Synchro in/out
21 Serial in/Serial out normal operation)
22 Serial in/Serialiout (parity error op eration7
24 Remote terminal to Remote
25 Spare
26 Spare
27 Spare
Spare
29 Spare
30 Spare
31 Spare
32 Spare

-137-
 * Segmenting test software to functio , ,ceas oi tie
hardware under teslt.. ,is fa. -
tion oy llowing tht, t ,c :, ,;IT- o0
running test soft.wad e on tin: faiiii~ llEi t,'
(-I

e Providing stop on error and loop on, sctioli, stn..-

section:, and fail ing data pattern. Th,, fjC i itdted
problems isolation and provided conditions under w,'hch f,
problem (even i-termittent) could be souped' or tracedC
with a logic analyzer.

* "enerating data pitterns at execution rott_ MI,

coisraracle to the nomarinl operation rat,: fIr- tfe eu p-
ment ander test. Many failur_ modes wLiu iduceo only
at or near maximum data rates because of noise, -,iqmal
line "ringing" or "cross talk" tnd other highspeed
phenomena.

* Sequencing through all phases of the test repetitmvel 1

(looping) with error checking. Capability al'owed
equipment testing for thermal, noise, and other inter-
mittent errors, and provided a high deoree of conf dencr
when equipment operated successfully for extended
periods of time.

* Supporting system verification prior to loading an,,

running mission software, and supportiino probieM
detection and isolation durina mission software ciiecout
and predemonstration phases. System intelrity wai
established before loadlnn9 mission software so missior
software debugging would not be plagued with hardware
pro bi ems.

* Providing structured and modulav test software to

facilitate development in stages and to aolow incus Ur
0

of test software Itom varijus sources.

The C&D AFP performs two major famic ioC' to ~ti1(7 th- C.&. i,.
nandles the interface between the C&F devices 'rd coo teat sc'twit'. T
interface programs are called EQUIP's. Secondly, it controls execution bv
prompting the user and performs the actual test-. 'able 16 briefly describes
tie programs comprising this ATP. Figure 4) presents the hardware confiqun.-
timn; used in performing the tests.

The AN/AYK-15A Performance Momitor Interface Un. it ([MiiU) Ac eptanco

Test Program is an integrdl [art of thc [NIU "o. Ication package. The FMI'
ATP consists of three functionai types: (,) Interface test software, respons-
it le for the testing of the PMiIU/PDP-11 interface: (2' Control and monitor
test, responsible for the testing nf PIIIY control! ac monitor ounetiuons, (3)
Post run editor, responsible fo- thc formattinq mcd processing of Jata gatnered
during PMIU testing.

the ATt' was designed so as to alow ),,er I1iectives via interactive

or disk file inputs. lhis will facilitate the u(s,, of the" Pll ATP for AYK-15A
software development. F igure 5C ;hews the 1"'1. t:i !rd interface require-
men ts. Prior 'o execution, the AP -,oft.ware m, t be o.)ded into trie 'lT[- II
with all appropriate devices as shown in [mire Y).
[ -138"
 TABLE 16. CONIROLS AND DISPLAYS ATP

Task Description

EQUIPS:
QPO1IMFK'IN IMFK input equip for RT 16.
QPO21MFK'IN IMFK input equip for RT 9.
QP03IMFK'ARBIT IMFK input arbitrator task.
QPO4DEKI'IN DEK-1 input equip for RT16.
QPO5DEKI'ARBIT DEK-I input equip for RT 9.
QPO6DEKI'ARBIT DEK-1 input arbitrator task.
QPO7MMP'IN MMP input equip for RT16.
QPO8MMP'IN MMP input equip for RT 9.
QPO9MMP'ARBIT MMP input arbitrator task.
QPJODEK2'IN DEK-2 input equip for RTl6.
QPIIDEK2'IN DEK-2 input equip for RT 9.
QP12DEK2'ARBIT DEK-2 input arbitrator task.
QP13MPDG1'IN MPDGJ status input equip for RTl6.
QP14MPDGI'IN MPDG1 status input equip for RT 9.
QP15MPDG1'ARBIT MPDG1 status input arbitrator task.
QPl6MPDG2'IN MPDG2 status input equip for RT16.
QP17MPDG2'IN MPDG2 status input equip for RT 9.
QPI8MPDG2'ARBIT MPDG2 status input arbitrator task.
QP19MFK'IN MFK input equip for RTl6.
QP2OMKF'IN MFK input equip for RT 9.
QP21MKF'ARBIT MFK input arbitrator task.
QP22SA8'IN SA8 input equip for RT16 and RT 9.
QP24SA9'IN SA9 input equip for RT16 and RT 9.
QP26SAII'IN Detemine the state of the PCP.
QP5OIMFK'OUT Displays data/pages on the IMFK.
QP51MMP'OUT Outputs light commands to the MIMP.
QP52SA6'OUT SA6 output equip for RT16 and RT 9.

TEST SOFTWARE:
CPOOINIT Initializes data and schedules equips,
calls CPOI to begin execution.
CPOITEST'SELECT Allows the user to select major test
categories and then schedule the
selection. Currently only CP02 is
available (C & D test).
CPO2CD'TEST Allows the user to select which C & D
device he wishes to test and then
schedule the selection.

-139-
 TA BL - 6. t.NT PO L ,

Task Descr iptt ic:

TEST SOFTWARE Cont.

CPOS,1P' [EST Turns on/off M¢,IP lights when respect-
ive key hits are made.
CPIOIMFK'TEST Turns on/off IMFK lights when respect-
ive k,_y hits are made. Displays
all applicable characters on CRT.
CP15MFK'TEST Turns on/off MFK lights when respect-
ive key hits are made. Activates
all back light displays.
CP2ODEKI'TEST Echoes back on IMIFK the value entered
on the DEKI.
CP25DEK2'TEST Echoes back on IFK the value entered
on the DEK?.
CP3OSCU'TEST Allows the user to select which SCU
device he wishes to test and then
schedule the selection.
CP31SCU'KEY'TEST Turns on/off SCU lights when respect-
ive key hits are made.
CP32SCU'TRIGGER'TEST Displays trigger leve l on INFK.
CP33SCU'ROCKER'TEST Displays rocker position in IMFK.
CP34SCU'CONTROLLER'TEST Displays the numeric value of the SCU
controller and terminates upon
hitting the controller switch.
CP35AP'TEST Allows the user to select which arma-
ment panel device he wishes to
test. and then schedules the sele-t-
ion.
CP36ARM'PANEL'TEST Displays the stati- of AP sw:.tches cn
the IMFK.
CP37MASTER'ARM'TEST Displays the state of the master an
switch on the IMFK.
CP38SALVO'SWITCH'TEST Displays the state of the salvo switch
on the IMF,.
CP4OHU Displays the state of the HUD switches
of the MMP on the IMFK.
CP45MPDG'KEY'TEST Allows the user to select which MPDG
display he wishes to test.
CP46VSD'KEY'TEST Turns on/off VSD lightswhen respect-
ive key hits are made and displays
range switch state on IMFK.

-140-
 TABLE 16. CONTROLS AND DISPLAYS ArP (Con't)

Task Description
TEST SOFTWARE Cont.
CP47HSD'KEY'TEST Turns on/off HSD lightswhen respective
key hits are made and displays range
switch state on IMFK.
CP48MPDi1'KEY'TEST Turns on/off MPD1 lightswhen respect-
ive key hits are made and displays
range switch state on IMFK.
CP49MPD2'KEY'TEST Turns on/off MPD2 lightswhen respect-
ive key hits are made and displays
range switch state on IMFK.
CP5OPCP'TEST Allows the user to test either the
input or output function of the PCP.
CP51PCP'INPUT'TEST Displays the status of the PCP switches.
CP52PCP'OUTPUT'TEST Turns on/off PCP lights in a pre-defined
order. Also, forces the processor
to issue PCP latch commands, which
may be tested by the user.
CP55STICK'TEST Displays the status of the stick
switches and trigger on the IMFK.
CP6OTHROTTLE'TEST Displays the status of the throttle
switches on the IMFK.
CP65RT'CONTROL'TEST Allows the user to select which RT
is primary and whether the I1FK
or MFK/MPDI display is to be used.
CP7OMP Allows the user to select which function
of the MPDG is to be tested.
CP71BOOT'MPDG Allows the user to boot, load and
execute an MPDG.
CP72MPDG'STATUS Displays the status of the MPDG.
CP73WAYPOINT Allows the user to select the various
options concerning the activation
and control of the map driver.
CP74TABLE'CONTRL Allows the user to read, modify and
display text tables.
CP75TASK'ASSIGNMENT Assigns tasks to MPDG displays as a
function of user input.
CP76MASTER'MODE Allows the user to select various data
sets that are used in MPDG displays.
Also allows symbology to be turned
on/off.

-141-
 TABLE 16. CONTROL 5 AND DIS LAYS AFt (Con' t)

Taik Description

TEST SOFTWARE Cont.

CP9ONAV'UPDATE Calculates aircraft position based on
its velocity vector and current
position.
CP95WAYPl'DISPLAY'TEST Allows the user to test the various
functions associated with the way-
point display.
CP96DECLUTTER'TEST Allows the user to select various de-
clutter modes and observe the re-
sult on the MPDG display.
DP51MAPUPDATE Determines which map chips need to
be loaded and sends appropriate
data to map driver.

I
 CONFIGURATION 1:

CONFIGURATION 2:
MUX BUS

ou;J I(iukAT IO; 3

:U
U

CONhFIGURATION 4:

fs R
*PRIMARY RT

FIGURE 49. HARDWARE CONFIGURATIONS FOR TESTING THE C&D

-143-
 UN IBUS

VT52 C0O4PATIBLE CRT

DISK
STORAGE22

PDP- 11

TELETYPE OR
LINE PRINTER

UN I BUS

FIGURE 50. PMIjU INTER~FACE DIAGRPAM

-144-
8.3 System Readiness Test

The System Readiness Test (SRT) is designed to quickly test the

operating condition of the DAIS Software Test Stand (STS) or the Integrated
Test Bed (ITB). The following systems are tested:

1. PMC and SSDF PDP-11/40s

2. Console Intelligence Units (CIU)
3. Super Control and Display Units (SCADU)
4. Remote Terminals (RTs)
5. Universal Remote Terminals (URT)
6. AN/AYK-15 processors and BCIUs or AN/AYK-15A
processor/BCIs
7. Bus Monitors
8. Performance Monitor Interface Units
9. Evans and Sutherland System
10. DAIS Controls and Displays

The following group of programs forms the SRT:

1. Control file that runs with the PMC software or

the PMIU software
2. Assembly language programs that run on the AN/AYK-15
or AN/AYK-15A

3. A FORTRAN program that runs on the DECsystem-1O

4. Post run edit files that run on the PMC PDP-11/40

The programs work together to perform a quick check on the above hardware in
jess than 15 minutes; therefore, the DAIS users could run this software every
;orning and before demonstrations to insure the DAIS systems are in working
order.

d.4 Results of Testing AN/AYK-15As from Two Contractors

This section describes the tests that were performed on the

Westinghouse and Sperry Univac AN/AYK-15As during 1980 and early 1981. A
summary of the test results for each vendor and a summary of the compatibility
between the two implementations of the AN/AYK-15A are included.

8.4.1 Inventory of Tests

The tests performed on each AN/AYK-15A include:

* Execution of the Bootstrap Loader

e 3-Processor Executive Acceptance Test Program
e Processor Acceptance Test Program
* Multiplex System Diagnostics
e Bus Control Module (BCM) Error Response Tests
* Input/Output and Internal Tests
* Miscellaneous Tests
All of the tests were performed with both AN/AYK-15/BCIUs and other AN/AYK-15As

from both vendors.

-145-
b.4.i.1 -bootstrap Loader
The Bootstrap Loader was used to load all of the 1h test soltw,,
programs from the PDP-I1/URT to the 15A processor memory over the 15..
multiplex bus as illustrated in Figure 51. The software program in the PlY-
was used to simulate a mass memory device on the multiplex bus. Software
resident in the upper core of the 15A memory was then used to iritiat: the
BCM as a bus controller and transfer application and test software and ddta
from the mass memory device to Lhe 15A processor memory. 64K words car, be
transferred in approximately 15 seconds using this technique.

8.4.1.2 3-Processor Executive Acceptance Test Prograin LATP)

The 3-Processor Executive ATP with the AN/AYK-15A as the unit under
test (UUR) was executed using the test configuration shown in Figure 51.

6.4.1.3 Processor Acceptance Test Program (ATP)-

The Processor ATP (15A, 1750) was executed using the test confi4-
uration shown in Figure 52. This set of software programs was used to test
the entire instruction repertoire and functional capability of the 15- ,ro-
cessor.

8.4.1.4 Mutjijpex_ System Diagnostics

The Multiplex System Diagnostic tests were executed using tne tes,
configuration shown in Figure 53. The software programs were used to test
the Master and Remote mode functional requirements of the 15A BCM and the Pi
processor interface. The software in the PDP-11 was used to simulate rlultiple
kTs via the URT.

'8.4.1.5 BCM Error Response Tests

BCM Error Response tests were conducted to test the performanct of

.ne 15A BCM when errors occur on the multiplex bu and were accomriished usiiq
the test configuration shown in Filure 54.

;,.4.1.6 Input/Output (I/0) and Internal TesLs

I/O and Internal tests were conducted to test the input and output
requirements of the AN/AYK-15A (e.g., program,,ed input/output, direct memory
access, interrupts, etc.) and to verify the reolution of unique problems
encountered during the debugging stage of the iSAs. The test configuratior
for the I/O tests is shown in Figure 55.

8.4.1.7 Miscellaneous Tests

Investigations and measurements were made to obtain additional infor-

mation on the performance of the AN/AYK-15As. Of particular interest are the
measurements of memory access times with CPu1, DMA and BCM memory contention on
the Sperry Univac AN/AYK-15A and the measurements of the Master mode BCM start
and stop times for both the Westinghouse and Sperry Univac AN/AYK-15As. A
summary of these measurements is given in section 8.5.2.3.

-146-
 LJ

LI

LAJ

C)
Lf)

LOL)

LJ

IL-

'4-

C-)

I-

LL/)

IL-

-147-
 C-)

-148-
 U

of-

LU

-
Ln~

cH-

-149-
 LU

LOU

C) cl

Of C)

- ~L~
of

'CC,

In

C)
U-1

44~u~t
 L
LO )

co LO

>- C3

LW

LJ

Co
LO
3 ssss! -

-cc-

1/C)

LAL

CLJ~

=u
ofL

:- - >< >C

LLA

co

4-I-

-Dmi.
 L Rtesu i L .T -t I

aInd SPerr) J21li'

v. I %, A . . i - :I' "
The un its atter (ver-,, iLvr tlori-, u,
ot IUI'u
CT(-AL V- IoI i, .
test resuIt asSLocijt(ot , ,i it h tth i V i mit,
lt f ui f': '!
of informal test rcports.

,.4. .1 Test Retultm r 'Aestu 5ous .k/,YK-1 b

Ti e boot tr ap Loader and tLhe -P es(cr Lcuti ve A; were - xecu t':

without incident. Tables 17 t!,rutqh 11 ino cate the 'esults, Vf the Processo,
4TP, Multiplex System Di agnost .s, and oCR. irrur P-n.e t , r - pect i ve .
that failed on the Westinihousp ANiAYf-1." . " le 2 jimo rizes tne result,,
of the I/O tests.

0.4.2.2 TesL Results for Sprry _ vac ./ I 15A

The Bootstrap loader and the 3-frocessor ,-(.,jtive ATP were execute,,!
without incident. Tables 21 thro q . i t,(Iik.:a, the re2 ult of the Processor
ATP, N'ulLiplex System Diagno-tics, aind BC, L, ror Re- uicse tets, :i--s[rctively,
that failed on the Sperry Univac AN/4tk-15A. Table 2 summariz , the,-result,
of the I/O tests.

8'.4.2.3 Results of Miscellaneous Tests

Toe results of memory access t a s

summarized in ,l 25 and
'.ere rmeasured on the Sperry Univac AN/YK 15A K.')totyp ea-y in ,ay uf 191K.
,he results of measurements taken on toe iB/AP' - ubotn vendors for the
m tro
'Yaster mode BCM start and stop time, under va rious conditions are u-r ariz i
•,r Table 26.

U.4.3 AN/AYK-15A Compatibility

One of the original goals cited for ttie dual source procjrement of
-he AN/AYK-15A digital processor was to a,certain the feasibility of ',roc;,, 1)
iatIblc
t 15As from two vendors util izing different in ,,lemerltat ion to ie e
tre same requirements. To achieve this v-esult. tr c:it lo c;. ;Pecifi,rK"
necessarily be:

1) general enough to support rather thin supplant t-ir

design and implementation of the AN/AVK-15A, and

2) specific eno gn to avoid multiple interpretations

and .nclearly specified renuiremerts that lead to
incompatiole performance.

riu addition of the specification chunqeswas made, in part, to improJve

the specification and eliminate those areas of tne specification where incom-
patibiitv issues had been ouserved between the two vendors.

.T eirp] ,ieasure o' Lonqotib ify : iwIeert t',e Westinghouse ard

",,)err, )niivj( , - t¢, Ur :,ucsrt itution of eitler 15A into a
irlv \v
-
r,,
y . . jn ira t lu. A;thowt cnanqus to sv>'Lem pertorii nce and without

-15?-
 TABLE 17. WESTINGHOUSE AN/AYK-15A SUMMARY
OF FAILING PROCESSOR TESTS

FEST NAME REASON FOR FAILURE

FSB Results not accurate to the least

FS significant bit on floating point
FSR subtracts.

FDB Results not accurate to the least

FD significant bit on floating point
FDR divides.
EFD
EFDR

BRX Results not accurate to the least

significant bit on floating point
subtracts and floating point divides.

HANGT TEST Execution of an illegal opcode sometimes

causes CPU Memory Protect and Illegal
Instruction bits to be set in the Fault
Register--depending on the contents of
the general registers.

BCMGEN Some of the BCM control and general

TEST registers are tied together.

Illegal Execution of an illegal I/0 instruction

I/0 Test (output opcode with an input operand)
that deals with the BCI control register
0 or BCI general register 0 causes BCI
to generate an interrupt when the GO bit
in the PCR is zero.

-153-

- . t iA
 TAB E i A I U UU ii
Oi MU'IU
L[PE:u ACS I. :
TEST
NUMBER IEST NAME NA',IL ',(Li
INIT !nitializat on P P
0 Initial Polling P
2 BCI Undefined Mode Coitriands P P
3 UCI MTU Shutdown Mode Lo"ands F
4 ULI Mude Commands With interrupts F(Note I) p
5 P7 Undefined Mode Convnands P N/A
6 PT Initialize Teninal Mode Coimands N/A
7 RT MTU Shutdown Mode Conmmands P N/I
8 bRT Mode Coimands P NIA
9 Master Async to Remote Sync Transfer, P P
10 Master Sync to PReviute Async Transfers P P
11 BCM State Transitions P N/A
12 BCM Internal Operations P N/A
13 Remote Transmission Lockout Flag P P
14 Remote Reception Lockout Flag P P
15 Lockout Flag Set/Reset P
16 Master to Remote Synchronous Transfers P P
17 Master to Reincte Synchronous Transfers P 5 1
18 Remote to Remote Synchronous Transfers, P
19 Master to Remote Synchronous Transfers P P
20 Remote to Remote Synchronous Transfers P P
21-24 Mass Memory Tests - -
25 Remote BCI Self-Test F P
26 Master BCI Self-Test P N/A
27 Lockout Flag Duration P P
23 Lockout Flag on Receive P
29 Lockout Flag on Transmit P P
30 MTU Shutdown Command F(Note 2) P
31 Bus Active Bit P P
32 Bus List P
'iBADDRESS
OR MO1DE

0
31 P P

MULTIPLEX
BUS

A P P
P P

: Pas "),(11
N":ot
m1 N/A: Not Apn Iic,-bIe

tf ication
1K nter -"'.t ion Prolem (See section 8.5.3)

No Se 2 ,4esti mmouse 15A does not incorporate SCN2 changes to

SA 421 205
- 154-

.=.,-
. m _.t - U
 C4-4-)

_I_ CDCC( CDa)4

01 4- S-- Lio)%-' (A
0)~a 42 .- c C)'A i4

U Q) c\A S- >,i > 3 a) > S- )

M a) 4-) 4)(. It 4-) - - a) '
4-)4-)4 1)41' 'a
- aL) 4- C' <Z C .l' C f>, LAiC C > .
zzD vO +'j W) a.- 0- 4- 0 =0
L-) S- 0 S- c inO0 4-'a0) inO0 (a--- Ln 4-Ej t
<- cr- o L 0 4-J o -3- 3'
1-- 4) u l:O:I .0C
CQ u C\I) E nv L.S S-
a) S-e 4)WOJ oU 4A- r-. to
x )~ 4
-) 4 F- 41. S- S-~E 24-) >g
0n WCC. VUW >C CCD C (C 71

5- S.- 0 C
0: 0: a) a0 C
4J\JS. S.- >a)S- n
:3
E 3:- 4- 4) a) S..(1--0
%a aQV
) _0 L" >-0
0U)r mV )C Lf) >' U a)
X a)~ VV)d ro V.- C.S-li.- lO5
SLJH 0) S-C 0 -' 'UO-04 aU - 4-) .lC-
0- LlJ Q) a)L /
4-3 I :C (1 - *aS- 0) LAU.-

-~><0 A4-)
V1 >) ulCfl( >Wa) W - >< ra 0
4J ) S-i 'V
ra)( C 0 a) C lo> L E
10 ' 4-' > 4-' u-+4- L) 4-' +3-' .>Z 0 =
4-') aCC: Ln C .- < -0 ..- Uf.0 > -0 S- U

C 4-) (V C

0 7~ )
4-) 4C 0i C) - 2-
0'4 20. - 4JV ( a
4--' C0
3
C.) ,- (A~ CL F- 4-) *. ...-- u 0
ZDJ= 44-' t 0C 4-)-mS-O czu : 1)0E OS.-
:3 5- o - a1 0 - Sc.-.o- 0
020a) a) 0 t (V C E E La)0 c
:
Q 3
0
C
a)
X
C-
(a
><)
0 0
4J
0
~4- -0
(
S
L,:
J4 C
2 (

U4 2
E S-) U 4-bS E . EE 4-' .V
20
4-1 M0 ( 0) u3Q 0 t,-4-' c CE.-
LMV -5- S.- S-34- CA

LU 00 0 00 '
2jj-
4- 4' -
:: to I-
eo ) Ito to (at)(
V) ) - c r-( cV. 0. ' 0~e-
Co -C C 0 C CO- 4J

ES C C5- 5_5 CI
a)000 0) 00 00 00

S- - - - - F- 5- 0

IL) a) 4) a) c a) a)
w A-)
M) 2J 1 .41 4-'$ 4- 4- 2 0
0 Ii Li) L) CA i 0) ) E
~~~:t
'o( ' 0 IV to )

-155-
 00-

s-- o:: Q)a ~

S-F S i 3

(-- L ra4- l 4 -)U -o

-j~' mIt- :3t :

4- ea L -

o 41 +j m - 4-
LS~
_j+ o 3 x
o L L

L ~ *- LI

cl, LUj 10 4

5-) W V) ~ _ 0 .-.

>< L

(L
00

C5-

LUo o Q-
- 0 4-

C ~ ~ *-' 0D4 0
F--
LUj
:3 ) : L

5- dJC GJ LU-

~Lu
05a 0

':) ~ 0 000

0 E E
0) 0
C4
(A

LUJ

- Lu

C~)

LLU

V)

211
oZ
u0
V)

LUJ

0 S_ (n

(A4- .~ '-. . o c :x S_ .

LUS n -0L) S
(A ___C_0__L

a) 0
LnC o 4 4-

0. -
a)S )VIC Ca
a) a) C )u 0: O

ELU. L4J-) X . 0 J U. < <

LU- 00 COL)M-- )X( : X

1. -I-..$..-cfl L

-157-
 VABLL ZI. UtJIVAL At/AYi.- lA JIJMMAIFU
OF FAIL INkOSA TT

ES WIVI:'S' Proces~ or througriput roiturc-d at

T
TI)'T Trno CK riory [protect i; e
1 u,"c after execu'-ion (,4 trQ
ne; t ii: 'ructicn. 1h - , 'IayV
ci,asc.- th softw~are foas> c ela
vwr'te !.o*cct dic not ocrand
display an error rnessice.

Ch~c~a,') ostini cft

HI;NGT, wn v ie-rotEoct in to rr'jt f, e0
itoU' rcpt ) caus e% Cvs ul- .
t he ne yt i e l,'L ,Ct i o r , .3' (
- a
a lieve] I interrupt vwhich 1i
,oosted,(, immediately. . 1 e'-
orirtis
in thr-nofore, cerie'-a-
ci of another level] rr
ci cdjusOS t he s oftware t.
;ioin- upr i r tie i ntei-ru:,

D6 Te CPU is not Qeneratin ; a xed

Bi X (OBY; point interrupt for thie rnal est
IM (~tI) neqdtivfe number (8000 or 8300000)
D divided riy the larqe.t ren ative i-

DP be (F FF ci F) iV
08

-150--
 TABLE 22. UNIVAC AN/AYK-15A SUMMARY
OF MULTIPLEX DIAGNOSTIC TESTS
TEST
--NUMBER TEST NAME MASTER REMOTE
INIT Initialization P P
0 Initial Polling P P
2 BCI Undefined Mode Cormnands P P
3 BCI MTU Shutdown Mode Commands P P
4 BCI Mode Commands With Interrupts P p
5 RT Undefined Mode Commands P N/A
6 RT Initialize Terminal Mode Conmands P N/A
7 RT MTU Shutdown Mode Conands P N/A
8 URT Mode Commands P N/A
9 Master Async to Remote Sync Transfers P P
10 Master Sync to Remote Async Transfers P P
11 BCM State Transitions F(Note 1) N/A
12 BCM Internal Operations P N/A
13 Remote Transmission Lockout Flag P P
14 Remote Reception Lockout Flag P P
15 Lockout Flag Set/Reset P P
16 Master to Remote Synchronous Transfers P P
17 Master to Remote Synchronous Transfers P P
18 Master to Remote Sybchronous Transfers P P
19 Master to Remote Synchronous Transfers P P
20 Master to Remote Synchronous Transfers P P
21-24 Mass Memory Tests
25 Remote BCI Self-Test P P
26 Master BCI Self-Test P N/A
27 Lockout Flag Duration P P
28 Lockout Flag on Receive P P
29 Lockout Flag on Transmit P P
30 MTU Shutdown Command P P
31 Bus Active Bit P P

SUBADDRESS
FOR MODE
CODES
0 P P
31 P P

MULTI PLEX
BUS
A P P
B P P

P; Pass -: Not Run

F: Fail N/A: Not Applicable

Note 1: BCM does not generate an interrupt to the processor

for one internal operation (minimal impact)

-159-
CLC

- L-1C .A- ZJv

477) . -

C:IC

LU -- - -min
 LUL

L Lu

Lteo 4 Zo

L
V)-

co
C) S- C (-
o 0 Cl
C). C,)

LL- oLA n
C) -'C)
- _Cf-'0 ~
< 4.,

Q U0) -

CJ-' Ln
LLJ~-- 1 U-

< l -- -- - -- - C- 4--- a- S-- S.- - (A

I'--
LI) U00 L- c-C~
--I ~ L :u C

CCL

C) t/ -) :D UL
En a C)f.

co ca u '/ C

t4-
 'ALLE 25. '4,!VACAY:y- 5hEu I

WN~9 O;N NL 6 i..UL L:j 17

C-P
U B-CI DrMfA ItJTAL

bI al ly ~ YT~.

DMA Only --

CPU & iC1i 0 U0&

CPU & DMA 0.U62 - (7

DC)LI
& DIMA ",UT TL'.§Lb*

CPU, BCI & DMA 0.> k, o> .09

*BCI will not run un',ess C~ s m~in nc)

bSi S

a CPU perfoc';innu a serie,, O bl iu.dc

double store instructions.

e BCM perforioinq a series of no-op instructions.

* DMA wri te operati ons pet" orvea repet ti, (velvisir.

DAIS 1/0 exevci-,er-.

-162-
 V/)

V)

Ln N. >

4, U') NJ
I.J to
N

0J - 4J 4J

LI)

LI)

H- -AC)

uJ U*JL!) C) U)
LU: (0) ZZ of) Ln(0
0 )1 V) 0

Ln~-> -C )( 2
V) F- V) Of ;_- F- N/
4-) Li4-i CD Ofi V) <c

Ct I LL .7 -D
V. L- C)OV

< CDV k)n - V

- - - -3LI)L (
LL- OfI4of<.iV)u

L') -j LU LU I) (I):c:e
F-i CD LzuC
LI) I- (1) LL- <-c)
of Of~LH-C 0 I)
~~fl HV- H-)C
L-.0
CL
:c
LU 2: C
LI)
V) C)() LI L) C) (2 LI) i 4 ;
'd W- - A- ~ - C- ClU C:3

co
V) fi F-
C:-2:
-J F--
C-)-Z C
C)
LU
27 -.
2: 1- UL D - C) x -

U LU tf=A C- F- Cm
:
no) co H- .- : o V-- H- L/ C) 0

VI)0 - L/I off L/) -j OfX LI) (Ill -

C3 C)2:LU C)2:LU2 < LW"i -x<

V)

Q9 LUJ
2:
LI) V)CD

L U0 C) 0 C, H

I-C) C) )0

C): )

C))
-Of

L~
I ----~

- 163-
Ii ardwal Ie
, e oi
T .1 T Vo if,
IWY, Til''
_ 1 C. 11 .; ''

tJ ' L i I '!W i'' F

'iive C C aY
'ijusCe ranr )Pery MVnU I r I9' '
des a)n <Cc l fi .1 i . i i 3i * I. '
i e nta
aI ' mffi
JA ' n ' ' L
ca n be 'i~t
v ,j Ti ii Lu!t2 e u'
yT'a.':5 and ii e o t irc i I '1Wito a tiaL tocnfa i'

I' j'i' I ame w, r I " U' ' 'IF,'

e 1 3
d ''"''1

* n>LetT2-.la
F
3~~~~~~~~~~L
i'L.j t~ f I ' .''u ' U
4'e tT'C]i !(:u3s cf - 1S. u~''11! v,c ( I to tCi t ri
(_Iu 19',
ciiFS n ~ >iiF I,' t-ic F C(''iir an t

* raq~u IFti~ 'L S

ce SS0rYt I r TiJ u
a) ' 2d I a
intcnvie aq'tie.t ,mr'5 i t''Jl-
f ca ti~ CI e
4Es1t nu h Aia
ti I il- (' -O xit
Ila Lbeen
It ev (TeA
ot h: o' I Fj'I e~r 'T r it-L
I) It(Iet iN t I s LF't'srF tIle .c(2 11 r u '1 1 't

,I "c( 01r let ilt' t' t fa,-t 'tat ''0 ii

a 'il n ti ea
rCS tnte exec-ut ive L'h, 6 .
foir 'C ()Ii Let- ~ ' ti", -ni ,liC
o II'', '

*1Kn ug
2- iq j atUt 1) U
tan The 01' iinai 1 Flo' A
L 0)A dJvCei o ic i.L pe i ' I
Cr~ii 0o1' ] ' iI 'T
Pa wa ~ Lr,
i .,.,5 vIi i '-U' u -, w,
CM ,h Uo adiT! t ~''' ~ ' i 'llt
.1 Ti'
'' L A
J,.nt,
Fhl 'a 'n - '' L'pt ml ',

to incci DOat' til ' n

Iaric i'a 'es the, t wvc ' '-r lI- c 1 IaC.
No te, nawev e r, t ha t (,&ternali inte re nis sL C, enit
controlII1 leis ', i d tfil s ncF,1nPat -" I Fe f Ll riue

* )A
,,( _taj, I~he rf ' tiI.iu 1 i l' ' tr herUCI
t iei Pu1 ho~InN J3Isa . imL <i
,"e at ter a 1 a t I-' RQM
i't t;',Cis, u dS:''c :. trit. ili'ti'.at Oti 1', ;ig a
bieac W0!it IT, t.'lt Oi. a TYn''-S'I , fthe westingriouse
and LUni vac 'ItAs Ji so~ Li ticu tN, a L (-i, t Ern t t Im's. The
ROM -anrLnATJ l3Fo'j'Timw i'.'i 'rc t', i51 i'ri( ij'lIio i Li It..
 9 Exception Response - There is some ambiguity in the
specification regarding the setting of the RDE bit in
the ISR when a remote transmitter is busy. The
Westinghouse 15A, upon receiving a busy status response
from a remote transmitter, does not expect data and,
therefore, sets only the XBSY bit in the ISR. The
Univac 15A, on the other hand, continues to expect data
and, therefore, sets bcth the XBSY and RDE bits in the
IS. Since the ICR codes for this type of response are
identical in either case, the problem becomes trivial.
However, multiple status word exceptions and/or errors
on the bus (see Tables 19 and 23) can lead to incompatible
status response handling in the master 15As.

9 Power-On Initialization - Global memory protection of the

15A processor after a power-on initialization or a user
console clear command is treated differently in the two
implementations of the AN/AYK-15A. SCN 2 to SA 421 205
clarifies the proper requirements.

8.!) Fiber, Optics Multiplex System Integration and Test

The AVSAIL fiber optics integration plan was initiated to inves--

tigate the feasibility of time-division multiplexed communication over a
fiber optic bus. Because of its inherent qualities (i.e. noise immunity,
security, electrical isolation, low loss and high bandwidth), fiber optics
was chosen as a desirable transmission medium for MIL-STD-1553B.

The successful completion of the AVSAIL Fiber Optics integration

plan would make possible the operatior of real-time software simulation
supported by an optically coupled network of up to 32 MIL-STD-1.553B devices.

Interfacing between the MIL-STD-1553B Bus and an optical network

requires several considerations. Among them is the conversion of the bi-stpte
(one, zero) optical format to a tri-state (plus, minus and zero) Manchester
format. Because of this state transition, another consideration is intro-
duced: delay. In order to discern between an end of message or a command
(status word tollowed by a data sync, the optical receiver must wait a finite
amount of time before deciding whether the Manchester output should return to
zero (end of message) or remain at a minus value (data sync detected).

Manchester-to-optical encoding is performed by modulating the

optical tra; tier with the positive ha.f of the Manchester waveform (plus,
zero convert one, zero).

Tne nardware implementation of this plan has been broken down into
..,~d ifferent tasks asigned to various contractors. Singer Kearfott was
t'2
o provide optical translator units capable of interfacing any
, ,,,r'eMIL-STD-1553B device to a fiber optic network. Westinghouse
,,td u,)arate efforts to produce embedded fiber optic inter-
". '~-i processors. Under a separate contract, IBM
tnat effectively ties all available optical
 de~ tu I opt 1cad OUtp;ut dfIrUr i II. t:t i~ I IttC L. VL'tII

/tu;jlc nfLne onlvai, firu ~I es maod OcCC..t IL! 0p, i.Ai I..1
d I (OfIi Imu 1 ty l~as no~ti lI i t Iif L it or ' rda t. fC
Ile so T(Ien,

A itUh uth modu i ml, the LL k Wa's acceptablIe ir Loth fr)( if,
luwer- optical ly received power ranges, out a total A oi'i *val~r,
.oins
ouserved between theii.

,Af(ter verityinq tni. existencct ol The prh mw~th thi-

imodoui es were returnued to on ivac tot duol IYS IS. Tn e uoIn
IIe,_ _s were . v
avai lat~ie for -'etes-timy at the teruounition ~iu
f cutuut

t it the ol', 111. ton 01 thi ltui il .lu V i~

os .12S Una3V i
m.OdWU :1dIcoL' for- t st i rl

curing the first quarter of 1981, testing and developrient ,,fi

,lit 1c:ve, Lasi. ias conducted on the eirciht otical translator- nitS
-le ivered by Sunqer Kr titt.

02rtai10 uohi eiutic condi tin

105 x',,PjI orictrCi j tri 'A -

lb~ty ti tn tie 4'""Smu ti pie,. bnk<C 1 1

Lerrilrat ioni in' part 1co dr. Atter true
pr-UCI iemt'ei're0O ved, wor
c_,iitifiueain the .ireas ot hardware debuggirig ird Ili t level crara' tor 17catI (n.
ire coimiiAneO uti'rt invol vinq P'x and r\W'L U,,j _ telat r~,, *,'_.- cuarao-
ter] ze jfnderweiit an uoijrjdinq, prokcess ,liereb_ ti2 li 1t emi t. Id900C
irerepluced witri hiyf power, niqh re! iabil ity o ne t s.

3ecaume(_ the o4 i i, I ar coi_ii, wai r I v~iII)!uo e t

,oni,JoU te~s-inq ta., ono jct~i ) 3 a artial yster lvit evi i ' i,.' l]'..
rema(ts ot te
till In are7 k,(
'.uuuenu, 11 ' o Chidt i
IA 'i6

-hie Hoer I( Eva ! a tion

Ccl Sof twa r, 1 tit' +r t-
3CtN I;
ointCfuf'lii t lye'vel I-' d utI ioUll 6 oe arm
I~.
n. I
1
en
-, pt ic ra n,, la to c i I ti s t

d . 0 lJIliTIa
I 0le dL lul
0 , )~ittv.c rl! *2 rL '()IOf
cOn ,ron ,) tr Nl asiLr Proc;: 'r'P r
ri
!anpr ri. ert
udMa

1). Muoi tip iex Soltxa resriur-i.i:i fi Y cuotot or ;

ai
e roces or/ 1-11. !) the Dw,'a Tr ft~r er

c.keiote '_)0f tWar, tespO:! ) IC for -oritro I f the

Reii~ite firoces sor, 11,(s! f or aI I tes ts.

d. Optical Dynamic Fornqe lest. KONI~' 1o Sottware. resplon-

si ble tor ccritrol of tire '01acter tl1Tri-CeSIor/ SC 10 for
the Op t cuI DynriamIc anrg e e t
e. ODRT #2 Software, responsible for control of the
Master #2 Processor/BCIU for the Optical Dynariic Range
Test, and

f. Word Error Rate Test (WERT) Software, responsible for

control of the Master Processor/BCIU for the Word
Error Rate Test.

.........
 I) UFIWARL ME1

01 Ap ic iion ,of twoa ,w-r

both -ne J/3/ 1 and trie 2'7" ver-s i s of fri-:- a[)4,, i ,r L~ *Vt -
,Ner-. assessod. The j Sse'[;;k ~fj*;
'r

0 compliance of the -Oftiare to so)ec t 'catior!

* perfor-mance of tho uf..or
* adnererwe of tht, coo( to striarcs
* uljef o trio ~UC-;' 1r~i

The spec t icatittns ,tfot code, thtj ro ir :,: alI c ri tK ar t h t-.'; e i!i ri t atir
were eval1ua ted. Conoonitra ti on vids on the .1o''"...o-,nt ti t i.n d i t w as P vai ,u t ed
n,
aijairst strict standjards . T he ref r)e, tie djiSCreIjancie fOS U ( ioO ridicate delia-
tions fr- the stcandiards and do rort netes,c-szily 'i 0tle j5%hii it. ;f
the produL:7. A few j .o r i i-,a ( u aa1 n eSt r in tsi or twIire. Sj
these are not serious wnen v ielled thi ,t v- it
r t

s deviation frofy fu!a1; if. iet

I L - -. Li-A ',(
1' P-I I - p t or 1 O
1,~1

*~~~ -ole~ccd oo ~ 4o

7 Io i A -
n piv
ot nr i it2r Ar, -

li uM7r t- : -1 1 f ut' rfreti

) *uo n i, Ott 11'l 4 "

If!ws :,1 Ort ,' , -i 0
, 'a

t veral11, the ~Ts o(f Lva re and dor Ii' onto t or, las jtiyj, 1 to motor excfeel
i;;ost requ "'enerts,. The lol 1lwittq jroller's tmind are' ili ni an1d have itni , a

* Ffn I' - j able'; di' it 50150 C cite I ,, con141 LA t;O

* Interface and i nmt itna test was del ayeud arnd is not
ful ly docuimented
 lhe UMSS does function as required. The evaluation shows this

software to be very usable, maintainable, modifiable and portable.

9.3 PMC Assessment

The PMC assessment consists of the following five sections:

1. Part I specification review and assessment

2. User's manual review and assessment
3. PMC system capabilities assessment
4. Assessment of PMC capability to support system
testing
5. PMC usability assessment

The assessment was performed by a five-member team. Upon the completion

3f the testing an assessment report was written to the DAIS Document Control
Board (DCB).

The PMC assessment resulted in the following recommendations:

1. Keep the current system, as is, for possible future

use in the AN/AYK-15 ITB/STS. Most of the basic
functions work and might be useful for future debugging/
development. In particular, the team feels it could be
useful for single processor module interface testing.
Additional development efforts to improve the current
system are not recommended.

2. for future DAIS developments, do not use the current PMC

as a baseline. The concepts and some of the functions
may be useful.

3. For tuture PMC-t.pe developments, consider ,mall, easy

to use, stand-alone tools which execute fast and will
satisfy system requirements. Insure that needed capa-
bilities are provided. Avoid complex functions which
may not be used. User irnstructions should be well
documented and easy to follow.

During the assessment the following basic problems were

discovered:

1) The PML is a large software system. It contains a number of

features that are complex and were difficult to implement. For example,
interfale with 173/1 to allow debugging at the HOL level; start/stop/restart/
of the system, etc. As such, it is difficult to use, some of the functions
do not work, some produce incorrect results and the system crashes under
certain conditions. It snould be noted that the hardware, such as the BMU
and SCADU, also impose some PMC limiations. Since its delivery/installation,
the PMC has never been used as a system development/debugging tool. Users
have used some of the functions that the PMC performs, but have not done so
through the PMC, i.e. they have used the functions in a manual stand-alone
mode.

-169-
 '~he sy! te lacks _eo'r. I t - 1Cic c, t
devu-I opHmel /e[h Ia ' dI)
J 'C ''l1tO o'c.<r
a FIa1 1 a r; r 5 f) il I 'I

B Arid A1 3) r 11, Af Li-t. 11 i t!~~t

ca tj

o r- 1at-e system dev elupmrents/ test i na t he PNr IdCa5k1s

StoY'a(i f 0r1 fdata Iogg i cl anard does io t won ta in a fly pLY t - ru a ,adi aVi
it ieS.- Fur- lorl
10 ission si.mulation run, 1 tqge ainu u'lLI of difa. y ; w,
Lie c ci I t cd then d Otrograln 0/uid 1,L neceded . '~ ti r a a .'c
into frw..
oei~b

4) A u aj Mc t p sy stu i: O _ 9 J t' f i intig ra p-ia t o

of1 tv re,'riar'dwalrV doeveo olp ent/tut ri
inqL ii j LI I. , ' I Tmdtw-v v!, ii-

w ti' u ptFO[.
! Y too .

based vOi tlie ahve prILlems, Cver I- Cr I t~i

1) 'oj
toL~da s'~. idOb CS ij'<l e:fl
su!-l ttjd Iqat' i
k wj ttd
(I c - , ' ' ~ U v

'tit, developmn t rii it . rq

:It . ii I ,t_' i i
:et ;n

.. rl ~ 1 ; fiT! t , -dI '

T ith t a,, U, ii 1A ) r(, 'u~t
ren0,l m e'

rilIatI,'I r Ii ~ nr ~

I co
I~e f a I the1L" oss
cIr~l ot: t ,lS1r-inQ,'lk
I~i

-170
10.0 MISSION DEMONSTRATION

The overall DAIS objectives are to (1) reduce unnecessary develop-

ment proliferation, (2) improve operational efficiency including availability/
maintainability, and (3) improve flexibility to changes. These objectives
must be achieved without sacrificing the mission avionic functional capability
attainable with conventionally configured complements of sensor and weapon
subsystems. The satisfaction of these objectives and the requirements for
acceptable system functional capability have been illustrated by successfully
operating DAIS under simulated mission conditions. Specifically, the mission
demonstration has illustrated: (1) the pilot interface with Controls and
Displays (C&D), (2) the operation of the processors, mission software and
multiplex system under realistic workload conditions, and (3) the ability of
the system to perform weapon delivery and navigation functions.

The DAIS demonstrations were performed in the Integrated Test Bed

facility. The purpose of this facility is to test DAIS mission software and
core element hardware under real-time conditions. The facility provides a
real-time simulation of a military aircraft performing an operational mission.
The simulation generates the interface signals so that the DAIS equipment and
nission software is subjected to a data signal environment which is nearly
identical to actual flight.
Simulation software was developed to provide real-time simulation of a
nlilitary aircraft in an operational environment including the aircraft dynamics,
the aircraft sensors and weapon targets. The simulation is drivel, from the
cockpit by an operator acting as a "pilot". This simulated cockpit is equipped
with the DAIS controls and displays so that the various modes of a mission may
be "flown" by a "pilot" with an out-the-window background scene.

Four mission demirstrations were originally planned to satisfy the

overall DAIS objectives. However, as the DAIS program progressed the final
two demonstrations were deleted, and the remaining demonstrations were re-
designed and redirected to satisfy the program objectives and validate new
technulogical capabilities (MIL-STD-1553B multiplex architecture, MIL-STD-1750
processor instruction set architecture, and MIL-STD-1589B (JOVIAL).
10.1 Baseline Demonstration (Mission a)

The Mission demonstration was successfully performed during

d
Septebe, 1978 to demonstrate the OAIS system. This demonstration was the
first of the four originally scheduled Close Air Support (CAS) demonstrations.
This initial demonstration included functional capabilities such as: Inertial/
Baro-Jamped Navigation; ComImand Navigation, TACAN and ILS Steering, MK82 Weapon
Delivery (with weapon scoring); Stores Management; and PREFLIGHT, TAKEOFF/CLIM,
CK'SL and APPROACH/LAND checklists.

The simulation was flown from the DAIS cockpit using active DAIS
Controls/Displays and simulation models which reside on the DECsystem-1O. No
real sensors were used in the demonstration. The avionic system consisted of
a two-processor DAIS configuration as shown in Figure 56 and Table 27. All
communication between the DAIS processors/Bus Control Interface Units, the DAIS
cockpit and the simulation models was accomplished over a dual redundant MIL-
STD-1553A multiplex bus using DAIS/1553A system protocol. A DAIS remote
terminal was used to interface the DAIS cockpit electronics to the dual
redundant Ib53A multiplex bus.
-171-
 C--1
Cd:)

C) 0-

CL ! l-
C/j

CC.3J.
LUh

C,, JJ C.3

MEC en CD V) L-

C-,r

LAJ
-J = LU
LA W~ CMLA I-
Cfl I L3 a C

cal2
 TABLE 27. MISSION a CONFIGURATION

Weather: Night - Clear (VFR)

Target: Fixed Ground Target
Weapons: MK-82 LDGP Bombs
Threats: None
Simulated Sensors: INS
Laser Ranger
Air Data Sensors
Radar Altimiter
ILS
TACAN
Core Element Hardware: DAIS Processors (2): Master & Remote #1
BCIUs (2)
RTs (2)
Controls and Displays
RT (1) C&D Mass Memory
VSD SCU
HSD HUD
MPD-1 MPDG (1)
MPD-2 DSMU
IMFK AP
DEK MMP

Support Facility: ITB Functional Diagram as shown in

DA 130 102-1

Functions: Navigation - Inertial/Baro-Damped

Steering - Command
TACAN
ILS
Navigation Update - Flyover
HUD/Laser Ranger
FLIR/Laser Ranger
Acquisition/Cueing - Pilot/HUD
Pilo'/FLIR
Target or (OAP) Fix - HUD/Laser Ranger
FLIR/Laser Ranger

Weapon Delivery - CCIP/Auto

CCIP/Manual
Stores Management
Communications - UHF
Checklist

-173-

, ,., -I
I. Upraued Mission Deonstration (Mission K
Ijsi nq the Mission -L derminstrti on ,isa Lasel iAl ior devel',1.lev ,
several features were added whico led to the 'lisioni. :ttrt on, in
Mission deonstra'ion was the second and ' ina deii:.,u It ion for the DP.A
prograi. It was actually performed four tires: first, to demonstrate the
functioial enhancements made to the Mission ,xdemonstration L-aselitne; soS li
conversions were required to accoroodate the MlL-'TD- &53E ! nltiplex Systev;;
third, the software was re-targeted to ruun on the AIA,'K-15A (11] _TD-!7K'i
processor; and fourth, the software was converted from JOVIAL /31 to
JOV:i1L (MIL-STD-1539)).

The Hission 6 demonstration included fur'-tiona capa ilit es sOLE

as: Glyrnand lav iga t ii, Command Heading, Command ' t tude, Coi marid Track,
TCAN, and ILS Steering; Dead Reckoning, and TACAN Area hc,,i. >tio,; .,K.?
Weapon Delivery (withi scoring); Stores Management; and PREFLIGHT, TAKEOFF!
CLIMB, CRUISE, and APPROACH/LAND checklists.

As with the Mission a, Mission demonstration was "flown" fro, tre

DAIS cockpit using active DAIS Controls/Displays and the siulation models
which reside on the DECsystem-lO. No real sensors were used in the delonstra-
tion. The aviunic suite for Mission B consistec of 1 three-ru._essor DA cor,-
fiauration as shown in Figure 57 and Table 28. All communication between the
,
DAIS processors, the DAIS cockpit and the siim;ulation models was azcorplis',-f
over a dual redundant MIL-STD-15531B multiplex bus, usin(;DA,!1553b syst
protocol. A DAIS remote terminal was used to interface the DAS cockpit
olectronics to the duo' redundant 1553B ,ulfti e..bus. ltms'uh each cf t'I
i.ission ? demonstrations was conducted on the pasi,. described above, eacO was
so!:mewhat different in the technology used. Table 29 indicates the use-
transparent' differences in the three Mission delons:'atcn,rs.
;.

- 1/4-

!'.
 F-

ILw LU U

H- CD( C)

LI)
LI)
LU
l<
Li
C) LU I
~ IX
WU LUI H- - C) C)
Qj -- V ) L/)) -
C)
C; -L)
C>-
(0
01/ )
LU>-
t L/)
HH
ULL)
~C LUJ

C) LUC) H-C:D C) z <

CL)

- __ - _ _ _ __ 1 _F _ _ H-

-) (J FU LUJ Z

L- L L U LV) -3

:z
-L ( ) 0- <r)L- <Z
C) ) 0 L 1) (-) LUj
LU
CI) LU- C) L)

LU~V -I) > LU <H

C) C) ~CH
LU -J C)C( ) LU
co C- V)
-~~~lC H I)L 0

-D LU
H-- - < C

- __ D _ __ _ __ _ _ LU U
CDV L V ) L/) U-)

V) H-
L 0u-L-
< U)
Z, 0
C) LJ HJ- > >-
a- L/) LU

0 CCwL C H-M,~L L c-
LI) -r C)
LI)) -L'i- U L

C)
L L> L0-
IC

0. L)U - >C) - Io /C LDV) L

<C) C)
0- .' (0L _j c

2-- x Li C)ZD C)

XI H- C) L-) le
L/) LU0-- V) InC)c ) lC - < -
-L U LI) - - <V ) -M = - I)

H- L.A -) - -- - - - -
 TL L is27

Wea they,:N !1ht - ir

drf;e~I. ji ed 6 ru nd Ta r'U
Wea oon s MK-82 LLJCP Loarbs
Thr'eat-,: N1
Si";ul~ited Sensors: :NS (SKN2416'

r oa ta Sensor-s
Pitimpter
Ksdar(ARN-58A) ''- '4'~
ILS
TACAN (ARN-118)
Core ElerienL hardware: DAIS Proce2 ,ors (): Master. 4emote
and Poei-f ":
BCIU/BCI J
RTs
Simvulated floss :Mawiory
Conitrols aric Display-,
PT ( 1:
OSD SL
HSD
'MPD-

DEK (2
MMP M

Support Facil ity: Per ITB Funct,,onal Block Oiaooraii DA 10. 102-1

Sof twa r c:

DJAIS Mi sion Software (ALnpI ci~ion~

SSDF (URT)/Simulated Mass Memory
MP DC

Sirlulated '.odeIs
E&S
 TABLE 28. MISSION CONFIGURATION (Con't)

Functions: Navigation - Inertial/Baro-Damped

TACAN Area Navigation
Dead Reckoning
Steering - Cowmand AV
Command Track
Command Heading
Conmmand Altitude
TACAN
ILS
Navigation Update - Flyover
HUD/laser Ranger
FLIR/Laser Ranger
Acquisition/Cueing - Pilot/HUD
Pilot/FLIR
Target or (GAP) Fix - HUD/Laser Ranger
FLIR/Laser Ranger
Weapon Delivery - CCIP/Auto
CCIP/Manual
Stores Management
Communications - UHF
Checklist
Startup/Restart
Systems

-177-
 J 11LI
-. . :-1

- '-3 --

<12

- t-I

-- I ' j '. j
7

- .. - .. - . . . - - - " I I
AD-AJLOT906 TAN DEFENSE[AND SPACE SYSTEMS GROUP REOONO0 BEACH CA F/S 9/2
DIGITAL AVIONICS INFORMATION SYSTEM (DAIS): DEVELOPMENT AND DEM--ETC(U)
SEP a1 M j COOK, R C MASON, J L STAUTBERe F33615-TB-C-1502
UNCLASSIFIED AFWAL-TR-81-165 NL
3 mmmmND

.mmmmmmuL
11.0 TECHNICAL SUPPORT

Througnout the DAIS program a high degree of technicdl interchange

with other programs and other Air Force organizations was maintained. The
most significant of these was the interaction/contribution DAIS nade to the
development of MIL-STD-1553B, MIL-STD-1750A and MIL-STD-1589B. Other tech-
nical support supplied by DAIS is identified in the following paragraphs.

11.1 Hot Bench Development for PAE

DAIS supported the development of the Precision Attack Enhancement

Program at Martin-Marietta Corporation, providing numerous software packages
including Diagnostics software and URT software for checkout and use on the
PAE hot bench. DAIS also assisted in the installation of several versions
of the Executive and supported investigation of problems related to the
interface of these -oftware packages and hardware at the PAE facility.

11.2 Fiult Tolerant Assessment of DAIS

This study was conducted under Air Force Contract F33615-77-C-1232.

DAIS provided technical consultation in the areas of reconfiguration, monitor
processor plans and terminal failure/recovery operations. Documentation of
the System Control Procedures and core element hardware specifications were
provided.

11.3 Advanced Avionics Systems for Multi-Mission Applications (AASMA)

This study/implementation effort was performed under Air Force

Contract F33615-77-C-1252. DAIS provided documentation of the System Control
Procedures and Executive software as well as consultation on technical issues.
A version of the DAIS executive was used as the starting point for the develop-
ment of the Single Processor Synchronous Executive (SPSE). The contractor
reported that such a development/implementation would normally have been
allocated 52 weeks but was successfully accomplished in 3 weeks.

11.4 Fiber Optics Bus Receiver Requirement

This study/implementation was performed under Air Force Contract

F33615-78-C-1561. DAIS supplied technical documentation and consultation
on multiplex bus and RT operations and supported prototype testing in the
ITB.
11.5 Remote Link Unit Design

This study/implementation was performed under Air Force Contract

F33615-78-C-1634. DAIS supplied documentation and consultation on the System
Control Procedures and multiplex system operation and supported prototype
testing in the ITB.

11.6 Fault Tolerant Computer Network Study

This study is being conducted under Air Force Contract F33615-79-C-1180.

DAIS has supplied documentation and consultation on the startup/loader operation,
reconfiguration and difficulties with the monitor processor concept.

-179-
.1
1I.7 Mission Manaqeent Software for the iK -'25 Avionics ".o(ertiz t,,
Hot 3ench

This design/development is being condusted under Air ForcL CutrL,

F33615-80-C-0274. DAIS supplied technical docurr,taticn and Lonsultatior Jr.
the system; control procedures, Executive softwjre, ::
odels, i ulati(o,, -r2
other support software. A version of the DAIS exeLutive was .e ,
startin,, point for this development.

-180-;

ii
12.0 CONCLUSIONS/RECOMMENDATIONS

The DAIS program successfully demonstrated the concept of a multi-

processor avionics system configuration in which standard, general purpose.
digital processors, programmed in a standard high order lanquaqe, communicate
with each other and other avionics system elements via a standard, dual redun-
dant, multiplex data bus.

More than just a concept, the DAIS integrated test bed represents an
actual implementation of the following military standards:
* MIL-STD-1553B
e MIL-STD-1750
* MIL-STD-158SB

In addition DAIS represents a comprehensive, fully tested, mature base-

l-ne for the potential development of new standards in the areas of:

9 Executive Software
o Executive to Applications Software Interface
* System Control Procedures

The DAIS architecture is a proven technology which can and -hould be

applied to real aircraft and missions. It lacks only demonstration in a real
flight environment (vibration and acoustics, EMI, etc.) The Air Force should
vigorously parsue the infusion of this technology into the fleet.

In addition to the above overall conclusions/recommendations a number

of specific items are covered in the following subsections.

12.1 Core Element Hardware

The AN/AYK-15A processors represent an advance in avionics technology.

They demonstrate the feasibility of embedding a bus interface/controller in the
processor box and of implementing the MIL-STD-1750 instruction set architecture.
Of major importance was the successful dual source procurement and subsequent
compatibility demonstration. There is little doubt the AN/AYK-15A processors
will find widespread application.

The Air Force should continue to track any problems or variances in

operation in these units and seek resolution of any which threaten compatibility
The specification SA 421 205-1 should be actively maintained and revised as
necessary.

Evolutionary enhancements to the AN/AYK-15A are in effect being scoped

by the MIL-STO-1750A working groups. The area that should receive first atten-
tion is the extended memory capability. Other areas, not covered by the standard,
which should be investigated as an extension of the AN/AYK-15A technology are
an increased intelligence in the controller to handle error and exception pro-
cessing and the expansion to multiple buses to support future hierarchical bus
architectures and the like.
The DAIS BCIU proved to be a useful step in the development of the
AN/AYK-15A technology, but these units have served their purpose and should not

-181-
!)e devel pud furthfe . rL I,A ,
tr..' -
can cernti:ue tc pe r ; io- u:, ] L_. I': , '.n : i': ,. . . , '. '
'-or example).

The DAlS RTs demon,,trated that a sinu!4r unit (ould , ter'(ce

variety of subsystevis and si(na I type,,. However, t ilec , t ',-e ' ),i v
systems is toward embedded bus interfaces arid the 'JA. J PTI, , a rrt ti,. J( t o
to find much appl icabil ity. The one potential dpl iiti ou wou1I, rt, t, tr
in a "clustering" architectUre in which PTs woul1 b(,, strdt; d t t, l
the a i rcraft ,jeotetr) and inter'ace Il eni pmelt i ! t , i,. A,
froi this, tho, RTs sh,,uld be vi,-wed n se ,v-I
tie nh t I
C.t
mert of the multi ul ey technoloqy and ,iot Ourtued tul ther.

The MIL-STD-1553B multiplex was denontrdted by r)A', to be ar ef'e'.-..

data commnunications technology. Evolution of this stanAdrd is t( he exp-(t(
and the DAIS experierce should be brought to bear on thai: i;roce.. As ide, ( I -
in the conversion discussion, some short~ovirqs in tow t.3:dlr:. evide,
example, lack of a mechanism to Lliar t ctor vur,:. At tht sal,'c t'.
'
should be recognized that when MIL-STD-1553B deleted the tode cooe inero, .
1
module error register" DAIS resorted to local error handlinn in 'ho RT .. it .
net resilt of better error recovery and reduced execst ive softwar-e. The.
learned is that when an avionics system designer's favorite te'-ii ie see! s
incompatible with the standard it may well be that tho sa,,Hcd 5uil
suggests a better approach.

The DAIS Controls and Displays proved to te i(, e t'.ve, *le, -,

pil ftinterface. The advantages of multiple purpus, ,i .olay; I,,, evide,.t
th'ere is no doubt they will persist for generations of -1c,. ;'
svstst ,.
Tt is significant that in formatting displays DAIS found it recessa,- to '
graphic representations of the HSI, the FPM, and other symboloqy. The hun.n
factors considerations must not be overlooked, and the graphic representation
oealier generation equipment must be viewed as a useful gen-ral prr;,s .

The DAIS system mass ,emory was, actu/l 1o I ,. *, ,

'-v,2. The actual bubble me'rory oevUe ,: ,t r d, r.c, CI
to'.,o ut, -4.,d into t ~ Ir Tn "n Of . . ..
:mor Interfaced via tne multiplex bus was d:tonstrateI bu! neither thil
"ocord formats nor the interface protocol bear any ess;,,t;a 1 r, !ti,'n tc tl> .
memory technology. The interface protocol was driven by requirements ol cor'-
patibility with other Air Force organizations. The system mass memory should he
the subject of further investiqatior. The question of interfacirg via the bIo
or directlv to processors should he evaluated in light of advarces in memor,
te(hoology (itc'udinh expanded processor memory) and the T ir Force should rr,.,
the compatibility requirements nn the interface prtocol. A record-(rather tna,
word-)ddressable interface :1ay be 'lore applicable and a re-read function would
be useful.

12.2 DAIS Software

i, A, t'aster and L'cal xecutives form a powerful, general purpos.t

s,tware packaw triat can be the basis of future avionics systems. The use of
the executive for other applications has already been demonstrated. The DAIS
eIitivo was , the baseline for thro Sin'Jlr Processor Synchronous Executive (SPSE)

-18?--i

~.0 -
developed in the AASMA program, and the DAIS executive is the baseline for the
current KC-135 hot bench development progrdm. In the former case, the contrac-
tor reported the successful generation of an operable executive in three weeks
time whereas normally they would have allocated a full year to achieve this
important first milestone.

The Air Force should continue to supply the DAIS executive as the base-
line for new developments and should support those efforts with strong technical
assistance. Moreover the Air Force should follow up those efforts, soliciting
feedback on problem areas and specific accomplishments.

The initial implementation of the DAIS executive was excessively large

and inefficient. Improvements have been made continuously as the system matured
from one demonstration to the next. The combined effect of better software
structuring, the removal of the memory boundary constraints in the AN/AYK-15A
processor, and the exploitation of the single word instruction format of MIL-
S-D-1750 by the J73 compiler resulted in an overall reduction of approximately
30%. One specific function, minor cycle setup, was initially a very complex
function which was measured to be responsible for 25% overhead. Restructuring
bus lists and reworking this function reduced that figure to less than 5%.

This proyress in continuing. The final executive for the beta demonstra-
tion was about 4K words each for the Master and Local. With technical advice from
the DAIS program, the KC-135 hot bench development has brought these figures down
to about 3K and 2K respectively while at the same time approaching overhead figures
worthy of a well organized assembly language executive. The lesson learned is
that oversized, inefficient software is a consequence of specific implementation
techniques and not due to the use of a higher order language. An efficient,
reasonably sized executive can be written in HOL.

Two implementation approaches were identified as particularly harmful

to the DAIS executive. One of these is giving strict, pre-emptive priority
to asynchronous bus operation. The other was the adoption of a virtual memory
approach for the software architecture. The asynchronous message handling is
discussed more fully below, but briefly, the problem is that suspending and re-
storing bus operation is a very expensive process both in the software required
to accomplish it and in wasted processor time. The virtual memory approach is a
useful concept for software development, but it should not be carried over into
the operational system. The partitioning of related tasks to different processors
results in additional bus traffic and even if it is not done, just the potential
of it places unnecessary constraints on the executive software.

In practice, task partitioning is along functional lines, keeping related

tasks resident in the same processor to minimize interprocessor communication.
The executive should be allowed to make use of knowledge of the system partitioning.
One example of this is that upon a mission mode change the Master Sequencer signals
all events individually as if the tasks were resident in the same memory. The
event handling software must then determine what tasks are not resident and
generate requests for asynchronous messages (one per event) to communicate the
signals. Without the virtual memory constaint, the Master processor would simply
signal the mode change to the remote processors. As noted elsewhere, the virtual
memory approach also inhibits reconfiguration.

A
I
-183-
r)' ...... 0... r

:' C;e Sur 0,o. ;'rq

1',r ,, 'r ,* i*,' ;,i 4fi, . This wr 'i :1 '.! (' :
pr',. 'lV tc the '!.v t i'.atth:o ,; is d ivLr bL ,o , e,
eartitienir
of e xte rri Itf . to,'' a y 'onk-(ad 'o o t 'A tO1LI1:- i, 0' h.~
a useif l : uu)p)rt tool for thul din ,.-.cut ve tables The Air Force ioul( "a , -
tain this tool arn_ consid'e,' u-)qradiri(; it to format and outiout sote tne Cr.-
siderabeo ata it has (in i systC,,f'1 sion/coo'figurati, n. .4i theut !uch difti..'t
PALEFAC cculd ,. made to jerierate a ",odel of expected cystem ierformance incluoit.'
a timel ine of bus loadi'' t cro(s m ,, .'' c/es, ?eV 'u ' sir ,., , .p te,' .
syste:i bottlrecks, etc.

The DAIS startup/loader was fully demonstrate,! to accorwplish all var-

tions of startup, rcstart, reload, and transient rec(.very for all combinations
of orocessor confiqurctions. It is a complete and general purpose capability
which is wholly indepe,lent of the DAIS executive software. The Air Force should
make this technology available to other urograms and provide technical support t,
adept it to cprlicatio'rs implementing : different -'a:,', "emory technology " 7
different processor control panel artoach. Adantation will also be requ'red i
the startup/loader is to be abp4'ed to Lno'fioulatli;- of more than four :rocesso".
None of these adapzations are si7nificar- and apart from them the star-.'tup/loader
is capable of handlinrq a'y ronfiqur,tion of pro(essor- initerconrnected via a Y'.l-
STD-1553B multiplex data bus. (Nt. r:r, irocessor corv<,t ibiity i., 'equired;
only the standard bus interface.)

DAIS Sport hard,.ware

The DAIS coilnleren t of suppnr t hardware rove' t., be a,1 effective

s et
tools F,_r the checkout/irtepratio-i of the DAIS core elements, but for the most
part these are specific to the ITB configuration. They should be maintained
and assessed for applcability to future laboratory proqrams. No efforts to dis-
oerse this technol',ov tr - other programs is reccmmended.

A: AIS Snpf;.' t Sofware

The , i.: re;ertoi rr ,t -; or " :.' ' ,-,

.",a.n crquld be conscientiously maintained and made available to other ,i,
-:r.e prou;ram-. To a la-ge extent this has already been accorniished, but c"'
should be expended to sustain a widespread awareness of the capability and avail-
ability of the DAIS support software. 4 presentatior or two at appropriate
national confPereces would seem to be in order.

In particular, the MIL-STD-1750A acceptance test proqram should fi.i

wide applicability. The 1750A ATP extensively tests the instruction set and
many of the available options, thus providing a useful tool for verifying
simulator operation or detection of hardware errors. Possible improvements for
the ATP could include expanding the testing field to cover all notions not
currently tested and, combiring various hK': truct inns to verify actual preqramioinr
situations.

1, contrast, tue performaoce monitor and control (PMC) software,

upon careful assessment by an evaluaLiun trav),proved unwieIdy and unstaible.
 The PMC software evaluation team advised that software not be changed,
but since it had a tendency to instability, they recommended the software not
be used for a baseline for future software.

12.5 DAIS System Control Procedures

The DAIS System Control Procedures as documented in MA 221 200-1 and
SA 221 200 proved to be an effective vehicle for identifying and resolving
system-level issues. They not only present the overall system operation
(hardware/software/procedural) but also illuminate the underlying rationale.
MA 221 200-1 documents the final configuration of the ITB while SA 221 200 is
in essence a system designer's guidebook for the application of the DAIS
technology. The Air Force should give wide distribution to these documents
to aid in the infusion of the DAIS technology to other programs.

Several System Control Procedures topics deserve separate discussion,

including synchronous operations, asynchronous operations, error/failure
handling and the Monitor/Backup concept.

DAIS demonstrated that effective synchronous communications could be

accomplished based on the period and phase concept. Further, by adopting the
constraint that periods should be a power of two and adopting the convention
of transmitting largest period data first, DAIS was able to define a static bus
list requiring only that the BCM be started at the correct point in the list.
Thus even though different sets of synchronous bus operations are performed
each minor cycle, no dynamic bus list manipulation is required.

DAIS demonstrated that asynchronous message operations are strongly

implementation-dependent. DAIS implemented a strict priority for asynchronous
operations requiring that synchronous operations be suspended upon the recogni-
tion of an asynchronous request and that the complete decoding of the request
and transfer of data be accomplished before resuming the synchronous operation.
This proved to be very expensive in terms of the amount and complexity of software
required and it resulted in processor throughput degradation. It also was the
source of several difficult-to-isolate problems of a hardware/software interaction,
timing dependent, variety. While alternate procedures were defined, they were
not implemented in DAIS. They are being pursued in the KC-135 hot bench develop-
ment.

Another aspect of the asynchronous implementation was that a remote

processor advanced its transmission queue when it finished sending an asynchronous
message. This necessitated a special re-transmission procedure when errors occurred.
Interestingly enough the conversion to MIL-STD-1553B aided the solution to this
problem. The deletion of the mode code to "reset status code field" forced a
rework of this area and the revised control procedures withheld the transmission
queue update until the reception of a"synchronize mode code." The net result of
this modification was a reduction of software in both the Master and local execu-
tive. The important corollary of this result is that the software expediency
of performing buffer management in the transmitter at the completion of message
transfer actually generates additional software requirements in both the trans-
mitter and master controller.

The DAIS experierce therefore is that asynchronous bus operations can

have a severe impact on size and performance. This, however, is not a property

-185-
 of a ,vrchrc rous m'ssaoes bit rather of the implerl-.rltati,.,i U,_clr, uv
cien , fully dterministic, dsynchton',u, implementation is ')ossiol&.

Message error handling and retry is an important related area that

the System Control Procedures must deal with. At one point i'ithe DAIS procr ".
when the control procedures applied error considerations to all message types
and combinations of transmitters and receivers, it became necessary to define
seven separate classes of message retry. By the time of the final DAIS demons'ra-
tion this had been reduced to two types of retry plus special handling for the
systew mass memory.

The careful retry procedure was introduced to handle the situation oW

a device of subsystem which would function improperly if sent data twice. An
early DAIS configuration had an inertial measurement unit (IMU) which operated
in this fashion. The procedure to handle this type of device is to perform a
"last commana" mode code operation to first confirm that the device received the
command work and then a "transmit status" to confirm the device did indeed detect
an error prior to repeating the message. And, of course, proper operation
requires this be performed immediately, before resuming normal bus operations.
MIL-STD-1553B removed the need for a separate transmit status operation, but the
last command sequence remains an awkward procedurc with undesirable software and
performance impacts. The Air Force should eliminate this requirement. Subsystem
procurement specifications should include the requirement that the subsystem shall
continue to function properly when intermittently sent repeated data. The sub-
system should similarly be tolerant of occasional brief lapses in the data flow.
The Or Force should place the same requirements on application software and
shouid include data repeat and data lapse tests in acceptance test programs for
application software and subsystems.

Another type of message that represents a severe difficulty for the

system control procedures is the "critical message." This is a message which
must succeed for proper operation. If that is indeed the requirement, the
control procedu-es have no choice except to terminate in endless retries,
Jevice fa'lure, or system failure. The Air Force should endeavor tU) e:v'iIad
cr','cai messages" wnenever possible.

The Monitor/Bdc.kup operation is an area in which DAIS did not acconvpli,

its original obJective. The startup/loader provides a complete reconfigurati.'
capability and (for certain systems and missions) this is sufficient to accomplish
the Monitor/Backup function, but DAIS did not succeed in solving the general
case problem. The Monitor/Backup concept is one in which a spare processor, the
Mor.itor, is capable of detecting a failure of the Master and then of assuminq
the functions of the Master to maintain system operation. DAIS defined and
demonstrated the mechanism for the monitor to quickly and reliably detect a
master failure and to L.ke control of the system. The stumbling block is in the
definition of the contents of the monitor. The nominal definition of a duplicate
of the master leaves unaddressed the question of how the monitor obtains adequate
data on the state (f the system to actually perform the master function. The
approach of configuring the Monitor as a remote during normal coeratins ir,
,rd'r t;tat tlO m.astei cdn send h;, the required data has several flaws. It adds
-o Tworc ,t.u reer, ci the master, regates the concept of the duplicate master
and creates a spectrui, of failure cases for the monitor to deal w'th. This
approach Irust also answer the difficult philosophical and practical question of

-186- .
L.. _ _ _ _ _ _ ,j'
_ "
_
 how can the monitor reliably begin system operition based on data received
from a failing master.

Another aspect of the Monitor/Backup problem is the monitor assump-

tion of the role of a remote processor. A reload is required in this case and
it is desirable for the balance of the system to maintain a degraded mode of
operation while this is taking place. The virtual memory architecture of the
software, however, permits each remote processor to depend on every other for
correct, continued operation. In principle, then, the degraded mode of opera-
tion is not possible. The system operation would have to stop while the monitor
was reloaded and reinitialized to perform the remote function. This approach
is within the scope of the current DAIS technology but it was not imilemented
since the startup/loader already accomplishes the equivalent end result and is
a more general solution to the restart problem.

Thus, DAIS has solved the error detection/rapid failure portion of

the Monitor/Backup problem, but lacks a definition of the Monitor content, the
protocol to update it with current data, and the ability to continue operation
following a remote failure. The Air Force should continue to address the
difficult question of the Monitor/Backup technology. The most promising ave-
nues appear to be in first controlling the software partioning to remove the
interdependency of remote processors and secondly of expanding the bus controller
capability to include an operational mode which is truly a monitor, i.e. one
in which the required system state data may be obtained without perturbing the
normal system operation (in which case the duplicate master approach is feasible).

These issues must be addressed in future programs, but always in

the context of the system control Frocedures so that all pertinent considerations
can be brought to bear. It is recommended the Air Force give a high priority
to this area of advanced avionics technology.

-187-

- ' . - -9 -