NASA Contractor Report 181874 

1. 

Advanced Information Processing System: 

Input/Output System Services 

Tom Masotto 

Linda Alger 

THE CHARLES STARK DRAPER LABORATORY, INC. 

CAMBRIDGE, MA 02139 

Contract NAS1-18565 

August 1989 

National Aeronautics and 

Space Administration 

Langley Research Center 

Hampton, Virginia 23665-5225 
TABLE OF CONTENTS 

Title Page 

LIST OF ILLUSTRATIONS ........................................................................ v 

1.0 INTRODUCTION .............................................................................. 1 

1.1 AIPS Architecture ......................................................................... 1 

1.1.1 AIPS Networks ................................................................... 4 

1.2 AIPS System Software ................................................................... 5 

1.2.1 AIPS Software Design Approach ............................................... 5 

AIPS System Software Overview .............................................. 5 

1.2.2.1 Local System Services ................................................ 8 

1.2.2.2 Inter-Computer System Services .................................. 10 

1.2.2.3 System Manager ..................................................... 10 

1.2.2.4 1/0 System Services ................................................. 11 

1.2.2 

2.0 I/O USER INTERFACE ..................................................................... 15 

I/O User Interface Functional Description ............................................ 15 

2.1.1 VO Request Construction ...................................................... 16 

2.1.2 1/0 Data Access Operations .................................................... 17 

2.1.3 VO Request Scheduling ........................................................ 19 

2.2 YO User Interface Software Specifications ............................................ 20 

2.2.1 VO Request Construction ................... i .................................. 20 

2.2.1.1 Creation of a Transaction ........................................... 20 

2.2.1.2 Creation of a Chain .................................................. 23 

2.2.1.3 Creation of an VO Request ......................................... 24 

2.2.2 1/0 Data Access Operations .................................................... 27 

2.2.2.1 VO User Interface Write Procedures .............................. 27 

2.2.2.2 1/0 User Interface Read Procedures ............................... 29 

2.2.2.3 User Interface Selection and Deselection Procedures ........... 31 

2.2.2.4 VO User Interface Error Checking Procedures .................. 33 

2.2.2.5 1/0 User Interface Overrun Check ................................. 34 

2.2.3 VO Request Scheduling ........................................................ 35 

2.2.3.1 Synchronization Using Flags ...................................... 35 

2.2.3.2 Synchronization Using Events ..................................... 36 

2.3 I/O User Interface Software Process Descriptions ................................... 38 

2.3.1 VO System Services VO Request Specification ............................. 38 

2.3.2 VO System Services Application Log ........................................ 56 

2.4 I/O User Interface Data Dictionary ..................................................... 58 

2.1 

3.0 VO COMMUNICATIONS MANAGEMENT ............................................. 61 

3.1.1 1/0 Traffic Control .............................................................. 61 

3.1.1.1 Queue Management ................................................. 62 

3.1.1.2 I/O Request Execution .............................................. 63 

3.1.1.3 I/O Request Completion ............................................ 65 

3.1.2 1/0 Low Level Utilities ......................................................... 65 

3.2.1 VO Traffic Manager ............................................................ 66 

3.2.1.1 Queue Management ................................................. 66 

3.2.1.2 VO Request Execution .............................................. 68 

3.2.1.3 VO Request Completion ............................................ 71 

3.1 VO Communications Management Functional Description ......................... 61 

3.2 The VO Communications Management Software Specifications ................... 66 

... 

PRECEDING PAGE BLANK NOT FILMED 

... 

lll 
3.2.2 I/O Low Level Utilities ......................................................... 72 

3.3 I/O Communications Management Software Process Descriptions ................ 73 

3.3.1 I/O System Services Queue Manager ......................................... 74 

3.3.2 

3.3.3 

3.3.4 

3.3.5 

3.3.6 

3.3.7 

3.3.8 I/O System Services Shared Memory Allocation .......................... 111 

3.3.9 

3.4 I/O Communications Management Data Dictionary ................................. 122 

I/O System Services IOP Construct VO Requests .......................... 90 

VO System Services Main Initialization ...................................... 97 

I/O System Services Communication of Specifications Task ............. 98 

I/O System Services Posting Tasks ......................................... 100 

I/O System Services IOP Powerup .......................................... 102 

I/O System Services Global Memory Utilities ............................. 107 

I/O SystemServicesDualPo~Memory Map .............................. 118 

3.3.10 I/O System Services Private ID Types ...................................... 120 

4.0 I/O SYSTEM SERVICES USER EXAMPLE ............................................ 129 

4.1 Overview ................................................................................ 129 

4.2 Construction of an VO Network Topology ......................................... -131 

4.3 Creation of an I/O Request ............ : ............................................... 134 

4.4 Creation of an Application Task ...................................................... 139 

4.5 Passing Control to an Application Task .............................................. 142 

5.0 CONCLUSIONS AND RECOMMENDATIONS ....................................... 145 

5.1 Testing of the I/O System Services ................................................... 145 

5.2 Performance Memcs .................................................................... 146 

5.3 Future Work ............................................................................. 148 

6.0 REFERENCES ............................................................................... 151 

APPENDIX A GLOSSARY OF I/O NETWORK TERMS ................................. A-1 

APPENDIX B 

APPENDIX C I/O SEQUENCER ............................................................. C-1 

I/O SERVICE OPERATING RULES ....................................... B-1 

iv 
8 . 

LEX OF ILLUSTRATIONS 

Tme page 

1 . 

2 . 

3 

4 

5 . 

6 . 

7 . 

8 . 

9 . 

10 . 

11 . 

12 . 

13 . 

14 . 

15 . 

16 . 

17 . 

18 . 

19 . 

AIPS Distributed Configuration .............................................................. 3 

AIPS System Design Approach .............................................................. 6 

Centralized AIPS Configuration .............................................................. 7 

Top Level View of System Services ........................................................ -8 

Inter-Computer System Services ........................................................... 11 

I/O System Services ......................................................................... 13 

Local System Services ......................................................................... 9 

System Manager .............................................................................. 12 

Interprocessor Synchronization for Communication of YO Request Specifications . 23 

Data Structure .. used for YO Request Construction and Interprocessor 

Communication ............................................................................... 25 

Control Flow for VO Request Execution and Completion ............................. -69 

I/O System Services Network Data Types Package ..................................... 129 

I/O System Services Central Database Package ......................................... 130 

I/O Request Package ........................................................................ 130 

CP Main Initialization Package ............................................................ 131 

40 Request Processing Times for the Sample Application ............................ 145 

40 Request Processing Times for the Sample Application (Continued) ............. 146 

Application Tasks Package ................................................................. 130 

I/O System Services Timings for the Sample Application .............................. 147 

V 
1.0 INTRODUCI'ION 

This purpose of this report is to document the functional requirements and detailed 

specifications for the UO System Services of the Advanced Information Processing System 

(AIPS). This introductory section is provided to outline the overall architecture and 

functional requirements of the AIPS system. Section 1.1 gives a brief overview of the 

AIPS architecture as well as a detailed description of the AIPS fault tolerant network 

architecture, while Section 1.2 provides an introduction to the AIPS system software. 

Sections 2 and 3 describe the functional requirements and design and detailed specifications 

of the VO User Interface and Communications Management modules of the VO System 

Services, respectively. Section 4 illustrates the use of the UO System Services, while 

Section 5 concludes with a summary of results and suggestions for future work in this 

area. 

The Advanced Information Processing System is designed to provide a fault- and damagetolerant data processing architecture which can serve as the core avionics system for a 

broad range of aerospace vehicles being researched and developed by NASA. These 

vehicles include manned and unmanned space vehicles and platforms, deep space probes, 

commercial transports, and tactical military aircraft. 

AIPS is a multicomputer architecture composed of hardware and software 'building blocks' 

that can be configured to meet a broad range of application requirements. The hardware 

building blocks are fault-tolerant, general purpose computers (GPCs), fault- and damagetolerant inter-computer and input/output networks, and interfaces between the networks and 

the general purpose computers. The software building blocks are the major software 

functions: local system services, inputloutput system services, inter-computer system 

services and the system manager. This software provides the services necessary in a 

traditional real-time computer such as task scheduling and dispatching, communication with 

sensors and actuators, etc. The software also supplies the redundancy management 

services necessary in a redundant computer and the services necessary in a distributed 

system such as inter-function communication across processing sites, management of 

distributed redundancy, management of networks, and migration of functions between 

processing sites. 

The AIPS hardware consists of a number of computers located at processing sites which 

may be physically dispersed throughout a vehicle. These processing sites are linked 

together by a reliable, damage-tolerant data communication pathway called the InterComputer (IC) bus. Since the hardware implementation of this "virtual bus" is a circuitswitched network, but from the GPC communication and protocol viewpoint it appears as a 

conventional bus, the terms "bus" and "network" an used interchangeable throughout this 

document. A computer at any particular processing site may also have access to varying 

1 
numbers and types of InpudOutput (UO) buses, which are separate from the IC bus. The 

UO buses may be global, regional or local in nature. VO devices on the global VO bus are 

available to all, or at least a majority, of the AIPS computers. Regional buses connect VO 

devices in a given region to the processing sites located in their vicinity. Local buses 

COMW a computer to the VO devices dedicated to that computer. Additionally, UO devices 

may be connected directly to the internal bus of a processor and accessed as though the VO 

devices reside in the computer memory (memory mapped YO). Both the VO buses and the 

IC bus are timedivision multiple-access contention buses. Figure 1 shows the laboratory 

engineering model for a distributed AIPS configuration. This distributed AIPS 

configuration includes all the hardware and software building blocks mentioned earlier and 

was conceived to demonstrate the feasibility of the AIPS architecture. 

The laboratory configuration of the distributed AIPS system shown in Figure 1 consists of 

four processing sites. Each processing site has a General Purpose Computer (GPC). 

GPCs may be simplex or they may be FTPs of varying redundancy levels. Of the four 

FTPs in the laboratory configuration, one is simplex, one is duplex, and two are triplex 

processors. An FTP may also be quadruply redundant but none was fabricated for the 

AIPS laboratory demonstration. The redundant FTPs are built such that they can be 

physically dispersed for damage tolerance; each of the redundant channels of an FIT can be 

as far as 5 meters from other channels of the same FI'P. 

The GPCs are interconnected by a triplex circuit-switched network. Each network layer 

forms a full two way 'virtual bus'. The three layers are totally independent and are not 

cross-strapped to each other. Each layer contains a circuit-switched node for each 

processing site; thus every processing site is serviced by three nodes of the IC network. 

GPCs are designed to receive data on all three layers, but the capability of a GPC to 

transmit on the network depends on the GPC redundancy level. Triplex FTPs can transmit 

on all three layers, duplex FTPs on only two of the three layers, and simplex processors on 

only a single layer. In duplex and triplex FI'Ps, a given processor can transmit on only one 

network layer. Thus malicious behavior of a processor can disrupt only one layer. 

The IC network and the GPC interfaces into the network are designed in strict accordance 

with fault-tolerant systems theory. Thus an arbitrary random hardware fault, including 

Byzantine faults, anywhere in the system can not disrupt communication between triplex 

FTPs. In other words, the triplex IC network, in conjunction with the GPC interfaces into 

the network, provides error-masking capability for communication between two triplex 

computers. 

The laboratory demonstration of the YO network is implemented using a 15-node circuitswitched network that interfaces with each of the GPCs on 1 to 6 nodes, depending on the 

GPC redundancy level. The 15 VO nodes can be configured in the laboratory as global, 

regional, and local 1/0 networks to demonstrate various dimensions of the AIPS VO. 

concept. 

2 
E 

Q) 

v) 

c, 

v) 

v) 

0 

E 

0 

YI 

r 

E 

m 

0 

0 

U 

m 

2 

m 

P) 

c 

0) 

a 

c 

a 

c 

w 

.- 

L 

.- 

p 

Figure 1. AIPS Distributed Configuration 

3 
1.1.1 AIPS Networks 

For communication between GPCs and between a GPC and UO devices, a damage and 

fault tolerant network is employed. The network consists of a number of full duplex links 

that are interconnected by circuit switched nodes. In steady state, the circuit switched 

nodes route information along a fixed communication path, or 'virtual bus', within the 

network, without the delays which are associated with packet switched networks. Once the 

virtual bus is set up within the network the protocols and operation of the network are 

similar to typical multiplex buses. Every transmission by any subscriber on a node is heard 

by all the subscribers on all the nodes just as if they were all linked together by a linear bus. 

Although the network performs exactly as a bus, it is far more reliable and damage tolerant 

than a linear bus. A single fault or limited damage can disable only a small fraction of the 

virtual bus, typically a node or a link connecting two nodes. Such an event does not 

disable the network, as would be the case for a linear bus. The network is able to tolerate 

such faults due to the richness of interconnections between nodes. By reconfiguring the 

network around the faulty element, a new virtual bus is constructed. Except for such 

reconfigurations, the structure of the virtual bus remains static. 

The nodes are sufficiently intelligent to recognize reconfiguration commands from the 

network manager, which is resident in one of the GPCs. The network manager performs 

the necessary diagnostics to identify the failed element and can change the bus topology by 

sending appropriate reconfiguration commands to the affected nodes. 

Damage caused by weapons or electrical shorts, overheating, or localized fire would affect 

only subscribers in the damaged portion of the vehicle. The rest of the network, and the 

subscribers on it, can continue to operate normally. If the sensors and effectors are 

themselves physically dispersed for damage tolerance, and the damage event does not affect 

the inherent capability of the vehicle to continue to fly, then the digital system would 

continue to function in a normal manner or in some degraded mode as determined by 

sensor/effector availability. 

Fault isolation is much easier in the network than in multiplex buses. For example, a 

remote terminal transmitting out of turn, a rather common failure mode which will totally 

disable a linear bus, can be easily isolated in the network through a systematic search where 

one terminal is disabled at a time. Furthermore, for networks of moderate size, up to 50 

nodes, most faults can be detected, isolated and the network reconfigured in milliseconds. 

The network can be expanded very easily by linking the additional nodes to the spare ports 

in existing nodes. In fact, nodes and subscribers to the new nodes (YO devices or GPCs) 

can even be added without shutting down the existing network. In bus systems, power to 

buses must be turned off before new subscribers or remote terminals can be added. 

Finally, there are no topological constraints, as are encountered with linear or ring buses. 

4 
In fact, these are simply subsets of the fault-tolerant network architecture. 

1.2 AlPSSystemSoftware 

The AIPS system software, as well as the hardware, has been designed to provide a virtual 

machine architecture that hides hardware redundancy, hardware faults, multiplicity of 

resources, and distributed system characteristics from the applications programmer. 

Section 1.2.1 discusses the approach used for the AIPS system software design. Section 

1.2.2 is a high level description of the system services that are provided for AIPS users. 

1.2.1 AIPS Sobe Design Approach 

The approach used to design the AIPS system software is part of the overall AIPS system 

design methodology. An abbreviated form of this system design methodology is shown in 

Figure 2. This methodology began with the application requirements and eventually led to 

a set of architectural specifications. The architecture was then partitioned into hardware and 

software functional requirements. This report documents the design approach used for 1/0 

System Services software, beginning with the functional requirements and proceeding 

through detailed specifications. 

Hardware and software for the AIPS architecture is being designed and implemented in two 

phases. The first phase is the centralized AIPS configuration. The centralized AIPS 

architecture, as shown in Figure 3, is configured as one triplex Fault Tolerant Processor 

(FTP), an InpuVOutput network and the interfaces between the FTP and the network, 

referred to as input/output sequencers (10s). The laboratory demonstration of the 

input/output network consists of 15 circuit-switched nodes which can be configured as 

multiple local VO networks connected to the triplex GPC. For example, the VO network 

may be configured as one 15-node network, as shown in Figure 3, or as three 5-node 

networks. The software building blocks that have been designed and implemented for the 

AIPS centralized architecture include local system services and VO system services. The 

following subsection 1.2.2 gives an overview of all the AIPS software building blocks. 

The rest of this document, Sections 2 through 4, focuses on the functional design and 

detailed specification of the VO System Services. 

1.2.2 AlPS System Sohare Overview 

As shown in Figure 4, AIPS system software provides the following AIPS System 

Services: local system services, communication services, system management, and VO 

system services. The system software is being developed in Ada. System services are 

modular and partitioned naturally according to hardware building blocks. The distributed 

AIPS configuration includes all the services. Versions of the system software for specific 

applications can be created by deleting unused services from this superset. The System 

Manager functions reside on only one GPC, but all functions of the System Manager are 

5 
r7 Application 

Requirements 

 specification^ 

Functional 

System Software 

Specifications Syatom Hardware 

Specifications 

Figure 2. AIPS System Design Approach 

not necessarily on the same GPC. The other system services are replicated in each GPC. 

The following is a brief description of each of the services. 

6 
15-NODE I/O NETWORK 

DIU 

0 

- 

- 

DIU 

c6 

Node 

Active 

Spare 

TRIPLEX FTP 

Link 

Link 

Device Interface Unit 

GPC/Network Interface (I/O Sequencer) 

figure 3. Centralized AIPS Configuration 

7 
Figure 4. Top Level View Of System Services 

1.2.2.1 Local System Services 

The local system services provided in each GPC are: GPC initialization, real-time operating 

system, local resource allocation, local GPC Fault Detection, Isolation, and 

Reconfiguration (FDIR), GPC status reporting, and local time management (see Figure 5). 

The function of GPC initialization is to bring the GPC to a known and operational state 

from an unknown condition (cold start). Each channel of a GPC has two processors: a 

computational processor (CP) and an inpudoutput processor (IOP). GPC initialization 

synchronizes the CPs with each other, synchronizes the IOPs with each other, and resets or 

initializes the GPC hardware and interfaces (interval timers, real time clock, interface 

sequencers, DUART, etc.) It makes the hardware state of the redundant channels 

congruent by alignment of memory and control registers. It then activates the system 

baseline software that is common to every GPC. 

The AIPS real-time operating system supports task execution management, including 

scheduling according to priority, time and event occurrence, and is responsible for task 

dispatching, suspension and termination. It also supports memory management, software 

exception handling, and intertask communication between companion processors (IOP and 

CP). The AIPS operating system resides on every CP and IOP in the system. It uses the 

vendor-supplied Ada Run Time System (RTS), and includes additional features required 

for the AIPS real-time distributed operating system. 

8 
m 

SYNC 

GPC ' LOCAL 

~NFK; ICSTATUS 

1 

&AL LOCAL 

+ + SYSTEM STATUS TIME STATUS 

Figure 5. Local System Services 

The GPC resource allocator coordinates and determines responsibility for any global or 

migratable functions from the system resource manager. It also monitors commands from 

the system resource manager to start or stop any function. 

The GPC status reporter collects status information from the local functions, the local GPC 

FDIR, the IC system services and the UO system services. It updates its local data base 

and disseminates this status information to the system manager. 

GPC FDIR has the responsibility for detecting and isolating hardware faults in the CPs, 

IOPs, and shared hardware. It is responsible for synchronizing both groups of processors 

in the redundant channels of the FTP and for disabling outputs of failed channel(s) through 

interlock hardware. After synchronization, all CPs will be executing the same machine 

language instruction within a bounded skew, and all IOPs will be executing the same 

machine language instruction within a bounded skew. GPC FDIR logs all faults and 

reports status to the GPC status reporter. It is responsible for the CPU hardware exception 

handling and downmoding/upmoding hardware in response to configuration commands 

from the system manager. It is also responsible for transient hardware fault detection and 

for running low priority self tests to detect latent faults. This redundancy management 

function is transparent to the application programmer. 

The local time manager works in cooperation with the system time manager to keep the 

local real time initialized and consistent with the universal time. It is also responsible for . 

9 
providing time services to all users. A detailed description of the Local System Services in 

provided in [ 11. 

1.2.2.2 Inter-Computer System Services 

The inter-computer system services provide two functions: (1) inter-computer user 

communication services, that is, communication between functions not located in the same 

GPC, and (2) inter-computer network management (Figure 6). 

The IC user communication service provides local and distributed inter-func tion 

communication which is transparent to the application user. It provides synchronous and 

asynchronous communication, performs error detection and source congruency on inputs, 

and records and reports IC communication errors to IC network managers. Inter-computer 

communication can be done in either point to point or broadcast mode and is implemented 

in each GPC. 

The IC network manager is responsible for the fault detection, isolation and reconfiguration 

of the network. The AIPS distributed configuration consists of three identical, independent 

IC network layers which operate in parallel to dynamically mask faults in a single layer and 

provide reliable communication. There is one network manager for each network layer. 

However, the three network layer managers do not need to reside in the same GPC. They 

are responsible for detecting and isolating hardware faults in IC nodes and links and for 

reconfiguring their respective network layer around any failed elements. The network 

manager function is transparent to all application users of the network. 

1.2.2.3 System Manager 

The system manager is a collection of system level services including the applications 

monitor, the system resource manager, the system fault detection, isolation and 

reconfiguration (FDIR), and the system time manager (Figure 7). 

The applications monitor interfaces with the applications programs and the APS system 

operator. It accepts commands to migrate functions from one GPC to another, to display 

system status, to change the state of the system by requesting a hardware element state 

change, and to convey requests for desired hardware and software configurations to the 

system resource manager. 

The system resource manager allocates migratable functions to GPCs. This involves the 

monitoring of the various triggers for function migration such as failure or repair of 

hardware components, mission phase or workload change, operator or crew requests and 

10 
REAIu)<= Fu" 

FLAG ALLOCATION 

ICmoRK 

m COMMAND GPC STATUS 

LOCAL IC STATUS 

Figure 6. Inter-Computer System Services 

timed events. It reallocates functions in response to any of these events. It also designates 

managers for shared resources and sets up the task location data base in each GPC. 

The system fault detection, isolation and reconfiguration (FDIR) is responsible for the 

collection of status from the inter-computer (IC) network managers, the I/O network 

managers, and the local GPC redundancy managers. It resolves conflicting local fault 

isolation decisions, isolates unresolved faults, correlates transient faults, and handles 

processing site failures. 

The system time manager, in conjunction with the local time manager on each GPC, has the 

job of maintaining a consistent time across all GPCs. The system time manager indicates to 

the local time manager when to set its value of time. It also sends a periodic signal to 

enable the local time manager to adjust its time to maintain consistency with an external time 

source such as the GPS Satellites or an internal source such as the real time clock in the 

GPC which hosts the system time manager software. 

1.2.2.4 I/O System Services 

The UO system services provide efficient and reliable communication between the user and 

external devices (sensors and actuators). The I/O system services software is also 

responsible for the fault detection, isolation and reconfiguration of the I/O network 

hardware and GPC/network interface hardware (inpudoutput sequencers). 

I/O system services is made up of three functional modules: I/O user interface, I/O 

communication management and the UO network manager (Figure 8). 

The I/O user interface provides a user with read/write access to VO devices or device 

interface units (DIUs), such that the devices appear to be memory mapped. It also gives the 

11 
Figure 7. System Manager 

user the ability to group VO transactions into chains and I/O requests, and to schedule VO 

requests either as periodic tasks or on demand tasks. 

The VO communication manager provides the functions necessary to control the flow of 

data between a GPC and the various I/O networks used by the GPC. It also performs 

source congruency and error detection on inputs, voting on all outputs, and reports 

communication errors to the I/O network manager. It is also responsible for the 

management of the VO request queues. 

The VO network manager is responsible for detecting and isolating hardware faults in VO 

nodes, links, and interfaces and for reconfiguring the network around any failed elements. 

The network manager function is transparent to all application users of the network. 

The I/O user interface, I/O communications management, and VO redundancy management 

modules are dependent processes, as illustrated in Figure 8. The VO communication 

management process uses the database of VO request specifications (VO request database) 

that is constructed by the I/O user interface. In addition, the I/O user interface and 

communications management modules interact when communicating the 1/0 data, 

12 
Figure 8. I/O System Services 

synchronizing the CP and IOP tasks, and processing of the IlO requests. The 1/0 

communications management process interacts with the VO redundancy management 

module for the communication of network status, diagnostic information, and FDIR 

commands. Furthermore, the communication management and redundancy management 

modules both use the VO database and VO low level utilities. 

Sections 2 and 3 describe the functional requirements and design and detailed specifications 

of the UO User Interface and VO Communications Manager, respectively. The software 

requirements and specifications for the UO Network Manager are described in [2]. Section 

4 illustrates the use of the VO .System Services for the applications programmer, and 

Section 5 concludes with a summary of results. 

13 
2.0 YO USER INTERFACE 

The VO User Interface provides a user with access to VO devices or device interface units 

@IUS). It provides this access to the DIUs in such a way that to the applications user they 

appear to be memory mapped. That is, each DIU with which the FTP interfaces can be 

simply addressed by means of redwrite routines that simulate memory mapped YO to the 

user. It also provides the user with the option of either single or chained transactions on an 

VO network (a transaction is an HDLC frame sent to a single DIU using the HDLC 

protocol; a chain or chained transactions is an ordered set of one or more transactions 

addressed to devices on one VO network). The use of chained transactions allows very 

efficient use of the network bandwidth. Redundant chains can be executed in a (nearly) 

simultaneous fashion on redundant VO networks to provide data to and from redundant 

devices with a bounded time skew. VO activity may be scheduled to run periodically or on 

demand. The VO User Interface provides the means to form VO requests from single or 

chained transactions and to schedule VO requests (an VO request is a set of one or more 

single or chained VO transactions, each of which executes on a different I/O network). 

These VO request specifications result in CP/IOP shared memory assignments for data and 

error information for each DIU transaction. In addition, the VO User Interface provides 

system calls for safely accessing those memory mapped locations. Although DIUs are 

connected to a fault tolerant network, all network access protocols, source congruency and 

error processing on inputs, and fault masking on outputs are transparent to the user. 

The description of the VO User Interface is divided into three sections: functional 

description, software specifications, and software process descriptions. 

21 I/O User Interface Functional Description 

The VO User Interface is divided into three functions: VO Request Construction, 40 Data 

Access Operations, and VO Request Scheduling. 

I/O USER 

INTERFACE 

I . 1 1 m m 

I/O REQUEST I/O DATA ACCESS I/O REQUEST 

CONSTRUCTION OPERATIONS SCHEDULING 

The VO Request Construction function allows the user to create VO transactions, specify 

how they will be grouped and how each I/O request will be scheduled. The I/O Data 

Access Operations provide the read/write routines that allow the user to access VO chain 

15 

PRECEDING PAGE BLANK NOT FILMED 
data in shared memory,-while hiding the CP/IOP protocol from the user. The VO Request 

Scheduling provides the user with the flexibility to schedule each UO request as a cyclic 

free running task that runs and signals the caller when each cycle has completed or an ondemand task that is only scheduled when requested. 

2.1.1 VO Request Construction 

The applications user can construct transactions, chains, and UO quests in an hierarchical 

manner. Initially, the parameters associated with each transaction must be specified. 

Secondly, the transactions that are sequentially executed as a unit on one network are 

grouped to form an VO chain. Finally, the chains are grouped into UO requests to fully 

maximize the bandwidth of the communications network by allowing the simultaneous 

execution of chains on the parallel networks of an VO service. The applications user can 

construct one or more VO requests for each VO service (an UO service is a logical 

organization imposed on I/O network use) as dictated by the requirements of the 

application. 

The VO User Interface requires several parameters to be specified in order to create an UO 

transaction. The user has to specify whether the transaction will request information from 

or send a command to a DIU (input and output transaction respectively). In either case, the 

DIU must be specified. In addition, the user must provide the number of data bytes to be 

sent to the DIU (all transactions) and the number of data bytes that will be returned by the 

DIU (all input transactions). Accordingly, the location(s) of the appropriate data buffer(s) 

on the CP must be specified in order to readwrite the data associated with the DIU. The 

user must also specify whether the output data is dynamic or static. If the data is dynamic, 

then it is copied into the 10s prior to each execution of the associated chain. If the data is 

static, then it is copied into the 10s only once. For input transactions, the user must 

specify the maximum number of errors that are tolerable before the transaction is bypassed 

(deselected by the VO System Services) and the transaction time-out which is the maximum 

time that can expire before a byte of data is received from the DIU. The VO User Interface 

constructs a record using this information and returns a transaction identifier (ID) to allow 

the user to later identify the transaction. 

After the transactions are specified and created, they are grouped to form chains. Chains 

allow efficient use of the communications bandwidth, but are only applicable to a single 

network. Accordingly, the user must specify the transactions that will form the chain, and 

the network on which they will be executed. The VO User Interface records the chain 

information and returns a chain identifier to the user. 

After the chains are specified and created, they are grouped into 40 requests. An VO 

request is a set of one or more chains each of which simultaneously executes on a parallel 

network of an VO service. The creation of the VO request requires the user to specify the 

chains that will form the request. In addition, the user must provide the YO request time 

16 
out which is the maximum length of time that the VO request requires the VO network (used 

for UO request execution and processing). Furthermore, the desired scheduling 

requirements must be provided. This scheduling information specifies if the VO request is 

periodic or on demand, the priority of the request, and the frequency with which VO 

request uses an event to signify its completion. If the I/O request is periodic, the 

scheduling requirements also specify the repetition period, how it is started (after-delay, 

on-event, or at-absolute-time), and how it will stop (never-stop or stop-on-event). The 

VO User Interface records the I/O request information and returns an I/O request identifier 

to the user. 

In order to make the redundancy management, source congruency, multiprocessing 

(CP/IOP) communications protocol, and fault masking transparent to the user, the VO 

specifications (transaction, chain, and VO request) must be communicated through shared 

memory to the IOP. The IOP uses the information to construct a set of companion records. 

The companion records are transaction, chain, or VO request specification records that are 

the IOP duals of CP transaction, chain, or UO request records. The companion records are 

used when processing the VO requests. A CP/IOP handshaking protocol is incorporated to 

insure that the VO request specifications and associated data are not corrupted during their 

transmission through shared memory. 

2.U I/O Data Access Operations 

The ID Data Access Operations provide redwrite routines that allow the user to access UO 

data in shared memory that appears to the user to be memory mapped. The redundancy 

management of the fault-tolerant network, network access protocols, source congruency 

and error processing on the inputs, fault masking on the outputs, and CP/IOP 

communications protocol are transparent to the user. The applications user is able to write 

commands to and request information from the DIUs. In addition, select and deselect 

system calls are available allowing the user to add and remove transactions from their 

corresponding chains (enabling error recovery and dynamic UO request reconfiguration). 

The VO Data Access routines also allow the user to determine whether or not errors 

occurred in the UO requests and to isolate the location of the error(s) if one (or more) 

resulted. 

The user can send control data to the DIUs using the UO User Interface write procedures. 

Command information (output data) can be sent a DIU by writing data to the transactions 

that communicate with the DIU. The data can be modified on a transaction by transaction, 

chain by chain, or request by request basis. The CP must write the data into shared 

memory to communicate it to the IOP. The IOP reads the data and writes it into the dual 

ported memory of the 10s prior to executing the VO request. Since the IOP may attempt to 

read the data from shared memory while the CP may be modifying it, semaphores and 

double buffering are used to maintain consistent data sets. Since a chain is executed as a 

unit, the data associated with the chain must also be considered a unit. Accordingly, it is 

17 
not sufficient that the semaphores simply lock access to the transactions. The semaphores 

must, at least, control the access to the VO chain data. 

The user can read the information returned by the DIUs (input data) using the VO User 

Interface read procedures. Accordingly, the user can obtain response data from the DIUs, 

process the data, and generate output commands based upon the results. The data can be 

read on a transaction by transaction, chain by chain, or request by request basis. As with 

the write procedures, semaphores and double buffering are used to maintain consistent data 

throughout the chains. The data returned by the DIUs may be corrupted by errors. The VO 

User Interface returns a parameter that notifies the user of an occurrence of an error. In 

addition, the data returned to the user may not have been updated since the previous read 

procedure ("old data"). The occurrence of "old data" signifies that a scheduling overrun 

has occurred except when the YO request and its associated applications task are not 

synchronized (Le. both are free running cyclic tasks). The I/O User Interface allows the 

user to check whether or not the data has been modified since the data was last read. 

The occurrence of errors in the network may cause a DIU to become inaccessible. As a 

result, a transaction requesting data from that DIU would not contain any valid information. 

The ability to deselect a transaction allows the user to remove any undesired transactions 

