Dorian Punj.

A survey of Navy tactical computer applications and executives : report of a study by online

. (page 4 of 14)
Online LibraryDorian PunjA survey of Navy tactical computer applications and executives : report of a study by → online text (page 4 of 14)
Font size
QR-code for this ebook


The executive apparently lets a running job run until a significant
event — e.g., termination or I/O forces the job into an idle state.

2.3.3 Interrupt Management

This executive function receives and decodes external
interrupts. If a module has not registered to handle the specific
interrupt, SDEX/20 will process the interrupt. If a module has
been registered, processor control is given to the required module.
Certain interrupts, of course, may only be handled by SDEX/20.

2.22



These would include timer runout, hardware failure, and similar
serious errors.

2.3.4 Input/Output Management

The I/O managem -nt function enablos tuo user to do all
I/O, with or without obtaining explicit control over the I/O device.
User modules may register to process any or all interrupts on a
particular channel; this might '"■ -a useful when one program is con-
trolling a specific device (e.g., radar) that is not similar to
the normal computer peripheral equipment.

2.3.5 Error Management

The error management function identifies and acts upon
hardware and software errors. It allows user modules to register
reponsibility for certain errors, and either pass control to the
module or stop the processor when no module has been designated.
Processing is resumed as indicated by the module or the computer
operator.

2.3.6 Other SDEX/20 Features

SDEX/20 is completely independent of the user modules
it services, and thus is not restricted to any particular environ-
ment. Communication with the executive is done only through ESR
requests. The user-executive interface is general in nature but
can easily be used by a job for specific and unusual purposes. This
is true because in most cases bDtX/iu will not process user-caused
interrupts or errors; therefore the user can easily use non-standard
procedures or peripheral devices.

SDEX/20 will not process unanticipated errors, and stops
the processor if they occur. This is a weak feature seen throughout
the entire system. Much more executive support for both I/O inter-
rupts and error handling should be available, perhaps as a compile-
time option.



2.23



2.3.7 Analys is of SDEX/20

Designed to be functionally independent of user modules,
SDEX/20 is an advrmccd Navy Executive for the AN/UYK-20 mini-
computer. Features of SDEX/20 that are desirable and should be
retai'^'^J in a sLandard Navy executive are SDEX/20 's application
independence, scheduling capabilities, configuration control,
and I/O flexibility. SDEX/20 is designed to be a flexible oper-
ating system with a general interface between it and the user
modules. This generality allows it to be used for a wide variety
of applications - more specifically, it is not "tuned." to one
particular tactical job. SDEX/20 scheduling facilities are fairly
general in nature and allow great flexibility in task scheduling;
further, particular scheduling priority structures can be varied
at SDEX/20 compile time. Although SDEX/20 's particular method
for achieving configuration flexibility (that is, giving the user
modules the responsibility) is not desirable, configuration inde-
pendence is a valuable concept and should be retained in a
standard Family of Operating Systems.



I/O flexibility in SDEX/20 is achieved by allowing the
user modules a wide variety of options in regards to error reg-
istration and I/O handling. Such flexibility is a desirable
feature; however, SDEX/20 's methods for achieving this flexibility
(i.e., by giving responsibility to tJie user) are not advocated,
(i.e., there are no default T/0 handlers that can be used).

Although SDEX/20 was designed to be a general purpose
Navy executive, it has several weaknesses that preclude it from
serving as such. User and unanticipated errors must be processed''
by user module. If such errors are not handled by the user,
SDEX/20 stops the processor; certainly not a form of graceful
system degradation that is desirable in tactical executives.
Additionally, SDEX/20 has very little I/O support facilities
but instead places such responsibilities upon user modules.



2.24