from a chain. The deselection command is communicated to the IOP through shared 

memory. Since the IOP may be executing an VO request when the deselection procedure is 

called, the CP may not be able to immediately send the command. The application tasks 

should not have to wait for the deselect command to be accepted by the IOP. As a result, 

the deselect procedure returns a parameter specifying whether or not the deselection request 

was accepted. 

The restoration of failed elements of the network may cause a previously inaccessible DlUs 

to become reachable. The select procedure allows the user to include previously deselected 

(or bypassed) transactions in the I/O chains. As with the deselect procedure, the VO User 

Interface returns a parameter specifying whether or not the selection request was accepted. 

As previously mentioned, the data returned by the DIUs may be corrupted by errors. The 

user is notified of the occurrence of errors by a parameter returned by the read procedure 

call. The I/O User Interface allows the user to determine if the error was in a chain (chain 

time out) or a transaction of a chain. The user can isolate the location of an error and 

disregard the corrupted data. 

The creation of an I/O request requires the specification of its scheduling requirements (see 

Section 2.1.1 - VO Request Construction). The VO request is scheduled on the IOP based 

on these specifications and is executed when the requirements are met. If the VO request is 

not able to executed when the scheduling requirements have been fulfilled, a scheduling 

overrun occurs. The VO User Interface allows the user to check whether or not an overrun 

has occurred. 

18 
2.13 YO Request Scheduling 

The UO Request Scheduling provides the application with the flexibility to schedule each 

VO request as a cyclic free running task that runs and signals the caller when complete or an 

on demand task that is only scheduled when requested. The user specifies the scheduling 

requirements for the UO requests when the VO requests are mated (see Section 2.1.1 - VO 

Request Construction). 

Each VO request may correspond to one or more application tasks defined by the user. 

Accordingly, the YO User Interface must provide synchronization mechanisms to 

coordinate the VO requests with the application tasks. The synchronization mechanisms 

provided by the VO System Services are events and flags. Events are signals which are 

observed by the GPC Real Time Operating System. The events interrupt the co-processor 

and are used to activate/deactivate a task on the co-processor. Flags are passive signals 

which may be observed or ignored by the application tasks. The flags do not interrupt the 

co-processor and are used to indicate the completion of the VO requests. 

The completion of an 40 request is indicated by a flag in shared memory. The VO System 

Services on the IOP sets the flag when the VO request completes whether or not errors 

occurred. The application tasks on the CP can read and clear the flag. 

The completion of an UO request is indicated by an event if the user has specified this 

option when creating the VO request. The VO System Services on the IOP signals the 

event when the VO request completes whether or not errors occurred. These events are 

used to activate application tasks (via the GPC Real Time Operating System) that are 

blocked waiting for the completion of an VO request. The VO User Interface provides a 

mechanism for an application task to obtain a pointer to an event, allowing the task to be 

scheduled as an event-driven process. 

On demand VO requests are started on the IOP only when the user issues a start command. 

When an on demand VO request is created, the user must specify the priority of the request, 

how often the completion event should be set, and the VO request time-out. 

Periodic VO requests are executed periodically on the IOP. Accordingly, the user must 

specify the period of the VO request. In addition, the priority of the VO request and VO 

time-out must be provided. The periodic VO requests may be scheduled to start on 

demand, at a specific time, or after a specific amount of time has expired. Furthermore, the 

periodic YO requests may be scheduled to run forever or to stop on demand. 

19 
23 VO User Interface Sohare Specifications 

As discussed in Section 2.1, the VO User Interface is divided into three sections: 40 

Request Construction, VO Data Access Operations, and VO Request Scheduling. 

The VO Request Construction function involves the allocation and initialization of VO 

request records on the CP, data buffers in shared memory, and pmgradclata regions on the 

VO Sequencer (10s - see appendix C for detailed description). This function also 

communicates the VO request specifications to the IOP and creates companion VO records 

(the IOP transaction, chain and VO request specification records that arc the IOP duals of 

the transaction, chain and UO request records on the CP) which are used when executing 

and processing the VO requests. 

The Data Access Operations use the shared memory data buffers allocated during the VO 

Request Construction to provide the appearance of memory mapped VO. These functions 

use semaphores and double buffering to maintain consistent data sets. The Data Access 

Operations also control the interprocessor communication required to allow the user to 

select/deselect transactions and obtain error information. 

The VO Request Scheduling function supports the use of flags and events to synchronize 

application tasks on the CP with their corresponding VO requests. 

2.2.1 YO Request Construction 

The applications user is able to construct transactions, chains, and VO requests in an 

hierarchical manner. Since the 40 requests are created on the CP and all 40 activity is 

performed by the VO System Services on the IOP, the VO Request Construction process 

must initialize the CP, IOP and shared memory. The design of the I/O Request 

Construction function is discussed in the following sections. 

2.2.1.1 Creation of a Transaction 

The basis of the construction of an VO request is the specification of an VO transaction. 

The format for the creation of a transaction is as follows: 

CREATE-TRANSACTION( TRANSACTION-ID, 

TRANSACTION-INFO); 

where 

TRANSACTION-ID is an identifier (returned by the VO User Interface) which 

uniquely specifies the transaction. The applications programmer uses the 

TRANSACTION-ID when using system calls during later operation. 

20 
TRANSACTION-INFO is a discriminated record (provided by the user) based on 

whether it is an INPUT or OUTPUT transaction (specified by its IO parameter). 

1. The TRANSACI'ION-INFO record always has the following fields: 

DIU-ID is an identifier that specifies the device interface unit addressed. 

NUM-DATABYTES-OUT is a parameter which specifies the number of 

bytes that will be sent to the DIU. 

DYNAMIC-OR-STATIC is a boolean that specifies whether the output data 

associated with the transaction is dynamic or static. 

DATA-BUFFER-OUTPUT is a parameter which specifies the address on the 

CP of the user's output data buffer (for specifying output commands to the DIU 

for this transaction). 

2. If IO = INPUT, then the TRANSACTION-INFO record has the following 

additional fields: 

NUM-DATA-BYTES-IN is a parameter which specifies the number of bytes 

that will be returned by the DIU. 

MAXBEFORE-BYPASS is a parameter which specifies the maximum 

number of errors that can be tolerated before the transaction is bypassed. If the 

parameter is zero, then the transaction will not be bypassed. 

TIME-OUT is a parameter which specifies the maximum length of time (even 

number of microseconds) that can expire before an incoming data byte is 

received. 

DATA-BUFFER-INPUT is a parameter which specifies the address on the CP 

of the user's input data buffer (to record the response data from the DIU for this 

transaction) 

The CREATE-TRANSACTION call allocates and initializes a transaction record object 

using the information provided by the user. The allocation of the record involves the 

initialization of an element of a local transaction pointer array. The local transaction pointer 

array accesses a transaction record using the transaction ID as an index. As a result, the I/O 

User Interface can directly access any information associated with a transaction, if its ID is 

known. The UO User Interface returns the transaction ID to allow the application to 

identify each transaction. The identity of the transaction is necessary when the user 

constructs chains, checks for transaction errors, and selects/deselects transactions. 

21 
Due to limited dual ported memory (4000 bytes for user VO chains and data) in the IOS, the 

number of transactions that can be created is limited. When the transaction is created, the 

size requirements of the transaction (program and data memory requirements) are calculated 

and compared to the available memory space. If memory required is less than the memory 

available, then a section of dual ported memory is reserved for this transaction. If the 

memory required is greater than the available memory, an exception is raised to the user 

indicating the problem. 

After the initialization of the transaction record, the CREATE-TRANSACTION process 

running on the CP allocates two input data buffers (if an input transaction) and two output 

data buffers in shared memory. Two sets of YO data buffers are allocated per transaction to 

eliminate data contention problems between the VO System Services readwrite tasks 

executing on the CP and the readwrite tasks executing on the IOP. Data contention is 

eliminated because each processor is always able to obtain one of the two buffers. The 

processor that is writing data into shared memory determines which buffer is available (not 

locked by the other processor) prior to writing. The processor that is reading data 

determines the available buffer that contains the most current data. In order to select and 

lock the I/O buffers, the processes running on the CP and IOP allocate common data buffer 

select variables (pre-defined flags) in shared memory. These select variables are protected 

by semaphores so that the variables are only modified by one process at a time. In 

addition, two error status records are allocated in shared memory to associate error 

information with each set of VO buffers. As a result, this "Double Buffering" scheme 

allows the simultaneous writing and reading of VO request data (to different buffers) while 

maintaining consistent data and error information. 

After the VO buffers have been allocated, the output data buffers are initialized if the user 

provides initial data. The CP process then waits (polls a flag) until the corresponding IOP 

communication task acknowledges (sets the flag) that it can accept the new transaction 

record. The CP process then writes the transaction specifications to shared memory. The 

CP process also writes, into a predefined memory location, the addresses of the previously 

allocated shared UO data buffers. After the information has been written, the CP process 

signals the IOP communication task using an event. The IOP task reads the transaction 

specifications, allocates a compahion transaction record, initializes a local transaction 

pointer, and creates the transaction record. The communication protocol between the CP 

and IOP is illustrated in the Figure 9. 

22 
CP IOP 

Parameters; 

Allocate SM based I 

011 the User's Desired Number 

OfDataBytes; 

Wait-fw-IOP-Ready ; 

Put the Addrs of the 

SM Data Buffers into SM 

Put the Record Info. into 

m 

Initialize the SM 

Data Buffer; 

Use an Event to 

Schedule the IOP 

Communication Task; 

I 

Completion Signal from Previous Cycle 

Allowing this Procedure Call to Proceed /- 

Wait-fOr-!khedule; 

Dynamically Allocate a 

RecordType; 

ReadtheRecord 

Paramern from SM; 

Read the Addrs of the SM 

Data Buffers; 

Initialize Local Record 

Pointer; 

Use a Flag to Signal the 

Completion of the Initialization / of the Companion Record 

1 

End Loop; 

Completion Signal allowing Next 

Procedure Call to Proceed 

Figure 9. Interproasor Synchmnization for Communication 

of I/O Request Specifications 

2.2.12 Creation of a Chain 

After the specification of the transactions, they are grouped into chains. The format for the 

specification of a chain is as follows: 

CREATE-C"( CHAIN-ID, 

NETWORK-ID, 

TRANS ACTION-LIST) 

where 

CHAINJD is an identifier (returned by the I/O User Interface) which uniquely 

specifies the chain. The application uses the CHAIN-ID when using system calls 

during later operation. 

23 
NETWOW-ID is an identifier which specifies the network on which the chain will 

be executed (provided by the user). 

TRANSACTION-LIST is a variant object which specifies the number of 

transactions in the chain and the corresponding array of TRANSACTION-IDS 

(provided by the user). 

The CREATE-CHAIN call allocates and initializes a chain record object using the 

information provided by the user. The allocation of the record involves the initialization of 

an element of a local chain pointer array. The local chain pointer array accesses a chain 

record using the chain ID as an index. As a result, the VO User Interface can directly 

access any information associated with a chain, if its ID is known. The initialization 

process forms a doubly linked tree between the transactions and their respective chain 

allowing direct access to a chain from a transaction or to a transaction from a chain 

(illustrated in Figure 10). The CP process returns the chain ID to allow the applications 

user to identify each chain. The identity of the chain is necessary when the user constructs 

VO requests and checks for chain errors. 

After the allocation and initialization of the chain record, the CP process communicates the 

information to the IOP communication task using the same protocol as involved in sending 

transaction records. The IOP task creates a companion chain record on the IOP and assigns 

an element of its local chain pointer array to point to it. 

2.2.13 Creation of an YO Request 

After the specification of the chains, they are grouped into VO requests. The format for the 

specification of an I/O request is: 

CREATELIOR( IOR-ID, 

CHAIN-LIS T, 

SCHED-INFO) 

where 

IOR-ID is an identifier (returned by 1/0 User Interface) which allows the 

application to uniquely specify the I/O request. The applications programmer uses 

the IORJD when using system calls during later operation. 

24 
YO Request 

Record 

Rgure 10. Data Structure wed for YO Request Comtm& 'on and Interprocessor 

CHAIN-LIST is a variant object which specifies the number of chains in the UO 

request and the corresponding array of CHAIN-IDS (provided by user). 

SCHED-INFO is a discriminated record (provided by the user) based on whether it 

is an ON-DEMAND or PERIODIC I/O request (specified by its 

HOW-SCHEDULED parameter). 

1. The SCHED-INFO record always has the following fields: 

PRIORITY is a parameter which specifies the priority (0 - 7) of the associated 

IOP task. A lower priority number implies a lower degree of urgency and an 

VO request with a priority of 7 will preempt lower priority requests. 

COMPLETION-EVENT is a parameter indicating the frequency 

(ONCE-ONLY, ALWAYS, NEVER) with which an VO request uses an event 

to signify its completion. 

IOR-TIME-OUT is a parameter which specifies the maximum length of time 

(in microseconds) that an I/O request actively possesses an I/O network(s) 

25 
during its execution. The parameter is used by the VO System Services when 

executing and processing the VO request. 

2. If HOW-SCHEDULED = PERIODIC, then the SCHED-INFO record requires 

the following additional fields: 

REPETITION-PERIOD is a parameter which specifies the length of the 

repetition period in seconds. 

WHEN-TO-STOP is an enumeration type which may be assigned to 

NEVER-STOP or STOP-ON-DEMAND. The parameter is used to specify 

how the I/O request should complete. 

START is a discriminated record based on whether the HOW-STARTED 

discriminate is specified to be START-ON-DEMAND, 

START-AFER-DELAY, or START-AT-ABSOLUTE-TIME. 

a. If HOW-STARTED = START-ON-DEMAND 

b. If HOW-STARTED = START-AFTER-DELAY 

- Additional fields are not necessary. 

- The additional field WAIT-FOR is necessary which specifies the 

length of time to wait before the VO request is initiated (in seconds). 

- The additional field AT-ABSOLUTE-TIME is necessary to specify 

C. If HOW-STARTED = START-AT-ABSOLUTE-TIME 

the time to start the VO request (in seconds). 

The CREATE-TOR call allocates and initializes an VO request record object using the 

information provided by the user. The allocation of the record involves the initialization of 

an element of a local I/O request pointer array. The local VO request pointer array accesses 

an VO request record using the VO request ID as an index. As a result, the VO User 

Interface can directly access any information associated with an VO request, if its ID is 

known. The initialization process forms a doubly linked tree between the chains and their 

respective VO request (allowing direct access to an VO request from a chain or to a chain 

from an VO request). As a result; transactions can indirectly access their associated VO 

request as illustrated in the Figure 10. The CREATE-IOR process running on the CP 

returns the VO request ID to allow the applications user to identify each request. The 

identity of the request is necessary when referencing VO requests from application 

proces se s/t as ks . 

The initialization of the VO request record involves the calculation of a VO System Services 

VO request time out. As previously mentioned, the VO request time out is the length of 

time that the VO request actively possesses an VO network(s) during its execution. Since 

each chain of the VO request executes (nearly) simultaneously, the VO request time out only 

26 
depends on the longest chain time out. The chain time out, which is the length of time a 

chain requires possession of a network, is based on the number of transactions, length of 

the transaction time outs, and amount of VO data associated with the chain. After the UO 

System Services v”0 request time out is calculated, it is compared to the VO request time out 

provided by the user to determine if the user’s UO request time out is too short. If the 

user’s I/O request time out is deemed to be too short, a warning is issued to the user. 

After the allocation and initialization of the 1/0 request record, the CP process 

communicates the information to the IOP communication task using the same protocol as 

involved in sending transaction records. The IOP task creates a companion VO request 

record and assigns an element of its local UO request pointer array to point to it. 

2.22 VO Data Access Operations 

The applications user is able to access the data associated with the VO requests in a memory 

mapped fashion. The appearance of memory mapped VO is accomplished by allocating 

data sections in shared memory to emulate the data regions of the 10s and making the 

reading/writing protocol transparent to the user. The VO Data Access function also 

provides error detection and chain reconfiguration capabilities to the user. The design of 

the VO Data Access function is discussed in the following sections. 

222.1 VO User Interface Write Procedures 

The I/O User Interface allows the user to write output data to DIUs on a transaction by 

transaction or VO request by VO request basis. The ability to write data only to a 

transaction is desirable when a chain is mixed but primarily consists of static command 

frames. The ability to write data to all of the output data buffers is desirable when one or 

more of the chains of an VO request are mixed but primarily consist of dynamic command 

frames. The procedures for writing output data to DIUs are as follows: 

1. WRITE-TRANSACTION( TRANSACTION-ID, 

IOR-DATA-IS-CONSISTENT, 

LOCKED); 

2. WRITE_IOR( IOR-ID, 

LOCKED); 

3. WRITEINITIAL-IOR-DATA( IOR-ID, 

-); 

27 
TRANSACTION-ID is a parameter which uniquely identifies the associated 

transaction. It is assigned by the system when the transaction is created and must 

be provided by the user for the WRITETRANSACIION system call. 

IOR-ID is a parameter which uniquely identifies the associated VO request. It is 

assigned by the system when the VO request is created and must be provided by the 

user for the WRITE_IOR system call. 

IOR-DATA-IS-CONSISTENT is a boolean (provided by the user) which, when 

TRUE, signifies that the output data for the 40 request is consistent. 

LOCKED is a boolean (returned by VO User Interface) which, when TRUE, 

signifies that the shared memory buffer select area was locked when the 

applications process/task attempted to select an output buffer. 

Since the VO System Services on the IOP controls access to the 10s dual ported memory, 

the output data is written into shared memory from the CP rather than directly to the 10s. 

An output data buffer select variable is used to determine an available buffer. The buffer 

select variable is guarded by a semaphore to guarantee mutual exclusion. After a buffer is 

selected, the output data is written and the buffer is made available to the I/O System 

Services on the IOP. As a result, the chain output data sets of the VO request are consistent 

and VO data contention is avoided. 

The WRITE-IOR procedure performs a test and set operation on the semaphore that guards 

the output data buffer select variable for the VO request and if the select region is unlocked, 

it selects an available buffer, unlocks the select region, and writes the dynamic output data 

for the entire VO request into shared memory. If the buffer select variable is locked, the 

procedure continues to perform the test and set operation until the region becomes unlocked 

or 100 test and set iterations pass. If 100 iterations pass and the select region is still 

locked, it is assumed that a fault has caused a deadlock situation (select region is locked but 

neither processor has control of it). If such a deadlock situation occurs, the procedure 

disregards the semaphore, determines the available buffer, resets the semaphore, sets the 

LOCKED parameter, and writes the output data. 

After the output data has been written into shared memory, the select variables must be 

updated to specify the available buffer with the most current data. The WRITE-IOR 

procedure performs the test and set process as previously described, and when the select 

region is unlocked, the buffer select variable (in shared memory) is set equal to the buffer 

into which the output data was written. 

28 
Similarly, the WRlTE-TRANSACTION procedure checks the locking mechanism, selects 

a buffer, and writes the output data for the specified transaction. Yet, the user may want to 

change one transaction in each chain before the associated VO request is executed. 

Accordingly, the Write Transaction procedure allows the user specify if the data is 

consistent throughout the VO request. If the data is not consistent, the buffer is not made 

available to the VO System Services on the IOP, and the VO System Services will read the 

other data buffer until the user states that the data is consistent. As a result, the user does 

not have to worry about an I/O request being executed with inconsistent data. 

The WRITE-INITIAL-IOR-DATA procedure is identical to the WRITE-IOR procedure 

except that it writes all of the VO request output data (dynamic and static) into shared 

memory. Typically, this procedure is used to initialize the 10s output buffers. 

232.2 I/O User Interface Read Procedures 

The I/O User Interface allows the user to read input data from DIUs only on an VO request 

by VO request basis. Since the input data is dynamic, all of the input data associated with 

an YO request is desired. The format for reading data from DIUs is as follows: 

READ-IOR( IOR-ID, 

LOCKED, 

ERROR, 

OLD-D ATA) ; 

where 

IOR-ID is a parameter which uniquely identifies the associated VO request. It is 

assigned by the system when the I/O request is created and must be provided by the 

user for the READ-IOR system call. 

LOCKED is a boolean (returned by 40 User Interface) which, when TRUE, 

signifies that the shared memory buffer select area was locked when the 

applications process/task attempted to select an input buffer. 

ERROR is a boolean (returned by 1/0 User Interface) which, when TRUE, 

signifies that an error occurred in at least one of the chains of the I/O request. The 

application can isolate the location of the error by invoking the procedures 

TRANSACTION-ERROR and CHAIN-ERROR. 

OLD-DATA is a boolean (returned by VO User Interface) which, when TRUE, 

signifies that the VO request data was NOT updated by the IOP since the previous 

READ-IOR call. The data was NOT read during this call. 

29 
Since the VO System Services running on the IOP controls access to the 10s dual ported 

memory, the input data is read from shared memory to the CP rather than directly from the 

10s. An input data buffer select variable is used to determine the available buffer that 

contains the most current data. A semaphore is used to guarantee that the buffer select 

variable is only modified by one processor at a time (note that this is a different semaphore 

than that used for output data buffers). After the available buffer is selected, it is locked by 

the VO System Services on the CP to maintain consistent data throughout the buffer 

(prevents the VO System Services on the IOP from writing into the buffer while the CP is 

reading from it), and the input data and associated error information is read into the CPs 

local memory. 

The READ-IOR procedure performs a test and set operation on the semaphore that guards 

the input data buffer select variable for the VO request and if select region is unlocked, the 

procedure selectsflocks an available buffer, unlocks the select region, and reads the input 

data and error status for the VO request. If the buffer select variable is locked, the 

procedure continues to perform the test and set operation until the region becomes unlocked 

or 100 test and set iterations pass. If 100 iterations pass and the select region is still 

locked, it is assumed that a fault has caused a deadlock situation (region is locked but 

neither processor has control of it). If such a deadlock situation occurs, the procedure 

disregards the semaphore, determines the available buffer, resets the semaphore, sets the 

LOCKED parameter, and reads the input data and error information. 

After the input data and error status has been read from shared memory, the input data 

buffer select variable must be updated to unlock the input data buffer. The Read VO 

request procedure performs the test and set process as previously described, and when the 

select region is unlocked, the buffer is unlocked by modifying the select variable in shared 

memory. 

The VO Request Completion Function (discussed in Section 3.1.1.3) checks for chain and 

transaction errors. The errors are communicated to the VO System Services on the CP by 

setting flags in shared memory. The ERROR flag is an ORing of all chain and transaction 

errors. 

An "old data" flag is returned to the application task to notify the task that the input data has 

not been updated since it was last read. This flag is set by the Read VO Request process, 

and it is reset when the IOP writes new data into the shared data buffers. If the Read VO 

Request procedure returns a true value in the OLDDATA flag and the application process 

is synchronized with the VO request, then a scheduling overrun has occurred. 

30 
2.2.23 I/O User Interface Selection and Deselection Pmcedures 

The I/O User Interface allows the user to select and deselect transactions from their 

corresponding chains. As a result, the user has some error recovery control and can 

dynamically reconfigure the VO requests. The format for selecting and deselecting 

transactions is as follows: 

1. SELEm-TRANSACI'XON( TRANSACTION-ID, 

REQUEST-ACCEPTED) 

2. DESELECT-TRANSACTION( TRANSACTION-ID, 

REQUEST-ACCEPTED) 

where 

TRANSACTION-ID is a parameter which uniquely identifies the associated 

transaction. It is assigned by the system when the transaction is created and must 

be provided by the user for the SELECT-TRANSACTION or 

DESELECT-TRANSACTION system call. 

REQUEST-ACCEPTED is a boolean (returned by VO User Interface) that, if 

TRUE, signifies that the command was accepted. 

As previously mentioned, the VO System Services on the IOP controls access to the 10s 

dual ported memory. Accordingly, the transaction selection (or deselection) command 

must be communicated to the IOP. The basic unit of information that must be transmitted is 

the type of command (selection or deselection) and transaction ID. The VO User Interface 

uses two five element arrays, two semaphores and two boolean flags to communicate 

transaction selection and deselection commands from the CP to the IOP. The arrays (one 

for selection and one for deselection) are buffers to communicate the transaction IDS to the 

IOP. The semaphores are used to maintain consistent sets of IDS, and the boolean flags are 

used to notify the IOP of the selection and deselection commands. The CP control flow 

involved in the communication of a SELECT-TRANSACTION procedure call is outlined 

below: 

1) The application invokes the SELECT-TRANSACTION system call. 

2) The CP Select Transaction process test and sets the semaphore locking the 

shared memory select buffer. 

3) If the IOP is reading from or writing to the buffer (is locking the region), the 

Select Transaction process notifies the application that the request was not 

accepted. 

31 
If the IOP is not reading from or writing to the buffer (the region is available), 

the Select Transaction process searches for the first unused element in the array 

(the test and set function has locked the buffer). 

If the array is full (five selection requests are pending), the Select Transaction 

process notifies the application that the request was not accepted and unlocks 

the buffer. 

If an element of the array is available, the Select Transaction process initializes 

the element, sets a shared memory flag to notify the IOP, and unlocks the 

buffer. 

The IOP control flow involved in the processing of an VO request (with respect to the 

SELECT_TRANSACTION and DESELECI'-TRANSACTION procedure calls) is outlined 

The Queue Manager task accepts a pending I/O request to be processed. 

The Queue Manager task checks the selection shared memory flag to determine 

if a selection request has been made. 

If the flag is not set, then the Queue Manager task processes the VO request. 

If the flag is set, the task test and sets the semaphore locking the shared 

memory select buffer. 

If the CP is reading from or writing to the buffer (is locking the region), the 

Queue Manager processes the VO request. 

If the CP is not reading from or writing to the buffer (the region is available), 

the Queue Manager process reads the first transaction ID (the test-and set 

function has locked the buffer). 

The Queue Manager task modifies the 10s program area to select the 

transaction, initializes the transaction ID to a null value, and checks the array to 

determine if another transaction is to be selected. 

If another transaction ID is in the shared memory buffer, then (7) is repeated. 

If not, then the Queue Manager task unlocks the select buffer. 

After the select transaction requests have been processed, the Queue Manager 

repeats the same process (2-8) for deselection requests. 

10) After the deselect transaction requests have been processed, then the Queue 

Manager task processes the I/O request. 

To deselect a transaction, the Queue Manager task modifies the chain program so that the 

10s skips over the set of instructions used to execute the deselected transaction. To select a 

transaction, the task modifies the chain program so that the 10s does not skip over the 

relevant set of instructions. 

32 
2.2.2.4 I/O User Interface Em Checking procedures 

Errors may occur during the execution of the 40 requests. The user is notified of the 

occmnce of an erroxfs) when the input data corresponding to the VO request is read. The 

VO User Interface provides system calls to allow the user to determine the location of the 

error@). The formats for these calls are as follows: 

1. TRANSACTION-ERROR(TRANSACTI0NJD) 

2. TRANSACTION-ISBYPAS SED(TRANSACTI0NJD) 

3. CHAIN-ERROR( CHAIN-ID, 

ERROR-IN-CHAIN, 

ALL-TRANS ACTIONS-ARE-BAD, 

CHAIN-DID-NOT-COMPLETE, 

TRANS ACTION-NOT-EXECUTED, 

NETWORK-STATUS) 

where 

TRANSACTION-ID is a parameter which uniquely identifies the associated. 

transaction. It is assigned by the system when the transaction is created and must 

be provided by the user for the TRANSACTION-ERROR function call. 

CHAIN-ID is a parameter which uniquely identifies the associated chain. It is 

assigned by the system when the chain is created and must be provided by the user 

for the CHAIN-ERROR procedure call. 

ERROR-IN-CHAIN is a boolean parameter (returned by the I/O User Interface) 

that, if TRUE, signifies that an error occurred during the execution of the chain. 

ALL-TRANSACTIONS-ARE-BAD is a boolean parameter (returned by the I/O 

User Interface) that, if TRUE, signifies that errors occurred in all of the transactions 

of the chain. 

CHAIN-DID-NOT-COMPLETE is a boolean parameter (returned by the VO User 

Interface) that, if TRUE, signifies that the chain did not complete when the VO 

request was processed. 

TRANSACTIONS-NOT-EXECUTED is a boolean parameter (returned by the VO 

User Interface) that, if TRUE, signifies that one or more transactions in the chain 

were not executed because they were deselected and/or bypassed. 

33 
NETWORK-STATUS is a enumerated object (returned by the I/O User Interface) 

that signifies the state of the network when the 1/0 request was executed 

(In-Service, Temporarily-Out-of-Service, Permanently-Out-of-Service). 

As discussed in the VO Communications Management Functional Requirements (Section 

3.1), the VO Traffic Control function performs the VO Request Completion processing. 

The VO Request Completion function primarily consists of chain and transaction error 

processing. If an error is detected, then flags are set in shared memory to notify the VO 

System Services on the CP of its existence and location. Each transaction has two boolean 

status flags (to convey error and bypass information) and each chain has five status flags 

(in correspondence with the parameters returned by the CHAIN-ERROR procedure). The 

CHAIN-ERROR procedure returns the state of the corresponding error flags to the user. 

If the state of the ERROR-IN-CHAIN boolean is true, then the transaction(s) which has an 

error can be isolated using the TRANSACTION-ERROR procedure. Furthermore, if the 

state of the TRANSACTION-NOT-EXECUTED flag is true, the 

TRANSACTION-IS-BYPASSED procedure can be used to determine whether or not a 

transaction has been bypassed by the I/O System Services. The 

TRANSACTION-IS-BYPASSED procedure specifies which transactions have been 

bypassed by the I/O System Services (not deselected by the user). If one or more 

transactions have been deselected by the user, the TRANSACTION-NOT-EXECUTED 

flag will be set by the 1/0 System Services, but the 'associated 

TRANSACTION-IS-BYPASSED fields will not be set. The application must account for 

the transactions that it &selects. 

The status information returned by the CHAIN-ERROR, TRANSACTION-ERROR, and 

TRANSACTION-IS-BYPASSED procedures is only valid after the READ-IOR 

procedure has been called due to the "Double Buffering" scheme. Since two sets of VO 

buffers are used for interprocessor data communication, two sets of status buffers are 

required to maintain consistent dawstatus information (each data buffer must its own status 

buffer). When the READ-IOR procedure is called, one set of data and status buffers is 

written into the local memory on the CP from shared memory. The CHAIN-ERROR, 

TRANS ACTION-ERROR, and TRANS ACTION-ISB YPAS SED procedures read the 

status buffer in local memory when returning status information to the application. As a 

result, the READ-IOR procedure must be called prior to invoking any of these error 

checking procedures. 

2.2.25 I/O User Interface Overrun Check 

If an VO request can not be executed when its scheduling requirements have been fulfilled, 

then a scheduling overrun occurs. The VO User Interface allows the user to determine if an 

overrun has occurred using the following function call: 

IOR-HAS-OvERRUN(I0R-ID) 

34 
where 

IOR-ID is a parameter which uniquely identifies the associated VO request. It is 

assigned by the system when the VO request is created and must be provided by the 

user for the IOR-HAS-OVERRUN system call. 

The occmnce of an overrun is detected by the Posting task associated with the VO request 

(a Posting task is a ksk that is scheduled on the IOP based on the scheduling requirements 

of an UO request). A parameter (integer number) in shared memory is updated to reflect the 

occurrence (or frequency of occurrences) of an overrun. This parameter is read from 

shared memory and returned to the user by the IOR-HAS -OVERRUN function. 

223 I/O Request Scheduling 

Each I/O request may correspond to one or more application tasks executing on the CP. 

Since the VO requests are processed on the IOP, the VO User Interface must provide flags 

and events (synchronization mechanisms) to coordinate the VO requests with the 

application tasks. 

2.2.3.1 Synchronization Using Flags 

Flags are used to indicate the completion of VO requests. The VO Request Completion 

processing involves the setting of a flag in shared memory to notify the user that the request 

has been executed and processed. The VO User Interface allows the user to read and clear 

these flags. 

1. IOR-READY(I0R-ID) 

2. CLEAR-IOR-READY(I0RJD) 

3. IORJXEADY-AND-CLEAR(IOR-ID) 

where 

IOR-ID is a parameter which uniquely identifies the associated VO request. It is 

assigned by the VO System Services when the VO request is created and must be 

provided by the user for the system call. 

The IOR-READY function call reads the completion flag associated with the VO request 

identified by the IOR-ID parameter. If the VO request has completed, then the flag will be 

set (true). The flag may be cleared using the procedure CLEAR-IOR-READY. In 

35 
addition, the flag can be read and cleared in a single step using the procedure 

IOR-READY-AND-CUAR. 

Flags are also used to synchronize the I/O System Services on the CP and the IOP. The 

IOP must wait for the CP to create and communicate the UO request specifications. 

Alternatively, the CP must wait for the IOP to initialize the UO Services. Accordingly, 

functions are provided to allow the CP to signal and wait for the IOP. 

1. CP-COMPLETED 

The CP-COMPLETED function sets a flag in shared memory to acknowledge the 

completion of YO request initialization process. The WAIT-UNTIL-IOP-COMPLETED 

function allows the CP to wait until the IOP initializes the I/O Services before continuing. 

2.2.3.2 Synchronization Using Events 

The completion of an I/O request is indicated by an event if user has specified this option 

when creating the I/O requests. The I/O User Interface allows the user to obtain a pointer 

to the UO request completion event allowing the scheduling of application tasks through the 

GPC Real Time Operating System. The format for the function call is as follows: 

IOR-COMPLETION-EVENT( IOR-ID) 

where 

IOR-ID is a parameter which uniquely identifies the associated I/O request. It is 

assigned by the system when the I/O request is created and must be provided by the 

user for the system call. 

The frequency that the I/O User Interface uses an event to signal the completion of an I/O 

request is specified when the request is created. The completion event may be specified to 

occur once only, always, or never. The event is used to either initially synchronize an 

application task with its corresponding I/O request or to periodically trigger an on demand 

application task. 

Events are also used to start and stop I/O requests. The following system calls are available 

to the user. 

1. START-IOR(IORJD) 

2. STOP-IOR(IOR-ID) 

36 
where 

IOR-IJl is a parameter which uniquely identifies the associated UO request. It is 

assigned by the system when the VO request is created and must be provided by the 

user for the system call. 

These procedure calls are used to start or stop an UO request after a periodic request has 

been created with the START-ON-DEMAND or STOP-ON-DEMAND option. The 

START-IOR procedure is also used to start on demand UO requests. 

37 
2.3 UO User Interface Sohare Process Descriptions 

IOSS - IOR-SPEC 

The VO User Interface Software Process Descriptions divide the description of the I/O User 

Interface into functional packages. This section uses Booch diagrams (a high level 

diagrammatic design methodology put forward by Grady Booch - see [3]) and process 

descriptions to present the Software Specifications in more detail. The Booch diagrams are 

used to map the VO User Interface Software Specifications into functional packages, tasks, 

and subprograms. The process descriptions are used to describe these functional groups in 

detail. 

The VO User Interface is divided into two functional packages: 40 System Services 40 

Request Specification and Application Log. 

23.1 UO System Services YO Request Specification 

CHAIN-ID-TYPE 1 

I 

PERIODIC-SCHED-RECORD I ~ 

IOR-SCHEJ-RECORD 

(TRANSACTION-INFO-RECORD 1 

CREATE-TRANSACTION 

I I 

DESELECT-TR ANS ACTION 

I READ_IOR I 

I 

38 
IOSS-IOR-SPEC 

START-IOR 

STOP-IOR I 1 

I IOR-READY I 

I I I IOR-H AS-OVERRUN 

WRITE-INITIAL-IOR-D ATA 

WAIT-FOR-IOP-COMPLETED 

I CP-COMPLETED I 

I 

7 WAIT-FOR-SPEC-RECEIVED 

39 
2.3.1.1 Process Name: Create Transaction 

Inputs: Transaction Information Record 

Reqllimnents 

Reference: 

Transaction Identifier 

Transaction Specifications 

VO User Interface Functional Requirements, Section 2.1.1 

VO User Interface Software Specifications, Section 2.2.1.1 

Nota: None 

The Create Transaction process allocates memory on the CP and initializes a transaction 

record (transaction specifications) based on the transaction information provided by the 

application. The application can create two types of transactions: 

1) An input transaction which involves an output sequence of instructions that 

requests information from a DIU and an input sequence of instructions that 

waits for the DIU response. 

2) An output transaction which consists of an output sequence of instructions that 

sends information to a DIU and does not expect a response. 

The application must provide the following information for all transactions: 

1) The type of transaction - input or output. 

2) DIU identifier. 

3) Number of output data bytes. 

4) Type of output data - dynamic or static. 

5) Pointer to the output data buffer on the CP. 

The application must provide the following additional information for input transactions: 

1) Number of input data bytes. 

2) Maximum number of errors allowable before system bypass. 

3) Allowable time out before an incoming data byte is received. 

4) Pointer to the input data buffer on the CP. 

The process calculates the transaction identifier and returns it to the application. The 

identity of the transaction is necessary when the user constructs UO chains, checks for 

transaction errors, and selects/deselects transactions. The process also initializes an 

element of a local transaction pointer array which allows the VO User Interface to access 

any information associated with the transaction if its ID is known. In addition, the process 

40 
initializes internal variables (variables that are transparent to the application) which are used 

far VO error processing. 

After the transaction record is initialized, the Create Transaction process communicates this 

information to the IOP communication task through shared memory. The communication 

process is initiated by waiting for the IOP task to acknowledge that it is ready for new data. 

After the acknowledgement has been received, the Create Transaction process writes the 

transaction record information into pre-defined locations. The process then allocates two 

sets of VO buffers in shared memory to communicate data between the CP and IOP. The 

pointers to these data buffers are communicated to the IOP task through pre-defined 

locations in shared memory. In addition, if the application provides initial output data, the 

process initializes the shared memory output data buffers. After the allocation and 

initialization is finished, the Create Transaction process uses an event to notify an IOP 

communication task that the new transaction specifications and data pointers are available 

and can be read. 

When the event activates the IOP communication task, the task creates and initializes a 

companion transaction record on the IOP and assigns an element of its local transaction 

pointer array to point to it. 

2.3.1.2 Process Name: Create Chain 

Network Identifier 

Transaction List 

Chain Identifier 

Chain Specifications 

Requiremenls 

RderenCe: I/O User Interface Functional Requirements, Section 2.1.1 

VO User Interface Software Specifications, Section 2.2.1.2 

Notes: None 

The Create Chain process allocates and initializes a chain record object using the 

information provided by the application. The allocation of the record involves the 

initialization of an element of a local chain pointer array. The local chain pointer array 

accesses a chain record using the chain identifier as an index. As a result, the VO User 

Interface can directly access any information associated with a chain, if its ID is known. 

The initialization process forms a doubly linked tree between the transactions and their 

respective chain (allowing direct access to a chain from a transaction or to a transaction 

41 
from a chain). The Create Chain process returns the chain ID to allow the applications user 

to identify each chain. The identity of the chain is necessary when the user constructs VO 

requests and checks for chain errors. 

After the allocation and initialization of the chain record, the Create Chain process 

communicates the information to the IOP communication task using the same protocol as 

involved in sending transaction records. The IOP task creates a companion chain record on 

the IOP and assigns an element of its local chain pointer array to point to it. 

2.3.1.3 Process Name: Create VO Request 

maw 

Requirements 

Reference: 

Scheduling Information 

Chain List 

VO Request Identifier 

VO Request Specifications 

VO User Interface Functional Requirements , Section 2.1.1 

UO User Interface Software Specifications, Section 2.2.1.2 

Nota: None 

The Create VO Request call allocates and initializes an VO request record object using the 

information provided by the user. The allocation of the record involves the initialization of 

an element of a local VO request pointer array. The local VO request pointer array accesses 

an UO request record using the VO request identifier as an index. As a result, the VO User 

Interface can directly access any information associated with an UO request, if its ID is 

known. The initialization process forms a doubly linked tree between the chains and their 

respective I/O request (allowing direct access to an VO request from a chain or to a chain 

from an I/O request). As a result, transactions can indirectly access their associated VO 

request. The CP returns the VO request ID to allow the applications user to identify each 

request. The identity of the request is necessary when referencing VO requests from 

application processes/tasks. 

After the allocation and initialization of the I/O request record, the CP communicates the 

information to the IOP using the same protocol as involved in sending transaction records. 

The IOP creates a companion VO request record and assigns an element of its local UO 

request pointer array to point to it. 

42 
2.3.1.4 Process Name: Select Transaction 

Transaction Identifier 

Note: 

Confirmation of Select Request being Accepted 

Transaction Select Flag 

Transaction Select Array 

VO User Interface Functional Requirements, Section 2.1.2 

VO User Interface Software Specifications, Section 2.2.2.3 

None 

Desaiptim: 

The Select Transaction process sends a selection request to the VO Communications 

Management function. The protocol involved in the communication of the selection request 

is discussed in detail in Section 2.2.2.3 of the VO User Interface Software Specifications. 

2.3.1.5 Process Name: Deselect Transaction 

Inpuk Transaction Identifier 

Requin?me!nts 

Reference: 

Confirmation of Deselect Request being Accepted 

Transaction Deselect Flag 

Transaction Deselect Array 

UO User Interface Functional Requirements, Section 2.1.2 

VO User Interface Software Specifications, Section 2.2.2.3 

Nota: None 

Desaiptim: 

The Deselect Transaction process sends a deselection request to the VO Communications 

Management function. The protocol involved in the communication of the deselection 

request is discussed in detail in Section 2.2.2.3 of the UO User Interface Software 

Specifications. 

43 
2.3.1.6 Process Name: Write UO Request 

UO Request Identifier 

State of the Locking Semaphore 

Dynamic Output Data 

UO User Interface Functional Requirements, Section 2.1.2 

UO User Interface Software Specifications, Section 2.2.2.1 

Notes: None 

The Write UO Request procedure performs a test and set operation on the semaphore that 

guards the output data buffer select variable for the I/O request. If the select region is 

unlocked, it selects an available buffer, unlocks the select region, and writes the dynamic 

output data for the entire UO request into shared memory. If the buffer select region is 

locked, the procedure continues to perform the test and set operation until the region 

becomes unlocked or 100 test and set iterations pass. If 100 iterations pass and the select 

region is still locked, it is assumed that a fault has caused a deadlock situation (select region 

is locked but neither processor has control of it). If such a deadlock'situation occurs, the 

procedure disregards the semaphore, determines the available buffer, resets the semaphore, 

sets the LOCKED parameter, and writes the output data. 

After the output data has been written into shared memory, the output data buffer select 

variable must be updated to specify the available buffer with the most current data. The 

Write UO Request procedure performs the test and set process as previously described, and 

when the select region is unlocked, the buffer select variable (in shared memory) is set 

equal to the buffer into which the output data was written. 

44 
2.3.1.7 Process Name: 

Note: 

Desaiptim: 

Read VO Request 

VO Request Identifier 

State of the Locking Semaphore 

Error Flag 

Old Data Flag 

Input Data 

VO User Interface Functional Requirements, Section 2.1.2 

40 User Interface Software Specifications, Section 2.2.2.2 

None 

The Read VO Request procedure performs a test and set operation on the semaphore that 

guards the input data buffer select variable for the VO request. If select region is unlocked, 

the procedure selectsbocks an available buffer, unlocks the select region, and reads the 

input data and error status for the 40 request. If the buffer select region is locked, the 

procedure continues to perform the test and set operation until the region becomes unlocked 

or 100 test and set iterations pass. If 100 iterations pass and the select region is still 

locked, it is assumed that a fault has caused a deadlock situation (region is locked but 

neither processor has control of it). If such a deadlock situation occurs, the procedure 

disregards the semaphore, determines the available buffer, resets the semaphore, sets the 

LOCKED parameter, and reads the input data and error information. 

The I/O Request Completion function checks for chain and transaction errors. The errors 

are communicated to the CP by setting flags in shared memory. An error flag is returned 

to the application, and it represents an ORing of all chain and transaction errors. 

An "old data" flag is returned to the application task to notify the task that the input data has 

not been updated since it was lasr read. This shared memory flag is set by the Read 40 

Request process, and it is reset when the IOP writes new data into the shared data buffers. 

If the Read VO Request procedure returns a true value in the "old data" flag and the 

application process is synchronized with the UO request, then a scheduling overrun has 

occurred. 

After the input data has been read from shared memory, the input data buffer select variable 

must be updated to unlock the input data buffer. The Read 40 request procedure performs 

the test and set process as previously described, and when the select region is unlocked, the 

buffer is unlocked by modifying the select variable in shared memory . 

45 
2.3.1.8 Process Name: Write Transaction 

Requirements 

Reference: 

Transaction Identifier 

Data is Consistent Boolean 

State of the Locking Semaphore 

Output Data for the Transaction 

VO User Interface Functional Requirements, Section 2.1.2 

VO User Interface Software Specifications, Section 2.2.2.1 

NdeS: None 

Description: 

The Write Transaction procedure performs a test and set operation on the semaphore that 

guards the output data buffer select variable for the UO request. If the select region is 

unlocked, it selects an available buffer, unlocks the select region, and writes the output data 

for the transaction into shared memory. If the buffer select region is locked, the procedure 

continues to perform the test and set operation until the region becomes unlocked or 100 

test and set iterations pass. If 100 iterations pass and the select region is still locked, it is 

assumed that a fault has caused a deadlock situation (select region is locked but neither 

processor has control of it). If such a deadlock situation occurs, the procedure disregards 

the semaphore, determines the available buffer, resets the semaphore, sets the LOCKED 

parameter, and writes the output data. 

The user may want to change one transaction in each chain before the associated VO request 

is executed. Accordingly, the Write Transaction procedure allows the user specify if the 

data is consistent throughout the I/O request. If the data is not consistent, the buffer is not 

made available to the UO System Services on the IOP. As a result, the user does not have 

to worry about an I/O request being executed with inconsistent data. 

After the output data has been written into shared memory, the output data buffer select 

variable must be updated to specify the available buffer with the most current data (if the 

data is consistent). The Write Transaction procedure performs the test and set process as 

previously described, and when the select region is unlocked, the buffer select variable (in 

shared memory) is set equal to the buffer into which the output data was written. 

46 
23.1.9 Process Name: YO Request Completion Event 

VO Request Identifier 

outpls Event Pointer 

Requirements 

RelerenCe: VO User Interface Functional Requirements, Section 2.1.3 

VO User Interface Software Specifications, Section 2.2.3.2 

Nota: None 

Description: 

The completion of an YO request is indicated by an event if user has specified this option 

when creating the YO requests. The YO Request Completion Event process allows the 

application to obtain a pointer to the 110 request completion event allowing the scheduling 

of application tasks through the GPC Real Time Operating System. The Completion Event 

is used to either synchronize an application task with its corresponding YO request or 

periodically trigger an on-demand application task. 

2.3.1.10 Process Name: Start VO Request 

Inputs: VO Request Identifier 

hm YO Request Start Event 

Requiremenps 

Reference: VO User Interface Functional Requirements, Section 2.1.3 

YO User Interface Software Specifications, Section 2.2.3.2 

Nota: None 

Desaiptim: 

Events are used to start and stop VO requests. The Start YO Request process is used to 

start an 1/0 request after a periodic request has been created with the 

START-ON-DEMAND option. The Start I/O Request process is also used to start 

on-demand YO requests. 

47 
23.1.11 Process Name: Stop 40 Request 

VO Request Identifier - VO Request Stop Event 

40 User Interface Functional Requirements, Section 2.1.3 

I/O User Interface Software Specifications, Section 2.2.3.2 

Nota: None 

Events are used to start and stop VO requests. The Stop VO Request process is used to 

stop an 40 request after a periodic request has been created with the STOP-ON-DEMAND 

option. 

2.3.1.12 Process Name: VO Request Ready 

Inpuis: VO Request Identifier 

VO Request Completion Flag 

ReqlJiRmtS 

Reference: 

Nota: 

VO User Interface Functional Requirements, Section 2.1.3 

VO User Interface Software Specifications, Section 2.2.3.1 

None 

Flags are used to indicate the completion of VO requests. The VO Request Completion 

processing involves the setting of a flag in shared memory to notify the application that the 

request has been executed and processed. The VO User Interface allows the user to read 

and clear these flags. 

The 40 Request Ready process reads the completion flag associated with the VO request 

identifier (provided by the application). If the VO request has completed, then the flag that 

is returned to the application will be set (true). 

48 
23.1.13 Process Name: Clear UO Request Ready 

Jnw UO Request Identifier 

ow- UO Request Completion Flag 

UO User Interface Functional Requirements, Section 2.1.3 

VO User Interface Software Specifications, Section 2.2.3.1 

Nde: None 

The Clear UO Request Ready procedure clears the completion flag that is associated with 

the UO request identifier (provided by the application). 

2.3.1.14 Process Name: UO Request Ready and Clear 

Inpuls: UO Request Identifier 

UO Request Completion Flag 

RetpliIVIIM!IltS 

Reference: VO User Interface Functional Requirements, Section 2.1.3 

UO User Interface Software Specifications, Section 2.2.3.1 

Note: None 

Flags are used to indicate the completion of I/O requests. The VO Request Completion 

processing involves the setting of a flag in shared memory to notify the application that the 

request has been executed and processed. The VO User Interface allows the user to read 

and clear these flags. 

The YO Request Ready and Clear process reads and resets the completion flag associated 

with the UO request identifier (provided by the application). 

49 
23.1.15 Process Name: 

hnputs: 

outplts 

Requirements 

Recgence: 

Nota: 

Desaiptim: 

Transaction Error 

Transaction Identifier 

Transaction Error Flag 

VO User Interface Functional Requirements , Section 2.1.2 

UO User Interface Software Specifications, Section 2.2.2.4 

None 

The 40 Request Complet-m function performs cllain and transaction error processing. If 

an error(s) occur in the execution of the I10 request, then the VO Request Completion 

function sets flags in shared memory to notify the VO System Services on the CP. The 

Transaction Error process checks for the occurrence of an error in a transaction by reading 

the associated error flag. 

The status information returned by the Transaction Error procedure is only valid after the 

Read VO Request procedure has been called due to the "Double Buffering" scheme. Since 

two sets of 40 buffers are used for interprocessor data communication, two sets of status 

buffers are required to maintain consistent dadstatus information (each data buffer must its 

own status buffer). When the Read 40 Request procedure is called, one set of data and 

status buffers is written into the local memory on the CP from shared memory. The 

Transaction Error procedure reads the status buffer in local memory when returning status 

information to the application. As a result, the Read UO Request procedure must be called 

prior to invoking the Transaction Error procedure. 

50 
23.1.16 Process Name: Transaction is Bypassed 

Requirements 

ReFerence: 

Notes: 

Desaiption: 

Transaction Identifier 

Transaction Bypassed Flag 

VO User Interface Functional Requirements , Section 2.1.2 

I/O User Interface Software Specifications, Section 2.2.2.4 

None 

The I/O Request Completion function performs chain and transaction error processing. If a 

transaction was not executed because it was deselected or bypassed, then the I/O Request 

Completion function sets flags in shared memory to notify the I/O System Services on the 

CP. The Transaction Is Bypassed process checks whether or not a transaction is bypassed 

by reading the associated status flag. 

The status information returned by the Transaction Is Bypassed procedure is only valid 

after the Read I/O Request procedure has been called due to the "Double Buffering" 

scheme. Since two sets of I/O buffers are used for interprocessor data communication, two 

sets of status buffers are required to maintain consistent datdstatus information (each data 

buffer must its own status buffer). When the Read I/O Request procedure is called, one set 

of data and status buffers is written into the local memory on the CP from shared memory. 

The Transaction Is Bypassed procedure reads the status buffer in local memory when 

returning status information to the application. As a result, the Read VO Request procedure 

must be called prior to invoking the Transaction Is Bypassed procedure. 

51 
23.1.17 Process Name: Chain Error 

Jnpues: Chain Identifier 

Note: 

Chain Error Flag 

All Transactions are Bad Error Flag 

Chain Did Not Complete Error Flag 

Transaction Not Executed Flag 

Network Status Flag 

VO User Interface Functional Requirements , Section 2.1.2 

VO User Interface Software Specifications, Section 2.2.2.4 

None 

The UO Request Completion function performs chain and transaction error processing. If 

an error(s) occur in the execution of the VO request or a transaction(s) has not been 

executed because it has been deselected or bypassed, then the VO Request Completion 

function sets flags in shared memory to notify the YO System Services on the CP. The 

Chain Error procedure checks for the occurrence of errors and deselectedhypassed 

transactions in a chain by reading the associated status flags. 

The VO Request Completion function records the status of the VO networks on which an 

VO request is executed (recorded when the VO request is processed). The Chain Error 

procedure returns a field to the user giving the status of the associated VO network at the 

time the chain was executed. 

The status information returned by the Chain Error procedure is only valid after the Read 

VO Request procedure has been called due to the "Double Buffering" scheme. Since two 

sets of I/O buffers are used for interprocessor data communication, two sets of status 

buffers are required to maintain consistent dadstatus information (each data buffer must its 

own status buffer). When the Read VO Request procedure is called, one set of data and 

status buffers is written into the local memory on the CP from shared memory. The Chain 

Error procedure reads the status buffer in local memory when returning status information 

to the application. As a result, the Read VO Request procedure must be called prior to 

invoking the Chain Error procedure. 

52 
23.1.18 Process Name: VO Request Has Ovem 

VO Request Identifier - Number of Overruns t 

Requirements 

RefeIWK!t?: VO User Interface Functional Requirements, Section 2.1.2 

VO User Interface Software Specifications, Section 2.2.2.5 

Notes: None 

If an VO request can not be executed when its scheduling requirements have been fulfilled, 

then a scheduling overrun occurs. The VO Request Has Overrun process allows the 

application to determine if an overrun has occurred. 

The occurrence of an overrun is detected by the Posting task (discussed in Section 3.2.1.1) 

associated with the VO request. A parameter (integer number) in shared memory is updated 

to reflect the occurrence (or frequency of occurrences) of an overrun. This parameter is 

read from shared memory and returned to the application by the VO Request Has Overrun 

process. 

2.3.1.19 Process Name: Write Initial VO Request Data 

Inputs: YO Request Identifier 

Note: 

State of the Locking Semaphore 

Static and Dynamic Output Data 

VO User Interface Functional Requirements, Section 2.1.2 

VO User Interface Software Specifications, Section 2.2.2.1 

None 

The Write Initial VO Request Data procedure performs a test and set operation on the 

semaphore that guards the output data buffer select variable for the VO request. If the select 

region is unlocked, it selects an available buffer, unlocks the select region, and writes the 

static and dynamic output data for the entire VO request into shared memory. If the buffer 

53 
select region is locked, the procedure continues to perform the test and set operation until 

the region becomes unlocked or 100 test and set iterations pass. If 100 iterations pass and 

the select region is still locked, it is assumed that a fault has caused a deadlock situation 

(select region is locked but neither processor has control of it). If such a deadlock situation 

occurs, the procedure disregards the semaphore, determines the available buffer, resets the 

semaphore, sets the LOCKED parameter, and writes the output data. 

After the output data has been written into shared memory, the output data buffer select 

variable must be updated to specify the available buffer with the most current data. The 

Write Initial UO Request Data procedure performs the test and set process as previously 

described, and when the select region is unlocked, the buffer select variable (in shared 

memory) is set equal to the buffer into which the output data was written. 

2.3.1.20 Process Name: Wait Until IOP Completed 

Inputs: IOP Completed Flag 

YO User Interface Functional Requirements, Section 2.1.3 

UO User Interface Software Specifications, Section 2.2.3.1 

Notes: None 

Flags are used to synchronize the UO System Services on the CP and the IOP. The IOP 

must wait for the CP to create and communicate the I/O request Specifications. 

Alternatively, the CP must wait for the IOP to initialize the UO Services. 

The Wait Until IOP Completed process allows the CP to wait until the IOP initializes the 

I/O Services. 

54 
23.1.21 Process Name: CP Completed 

hpuk None 

outplts: CP Completed Flag 

VO User Interface Functional Requirements, Section 2.1.3 

VO User Interface Software Specifications, Section 2.2.3.1 

Note: None 

Flags are used to synchronize the VO System Services on the CP and the IOP. The IOP 

must wait for the CP to create and communicate the I/O request specifications. 

Alternatively, the CP must wait for the IOP to initialize the I/O Services. 

The CP Completed process sets a flag in shared memory to acknowledge the completion of 

VO request creation process. 

2.3.1.22 Process Name: Wait for Specification Received 

Ready for New Specification Flag 

Requirements 

Reference: None 

Note: None 

Desaiptim: 

The Wait for Specification Received process polls the Ready for New Specification flag 

until it is set (true). The process is used to synchronize the VO System Services on the CP 

and IOP during the interprocessor communication of the VO request specifications. 

55 
23.2 VO System Services Application Log 

IOSS - APPLICATION-LOG 

r 

x DISPLAY-ERROR-LOG 

2.3.2.1 Process Name: Log Error 

Inputs: Application Log Identifier 

Node Identifier 

Error Test Smng 

Error Description String 

outpdr: Entry in Application Log 

Requirements 

Reference: None 

Notes: None 

The Log Error process logs the Application Log Identifier, Node Identifier, Error Test 

string, and Error Description string in an Application Log (identified by the Log ID). An 

Application Log is a 15 line cyclic log which is used to record information associated with 

the application processes, VO request processing, and interprocessor communication. 

56 
2.3.2.2 Process Name: Display Error Log 

Inpuls: Application Log Identifier - None t 

Require-6 

Reference: None 

Note: None 

The Display Error Log process displays the contents of the Application Log which is 

identified by the Application Log identifier. 

57 
2.4 VO User Interface Data Dictionary 

Chain ID Type: The range of possible values for a chain ID (0 - Maximum Chain ID). 

ID Array : A variant record type available to the applications user for the creation of arrays 

of transactions or chains. The applications programmer must use this record to group 

transactions into a chain and chains into an VO request. 

VO Request ID Type: The range of possible values for an VO request ID (0 - Maximum 

IOR ID). 

YO Request Scheduling Record : A discriminate record available to the applications user 

for specifying scheduling parameters for an VO request. The record always has fields 

indicating the completion event, I/O request time out, and priority of the 1/0 request. The 

record is discriminated on a two state variable indicating the type of VO request (on demand 

or periodic). If the 1/0 request is periodic, then fields indicating its period, how it will be 

started, and how it will be stopped must also be provided. 

Maximum Chain ID : An integer constant which specifies the maximum number of chains. 

Maximum IOR ID : An integer constant which specifies the maximum number of I/O 

requests. 

Maximum Transaction ID : An integer constant which specifies the maximum number of 

transactions . 

Periodic Scheduling Record : A discriminate record available to the applications user for 

specifying start parameters for a periodic VO request. The record is discriminated on a 

three state variable indicating how the periodic I/O request should be started 

(Start-On-Demand, Start-After-Delay, or Start-At-Absolute-Time). If the discriminate is 

S tart-After-Delay or S tart-At-Absoluteime, then information concerning the delay or 

specific start time, respectively, must also be provided. 

Transaction ID Type: The range of possible values for a transaction ID (0 - Maximum 

Transaction ID). 

Transaction Information Record : A discriminate record available to the applications user 

for specifying VO parameters for a transaction. The record always has fields indicating the 

destination DIU, number of output data bytes, type of output data (dynamic or static), and 

local CP address of the application output data buffer. The record is discriminated on a two 

state field indicating the type of transaction (input or output). If the transaction is an input 

transaction, then fields indicating the number of input data bytes, maximum number of 

58 
errors before bypass, time out, and local CP address of the application input data buffer 

must also be provided. 

59 
3.0 VO COMMUNICATIONS MANAGEMENT 

The description of the VO Communications Management is divided into three sections: 

Functional Description, Software Specifications, and Software Process Descriptions. 

3.1 VO Communications Management Functional Desaiption 

UO Communications Management provides the processes necessary to control the flow of 

data between the GPC and the various VO networks used by the GPC. This work is 

divided between two functions, VO Traffic Control and VO Low Level Utilities. 

I/O TRAFFIC 

CONTROL 

c 

The function of the VO Traffic Control includes the processing that must'be done to place 

an VO request in its proper place in the priority queue of a given network and to transfer 

data between shared memory and its correct location in the dual ported memory of the 10s. 

In addition, the VO Traffic Control function coordinates the simultaneous execution of 

chains on an VO service which has redundant networks and processes any errors detected 

during the execution of the VO request. 

The Low Level Utilities are responsible for congruently distributing inputs to the redundant 

channels of the GPC, voting output data, and screening input data for errors. This error 

processing involves error detection (including chain time out and byte count errors) and 

error logging. The Low Level Utilities function is also responsible for performing the 

correct physical to logical mapping'for each network on the GPC. 

3.1.1 VO Traffic Control 

The main responsibilities of the VO Traffic Control process are to manage the VO request 

queues associated with each VO service accessible by the GPC, to cause chains in an VO 

request to be executed, and to process any errors which occurred during chain execution. 

Accordingly, the VO Traffic Control process is divided into three functions: Queue 

Management, VO Request Execution, and VO Request Completion. 

PRECEDING RAGE BLAW NOT FlEMED 61 
I I/O TRAFFIC 

CONTROL 

I 

I I I 

QUEUE I/O REQUEST I/O REQUEST 

MANAGEMENT EXECUTION COMPLETION 

3.1.1.1 Queue Management 

VO requests are conducted on an VO service. These VO services may be regional or local, 

and if they are local, they may involve a set of redundant networks. A GPC can only post 

VO requests to VO services to which it is connected. A list of all the VO services accessible 

by a GPC is available in its local I10 database. 

The Queue Management function initializes each UO service that is connected to the GPC. 

The initialization of an VO service means that the network and data structures associated 

with the service are initialized, the service is grown, and the tasks required by the service 

are activated. Accordingly, the Queue Management process activates a Queue Manager task 

for each VO service, schedules a Posting task for each VO request, and constructs a set of 

priority queues for each Queue Manager task. 

The primary role of the Queue Management process is to mate and manage a set of priority 

queues for each VO service in the local database. Each priority queue holds a prioritized list 

of service requests (e.g. a network restoration request, spare element cycling request, or 

VO request) for that VO service. The Queue Management process must provide a way to 

post a service request to an VO service, to supply the next service request which should 

execute on that service, and to indicate that no requests are pending. 

The Queue Management process activates an VO Posting task for each VO request created 

by the application. A Posting task is a task that is scheduled on the IOP based on the 

scheduling requirements of the VO request. When the scheduling requirements of the VO 

request are met, the Posting task posts a service request to the correct priority queue of the 

appropriate VO service. 

A Queue Manager task is activated for each VO service. This task controls all access to the 

VO service. If I/O requests are pending, the Queue Manager task accepts the VO request 

with the highest priority, invokes the VO Request Execution function, and calls the VO 

Request Completion process. If a fault in an VO network causes errors to occur in the VO 

request, then the Queue Manager task takes the appropriate network out of service and calls 

62 
the network manager FDIR. If no 40 requests are pending, then the Queue Manager can 

accept service requests to cycle the spare components of the VO service. In addition, the 

Queue Manager task controls the modification of the IlO chains (transaction 

selection/deselection) and the restoration of failed network elements. 

3.1.1.2 YO Request Execution 

Each I/O service requires a Queue Manager task to control the execution of VO requests on 

that service. Whenever an VO service is "ready" or "idle" and any VO requests have been 

posted to that service, the Queue Manager task will begin to process the pending VO 

request which has the highest priority. 

When an I/O request has just completed on a service, that service is designated as "ready"; 

that is, ready to begin another VO request. If one or more VO requests are pending at that 

service, the request with the highest priority will be started as soon as the service becomes 

ready. However, if no request is pending at a service when it becomes ready, the 1/0 

service is considered "idle". An I/O request which is posted to an idle VO service will be 

started immediately. This scheme is intended to achieve a high degree of YO service 

utilization by eliminating unnecessary delays in starting I/O request execution. 

A 

An VO service may utilize only one network or it may require a set of parallel redundant 

networks. Within each service, a given network may be in or out of service. Typically, a 

network will be out of service for one of two reasons: it has not yet been grown by its 

network manager or a fault(s) exists in the network causing it to be pulled out of service to 

allow FDIR activity to proceed. While a network is out of service, user chains will not be 

executed on the network but manager chains, of course, will be allowed. If the service is 