Because this is a gp-ic- al purpose executive, support for stan-
dard devices should be available as an option so that standard
I/O support facilities arc not roprogranuned fci each new appli-
cation. Although SDEX/20 is somewhat configuration independent,
it does not support multi-processing; further, such configuration
independence is achie> ed by moving configuration deoendent sup-
port responsibilities from the system to the user. Other weak-
nesses include lack of memory management facilities and no
explicit support for reentrant code. Although SDEX/20 has some
compile time options (e.g., scheduling options) it is not com-
pletely modular and allows no flexibility in replacing particu-
lar executive functions with other more applicable versions. This
is -seen as a major weakness that makes SDEX/20 both difficult to
"tune" to particular tactical system demands and difficult to
extend to fulfill future executive requirements (e.g., paging,
multi-processing, alternative scheduling methods, etc.).



2.25



2.4 COMMON PROGRAM (CP )

The COMMON PROGRAM is the AN/UYK-7 executive software for
the SSN-688 Central Computer Complex and the TRIDENT Command and
Control System. It was i-itroduced to the FOS group at N.U.S.C,
Newport, Rhode Island, where it is being used for developing and
testing systems for on-board use. These are principally systems for
Fire Control which interface wit': other systems such as Sonar and
Navigation.

2.4.1 Overview of Environment

CP runs on a standard AN/UYK-7 computer. Typical devices
include teletypes, CRT displays, and magnetic tape. On the SSN-688,
Fire Control shares the Central Computer Comples , CCC, (which con-
sists of two AN/UYK-T's) with the Navigation System. Sonar is a
separate system using its own AN/UYK-7. On the TRIDENT, Fire Control
and Sonar share the CCC with other subsystems.

2.4.2 The Executive

The size of the CP used on SSN-688 is about IS, 000 words.
The COMMON PROGRAM provides little in the way of dynamic memory
management . The programs are loaded from disk when necessary. Al-
though the AN/UYK-7 has relocation registers, a fixed partition
^ize is usually employed because of the separate functions of most
of the programs. CP allows the user module to build messages in an
■executive data store and to receive messages in another executive area.

The scheduling algorithm provides priority, periodic, and
-time sliced options, but the majority of processing is performed
using priority or periodic 5 msec "run to completion". CP allows
■'€4 different scheduling levels within its first level of scheduling
known as the "Priority Entrance".



2.26



Message handling is necessary for two types of messages -
1) those within a user (i.e., an application area, such as fire con-
trol) and 2) those between "users" (e.g., between sonar and fire
control). The CP message handlers are used primarily between users.
Special procedures and conventions are often used to handle messages
within a user for efficiency.

CP supports multiprocessing and multiprogramming . It also
allows modules to be dedicated to given CPU's.

2.4.3 Analysis of CP

A survey was made of COMMON PROGRAM users at NUSC in June
1974. In general, users felt that COMMON v;as geared mainly towards
an operational system and was inadequate in supporting the development
aspect as it lacked many development aids. There is a lack of utility
programs (e.g., there is no way to dump core). There are no tracing
facilities to follow the flow of execution of programs. Moreover,
the CMS-2 programming language does not run under COMiMON , making a
compile, load and go environment impossible. The conclusions arrived
at from the NUSC survey are reproduced below:

"The Common Program in the operational environment for which
it was designed appears to perform its executive task adequately.
The primary shortcoming is lack of, or unnecessary complexity in,
development aids such as utilities, linking and loading, and diag-
nostics.

This shortcoming results in significant expense and time
loss in user software development which can be avoided, or at least
reduced, by incorporating the development aids of the compiler
(operating) system into the executive system. For example, utilities
and a more adaptable I/O handler philosophy could be provided for the
user, if the executive interfaced with the operating system (or com-
piling system) under which the executive users operated The present
Common Program was written and in use before the CMS-2Y existed, and
there is no way that modules of one can be utilized by the other.

2.27



In the future, separate development ot I/O handlers, utility
packages, and loaders for executive systems should not be necessary.
If the operating system that includes the compiler is constructed in
a modular enough fashion, the executives for the various Navy systems
could be constructed, at least in part, froiu pieces of the operating
system. For example, in terms of the ^^resent Common Program, instead
of having a unique Common Peripheral module for the handling of I/O,
the CMS-2Y CINOS module might have been utilized."



2.28