not redundant, user chains will not be executed until the network is back in service. 

However, if the service is redundant, the unfailed networks will remain in service while 

FDIR is conducted on the network which experienced errors. Thus, user chains in the 

unfailed networks will continue to execute at their normal rate, unimpeded by the repair 

activity of the FDIR processes. This scheme is intended to provide an application with an 

uninterrupted flow of VO data even in the presence of hardware faults (when a redundant 

VO service is part of the system). 

Another aspect of VO Request Execution is updating, whenever necessary, the chain 

program or set of redundant chain programs in dual ported memory. This is necessary to 

support the transaction selection/deselection option open to a user and the transaction 

bypassing feature available to the VO System Services. The VO System Services may 

bypass a particular transaction if it is repeatedly the source of errors and the application 

allows that transaction to be bypassed. 

To bypass or deselect a transaction, the chain program is modified so that the 10s will skip 

over the set of instructions used to execute the deselected transaction. To select a 

63 
transaction, the chain program is modified so that the 10s will not skip the relevant set of 

instructions. A chain program consists of a header and a linked list of transactions. The 

header contains instructions that affect the entire chain such as the polling priority and 

number of residual bits, and it ends with a branch instruction to the first transaction of the 

chain. Each transaction in the linked list is a sequence of 10s instructions which ends with 

a branch instruction to the first instruction of the next transaction or to an end of chain 

program (which causes the 10s to get ready for another command from the interface 

command register). To deselect a specific transaction N, the operand of the branch 

instruction of the transaction that precedes transaction N is modified to point to the 

transaction that succeeds transaction N. To select a specific transaction N, the operand of 

the branch instruction of the transaction that precedes transaction N is modified to point to 

transaction N, and the operand of transaction N's branch instruction is set equal to its 

preceding transaction's branch operand. 

Another function of VO Request Execution process is the transfer of output data from 

shared memory to dual ported memory (DPM) of the 10s. The output data for a 

transaction must be written to the DPM of the 10s prior to the execution of the command 

frame of the transaction, that part of a transaction which carries data from the GPC to the 

DIU. Command frames may be static or dynamic. Data for static command frames are 

updated only once, whereas data for dynamic command frames are updated each time the 

chain executes. When a chain contains only static command frames, the entire chain is 

designated as having static output. This designation saves processing time since each 

transaction does not need to be tested to determine whether or not it contains a dynamic 

command frame. Similarly, when a chain contains only dynamic command frames, the 

entire chain is designated as having dynamic output. Again, processing time is saved, 

since the data transfer can take place without a test of whether or not a transfer is necessary. 

Chains with both dynamic and static command frames are designated as mixed. This type 

of chain requires additional processing time and, where performance is a factor, should be 

avoided. 

Once the output data and chain program for all the chains in the VO request have been 

updated, the 10s is commanded to start the chains by means of a word written to the 

interface command register (ICR) of the 10s. In the case of redundant chains, this 

command must be written to more than one ICR and should be performed with the shortest 

possible delay between writes. If possible, the commands should be written 

simultaneously. If not, they should be written with consecutive machine instructions from 

the GPC. After starting the chains in the VO request, the VO Request Execution process is 

complete. 

64 
3.1.13 YO Request Completion 

I 

INPUT SOURCE 

CONGRUENCY 

The VO Request Completion function is triggered after the VO request time out (the length 

of time that the I/O request actively possesses an VO network or networks during its 

execution) has expired. This processing involves chain completion processing for each 

chain of the VO request. Chain completion processing entails chain error processing, chain 

error logging, transaction error processing, transaction error logging, and the transfer of 

transaction input data from DPM to shared memory. After the completion processing for 

the VO request is finished, the application is signalled that the VO request has completed 

and the data in shared memory is readable. 

I 

ERROR 

PROCESSING 

3.1.2 VO Low Level Utilities 

The UO Low Level Utilities perform source congruency and error detection on inputs from 

external devices and consistent error free outputs to external devices. They are also 

responsible for the mapping of physical to logical devices (nodes, links, DIUS) and the 

assurance that a consistent network database exists for each VO network attached to the 

GPC. The VO Low Level Utilities are made up of four functional modules: Input Source 

Congruency, Output Voting, Error Processing, and Database Operations. 

( I/O LOW LEVEL 1 

\ UTILITIES 

DATA BASE 

OPERATIONS 

The VO Low Level Utilities are used by both the VO Redundancy Management and VO 

Communications Management. They record and report communication errors to both 

functions. 

65 
3.2 The YO Communications Management Software Specifications 

As specified in Section 3.1, the VO Communications Management is divided between two 

functions: VO Traffic Control and VO Low Level Utilities. 

The VO Traffic Control process is responsible for allocating and initializing the tasks that 

control the processing of the VO requests. These tasks include the Posting tasks, priority 

queue processes, and Queue Manager tasks. The VO Traffic Control function is also 

responsible for initializing the VO services, executing the VO requests, and VO Request 

error processing. 

The I/O Low Level Utilities are responsible for supporting source congruency on the 

inputs, voting on the outputs, and fault masking. 

3.2.1 YO Traffic Manager 

As previously discussed in the I/O Communications Management Functional 

Requirements, the VO Traffic Manager is divided into three sections: Queue Management, 

VO Request Execution, and I/O Request Completion. The VO Queue Management process 

is responsible for initializing the VO services, activating the Posting tasks, and managing 

the priority queues. The VO Request Execution function is responsible for execution of the 

chains of the VO requests, while the VO Request Completion function is responsible for the 

error piocessing and logging required by the VO requests. 

3.2.1.1 Queue Management 

The Queue Management process accesses the local VO database to determine the VO 

services to which the GPC is connected. A Queue Manager task is allocated for each VO 

service, and each task initializes its corresponding VO service. The initialization of an VO 

service involves the initialization of the IOSes, VO networks, and priority queues of the 

service. The Queue Manager task loads the dual ported memory of the IOSes with the VO 

chains and output data specified by the application. The task then waits for the associated 

VO network Managers to grow the VO networks of the service. After the networks are 

active (the state of each network is "in-service") and all of the 40 request specifications 

have been communicated to the IOP, the Queue Manager constructs and initializes the 

priority queues. In addition, it schedules the Spare Link Cycling task (if enabled by the 

application) and activates the Posting tasks. When the VO service has been initialized, the 

Queue Manager sets a flag in shared memory to notify the VO System Services on the CP. 

The initialization of an 10s involves partitioning the program region of the 10s into a 

header section and a linked list of transaction modules. Each transaction section of the 10s 

is used by only one chain, whereas the header section is used by all chains. The 

initialization of the 10s program region entails the linking of the transaction sections to 

66 
make the chains. The linking of the transactions is accomplished by modifying each 

transaction's branch instruction to point to the next transaction in the chain or to the end of 

the chain program. 

The VO requests are assigned a priority of 0 through 7 (where priority 0 is the lowest and 

priority 7 preempts priorities 0 through 6). An VO request priority queue is constructed to 

control the processing of the VO requests. The number of records in the queue is equal to 

the number of VO requests that are created by the application for the VO service. Each 

record has three fields: the VO request ID, a boolean flag which indicates whether or not the 

scheduling requirements for the request have been met, and a pointer to the next record in 

the queue. The VO request priority queue is a linked list of VO request records and its 

ordering is based on the priorities of the VO requests (the highest priority request is first, 

the lowest last, etc.). 

The Queue Manager task must manage three queues of service requests for the VO service. 

These queues are the VO request priority queue (previously described), spare component 

cycling queue, and restoration queue. The Queue Manager task accepts service requests 

posted to each queue, removes service requests for processing, and indicates when a 

priority queue is empty. In addition, the task determines the next service request to be 

The Queue Manager determines the request to be serviced in the following 

Process any preempted VO requests. 

Process the highest VO request pending. 

If an VO request with a priority of 0 - 6 is being processed and an VO request 

with a priority of 7 is posted, preempt the request being executed and process 

the priority 7 request. 

If no VO requests are pending and a cycle spare link command is posted, cycle 

the spire link. 

If a spare link is being cycled and an VO request is posted, preempt the cycling 

request and process the 40 request. 

If no 40 requests are pending and a restore element command is posted, 

restore the network element. 

Each VO request that is created by the application has a corresponding Posting task that 

executes on the IOP. A Posting task is a task that is scheduled through the GPC Real Time 

Operating System based on the scheduling requirements of the VO request. The Posting 

task is activated by the Queue Manager task during initialization and is blocked until its 

scheduling requirements of the VO request are met. When scheduling requirements have 

been fulfilled, the Posting task sets an execution flag in the VO request priority queue and 

calls the Queue Manager task (posts a service request). The task is then blocked until the 

Queue Manager task accepts the service call. After the VO request has been accepted, the 

Posting task checks to see if an overrun has occurred, updates the overrun parameter in 

67 
shared memory to reflect the number of overruns that have occurred, and loops back to 

again wait for scheduling requirements of the VO request to be met. 

After the priority queue process and posting tasks have been initialized, the Queue Manager 

task waits until a service request is posted. When more than one service request is 

pending, the task determines the next service request to be processed. If the service request 

accepted is an VO request, the Queue Manager task invokes the VO Request Execution 

function to execute the request and the VO Request Completion function to process the 

corresponding input response (if necessary). Alternatively, if the service request accepted 

is a spare component cycling or restore command, the associated I/O network (or 

networks) is taken out of service and the corresponding network manager(s) is called to 

execute the request. 

- 

33.13 VO Request Execution 

The VO Request Execution function is invoked by the Queue Manager task after an VO 

request sent to the VO service has been accepted. An VO service may utilize one network 

or a set of parallel redundant networks. Each network is either in-service, 

temporarily-out-of-service, repaired, or permanently-out-of-service. The network is 

in-service during no fault operation. The network is temporarily-out-of-service when the 

network FDIR is invoked, while network components are restored, or during spare 

component cycling. The network is repaired after the network FDIR has completed, a 

network element has been restored, or a spare component has been cycled. The network is 

permanently-out-of-service when it is unreachable from the GPC. The network is set to 

in-service from repaired and to temporarily-out-of-service from in-service by the Queue 

Manager task. The network is set to repaired (or permanently-out-of-service) from 

temporarily-out-of-service by the network manager tasks. If the network is in-service or 

repaired, the chains can be executed on the network whereas, if the network is 

out-of-service (either temporarily or permanently), they can not be executed on the 

network. 

The control flow of the VO Request Execution function (along with the VO Request 

Completion function) is illustrated in the Figure 11. The bold path depicts the no fault 

control path. 

The VO Request Execution function initially checks the transaction selectionldeselection 

shared memory flags to determine if there are any transactions to be selected or deselected. 

If either of the flags is set, the Request Execution function follows the selectionldeselection 

procedure outlined in Section 2.2.2.3. If the flag is not set, then the function begins 

processing the VO request. 

68 
CHECKFOR TRANSACTION SELECTIO~JILECTION 

WRITE OUTPUT DATA To ALL CHANNELS 

c 

CHECK CHANNEL CONFIGURATION 

%\FAJzm SWITCHROOTLINK &w"."+"--%, >\, ',

1 

!RARTI/O REQUEST 

CHECK CHANNEL CONFIGURATION ' 

'> FAILED 9 

...*J ..\ ..* ..-. ...*.' "., 

(VO REQUEST EXECUTION) 

2% (VO REQUEST COMPLETION) 

WAITUNTILVOREQUEST HAS COMPLETED EXECUTION 

............... ......~%~~...........................

".,, 

..--\ CHAIN 

COMPLETELI ',& CHAIN CHECK CHANNEL CONFIGURATION '&.. ,I DID NOTCOMPLETE 

".. .Y. *,. FAILED '% 

a "k 'a 

SWlTCH ROOT LINK CHECK CHANNEL CONFIGURATION t %, \, 

".,<,\ FAILED 

WRlTE DATA TO 

SHARED MEMORY 

FROM 10s 

., "..*. 

SWITCH~~OOTLINK \ CHECK CHANNEL CONFIGURATION 

PROCESS DATA ROOTLINKSWlTCH 

Figure 11. Control Flow for UO Request Execution and Completion 

69 
The processing of the VO request begins with the loading of the IOSes of the VO service 

with the dynamic output data (both the static and dynamic data must be written if the VO 

request is being executed for the first time). To write the output data to the DPM of the 10s 

from shared memory, the VO Request Execution process performs a test and set operation 

on the semaphore that guards the output data buffer select variable for the VO request. If 

select region is unlocked, the procedure selectsbocks the available buffer, unlocks the select 

region, calculates a sumcheck over the data, and writes the output data and sumcheck to the 

10s. If the buffer select region is locked, the procedure continues to perform the test and 

set operation until the region becomes unlocked or 100 test and set iterations pass. If 100 

iterations pass and the select region is still locked, it is assumed that a fault has caused a 

deadlock situation (region is locked but neither processor has control of it). If such a 

deadlock situation occurs, the procedure disregards the semaphore, determines the available 

buffer, resets the semaphore, calculates the sumcheck, and writes the output data and 

sumcheck to the 10s. 

After the output data has been written from shared memory to IOS, the output data buffer 

select variable must be updated to unlock the output data buffer. The I/O Request 

Execution process performs the test and set process as previously described, and when the 

select region is unlocked, the buffer is unlocked by modifying the select variable in shared 

memory. 

After the output data buffer is unlocked, the channel configuration is checked to see if the 

channel(s) executing the VO request is on-line. If the channel is not on-line, the root link is 

switched until either an active root link is found or the corresponding network(s) is 

determined to be unreachable. If the channel is on-line, the VO request is prepared for 

execution by setting up each chain of the VO request. The set up procedure involves 

several steps: 

a) The modification of the branch instruction of the header to point to the first 

transaction of the chain. 

b) The modification of the poll instruction in the header of the chain to start 

immediately if the associated network is local or start with a poll otherwise. 

c) Clear the Chain Status Register. 

d) Set the Solicited Chain Pointer of the 10s to point to the header of the chain. 

After the completion of the chain setup procedure, the chains of the 40 request can be 

executed. To execute a chain, an execute command is written to the Interface Command 

Register (ICR). In the case of two redundant chains, the execution commands are written 

in consecutive machine instructions. In the case of three or more redundant chains, the 

commands are written in a "tight" machine instruction loop. 

As previously discussed in Section 3.2.1.1, VO requests with a priority of 7 preempt lower 

priority VO requests. A check for pending priority 7 requests is made before the output 

data for an VO request is written to the 10s. In addition, a similar check is performed 

70 
prior to the VO request being executed. If a priority 7 VO request is pending and a lower 

priority request is being processed, the state of the lower priority request is saved, the 

request is suspended, and the pending request is processed. When the processing of the 

priority 7 VO request has completed, the state of the preempted request is restored and 

processing of the request is continued. 

. During the execution of an VO request, the VO request must actively possess the network 

for a specific amount of time; that is, the VO request time out. Accordingly, the Queue 

Manager must wait for the VO request time out to expire before it can invoke the I/O 

Request Completion function. 

3.2.13 YO Request Completion 

The control flow for the VO Request Completion function is illustrated in Figure 11. 

Initially, the VO Request Completion function checks the channel configuration and the 

chain complete bit of the Chain Status Register. If the configuration check detects that the 

channel has failed, then the root link is switched. If the channel is on-line and the chain did 

complete, then the input data returned by the UO request is written into shared memory 

from the DPM of the 10s (using a process similar to the Write UO Request procedure - 

Section 2.3.1.6). 

After the input data has been written to shared memory, the channel configuration is again 

checked. If the configuration check detects that the channel is down, then the active root 

link is switched. If the channel is on-line, then the data is processed for errors. The error 

detection process (I/O Low Level Utilities) checks for transmission, byte count, and 

sumcheck errors. The error logging process sets shared memory flags to notify the 

application of any chain and/or transaction errors that result. If any errors are detected, the 

channel configuration is checked and the data exchange tests are performed. 

To support the VO request preemption capability, a check for priority 7 requests is made 

before the input data is written to shared memory. If a priority 7 VO request is pending and 

a lower priority request is being processed, the state of the lower priority request is saved, 

the request is suspended, and the pending request is processed. When the processing of 

the priority 7 I/O request has completed, the state of the preempted request is restored and 

processing of the request is continued. 

After the error processing has been completed, the VO completion flag for the VO request is 

set. In addition, if the application selects the completion event option during the creation of 

the VO request, the VO completion event is signalled. 

71 
3.22 I/O Low Level Utilities 

As discussed in Section 3.1.2, the VO Low Level Utilities is made up of four functional 

modules: Input Source Congruency, Output Voting, Error Processing, and Database 

Operations. 

The Input Source Congruency function is implicitly preformed by the shared data exchange 

hardware. 

The Output Voting is performed by writing data (bytes or words) into a data exchange 

transmit register (see [l] for a detailed description). The VO Communications Management 

and Redundancy Management processes use this register to vote all output data written to 

the IOSes. 

The Error Processing capabilities of the GPC are used to determine VO network errors. I/O 

network errors are determined by analyzing status information returned by the network 

nodes. This error information is used by the I10 Communications Management and 

Redundancy Management functions. 

The Database Operation function is used by the VO Communications Management and I/O 

Redundancy Management function to access information in the VO database concerning the 

VO services supported by the GPC site. It is responsible for the mapping of physical to 

logical devices (nodes, links, DIUS) and the assurance that a consistent network database 

exists for each VO network attached to the GPC. 

72 
33 YO Communications Management Software Process Descriptions 

The 1/0 Communications Management Software Process Descriptions divide the 

description of the VO Communications Management into functional packages. This section 

uses Booch diagrams and process descriptions to present the Software Specifications in 

more detail. The Booch diagrams are used to map the UO Communications Management 

Software Specifications into functional packages, tasks, and subprograms. The process 

descriptions are used to describe these functional groups in detail. 

The VO Communications Management is divided into ten functional packages: 

1) UO System Services Queue Manager 

2) VO System Services IOP Construct UO Requests 

3) VO System Services IOP Main Initialization 

4) VO System Services Communication of Specifications Task 

5) VO System Services Posting Tasks 

6) UO System Services IOP Powerup 

7) VO System Services Global Memory Utilities 

8) VO System Services Shared Memory Allocation 

9) VO System Services Dual Ported Memory Map 

10) VO System Services Private ID Types 

73 
33.1 YO System Services Queue Manager 

IOSS_QUEUE_MGR 

7 

RESTORE-NODE-OR-LINK 

QUEUE-MGR-TASK 

UPD ATE-10s-AFX'ER-RERE 

I 

I ~ 

1 DPM-TO-SM-XHK I 

=CHECK-FOR-COMM-ERRORS I 

I PROCESS-IOR-CALL I 

I 

I EXEC-IOR-CALL 1 

I UPLO AD-IOR-C ALL I 

I 

I ADD-TO-LIST 1 I 

2 INITIALIZE-IOR-QUEUE I DETERMINE-NEm-IOR 

74 
3.3.1.1 Process Name: Restore Node or Link 

Inputs: 

Note: 

VO Network Identifier 

Node Identifier 

Port Identifier 

Type of Restoration 

Confurnation that Restoration was Accepted 

Restoration Service Request 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

The Restore Node or Link process posts a restoration service request to the Queue Manager 

task. Initially, the process determines if the request is to restore a node or link. Next, the 

service request is posted to the restoration priority queue. If the Queue Manager is not 

processing a different service request, the restoration request is accepted and processed. If 

the Queue Manager is processing a different service request, the restoration request is 

retracted. The service request is retracted to avoid the possibility of the Restore Node or 

Link process being endlessly blocked if the Queue Manager is busy processing other jobs 

(restoration is a low priority job). If the service request is retracted, the process delays for 

one second and resubmits the request. If the Queue Manager can not accept the second 

request, the process delays again for a second time and then resubmits the request a third 

time. If the third request is not successful, then the Restore Node or link process notifies 

the calling process that the restoration was not accepted. If the restoration request was 

accepted in one of the three tries, then the process notifies the calling process that the Queue 

Manager accepted the request. 

75 
33.1.2 Process Name: Queue Manager 

In- 

&- 

ReqUh?XIlentS 

Reference: 

Nota: 

r/o Request Hierarchical Database 

VO Network Identifier 

VO Transaction Identifier 

I/O Request Output Data 

UO Transaction Selection 01: Deselection Record 

VO Network Restoration Record 

Cmnt Channel 

Network State 

Channel Configuration 

YO Service Configuration 

VO Network Identifier 

Network State 

I/O Request Errors 

VO Request Input Data 

Current Channel 

Connected Networks 

VO Network Restoration Record 

10s DPM Address Pointer 

VO Transaction Identifier 

VO Communications Management Functional Requirements, 

Section 3.1.1 

VO Communications Management Software Specification, 

Section 3.2.1.1 

None 

The Queue Manager task is a process that controls the Queue Management, VO Request 

Execution, and 40 Request Completion functions associated with a particular VO service. 

The Queue Management function constructs and manages a set of priority queues and 

initializes the I/O service. The I/O Request Execution function writes the dynamic output 

data from shared memory to the appropriate IOSes, updates the chain headers, and executes 

the VO request. The VO Request Completion function checks for the occurrence of errors 

and writes the input data from the DPM of the 10s to shared memory. 

76 
. 

. 

The Queue Manager task is blocked until the I/O System Services on the CP has 

communicated all of the I/O request specifications to the IOP and the companion VO request 

records have been constructed. The task then constructs an VO request priority queue 

using the priorities assigned to the requests. The VO requests with the higher priorities are 

placed closer to the front of the queue whereas those with the lower priorities are placed 

nearer to the bottom. 

After the VO request priority queue is created, the Queue Manager task creates the priority 

queues (FIFO) for the spare link cycling and restoration processes. In addition, the VO 

chains are constructed, and the spare link cycling task is scheduled. The construction of 

the VO chains involves the modification of branch instructions to link the transaction 

program modules into a chain module. This procedure also initializes the VO data pointers 

and output data buffers. The spare link cycling task is scheduled as a background task, and 

it periodically posts a reconfiguration service request to the VO service. 

The VO requests can not be scheduled until the VO networks associated with the I/O service 

are grown. The growth of the VO networks is performed by the 110 Network Managers, 

and the Queue Manager waits until these I/O networks are in-service. After the growth of 

the networks is complete, the Queue Manager task schedules an VO Posting task for each 

VO request created by the application. The Posting task is scheduled on the IOP in the 

manner specified by its corresponding VO request. When the scheduling requirements of 

an VO request have been met, the associated VO Posting task sets an execution flag in the 

VO request priority queue and calls the Queue Manager task (posts a Service request). 

After the VO Posting tasks have been scheduled, the Queue Manager task sets a flag to 

notify the CP application tasks that the initialization of the I/O service has completed. At 

this time, the application tasks can start any on demand VO requests. 

The Queue Manager task controls access to the VO service. Several processes contend for 

the service. These processes are: 

1) The execution of an VO request. 

2) The cycling of a spare link. 

3) The restoration of a node or link. 

Each of the contending processes posts a service request to its associated queue when its 

scheduling requirements have been fulfilled. The service request to be next processed by 

the Queue Manager task is selected based on priority scheme described in Section 3.2.1.1. 

If an VO request is accepted by the Queue Manager task, then the VO Request Execution 

function is called to process the request. The processing of an VO request involves several 

steps. Initially, a check is made to determine if there are any transactions to be selected or 

deselected. Secondly, the dynamic output data is written from shared memory to the DPM 

of the IOSes (the static output data is also written if the VO request has not been previously 

executed) and the chain headers are initialized to point to the first transaction of the 40 

77 
chains. After the headers have been updated, the VO request is executed. The VO request 

is started by writing a command to the Interface Command Register (ICR) of an 10s. In 

the case of two redundant chains, the execution instructions are written in consecutive 

machine instructions to two IOSes. In the case of three or more simultaneous chains, the 

commands axe written in a tight machine instruction loop (to multiple IOSes) to minimize 

the delay between the writes while allowing the flexibility of variable size VO requests. 

After the 40 request execution has started, the Queue Manager task waits until the VO 

request time out has expired. At this time, the Queue Manager task invokes the VO Request 

Completion process to perform error checking (byte count, transmission, and sumcheck), 

notify the application of the occurrence of errors, bypass the transactions which have 

exceeded their maximum error limitations, invoke the network FDIR (if necessary) and - 

write the input data from the DPM of the IOSes to shared memory. After the input data has 

been written, the processing of the VO request is finished, and the Queue Manager task 

notifies the associated CP application of the completion of the VO request using a 

completion event and/or flag. 

The processing of a spare link cycling service request involves two steps: the collection of 

node status from the VO networks of the VO service and the reconfiguration of the virtual 

circuit path if there are not any errors in the networks. The collection of node status 

information is required to determine if all of the expected network nodes are reachable prior 

to reconfiguration. If one or more of the nodes does not send its status or sends 

inconsistent status (inconsistent with the VO network topology database), then a network 

fault is assumed to exist. If a fault is present in a network, the network is taken out of 

service and a repair request is sent to the associated VO Network Manager task. In the case 

of redundant networks, this status collection is performed in near simultaneous manner 

similar to the execution of simultaneous VO chains. If there are not any errors in the VO 

service, then a spare link of each VO network is made active by reconfiguring the virtual 

path. If redundant networks are involved, the reconfiguration is performed in near 

simultaneous manner. 

The processing of a network element (link or node) restoration service request involves 

sending a restore request to the appropriate VO Network Manager task. 

The Queue Manager accepts service requests from the contending processes until it is 

descheduled. 

78 
33.1.3 Process Name: Update 10s After Channel Restoration 

u Restore 10s Data Flags 

Requimmts . 

Reference: VO Communications Management Software Specifications, 

Section 3.2.2 

Nota: None 

Description: 

The Update 10s After Channel Restoration process sets the Restore 10s Data flags to 

notify the Queue Manager that the static output data for the VO requests must be restored. 

The loss of a channel due to a fault may cause the data in the 10s to be corrupted. Since 

the static data is not updated each time an VO request is processed, the data must be updated 

when the channel is restored. 

3.3.1.4 Process Name: Shared Memory to DPM with Sumcheck 

Inputs: 

Notes: 

Desaiption: 

Chain Identifier 

User Program and Data Pointer 

Output Data 

Value of Lucking Semaphore 

Voted Output Data 

Voted Sumcheck 

Voted Number of Data Bytes 

VO Communications Management Software Specifications, 

Section 3.2.1.2 

None 

The Shared Memory to DPM process updates output buffers of the DPM of the IOSes. 

The output data has been written into shared memory by the application. The process 

updates the dynamic output data each time a chain is executed. The process updates the 

79 
static output data prior to the first execution of the chain and after a chain error has 

OCCd. 

The Shared Memory to DPM process performs a test and set operation on the semaphore 

that guards the output data buffer select variable for the VO request. If select region is 

unlocked, the procedure selects/locks the available buffer, unlocks the select region, 

calculates a sumcheck over the data, and writes/votes the output data and sumcheck to the 

10s. If the buffer select region is locked, the procedw continues to perform the test and 

set operation until the region becomes unlocked or 100 test and set iterations pass. If 100 

iterations pass and the select region is still locked, it is assumed that a fault has caused a 

deadlock situation (region is locked but neither processor has control of it). If such a 

deadlock situation occurs, the procedure disregards the semaphore, determines the available 

buffer, resets the semaphore, calculates a sumcheck over the data, and writes/votes the 

output data and sumcheck to the 10s. 

After the output data has been read from shared memory, the output data buffer select 

variable must be updated to unlock the output data buffer. The Shared Memory to DPM 

process performs the test and set procedure as previously described, and when the select 

region is unlocked, the buffer is unlocked by modifying the select variable in shared 

memory. 

3.3.15 Process Name: DPM to Shared Memory with Sumcheck 

Inputs: 

Requimmts 

Referenoe: 

Nda: 

Chain Identifier 

User Program and Data Pointer 

Input Data 

Value of Locking Semaphore 

Array of Transaction Data Sumchecks 

Input Data 

I/O Communications Management Software Specifications, 

Section 3.2.1.2 

None 

The DPM to Shared Memory process reads input data from the DPM of the IOSes and 

updates the shared memory input data buffers. The input data is the response from a DIU 

to a request given by the application. The process updates the shared memory input data 

buffers each time an input response from an I/O request is received. 
The DPM to Shared Memory process performs a test and set operation on the semaphore 

that guards the input data buffer select variable for the UO request. If the select region is 

unlocked, it selects an available buffer, unlocks the select region, calculates a sumcheck 

over the data, resets the Old Data flag (notifying the CP that the input buffers have been 

updated since the previous data read), and writes the input data for the entire UO request 

into shared memory. If the buffer select region is locked, the procedure continues to 

perform the test and set operation until the region becomes unlocked or 100 test and set 

iterations pass. If 100 iterations pass and the select region is still locked, it is assumed that 

a fault has caused a deadlock situation (select region is locked but neither processor has 

control of it). If such a deadlock situation occurs, the procedure disregards the semaphore, 

determines the available buffer, resets the semaphore, calculates a sumcheck over the data, 

resets the Old Data flag (notifying the CP that the input buffers have been updated since the 

previous data read), and writes the input data to shared memory. 

After the input data has been written into shared memory, the input data buffer select 

variable must be updated to specify the available buffer with the most current data. The 

DPM to Shared Memory process performs the test and set procedure as previously 

described, and when the select region is unlocked, the buffer select variable (in shared 

memory) is set equal to the buffer into which the input data was written. 

3.3.1.6 Process Name: Setup Chain 

Requirements 

Ref-: 

Chain Identifier 

User Program and Data Pointer 

DPM Program Pointer 

10s Solicited Chain Pointer 

Chain Header Branch Instruction 

10s Poll Instruction 

Nota: None 

VO Communications Management Software Specifications, 

Section 3.2.1.2 

The Setup Chain process sets up the chain header section of the user program region in 

preparation for the execution of the chain. The process involves several steps: 

81 
a) The modification of the branch instruction of the header to point to the first 

transaction of the chain. 

b) The modification of the poll instruction in the header of the chain to start 

immediately if the associated chain is local or start with a poll otherwise. 

c) Clear the Chain Status Register. 

d) Set the Solicited Chain Pointer of the 10s to point to the header of the chain. 

3.3.1.7 Process Name: 

Inputs: VO Request Identifier 

oum 10s Interface Command Register 

Execute VO Request 

Requi~mt?IltS 

Reference: I/O Communications Management Software Specifications, 

Note: 

Desaiptim: 

Section 3.2.1.2 

None 

The Execute VO Request process executes the VO request after tle output data buffers have 

been updated. To execute a chain, an execute command is written to the ICR of an 10s. To 

execute the simultaneous chains, execute commands are written to multiple ICRs with a 

minimal delay between the writes. 

After the execute commands are written, the process waits until the VO request time out has 

expired. 

82 
. 

33.1.8 Process Name: 

NdeS: 

Desaiption: 

Check for Communication Errors 

User Data and Program Pointer 

DPM Program Pointer 

Array of Data S umchecks 

Chain Identifier 

Active Root Link 

Error in Chain Flag 

Shared Memory Error Flags 

VO Communications Management Software Specifications, 

Section 3.2.1.2 

None 

The Check for Communication Errors process determines if an error(s) occurred during the 

execution of a chain and if so, it isolates and logs the type and location of the error(s). The 

process checks for the following types of errors: 

Channel failure during chain execution. 

Chain did not complete execution. 

1) 

2) 

3) Transmission Errors. 

4) Byte count errors. 

5) Sumcheck errors. 

The Check for Communication Errors process updates several shared memory flags to 

notify the application of the occurrence and type of errors. The process also determines if a 

transaction should be bypassed. 

If a response from a DIU has been corrupted by errors and the DIU is reachable, then the 

Check for Communication Errors process calls the associated I/O Network Manager 

process to repair the network (except for sumcheck errors). 

83 
3.3.1.9 Process Name: Process VO Request Procedure call 

Requirements 

Reference: 

YO Request Identifier 

UO Request Output Data 

10s Status Registers 

Network Status 

Completion Flag 

Completion Event 

UO Request Input Data 

I/O Communications Management Software Specifications, 

Section 3.2.1.2 

Nota: None 

The Process VO Request procedure performs the I/O Request Execution and VO Request 

Completion functions, as discussed in VO Communications Management Functional 

Requirements and Software Specifications. In short, the process performs the following: 

1) Checks for a transaction selectioddeselection request. 