CHAPTKR 3

EXECUTIVES FOR AIRBORNE APPLICATIONS
3.1 Introduction

Avionics applications in the Navy perforin a wide variety of
real-tinr.-;. junctions, such as automatic flight control, radar signal
processing, controlling displays, navigation, firing missiles, and
communications control. As almost all the work is real-time, few
capabilities are provided for program generation (a serious problem
for those involved in software development efforts) .

The variety of functions performed in avionics applications
fall very well into the categories described in Chapter 1. For example,
navigation is usually performed by sampling signals from radars.
Weapons control invokes a large amount of data reduction (e.g., con-
trolling the flight of a missile) . The tactical situation that an air-
craft encounters invokes a large amount of data analysis.



This chapter discusses the P-3C Update executive program,
used on the P-3C fighter aircraft, and the PROTEUS executive for the
PROTEUS system. Also discussed are two applications which v 3re studied
at Grumman Aircraft Corporation at Bethpage, Long Island, namely the
F-14 fighter system and the E-2C early warning system.



3 . 2 The P- 3 C Update Executive Program

The P-3C Update is the executive program for a complete
tactical system to be used on board the P-3C aircraft. The main
system consists of a CP-901 computer (similar to a Univac 490 in
instruction and character sets) as well as an enhanced CP-642B.



3.1



3.2.1 Hardware



The CP-901 is a 65:;, 30 bit machine with no floating point.
It has a number of control registers, 16 I/O channels, a real time
clock, and an access time of a little under o microsecond. It has a
cycle time with overlap of 1 microsecc- i, -^ith an average execution
time of approximately 5 microseconds.



3.2.2 Device s

Only the lower 32K of memory can be accessed for I/O purposes.
The major devices used on P-3C are:

1) Magnetic tapes, on line (the Honey^v'ell airborne type with
a regular 2400 ft. reel, but very slow transfer rate).

2) A 338,000 word drum with an average access time of 12-1/2
The drum spins at 4 800 rpm, and because a checkerboarding
technique is used, two (2) revolutions are needed to get
all the 1024 words per track off the drum. Write protect
on the drum is on a 32K basis.

3) Sensors and Display s. There are four (4) multi-purpose
displays used for tactical coordination purposes on board
the new P-3C aircraft. All the displays are refreshed
from the computer's memory but it would be preferable to
have more capability external of the displays.

The first display is used in the pilot's station. ^^
Basically, the pilot tries to fellow a point on a 10"
display, which helps him know where he is going. The
second display is a horizontal situation indicator which
outputs a series of banking commands. The third is a
navigational control station with an auxiliary readout
device which provides navigational and tactical infor-
mation, and provides a means of accessing and modifying
the data base.

The fourth is a set of displays called "sensor sta-
tions", which are 15" multi-purpose displays providing
radar and contact information and monitoring returns from
buoys. Each of the I/O handlers contain the character-
istics of the device.



3.2



3.2.3 The ExGCUtiivo Program

The P-3C Update Executive program runs on the CP-901 computer
and provides a multiprogramming environment ^n a uniprocessor system.
The P-3C executive is designed in a mr^-^-^iar fashion, and provides for
additions and modifications to the system in a simple yet controlled
manner. The system is designed to be failsoft and will operate in a
degraded mode.

3.2.3.1 Memory

Memory is divided into pages of size 2K. The upper 4 bits
(11-14) is the page number and is translated to the appropriate paging
register. The effective address is then generated. (Because the half
word size is 15 bits, the greatest access is approximately 32,768 words.)

One of the problems that was mentioned in a trip visit was that
memory is protected only on f-"^ 2K boundaries (only write protected) .
A system that could offer protection within the page itself would be
very useful to the P-3C's.

Core management is provided only internally, for management of
transient tasks and files. Drum management is provided. Additionally,
a file management system is supplied for use with files on the drum (or
in core when the drum is not available) .

3 .2.3.2 Scheduling

There are a number of user tasks, each of which has associated
with it some number of entries at which the task can be scheduled.
Tasks can be permanent or transient; transient tasks are swapped between
core and the system drum as necessary.



3.3



The scheduler is fairly sophisticated, involving five (5)
preemption levels and 16 priorities within each level. The details
are available in the previously cited reference. It must be remembered
that of the 60 "periodic tasks" (units of work as seen by the executive) ,
15 of them are always active. The average execution time per task is
approximately 3-5 ms.

The scheduler accepts requests from executive interruot proc-
essing modules and from executive service request (ESR) modules. ESR
requests introduce new work into system. Any necessary core allocation
and drum reads (to bring modules into core) must be done.

If a task to be scheduled is already active, or in ready-to-
run state, then:

1) queue shall contain an entry for each request of a task

2) all entries for a task must be at the same state/priority
level

3) order is FIFO

Certain tasks (usually low priority periodic tasks) are not candidates
for scheduling if they are active or ready-to-run, i.e., they have al-
ready been scheduled but have not finished running.

There is a limited set of tasks which should run within 10 ms -
from request time (data acquisition and transm-.ssion) . There is a set
of periodic tasks which run repetitively every 50 ms. There are several
sets of long running tasks (700 ms) which share memory and processor
time with each other. The majority of tasks are demand and should run
within 500 ms of request. Also there are backgroxmd tasks.



3.4



There are 5 preemption levels, v;ith 16 priorities per level.
A preempted task in any level has the highest priority in that level.

Preemption levels:
Level

1 Tasks here cannot be preempted; they are dispatched in
priority order.

2 Tasks in this level can preempt any lower level tasks
unless they are 10 ms tasks or they have locked the
data base.

3 These tasks can only preempt level 5 tasks (if they have
not locked the data base or are not 10 ms tasks) .

4 Tasks here can only preempt level 5 tasks (unless they
are of the two (2) special types) . A preempted level 4
task is the last to run within its priority level.

5 liowest priority in the system. These tasks run only' when
no higher level tasks are ready.

The dispatcher places the highest level ready-to-run task in
control of the CPU. The dispatcher must restore the physical environ-
ment of a preempted task when it is restarted.

Other considerations:

1) Tasks which can complete within 10 ms are allowed to
run to completion.

2) A task which has issued a "lock data base" command and
has not unlocked it will be allowed to complete its
accesses and not be a candidate for preemption until the
data base is unlocked.



3.5



3.2.4 Other Features

There are approximately 300 tasks in the system, of which
60 are periodic 'n nature. There is a common data base available to
all 300 tasJ's. Displaying of data usually involves only a read only
access. The display maintenance program is the only one. that uses
entire data base.

The executive includes an input/output control module, which
includes handlers for system-required devices. This module can be
expanded to contain handlers for other devices in the system. The
P-3C Update Executive also includes extensive system analysis aids.

Most of the programming for the P-3C is in CMS-2, although
the executive is written in direct code.

9

There is no dynamic linking or loading available. The memory
reolacement algorithm attempts to keep a task in memory as long as
possible on the principle that if a task is used once, there is a high
probability that it will be used again.

The executive time stamps all data that enters the system.
The short term tasks can run for as little as 10 milliseconds. Long
term tasks can run for as long as a maximum of 400 to 500 ms.



3.6



3. 3 The PROTEUS System

The Proteus system is an accoustic processing system
for real-time analysis of incoming sonar data. It consists
of three Pioteus Advanced Signal Processor units (ASPs) - the
anal^Ler, post-processor, and display processor - each consisting
of at least a general purpose processor (CP/IO) and optimally
additional hardware to aid in each processors respective func-
tions. It is intended to be the Navy standard interim airborne
signal processor with planned utilization on the P-3 aircraft
on helicopters and on the "lamps" aircraft.

3.3.1 Hardware

The general purpose processor (CP/IL) is architectur-
ally the same in all configurations of the ASP; however, it is
extensively microprograramible . There exist tailored CP/IO
instruction sets for each of the different configurations of the
ASP (analyzer, pest-processor, a display processor) . The basic
instruction sets are very close to that of the IBM 360/370 computer.