2) Writes the output data from shared memory to DPM. 

3) Sets up the chain header(s) for the VO request. 

4) Executes the VO request. 

5) Writes the input data from DPM to shared memory. 

6) Checks for communication errors. 

7) Notifies the application of the completion of the VO request via event and/or 

flag. 

84 
3.3.1.10 Process Name: Execute VO Request Procedure Call 

- Requirements 

Refgence. 

Notes: 

I/O Request Identifier 

10s Status Registers 

Network Status 

Completion Flag 

Completion Event 

VO Request Input Data 

VO Communications Management Software Specifications, 

Section 3.2.1.2 

None 

During the processing of an I/O request, checks are made to determine if the VO request 

being processed should be preempted. The VO request should be preempted if its priority 

is between 0 and 6 and a priority 7 I/O request is pending. If an VO request is preempted, 

its state is recarded to avoid unnecessary reprocessing. The Execute VO Request procedure 

is invoked when an I/O request is preempted before the it is executed. In short, the process 

performs the following: 

1) Sets up the chain headexfs) for the I/O request. 

2) Executes the VO request. 

3) Writes the input data from DPM to shared memory. 

4) Checks for communication errors. 

5) Notifies the application of the completion of the VO request via event and/or 

flag. 

85 
3.3.1.11 Process Name: Upload VO Request Procedure Call 

Requirements 

R&enCe: 

Nota: 

VO Request Identifier 

10s Status Registers 

Network Status 

Completion Flag 

Completion Event 

VO Request Input Data 

VO Communications Management Software Specifications, 

Section 3.2.1.2 

None 

Description: 

During the processing of an VO request, checks are made to determine if the VO request 

being processed should be preempted. The VO request should be preempted if its priority 

is between 0 and 6 and a priority 7 VO request is pending. If an VO request is preempted, 

its state is recorded to avoid unnecessary reprocessing. The Upload 40 Request procedure 

is invoked when an VO request is preempted before the input response from the VO request 

is processed. In short, the process performs the following: 

1) Writes the input data from DPM to shared memory. 

2) Checks for communication errors. 

3) Notifies the application of the completion of the VO request via event and/or 

flag. 

86 
3.3.1.12 Process Name: Spare Link Test 

ReqlJimrne!ilts 

Ref-: 

Notes: 

Desuiption: 

Spare Link Test Count 

Channel Configuration 

VO Service Database 

Network Status 

10s Status Registers 

None 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

The Spare Link Test process controls the cycling of the spare links of the network(s) of an 

VO Service. 

The Spare Link Cycling procedure involves two steps: the collection of node status from 

the VO networks of the VO Service and the reconfiguration of the virtual circuit path if there 

are not any errors in the networks. The collection of node status information is required to 

determine if all of the expected network nodes are reachable prior to reconfiguration. If one 

or more of the nodes does not send its status or sends inconsistent status (inconsistent with 

the VO network Topology database), then a network fault is assumed to exist. If a fault is 

present in a network, the network is taken out of service and a repair request is sent to the 

associated I/O Network Manager task. In the case of redundant networks, this status 

collection is performed in near simultaneous manner similar to the execution of 

simultaneous VO chains. If there are not any errors in the VO Service, then a spare link of 

each VO network is made active by reconfiguring the virtual path. If redundant networks 

are involved, the reconfiguration is performed in near simultaneous manner. 

87 
33.1.13 Process Name: 

Inpds: 

Note: 

Desaiption: 

Initialize 'VO Service 

Connected Networks 

Network State 

None 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

The Initialize VO Service process initializes the VO Service associated the Queue Manager 

task. The process involves constructing the user chains in the IOS, scheduling the spare 

link testing task, waiting for the networks to be grown by the VO network managers, and 

scheduling the Posting tasks. 

3.3.1.14 Process Name: 

Inputs: 

ouw 

Requirrments 

Reference: 

Nota: 

Desaiption: 

Add to List 

VO Request Identifier 

VO Request Priority Queue 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

The Add to List process adds the designated VO request to the VO request priority queue. 

The position of the VO request in the queue depends on the priority assigned to it by the 

application. The I/O request priority queue is used to determine the next service request to 

be processed. 

88 
33.1.15 Process Name: Initialize VO Request Queue 

Inpix VO Request Identifiers 

* VO Request Priority Queue 

Requirements 

Refgence: 

Nota: 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

The Initialize UO Request Queue process initializes the UO request priority queue by 

ordering the VO requests and invoking the Add to List procedure for each request. The 

position of the 1/0 request in the queue depends on the priority assigned to it by the 

application. The VO request priority queue is used to determine the next service request to 

be processed. 

3.3.1.16 Process Name: Determine Next VO Request 

Inpub: VO Request Priority Queue 

Requirements 

ReFerence: 

VO Request Identifier 

Queue Empty Flag 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

Nota: None 

The Determine Next VO Request process determines which pending VO request should be 

next processed. The process parses the VO request priority queue and returns the first 

pending request to the Queue Manager for processing. Since the priority queue was 

ordered from highest to lowest priority, the first pending entry has the highest priority. 

It is possible for the VO request priority queue to be empty. Accordingly, the process 

rems a boolean flag to notify the Queue Manager that no VO requests are pending. 

89 
33.2 I/O System Services IOP Construct UO Requests 

I IOSS -- IOP CONsllR - IOR I 

CONSTRUCT-TRANS ACTION 

RESMRE-TR ANS ACTION I 

I RESTORE-CHAIN 

I -1 I 

WRITE-DIU-OVERHEAD 1 I 

ASSIGN-BR ANCH-POINTER 

I 

90 
3.3.2.1 Process Name: Construct Transaction 

Requin?ments 

Rd-: 

Nota: 

10s User Program and Data Pointer 

Transaction Pointers 

Transaction Output Data 

Transaction Branch Instruction 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

To execute the I/O requests created by the application, the IOSes have to be initialized. 

The program region of the 10s is partitioned into a header section and a linked list of 

transaction sections. Each transaction section of the 10s is used by only one chain, 

whereas the header section is used by all chains. The construction of the 10s program 

region entails the linking of the transaction sections to make the chains. The linking of the 

transactions is accomplished by modifying each transaction's branch instruction to point to 

the next transaction in the chain or to the end of chain program. 

The Construct Transaction process initializes one transaction region in the DPM of a 

specific 10s. In addition to modifying the branch instruction of the transaction module, the 

Construct Transaction process allocates the I/O data buffers necessary to satisfy the 

transaction VO requirements. The process also initializes the output data buffer and the 

input and/or output data buffer pointers. 

91 
3.3.2.2 Process Name: Construct Chain 

Requiremt!3 

Reference: 

Note: 

10s User Program and Data Pointer 

10s Network Manager Pointer 

Chain Pointer 

Chain Header Branch Instruction 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

Description: 

To execute the VO requests created by the application, the IOSes have to be initiaIized. 

The program region of the 10s is partitioned into a header section and a linked list of 

transaction sections. Each transaction section of the 10s is used by only one chain, 

whereas the header section is used by all chains. The construction of the 10s program 

region entails the linking of the transaction sections to make the chains. The linking of the 

transactions is accomplished by modifying each transaction's branch instruction to point to 

the next transaction in the chain or to the end of chain program. 

The Construct Chain process links a set of transaction regions into a chain. This procedure 

involves calling the Construct Transaction process for each transaction in the chain. 

The Construct Chain process also records the address of the first transaction of the chain 

which is necessary to execute the VO request. 

92 
33.2.3 Process Name: Construct Chain Header 

. 10s User Program and Data Pointer 

Chain Pointer 

Chain Header Branch Instruction 

Solicited Chain Pointer 

VO Communications Management Functional Requirements, 

Section 3.1.1.3 

Notes: None 

In order to execute an VO request, the Solicited Chain Pointer register of the IOSes must be 

initialized to pointer to the header of the chains. Since the header section of the 10s 

program region is used by all chains, the branch instruction of the header section must be 

modified to point to the first transaction of the chain prior to executing the I10 request. 

This procedure is completed by the Construct Chain Header process. 

3.3.2.4 Process Name: Low Level Select Transaction 

Inputx 10s User Program and Data Pointer for Writing to 10s 

10s User Program and Data Pointer for Reading from 10s 

Transaction Pointer 

Transaction Branch Instructions 

VO User Interface Software Specifications, Section 2.2.2.3 

Nota: None 

The Low Level Select Transaction process is called by the Select Transaction procedure and 

completes the low level procedures required to select a transaction. The Low Level Select 

Transaction process determines the preceding and succeeding transactions to the transaction 

to be selected. The preceding transaction's branch instruction is modified to point to the 

93 
selected transaction while the branch instruction of the selected transaction is modified to 

point to the succeeding transaction. 

If the selected transaction is the frrst transaction of the chain, then its address is recorded as 

the new chain header address (the chain header address is the address written into the 

branch instruction of the header section of the 10s program region prior to executing the 

chain). Alternatively, if the selected transaction is the last transaction in the chain, then its 

branch instruction is modified to point to the end of chain program (the end of chain 

program is a sequence of instructions which saves several registers and performs the 

transition from solicited to unsolicited mode). 

33.2.5 Process Name: Low Level Deselect Transaction 

10s User Program and Data Pointer for Writing to 10s 

10s User Program and Data Pointer for Reading from 10s 

Transaction Pointer 

outpllts: Transaction Branch Instructions 

ReqUil=l?YM!?ltS 

Reference: VO User Interface Software Specifications, Section 2.2.2.3 

Note: None 

The Low Level Deselect Transaction process is called by the Deselect Transaction 

procedure and completes the low level procedures required to deselect a transaction. 

The Low Level Deselect Transaction process determines the preceding transaction to the 

transaction to be selected and then modifies its branch instruction to point to the transaction 

that succeeds the transaction to be deselected. If the deselected transaction is the first 

transaction of the chain, then the address of its succeeding transaction is recorded as the 

new chain header address (the chain header address is the address written into the branch 

instruction of the header section of the 10s program region prior to executing the chain). 

Alternatively, if the deselected transaction is the last transaction in the chain, then the 

branch instruction of its preceding transaction is modified to point to the end of chain 

program (the end of chain program is a sequence of instructions which saves several 

registers and performs the transition from solicited to unsolicited mode). 

94 
3.3.2.6 Process Name: Restore Transaction 

Requirements 

Referenee: 

10s User Program and Data Pointer 

Transaction Pointers 

Transaction Output Data 

Transaction Branch Instruction 

None 

Nota: None 

The Restore Transaction process initializes one transaction region in the DPM of a specific 

10s. In addition to modifying the branch instruction of the transaction module, the process 

initializes the input andor output data buffer pointers. 

3.3.2.7 Process Name: Restore Chain 

10s User Program and Data Pointer 

10s Network Manager Pointer 

Chain Pointer 

Requirements 

Reference: None 

Nota: None 

Desaiption: 

When a channel is restored from a failed state, the user program region of the IOSes of that 

channel has to be restored. The Restore Chain process restores a chain in an 10s by 

linking a set of transaction regions into a chain (after the 10s is reinitialized). This 

procedure involves calling the Restore Transaction process for each transaction in the 

chain. 

c -a 

95 
3.3.2.8 Process Name: Write DIU Overhead 

10s User Program and Data Pointer 

Transaction Pointer 

DIU Address 

Encoded DIU Address 

Residual Bits 

None 

Notes: None 

Desaiption: 

The Write DIU Overhead process initializes the data region in an 10s with the DIU 

address, encoded DIU address, and residual bits for a transaction. 

. 3.3.2.9 Process Name: Assign Branch Pointer 

10s User Program and Data Pointers 

Transaction Identifiers 

htpds: Transaction Branch Instruction 

Requirements 

ReferenCe: None 

NdeS: None 

The Assign Branch Pointer process bypasses the designated transaction by modifying the 

branch instruction of the preceding transaction. 

96 
333 UO System Services Main Initialization 

10s -- IOP MAlN-m 

3.3.3.1 Process Name: Initialize IOSS 

Inputs: None 

outputs: Queue Manager Start Command 

R~Ui~~tS 

Reference: None 

Notes: None 

The Initialize IOSS process controls the initialization of the UO Services. The process calls 

the Powerup-IOP procedure to schedule an IOP task to allow the communication of the I/O 

request specifications. The process waits for the CP to complete the communication of the 

specifications and then schedules the Queue Manager task which initializes the VO Service. 

97 
33.4 YO System Services Communication of Specifications Task 

@ARE-LINK-TESTING-TASK ) 

33.(4.1 Process Name: Shared Memory Communication Task Type 

Companion Transaction Records 

Companion Chain Records 

Companion UO Request Records 

Requimmts 

Reference: VO User Interface Software Specifications, Section 2.2.1 

Note: None 

The Shared Memory Communication task reads the VO request specifications from shared 

memory and creates the IOP database of companion records. 

The task is scheduled on the IOP through the GPC Real Time Operating System as an on 

demand process. The task is synchronized with the Create-Transaction, Create-Chain, 

and Create-IOR processes which reside on the CP. The interprocessor synchronization is 

achieved using an event and a flag. The event is used to signal that a transaction, chain, or 

VO request record has been written into shared memory by the VO System Services on the 

CP and can be read by the VO System Services on the IOP. The flag notifies the CP that 

the IOP has read the record. 

After being signaled by the CP, the IOP Shared Memory Communication task accesses 

shared memory and determines the type of record (transaction, chain, VO request) being 

communicated. The task then reads the specification record, allocates memory for the 

companion record, and initializes the companion record. Finally, the task notifies the UO 

System services on the CP that the companion record is created and that another record can 

be communicated. 

98 
3.3.4.2 Process Name: Spare Link Test Task 

None - Spare Link Cycle Service Request 

I/O Communications Management Software Specifications, 

Section 3.2.1.1 

Notes: None 

Description: 

The Spare Link Test task posts Spare Link Cycling service requests to the Queue Manager. 

It is scheduled through the GPC Real Time Operating System as a periodic task by the 

Spare Link Test Scheduling procedure. 

99 
3.3.5 I/O System Services Posting Tasks 

I IOSS - POSTING-TASKS I I 

( POSTING-TASK-TYPE 3 

1 POSTING-TASK-M ANAGER 

3.3.5.1 Process Name: Posting Task Type 

Inputs VO Request Identifier 

Notes: 

Service Request for VO Request Execution 

Number of Overruns 

VO Request Preemption Flag 

Spare Link Test Preemption Flag 

VO Communications Management Functional Requirements, 

Section 3.1.1.1 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

Each VO request that is created has a corresponding Posting task on the IOP. A Posting 

task is a task that is scheduled through the GPC Real Time Operating System based on the 

scheduling requirements of the VO request. The Posting task is activated by the Queue 

Manager task during initialization'and is blocked until the scheduling requirements of the 

VO request are met. When scheduling requirements have been fulfilled, the Posting task 

sets its execution flag in the VO request priority queue and calls the Queue Manager task 

(posts a service request). The task is then blocked until the Queue Manager task accepts the 

call. After the I/O request has been accepted, the Posting task checks to see if it has 

overrun, updates the overrun parameter in shared memory to reflect the number of overruns 

that occumd, and loops back to again wait for its scheduling requirements to be met. 

100 
3.3.5.2 Process Name: Posting Task Manager 

VO Request Identifier 

NOteS: 

VO Communications Management Functional Requirements, 

Section 3.1.1.1 

UO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

The Posting Task Manager allocates a Posting task for a particular VO request and 

schedules it based on the scheduling requirements of the VO request. 

101 
33.6 YO System Services IOP Powerup 

IOSS -- IOP POWERUP 

~ 

AcrrVATE-POSTING_TASKS 

CON!TIRUCT-USER-CHAS 

RESTORE-USER-CH AINS 

I 

I 

I I I POWERUP-IOP 

I 

I IOP-COMPLETED I 

3.3.6.1 Process Name: Powerup IOP 

Inpuls: None 

Requiremts 

Reference: 

Note: 

None 

None 

The Powerup IOP process calls the Specifications Scheduler procedure to schedule the IOP 

Shared Memory Communication task that accepts the VO request specifications. 

102 
33.6.2 Process Name: IOP Completed 

None 

outplg: IOP Completed Flag 

mRdC!ItIMX: UO User Interface Functional Requirements, Section 2.1.3 

ID User Interface Software Specifications, Section 2.2.3.1 

Notes: None 

Description: 

Flags are used to synchronize the VO System Services on the CP and the IOP. The IOP 

must wait for the CP to create and communicate the I/O request specifications. 

Alternatively, the CP must wait for the IOP to initialize the I/O services. 

The IOP Completed process sets a flag in shared memory to acknowledge the completion 

of UO service initialization process. 

3.3.6.3 Process Name: Wait Until CP Completed 

Inputs: CP Completed Flag 

~menb 

Reference: I/O User Interface Functional Requirements, Section 2.1.3 

VO User Interface Software Specifications, Section 2.2.3.1 

Notes: None 

Description: 

Flags are used to synchronize the 40 System Services on the CP and the IOP. The IOP 

must wait for the CP to create and communicate the 1/0 request specifications. 

Alternatively, the CP must wait for the IOP to initialize the I/O services. 

The Wait Until CP Completed process polls the CP Completed flag in shared memory 

waiting for the VO System Services on the CP to finish communicating the VO request 

specifications. 

103 
33.6.4 Process Name: Specifications Scheduler 

Inpix None 

OuW None 

Rdgence: 

Note: None 

VO User Interface Software Specifications, Section 2.2.1.1 

Desaiptim: 

The Specifications Scheduler process uses the GPC Real Time Operating System to 

schedule the IOP Shared Memory Communication task. The Shared Memory 

Communication task interacts with the CP to transfer the VO request specifications from the 

CP to the IOP. 

3.3.6.5 Process Name: Spare Link Test Scheduler 

None 

None 

VO Communications Management Software Specifications, 

Section 3.2.1.1 

None 

The Spare Link Test Scheduler process uses the GPC Real Time Operating System to 

schedule a Spare Link Test task. The Spare Link Test task posts spare link cycling service 

requests to the Queue Manager task. 

104 
33.6.6 Process Name: Activate Posting Tasks 

h?)Ut= Number of VO Requests 

outplg: None 

-is 

RdCSWlCE I/O Communications Management Software Specifications, 

Section 3.2.1.1 

Note: None 

Description: 

The Activate Posting Tasks process calls the Posting Task Manager procedure to schedule a 

Posting task for each VO Request. 

3.3.6.7 Process Name: Construct User Chains 

InplIrs: Number of VO Chains 

outplg: None 

Requirrments 

Rd-: None 

Notes: None 

The Construct User Chains process calls the Construct Chain procedure to initialize an 10s 

program region for each VO Chain created by the application. 

105 
33.6.8 Process Name: Restore User Chains 

Number of UO Chains 

Deselected Transactions 

w None 

None 

Nota: None 

The Restore User Chains process calls the Restore Chain procedure to restore an 10s 

program region (after a channel fails and returns) for each VO Chain created by the 

application. 

106 
33.7 YO System Services Global Memory Utilities 

~ 

IO-GLOB AL-MEM-T 

I CP-ALLOCATE 1 

I 

I IOP-AUOC ATE I 

I PUT I 

GET 

3.3.7.1 Process Name: 

ReC,l*IllefltS 

Reference: 

Notes: 

CP Allocate 

Number of Bytes 

Address of Buffer in Shared Memory 

None 

None 

The CP Allocate process reserves a region in shared memory for an IlO buffer. The 

process returns the address of the buffer to the calling process. 

107 
33.7.2 Process Name: IOP Allocate 

In@: Shared Memory Address Record 

u Address of Buffer in Shared Memory 

Rd-: None 

Note: None 

Description: 

The IOP Allocate process extracts the address of a shared memory VO buffer from a shared 

memory address record. The address record is communicated from the CP to the IOP so 

that both processors know the location of the buffer. 

3.3.7.3 Process Name: Put 

Inputs: 

ReqUhIK8ltS 

Reference: 

Number of Bytes 

Destination Address (private type) 

Source Address 

None 

None 

Note: None 

Description: 

The Put process moves and votes the designated number of bytes from the source address 

to the destination address. 

108 
3.3.7.4 Process Name: Get 

Number of Bytes 

Destination Address 

Source Address (private type) 

outpkr: None 

Requirements 

ReFerenCe: None 

Note: None 

Description: 

The Get process moves the designated number of bytes from the source address to the 

destination address. 

3.3.7.5 Process Name: Put with Sumcheck 

Note: 

Description: 

Number of Bytes 

Destination Address (private type) 

Source Address 

Sumcheck 

None 

None 

The Put With Sumcheck process moves and votes the designated number of bytes from the 

source address to the destination address while calculating a modulus 256 sumcheck over 

the data. 

109 
33.7.6 Process Name: Get with Sumcheck 

Number of Bytes 

Destination Address 

Source Address (private type) 

outplts Sumcheck 

l%quimmb 

Reference: None 

Nota: None 

The Get With Sumcheck process moves the designated number of bytes from the source 

address to the destination address while calculating a modulus 256 sumcheck over the data. 

110 
33.8 I/O System Services Shared Memory Allocation 

r 

10s -- SM ALLOCATE 

I NEW-SPEC-SENT I I 

I SEND-NEW-SP EC I 

CLEAR-COMPLETION-FLAG 

~~ 

I IOR-COMPLETED 1 

111 
33.81 Process Name: New Specification Sent 

Inputs: None 

u Flag for CP/IOP Interprocessor Communication of VO 

Requests 

ReqUhmmis 

R€!fetWW% YO User Interface Software Specifications, Section 2.2.1.1 

Nota: None 

The New Specification Sent process resets a flag in shared memory to coordinate the 

communication of the transaction, chain, and VO request specifications from the CP to the 

IOP. The process is used by an VO System Services CP process to synchronize the 

interprocessor communication. 

3.3.82 Process Name: Send New Specification 

Inputs: None 

u 

Requirements 

RderenCe: 

Flag for CP/IOP Interprocessor Communication of VO 

Requests 

VO User Interface Software Specifications, Section 2.2.1.1 

Nota: None 

Desaiption: 

The Send New Specification process sets a flag in shared memory to coordinate the 

communication of the transaction, chain, and I/O request specifications from the CP to the 

IOP. The process is used by the IOP Shared Memory Communication task to synchronize 

the interprocessor communication. 

112 
3.3.83 Process Name: Ready for New Specification 

Reference: 

Flag for CP/IOP Interprocessor Communication of VO 

Requests 

Flag for CP/IOP Interprocessor Communication of UO 

Requests 

VO User Interface Software Specifications, Section 2.2.1.1 

NdeS: None 

Desaiption: 

The Ready for New Specification process reads a flag in shared memory used to coordinate 

the communication of transaction, chain, and VO request specifications. The process is 

used by a CP process to determine if the IOP is able to receive more information. 

3.3.8.4 Process Name: Clear Completion Flag 

Inputs: VO Request Identifier 

WJl- VO Request Completion Flag 

Requirements 

Reference: VO Communications Management Software Specifications, 

Section 3.2.1.3 

Note: None 

Desaiption: 

The Clear Completion Flag process resets the shared memory completion flag associated 

with the designated VO request identifier. This process is used by a CP application task to 

clear a completion flag prior to polling it. 

113 
33.8.5 Process Name: Set Completion Flag 

In- I/O Request Identifier 

OUQ- I/O Request Completion Flag 

Requirements 

Refgence: I/O Communications Management Software Specifications, 

Section 3.2.1.3 

Notes: None 

The Set Completion Flag process sets the shared memory completion flag associated with 

the designated UO request identifier. This process is used by an IOP I/O Request 

Completion process to notify the CP application that the VO request has been processed. 

3.3.8.6 Process Name: VO Request Completed 

Inputs: VO Request Identifier 

Qm- I/O Request Completion Flag 

Requirements 

Reference: VO User Interface Software Specifications, Section 2.2.3.1 

Nota: None 

The I/O Request Completed process reads the shared memory completion flag associated 

with the designated UO request identifier. This process is used by a CP application task to 

determine if the I/O request has been completely processed. 

114 
33.8.7 Process Name: Unlock UO Request 

UO Request Identifier 

olltprcr: UO Request Semaphore for Output Buffers 

VO User Interface Software Specifications, Section 2.2.2.1, 

2.2.2.2 

Notes: None 

Desaiption: 

The Unlock VO Request process unlocks the shared memory output data buffer select 

region of the designated 40 request by resetting the locking semaphore. 

3.3.8.8 Process Name: Unlock YO Request Read 

Inputs: VO Request Identifier 

oum YO Request Semaphore for Input Buffers 

Requirpmentr: 

Ref-: UO User Interface Software Specifications, Section 2.2.2.1, 

2.2.2.2 

Notes: None 

The Unlock VO Request Read process unlocks the shared memory input data buffer select 

region of the designated 40 request by resetting the locking semaphore. 

115 
33.8.9 Process Name: Update VO Request Overrun Count 

I/O Request Identifier 

Number of Overruns 

outw= Number of Overruns Variable in Shmd Memory 

None 

NOteS: None 

The Update VO Request Overrun Count process sets an integer variable in shared memory 

to equal the designated number of overruns. The process is used to notify the application 

of the Occurrence of an overrun (or frequency of occurrences). 

3.3.8.10 Process Name: Unlock Select Lock 

Inpub: None 

outw= Semaphore for Select Buffers 

Requiremts 

Reference: VO User Interface Software Specifications, Section 2.2.2.3 

NdeS: None 

The Unlock Select Lock process unlocks the shared memory select buffers by resetting the 

locking semaphore. The process is called by the CP Select process after writing the 

transactions to be selected into shared memory and IOP I/O Request Execution process 

after selecting the specified transactions. 

116 
33.8.11 Process Name: Unlock Deselect Lock 

Jn- None 

ouw= Semaphore for Deselect Buffers 

I/O User Interface Software Specifications, Section 2.2.2.3 

Note: None 

The Unlock Deselect Lock process unlocks the shared memory deselect buffers by resetting 

the locking semaphore. The process is called by the CP Deselect process after writing the 

transactions to be deselected into shared memory and IOP I/O Request Execution process 

after deselecting the specified transactions. 

3.3.8.12 Process Name: Allocate Memory 

Note: 

Shared Memory Flags 

Shared Memory Events 

Shared Memory Communication Buffers 

VO User Interface Software Specifications, Section 2.2.2.4 

None 

The Allocate Memory process allocates and initializes flags, events, and buffers in shared 

memory for the VO System Services. These flags, events, and buffers are used for 

interprocessor data communication and synchronization. 

117 
3.3.9 YO System Services Dual Port Memory Map 

IOSS - DPM-MAP 

USER-RECORD 

USERACCESS 

I 

I 

3.3.9.1 Process Name: Initialize I/O User Services DPM 

User Program and Data Pointer 

Network Manager Program and Data Pointer 

ReqUiR?lIlelltS 

Refgence: None 

Note: None 

To execute the I/O requests created by the application, the IOSes have to be initialized. 

The program region of the 10s is partitioned into a header section and a linked list of 

transaction sections. Each transaction section of the 10s is used by only one chain, 

whereas the header section is used by all chains. 

The Initialize I/O User Services DPM process initializes the program region of the IOSes of 

a GPC with the chain header and linked list of transaction modules. The process must 

initialize the DPMs prior to the construction of the VO user chains (see Process 3.3.2.2 - 

Construct Chain). 

118 
3.3.9.2 Process Name: Initialize Global Variables 

None 

Requirements 

Refgence: 

Notes: 

Global Transaction Count 

Global Chain Count 

Global VO Request Count 

Memory Index Array 

None 

None 

The Initialize Global Variables process initializes the Transaction, Chain, and VO request 

identifier global variables (global to the VO System Services on a processor). It also 

initializes the Memory Index Array which is used to initialize the IOS(es) of a GPC. 

119 
33.10 I/O System Services Private ID Types 

IO!% - PRIVATE 

ID 

RETURN-ID-VALUE 

SET-ID-VALUE 

I 

I 

I 

I 

I I 

3.3.10.1 Process Name: 

Inputs: 

outplts: 

Return Identifier Value 

Identifier of the private type ID 

Identifier of the type Integer 

Requiremb 

Reference: None 

Notes: None 

Description: 

A private type is used for the transaction and chain identifiers to protect the VO User 

Interface from errors introduced by the application. 

The Return Identifier Value process converts an identifier from the private type to an integer 

type. 

120 
3.3.10.2 Process Name: Set Identifier Value 

Identifier of the type Integer 

u Identifier of the private type ID 

None 

NOteS: None 

Description: 

A private type is used for the transaction and chain identifiers to protect the YO User 

Interface from errors introduced by the application. 

The Set Identifier Value process converts an identifier from an integer type to the private 

tY Pes 

121 
3.4 UO Communications Management Data Dictionary 

Absolute Chain ID : The number of chains that have been created by the applications user 

(range 1 - Maximum Chain ID). 

Absolute YO Request ID : The number of VO requests that have been created by the 

applications user (range 1 - Maximum VO Request ID). 

Absolute Transaction ID : The number of transactions that have been created by the 

applications user (range 1 - Maximum Transaction ID). 

Active Root Link : A record containing the channel number and the channel identifier of the 

FIT channel which is currently being used to access a given network via an 10s connected 

to that channel. 

Active Root Link Flag: A boolean valued flag indicating whether or not a working 

connection from a GPC to a root node exists. 

Available YO Services : An array of booleans indexed by I/O service identifiers, one for 

each GPC in the system. When the boolean is true, the given service is available to the 

GPC. 

Channel Identifier : An identifier which designates a particular physical channel of an IOP. 

Channel Number : A logical identifier for a channel of an IOP which contains the 10s 

connected to a given network. 

Chain Record : A record that retains all of the information associated with a chain created 

by an applications user. The fields of a chain record are as follows: 

a) Visible chain ID. 

b) Private chain ID. 

c) NetworkID. 

d) Array of transaction IDS (transactions in the chain). 

e) Number of transactions. ' 

f) Boolean flag which, when set, indicates that the chain has been assigned to an VO 

request. 

g) Type of data in the chain (static, dynamic or mixed). 

h) Address in the 10s DPM of the first transaction in the chain. 

i) Pointer to the next chain in the VO request. 

j) Pointer to the associated VO request record. 

Channel Selection : An array indicating which FTP channels interface to a particular 

network. 

122 
Connected Networks : An array of booleans indexed by GPC identifier. When the boolean 

is true, the given network is physically connected to the GPC. 

Connection Indicator : A boolean valued object which when true indicates that a given 

network is physically connected to a given GPC. 

Current Root Link : A record containing the channel number and the channel identifier of 

the FTP channel which is currently being used to access a given network via an 10s 

connected to that channel. 

DIU Chain Header Record : A record that specifies the initial sequence of instructions that 

are executed by an 10s when each chain is executed. The sequence of instructions are as 

follows: 

Read the local time. 

Read the HDLC Interrupt Register. 

Read the HDLC Status Register. 

Set the number of residual bits. 

Set the polling priority. 

Enable the receiver. 

Start the poll. 

Read the local time. 

Branch to first transaction in the chain. 

DIU Chain Program Record : A record that consists of a DIU chain header record and 

array of DIU transaction records. The record is used as a temp€ate to initialize the user 

program region of the DPM of the 10s. The organization of the DPM after the initialization 

process is illustrated in the following figure. 

TRANSACnONS "Z 2 

EM)OFC" 

PROGRAM 

123 
DIU Transaction Record : A record that specifies the sequence of instructions that are 

executed by an 10s when each transaction is executed. The sequence of instructions are as 

follows: 

a) Disable the HDLC transmitter and receiver. 

b) Stop the local timer. 

c) Enable the 10s auto flag. 

d) Enable the HDLC transmitter. 

e) Send the output command (data) to the DIU. 

f) Disable the 10s auto flag. 

g) Enable the HDLC receiver and disable HDLC transmitter. 

h) Read the Interrupt Register. 

i) Write the desired time out to the timer and start timer. 

j) Receive solicited input. 

k) Branch to next transaction in the chain or end of chain program. 

DPM Pointer : A pointer whose value is the address of the fxst addressable byte of one 

DPM or set of DPMs. When used to read from a DPM, the pointer value selects exactly 

one DPM. When used to write to a DPM, the pointer value may select a set of physical 

DPMs, at most one per channel, each occupying the same memory space within the 

channel. The pointer imposes an organization on the memory space which supports the 