3.3.2 The Proteus Executive

The Proteus ASP has two executives currently undergoing
design and implementation - IBM' s originally specified executive,
and the Naval Air Development Center (NAVAIRDEVCEN) general pur-
pose executive. The later will probably be the executive chosen
for fleet utilization and will be discussed here. Basically, the
objective of the executive is to allow tasks to execute in a
periodic fashion to analyze incoming sonar data. Depending on
the particular ASP configuration (i.e., analyzer, post-processor,
display) , additional hardware must be kept (e.g. , the arithmetic
processors in the analyzer configuration) .



3.7



3.3.2.1 Memory Management

In the initial design there is no dynamic management. Al-
though all the programs currently fit in corp . the system is being
orovided with facilities to support swapr.ing.



3.3.2.2 Scheduler (Task Management )

There are three (3) types of scheduling algorithms used on
PROTEUS .

a) A fixed priority scheme whereby a task gets control of
the CRU according to its priority.

b) A " least time to go " algorithm for tasks whose run time
has been very accurately predetermined. This algorithm
appears to be the best for their use as far as efficient
scheduling is concerned. If a very critical task must
be performed, i' is simply given a very high priority
level.

c) Whenever the system is idle, a " background monitoring "
program will be run.

3.3.2.3 Initialization

This is accomplished with an Initial Program Load (IPL) process
whereby the Executive and user ir.cdulos v.'ill bo loaded into memory. Con-
trol is then transferred to the Executive initialization routine.

This routine determines where the Executive itself ends and
the "IPL table" begins. This table contains a list of entry points to
receive control of the central processor during initialization. The
executive scans each entry and sends an initialization message- This
"wakes up" each module, and when finished, the executive continues in-
ternal initialization.



3.3



3.3.2.4 Input/Output

Only the executive can initiate I/O directly; user modules
must issue an "I/O Request" ESR to the; Executive. I/O requests are
queued if an open channel ?s not available.

3.3.2.5 Interrupt Processing

During Executive initidlization , software linkup with the
interrupt mechanism is set up to the appropriate interrupt processor.
All status information is saved for restart. During interrupt process-
ing, higher priority interrupts remain enabled.

The executive is subject to "pseudo-periodic" interrupts,
mainly from an intercomputer channel. In general quick responses
will be required from the system, with certain functions having to be
perfonried every 50 ms.



3.9



3.3.2.6 Error Managcmerit

Proteus 's hardware automatically traps storaqa protection and
privileged instructions. The Executive also validates all user supplied
parameters, such as entry point addresses, I/O requests, etc.

If an arithmetic error occurs, the Executive suspends the
task and sends a message to its parent module. This module may take any
corrective action required. If the task is not aborted, execution will
resume.

If the error was an addressing or privileged instruction
violation, a message is sent to the parent module and the task is
aborted. No restart is attempted.

I/O errors cause the Executive to attempt to recover and
make the' channel usable. The Executive then reports to the task, via
the I/O status word.

Main errors, such as power failure, halt the machine with
the error displayed in a fixed part of memory, or on a panel readout.

3.3.2.7 Performance Monitoring

»
Proteus monitors both the computer system and itself con-
tinually. This allows optimization, system debugging aid, and fine
tuning .

3.3.2.8 Data Management

Data management is different in scope for different functions,
usually consisting of tables of data in core memory. Data is always
recorded, with the system keeping track of information, (such as: how
many times the interrupt occurred; v?hen a task was last scheduled; and
how many times it was scheduled) . ^ .



3.10



3.3.3 PROTEUS CP/IO Executive Analysis

The PROTEUS CP/IO executive is a general purpose
operating system designed to handle user needs in any of the
configurations of the advanced signal p- ocessor (ASP) . It
has a standard user interface and


1 2 4 6 7 8 9 10 11 12 13 14

Online LibraryDorian PunjA survey of Navy tactical computer applications and executives : report of a study by → online text (page 4 of 14)