execution of chains on an VO network and the reading and writing of data used by those 

chains. 

VO Network Identifier : A logical identifier which is uniquely assigned to every physical 

network in the system. 

YO Network Manager Did Not Accept Repair : An array (indexed by network ID) of 

boolean flags which, when set, indicate that the VO Network Manager was unable to accept 

a network repair request. 

I/O Request Execution Count : The number of times of VO request has been executed. 

YO Request Preempted Flag : A boolean flag which, when set, indicates that an VO request 

was preempted by a priority 7 VO request. 

YO Request Record : A record that retains all of the information associated with an VO 

request created by an applications user. The fields of an VO request record are as follows: 

a) Visible VO request ID. 

b) Private VO request ID. 

c) Network ID. 

d) Array of chain IDS (chains in the VO request). 

e) Number of chains. 

f) Total number of transactions in the VO request. 

124 
g) VO request time out. 

h) Frequency at which an event is used to notify the completion of the UO request. 

i) priority of the VO request. 

j) Scheduling parameters - initiation, completion, and repetition. 

k) Pointer into the VO request priority queue. 

YO Service Descriptor : A record which states whether a given VO service is local or 

regional. In the case of a local VO network, it contains an array of network identifiers 

which specify the networks assigned to this service. 

YO Service Identifier : A logical identifier which is uniquely assigned to every VO service 

in the system. 

10s Identifier : An logical identifier which designates a particular 10s which in turn maps 

to a specific address range within an FIT channel. 

Local Chain Pointers : An array of pointers to chain records created by the applications 

user. The array is indexed by chain ID and allows direct access to the chain records. Local 

Chain Pointer arrays are constructed on the CP and IOP. 

Local YO Request Pointers : An array of pointers to UO request records created by the 

applications user. The array is indexed by UO request ID and allows direct access to the 

VO request records. Local VO Request Pointer arrays are constructed on the CP and IOP. 

Local Transaction Pointers : An array of pointers to transaction records created by the 

applications user. The array is indexed by transaction ID and allows direct access to the 

transaction records. Local Transaction Pointer arrays are constructed on the CP and IOP. 

Maximum Storage : An integer constant indicating the maximum number of bytes available 

for the YO chain programs and data for the dual ported memory of an VO Sequencer. 

Memory Index Array : An array of pointers indexed by network ID that indicate the next 

available byte in the DPM of a particular 10s. The array is used to reserve memory in the 

DPM of the IOS(es) for the transaction UO buffers. 

Posting Task Pointers: An array of pointers indexed by VO request ID to the tasks that post 

VO service requests to the Queue Manager task (YO Posting tasks). The array is used 

during the allocation and scheduling of the Posting tasks. 

Preempt YO Request Flag : A boolean flag which, when set, indicates that a priority 7 I/O 

request is pending. 

125 
Preempt Spare Link Test Flag : A boolean flag which, when set, indicates that an VO 

request is pending. 

Preempted VO Request ID : The ID of the VO request that was preempted by a priority 7 

UO request. 

Preempted VO Request State : The state (either "before writing output data to the DPM", 

"before VO request execution" or "before uploading input data from the DPM') of the VO 

request prior to being preempted by a priority 7 VO request. 

Relative DPM address : A record which is used to map the thirty-two bit address used by 

the FTP to access a location in an IOS/DPM into a sixteen bit value which the 10s will use 

to access the same location. Since the address space of the 10s is 8K bytes, only the lower 

thirteen bits are used in the mapping, the three highest order bits are assigned a value of 

zero. The mapping is defined below, where f is the value of the i* bit in the sixteen bit 

address: 

0, if 15 c= i <= 13 

value of the ith bit in the thirty-two bit address if 0 <= i <= 11 

value of the 15th bit in the thirty-two bit address if i= 12 

f(i)= 

Restoration Record: A record containing information about the repaired network 

component which the operator wishes to be returned to service. If a node is to be restored, 

the node number is provided. If a link is to be restored, a node number and a port number 

adjacent to that link is provided. 

Results of Channel OK Test : A boolean value which is true if the test indicates that an 

FTP channel is not desynchronized and false if it is desynchronized. 

Spare Link Test Preempted Flag : A boolean flag which, when set, indicates that a spare 

link cycling request was preempted by an VO request. 

System Address : A thirty-two bit value which maps to some physical location in the 

system. By which the M680XO microprocessor accesses those physical locations 

Unreachable DIUs : A list of DIUs which are attached to failed nodes and which therefore 

cannot send or receive messages on the VO network. 

Transaction Record : A record that retains all of the information associated with a 

transaction created by an applications user. The fields of a transaction record are as 

follows: 

a) Visible transaction ID. 

b) Private transaction ID. 

c) DIU address. 

126 
1. 

ld) Transaction type (input or output). 

e) Number of input data bytes. 

f) Number of output data bytes. 

g) Maximum number of errors before system bypass. 

h) Number of errors that have occd during the execution of the transaction. 

i) A boolean flag which, when set, indicates that the transaction is selected. 

j) Timeout. 

k) Local address (CP or IOP) of the input data buffer. 

1) Local address (CP or IOP) of the output data buffer. 

m) Location of input data buffer in shared memory. 

n) Location of output data buffer in shared memory. 

0) Pointer to next transaction in chain. 

p) Pointer to associated chain record. 

q) Location of input data buffer in DPM of the 10s 

r) Location of output data buffer in DPM of 10s. 

s) Boolean flag indicating if the transaction has been assigned to a chain. 

User Pointer : A pointer whose value is the address of the first addressable byte of the 

upper 4K of one DPM or set of DPMs. When used to read from a DPM, the pointer value 

selects exactly one DPM. When used to write to a DPM, the pointer value may select a set 

of physical DPMs, at most one per channel, each occupying the same memory space within 

the channel. The pointer imposes an organization on the memory space which supports the 

execution of application chains on an VO network and the reading and writing of data used 

by those chains. 

127 
4.0 YO SYSTEM SERVICES USER EXAMPLE 

The UO User Interface provides a user friendly environment allowing the applications 

programmer to create and schedule UO requests, develop application tasks and processes, 

and access DWs. This section provides examples of the construction of an UO network, 

creation of an VO request and development of an application task to illustrate the use of the 

UO System Services. 

4.1 Overview 

The UO System Services are written in Ada@, a design language primarily developed for 

the US Department of Defense for use in embedded systems. Ada is structured around a 

package framework allowing the development of structured modules. Accordingly, the VO 

networks, 1/0 requests and application tasks are constructed in a package oriented 

environment. 

The construction of 1/0 networks, 1/0 requests, and application tasks require the 

m&ication/creation of five Ada packages: UO System Services Network Data Types, 1/0 

System Services, Central Database, UO requests, applications tasks, and I/O System 

Services CP Main Initialization (illustrated in the Booch diagrams of Figures 12- 16). The 

UO System Services Central Database and Network Data Types packages are the packages 

in which the networks are defined, and they must be modified to construct the network 

topologies required by the application. The YO Requests package is a module in which the 

transactions, chains, and UO requests are created. Furthermore, the Application Tasks 

package is the module in which the user develops the application tasks that interact with the 

VO requests. Finally, the CP Main Initialization package is the means by which the user 

transfers control from the YO User Interface to the application tasks. 

I IOSS - NETWORK - DATA-TYPES I 

f DIU-ID-TYPE I 

Figure 12: VO System Services Network Data Types Padtage 

129 
I IOSS - CENTRAI-DATABASE I 

I I I 

INIT-GLOB AL-TOPOLOGY-1 

I"I'-GLoBAL-TOPOuX;Y-2 

I 

I"I'-GLOBAL-TOPOLOGY-m I 

Figure W: YO System Services Central Database Package 

TRANSACTION-D ATA-ARRAY 

IOR-ID-ARRAY 

I 

CREATEIO-REQUESTS 

I 

I 

Figure 14: YO Request Package 

APPLICATION-TASKS 

APPLICATION-TASK-1 

I 

APPLICA?'ION-TASK-2 

I 

I 

APPLICATION-TASK-m 1 

\ d 

Figure 15: Application Tasks Package 

130 
I 

I~TART_APPLICATION-TASKS I I 

Section 4.2 presents a template to illustrate the construction of an VO network, while 

Section 4.3 uses an example to illustrate the creation of a single chain, on demand I/O 

request and a two chain, periodic VO request. Section 4.4 provides an example of a on 

demand application task which is synchronized with the I/O requests created in Section 4.3. 

Finally, Section 4.5 provides an example of the use of the CP Main Initialization package to 

transfer control from the VO User Interface to the application tasks. 

4.2 Construction of an I/O Network Topology 

The discussion of the VO User Services and VO Communications Management function of 

the VO System Services has continually referred to VO networks. The I/O networks are 

defined in the INIT-GLOBAL-TOPOLOGY procedures of the package 

IOSS-CENTRAL-DATABASE. These procedures must be modified to create the I/O 

network topologies required by the application. In addition, the type DIU-ID-TYPE in the 

IOSS-NETYPES package must be modified to provide logical names for the DIUs that are 

connected to the network. In this section, the method to construct a specific network 

topology for the AIPS system is illustrated. 

procedure body INIT-GLOBAL-TOPOLOGY-2 is 

begin 

N-P-N(2) := 10; 

-- Network 2 consists of 10 nodes. 

GLOBAL-TOPOLOGY(2) := new.NODE-ARRAYTYPE( 1 .. N-P-N(2)); 

-- Define the range of nodes numbers in network 2 and allocate the required memory. 

-- Node 1 

GLOBAL-TOPOLOGY(2)( l).NODE-ADDRESS := 1; 

-- The physical node address for logical node 1 of network 2 is 1; 

13 1 
-- Pat 0 of Node 1 is a Root Node, connected to an 10s (logical ID of 3) in 

-- channel A of a GPC, and the network is connected to GPC 2 (GPC-ADDR). 

GLOBAL-TOPOLOGY (2)( l).PoRT-ARRAY (0) := 

(ADJACENT-ELEMENT => GPC, 

GPC-ADDR => 2, 

CHANNEL => A, 

10s => 3); 

-- Port 1 of Node 1 is connected to Port 1 of logical Node 3 (Node-Number is 

-- logical ID) The physical address (Node-Address) of Node 3 is also 3. 

GLOBAL-TOPOLOGY (2)( 1 ).PORT-ARRAY ( 1) := 

(ADJACENT-ELEMENT => NODE, 

NODE-NUMBER => 3, 

NODE-ADDRESS => 3, 

PORT-NUMBER => 1); 

-- Port 2 of Node 1 is connected to Port 2 of Node 2. 

GLOBAL-TOPOLOGY (2)( l).PORT-ARRAY (2) : = 

(ADJACENT-ELEMENT => NODE, 

NODE-NUMBER => 2, 

NODE-ADDRESS => 2, 

PORT-NUMBER => 2); 

-- Port 3 of Node 1 is connected to a DIU with a logical name of S 1 and physical 

-- address of 11. The logical name S 1 must be included in the type DIU-ID-TYPE 

-- in the IOSS-NETYPES package. 

GLOB AL-TOPOLOGY (2)( l).PORT-ARRAY (3) : = 

(ADJACENT-ELEMENT => DIU, 

DIU-ADDR => 11, 

DILJJD => Sl); 

-- Port 4 of Node 1 is connected to Port 4 of Node 6. 

GLOBAL,-TOPOLOGY(2)( l).PORT_ARRAY(4) := 

(ADJACENT-ELEMENT => NODE, 

NODE-NUMBER => 6, 

NODE-ADDRESS => 6, 

PORT-NUMBER => 4); 

-- Node 2 

GLOBAL-TOPOLOGY(2)(2).NODE-ADDRESS := 2; 

-- The physical node address for logical node 2 of network 2 is 2; 

132 
-- Port 0 of Node 2 is connected to Port 0 of Node 8. 

GLOBAL-TOPOLOGY (2)(2)90RT_ARRAY (0) := 

(ADJACENT-ELEMENT => NODE, 

NODE_NUMBER => 8, 

NODE-ADDRESS => 8, 

PORT-NUMBER => 0); 

-- Port 1 of Node 2 is not connected. 

GLOBAL-TOPOLOGY (2)( 2)90RT-ARRAY ( 1) := 

(ADJACENT-ELEMENT => NONE); 

-- Port 2 of Node 2 is connected to Port 2 of Node 1. Notice the corresponding 

-- connections with Port 2 of Node 1 in the database. 

GLOBAL-T0POLOGY(2)( 2)90RT-ARRAY (2) : = 

(ADJACENT-ELEMENT => NODE, 

NODE_NUMBER => 1, 

NODE-ADDRESS => 1, 

PORT-NUMBER => 2); 

-- Port 3 of Node 2 is not connected. 

GLOBAL-TOPOLOGY(2)(2)SORT_ARRAY(3) := 

(ADJACENT-ELEMENT => NONE); 

-- Port 4 of Node 2 is connected to Port 4 of Node 4. 

GLOB AL-TOPOLOGY (2)(2).PORT_ARRAY (4) := 

(ADJACENT-ELEMENT => NODE, 

NODE-NUMBER => 4, 

NODE-ADDRESS => 4, 

PORT-NUMBER => 4); 

133 
-- Node 10 

GLOBAL-TOFQLOGY(2)( lO).NODE-ADDRESS := 10; 

-- The physical node address for logical node 10 of network 2 is 10; 

-- Port 0 of Node 10 is connected to Port 0 of Node 4. 

GLOBAL-TOPOLOGY (2)( lO).PORT-ARRAY (0) := 

(ADJACENT-ELEMENT => NODE, 

NODE-NUMBER => 4, 

NODE-ADDRESS => 4, 

PORT-NUMBER => 0); 

-- Port 1 of Node 10 is not connected. 

GLOBAL-TOPOLOGY (2)( 1 O).PORT-ARRAY ( 1) := 

-- Port 2 of Node 10 is connected to Port 2 of Node 9. 

GLOBAL_TOPOLOGY(2)( lO).PORT-ARRAY (2) := 

(ADJACENT-ELEMENT => NONE); 

(ADJACENT_ELEMENT => NODE, 

NODE-NUMBER => 9, 

NODE-ADDRESS => 9, 

PORT-NUMBER => 2); 

-- Port 3 of Node 10 is connected to Port 3 of Node 8. 

GLOBAL-TOPOLOGY (2)( lO).PORT-ARRAY (3) : = 

(ADJACENT-ELEMENT => NODE, 

NODE-NUMBER => 8, 

NODE-ADDRESS => 8, 

PORT-NUMBER => 3); 

-- Port 4 of Node 10 is not connected. 

GLOBAL-TOPOLOGY (2)( 10) .PORT-ARRAY (4) : = 

(ADJACENT-ELEMENT => NONE); 

end INIT-GLOBAL-TOPOLOGY-2; 

4.3 Creation of an YO Request 

The creation of VO requests was discussed in detail in Section 2.2 - VO User Interface 

Software Specifications. In this section, the creation of a periodic and on demand 1/0 

request is provided to illustrate the use of the VO User Interface. 

134 
with IOSS-IOR-SPEC; use IOSS-IOR-SPEC; 

-- include the VO Request Specification package to make the VO User Interface calls 

-- visible to the IO-REQUESTS package; 

package IO-REQWSTS is 

-- An Ada package consists of a package specification and a package body. The package 

-- specification contains the types, objects, and subprograms declarations that are visible to 

-- other packages. The body contains transparent types, objects, and subprograms and 

-- provides the instructions that implement the visible subprograms. 

type BYTE is range 0 .. 255; -- define a memory byte type. 

for BY"SI2E use 8; 

TRANSACTION-INPUT-DATA-1 : array (0 .. 6) of BYTE, 

TRANSACTIONJNPUT-DATA-2 : array (0 .. 6) of BYTE; 

TRANSACTION-OUTPUT-DATA-1 : array (0 .. 1) of BYTE; 

TRANSACrION-OUTPUT-DATA-2 : array (0 .. 1) of BYTE; 

TRANSACTION-OUTPUT-DATA-3 : array (0 .. 1) of BYTE; 

TRANSACrION-OUTPUT-DATA-4 : array (0 .. 1) of BYTE; 

-- set the size of the type BYTE to be 8 bits. 

-- Each output transaction (3,4) has 2 bytes of output data. Each input 

-- transaction (1,2) has 2 bytes of output data and 7 bytes of input data. 

TRANSACTION-ARRAY-1 : ID-ARRAY( 1); 

TRANSACTION-ID-ARRAY-2 : ID-ARRAY( 1); 

TRANSACTION-ID-ARRAY-3-4 : ID-ARRAY(2); 

-- Definition of the transaction arrays that will be passed into the Create-Chain 

-- procedure. The number in parentheses depicts the number of transactions that 

-- will be in the chain. 

C"-ID-ARRAY-12 : ID-ARRAY(2); 

CHAIN-ID-ARRAY-3 : ID_ARRAY( 1); 

-- Chains 1 and 2 will be executed simultaneously on two redundant networks 

-- (the chains of multiple chain VO requests must be executed on different 

-- networks). Chain 3 is only executed on one network. The number 

-- in parentheses depicts the number of chains that will be in the I/O request. 

IOR-1, IOR-2 : IOR-ID-TYPE 

--The definition of the VO request IDS. 

procedure CREATE-IO_REQUESTS; 

-- The procedure that creates the I/O quests. It will be called from the CP Main 

-- Initialization package. 

end IO-REQUESTS; 

135 
package body IO-REQUESTS is 

SCHED-INFO : IOR-SCHED-RECORD; 

PERIODIC-SCHED_INFO : PERIODIC-SCHED-RECORD; 

TRANS-INFO : TRANSACTION-INFO-FECORD; 

-- Definition of types that are used to create the transactions and VO requests. 

procedure CREATE-IOR-1 is 

TRANSACTION-OUTPUT-DATA-l:= (16#F3#, 16#BO#); 

TRANSACTION-OUTPUT-DATA-2 := (16#F3#, 16#BO#); 

-- Initialize the output data buffers for transactions 1 and 2. 

TRANS-INFO:= ( IO => INPUT; 

DIU-ID => 12; 

NUM-DATA-BYTES-IN => 7; 

NUM-DATA-BYTES-OUT => 2; 

DYNAMIC-OR-STATIC => STATIC; 

MAX-BEFOW-BYPASS => 0; 

TIME-OUT => 255; 

DATA-BUFFER-INPUT => 

DATA-BUFFER-OUTPUT => 

TRANSACTION-INPUT-DATA-1 'ADDRESS; 

TRANS ACTION-OUTPUT-DATA- 1 'ADDRESS); 

-- Definition of VO parameters for transaction #1 

CWATE-TRANSACI'ION( TRANSACI'IONJD_ARRAY-l.IDS( l), 

-- Create transaction #l; 

TRANS-INFO); 

136 
TRANSINFO:= ( IO => INPUT; 

DIU-ID => 13; 

NUM-DATA-BYTES-IN => 7; 

"M-DATA-BYTES-OUT => 2; 

DYNAMIC-OR-STATIC => STATIC; 

MAX-BEFORE-BYPASS => 50; 

TIME-OUT => 128; 

DATA-BUFFER-INPUT => 

DATABUFFER-OUTPUT => 

TRANSACTION-INPUT-DATA-2'ADDRESS; 

TRANSACTION-OUTPUT-DATA-2'ADDRESS); 

-- Definition of UO parameters for transaction #2 

CREATE-TRANSACIION( TRANSACIION-Il-ARRAY-2.IDS( l), 

-- Create transaction #2; 

TRANSINFO); 

CREATE-CHAIN( CHAIN-ID-ARRAY- 12. IDS ( 1 ), 

NETWORK-ID => 1, 

TRANSACI'ION-ID-ARRAY-1); 

-- Create Chain #1 which will execute transaction #1 on network #l. 

CREATE-C"( CHAIN-ID-ARRAY-1-2.IDS(2), 

NETWORK-ID => 3, 

TRANS ACI'ION-ID-ARRAY-2); 

-- Create Chain #2 which will execute transaction #2 on network #3. 

PERIODIC-SCHED-INFO := ( HOW-STARTED =>START-AFIER-DEL,AY; 

-- Start the periodic application task after a 30 second delay. 

WAIT-FQR => DURATION(30)); 

SCHEDJNFO := ( PRIORITY => 6; 

COMPLETION-EVENT => ALWAYS; 

IOR-TIME-OUT => 1OOo; 

HOW-SCHEDULED => PERIODIC; 

START => PERIODIC-SCHED-INFO; 

REPETITION-PERIOD => DURATION( .Ol); 

WHEN-TO-STOP => NEVER-STOP); 

-- Schedule the VO request to be periodic at 100 hz, have a priority of 6, always 

-- use an event to signal its completion, start after a 30 second delay, require 1 ms. 

-- on the networks and never stop. 

137 
CREATE-IOR(I0R-1, CHAIN-ID-ARRAY-1-2, SCHEDJNFO); 

-- Create ID request #1 

end CREATE-IOR-1; 

procedw CREATE-IOR-2 is 

TRANSACTION-OUTPUT-DATA-3 := (16#F3#, 16#B 1#); 

TRANSACTION-OUTPUT-DATA-4 := (16#F3#, 16#B2#); 

-- Initialize the output data buffers for transactions 3 and 4. 

TRANS-INFO:= ( IO => OUTPUT, 

DIU-ID => 14; 

NUM-DATA-BYTES-OUT => 2; 

DYNAMIC-OR-STATIC => DYNAMIC; 

DATA-BUFFER-OUTPUT => 

TRANSACTION-OuTPUT-DATA-3'ADDRESS); 

-- Definition of output parameters for transaction #3 

CREATE-TRANSACI'ION( TRANSACTION-ID-ARRAY-3-4.IDS( l), 

-- Create transaction #3; 

TRANS-INFO); 

TRANS-INFO:= ( IO => OUTPUT; 

DIU-ID => 13; 

NUM-DATA-BYTES-OUT => 2; 

DYNAMIC-OR-STATIC => DYNAMIC; 

DATABUFFER-OUTPUT => 

TRANSACTION-OUTPUT-DATA-4'ADDESS); 

-- Definition of output parameters for transaction #4 

CREATE_TRANSACTION( TRANSACTION-ID-ARRAY-3-4.IDS(2), 

-- Create transaction #4, 

TRANS-INFO); 

CREATE-C"( CHAIN-IDARRAY-3. IDS ( 1 ) , 

NETWORK-ID => 2, 

TRANSACTION-ID-ARRAY-3-4); 

-- Create Chain #3 which will execute transactions #3 and #4 on network #2. 

138 
SCHED-INFO := ( PRIORITY => 7; 

COMPLETION-EVENT => NEVER 

IOR-TIMJ-OUT => 2000; 

HOW-SCHEDULED => ON-DEMAND); 

-- Schedule the VO request to be on demand, have a priority of 7, require 2 ms. on 

-- the network and never use an event to signal its completion. 

CREATE-IOR(I0R-2, CHAIN-ID-ARRAY-3, SCHED-INFO); 

-- Create VO request #2 

end CREATE-IOR-2; 

procedm CREATE-IO-REQUESTS is 

begin 

CREATE-IOR-1; 

CREATE-IOR-2; 

end CREATE-IO-REQUESTS; 

end IO-REQUESTS; 

4.4 Creation of an Application Task 

The application tasks that are created by the user may be synchronized with specific 1/0 

requests or "free running" processes. In the simple synchronized case, either the 1/0 

request is periodically triggered by the application (on demand VO request; periodic 

application) or the application task is periodically triggered by the VO request (on demand 

application; periodic I/O request). In the simple free running case, the I/O requests and 

application tasks are both periodic. Alternatively, combinations of the synchronization/free 

running schemes can be incorporated to handle more complex control applications. 

This section presents an example to illustrate some of the features of the VO User Interface. 

The example constructs an application task which is synchronized with the I/O requests 

created in Section 4.3. The control flow of the application task is as follows: 

1) VO request #1 periodically reads sensor information. 

2) The application task is started by the completion event of 1/0 request #l. 

3) After the application task is started, the input data is read. The application task 

4) After the output commands have been calculated, the application task writes the 

5) After VO request #2 is started, the application task loops back to repeat the 

' 

uses the input data to generate output commands. 

output data and uses an event to start VO request #2. 

process (2 - 4). 

139 
with SCHEDULER, EVENT-CONTROL, IO-REQUESTS, IOSS-IORSPEC, 

use SCHEDULER, EVENT-CONTROL, IO-REQUESTS, IOSS-IOR-SPEC, 

TASKS-IDS, APPLICATION-LOG; 

TASKS-IDS, APPLICATION-LOG; 

package APPLICATION-TASKS is 

task type APPLICATION-TASK-TYPE is 

end APPLICATION-TASK-TYPE; 

entry START-APPLICATION-TASK; 

APPLICATION-TASK : APPLICATION-TASK-TYPE 

-- Define an object of APPLICATION-TASK-TYPE. 

end APPLICATION-TA S KS ; 

package body APPLICATION-TASKS is 

function GET-APPLICATION-TASK-ID is new TASK-IDSID-OF 

APPLICATION-TASK-ID : TASK-IDS.TASK-ID := 

-- Determine an ID for the application task to schedule it. 

(APPLICATION-TASK-TYPE); 

GET_APPLICATION-TASK_ID(APPLICATION-TASK); 

task body APPLICATION-TASK-TYPE is 

COMPLETION-E~NT : a-EVENT, 

LOCKED, ERROR, OLD-DATA : BOOLEAN := FALSE; 

OVERRUN-CNT : INTEGER := 0; 

APPLICATION-LOG-ID : LOG-RANGE := 1; 

-- Define some objects that will be used for error checking. 

-- Select the application Log to be used. 

begin 

accept START-APPLICATION-TASK; 

-- Wait until control has been passed to the application task from the CP Main 

-- Initialization procedure. 

WAIT-UNTL-IOP_COMPLETED; 

--Wait until the VO Services have been initialized. 

140 
ICOMPLETION-EVENT := IOR~COMPLETION~EVENT(IOR~1); 

-- Obtain the pointer to the completion event associated with VO request #1. 

SCHEDULE( APPLICATION-TASK-ID, 

FALSE, 

SAME-PRIORITY, 

(ON-EVENT-SET, COMPLETION-EVENT), . 

NO-REPETITION, 

NO-COMPLETION); 

--Schedule the application task to be triggered by the completion event from I/O 

-- request #l. 

WAlT-FOR-SCHEDULE 

-- Wait for the scheduling requirements to be met. Specifically, wait for VO 

-- request #1 to be completed. 

READ_IOR( IOR-1, LOCKED, ERROR, OLD-DATA); 

-- Read the input data returned by I/O request #l. The input data is located 

-- in the buffers defined in IO-REQUESTS for transactions 1 and 2. 

if not ERROR and then not LOCKED then 

-- 

-- Follow appropriate control laws to determine output data. 

-- Store the output data in the output buffers allocated for 

-- transactions 3 and 4 in the package IO-REQUESTS. 

-- 

WRlTE-IOR(I0R-2, LOCKED); 

-- Write the output data. 

START-IOR( IOR-2); 

-- Start VO request #2. 

else 

Lffi-ERROR(APPLICATION-Lffi-ID, 

INTEGER(I0R-1); 

"APPLICATION TASK", 

"LOCKED OR ERROR DURING READ"); 

-- Log error in application log. 

141 
end if; 

end loop; 

end APPLICATION-TASK-TYPE 

end APPLICATION-TASKS; 

45 Passing Control to an Application Task 

The Local System Services performs the function of GPC Initialization, as discussed in 

[ 13. After the GPC Initialization process is complete, the VO requests can be created and 

the application tasks started. The START-APPLICATION-TASKS procedure allows the 

user to invoke the CREATE-IO-REQUESTS procedure and subsequently start the 

predefined application tasks. Unlike the IO-REQUESTS and APPLICATION-TASKS 

packages which can be arbitrarily named by the user, the IOSS-CP-MAIN-INIT package 

and START-APPLICATION-TASKS procedure names can not be changed. The main 

program on the CP expects these names to exist. 

The following example illustrates the invocation of the user defined Create VO Requests 

procedure and starting the associated application tasks. 

with IO-REQUESTS, IOSS-IOR-SPEC, APPLICATION-TASKS ; 

use IO-REQUESTS, IOSS-IOR-SPEC, APPLICATION-TASKS; 

package IOSS-CP-MAIN-INIT is 

procedure START-APPLICATION-TASKS; 

-- Make the Start Application Task procedure visible to the CP Main Program 

end IOSS-CP-MAIN-INIT, 

package body IOSS-CP-MAIN-INIT is 

procedure body START-APPLICATION-TASKS is 

begin 

CREATE-IO-REQUESTS ; 

-- Invoke Create VO Requests Procedure. 

CP-COMPLETED; 

-- Signal the IOP that the VO requests have been created. 

142 
APPLICATION-TASK.START-APPLICATION-TASK; 

-- Start the application tasks. 

end START-APPLICATION-TASKS; 

end IOSS-CP-MAIN-INIT, 

143 
5.0 CONCLUSIONS AND RECOMMENDATIONS 

The Advanced Information Processing System (AIPS) VO System Services have been 

designed, implemented, and tested on the centralized configuration of the AIPS engineering 

model. The VO User Interface provides a robust, user friendly environment that allows an 

applications programmer to create VO requests and applications tasks to directly reference 

DIUs (to the user, the DIUs appear to be memory mapped). The VO Communications 

Management system interacts with the VO User Interface to schedule, execute, and process 

the VO requests. The VO Network Management function initializes its associated network 

and performs network FDIR when required. The responsibilities of this software include 

the following: communicating VO request specifications from the CP to the IOP, 

scheduling application tasks and VO requests, communicating VO data between the CP and 

IOP, executing VO requests on single and redundant networks, performing VO request 

error processing, communicating error and status information to application tasks, and 

performing network FDIR. 

5.1 Preliminary Testing of the I/O System Services 

The preliminary testing of the VO System Services was performed by creating a sample set 

of VO requests and application tasks. The 1/0 requests exercised all of the 1/0 

communication, scheduling and synchronization features of the VO User Interface. The 

application tasks tested the interprocessor communication of I/O data and status 

information. This testing process involved 

single and redundant networks of varying topologies 

network nodes simulating DIUs 

synchronous and asynchronous VO requests of varying priorities and sizes 

synchronous and asynchronous application tasks of varying complexities 

interprocessor contention for shared resources 

channel, data exchange, IOS, network and DIU fault injection 

channel and network node/link restoration 

spare link cycling 

The testing of VO System Services focused on the near simultaneous execution of VO 

chains on redundant VO networks (a redundant network is a set of VO networks connected 

to the same GPC, where each network consists of a set of redundant DIUs). The tests 

primarily examined the performance of the VO System Services when faults were injected 

in a redundant network consisting of two VO networks and six DIUs. It was crucial to 

verify that the VO requests were executed without interuption on the fault-free network 

while VO network FDIR was performed on the faultly network. The types of network 

faults that were injected were IOS, link, and node faults. In all test cases, the faults were 

identifed (and bypassed if possible), and the VO requests were executed on schedule. 
5.2 Performance Metria 

Performance memcs were recorded and evaluated for a sample VO application. This 

application involved: 

1) a redundant I/O service - two 10 node networks 

2). network nodes simulating DIUs 

3) three application tasks 

a) a periodic task scheduled to execute every 100 ms. (10 Hz.) 

b) an on-demand task scheduled to execute every 200 ms. (5 Hz.) 

c) an on-demand task scheduled to execute every 400 ms. (2.5 Hz.) 

d) the periodic task started the on-demand tasks using local events 

4) three on-demand 40 requests 

5) synchronized application tasks and UO requests 

a) the 10 Hz. task starts a two chain VO request which has 8 input transactions per 

chain 

b) the 5 Hz. task starts a two chain VO request which has 10 input transactions per 

chain 

c) the 2.5 Hz. task starts a two chain VO request which has 2 input transactions 

per chain 

The performance memcs were measured on the centralized configuration of the AIPS 

engineering model which incorporates the following components: 

1) 68010 processors with 7.9 MHz. clocks (CP and IOP) 

2) custom UO Sequencers with 7.9 MHz. clocks 

3) 2 MBiVsecond VO buses 

4) custom network nodes 

a) 68701 processor with a 2 MHz. clock 

b) requires a 256 microsecond "quiet time" between successive node transmissions 

to check input buffers (affects network FDIR) 

5) Verdix 5.4 Run Time System 

The VO request processing times for the sample application are illustrated in Figures 17 and 

18. The timings of the VO System Services procedure and function calls are presented in 

Figure 19. 

146 
r/o Request (2 Chains - 2 Transaction per Chain) 

(2.5 Hz. VO request) 

25 ms. 

Overhead of event processing 

Overhead of accepting VO request for processing 

Overhead of transaction selectldeselect check 

Determine SM Buffer 

Write output data and setup chain 

Execute Chain 

Calculate SM Buffer 

Read input data and error processing 

Required 10s header time 

Required 10s processing time for input transaction 

Required network time 

Approximate IOR Time Out 

- 

1.0 ms. 

2.0 ms. 

0.1 ms. 

0.3 ms. 

9.6 ms. 

3.2 ms. 

0.4 ms. 

8.2 ms. 

150 ps. 

235 ps. 

334 ps. 1 ms. 

VO Request (2 Chains - 8 Transactions per Chain) (10 Hz. VO request) . 

41.1 ms. 

Overhead of event processing 

Overhead of accepting VO request for processing 

Overhead of transaction selectldeselect check 

Determine SM Buffer 

Write output data and setup chain 

Execute Chain 

Calculate SM Buffer 

Read input data and error processing 

Required 10s header time 

Required 10s processing time for input transaction 

Requkd network time 

Approximate IOR Time Out 

1.0 ms. 

2.0 ms. 

0.1 ms. 

0.3 ms. 

12.9 ms. 

6.0 ms. 

0.4 ms. 

18.2 ms. 

235 ps. 

1632 ps. 

3.8 ms. 

150 ps. 

Figure 17: YO Request Processing Times for the Sample Application 

. 

147 
FU" 

I/O Request (2 Chains - 10 Transactions per Chain) 

(5 Hz. ID request) 

a) Overhead of event processing 

b) Overhead of accepting UO request for processing 

c) Overhead of transaction selecddeselect check 

d) DetermineSMBuffer 

e) Write output data and setup chain 

f) Executechain 

g) Calculate SM Buffer 

h) Read input data and error processing 

i) Required 10s header time 

j) Required 10s processing time for input transaction 

k) Required network time 

1) Approximate IOR Time Out 

Latency between execution of 2 simultaneous chains 

52.6 ms. 

1.0 ms. 

2.0 ms. 

0.1 ms. 

0.3 ms. 

15.9 ms. 

6.8 ms. 

0.4 ms. 

25.8 ms. 

150 ps. 

235 ps. 

1916 ps. 

4.6 ms. 

4.1 ps. 

Figure 18 YO Request Processing Times for the Sample Application (Continued) 

5.3 Future Work 

As mentioned previously, the design and implementation of the VO System Services was 

completed on the centralized configuration of the AIPS engineering model. With respect to 

a centralized system, the I/O System Services is finished. Yet, with respect to the 

distributed configuration of the engineering model, the I/O System Services must be 

modified. These modifications are required because the I/O Communications Manager and 

its associated I/O Network Managers could reside on different remote sites. Accordingly, 

the interface between the I/O Communications Manager and Network Manager must be 

extended to allow for both intracomputer and intercomputer communication of FDIR, 

spare link cycling, and restoration commands and network status information. 

148 
Write-IOR 

a) 2 Chains, 2 Transactions per Chain, 2 Bytes 2.4 ms. 

b) 2 Chains, 8 Transactions per Chain, 2 Bytes 6.7 ms. 

c) 2 Chains, 10 Transactions per Chain, 2 Bytes 8.2 ms. 

ReadIOR 

a) 2 Chains, 2 Transactions per Chain, 7 Bytes 3.2 ms. 

b) 2 Chains, 8 Transactions per Chain, 7 Bytes 8.4 ms. 

c) 2 Chains, 10 Transactions per Chain, 7 Bytes 10.1 ms. 

Start-IOR 

S topJOR 

Transac tion-Error 

Transaction-IsB ypassed 

Chain-Error 

IOR-Has-Overrun 

SelectTransaction 

Deselect-Transaction 

Write-Transaction 

IOR-Read y 

Clear-IOR-Read y 

IOR-Read y-and-Clear 

0.5 ms. 

0.5 ms. 

0.2 ms. 

0.2 ms. 

0.6 ms. 

0.1 ms. 

0.5 ms. 

0.5 ms. 

1.2 rns. 

0.1 rns. 

0.1 rns. 

0.2 ms. 

Figure 19: I/O System Services Timings for the Sample Application 

149 
6.0 REFERENCES 

1. L. Burkhardt, L. Alger, R. Whittredge, and P. Stasiowski, "Advanced Information 

Processing System: Local System Services", NASA Contractor Report 18 1767, 

March, 1989. 

2. G. Nagle, L. Alger, and A. Kemp, "Advanced Information Processing System: 

Input/Output Network Management Software", NASA Contractor Report 18 1678, 

May, 1988. 

3. G. Booch, Software Engineerin? with Ada@, Benjamin/Cummings Publishing Co., 

Inc., Menlo Park, CA, 1983. 

PRECEDIMG PAGE BUNK NOT FILMED 

~TENTIONAUI BUM 

151 
APPENDIX A: GLOSSARY OF r/O NETWORKTERMS 

Network Hardware 

Node: a circuit switching device with 5 ports which can each be independently enabled or 

disabled. An enabled port retransmits the logical OR of all data which has been received by 

any other enabled port. The retransmission is carried out with minimal delay, nominally 

one half the period of the transmission clock. 

Device Interface Unit (DIU): The smallest unit addressable by an application on an I/O 

network. DIUs may be single devices (such as sensors or actuators) or collections of such 

devices. 

IOP VO Processor. 

CP Computational Processor. 

GPC: General Purpose Computer consisting of an IOP, a CP, and their interfaces to I/O 

and IC networks. 

I/O Sequencer (10s): A state machine whose function is to conduct the physical aspects of 

communication on an VO network for a GPC. The 10s communicates with one channel of 

a GPC by means of a Dual Ported Memory (DPM). The 10s executes a progr& which 

has been stored in DPM by the IOP. Part of the DPM behaves as a set of control and status 

registers for the 10s. Once a program has been stored in the DPM, communication 

between the 10s and GPC can be conducted by means of the control and status registers. 

Once the programs have been stored in the DPM, it is only necessary to update the data 

required by these programs. Input data must be exchanged across redundant channels for 

source congruency and output data must be voted to provide fault masking. Each 10s is a 

simplex device which performs its function asynchronously from other IOSes and from the 

GPC to which it is connected. 

Network Interface: the hardware involved in the connection between a GPC and a network. 

It consists of an IOS, 8 K bytes of dual ported memory, and a link (called the root link) 

connecting the 10s to a network node (called the root node). 

YO Network: a set of nodes and DIUs which are physically interconnected. 

YO Network Topology: The specific interconnections among the nodes, GPCs and DIUs in 

an VO network. 

A- 1 
Virtual Bus: A network whose nodes have been configured to allow communication 

between a GPC and DIUs or nodes on that network to emulate communication on a serial 

bus. 

Network Classification 

I/O Service: A logical organization imposed on VO network use. A service may be 

designated as Regional or Local. 

Regional YO Service: I/O activity conducted on a single VO network which is shared 

among several GPCs. Since only one GPC may use the network at any given time, GPCs 

must contend for use of the network. 

Local YO Service: I/O activity conducted on an VO network which is used exclusively by 

one GPC. If an VO network which is part of a Local VO Service is physically connected to 

more than one GPC, only one of those GPCs will be included in the service at any given 

time. A change in the GPC included in the service constitutes a function migration. 

Redundant I/O Network: a set of VO networks COM~CW~ to the same GPC. Each network 

in the set consists of a set of corresponding, redundant devices (sensors and effectors). It 

is not required that these devices be interconnected by the same topology. To support 

function migration, each network in the set may have corresponding connections to more 

than one GPC. However, during normal operation, access to this set of networks is 

reserved exclusively for one GPC. 

Redundant I/O Service: A special form of Local VO Service where VO activity is conducted 

on a set of redundant VO networks. This is the only type of service supported on 

redundant VO networks. The intent of this service is threefold: 

1) to provide simultaneous access to redundant devices on redundant networks 

2) to increase the bandwidth of the physical VO networks communicating with 

3) to provide applications an uninterrupted flow of I/O data during periods of 

during no fault conditions 

redundant external devices. 

network reconfiguration activity. 

Network Protocols 

HDLC Protocol: The bit oriented protocol conducted on the data link of the communication 

hierarchy . 

General YO Protocol: The protocol followed between the 10s and nodesDIUs for the 

purpose of conducting VO transactions. All transactions begin with a command frame sent 

A-2 
from the 10s to a node or DIU. A node always returns a response frame. A DIU is not 

required to return a response frame. 

Network Trafsic 

Frame: An HDLC frame. The smallest unit of communication between an 10s and an 

external device (node or DIU) on an UO network. 

Flag Reld: 01111110 ControlFIeld: 

Frame 

lbytb 

a 

RB G7 bits 

Addess M: 1 byte DataField: 1-122bytes FcsFlekf: 2bytes 

figure 17: HDLC Frame Format 

Command Frame: A frame sent to a single node or DIU from an 10s using the HDLC 

protocol. See Figure 17. A command frame to a node is distinguished from a command 

frame to a DIU by the number of residual bits which are transmitted. A node command 

frame has three residual bits while a DIU command frame has five residual bits. 

Response Frame: A frame sent to a GPC from a node or DIU using the HDLC protocol. 

See Figure 17. A response frame from a node is distinguished from a response frame from 

a DIU by the number of residual bits which are transmitted. A node response frame has 

three residual bits while a DIU response frame has five residual bits. 

I/O Transaction: A command frame which may be followed by a response frame. A node 

always returns a response fiame. A DIU is not required to return a response frame. 

I/O Chain: An ordered set of one or more transactions addressed to devices on one VO 

network. A chain consists exclusively of either node transactions or DIU transactions. A 

chain is the smallest unit of UO activity conducted by an 10s for a GPC. 

Redundant Chains: A set of UO chains designed to execute in loose simultaneity on a set of 

redundant 1/0 networks. The transactions within each chain are in a one to one 

correspondence with the transactions in the other chains. This reflects the one to one 

correspondence of redundant DIUs among the networks. 

A-3 
YO Request: A set of one or more UO chains each of which executes on a different I/O 

network. An VO request consists exclusively of one set of redundant or non-redundant 

chains. An I/O request is the smallest unit of I/O activity conducted by I/O System Services 

for a user. 

Chain Execution: The activity carried out by an 10s which results in the transmission of 

command frames and the reception of response frames on an UO network. The program 

which an 10s executes is under the direct control of I/O System Services and the indirect 

control of the user specifying the chain. When a user creates a chain of transactions, certain 

parameters must be specified which control the execution of the chain. I/O System 

Services then translates these specifications into a program which is stored in DPM and 

which executes when I/O System Services starts that chain. The activity is initiated by I/O 

System Services but executes independently of the program running in the GPC. 

Interprocessor Communications 

Companion YO Record: A transaction, chain or I/O request record residing on the IOP that 

is the dual of a transaction, chain, or I/O request record created by the user on the CP. 

These records are communicated to the IOP from the CP and are required for the execution 

and processing of the VO requests. 

Event: A signal which is observed by the GPC Real Time Operating System. Events 

interrupt the co-processor and are used to activate/deactivate tasks on the co-processor. 

Flag: A passive signal that does not interrupt the co-processor. Flags may be observed or 

ignored by tasks on the co-processor. 

Queue Management 

Queue Manager Task: A process which initializes and controls all access to an 1/0 service. 

Service Request: A request to process an 110 request, cycle a spare link, or restore a 

network element. 

YO Request Priority Queue: A prioritized queue which is constructed to control the 

processing of I/O requests. The queue is a linked list and is ordered based on the priorities 

of the I/O requests. The queue is used by the Priority Queue Manager to determine the next 

I/O request to be processed. 

Posting Task: A task that is scheduled through the GPC Real Time Operating System 

based on the scheduling requirements of its associated I/O request. When scheduling 

requirements of the I/O request have been met, the task posts a service request to I/O 

request priority queue. 

A-4 
APPENDIX B: YO SERVICE OPERATING RULES: NETWORKTOPOLOGY, GPC 

CON'NECI'MTY AND I/O REQUESI' DEFINITION 

I10 Service: Dejinition and Operanon 

1) An VO Service provides access either to one regional network or to a set of one or more 

local networks. 

2) An 40 Service to a set of local networks operates those networks in parallel. 

3) UO Requests are specific to one VO Service. It consists of a set of chains, at most one 

per network within the service. 

4) All chains in an VO Request are started at the same time. The VO Request is completed 

and data becomes available to a user, when all chains within the request are completed. 

5) Chains on parallel networks can be used to allow corresponding devices on each 

network to be accessed at approximately the same time. The degree of simultaneity which 

can be achieved is determined by three factors: the rate at which the 10s samples its 

Interface Command Register, the amount of time required to issue a Start Chain command, 

and the reproducibility of the response time for corresponding external devices. 

6) A network is out of service from the time errors are detected on that network until a 

reconfiguration has been effected. In this context, a reconfiguration consists of either a 

network interface switch or a network reconfiguration. When a network is out of service, 

no user chains are executed on that network, however, service to other networks in that VO 

Service is not affected. 

7) Node status collection and spare link testing will be conducted simultaneously on all 

parallel networks within an VO Service. 

Network Topology Rules 

1) Nodes will be connected in a way which would require at least 3 port failures to isolate 

any node or set of nodes from the rest of the network. This is the so called "minimum cut 

set". 

2) At most one DIU will be connected to a node. 

3) At most one GPC will be connected to a node. 

4) A node may be connected to both a GPC and a DIU. 

B- 1 
5) Parallel networks need not be connected in identical ways nor do they need to contain the 

same number of nodes or the same number of DIUs. In this way, user can trade 

throughput for reliability. 

A B 

GPC Connectivity and Network Interfaces 

C 

1) A network has at most one interface per GPC channel, Le. redundant root links to a 

network from a GPC come from distinct channels. Thus the maximum number of network 

interfaces connecting a GPC to a network is equal to the number of channels in the GPC. 

2) Parallel networks are local networks in that they are used exclusively by one GPC for 

normal operations for long periods of time. However, more than one GPC may be 

physically connected to these networks and are therefore capable of taking over control and 

use of these networks in response to failure conditions. These spare connections are made 

ready and initialized as if they were to be used but remain dormant until activated by some 

higher controlling process such as the system manager. 

3) Redundant network interfaces (i.e. root links to the same network) must have their 

IOSes occupy corresponding address spaces within their respective channels. This 

facilitates dual ported memory testing and allows modifications to chain programs and 

chain data to be made simultaneously to all redundant interface to the network. 

Network 1 1 

Figure B-1: Correct Redundant Root Link ConneCtion 

of a GPC to a Network 

B-2 
A B C 

I Network 1 I 

1 23 

Fw B-2: Incorrect Redundant Root Link Connection 

of a GPC to a Network 

K>sK>sK>sK>sK>SK>SK36m IC6 

1 2 3 1 '2 3 

I10 Request Definition 

1) UO Request Definitions determine whether an UO Service is being used for reliability or 

throughput. They may access redundant devices simultaneously for greater reliability or 

they may access non-redundant devices for greater throughput. 

2) An UO Request may run chains on a subset of networks in an VO Service, however, 

unused networks in the service remain idle during the execution of the request. 

I10 Request Construction 

1) A transaction ID returned by the Create Transaction procedure may only be used in one 

Create Chain procedure call. 

2) A chain ID returned by the Create Chain procedure may only be used in one Create I/O 

Request procedure call. 

B-3 
APPENDIX C: INPUT OUTPUT SEQUENCER (IOS) 

1.0 OVERVIEW 

The Input Output Sequencer (10s) is an autonomous asynchronous interface between an 

AIPS General Purpose Computer (GPC) and an UO network. It resides on the shared bus 

of the GPC and can be accessed by either the Computational Processor (CP) or the UO 

Processor (IOP). A major function of the 10s is to carry out detailed communication with 

VO devices on the network as well as with the network nodes, off-loading the GPC from 

lower level UO functions. A simplified block diagram of the AIPS UO organization is 

shown in Figure C- 1. 

The 10s is connected to a node of the UO network via a bidirectional connection, which is 

called a root link. When activated by the GPC, the 10s can transmit on the network via its 

root link. The 10s is a memory mapped device that can be accessed andor programmed by 

the CP or the IOP to perform a sequence of instructions which is called a chain. The 

memory locations within an 10s form a dual port memory that can be accessed by 

processors one side and the 10s on the other. GPCs preload data into the memory for 

transmission to Device Interface Units (DIUs) or nodes. The 10s interfaces with the DIUs 

and nodes in a command response mode, which is referred to as a transaction. During a 

transaction the 10s transmits a command to a DIU or node and then, if required, waits a 

predetermined time for a response. The 10s writes response data into the locations of 

memory specified by the GPC in the chain. An 10s executes a chain only when it is 

enabled by its GPC. 

Each channel of a redundant GPC may contain an 10s. These IOSs, if connected to 

individual networks, can all be active simultaneously. However, if all of the IOSs are 

connected to the same UO network, then only one should be enabled to transmit at a time. 

A GPC channel may also contain more than one 10s for redundancy. When an 10s is 

commanded to start, it first contends (polls) with all other active IOSs for the use of the 

network if the network is shared among several GPCs. If it wins, it then has exclusive use 

of the network and can send and receive messages to DIUs and nodes. If an 10s loses, it 

waits for the network to be quiet (no data traffic) for a fixed amount of time or for another 

poll to start before contending again. Provision is made within the 10s for starting a poll 

without waiting if a failure is perceived on the network 

A detailed explanation of the components of the 10s follows. It includes a description of 

the instruction format, memory assignments, register definition as well as chain examples 

for the 10s. For the purpose of this document a chain is defined as the instructions that are 

executed as a unit. All instructions within the 10s are 4 bytes long. All values are given in 

hexadecimal units unless otherwise specified. 

c- 1 
I 

I 

I 

I I--- 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

IU 

I& 

'U 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

1 

I 

'__-,,___,,,_-_: 

I 

I 

I 

b 

I 

IU I 

I 4 

I I 

I 

b 

'U' 

I I 

I I 

I I 

I I .--,_- 

Figure C-1. AIPS VO Organization 

c-2 
V 

t 

MEMORY 

I 4 

4FADDRESS 

DECODER 

CHAIN 

REG I STER 

DRIUERS 

RECEIUERS 

SHUTDOWN 

EF LATCH 

INTERFACE 

+&nJSR I 

!!L ENGAGE A 

I REGISTER 1 7-i 

Figure C-2. 10s Block Diagram 

c-3 
2.0.10s ORGANIZATION 

A block diagram of the 10s is shown in Figure C-2. The 10s is programmed from a GPC 

which has access to the dual port memory and hardware registers. After loading the 

.memory with the required chains the GPC then starts the 10s. The 10s can poll and run 

the chains without GPC intervention. An overview of the major components of the 10s is 

. givenbelow. 

2.1 MEMORY CONTROLLER - The memory controller arbitrates memory accesses from 

the GPC and the 10s. The memory is time shared between them by the use of processor 

signal 4F. When 4F is high the processor can access the memory and when 4F is low the 

10s can have access. The memory controller generates chip select, read-write and output 

enable at the appropriate times. 

2.2 ADDRESS MULTIPLEXER - The address multiplexer selects between the GPC and 

10s address buses. The output of the multiplexer is the memory address bus (MA). When 

4F is high the processor address bus is connected to memory and when 4F is low the 10s 

memory bus is connected to the memory. 

2.3 MEMORY - The 10s memory is a byte addressed memory containing 8192 bytes. It is 

used to store the chains, input packets and output packets. The first two bytes of memory 

are used as the solicited chain pointer and the second two bytes are used as the unsolicited 

chain pointer. 

2.4 GFC INPUT LATCH - The GPC input latch is a buffer driver used to input byte wide 

data from the GPC data bus (PD) to the memory data bus (MD). 

2.5 GPC OUTPUT LATCH - The GPC output latch is a buffer driver used to output data 

from the memory bus (MD) to the GPC data bus (PD). 

2.6 10s INPUT LATCH - The 10s input latch is a buffer driver used to input byte wide 

data from the internal 10s data bus @B) to the memory data bus (MD). 

2.7 10s OUTPUT LATCH - The 10s output latch is a buffer driver used to output data 

from the memory bus (MD) to the internal 10s data bus @B). 

2.8 ADDRESS DECODER - The address decoder, decodes the individual hardware 

registers which are located in the memory space between 10 and 1F. The addresses of the 

hardware registers is given in section 4. 

2.9 INTERFACE COMMAND REGISTER - The interface command register is a write 

only register that contains the commanded mode. See section 5.3.1 for a detailed 

description of the possible modes. 

c-4 
I 

2.10 SEQUENCER - The sequencer is the main control element of the 10s. When started 

the sequencer fetches the instructions from memory, stores them internally, decodes and 

executes the microcycles by generating the appropriate control signals. 

2.11 CHAIN STATUS REGISTER - The chain status register is a read only register that 

contains the chain and contention logic status within the 10s. See section 5.2.1.2 for a 

detailed description of the status reported. 

2.12 INTERFACE STATUS REGISTER - The interface status register is a read only 

register that contains the status of the 10s. See section 5.2.1.1 for a detailed description of 

the status reported. 

2.13 ADDRESS COUNTER - The address counter stores the current memory address that 

the 10s is using. It is used to point to where in memory the chain instructions are located. 

During an input instruction it points to the location where the incoming data byte is to be 

stored. In an output instruction it points to the byte to be output when the HDLC chip 

requests a byte. It is loaded during instruction fetches and incremented during the 

instruction microcycles. 

2.14 ADDRESS REGISTER - The address register contain the fixed addresses used in the 

instructions. During an input instruction it contains the address of the HDLC input 

register. During an output instruction it contains the address of the HDLC transmitter 

holding register. 

2.15 DATA COUNTER - The data counter contains data that is incremented during an 

instruction. During an input instruction it accumulates the byte count of the incoming data. 

During an output instruction it counts the number of bytes outputted until the message is 

complete at which time it signals the sequencer to terminate the instruction. 

2.16 DATA REGISTER - The data register is used to temporarily store data within an 

instruction. During an input instruction it holds the incoming byte from the HDLC receiver 

register until a memory cycle can be performed to store it. During an output instruction it 

holds the next byte to be outputted until the HDLC transmit holding register requests it. 

2.17 HDLC - The HDLC device contains independent transmitter and receiver sections. 

The HDLC transmitter section receives the data bytes, appends opening and closing flags, 

encodes, and transmits the data. The receiver section searches the data stream for an 

opening flag. When it detects one, it synchronizes with the data fields and decodes the data 

stream into bytes for storage. In both modes the device generates the handshaking signals 

necessary to run the interface. See Sections 5 for details on the operation and control of the 

HDLC registers. 

c-5 
2.18 FLAG SHUTDOWN - The flag shutdown logic guarantees that the external IO 

network transmissions lines are always left in the same state after use. This allows the data 

and poll logic to utilize the same transmission lines. See section 6 for details. 

2.19 DRIVERS and RECEIVERS - These drivers and receivers allow the 10s to interface 

to the IO network. The drivers are enabled by an engage line from the GPC. The receivers 

are always enabled but the input is controlled by the HDLC device. 

2.20 POLL LOGIC - The poll logic which allows the 10s to contend with other IOSs to 

gain control of the IO network. When enabled the poll logic monitors the IO network 

waiting for a quiet time and then starts a poll. If it wins it starts a solicited chain, and if it 

loses it waits for the next poll or quiet and mes again. See section 7 for additional details. 

2.21 TIME DRIVER - The time driver allows the chain to read a time byte that appears on 

the shared bus. 

3.0. INSTRUCTION FORMATS 

The 10s can execute a limited number of instructions to perform its functions. The 

following paragraphs detail the form and function of the 10s instructions. 

3.1. NOP (0000 OOO0)- This instruction updates the chain pointer to the address of the 

next sequential instruction. At the end of the NOP it will fetch that instruction. 

3.2. BRANCH (2000 dddd)- This instruction will fetch the instruction contained at 

location 'dddd' and begin its execution. The Chain Pointer will be updated to point to the 

next instruction (ddddd). 

3.3. MOVE (ass dddd)- This instruction will move a byte, located at any location lss' 

within the first 25610 bytes of 10s memory, to the byte location specified by 'dddd. 

MOVE can be used to store the current value of a hardware register or store a preset value 

into a register. 

3.4. MOVE IMMEDIATE (6Oxx dddd)- This instruction allows a constant, xx, to be 

stored into the destination dddd. 

3.5. INPUT (801B dddd)- This instruction will store incoming HDLC bytes in the buffer 

area specified by 'dddd'. At the start of execution of this instruction the byte reserved for 

the input byte count is set to zero and the current value of the contention status is also 

stored within the buffer. As bytes are received they are stored at the specified buffer 

locations and an internal byte count incremented. A valid message always ends with a 

closing flag, which causes the 10s to then store the byte count, HDLC status registers and 

C-6 
. 

the TIME byte within the incoming packet buffer area. The INPUT instruction has now 

completed and the next sequential instruction is fetched and executed. The maximum 

number of data bytes that a single instruction can store is 12210. If the INPUT contains 

more than 12210 data bytes, data will be lost. However, the buffer will never exceed the 

12810 bytes allotted to it. The byte count which includes the status bytes, will also never 

exceed 80 (12810). This instruction can also end if the time allotted for response is 

exceeded (the value programmed into the timer is reached without a data byte being 

received). However, in this situation none of the status information (HDLC IR & SR 

registers, time and byte count) is saved. An incoming data packet will always have the 

following format. 

Byte count 

HDLC IR register 

HDLC SR register 

contents of Chain Status Register 

data (fmt byte) 

data (last byte received) 

3.6. OUTPUT (EOlC ssss)- This instruction will transmit the bytes specified in the buffer 

starting at location lssss + 1'. The first byte at location 'ssss' contains the value of the 

expression, 80 - NB, where NB is the number of bytes to be transmitted. This instruction 

terminates when all the bytes have been transmitted. 

4.0. MEMORY MAP 

The following is the assigned memory locations in the dual port memory space of the 10s. 

Addresses 10 - 1F are hardware registers, however they are addressed the same as the 

RAM locations. All memory addresses, including the hardware registers are accessible 

from the CPU. 

ADDRESS FUNCTION 

oR/w Solicited Chain Pointer - High Byte (RAM) 

1 R/w Solicited Chain Pointer - Low Byte (RAM) 

2R/w Unsolicited Chain Pointer - High Byte (RAM) 

3m Unsolicited Chain Pointer - Low Byte (RAM) 

c-7 
10 

11 

11 

12 

13 

14 

15 

16 

17 

18 

19 

1A 

1B 

1B 

1c 

1c 

1D 

1E 

1F 

R 

W 

R 

W 

W 

W 

R 

R/w 

R/w 

R/w 

R 

W 

R 

W 

R 

Chain Status Register 

Interface Command Register 

Interface Status Register 

Timer Limit Register 

Poll ID Register - 6 bit polling address 

Poll Prio Register-3 bit prio & polling level 

Time 

Reserved 

Reserved 

HDLC Control Register 1 (CR1) 

HDLC Control Register 2 (CR2) 

HDLC Control Register 3 (CR3) 

HDLC Receiver Holding Register (RHR) 

Address Register (AR) 

HDLC Interrupt Register (IR) 

Transmit Holding Register(THR) 

HDLC Status Register (SR) 

Reserved 

Reserved 

With the exception of the addresses specified above, the rest of the dual port memory space 

can be used for any desired function. However, it should be noted that the MOVE 

instruction can only use the first 25610 addresses for the source byte. 

5.0. REGISTERS 

A description of the hardware registers and their use is contained in the following 

paragraphs. The hardware can execute two types of chains, solicited and unsolicited. 

Solicited chains are defined as command response chains and are meant to be executed 

when the GPC has control of the network. Unsolicited chains are defined as those that are 

performed when the GPC does not have control of the network but must accept all frames 

addressed to it. Unsolicited chains are not defined on the IO network, however, they are 

used as a vehicle while waiting for a poll to be won. On the IC network using the ICIS, 

unsolicited chains are executed whenever the GPC does not have the network, including 

while waiting for a poll to be won. 

5.1. READ/WRITE REGISTERS 

5.1.1. CHAIN POINTER REGISTERS 

5.1.1.1. SOLICITEiD CHAIN POINTER (ADDR = 00 & 01) - The solicited chain pointer 

is used by the 10s to indicate where the next instruction of a solicited chain is located. 

When a new chain is to be started this location is loaded with the address of the first 

C-8 
instruction to be executed. It must be loaded before an execute chain command is issued. 

As each chain instruction is fetched, this location is updated to point to the next sequential 

instruction. The GPC can read this location at any time. However, since the 10s writes 

the locations a byte at a time and the GPC can read them as a word, the value read by the 

GPC may be incorrect if a chain is executing. The GPC should not attempt to write these 

bytes while a chain is executing, since it cannot be guaranteed that the 10s is not presently 

also modifying them. 

5.1.1.2. UNSOLICITED CHAIN POINTER (ADDR = 02 & 03) - The unsolicited chain. 

pointer is used by the 10s to indicate where the next instruction of an unsolicited chain is 

located. When a new chain is to be started this location is loaded with the address of the 

fmt instruction of the unsolicited chain to be executed. It must be loaded before an execute 

chain command is issued. As each chain instruction is fetched, this location is updated to 

point to the next sequential instruction. The GPC can read this location at any time. 

However, since the 10s writes the locations a byte at a time and the GPC can read them as 

a word, the value read by the GPC may be incorrect if a chain is executing. The GPC 

should not attempt to write these bytes while a chain is executing, since it cannot be 

guaranteed that the 10s is not presently also modifying them. Unsolicited chains are 

identical to solicited chains and can execute any mix of instructions. 

5.1.2. HDLC READ/WRITE REGISTERS 

The following is extracted from the Western Digital data sheets on the HDLC chip (WD 

1935). Definitions of bit polarity and sense have been modified to reflect what is seen by 

the AIPS system. 

5.1.2.1. CONTROL REGISTER #1 (CR1) (ADDR = 18) - Control register 1 is used to 

specify the transmitter parameters and the transmitter and receiver enables. It can be loaded 

by a GPC or by a MOVE instruction in the chain. 

NOTE: This register must always be loaded after CR2 and/or CR3. If CR2 and/or CR3 

are ever changed, CR1. must again be reloaded after the change even if there are changes 

being made to CR1. 

7 6 5 4 3 2 1 0 

ACT ACT TC TC TU TU DTR MISC 

REC m1 0 1 0 OUT 

5.1.2.1.1. ACT REC (bit 7) - Activate receiver bit when set to a ZERO (0), the receiver is 

enabled to accept a data stream. When set to a ONE (l), the receiver will ignore any frames 

on the network. 

c-9 
5.1.2.1.2. ACT TRAN (bit 6) - Activate transmitter bit when set to a ZERO (0), the 

encoder and transmitter are enabled to output onto the network. When set to a ONE (1) the 

HDLC device will not transmit data. 

5.1.2.1.3. TC1 and TCO (bits 5 and 4) - The transmit command bits program the device 

into the requested mode. In AIPS, the OUTPUT instruction will function properly only in 

the data mode. These bits and the modes that they generate are as follows: 

bit bit MODE FUNCTION 

5 4 

1 1 data Outputs the contents of the transmitter 

1 0 abort Generates an abort message (not used 

0 1 flag Transmits one flag character (not used 

0 0 FCS Generates the two CRC bytes and a 

holding register 

on AIPS) 

on AIPS) 

closing flag (not used on AIPS) 

5.1.2.1.4. TCLl and TCLO (bits 3 and 2) - These bits control the number of bits per 

character from the transmitter. In AIPS this has been defined as 8 bit bytes. The definition 

of these bits follows: 

bit bit BITS PER 

3 2 CHARACTER 

1 1 8 

1 0 7 

0 1 6 

0 0 5 

5.1.2.1.5. DTR (bit 1) - Data Terminal Ready, a modem signal that is not used in this 

design and should be programmed'to a ONE (1). 

5.1.2.1.6 MISC OUT (bit 0) - Miscellaneous Output, a control signal not implemented in 

this design and should be programmed to a ONE (1). 

5.1.2.2. CONTROL REGISTER #2 (CR2) (ADDR = 19) - Control register #2 specifies 

the receiver parameters and other control functions as defined below. It can be loaded by a 

GPC or by a MOVE instruction in the chain. 

c- 10 
7 6 5 4 .3 2 1 0 

EXT ADDR EXT RCL RCL LOOP SELF AUTO 

CONT COMP ADDR 1 0 TEST FLAG 

5.1.2.2.1. EX" CONT (bit 7) - This bit extends the HDLC control field. It is not used on 

AIPS and must be programmed to a ONE (1). 

5.1.2.2.2. ADDR COW (bit 6) - This bit enables the on-chip address comparator. If set 

to a ZERO (0), the first byte after the opening flag will be compared to the byte stored in 

the AR register. If equal, the data bytes that follow will be output. If address compare is 

enabled, and the address does not compare, all data bytes following will be ignored. If bit 

six is set to a ONE (1) then address comparison is not performed in the chip and all bytes 

between the opening and closing flag are presented to the interface. In AIPS, the 10s and 

the NODES do not use the address compare function but the ICIS does. 

5.1.2.2.3. EXT ADDR (bit 5) - This bit extends the HDLC address field. It is not used on 

AIPS and must be programmed to a ONE (1). 

5.1.2.2.4. RCLl and RCLO (bits 4 and 3) - These bits specify the receiver character 

length. In AIPS this has been defined as 8 bit characters. The definition of these bits is as 

follows : 

bit bit BITS PER 

4 3 CHARACTER 

1 1 8 

1 0 7 

0 1 6 

0 0 5 

5.1.2.2.5. LOOP (bit 2) - Specifies HDLC loop mode, a test function, not implemented in 

the 10s. This bit should always be programmed to a ONE (1). 

5.1.2.2.6. SELF TEST (bit 1) - Chip diagnostic mode, not implemented through the 10s. 

This bit should always be programmed to a ONE (1). 

5.1.2.2.7. AUTO FLAG (bit 0) - When this bit is set to a ZERO (0) and the transmitter is 

enabled, the chip will issue constant flag characters between frames. The 10s design 

utilizes this function and therefore must be set to a zero during an output instruction. 

c-11 
5.1.2.3. CONTROL REGISTER #3 (CR3) (ADDR = 1A) This register is used to control 

the number of residual bits in a transmission. It can be loaded by a GPC or by a MOVE 

instruction in the chain. The definitions of these bits are as follows: 

7 6 5 4 3 2 1 0 

X X X X X TRES TRES TRES 

2 1 0 

5.1.2.3.1. BITS 7 through 3 - Unused 

5.1.2.3.2. TRES 2 - 0 (bits 2, 1 and 0) - These bits define the number of residual bits to 

be sent as the last character in a transmission. Messages sent to and from a NODE contain 

three (3) residual bits. Messages to and from DIUs contain five residual bits. The 

definition of these bits are as follows: 

bit bit bit RESIDUAL BITSFRAME 

2 1 0 

1 1 1 

1 1 0 

1 0 1 

1 0 0 

0 1 1 

0 1 0 

0 0 1 

0 0 0 

No residual bits sent 

1 

2 

3 

4 

5 

6 

7 

5.2. READ ONLY REGISTERS 

5.2.1 STATUS REGISTERS 

5.2.1.1. INTERFACE STATUS REGISTER (Read Only) (ADDR = 11) - This register 

contains status of the interface. 

5.2.1.1.1. UNSOLICITED INPUT RCVD (bit 0) - Set if any unsolicited input is 

received. This bit is set when the end of that message is detected, and reset whenever the 

IOP reads this register. 

5.2.1.1.2 STUCK ON HIGH (bit 1) - This bit is set to a one, if the receiver has been 

high for the IDLE time. It is cleared whenever a transition is detected. 

c- 12 
5.2.1.2. CHAIN STATUS REGISTER (ADDR = 10) - This register contains status of 

both the chain and the contention logic. 

CHAIN STATUS REGISTER (Read Only) 

7 6 5 4 3 2 1 0 

Comp State Default Tx Tx RCV RCV 

Chain Contention Possession Data Poll hY hY 

Fail Fail Fail Good 

5.2.1.2.1. CHAIN COMPLETE (bit 7) - This bit is set whenever the current chain has 

completed. Chain complete is defined as an 10s transition from solicited mode to 

unsolicited mode without the POLL bit in the command register set. It is reset whenever 

the poll bit is changed to a one in the interface command register or the 10s transitions from 

the unsolicited mode to the solicited mode. 

5.2.1.2.2. CONTENTION STATE (bits 6 and 5) - This is the present state of the poll 

logic only. The following are the possible states that can be indicated. 

5.2.1.2.2.1. INACTIVE, BUS RELEASED (00) Both bits are zero whenever the 10s is 

not attempting to gain control of the network. 

5.2.1.2.2.2. WAIT (01) This 10s has been instructed to acquire the network, however no 

POLL has completed since the request occurred. 

. 5.2.1.2.2.3. ATTEMPTED (10) This 10s has entered and lost at least one POLL 

sequence since being commanded to acquire the network. 

5.2.1.2.2.4. POSSESSES (11) This 10s presently has possession of the network. 

5.2.1.2.3. POSSESSION DEFAULT (bit 4) - Indicates that the 10s possesses the 

network and detected an incoming POLL length bit on the network. If a chain is in 

progress when this happens, it will continue to completion. This bit is reset whenever the 

POLL bit in the Command Register is set to zero. 

5.2.1.2.4. DATA TX FAIL (bit 3) - Indicates that a data bit was detected at the receiver 

during a command frame transmission. The chain will continue to completion. This bit is 

reset whenever the POLL bit in the Command Register is set to zero. This bit can only be 

set during a network possession. 

5.2.1.2.5. POLL TX FAIL (bit 2) - Indicates that a data length bit was detected during a 

Poll Sequence. This bit is reset whenever the POLL bit in the Command Register is set to 

zero. 

C-13 
5.2.1.2.6. ANY RCV FAIL (bit 1) - Indicates that at least one response frame has been 

received with a protocol error in it. It is reset whenever a new poll begins or the 10s 

transitions from the unsolicited mode to the solicited mode. 

5.2.1.2.7. ANY RCV GOOD (bit 0) - Indicates that at least one response frame has been 

received without a protocol error. It is reset whenever a new poll begins or the 10s 

transitions from the unsolicited mode to the solicited mode. 

5.2.2. HDLC READ ONLY REGISTERS 

5.2.2.1. RECEIVER HOLDING REGISTER (RHR) (ADDR = 1B) This read-only 

register contains the received bytes as they are decoded from the frame. When executing an 

input instruction the 10s automatically reads this location and stores the received characters 

into the specified location in the dual port memory. 

5.2.2.2. INTERRUPT REGISTER (IR) (ADDR = IC) This read-only register contains 

status information on the state of the HDLC operation. It can be read by the GPC or with a 

MOVE instruction within a chain. Bits 7 through 3 will accumulate information such that if 

the IR is read after several operations, it will have the "OR" of all those frames. The 

defmition of the bits within this register is as follows: 

7 6 5 4 3 2 1 0 

REOM REOM XMlT XMlT DISC DRQI DRQO INTRQ 

NO WITH NO WITH 

ERR ERR ERR URUN 

5.2.2.2.1. REOM NO ERR (bit 7) - When equal to a ZERO, this bit indicates that the 

frame was received without errors. If this bit is read before the closing flag is detected, it 

will not have been updated from the last frame. 

5.2.2.2.2. REOM WITH ERR (bit 6) - When equal to a ZERO, this bit indicates that the 

frame was received with errors. If this bit is read before the closing flag is detected, it will 

not have been updated from the last frame. The errors that are reported here are: CRC, 

overrun, invalid frame and aborted frame. 

5.2.2.2.3. XMIT NO ERR (bit 5) - When equal to ZERO, this bit indicates that the 

transmitted frame had completed without undermn errors. 

5.2.2.2.4. XMIT WITH URUN (bit 4) - When equal to ZERO, this bit indicates that the 

transmitted frame had extra bytes inserted by the chip because the data was not available to 

the transmitter in the allotted time. 

C- 14 
5.2.2.2.5. DISC (bit 3) - This bit is used with modems and in this system has no 

meaning. 

5.2.2.2.6. DRQI (bit 2) - When set to a ZERO, this bit indicates that there is a byte 

available in the Receiver Holding Register (RHR). Reading the RHR sets this bit to a 

ONE. The hardware uses a buffered copy of this bit when storing bytes into dual port 

memory during an input instruction. 

5.2.2.2.7. DRQo (bit 1) - When set to a ZERO, this bit indicates that the Transmit 

Holding Register (THR) is empty and requires another character to prevent an underrun 

error. Storing a byte into the THR sets this bit to a ONE. The hardware uses a buffered 

copy of this bit during an output instruction to read a byte from the dual port memory and 

store it into the THR. 

5.2.2.2.8. INTRQ (bit 0) - This bit is set to a ZERO whenever at least one of the other bits 

in the IR register is set to a ZERO. This bit is set to a ONE whenever the IR is read. A 

buffered copy of this bit is used to terminate a normally completing input or output 

instruction. 

5.2.2.3. STATUS REGISTER (SR) (ADDR = 1D) -. This read-only register contains 

status information that, when used in conjunction with the contents of the Interrupt 

Register, define the cause of the error. 

7 6 5 4 3 2 1 0 

RI CD DSR MISC RCVR RRES RRES RRES 

ERR /ERR /ERR 

IN IDLE 2 1 0 

5.2.2.3.1. RI (bit 7) - A modem signal not implemented in this interface. 

5.2.2.3.2. CD (bit 6) - A modem signal not implemented in this interface. 

5.2.2.3.3. DSR (bit 5) - A modem signal not implemented in this interface. 

5.2.2.3.4. MISC IN (bit 4) - An input discrete not used in this interface. 

5.2.2.3.5. RCVR IDLE (bit 3) - When set to a ZERO, the receiver is idle, i.e. a frame is 

not in process. 

5.2.2.3.6. RRES2 /ERR (bit 2) - This bit has a dual role. If bit 7 in the Interrupt Register 

is a ZERO, then this bit is part of a binary number (see section 5.2.2.3.8) representing the 

C-15 
number of residual bits received. If bit 6 in the Interrupt register is set to a ZERO, and this 

bit is set to ZERO then an aborted or invalid frame was detected. 

5.2.2.3.7. RRES1 /ERR (bit 1) - This bit has a dual role. If bit 7 in the Interrupt Register 

is a ZERO, then this bit is part of a binary number (see section 5.2.2.3.8) representing the 

number of residual bits received. If bit 6 in the Interrupt register is set to a ZERO, and this 

bit is set to ZERO then an overrun error was detected. An overrun error indicates that a 

received byte was not removed from the Receiver Holding Register before the next byte 

was received. That fmt byte will be lost. 

5.2.2.3.8. RRESO /ERR (bit 0) - This bit has a dual role. If bit 7 in the Interrupt Register 

is a ZERO, then this bit is part of a binary number (see below) representing the number of 

residual bits received. If bit 6 in the Interrupt register is set to a ZERO and this bit is set to 

ZERO, then a CRC error was detected. 

bit bit bit RESIDUAL BITSFRAME 

2 1 0 

1 1 1 

1 1 0 

1 0 1 

1 0 0 

0 1 1 

0 1 0 

0 0 1 

0 0 0 

No residual bits sent 

1 

2- 

3 

4 

5 

6 

7 

5.2.3. TIME (read only) (ADDR = 15) - This byte contains a value that is slaved to the 

system timer, incremented by a 6610 microsecond clock and capable of measuring 

16.83010 milliseconds. It can be read by the GPC or by a move instruction in the chain. It 

is automatically appended to all incoming frames that complete in a valid manner. 

5.3. WRITE ONLY REGISTERS 

5.3.1 INTERFACE COMMAND REGISTER (Write Only) (ADDR = 11) - This register 

contains the necessary control bits to operate the 10s. The following are valid commands 

used to control the 10s. The END CHAIN command transitions the 10s from solicited to 

unsolicited mode. The STOP CHAIN command turns the 10s off. 

START CHAIN WITH POLL = 94 

START CHAIN WITHOUT POLL = 80 

C- 16 
END CHAIN = 84 

STOP CHAIN = 20 (followed by a 00 command to prime the interface for 

the next command) 

INTERFACE COMMAND REGISTER (Write Only) 

7 6 5 4 3 2 1 0 

EXECUTE x STOP POLL SPOLL EXECUTE X X 

CHAIN IMM UNSOL 

CHAIN 

5.3.1.1 EXECUTE CHAIN (bit 7) - When only the execute chain bit is set to a one (l), 

this commands the hardware to fetch and start executing instructions starting at the address 

stored in the Solicited Chain Pointer. The chain will start even if a Poll was neither started 

nor won. If however, a poll is to be won first before starting the chain, then bits 7,4 and 2 

must be set to a one. The hardware will then start the polling logic, start an unsolicited 

chain pointed to by the unsolicited chain pointer (usually an input instruction) and when a 

poll is won, automatically start the chain at the location pointed to by the solicited chain 

pointer. 

5.3.1.2. Bit 6 - Not used by the 10s. 

5.3.1.3. STOP IMM (bit 5) - When the stop immediately bit is set to a one (1) the 

hardware will turn off the 10s. Whatever function the 10s is now performing will be 

terminated. This allows the GPC to stop the hardware if it is caught in a loop or otherwise 

malfunctioning . 

5.3.1.4. POLL (bit 4) - Whenever the poll bit is set to a one (1) the logic will attempt to 

gain control of the network by joining the next possible poll sequence. At the end of a 

chain this bit must be reset. 

5.3.1.5. SPOLL (bit 3) - Whenever the spoll bit is set to a one (l), the hardware will 

immediately start to poll. The hardware will not wait for the start of a new poll from 

another site or an idle condition on the network. At the end of a chain this bit must be 

reset. 

5.3.1.6. EXECUTE UNSOL CHAIN (bit 2) - This bit is only recognized by the 

hardware when set in conjunction with the execute chain bit, bit 7. If bits 7 and 2 are both 

set to a one (l), the hardware will execute the chain starting at the location pointed to by the 

unsolicited chain pointer. If a GPC desires to fxst gain control of a network, it sets bits 7, 

4 and 2 to a one and all others to a zero (0). The hardware will enable the polling logic, 

C-17 
start the unsolicited chain at the location pointed to by the unsolicited chain pointer (usually 

an input instruction) and when a poll is won, automatically start the chain at the location 

pointed to by the solicited chain pointer. 

5.3.1.7. Bits 1 and 0 are not used. 

5.3.2. HDLC WRITE ONLY REGISTERS 

5.3.2.1. ADDRESS REGISTER (AR) (ADDR =1B) - This write-only register contains 

the address that the chip is to use for comparison if on-chip address recognition is being 

used. If on-chip address detection is not used, the contents of this register will be ignored. 

5.3.2.2. TRANSMIT HOLDING REGISTER (THR) (ADDR = 1C) - This write-only 

register holds the next data byte to be transmitted. The hardware loads a byte into this 

register during an Output instruction whenever DRQo is set. 

5.3.3. TIMER LIMIT REGISTER (Write only) (ADDR = 12) - The timer limit register 

contains the current value to be used to time out an instruction. A non-zero value written to 

the timer limit register allows the timer to function. The timer is initialized at the beginning 

of each instruction and as each incoming data byte is detected. If an instruction does not 

complete or an incoming data byte is not detected in the programmed number of 

microseconds, the current instruction is terminated and the next sequential instruction 

started. A new value stored in the timer limit register will be accepted when the next 

instruction is started or the next incoming byte is accepted during an input instruction. 

5.3.3.1. TIMER LIMIT VALUE The timer limit is the number of periods of the clock 2F. 

2F has a period of approximately 2 microseconds. The timer has a range of 2 to 512 

microseconds. 

5.3.4. POLL REGISTERS 

5.3.4.1. POLL PRIORITY REGISTER (Write only) (ADDR = 14) - The Poll Priority 

Register contains the six high order polling bits. The three bits labeled PRIO, are used for 

the initial priority of this 10s. They will automatically increment after each poll sequence 

loss until they contain all ones, at which time incrementing is inhibited and the maximum 

priority held. Since the initial state of the PRIO bits are not saved, this register must be 

reloaded whenever the initial polling state is required. The three bits labeled LEVEL, are 

the high order bits of the poll sequence. For the IO network LEVEL 2 is set to a one, 

LEVEL 1 and LEVEL 0 are set to a zero. It can be loaded by a GPC or by a MOVE 

instruction in the chain. 

c-18 
7 6 5 4 3 2 1 0 

X LEVEL LEVEL LEVEL x PRIO PRIO PRIO 

2 1 0 2 1 0 

5.3.4.2. POLL ID REGISTER (Write only) (ADDR = 13) - The Poll ID register contains 

the six (6) low order bits used in the polling procedure. These bits normally contain the 

address that this 10s uses for polling. It can be written into by the GPC or by a MOVE 

instruction within the chain. 

7 6 5 4 3 2 1 0 

X X BIT5 BIT4 BIT3 BIT;! BIT1 BITO 

6.0. FLAG SHUTOFF SYNC 

The 10s uses the same 10 network lines to communicate and to poll. In order to be able to 

perform both functions on the same lines all operations must leave the lines in a known 

state. The HDLC protocol allows the signalling lines to be left in either state, and in fact 

the device used to generate the HDLC protocol does leave the line in either state depending 

upon the data content of the message. The 10s contains logic which upon sensing the end 

of a message utilizes the closing flags to turn off with the line in a low state without 

generating any extraneous data. When the next output message is started, the first flags are 

used to turn the logic back on to the state that the HDLC device attempted to leave the line. 

Again this is done without generating any extraneous bits. The polling logic is fabricated 

so as to always end with the line low. 

7.0. POLLING 

The 10s contains logic which allows it to contend with the other IOSs for use of the IO 

network. If the 10s is to contend for the network, the bits in the interface command 

register must be set to execute, poll and execute unsolicited mode. The logic will start the 

chain pointed to by the unsolicited pointer and simultaneously prime the polling logic. The 

reason for having a unsolicited chain is to give the 10s a place to wait for the poll to 

complete. Therefore, there must be an input instruction without the timer running where 

the 10s will "hang" waiting for the poll to be won. 

The polling logic waits for either a poll to begin or the bus going quiet for 512 

microseconds. When either occurs, the logic will assert a start bit for 48 microseconds. 

This gives all other IOSs time to recognize the start of a poll and join if required. At the 

end of the poll bit the logic compares the state of its input line with the state of its output 

C- 19 
line. If another 10s is joining the poll, the input line will also be high and the 10s must 

continue to poll to determine who will win. It next asserts the fixed priority bits, one at a 

time for 28 microseconds, followed by the variable priority bits and its address bits. At the 

end of each 28 microsecond period it compares its output to what it perceives on the bus. 

If what it hears is the same as what it is transmitting it must continue to the next bit as no 

decision can be made. If it hears a zero while it is transmitting a one, then it knows it has 

won because it has a higher value than all others that are contending. If it hears a one while 

it is transmitting a zero, then it knows it has lost because it has a lower value than at least 

one other contender, and it will stop transmitting and wait for another poll to begin. When 

the 10s decides that it has won it will abort the unsolicited chain and do a context switch to 

the solicited chain and start to execute it. 

The variable priority bits are incremented after each poll sequence loss until they reach the 

maximum value of 7. They will remain at this value until written into by the program or the 

chain. If an 10s detects a data bit during its polling it will terminate the poll and set an 

error bit. 

8.0. DUAL-PORT OPERATION 

The 10s utilizes a time shared 8k x 8 memory for program and input output buffer storage. 

This memory can be alternately accessed by the GPC and the 10s. Each site has 

independent access to the memory for four CPU clock periods. 

8.1 TIMING The dual-port memory utilizes the CPU clock signal 4F, which has a period 

of eight CPU clacks. When 4F is high the GPC has access to the memory and when 4F is 

low the 10s has access to the memory. In the following discussion the 10s timing is 

discussed, the timing as it pertains to the GPC is identical but only happening on the 

opposite phase of 4F. 

If the 10s requires the use of the memory it assert the signal MREQ. MREQ is recognized 

on the first rising edge of CPU clock after 4F falls, which causes a chip select to the 

memory to be asserted. (4F changes state on a falling edge of CPU clock.) Chip select is 

three clock periods wide. The memory cycle is terminated by MCLR being asserted for 

one CPU clock period and chip select being deasserted. 

When a write is specified, the readwrite line will be low. One clock period after chip select 

is asserted, a write enable signal to the memory is asserted. If a read is specified, the 

reawwrite line will be high and on the next rising edge of CPU clock after chip select is 

asserted, an output enable will be asserted. By delaying output enable, none of the 

memory switching transients are seen. 

The operation of the dual-port memory from the GPC side is identical except the memory 

request is initiated with the falling edge of PSEL and terminated with the assertion of 

c-20 
a 

CLRP. The GPC can only make memory requests during the time that 4F is high. The 

address multiplexers are also driven by 4F. 

9.0. HDLC PROTOCOLS 

The HDLC bit orientated protocol was chosen for use on AIPS. HDLC allows automatic 

address detection, control information and a cyclic redundancy error word to detect 

transmission errors. In the 10s automatic address detection and the control byte are not 

used. The 10s operates in a command response mode at all times. It sends a message to a 

site and then waits for a response only when it has control of the IO network. 

An HDLC frame contains an opening flag, address byte, control byte, data bytes (in AIPS 

up to 11910), FCS byte, FCS byte and a closing flag. The opening and closing flag are 

identical and consist of a zero, followed by six ones and a zero. It is not possible for a flag 

to look like data since the HDLC protocol specifies that within the data field after five 

continuous ones a zero is added. 

10.0. ENGAGE 

The AIPS GPCs generate a voted engage signal which is used to enable external functions. 

In a faulty GPC this signal will not be asserted. The 10s uses this signal to enable its bus 

driver that connects it to the IO network. Therefore, a faulty GPC and/or faulty 10s can be 

disconnected and prevented from bring down the IO network. 

11.0. BUFFER FORMATS 

A typical chain will contain both input and output instructions. Each of these instructions 

must have buffer areas within the IOS's memory. The input buffers contain the messages 

that the 10s receives from Nodes and DIUs. The output buffer areas contain the messages 

that the 10s sends to Nodes and DIUs. There are no restrictions on where in memory 

inputs or output are stored. The following is the format of the input and output messages. 

11.1. INPUT BUFFER FORMAT: The third and fourth byte of the input instruction point 

to a location in memory where the 10s will store an incoming message. Each incoming 

message contains a five byte preamble before the data part of the message. The first byte 

contains the byte count, which is the number bytes received plus the four additional bytes 

of the preamble. This can be used as an offset to point to the last byte of the buffer. If the 

input instruction is terminated by the timer expiring, then this byte will contain zero even if 

a partial message had been received before the message stopped. The second and third 

bytes contains the HDLC IR and SR registers respectively. These bytes are used to check 

for HDLC protocol errors. The fourth byte contains a time tag as ncorded at the end of the 

input instruction. The fifth byte contains the contents of the Chain Status Register. From 

c-21 
the sixth byte on is the data content of the message. To recap, input buffers within the 

memory all have the following format: 

Byte Count 

HDLC IR Register 

HDLC SR Register 

Ti 

Content of Chain Status Register 

data (first byte) 

data (last byte) 

In the case of a response from a Node the input format will be as follows: 

Byte Count 

HDLC IR Register 

HDLC SR Register 

Ti 

Content of Chain Status Register 

Node Address 

Port Activity Seen 

Transmission Errors Seen 

Valid Frame Seen 

Error in Node Messages Seen 

Node Port Configuration 

Sum Check 

c-22 
Residue Bits (3 bits residue + 5 bits FCS) 

FCS (next 8 bits of FCS) 

FCS (last 5 bits of FCS + 3 bits of pad) 

11.2. OUTPUT BUFFER FORMAT: The third and fourth bytes of the output instruction 

contain the address within the 10s memory of the output buffer for this instruction. The 

byte located at this location is 80 - NB, where NB is the number of bytes in this output 

message. Following the byte count is the rest of the message. Since the longest message 

that can be received has been defined as 12810 bytes, and each input message contains a 5 

byte preamble and 2 FCS bytes, the maximum data part of an output message can only 

contain 12110 bytes. If more than 12110 bytes are specified, the receiving location will 

truncate the message. The format of the output buffer is as follows: 

Byte Count (80 - NB) 

data 

last data byte 

12.0. EXAMPLE CHAINS 

The following are intended to show how a Chain is programmed in the 10s. 

12.1 EXAMPLE #1 - This example shows a chain which programs the HDLC chip and 

then does an Output frame followed by an input frame. The GPC stores the following 

values into the IOSs memory. (The 10s is a byte oriented device. For simplicity, the 

columns value or contents are two bytes and the columns labeled 10s location or address 

show the address of the high order byte. i.e. 0100 @ 8CX0oO means that a 01 is stored at 

location 8CXOOO and a 00 is stored at location 8CXoO1. The value of X indicates in which 

channel of a GPC the 10s is located. Le. X = 1 for channel A, X = 2 for channel B, X = 4 

for channel C. The high order bit of X is the high order bit of the address of the dual-port 

memory.) 

C-23 
The GPC writes the following locations: 

xx 8CX013 Value of low order polling bits 

4y 8CX014 Value of high order polling bits 

94 8CX011 Commands 10s to execute chain, execute unsolicited and 

poll 

The last store writes into the interface command register which instructs the 10s to enter a 

POLL as soon as it detects one starting, or to start a POLL if it sees the bus go idle. The 

10s meanwhile starts to execute the unsolicited instructions starting at location 200. As 

soon as this 10s thinks it won a POLL, it terminates the unsolicited chain and starts the 

solicited chain at location 100. (All values below are given in HEX.) 

INST ADDRESS CONTENTS DESCRIPTION 

-- 8CX000 0100 Solicited Chain Pointer 

-- 8CX002 0200 Unsolicited Chain Pointer 

0005 8CX100 4015 MOVE the current value of 

8CX102 OlFl time to location OlFl (This could 

be done to find out when the 

solicited part of the chain started) 

o006 8CX104 

8CX 106 

0007 8CX108 

8CXlOA 

0008 8CXlOC 

8CXlOE 

0009 8CX110 

8CX112 

401C 

01F2 

6oFC 

OOlA 

6oFE 

0019 

60BF 

0018 

Read the IR register to clear 

any prior status 

Store an FC in CR3. Sets the 

chip to send 3 residual bits. 

Store an FE in CR2. Puts the 

chip in the auto flag mode. This is 

mandatory to guarantee that all 

receivers will see the flag 

character and no extraneous data. 

Store a BF in CR1. This 

enables the chip in the data mode 

and turns on the transmitter. (CRI 

must be loaded after CR2 and 

CR3) Flags will now be sent until 

data is loaded into the THR. 

C-24 
0010 8CX114 EOlC 

8CX116 1000 

, 

001 1 8CX118 

8CX11A 

0012 8CX11C 

8CXllE 

0013 8CX120 

8CX122 

0014 8CX 124 

8CX 126 

0015 8CX 128 

8CX12A 

0016 8CX12C 

8CX12E 

607F 

0018 

401C 

01F3 

4Q1D 

01F4 

60FF 

0012 

801B 

4000 

Enter the OUTPUT mode. 

The byte count is read from 

location 10oO and the data bytes 

starting at location 1001 are 

transmitted. When the byte count 

reaches 80 the output instruction 

ends. 

There must be at least one 

instruction, that does not read or 

write the HDLC chip after an 

OUTPUT instruction, to allow the 

CRC bytes and closing flag time 

to be transmitted In this example 

a NOP was used, but any non 

HDLC instruction could be used. 

Store a 7F in CR 1. This 

instruction turns off the 

transmitter and turns on the 

receiver. 

Read the IR register and 

store it in location 01F3. This will 

clear the status before the next use 

of the HDLC chip. 

Read the SR register and 

store it in location 01F4. 

Store a FF in the timer 

limit register and enable it to run 

(Timer = 512 micro). 

Enter the INPUT mode. 

Location 4OOO will be cleared to 

accept the incoming byte count. 

If no data is received the 10s will 

wait here for 5 12 microsecond 

before going on to instruction 

#17. If any data byte is received 

before a timeout, the timer will be 

restarted. The 10s will stay in this 

C-25 
0017 8CX130 

8CX132 

0018 8CX134 

8CX 136 

0001 8CX200 

8CX202 

0002 8CX204 

8CX206 

0003 8CX208 

8CX20A 

6OOo 

0012 

2000 

0348 

4015 

OlFO 

6OOo 

m 

801B 

lFOO 

oO04 8CX2OC 2000 

8CX2OE 0204 

instruction until a closing flag is 

received or the timer expires or in 

the case of an infinite input 

message the GPC terminates the 

chain. 

Disable the timer. 

BRANCH to the next 

instruction to be executed in this 

chain at location 0348. (This is 

an example of how bypassing 

might be done. The next 

executable instruction will be at 

location 0348). 

MOVE the current value of 

time to location 01FO. (This could 

be done to log the time that this 

device was fust enabled) 

Turn off the timer. 

Enter the INPUT mode and 

store the frame starting at location 

1F00. In an IOS, the system will 

hang at this instruction for a poll 

to be won since there are no 

unsolicited messages on the VO 

network. 

In an 10s there would be 

only these two instructions. This 

BRANCH allows the 10s to 

return to unsolicited mode without 

the need to restore pointers. 

A possible way that a solicited chain could always end is the following. The last 

instruction in the chain does a branch to a location that performs the desired chain 

C-26 
termination. The advantage of this is that the solicited chain pointer will always have a 

known value in it whenever a chain has gone to completion. 

nnnn xxxx 2000 This is the last instruction of the chain. 

xxxx+2 OFFO It specifies BRANCH to OFFO. 

8CXFFO 6084 This is an END CHAIN command 

8CXFF2 001 1 It turns off the POLL and places the 10s in 

the execute unsolicited mode. The solicited 

chain pointer will contain the value OFF4, 

which can be used to verify that the chain has 

completed. 

C-27 
Report Documentation Page 

I. Report No. 

NASA CR- 18 1874 

2. Government Accession No. 

I 

4. Title and Subtitle 

Advanced Information Processing Systems: Input/Output 

System Services 

19. Security Classif. (of this report) 

Unclassified 

7. Authoris) 

Thomas Masotto and Linda Alger 

20. Security Classif. (of t 

Unclassified 

9. Performing Organization Name and Address 

The Charles Stark Draper Laboratory, Inc. 

555 Technology Square 

Mail Station 3B 

menq Name and Address 

National Aeronautics and Space Administration 

Langley Research Center 

Hampton, VA 23665-5225 

MA 07119 

5. Supplementary Notes 

NASA Langley Technical Monitor: Felix L. Pitts 

0 Fw@) 21. No. of pagas 

193 

3. Recipient’s Catalog No. 

22. Ph 

5. Report Date 

August 1989 

6. Performing Organization Code 

8. Performing Organization Repon No. 

10. Work Unit No. 

506-46-21-05 

11. Contract or Grant No. 

NAS 1-1 8 5 6 5 

13. Type of Report and Period Covered 

Contractor Report 

14. Sponsoring Agency Code 

6. Abstract 

The purpose of this report is to document the functional requirements and 

detailed specifications for the Input/Output (ID) Systems Services of the 

Advanced Information Processing System (AIPS). 

provided to outline the overall architecture and functional requirements of 

the AIPS system. 

as well as a detailed description of the AIPS fault tolerant network 

architecture, while section 1.2 provides an introduction to the AIPS systems 

software. 

and detailed specifications of the I/O User Interface and Communications 

Management modules of the I/o System Services, respectively. Section 4 

illustrates the use of the I/O System Services, while Section 5 concludes with 

a summary of results and suggestions for future work in this area. 

This introductory section is 

Section 1.1 gives a brief wentiew of the AIPS architecture 

Sections 2 and 3 describe the functional requirements and design 

18. Dstribution Statement 

Unclassified - Unlimited 

NASA FORM 1626 OCT 86